Von Redaktion codAIx | 13. April 2026

Wer ein KI-Produkt auf dem EU-Markt anbietet, muss sich mit zwei Verordnungen gleichzeitig auseinandersetzen, deren Pflichten gestaffelt bis August 2028 wirksam werden: dem Cyber Resilience Act für die Cybersicherheit und dem AI Act für die KI-spezifischen Risiken. Das klingt nach doppeltem Aufwand. In der Praxis gibt es jedoch eine Brücke — eine einseitige Konformitätsfiktion über Art. 12 CRA und, seit dem KI-Omnibus, Art. 42 Abs. 3 AI Act —, die Synergien ermöglicht, wenn man sie kennt.

Zwei Verordnungen, ein Produkt

Die EU hat innerhalb weniger Monate zwei Verordnungen verabschiedet, die für KI-Unternehmen gleichermassen relevant sind. Der AI Act — Verordnung (EU) 2024/1689[2], seit 1. August 2024 in Kraft — schafft den weltweit ersten umfassenden Rechtsrahmen für Künstliche Intelligenz. Der Cyber Resilience Act — Verordnung (EU) 2024/2847[1], seit 10. Dezember 2024 in Kraft — etabliert horizontale Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen.

Beide Verordnungen haben unterschiedliche Regelungsgegenstände. Der AI Act adressiert KI-spezifische Risiken: Bias, Transparenz, menschliche Aufsicht, Datenqualität[2]. Der CRA adressiert die Cybersicherheit über den gesamten Produktlebenszyklus — von der Planung bis zum Ende des Unterstützungszeitraums: sichere Produktgestaltung, Schwachstellenmanagement, Software-Stückliste (englisch software bill of materials, SBOM) und die Behandlung von Sicherheitsvorfällen[1]. Und doch überschneiden sich ihre Anwendungsbereiche: Ein KI-System, das als Software lokal installiert wird, kann selbst ein „Produkt mit digitalen Elementen“ im CRA-Sinne oder Teil eines solchen sein; läuft es als Datenfernverarbeitungslösung (RDPS) eines solchen Produkts, ist es dessen Bestandteil. Zugleich ist es ein „KI-System“ im AI-Act-Sinne. (Ob Ihr Produkt ein solches Produkt mit digitalen Elementen ist, klären der Drei-Elemente-Test und die Grauzone-Analyse aus den vorherigen Teilen dieser Serie.)

Das Ergebnis: Duale Compliance. Ein KI-Unternehmen muss beide Verordnungen gleichzeitig erfüllen, mit unterschiedlichen Anforderungen, unterschiedlichen Fristen und — ausser bei Hochrisiko-KI, für die Art. 52 Abs. 14 CRA die Marktüberwachung bei den KI-Behörden bündelt — unterschiedlichen Aufsichtsbehörden. Der Gesetzgeber hat zugleich eine Brücke eingebaut, die Doppelarbeit vermeiden soll.

Der AI Act im Schnelldurchlauf

Bevor wir die Schnittstellen zum CRA analysieren, ein kompakter Überblick über die Struktur des AI Act.

Der AI Act unterscheidet vier Risikokategorien[2]. KI-Systeme mit unannehmbarem Risiko — etwa Social Scoring oder, zu Strafverfolgungszwecken und vorbehaltlich eng gefasster Ausnahmen, biometrische Echtzeit-Fernidentifizierung in öffentlich zugänglichen Räumen — sind verboten. Ab 2. Dezember 2026 kommen Verbote für das Inverkehrbringen, die Inbetriebnahme und bestimmte Verwendungen von KI-Systemen zur Erzeugung oder Manipulation nicht einvernehmlichen intimen Materials oder von Darstellungen sexuellen Kindesmissbrauchs hinzu; sie sind an abgestufte Voraussetzungen und Ausnahmen geknüpft (Art. 5 Abs. 1 lit. ba und bb, Abs. 1a und 1b AI Act)[6]. Hochrisiko-KI-Systeme, die nach Art. 6 AI Act als solche eingestuft sind[2], unterliegen umfangreichen Anforderungen: Risikomanagementsystem, Daten-Governance, technische Dokumentation, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit. Bei transparenzpflichtigen Systemen müssen Anbieter dafür sorgen, dass Nutzer erkennen, dass sie mit einer KI interagieren, und künstlich erzeugte Inhalte maschinenlesbar kennzeichnen; wer als Betreiber Deepfakes erzeugt, muss offenlegen, dass die Inhalte künstlich erzeugt oder manipuliert sind (Art. 50 Abs. 1, 2 und 4 AI Act). Für alle übrigen KI-Systeme gelten — abgesehen von der KI-Kompetenz nach Art. 4 — keine besonderen Pflichten; freiwillige Verhaltenskodizes nach Art. 95 bleiben möglich.

