AI Act & CRA: Wenn Governance plötzlich zur Produktprüfung wird

AI Act & CRA: Wenn Governance plötzlich zur Produktprüfung wird

Es gab eine Ära, in der „Governance“ der Stoff für Policies, Organigramme und Audit-Agenden war. Man schrieb Richtlinien, legte Rollen fest, dokumentierte Risiken – und hoffte, dass all das im Ernstfall trägt. Diese Ära endet. Mit dem AI Act und dem Cyber Resilience Act (CRA) rückt die EU Governance an den Ort, an dem sich Wahrheit nicht vertuschen lässt: in die Produktentwicklung und den Betrieb. Plötzlich zählt nicht mehr, ob eine Regel existiert, sondern ob Ihr Produkt – Hardware, Software, Service, Modell – unter Last das hält, was Ihr Governance-Papier verspricht. Governance wird zur Produktprüfung. Wer das als Bürokratie empfindet, hat den Kern verfehlt. Wer es als Chance begreift, baut die Brücke zwischen Recht, Risiko und Ingenieursarbeit – und gewinnt Geschwindigkeit, Vertrauen und Marktzugang.

Der Kipppunkt: Von Papier-Governance zu Prüf-Governance

Warum dieser Bruch? Weil zwei Bewegungen zusammentreffen. Erstens KI-basierte Funktionen durchdringen Produkte quer durch alle Branchen – vom Risiko-Scoring in der Bank über visuelle Inspektionen in der Fertigung bis zu generativen Assistenten in SaaS-Plattformen. Zweitens zwingt die Digitalisierung der Lieferketten praktisch jedes Produkt, „mit dem Internet“ zu sprechen – und damit angreifbar zu sein. Wenn Fehlentscheidungen eines Modells diskriminieren können und eine Schwachstelle im Update-Mechanismus Hunderttausende Geräte trifft, dann reichen schöne Policies nicht mehr. Die EU schlägt daraus zwei Fäden: AI Act (Fokus: verantwortliche KI) und CRA (Fokus: durchgängig sichere Produkte mit digitalen Elementen). Beide Fäden laufen in derselben Mechanik zusammen: Konformität = Fähigkeit + Nachweis. Fähigkeit entsteht in Architektur, Code, Daten und Betrieb. Nachweis entsteht in Tests, Telemetrie und technischer Dokumentation.

Was der AI Act wirklich verlangt – jenseits von Schlagworten

Die Erzählung vom AI Act beginnt oft mit Risikoklassen. Ja, die Einordnung in verbotene, hochrisikobehaftete, „begrenzte“ und andere Zwecke strukturiert Pflichten. Aber in der Praxis wirken diese fünf Linien weit stärker:

1. Risikomanagement als Lebenszyklus: Nicht einmalig, sondern über Design, Entwicklung, Validierung, Release und Post-Market. Das ist kein ISO-Zitat, sondern konkrete Arbeit: Hazard-Analysen, Szenarien, Kontrollen, Belege.
2. Daten-Governance: Dokumentierte Herkunft, Eignung, Repräsentativität und Qualität der Trainings-, Validierungs- und Testdaten; Maßnahmen gegen Bias und Leakage; rechtliche Klärung zu Lizenzen und Persönlichkeitsrechten; Lineage statt Legenden.
3. Technische Anforderungen: Genauigkeit, Robustheit, Cybersicherheit – messbar. Dazu Logging und Nachvollziehbarkeit (Audibility), Transparenz gegenüber Nutzern (u. a. Kennzeichnung, Anleitung, Grenzen), menschliche Aufsicht (Human-in-the-Loop oder -on-the-Loop).
4. Qualitätsmanagementsystem: Nicht ein „Ordner“, sondern ein QMS, das Ziele, Rollen, Prozesse, Freigaben, CAPA-Zyklen und Change-Kontrollen definiert – und das mit der Build-Pipeline verheiratet ist.
5. Konformitätsbewertung & Post-Market: Je nach Risikoprofil interner Kontrollpfad oder Notified Body; dazu Post-Market-Monitoring, Vorfall- und Fehlermeldung, Modelldrift-Überwachung und ein eskalationsfähiger PSIRT/AI-Safety-Prozess.

Wer jetzt an Medizinprodukte denkt, liegt nicht falsch: Der AI Act bringt die Denke regulierter Produkte in die Breite – mit KI-spezifischem Vokabular, aber der gleichen Grundlogik: „Sag, was du tust. Tu, was du sagst. Belege, dass es wirkt.“