Die acht Hochrisikobereiche des Anhangs III umfassen Biometrie und Identifizierung, kritische Infrastruktur, Bildung und Berufsausbildung, Beschäftigung, Personalmanagement und Zugang zur Selbstständigkeit, Zugang zu wesentlichen Dienstleistungen, Strafverfolgung, Migration und Grenzschutz sowie Justiz und demokratische Prozesse[2]. Daneben führt auch der zweite Weg des Art. 6 Abs. 1 i. V. m. Anhang I AI Act zur Hochrisiko-Einstufung: KI-Systeme, die als Sicherheitsbauteil eines Produkts dienen oder selbst ein solches Produkt sind, das nach den in Anhang I gelisteten Harmonisierungsvorschriften einer Konformitätsbewertung durch Dritte unterliegt.

Für die CRA-Schnittstelle ist die Hochrisiko-Einstufung entscheidend. Denn nur bei Hochrisiko-KI-Systemen greift der besondere Verbindungsmechanismus zwischen beiden Verordnungen.

Zwei Weichen, die vor der Hochrisiko-Einstufung stehen

Weil an der Hochrisiko-Einstufung so viel hängt, lohnt ein genauer Blick auf zwei Regelungen, die den Weg in die Hochrisiko-Einstufung begrenzen. Beide sind für Softwarehersteller praktisch bedeutsam.

Erste Weiche: Was ist ein Sicherheitsbauteil? Der Anhang-I-Weg des Art. 6 Abs. 1 AI Act hängt an einem definierten Begriff. Die deutsche Fassung der Verordnung spricht von „Sicherheitsbauteil“ — in der Praxis wird synonym von „Sicherheitskomponente“ gesprochen. Nach Art. 3 Nr. 14 AI Act ist das „ein Bestandteil eines Produkts oder KI-Systems, der eine Sicherheitsfunktion für dieses Produkt oder KI-System erfüllt oder dessen Ausfall oder Störung die Gesundheit und Sicherheit von Personen oder Eigentum gefährdet; für die Zwecke dieser Begriffsbestimmung erfüllt ein Bauteil dann eine Sicherheitsfunktion, wenn seine Zweckbestimmung darin besteht, Risiken für die Gesundheit und Sicherheit von Personen oder Eigentum abzuwenden oder zu mindern“[2]. Art. 6 Abs. 1a AI Act stellt zudem klar, dass KI-Systeme, die ausschliesslich für nicht sicherheitsrelevante Aspekte der Nutzerunterstützung, Leistungsoptimierung, Leistungseffizienz, Automatisierung, Benutzerfreundlichkeit oder Qualitätskontrolle verwendet werden, keine Sicherheitsbauteile sind; nach Abs. 1b bleiben Systeme, deren Ausfall oder Fehlfunktion Gesundheit und Sicherheit gefährden würde, Sicherheitsbauteile. Nach Abs. 1c genügt eine Drittprüfungspflicht für den Anhang-I-Weg nicht, wenn sie ausschliesslich auf anderen Risiken als solchen für Gesundheit und Sicherheit beruht — etwa auf Funkfrequenz- oder EMV-Risiken[6]. Für Anbieter von Security-, Monitoring- und Schwachstellenmanagement-Software ist daneben eine Aussage aus Erwägungsgrund 55 AI Act wichtig: „Komponenten, die für die ausschliessliche Verwendung zu Zwecken der Cybersicherheit vorgesehen sind, sollten nicht als Sicherheitsbauteile gelten“[2]. Ein Erwägungsgrund ist Auslegungshilfe, nicht Normtext — die neue Legaldefinition stützt diese Linie nun jedoch normativ. Das Wort „ausschliesslich“ ist wörtlich zu nehmen: Wer mit derselben Komponente zugleich in einen operativen Steuerungsablauf eingreift, kann sehr wohl ein Sicherheitsbauteil bereitstellen. Ein verwandter Gedanke steht in Erwägungsgrund 54 AI Act: Biometrische Systeme, die ausschliesslich dazu bestimmt sind, Massnahmen zur Cybersicherheit und zum Schutz personenbezogener Daten durchführen zu können, sollen nicht als Hochrisiko-KI-Systeme gelten[2].

Zweite Weiche: In Anhang III genannt, aber nicht hochriskant. Die Zuordnung zu einem der acht Bereiche beendet die Prüfung nicht. Nach Art. 6 Abs. 3 AI Act gilt ein in Anhang III genanntes KI-System abweichend von Art. 6 Abs. 2 nicht als hochriskant, wenn es kein erhebliches Risiko der Beeinträchtigung von Gesundheit, Sicherheit oder Grundrechten natürlicher Personen birgt, „indem es unter anderem nicht das Ergebnis der Entscheidungsfindung wesentlich beeinflusst“[2]. Das setzt eine von vier Bedingungen voraus: eine eng gefasste Verfahrensaufgabe (lit. a), die Verbesserung des Ergebnisses einer zuvor abgeschlossenen menschlichen Tätigkeit (lit. b), das Erkennen von Entscheidungsmustern oder Abweichungen davon ohne Ersetzung der menschlichen Bewertung (lit. c) oder eine lediglich vorbereitende Aufgabe (lit. d).

Zwei Punkte begrenzen diese Ausnahme erheblich. Erstens die Rückausnahme: Ein in Anhang III aufgeführtes KI-System gilt „immer dann als hochriskant, wenn es ein Profiling natürlicher Personen vornimmt“ (Art. 6 Abs. 3 UAbs. 3 AI Act)[2]. Zweitens die Folgepflichten: Wer sich auf Art. 6 Abs. 3 stützt, muss nach Art. 6 Abs. 4 AI Act seine Bewertung dokumentieren, bevor das System in Verkehr gebracht oder in Betrieb genommen wird, sie den zuständigen nationalen Behörden auf Verlangen vorlegen — und das System nach Art. 49 Abs. 2 AI Act in der EU-Datenbank registrieren[2]. Die Ausnahme ist also kein stilles Opt-out.

Für die CRA-Schnittstelle folgt daraus: Greift Art. 6 Abs. 3 AI Act, entfällt zugleich die Brücke des Art. 12 CRA. Die CRA-Pflichten bleiben unverändert bestehen und sind dann eigenständig zu erfüllen. (Beide Weichen behandeln wir im nächsten Teil dieser Serie ausführlich — zusammen mit dem Rollenwechsel zum Anbieter nach Art. 25 AI Act, der eintritt, wenn ein Betreiber die Zweckbestimmung eines KI-Systems so verändert, dass es hochriskant wird.)

Art. 12 CRA: Die Brücke zwischen den Verordnungen

Art. 12 CRA[1] ist die zentrale Schnittstellennorm.

Sind die Voraussetzungen des Art. 12 Abs. 1 CRA erfüllt, gilt ein Hochrisiko-KI-System, das zugleich ein Produkt mit digitalen Elementen ist, kraft gesetzlicher Fiktion als mit den Cybersicherheitsanforderungen des Art. 15 KI-VO konform[1][6]. Wichtig: Diese Konformitätsfiktion gilt unbeschadet der Anforderungen an Genauigkeit und Robustheit gemäss Art. 15 AI Act. Die Anforderungen an Genauigkeit und Robustheit müssen daher separat nachgewiesen werden.

Nach Art. 12 Abs. 1 CRA müssen folgende Bedingungen erfüllt sein:

(a) Erfüllung der grundlegenden Cybersicherheitsanforderungen von Teil I Anhang I: Das Produkt muss die konkreten technischen und organisatorischen Sicherheitsanforderungen des ersten Teils des Anhangs erfüllen.

(b) Konformität der Herstellerprozesse mit Teil II Anhang I: Die vom Hersteller eingeleiteten Verfahren müssen den grundlegenden Cybersicherheitsanforderungen des zweiten Teils des Anhangs entsprechen — also den Anforderungen an die Behandlung von Schwachstellen: Software-Stückliste, Behebung, Tests, koordinierte Offenlegung und sichere Updates.

(c) Nachweis in der EU-Konformitätserklärung: Die Erreichung des in Artikel 15 der Verordnung (EU) 2024/1689 erforderlichen Cybersicherheitsschutzniveaus muss in der gemäss CRA ausgestellten EU-Konformitätserklärung (Art. 28 CRA, Anhang V) nachgewiesen werden.

Die Risikobewertung nach Art. 13 Abs. 2 und 3 CRA muss alle relevanten Cyberrisiken erfassen; bei Hochrisiko-KI gehören nach Erwägungsgrund (51) insbesondere Data Poisoning und Adversarial Attacks dazu[1]. Das ist Teil, nicht Zusatz der CRA-Compliance. Darüber hinaus dokumentieren praxisorientierte Frameworks wie MITRE ATLAS[3] sowie die OWASP Machine Learning Security Top 10[4] für Model Inversion und die OWASP Top 10 for LLM Applications[7] für Prompt Injection weitere relevante Angriffsvektoren, die je nach Produkt in die Risikobewertung einzubeziehen sind.

Harmonisierte Normen oder gemeinsame Spezifikationen, die die CRA-Anforderungen im KI-Kontext konkretisieren, können den Nachweis erleichtern. Der Normungsauftrag M/606 richtet sich an CEN, CENELEC und ETSI. Bis zum 11. Oktober 2026 ist noch keine Fundstelle einer CRA-harmonisierten Norm im Amtsblatt veröffentlicht worden. Eine Konformitätsvermutung entsteht nicht schon mit der Ratifizierung einer Norm, sondern erst mit ihrer Fundstelle im Amtsblatt (Art. 27 Abs. 1 CRA). Voraussetzung der Konformitätsfiktion nach Art. 12 Abs. 1 CRA sind harmonisierte Normen ohnehin nicht.

Die Konformitätsfiktion und ihre Reichweite

Der Wortlaut ist eindeutig: Die deutsche Fassung ordnet an, dass die Produkte als konform „gelten“, die englische spricht von „shall be deemed to comply“. Das ist die Sprache einer gesetzlichen Fiktion — anders als bei harmonisierten Normen, für die Art. 27 Abs. 1 CRA ausdrücklich eine Vermutung anordnet („shall be presumed“).