Generative KI und „GPAI“: Red Teaming wird Pflichtfach

Für leistungsfähige generative Modelle verschiebt der AI Act den Schwerpunkt zusätzlich: systemische Risiken und Missbrauchsgefahren müssen adressiert werden. Das heißt: Red-Team-Tests gegen Prompt-Injection, Jailbreaks, toxische Inhalte, Datenschutzlecks; Eval-Suiten für Halluzinationen, Sicherheit und Fairness; Content-Provenance und Kennzeichnung; Dokumentation zu Trainingsdaten, Energie- und Umweltaspekten; Governance für Foundation-Modelle und deren Downstream-Nutzung. Kurz: Nicht nur „funktioniert der Bot?“, sondern „verhält er sich unter Angriff so, dass wir es vertreten können?“ Und wieder ist das Ergebnis ein Beleg – nicht eine Selbstauskunft.

Was der CRA verlangt – Security als Produkteigenschaft

Der CRA dreht die Schraube auf der Infrastrukteseite. Produkte mit digitalen Elementen – Software, eingebettete Systeme, IoT – müssen sicher entwickelt, ausgeliefert, betrieben und gepflegt werden. Die Pflichten klingen vertraut, werden aber erstmals gesetzlich durchdekliniert:

• Secure-by-Design & by-Default: von der Bedrohungsanalyse bis zur Härtung, von sauberer Update-Kette bis zu sicheren Voreinstellungen.
• Vulnerability Handling & CVD: ein verpflichtender Prozess zur Koordinierten Schwachstellenmeldung, triage-fähig, mit schnellen Behebungsfristen, Kommunikation an Kunden und – je nach Fall – Meldungen an zuständige Stellen.
• CE-Konformität: technische Dokumentation, Konformitätsbewertung (intern oder extern), EU-Konformitätserklärung, CE-Kennzeichnung – wie bei anderen Produktrechtsakten.
• Post-Market-Surveillance: aktives Überwachen der Sicherheit im Feld, Sammeln von Signalen (Crash-Logs, Telemetrie, Rückmeldungen), Updates über den Unterstützungszeitraum, Ende-der-Unterstützung transparent markieren.
• Lieferkette: bekannte Komponenten und Abhängigkeiten; die Praxis etabliert dafür SBOMs (Software Bill of Materials) und – bei KI-Produkten – zunehmend DBOMs (Data Bill of Materials) sowie MBOMs (Model Bill of Materials).

Auch hier gilt: Produktprüfung statt Papierkontrolle. Nicht „wir haben Policies“, sondern „unsere Firmware-Signierkette ist reproduzierbar, unsere Updates verifizierbar, unsere Schwachstellen werden innerhalb definierter Fristen geschlossen, und hier sind die Belege.“

Die Schnittmenge: Governance trifft Engineering – live

AI Act und CRA sind unterschiedliche Gesetze – aber im Maschinenraum treffen sie sich. In beiden Fällen verlangt die Aufsicht die gleiche harte Linie:

• Anforderungen → Tests → Freigabe → Evidenz: Jede normative Forderung wird zu einer messbaren Akzeptanzbedingung in einem Test (funktional, sicherheitlich, robustheitsbezogen).
• Traceability: Von der Anforderung über den Code/ das Modell bis zum Test-Ergebnis – verlinkt in Artefakten.
• Gates in der Pipeline: Kein Release ohne bestandenes Gate. Für CRA-Pflichten (Kritikalitäts-Scans, Signaturprüfung, SBOM-Lücken), für AI-Pflichten (Eval-Suiten, Bias-Checks, Red-Team-Resultate, Logging-Abdeckung).
• Post-Market-Loop: Telemetrie, Vorfälle, Nutzerfeedback fließen in CAPA (Corrective and Preventive Actions), die in Sprints eingeplant, umgesetzt und verifiziert werden.

So wird Governance vom Meeting zur Maschine: sichtbar, reproduzierbar, auditfähig.

Data & Model Governance: Ohne Lineage keine Glaubwürdigkeit