Die Kommentarliteratur stützt diese Lesart: Sörup ordnet Art. 12 Abs. 1 CRA als Fiktion ein, deren Voraussetzungen kumulativ vorliegen müssen (§ 4 Rn. 63)[5]. Als gesetzliche Fiktion ist sie — anders als die Vermutung nach Art. 27 CRA — nicht widerlegbar; ihr Eintritt ist gesetzlich angeordnet, sobald die Tatbestandsvoraussetzungen vorliegen. Unsicherheiten können deshalb beim Vorliegen und bei der Reichweite der Voraussetzungen des Art. 12 Abs. 1 liegen, nicht bei der angeordneten Rechtsfolge.

Für die Praxis bedeutet das: Unternehmen sollten ihre CRA-Konformitätsbewertung so dokumentieren, dass das Vorliegen aller Tatbestandsvoraussetzungen des Art. 12 Abs. 1 nachvollziehbar ist — insbesondere die Erfassung der für das Hochrisiko-KI-System relevanten Cyberrisiken nach Art. 13 Abs. 2 und 3 CRA. Wo die Grenzen einzelner Voraussetzungen verlaufen, wird die künftige Aufsichts- und Rechtsprechungspraxis konkretisieren.

Hochrisiko-KI-Kombinationsprodukte: Verfahrenswechsel zur KI-VO

Eine zentrale, in der Praxis oft übersehene Folge der Schnittstellenkonstruktion regelt Art. 12 Abs. 2 CRA. Wenn ein Produkt zugleich ein Hochrisiko-KI-System im Sinne der KI-VO ist, dürfen Hersteller die Konformitätsbewertung nicht mehr aus den CRA-Modulen frei wählen. Stattdessen müssen sie das Konformitätsbewertungsverfahren nach Art. 43 KI-VO durchlaufen[2].

Der Verfahrensweg verlagert sich also: Die formellen Anforderungen an die Bewertung — interne Kontrolle, Beteiligung notifizierter Stellen, technische Dokumentation — folgen dem KI-VO-Regime und nicht den klassischen CRA-Modulen für nicht-wichtige Produkte. Die materiellen Anforderungen (Anhang I CRA) bleiben gleichwohl bestehen; sie werden in das KI-VO-Verfahren integriert nachgewiesen.

Was das konkret heisst, hängt vom Einstufungsweg ab. Für die meisten Anhang-III-Systeme (Nr. 2 bis 8) sieht Art. 43 Abs. 2 KI-VO die interne Kontrolle nach Anhang VI vor. Für Sicherheitsbauteile von Produkten nach Anhang I Abschnitt A gilt nach Art. 43 Abs. 3 KI-VO das Verfahren des jeweiligen Sektorrechts; eine Drittprüfung allein deshalb, weil das Produkt ein KI-Sicherheitsbauteil enthält, verlangt die KI-VO seit dem KI-Omnibus nicht. Für Maschinen gilt ein Sonderweg: Die Maschinenverordnung steht jetzt in Anhang I Abschnitt B; die KI-Anforderungen werden über delegierte Rechtsakte zur Maschinenverordnung eingeführt, die ab dem 2. August 2028 gelten, und Art. 15 und Art. 43 KI-VO gelten dort nicht unmittelbar. Die Brücke des Art. 12 CRA läuft dort nach unserer Auslegung weitgehend ins Leere; behördlich bestätigt ist das nicht (mehr dazu im nächsten Teil)[6].

Eine wichtige Konsequenz für die Auswahl der Bewertungsstellen: Notifizierte Stellen, die nach der KI-VO benannt sind, sind für diese gebündelten Bewertungen kompetent, sofern bei der Notifizierung auch die Anforderungen an notifizierte Stellen nach Art. 39 CRA mitgeprüft wurden (Sörup, § 4 Rn. 64)[5]. Notifizierte Stellen nach dem CRA können seit dem 11. Juni 2026 benannt werden; in Deutschland läuft das Akkreditierungsverfahren der DAkkS seit dem 28. Juli 2026. Hersteller sollten früh prüfen, ob die vorgesehene Stelle die Anforderungen beider Regime erfüllt (siehe Artikel 09).

Wichtige und kritische Produkte: Rückwechsel zum CRA-Verfahren nach Art. 12 Abs. 3 CRA

Für eine Untergruppe von Hochrisiko-KI-Systemen verschärft sich die Lage noch einmal. Ist ein Hochrisiko-KI-System zugleich ein wichtiges Produkt mit digitalen Elementen nach Anhang III CRA, das einem Drittbewertungsverfahren nach Art. 32 Abs. 2 lit. a oder b oder nach Art. 32 Abs. 3 CRA unterliegt, oder ein kritisches Produkt nach Anhang IV CRA, greift für die grundlegenden Cybersicherheitsanforderungen wieder die CRA-Konformitätsbewertung — allerdings nur, wenn für das KI-System nach der KI-VO an sich die interne Kontrolle nach Anhang VI KI-VO gälte.

Praktisch bedeutet das: Der Hersteller muss die einschlägige CRA-Konformitätsbewertung absolvieren, etwa Modul B+C oder Modul H nach Anhang VIII CRA. Bei Anhang-IV-Produkten ist ein europäisches Cybersicherheitszertifikat nach Art. 8 Abs. 1 CRA erst vorgeschrieben, sobald die Kommission dies per delegiertem Rechtsakt festlegt; ein solcher Rechtsakt ist bis zum 11. Oktober 2026 nicht erlassen worden. Bis dahin gelten die Verfahren nach Art. 32 Abs. 3 CRA. Für die grundlegenden Cybersicherheitsanforderungen tritt das CRA-Verfahren an die Stelle des KI-VO-Verfahrens; für alle übrigen Anforderungen der KI-VO bleibt es bei der internen Kontrolle nach Anhang VI KI-VO (Art. 12 Abs. 3 CRA). Im Ergebnis laufen damit zwei Verfahren für unterschiedliche Anforderungsgruppen nebeneinander; Sörup sieht darin eine „parallele Anwendbarkeit von CRA und KI-VO“ (§ 4 Rn. 65)[5].

Für die Compliance-Planung folgt daraus eine klare Reihenfolgenfrage: Hersteller müssen früh klären, ob ihr Produkt unter Anhang III CRA (Klasse I oder Klasse II) oder Anhang IV CRA fällt — denn nur dann ist überhaupt klar, ob das KI-VO-Verfahren allein ausreicht oder für den Cybersicherheitsteil das CRA-Verfahren gilt. Die Anhänge beschreiben die Produktkategorien funktional (etwa Identitätsmanagementsysteme, Browser und Hypervisoren in Anhang III; Hardwaregeräte mit Sicherheitsboxen, Smart-Meter-Gateways und Chipkarten in Anhang IV).

Die Konformitätsfiktion wirkt einseitig — Art. 12 CRA und Art. 42 Abs. 3 AI Act

Wichtig zu verstehen: Die Konformitätsfiktion zwischen den beiden Verordnungen ist nicht reziprok. Sie läuft ausschliesslich in eine Richtung — über Art. 12 CRA und, seit dem KI-Omnibus, den gleichgerichteten Art. 42 Abs. 3 AI Act, gestützt durch Erwägungsgrund 77 AI Act[2][6]. Dieser Erwägungsgrund ist der rechtspolitische Anker des Mechanismus: Er sieht ausdrücklich vor, dass die Erfüllung der Cybersicherheitsanforderungen des Art. 15 AI Act für Hochrisiko-KI über die EU-Konformitätserklärung nach dem CRA nachgewiesen werden kann.

Eine spiegelbildliche Wirkung zugunsten des CRA gibt es nicht. Auch der neue Art. 42 Abs. 3 AI Act ändert daran nichts: Er übernimmt die Regel des Art. 12 CRA in die KI-VO und wirkt in dieselbe Richtung. Art. 42 Abs. 2 AI Act betrifft Zertifikate nach dem Cybersecurity Act, Art. 95 AI Act[2] freiwillige Verhaltenskodizes — keine dieser Normen verleiht einer AI-Act-Bewertung Wirkung gegenüber dem CRA.

Das Ergebnis ist eine bewusst asymmetrische Konstruktion: Der Unionsgesetzgeber hat sich entschieden, den Cybersicherheitsteil der KI-VO über den CRA zu kanalisieren, nicht umgekehrt. Erwägungsgrund 77 AI Act formuliert dafür den politischen Kompromiss; Art. 12 CRA und Art. 42 Abs. 3 AI Act setzen ihn rechtstechnisch um.

Was bedeutet das praktisch? Für Unternehmen, die ein Hochrisiko-KI-System mit CRA-relevanter Produktarchitektur herstellen, gilt: Die Voraussetzungen des Art. 12 Abs. 1 CRA sollten früh in die Compliance-Planung einbezogen werden. Sind sie erfüllt, greift über diese Brücke die Konformitätsfiktion für den Cybersicherheitsteil des Art. 15 AI Act. Das spart nicht den gesamten AI-Act-Aufwand — Transparenz, menschliche Aufsicht, Datenqualität sowie Genauigkeit und Robustheit müssen separat nachgewiesen werden —, kann den doppelten Nachweis beim Cybersicherheitsteil aber verringern.

Wichtiger Hinweis zur Einschränkung: Die Konformitätsfiktion des Art. 12 CRA gilt ausschliesslich für Hochrisiko-KI-Systeme. Wer ein KI-Produkt herstellt, das nicht nach Art. 6 AI Act[2] als Hochrisiko-KI eingestuft ist — oder bei dem die Ausnahme des Art. 6 Abs. 3 AI Act greift —, erhält diese Rechtswirkung nicht. Er muss die CRA-Anforderungen und die eventuell anwendbaren AI-Act-Anforderungen, etwa Art. 50 AI Act, unabhängig voneinander erfüllen.

Die Zeitachse: Wann was gilt

Die Pflichten der beiden Verordnungen werden gestaffelt anwendbar, was die Komplexität zusätzlich erhöht.

Seit 2. Februar 2025 gilt Art. 4 AI Act zur KI-Kompetenz. In der durch die Verordnung (EU) 2026/1744 geänderten Fassung müssen Anbieter und Betreiber Massnahmen ergreifen, um die Entwicklung der KI-Kompetenz ihres Personals zu unterstützen; ein bestimmtes Kompetenzniveau müssen sie nicht garantieren[2][6].