Kein Thema kippt AI-Projekte schneller als unklare Datenherkunft. Der AI Act zwingt zur Ordnung: Datenkataloge mit Quellen, Lizenzen, Einwilligungen; Qualitätsregeln (Vollständigkeit, Konsistenz, Label-Güte); Kontrollmechanismen gegen Leakage (Train/Test-Separation, PII-Filter, synthetische Daten), Dokumente wie Model Cards und Data Sheets. Für generative Systeme kommen Provenance-Mechanismen hinzu: Wasserzeichen, Metadaten, Hash-Verweise. Für CRA-Reife passt es nahtlos: SBOM dokumentiert Komponenten; DBOM/MBOM dokumentieren Daten- und Modellartefakte. Das Ergebnis ist Erklärbarkeit – technisch, rechtlich, ethisch.

Security-Engineering im Produkt: Von SDL zur nachweisbaren Resilienz

Der CRA überführt gängige Security-SDL-Praktiken in Pflichten: Bedrohungsmodellierung, sichere Architektur (Least Privilege, Defense in Depth), Secure Coding, statische/dynamische Analysen, Dependency-Management, Secrets-Handling, Signierung, reproduzierbare Builds, gehärtete Update-Pfade (OTA mit Fail-Safe, Anti-Rollback, Key-Rotation). Die Aufsicht fragt nicht, ob Sie das „wollen“, sondern ob Sie es tun – und wie Sie es messen:

• Mean Time to Remediate je Kritikalität, Alter offener Schwachstellen, Ausnahmefristen mit Kompensation.
• Patch-Adoption im Feld (Telemetrie statt Glauben).
• Update-Erfolg inkl. Rollback-Quoten.
• Exploit-Zyklen vs. Reaktionszeiten.

Wer diese Metriken „lebt“, erfüllt nicht nur den CRA – er reduziert Incidents und Kosten.

Red Teaming, Evals und Safety: Prüfdisziplin für KI

Für KI gilt eine zusätzliche Prüfdisziplin: Sicherheit inhaltlicher Entscheidungen. Das ist neu für viele Engineering-Teams. Es bedeutet:

• Eval-Suiten (Faktentreue, Robustheit, Bias, Sicherheit) mit klaren Grenzwerten und Risikoklassen.
• Red-Team-Szenarien: Prompt-Injection, Jailbreaks, Content-Policy-Verstöße, PII-Exfiltration, „Model Theft“, Datenvergiftung.
• Guardrails: Moderation, Regel-Engines, Retrieval-Kontrollen, Human Oversight.
• Drift-Monitoring: Modell- und Daten-Drift, Out-of-Distribution-Detektion, automatische Fallbacks.
• A/B-Sicherheit: Changes laufen über Kill-Switches, Rollouts sind progressiv, Messpunkte sind vorab definiert.

Auch hier ist der rote Faden: Gates, Metriken, Nachweise – nicht „wir achten darauf“.

Rollen und Verantwortungen: Produkt trifft Aufsicht

Die Governance-Organisation ändert sich. Notwendig sind Rollen, die mancherorts neu sind:

• Product Compliance Owner: Verantwortlich für AI-/CRA-Konformität pro Produktlinie, Gate-Freigaben, technische Dokumentation.
• PSIRT & AI-Safety: Integriertes Team für Schwachstellen, Vorfälle, Safety-Incidents, Meldungen, Kundenkommunikation.
• Data/Model Stewards: Eigentümer für Daten-/Modell-Lineage, Qualitätsregeln, Freigabepfade.
• Authorized Representative / Importer (bei EU-Außenbezug): Zuständig für Konformität und Kommunikation mit Behörden.
• Notified Body-Koordination (wo erforderlich): Schnittstelle für Audit-Planung, Stichproben, Tech-File-Zugriff.

Wichtig: Diese Rollen brauchen Mandat. Ohne Freigaberecht wird Compliance zum Zuschauer.

Konformitätsbewertung: Standards als Abkürzung – nicht als Ersatz

Beide Gesetze stützen sich auf harmonisierte Normen. Wer sie anwendet, profitiert von Vermutung der Konformität. In der Praxis bilden Häuser Mappings: AI-Anforderungen ↔ ISO/IEC 42001 (AI-MS), ISO/IEC 23894 (AI-RM), ISO/IEC 27001/27002, ISO/IEC 27034 (Application Security), ISO/IEC 29119 (Test), ISO/IEC 25010 (Qualität), ETSI/EN-Reihen; CRA-Anforderungen ↔ EN/IEC-Familien (Secure Development, Update, 62443 für OT), ENISA-Leitfäden. Aber Vorsicht: Standards sind Werkzeug, kein Feigenblatt. Die Aufsicht prüft Wirksamkeit – nicht Zitationsdichte.