Seit 2. August 2025 gelten die Pflichten für Anbieter von General-Purpose AI (GPAI) nach Art. 53–56 des AI Act[2]. Wer ein GPAI-Modell — etwa ein Large Language Model — auf dem EU-Markt bereitstellt, muss technische Dokumentation erstellen, Informationen für nachgelagerte Anbieter bereitstellen, eine Strategie zur Einhaltung des Urheberrechts einführen und eine Zusammenfassung der Trainingsinhalte veröffentlichen.

Seit 2. August 2026 gelten die Transparenzpflichten des Art. 50 AI Act[2][6]. KI-Systeme, die direkt mit natürlichen Personen interagieren, müssen diese darüber informieren, dass sie mit einem KI-System kommunizieren — sofern dies nicht aus Sicht einer angemessen informierten, aufmerksamen und verständigen Person offensichtlich ist. Für generative KI-Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, gilt die Kennzeichnungspflicht nach Art. 50 Abs. 2 erst ab dem 2. Dezember 2026 (Art. 111 Abs. 4 AI Act)[6]. Die Hochrisiko-KI-Pflichten gelten nach der Änderungsverordnung (EU) 2026/1744 ab dem 2. Dezember 2027 für Systeme nach Art. 6 Abs. 2 und Anhang III AI Act sowie ab dem 2. August 2028 für Systeme nach Art. 6 Abs. 1 und Anhang I AI Act[6].

Seit 11. September 2026 gelten die CRA-Meldepflichten nach Art. 14 für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle — auch für bereits in Verkehr gebrachte Produkte (Art. 69 Abs. 3 CRA). Gemeldet wird über die einheitliche Meldeplattform der ENISA (Details).

Ab 11. Dezember 2027 gelten die vollständigen CRA-Produktanforderungen[1].

Für KI-Unternehmen ergibt sich daraus kein einheitliches Nacheinander: Die Transparenzpflichten des AI Act und die CRA-Meldepflichten gelten bereits; die Hochrisiko-Pflichten für Anhang-III-Systeme folgen am 2. Dezember 2027 und damit kurz vor den vollständigen CRA-Produktanforderungen am 11. Dezember 2027; die Hochrisiko-Pflichten für Anhang-I-Systeme greifen erst am 2. August 2028[1][6]. Die Vorbereitung auf beide Verordnungen muss deshalb parallel laufen, weil die CRA-Compliance-Infrastruktur — insbesondere SBOM, Schwachstellenmanagement und Risikobewertung — erhebliche Vorlaufzeit erfordert.

Was KI-Unternehmen jetzt tun sollten

Die duale Regulierung stellt KI-Unternehmen vor besondere Herausforderungen, bietet aber auch Chancen für die, die frühzeitig planen.

Der erste Schritt ist die Klassifizierung. Ist Ihr KI-System nach Art. 6 AI Act[2] als Hochrisiko-KI eingestuft — sei es als Sicherheitsbauteil eines drittzertifizierungspflichtigen Produkts oder selbst als solches Produkt (Art. 6 Abs. 1 i. V. m. Anhang I) oder über einen der acht Hochrisiko-Bereiche des Anhangs III? Und greift gegebenenfalls die Ausnahme des Art. 6 Abs. 3 AI Act — mit den Dokumentations- und Registrierungspflichten des Art. 6 Abs. 4 i. V. m. Art. 49 Abs. 2 AI Act als Preis? Diese Frage entscheidet über den gesamten Compliance-Aufwand. Bei Hochrisiko kann die Konformitätsfiktion greifen; dafür müssen die Voraussetzungen des Art. 12 Abs. 1 CRA erfüllt und das Verfahren nach Art. 43 KI-VO — bei wichtigen und kritischen Produkten gegebenenfalls für den Cybersicherheitsteil das CRA-Verfahren nach Art. 12 Abs. 3 CRA — eingeplant werden. Bei Nicht-Hochrisiko entfällt die Konformitätsfiktion, aber auch ein grosser Teil der AI-Act-Pflichten.

Zur Klassifizierung gehört auch die Frage, wer überhaupt Anbieter ist. Nach Art. 25 Abs. 1 lit. c AI Act gilt ein Betreiber selbst als Anbieter mit den Pflichten aus Art. 16 AI Act, wenn er die Zweckbestimmung eines nicht als hochriskant eingestuften KI-Systems so verändert, dass es zu einem Hochrisiko-KI-System im Sinne von Art. 6 AI Act wird[2]. Für Softwarehersteller, die KI-Assistenzfunktionen ausliefern, hat dieser Rollenwechsel zwei Seiten: Er kann sie entlasten, weil der Kunde zum Anbieter wird — er belastet aber den Kunden, und der ursprüngliche Anbieter bleibt nach Art. 25 Abs. 2 AI Act zur Zusammenarbeit verpflichtet; das ist seit dem KI-Omnibus bussgeldbewehrt (Art. 99 Abs. 4 lit. da AI Act). Diese Pflicht entfällt nur, wenn er eindeutig festgelegt hat, dass sein System nicht in ein Hochrisiko-KI-System umgewandelt werden darf (Art. 25 Abs. 2 letzter UAbs. AI Act)[2][6]. Vertragliche Regelungen verteilen dabei das Risiko im Innenverhältnis; an der objektiven Einstufung gegenüber Behörden ändern sie nichts.