Post-Market als Chefdisziplin: Betrieb schlägt Broschüre

Sowohl AI Act als auch CRA drehen den Scheinwerfer in die Nutzungsphase. Das ist der Prüfstand, auf dem Governance den Beweis antreten muss:

• Telemetry first: was im Feld passiert, ist sichtbar (ohne übergriffige Datensammelei).
• Signal-Routinen: Ereignisse haben Owner, Schwellen, Eskalation, Fristen, Re-Checks.
• Kommunikation: Kunden und Partner erhalten zeitnahe, klare Hinweise und Updates – nicht nur PDFs, sondern praktische Handlungsanweisungen.
• End-of-Support: klar, früh, gewarnt.
• Learning Loops: Lessons Learned werden zu Backlog-Items mit Termin – und verifiziert.

Das Ergebnis ist messbar: kürzere MTTR, weniger Folgeschäden, besseres Vertrauen – und robuste Audit-Spuren.

Lieferkette: Verträge sind nett, Steuerbarkeit ist Pflicht

AI Act und CRA schauen durch Ihre Verträge hindurch auf die Fähigkeit. Daraus folgt ein anderes Sourcing:

• Due Diligence: Security, Resilienz, Datenethik, QMS – mit Evidenzen.
• Rechte & Pflichten: Informations-/Prüfrechte, Meldepflichten, Sub-Transparenz, Portabilität/Exit.
• Telemetrie statt PDF: KPIs, Logs, SBOMs/DBOMs als Schnittstellen, nicht als E-Mails.
• Assessment-Plan: gemeinsame Tests, Red-Team-Szenarien, Umschaltproben.
• SLA mit Biss: Schwellen, Eskalation, Service-Gutschriften, Sonderprozesse bei „Zero Days“.

So wird aus „Third Party Risk“ eine führbare Disziplin.

Metriken mit Führungskraft: Wenige Zahlen, harte Konsequenz

Gute Governance ist nicht datenschwach, sondern entscheidungsstark. Fünf Familien reichen, wenn sie konsequent sind:

1. Erkennung/Behebung: MTTD/MTTR, Klassifizierungs- und Meldezeiten, First-Time-Fix.
2. Schwachstellen & Patches: Alterskurven je Kritikalität, Ausnahmefristen mit Kompensation, Patch-Adoption im Feld.
3. Wiederherstellung/Safety: Restore-Erfolgsquote je Serviceklasse, RTO/RPO-Erfüllung, Integritätsbelege; für KI: Eval-Scores vs. Schwellen, Red-Team-Trefferquoten, Guardrail-Wirksamkeit.
4. Identitäten: Rezertifizierungsquote, De-Provisioning-Dauer, JIT-Privilegien-Nutzungs- und Review-Raten.
5. Lieferkette/FinOps: SLA-Compliance, Incident-Meldezeiten, Audit-Findings pro Anbieter, Exit-Readiness; Kosten je Service/Transaktion, Budget-Drifts mit Ursachenanalyse.

Jede Zahl hat Schwelle, Owner, Eskalation, Frist, Re-Check. Sonst bleibt sie Tapete.

Drei Praxisbilder – drei Lektionen

IoT-Hersteller
Firmware-Update-Kette gehärtet (Signaturen, Anti-Rollback, Recovery-Partition), SBOM in jedem Release, Telemetrie für Update-Erfolg, PSIRT mit 72h-Kommunikationsfenster, CVD-Prozess mit Bug-Bounty-Integration. Ergebnis: schnelleres Patchen, weniger Feldschäden, CE-Belege auf Knopfdruck.

SaaS mit generativen Funktionen
Eval-Suite vor jedem Release (Faktentreue, Safety), Red-Team-Routinen (Injection, DLP, Policy), Guardrail-Layer mit Moderation und Retrieval-Prüfungen, Kill-Switch-fähiger Rollout, Model-/Data-Drift-Monitore. Ergebnis: niedrigere Risikoexposition, klare AI-Dokumentation, weniger Eskalationen.

Finanz-Dienstleister
AI-Scoring als High-Risk-Use-Case: Daten-Lineage inkl. Lizenzlage, Feature-Kontrollen gegen Proxy-Diskriminierung, Human-Oversight in Grenzfällen, CAPA-Zyklen aus Vorfallsanalysen; CRA-seitig Härtung und Telemetrie für Kunden-Apps. Ergebnis: Prüf-Sicherheit und geringerer Reputationsdruck bei Fehlern.