Der zweite Schritt ist die Risikobewertung mit KI-Fokus. Auch wenn Ihr Produkt nicht als Hochrisiko eingestuft ist, gehören KI-spezifische Angriffsvektoren in die Risikobewertung nach Art. 13 Abs. 2 und 3 CRA, soweit sie für Ihr Produkt relevant sind. Erwägungsgrund (51) CRA, der Data Poisoning und Adversarial Attacks ausdrücklich nennt, bezieht sich zwar nur auf Hochrisiko-KI, gibt aber einen guten Massstab. Darüber hinaus können Model Inversion und Prompt Injection je nach Produkt relevante Angriffsvektoren sein (Fundstellen siehe oben).

Der dritte Schritt ist die integrierte Compliance-Architektur. Statt CRA und AI Act als zwei getrennte Compliance-Projekte aufzusetzen, lohnt es sich, eine gemeinsame Struktur zu schaffen: ein Risikomanagementsystem, das beide Verordnungen abdeckt, eine technische Dokumentation, die CRA-Konformität und AI-Act-Konformität gemeinsam nachweist, und ein Schwachstellenmanagement, das klassische wie KI-spezifische Schwachstellen erfasst und nachverfolgt. (Welche CRA-Pflichten je nach Produktarchitektur konkret greifen — von der vollständigen RDPS-Compliance bis zu den abgestuften Sorgfaltspflichten nach Art. 13 —, haben wir im dritten Teil dieser Serie analysiert.)

Das Wichtigste für Hersteller

  • Art. 12 CRA und Art. 42 Abs. 3 AI Act wirken nur in eine Richtung: Wer die Voraussetzungen des Art. 12 Abs. 1 CRA erfüllt, gilt für die Cybersicherheitsanforderungen des Art. 15 AI Act als konform — umgekehrt nicht.
  • Die Fiktion setzt eine Hochrisiko-Einstufung nach Art. 6 AI Act voraus und lässt die Anforderungen an Genauigkeit und Robustheit sowie die übrigen Pflichten des AI Act unberührt.
  • Bei Hochrisiko-KI gehören KI-spezifische Angriffe wie Data Poisoning und Adversarial Attacks in die CRA-Risikobewertung nach Art. 13 Abs. 2 und 3 CRA; bei anderen KI-Produkten, soweit sie für das Produkt relevant sind.
  • Das Konformitätsbewertungsverfahren richtet sich bei Hochrisiko-KI grundsätzlich nach Art. 43 KI-VO; bei wichtigen und kritischen Produkten gilt unter den Voraussetzungen des Art. 12 Abs. 3 CRA für den Cybersicherheitsteil das CRA-Verfahren.
  • Die Fristen laufen gestaffelt bis zum 2. August 2028; die CRA-Meldepflichten gelten bereits seit dem 11. September 2026.

Enthält Ihr Produkt KI-Komponenten? Der CRA-Quick-Check gibt Ihnen eine kostenlose und unverbindliche Ersteinschätzung zu Ihren möglichen CRA-Pflichten und Ihrer CRA-Produktklasse. Die Schnittstellen zum AI Act — Hochrisiko-Einstufung und Konformitätsfiktion nach Art. 12 CRA — behandelt dieser Artikel; ihre verbindliche Beurteilung erfordert eine individuelle Prüfung.

Hinweis zur Methodik

Die rechtlichen Aussagen wurden gegen die Primärquellen geprüft: die Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 12 (einschliesslich Abs. 2 zum Verfahrenswechsel und Abs. 3 zum Rückwechsel zum CRA-Verfahren bei wichtigen und kritischen Produkten), Art. 13 Abs. 2 und 3, Art. 28, Art. 32 Abs. 2 und 3, Art. 52 Abs. 14, Art. 69 Abs. 3, Art. 71 Abs. 2 und Erwägungsgrund (51), sowie die Verordnung (EU) 2024/1689 (AI Act) in der durch die Verordnung (EU) 2026/1744 geänderten Fassung, insbesondere Art. 2 Abs. 2, Art. 3 Nr. 14, Art. 4, Art. 5, Art. 6 Abs. 1 bis 4, Art. 15, Art. 16, Art. 25 Abs. 1 lit. c und Abs. 2, Art. 42 (Abs. 2: Cybersecurity Act; Abs. 3: Spiegelnorm zu Art. 12 CRA), Art. 43, Art. 49 Abs. 2, Art. 50, Art. 53 Abs. 1, Art. 95, Art. 99 Abs. 4 lit. da, Art. 111 Abs. 4 und Art. 113 sowie die Erwägungsgründe 54, 55 und 77.

Erwägungsgründe sind Auslegungshilfe und kein Normtext. Die in Erwägungsgrund 55 AI Act genannten Beispiele — Systeme für die Überwachung des Wasserdrucks und Feuermelder-Kontrollsysteme in Cloud-Computing-Zentren — sind dort Beispiele für Sicherheitsbauteile kritischer Infrastruktur, nicht Beispiele für die Cybersicherheits-Ausnahme.