Anti-Patterns – sicher erkannt, schnell abgestellt

• PDF-Compliance: Kästchen ankreuzen, Gates auslassen. Heilmittel: Policy-as-Code, Gates in CI/CD, Blocker + Ausnahmeprozess.
• Letzte-Meile-Tests: Sicherheit/Evals am Ende aufpudern. Heilmittel: Shift-Left, Bedrohung & Eval in die Story.
• SBOM ohne Nutzung: ausgeben, aber nie prüfen. Heilmittel: Abgleich gegen Advisories, Schwellen-Alerts, Backlog-Verpflichtung.
• CVD als Postfach: Meldungen „gehen ein“. Heilmittel: Triage-SLA, Rückkanal, Veröffentlichung, KPI.
• Modelle ohne Drift: einmal gut, danach hoffen. Heilmittel: Drift-Sensoren, Re-Evals, kontrollierte Re-Trains.
• Zwei Wahrheiten: Tech, Recht, Produkt berichten Unterschiedliches. Heilmittel: Kohärenz-Reviews mit Ticket/Frist/Verifikation.

Roadmap 180 Tage: Von guter Absicht zu prüffähiger Realität

Monat 1–2
Produktlandschaft und KI-Use-Cases klassifizieren (Intended Use, Risiko, CRA-Kritikalität); Design-Faktoren festhalten (Bedrohung, Datenlage, Lieferkette); Gate-Katalog ableiten (AI/CRA-Pflichten → Tests → Akzeptanzkriterien); Rollen mit Mandat benennen (Product Compliance Owner, PSIRT/AI-Safety, Data/Model Steward).

Monat 3–4
CI/CD mit Gates bestücken (SAST/DAST, IaC-Checks, Signierung, SBOM-Erzeugung, Eval-Suiten, Red-Team-Minimums); Evidence-Ablage (versioniert, unveränderlich, Populationslogik); CVD mit Triage-SLA aufsetzen; erste SBOM-Ausrollung; Daten-/Modell-Lineage initial dokumentieren.

Monat 5
Post-Market-Telemetry und Incident-Backbone: Signale, Schwellen, Eskalation, Meldeschienen; Tabletop-Übungen (Vorfall, Meldung, Kundenkommunikation); Restore-Übungen mit Integritätsbeleg; Red-Team-Sprint; Lieferanten-Scorecards (Meldezeiten, SLA, Security-KPI).

Monat 6
Probe-Audit „Operating Effectiveness“: Stichproben an Gates, SBOM-Abgleich, CVD-Fälle, Eval-Ergebnisse, Restore-Logs, Drift-Reports; Lücken schließen, Re-Tests terminieren; Evidence-Days und quartalsweise Kohärenz-Reviews institutionalisiert; Management-Reporting auf Entscheidungen umgestellt.

Danach ist Konformität kein Ausnahmezustand, sondern Betrieb. AI Act & CRA laufen „by design“ – nicht „by Aufregung“.

Ökonomie und Reputation: Warum sich der Aufwand lohnt

Ja, Gates kosten Zeit. SBOMs, Evals, Red-Team-Zyklen, CVD – alles Aufwand. Aber die Gegenrechnung ist simpel: weniger Incidents, kürzere Ausfälle, weniger Rückrufe, bessere Versicherungskonditionen, stärkere Verhandlungsposition gegenüber Kunden und Aufsicht. Vor allem: Vertrauen. Produkte, die unter Druck bestehen, verkaufen sich besser – und kommen schneller durch Beschaffungsschleusen, in denen AI- und CRA-Konformität zum KO-Kriterium wird.

Schluss: Governance ist jetzt eine Ingenieursdisziplin

„AI Act & CRA: Wenn Governance plötzlich zur Produktprüfung wird“ ist keine Drohung, sondern eine Präzisierung. Governance war immer die Kunst, Risiken so zu steuern, dass Ziele erreichbar bleiben. Neu ist, dass dieser Nachweis im Produkt geführt werden muss – im Code, im Modell, im Update, im Telemetrie-Trail. Das klingt nüchtern und ist doch befreiend: Weg von Erklärstücken, hin zu funktionierender Realität. Wer seine Produktentwicklung an Gates, Metriken und Evidenz ausrichtet, erfüllt nicht nur Gesetze. Er baut Systeme, die halten. Und Halt ist die knappste Ressource in einer Welt, die schneller und vernetzter wird, als jedes Policy-Dokument jemals sein kann.