Für die rechtsdogmatische Einordnung der Konformitätsfiktion sowie für den Verfahrenswechsel zur KI-VO und den Rückwechsel zum CRA-Verfahren bei wichtigen und kritischen Produkten wurde der CRA-Kommentar herangezogen (Sörup, in: Wiebe (Hrsg.), Das neue Recht der Cyberresilienz — Kommentar zur CRA, Nomos 2025, § 4 Rn. 63–65)[5].

Die Zuordnung KI-spezifischer Angriffsvektoren erfolgt differenziert: Data Poisoning und Adversarial Attacks sind in Erwägungsgrund (51) CRA namentlich benannt. Model Inversion und Prompt Injection sind dort nicht namentlich erwähnt; sie werden anhand von MITRE ATLAS, der OWASP Machine Learning Security Top 10 (Model Inversion) und der OWASP Top 10 for LLM Applications (Prompt Injection) eingeordnet.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyber Resilience Act). ABl. L, 20.11.2024. https://eur-lex.europa.eu/eli/reg/2024/2847/oj

[2] Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates vom 13. Juni 2024 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz und zur Änderung der Verordnungen (EG) Nr. 300/2008, (EU) Nr. 167/2013, (EU) Nr. 168/2013, (EU) 2018/858, (EU) 2018/1139 und (EU) 2019/2144 und der Richtlinien 2014/90/EU, (EU) 2016/797 und (EU) 2020/1828 (Verordnung über künstliche Intelligenz), in der durch die Verordnung (EU) 2026/1744 geänderten Fassung; insbesondere Art. 2 Abs. 2, Art. 3 Nr. 12 und 14, Art. 4, Art. 5, Art. 6 Abs. 1 bis 4, Art. 15, Art. 16, Art. 25 Abs. 1 und 2, Art. 42 Abs. 2 und 3, Art. 43, Art. 49 Abs. 2, Art. 50, Art. 53 Abs. 1, Art. 95, Art. 99 Abs. 4 lit. da, Art. 111 Abs. 4, Art. 113, Anhang I und Anhang III sowie die Erwägungsgründe 53, 54, 55 und 77. ABl. L, 12.07.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

[3] MITRE ATLAS (Adversarial Threat Landscape for AI Systems), https://atlas.mitre.org – Ein Threat-Modelling-Framework zur Dokumentation von Angriffstechniken gegen KI-Systeme, mit strukturierter Katalogisierung von Data Poisoning, Adversarial Attacks, Model Inversion und verwandten Angriffsmustern.

[4] OWASP Machine Learning Security Top 10 (ML Top 10), https://owasp.org/www-project-machine-learning-security-top-10/ – Rahmenwerk des Open Web Application Security Project zur Identifikation und Mitigation der zehn kritischsten Sicherheitsrisiken in Machine-Learning-Systemen.

[5] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Sörup, § 4 Rn. 63–65 (§ 4 F II KI-Verordnung, zu Art. 12 CRA: Rn. 63 Konformitätsfiktion, Rn. 64 Verfahrenswechsel auf Art. 43 KI-VO und Zuständigkeit notifizierter Stellen, Rn. 65 parallele Anwendbarkeit der CRA-Verfahren bei wichtigen und kritischen Produkten nach Anhang III bzw. Anhang IV CRA).

[6] Verordnung (EU) 2026/1744 des Europäischen Parlaments und des Rates vom 8. Juli 2026 zur Änderung der Verordnungen (EU) 2024/1689, (EU) 2018/1139 und (EU) 2023/1230 im Hinblick auf die Vereinfachung der Umsetzung harmonisierter Vorschriften für künstliche Intelligenz (Digital-Omnibus-Verordnung zur KI), ABl. L, 24.07.2026; insbesondere Art. 1 Nr. 2, 4, 5, 7, 8, 12, 18, 19, 38, 39, 40 und 41 sowie Art. 3 Nr. 1. https://eur-lex.europa.eu/eli/reg/2026/1744/oj

[7] OWASP Top 10 for Large Language Model Applications 2025, LLM01: Prompt Injection.

Aktualisierung 11.10.2026: Anpassung an die Verordnung (EU) 2026/1744, insbesondere Art. 42 Abs. 3, Art. 3 Nr. 14 und Art. 4 AI Act, sowie an den operativen Start der CRA-Meldepflichten am 11.09.2026.

Haftungsausschluss: Dieser Beitrag ist eine allgemeine Information zum Cyber Resilience Act und ersetzt keine individuelle Rechtsberatung. Eine verbindliche Beurteilung Ihres konkreten Produkts und Ihrer konkreten Pflichten setzt eine Einzelfallprüfung voraus. Keine Rechtsberatung im Sinne des RDG. Das gilt auch für die Ausführungen zur KI-Verordnung. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 13.04.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: Hochrisiko-KI und CRA: Warum Art. 12 kein Freifahrtschein ist — warum Art. 12 CRA kein Freifahrtschein ist, weshalb seine drei Bedingungen anspruchsvoller sind, als sie auf den ersten Blick wirken, und was das für Ihre Compliance-Strategie bedeutet.