Von Redaktion codAIx | 27. April 2026

Auf den ersten Blick löst Art. 12 des Cyber Resilience Act ein lästiges Doppelproblem: Wer die CRA-Cybersicherheitsanforderungen erfüllt, gilt unter bestimmten Voraussetzungen auch als konform mit den Cybersicherheitsanforderungen des AI Act[1][2][10]. Ein Freifahrtschein ist das nicht. Die rechtlichen Voraussetzungen und die praktische Umsetzung reichen tiefer, als die kurze Vorschrift vermuten lässt. Risikobewertungen müssen KI-spezifische Angriffsvektoren und gegebenenfalls damit verbundene Grundrechtsrisiken abbilden; hinzu kommt das Konformitätsbewertungsverfahren nach Art. 43 KI-VO.

Die Konformitätsfiktion: Theorie und Realität

Der vorherige Artikel dieser Serie ordnet das Zusammenspiel von CRA und AI Act im Überblick ein. Für Hochrisiko-KI-Systeme, die zugleich Produkte mit digitalen Elementen sind, ordnet Art. 12 CRA eine einseitige Konformitätsfiktion zugunsten von Art. 15 AI Act an; seit dem KI-Omnibus ist sie in Art. 42 Abs. 3 AI Act gespiegelt[1][2][10]. Ihr Zweck: Doppelarbeit bei der Cybersicherheit vermeiden. Diese gesetzliche Fiktion ist von der widerlegbaren Konformitätsvermutung nach Art. 27 CRA zu unterscheiden.

Die Kurzform klingt einfach: CRA-Compliance deckt die Cybersicherheit nach dem AI Act ab. Bei der Umsetzung relativiert sich dieser Automatismus allerdings schnell. Unternehmen treffen auf eine erhebliche Einschränkung, drei praktische Hürden und ein verschachteltes Konformitätsbewertungsverfahren.

Die kritische Einschränkung: „Unbeschadet“

Art. 12 Abs. 1 CRA enthält eine Einschränkung mit erheblichen Compliance-Implikationen: Die Konformitätsfiktion gilt unbeschadet der Anforderungen bezüglich Genauigkeit und Robustheit nach Art. 15 KI-VO. Art. 15 KI-VO regelt Genauigkeit, Robustheit und Cybersicherheit für Hochrisiko-KI-Systeme gemeinsam in einer Norm; die Fiktion des Art. 12 CRA deckt jedoch nur den Cybersicherheits-Teil ab. Die Anforderungen an die Genauigkeit (Art. 15 Abs. 1 bis 3 KI-VO) und an die Robustheit gegenüber Fehlern, Störungen und Unstimmigkeiten einschliesslich Rückkopplungsschleifen (Art. 15 Abs. 4 KI-VO) bleiben separat unter dem AI Act zu erfüllen. Die Widerstandsfähigkeit gegen Angriffe unbefugter Dritter — einschliesslich Data Poisoning und Adversarial Examples — ordnet Art. 15 Abs. 5 KI-VO dagegen der Cybersicherheit zu; sie wird von der Fiktion erfasst, wenn die Voraussetzungen des Art. 12 Abs. 1 CRA erfüllt sind. Dafür sollte die CRA-Risikobewertung diese KI-spezifischen Angriffe ausdrücklich berücksichtigen (Erwägungsgrund (51) CRA).

Auch bei abgedeckter Cybersicherheit bleibt das Risikomanagement für Modellgenauigkeit, Verzerrungen (Bias) und die Robustheit gegenüber Fehlern deshalb eine separate Compliance-Pflicht unter dem AI Act. Wer die Unbeschadet-Klausel — englisch „without prejudice“ — übersieht, lässt einen Teil der Risiken ungeprüft.

Die drei rechtlichen Bedingungen von Art. 12 Abs. 1 CRA

Art. 12 Abs. 1 CRA formuliert drei Bedingungen der Konformitätsfiktion. Häufig werden sie verkürzt als „Hochrisiko-Einstufung, KI-spezifische Risiken, harmonisierte Normen“ wiedergegeben. Der Verordnungstext nennt andere:

(a) Erfüllung der grundlegenden Cybersicherheitsanforderungen nach Teil I des Anhangs I des CRA: Das Produkt mit digitalen Elementen — einschliesslich aller KI-Komponenten — muss die technischen Anforderungen erfüllen, die der CRA in Teil I des Anhangs I definiert. Das umfasst auch die KI-spezifischen Anfälligkeiten (siehe unten).

(b) Verfahren zur Schwachstellenbehandlung nach Teil II des Anhangs I des CRA: Die vom Hersteller festgelegten Verfahren zur Behandlung von Schwachstellen — Software-Stückliste (englisch software bill of materials, SBOM), Behebung, Tests, koordinierte Offenlegung und sichere Updates — müssen Teil II des Anhangs I entsprechen.

(c) Konformitätsnachweis in der EU-Konformitätserklärung: Das Erreichen des nach Art. 15 KI-VO erforderlichen Cybersicherheitsniveaus muss in der EU-Konformitätserklärung nach Art. 28 CRA nachgewiesen werden — Anhang V CRA regelt den verpflichtenden Inhalt dieser Erklärung. Dies ist der dokumentarische Nachweis, keine eigenständige technische Anforderung.

Rechtlich handelt es sich bei diesen drei Punkten um Voraussetzungen, nicht um „Hürden“. In der Umsetzung kommen jedoch praktische Schwierigkeiten hinzu, die Unternehmen bewältigen müssen.

Hürde 1: Ist Ihr KI-System wirklich Hochrisiko?

Die Konformitätsfiktion greift ausschliesslich für KI-Systeme, die nach Art. 6 KI-VO als hochriskant eingestuft sind[2][10] — entweder nach Art. 6 Abs. 1 i. V. m. Anhang I Abschnitt A KI-VO (Sicherheitsbauteile drittzertifizierungspflichtiger Produkte, z. B. Medizinprodukte oder Spielzeug) oder nach Art. 6 Abs. 2 i. V. m. Anhang III KI-VO. Für Maschinen gilt seit dem KI-Omnibus ein Sonderweg: Die Maschinenverordnung steht nun in Anhang I Abschnitt B. Die KI-Anforderungen werden über delegierte Rechtsakte zur Maschinenverordnung eingeführt, die ab dem 2. August 2028 gelten; Art. 15 und Art. 43 AI Act gelten für diese Systeme nicht unmittelbar (Art. 2 Abs. 2 AI Act)[10]. Nach unserer Auslegung laufen damit auch die Fiktion des Art. 12 Abs. 1 CRA und der Verfahrenswechsel nach Art. 12 Abs. 2 CRA für KI-Sicherheitsbauteile in Maschinen weitgehend ins Leere; behördlich bestätigt ist das nicht. Für KI-Systeme, die gar nicht hochriskant sind, existiert ohnehin keine Brücke zwischen den beiden Verordnungen.

Was ein „Sicherheitsbauteil“ ist — und was nach Erwägungsgrund 55 KI-VO keines sein soll

Der Weg über Art. 6 Abs. 1 KI-VO hängt an einem Begriff, den die Verordnung selbst definiert. Nach Art. 3 Nr. 14 KI-VO ist ein Sicherheitsbauteil „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“. Seit dem KI-Omnibus ergänzt die Definition: Ein Bauteil erfüllt eine Sicherheitsfunktion, wenn seine Zweckbestimmung darin besteht, Risiken für Gesundheit und Sicherheit von Personen oder Eigentum abzuwenden oder zu mindern[2][10]. Die deutsche Fassung der KI-VO verwendet durchgängig den Begriff „Sicherheitsbauteil“; in der Praxis und in diesem Artikel wird daneben synonym von „Sicherheitskomponente“ gesprochen. Derselbe Begriff kehrt in Anhang III Nr. 2 KI-VO wieder, wo es um KI als Sicherheitsbauteil in kritischer Infrastruktur geht.

Für Hersteller von Security-, Monitoring- und Schwachstellenmanagement-Software lohnt ein genauer Blick auf Erwägungsgrund 55 KI-VO. Die Passage geht in der Diskussion leicht unter. Zunächst beschreibt sie Sicherheitsbauteile kritischer Infrastruktur als Systeme, die deren physische Integrität oder die Gesundheit und Sicherheit von Personen und Eigentum schützen sollen, „die aber nicht notwendig sind, damit das System funktioniert“. Danach folgt die für Sicherheitssoftware entscheidende Aussage: „Komponenten, die für die ausschliessliche Verwendung zu Zwecken der Cybersicherheit vorgesehen sind, sollten nicht als Sicherheitsbauteile gelten“[2].

Ein verwandter Gedanke steht in Erwägungsgrund 54 KI-VO für den biometrischen Bereich: 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].

Beim Lesen dieser Passage sind vier Dinge auseinanderzuhalten:

Rechtliche Einordnung: Ein Erwägungsgrund ist Auslegungshilfe, nicht Normtext. Die verbindliche Einstufungsregel steht in Art. 6 KI-VO, die Definition in Art. 3 Nr. 14 KI-VO. Erwägungsgrund 55 formuliert im Konjunktiv („sollten nicht ... gelten“) und erklärt, wie der Gesetzgeber den Begriff verstanden wissen wollte. Seit dem KI-Omnibus ist diese Linie zusätzlich im Normtext verankert: Nach Art. 6 Abs. 1a KI-VO gelten KI-Systeme, die ausschliesslich für nicht sicherheitsrelevante Aspekte der Nutzerunterstützung, Leistungsoptimierung, Leistungseffizienz, Automatisierung, Benutzerfreundlichkeit oder Qualitätskontrolle verwendet werden, nicht als Sicherheitsbauteile; Cybersicherheit nennt die Vorschrift nicht. Ungeachtet dessen gelten nach Abs. 1b Systeme, deren Ausfall oder Fehlfunktion Gesundheit und Sicherheit gefährden würde, als Sicherheitsbauteile. Nach unserer Auslegung entscheiden deshalb die Zweckbestimmung (Art. 3 Nr. 12 und 14 KI-VO) und die Ausfallfolgen, nicht die Selbstauskunft „nur Cybersicherheit“. 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[10].

Reichweite des Wortes „ausschliesslich“: Die Entlastung gilt nur für Komponenten, die zur ausschliesslichen Verwendung für Cybersicherheitszwecke vorgesehen sind. Greift dasselbe Modul zugleich in einen operativen Steuerungsablauf ein — verändert es etwa Anlagenparameter, schaltet Prozesse ab oder steuert physische Zugänge —, kann es sehr wohl ein Sicherheitsbauteil sein. Nicht der Produktname zieht die Grenze, sondern die tatsächliche Funktion im Zielsystem. Ein Intrusion-Detection-System, das ausschliesslich detektiert und meldet, ist anders einzuordnen als eine Lösung, die im Ernstfall aktiv in die Prozessführung einer Wasser- oder Stromversorgung eingreift.

Funktion der Beispiele: Die im Erwägungsgrund genannten Fälle sind Beispiele für Sicherheitsbauteile, nicht für die Ausnahme. Erwägungsgrund 55 nennt „Systeme für die Überwachung des Wasserdrucks oder Feuermelder-Kontrollsysteme in Cloud-Computing-Zentren“ ausdrücklich als Sicherheitsbauteile kritischer Infrastruktur[2]. Sie illustrieren, was erfasst ist, und grenzen mittelbar das Verständnis des Gesetzgebers ab: Gemeint ist der Schutz physischer Integrität, nicht der Schutz von Daten und Systemen vor Angriffen.

Der zweite Einstufungsweg bleibt offen: Wer nach Erwägungsgrund 55 kein Sicherheitsbauteil bereitstellt, fällt damit lediglich aus dem Weg über Art. 6 Abs. 1 i. V. m. Anhang I KI-VO. Eine Einstufung über Anhang III KI-VO ist damit nicht automatisch ausgeschlossen; sie folgt eigenen Kriterien. Beide Wege sind getrennt zu prüfen.

Anbieter von Sicherheitssoftware sollten diese Einordnung dokumentieren, statt sie stillschweigend zu unterstellen. Wer sich auf den ausschliesslichen Cybersicherheitszweck seiner Komponente beruft, hält dafür die Funktionsbeschreibung, die Schnittstellen zum Zielsystem und ausgeschlossene Eingriffsmöglichkeiten nachvollziehbar fest.

Die acht Bereiche des Anhangs III

Anhang III KI-VO listet acht Bereiche (Nummern), die definieren, welche KI-Anwendungen als hochriskant gelten[2]. Die Liste ist abschliessend, aber innerhalb der Bereiche besteht Auslegungsspielraum.

Der erste Bereich (Anhang III Nr. 1) umfasst biometrische Fernidentifizierung, biometrische Kategorisierung anhand sensibler Merkmale und Emotionserkennung. Die Hochrisiko-Einstufung trifft hier nicht alle biometrischen Systeme gleichermassen: Anhang III Nr. 1 lit. a KI-VO enthält die Ausnahme für reine biometrische Verifizierung (Abgleich 1:1, deren einziger Zweck die Identitätsbestätigung ist) — diese Ausnahme gilt ausschliesslich für lit. a, nicht für lit. b oder lit. c.

Der zweite Bereich (Anhang III Nr. 2) betrifft die Verwaltung und den Betrieb kritischer Infrastruktur: KI-Systeme, die als Sicherheitsbauteile in der Verwaltung und im Betrieb kritischer digitaler Infrastruktur, des Strassenverkehrs oder der Wasser-, Gas-, Wärme- oder Stromversorgung eingesetzt werden.

Der dritte Bereich (Anhang III Nr. 3) erfasst Bildung und Berufsausbildung: KI-gestützte Prüfungsbewertung, Zulassungsentscheidungen oder adaptive Lernsysteme, die den Bildungsweg einer Person wesentlich beeinflussen.

Der vierte Bereich (Anhang III Nr. 4) umfasst Beschäftigung, Personalmanagement und Zugang zur Selbstständigkeit: automatisierte Bewerbervorauswahl, KI-gestützte Kündigungsentscheidungen, Leistungsüberwachung und Aufgabenzuweisung.

Der fünfte Bereich (Anhang III Nr. 5) betrifft den Zugang zu wesentlichen privaten und öffentlichen Dienstleistungen: Kreditscoring, Risikobewertung und Preisbildung bei Lebens- und Krankenversicherungen, Triage in Notaufnahmen sowie Priorisierung von Rettungsdiensten.

Der sechste Bereich (Anhang III Nr. 6) erfasst Strafverfolgung: Risikoeinschätzung für potenzielle Straftäter, Polygraphen, Beweismittelbewertung, Kriminalitätsvorhersage.

Der siebte Bereich (Anhang III Nr. 7) betrifft Migration, Asyl und Grenzkontrolle: automatisierte Visumprüfung, Risikoeinschätzung irregulärer Migration, Identitätserkennung an Grenzen.

Der achte Bereich (Anhang III Nr. 8) umfasst Rechtspflege und demokratische Prozesse: KI-Systeme, die Gerichte bei der Sachverhaltsermittlung oder Rechtsanwendung unterstützen, oder KI-Systeme, die Wahlprozesse beeinflussen.

Viele KI-Produkte, die intuitiv als „wichtig“ oder „sensibel“ erscheinen, fallen weder unter Anhang III noch sind sie Sicherheitsbauteile drittzertifizierungspflichtiger Produkte nach Art. 6 Abs. 1 i. V. m. Anhang I KI-VO. KI-gestützte Textverarbeitung, ein Chatbot im Kundenservice, Übersetzungssoftware oder ein Coding-Assistent sind in der Regel keine Hochrisiko-KI-Systeme. Eine Konformitätsfiktion nach Art. 12 CRA gibt es dann nicht. CRA-Compliance und AI-Act-Compliance — soweit der AI Act überhaupt Pflichten auslöst — laufen für diese Produkte parallel und unabhängig.

In Anhang III genannt — und trotzdem nicht hochriskant: Art. 6 Abs. 3 KI-VO

Die Zuordnung zu einem der acht Bereiche des Anhangs III beendet die Prüfung noch nicht. Art. 6 Abs. 3 KI-VO enthält eine Ausnahme, die in der Praxis erhebliche Bedeutung hat: Abweichend von Art. 6 Abs. 2 gilt ein in Anhang III genanntes KI-System nicht als hochriskant, „wenn es kein erhebliches Risiko der Beeinträchtigung in Bezug auf die Gesundheit, Sicherheit oder Grundrechte natürlicher Personen birgt, indem es unter anderem nicht das Ergebnis der Entscheidungsfindung wesentlich beeinflusst“[2].

Diese Ausnahme greift, wenn eine der folgenden vier Bedingungen erfüllt ist (Art. 6 Abs. 3 UAbs. 2 KI-VO)[2]:

  • lit. a: Das KI-System ist dazu bestimmt, eine eng gefasste Verfahrensaufgabe durchzuführen.
  • lit. b: Das KI-System ist dazu bestimmt, das Ergebnis einer zuvor abgeschlossenen menschlichen Tätigkeit zu verbessern.
  • lit. c: Das KI-System ist dazu bestimmt, Entscheidungsmuster oder Abweichungen von früheren Entscheidungsmustern zu erkennen, und ist nicht dazu gedacht, die zuvor abgeschlossene menschliche Bewertung ohne eine angemessene menschliche Überprüfung zu ersetzen oder zu beeinflussen.
  • lit. d: Das KI-System ist dazu bestimmt, eine vorbereitende Aufgabe für eine Bewertung durchzuführen, die für die Zwecke der in Anhang III aufgeführten Anwendungsfälle relevant ist.

Erwägungsgrund 53 KI-VO illustriert diese Bedingungen mit Beispielen: die Umwandlung unstrukturierter in strukturierte Daten, die Einordnung eingehender Dokumente in Kategorien, die Erkennung von Duplikaten, die sprachliche Verbesserung zuvor verfasster Dokumente, die Übersetzung von Erstdokumenten oder intelligente Lösungen für die Bearbeitung von Dossiers (Indexierung, Suche, Text- und Sprachverarbeitung)[2].

Die Rückausnahme ist die eigentliche Pointe. Art. 6 Abs. 3 UAbs. 3 KI-VO stellt klar: „Ungeachtet des Unterabsatzes 1 gilt ein in Anhang III aufgeführtes KI-System immer dann als hochriskant, wenn es ein Profiling natürlicher Personen vornimmt“[2]. Sobald also Profile natürlicher Personen erstellt werden, ist die Ausnahme des Art. 6 Abs. 3 versperrt — unabhängig davon, wie eng gefasst oder vorbereitend die Aufgabe erscheint. Für Produkte, die Verhaltens-, Leistungs- oder Präferenzprofile bilden, ist damit der Ausweg über Art. 6 Abs. 3 in der Regel verschlossen.

Und die Ausnahme ist nicht kostenlos. Wer sich auf Art. 6 Abs. 3 KI-VO stützt, übernimmt nach Art. 6 Abs. 4 KI-VO zwei Pflichten[2]: Der Anbieter, der zu dem Schluss kommt, dass ein in Anhang III aufgeführtes System nicht hochriskant ist, dokumentiert seine Bewertung, bevor das System in Verkehr gebracht oder in Betrieb genommen wird, und legt sie den zuständigen nationalen Behörden auf Verlangen vor. Zusätzlich unterliegt er der Registrierungspflicht nach Art. 49 Abs. 2 KI-VO — die Registrierung in der EU-Datenbank erfolgt also gerade auch dann, wenn der Anbieter die Hochrisiko-Einstufung verneint. Die Ausnahme ist damit kein stilles Opt-out, sondern ein dokumentierter und registrierter Vorgang. Art. 6 Abs. 5 KI-VO sieht Leitlinien der Kommission zur praktischen Umsetzung samt einer Liste praktischer Beispiele vor. Die dort bis zum 2. Februar 2026 vorgesehenen Leitlinien lagen bis zum 11. Oktober 2026 nicht in endgültiger Fassung vor; ein Entwurf wurde am 19. Mai 2026 veröffentlicht, die Konsultation bis zum 23. Juli 2026 verlängert[12].

Anwendungsjahre mitdenken. Die Pflichten aus Kapitel III Abschnitte 1 bis 3 KI-VO, darunter die Dokumentation nach Art. 6 Abs. 4, gelten nach dem durch den KI-Omnibus geänderten Art. 113 erst ab dem 2. Dezember 2027 (Anhang III) bzw. ab dem 2. August 2028 (Anhang I)[10]. Vorher in Verkehr gebrachte Systeme erfasst Art. 111 Abs. 2 erst, wenn ihre Konzeption danach erheblich verändert wird; für Hochrisiko-KI-Systeme, die von Behörden verwendet werden sollen, gilt der 2. August 2030. Art. 14 CRA gilt seit dem 11. September 2026 (Teil 5 dieser Serie).

Warum das für den CRA zählt: Die Einstufung als Hochrisiko-KI-System entscheidet mittelbar darüber, ob die Bündelungswirkung des Art. 12 CRA überhaupt greift. Fällt ein System über Art. 6 Abs. 3 KI-VO aus der Hochrisiko-Kategorie heraus, entfällt zugleich die Konformitätsfiktion des Art. 12 Abs. 1 CRA und der Verfahrenswechsel nach Art. 12 Abs. 2 und 3 CRA. Das ist keine reine Entlastung: Die CRA-Pflichten bleiben unverändert bestehen und müssen dann eigenständig — ohne den Rückgriff auf das KI-VO-Verfahren — erfüllt werden. Wer Art. 6 Abs. 3 KI-VO nutzt, sollte deshalb wissen, dass er damit auch die Brücke zwischen den beiden Verordnungen abbaut.

Wer ist Anbieter? Der Rollenwechsel nach Art. 25 KI-VO

Für Softwarehersteller, die KI-Assistenzfunktionen in ihre Produkte einbauen und an Unternehmenskunden ausliefern, ist eine Norm besonders wichtig, die in der CRA-Diskussion selten auftaucht: Art. 25 KI-VO („Verantwortlichkeiten entlang der KI-Wertschöpfungskette“).

Der Ausgangspunkt ist der Begriff der Zweckbestimmung. Nach Art. 3 Nr. 12 KI-VO ist das „die Verwendung, für die ein KI-System laut Anbieter bestimmt ist, einschliesslich der besonderen Umstände und Bedingungen für die Verwendung, entsprechend den vom Anbieter bereitgestellten Informationen in den Betriebsanleitungen, im Werbe- oder Verkaufsmaterial und in diesbezüglichen Erklärungen sowie in der technischen Dokumentation“[2]. Die Zweckbestimmung ist damit nichts, was ein Hersteller im Stillen festlegt: Sie ergibt sich aus dem, was er dokumentiert und bewirbt.

Nach Art. 25 Abs. 1 KI-VO gelten Händler, Einführer, Betreiber oder sonstige Dritte als Anbieter eines Hochrisiko-KI-Systems und unterliegen den Anbieterpflichten gemäss Art. 16 KI-VO in drei Fällen[2]:

  • lit. a: wenn sie ein bereits in Verkehr gebrachtes oder in Betrieb genommenes Hochrisiko-KI-System mit ihrem Namen oder ihrer Handelsmarke versehen — „unbeschadet vertraglicher Vereinbarungen, die eine andere Aufteilung der Pflichten vorsehen“;
  • lit. b: wenn sie eine wesentliche Veränderung eines bereits in Verkehr gebrachten oder in Betrieb genommenen Hochrisiko-KI-Systems so vornehmen, dass es weiterhin ein Hochrisiko-KI-System nach Art. 6 KI-VO bleibt;
  • lit. c: wenn sie die Zweckbestimmung eines KI-Systems — einschliesslich eines KI-Systems mit allgemeinem Verwendungszweck —, das nicht als hochriskant eingestuft wurde und bereits in Verkehr gebracht oder in Betrieb genommen wurde, so verändern, dass es zu einem Hochrisiko-KI-System im Sinne von Art. 6 KI-VO wird.

Art. 25 Abs. 2 KI-VO zieht daraus die Konsequenz: Unter diesen Umständen gilt der Anbieter, der das System ursprünglich in Verkehr gebracht oder in Betrieb genommen hatte, nicht mehr als Anbieter dieses spezifischen KI-Systems. Er ist damit aber nicht aus dem Spiel: Der Erstanbieter „arbeitet eng mit neuen Anbietern zusammen, stellt die erforderlichen Informationen zur Verfügung und sorgt für den nach vernünftigem Ermessen zu erwartenden technischen Zugang und sonstige Unterstützung“, die zur Erfüllung der Pflichten aus der Verordnung erforderlich sind — insbesondere für die Konformitätsbewertung des Hochrisiko-KI-Systems[2][10]. Der KI-Omnibus konkretisiert dies durch technische Unterlagen, Angaben zu bekannten Einschränkungen und Fehlerarten sowie gezielten technischen Zugang. Diese Mitwirkungspflicht entfällt nach dem letzten Unterabsatz des Art. 25 Abs. 2 KI-VO nur, wenn der Erstanbieter eindeutig festgelegt hat, dass sein KI-System nicht in ein Hochrisiko-KI-System umgewandelt werden darf. Verstösse gegen Art. 25 Abs. 2 und 4 sind nach Art. 99 Abs. 4 lit. da KI-VO bussgeldbewehrt[10].

Für einen Softwarehersteller, der KI-Assistenzfunktionen ausliefert, ist der Rollenwechsel damit der zentrale Steuerungshebel — aber er wirkt in beide Richtungen.

Entlastend: Liefern Sie eine KI-Funktion mit einer klar dokumentierten, nicht hochriskanten Zweckbestimmung aus, und setzt ein Kunde sie eigenmächtig für einen Anhang-III-Anwendungsfall ein — etwa einen Textassistenten für die Vorauswahl von Bewerbungen —, so ist es nach Art. 25 Abs. 1 lit. c KI-VO der Kunde, der zum Anbieter mit den Pflichten aus Art. 16 KI-VO wird. Die Zweckbestimmung, die Betriebsanleitung und das Verkaufsmaterial sind dabei die Belege dafür, was Sie tatsächlich bestimmt haben.

Belastend: Genau derselbe Mechanismus trifft Ihre Kunden — und damit Ihre Kundenbeziehung. Ein Unternehmenskunde, der eine harmlos wirkende Assistenzfunktion in einen Hochrisiko-Kontext hebt, übernimmt damit ein vollständiges Anbieter-Pflichtenprogramm: Risikomanagementsystem, Daten-Governance, technische Dokumentation, Konformitätsbewertung, CE-Kennzeichnung, Registrierung. Wer das nicht weiss, erfährt es im ungünstigsten Fall von der Marktüberwachung. Eine verständliche Beschreibung der Zweckbestimmung und der ausgeschlossenen Verwendungen ist deshalb nicht nur Eigenschutz, sondern gehört zur Produktinformation.

Haftungshygiene — und die Grenze der Vertragsgestaltung. Vertragliche Regelungen, Nutzungsbedingungen und Disclaimer verteilen das wirtschaftliche Risiko zwischen den Parteien im Innenverhältnis. An der objektiven Einstufung gegenüber Behörden ändern sie nichts: Ob ein System hochriskant ist und wer als Anbieter gilt, beurteilt sich nach Art. 6 und Art. 25 KI-VO anhand der tatsächlichen Zweckbestimmung und der tatsächlichen Verwendung — nicht nach der Überschrift einer AGB-Klausel. Das zeigt schon der Wortlaut der Verordnung selbst: Der Vorbehalt zugunsten vertraglicher Vereinbarungen steht nur in Art. 25 Abs. 1 lit. a KI-VO (Anbringen von Name oder Handelsmarke), nicht in lit. b und nicht in lit. c. Und die Möglichkeit des Art. 25 Abs. 2 letzter Unterabsatz KI-VO, die Umwandlung in ein Hochrisiko-KI-System auszuschliessen, befreit den Erstanbieter von der Mitwirkungs- und Dokumentationsübergabepflicht — sie verhindert nicht, dass ein Betreiber, der die Zweckbestimmung dennoch ändert, nach Art. 25 Abs. 1 lit. c KI-VO zum Anbieter wird.

Wer also die Zweckbestimmung als Steuerungsinstrument nutzt, muss sie technisch und dokumentarisch tragen: Sie muss zum tatsächlichen Funktionsumfang, zur Betriebsanleitung, zum Marketing und zur technischen Dokumentation passen. Eine Klausel ersetzt die Prüfung nicht — sie kann sie nur abbilden. Welche Formulierungen im Einzelfall tragen, ist eine Frage der individuellen rechtlichen Beratung und nicht Gegenstand dieses Artikels.

Hürde 2: KI-spezifische Risiken und — soweit einschlägig — Grundrechte-Risiken in der CRA-Bewertung

Auch wenn ein KI-System als Hochrisiko eingestuft ist, tragen die Bedingungen des Art. 12 Abs. 1 CRA in der Praxis nur, wenn die Risikobewertung nach Art. 13 Abs. 2 und 3 CRA die KI-spezifischen Cybersicherheitsrisiken ausdrücklich abdeckt; so legt es Erwägungsgrund (51) CRA nahe. Eine rein klassische Sicherheitsbewertung, die Buffer Overflows, SQL Injection und Netzwerkpenetration prüft, reicht nicht.

Erwägungsgrund (51) CRA[1] formuliert den Grund dafür: Bei der Bewertung der Cybersicherheitsrisiken eines Hochrisiko-KI-Produkts sollen die Risiken für die Cyberresilienz des KI-Systems gegenüber Versuchen unbefugter Dritter berücksichtigt werden, Nutzung, Verhalten oder Leistung des Systems zu verändern — einschliesslich KI-spezifischer Schwachstellen wie „Data Poisoning oder adversarial attack“. Diese beiden Angriffsvektoren sind im Erwägungsgrund explizit benannt.

Grundrechte-Risiken — soweit einschlägig. Erwägungsgrund (51) CRA nennt neben den Cyber-Risiken „gegebenenfalls Risiken für die Grundrechte, gemäss der Verordnung (EU) 2024/1689“[1]. Für Hochrisiko-KI-Kombinationsprodukte heisst das (ebenso Sörup, § 4 Rn. 59[7]): Die CRA-Risikobewertung sollte lebenszyklusübergreifend prüfen, ob Angriffe auf Nutzung, Verhalten oder Leistung des Systems Grundrechte beeinträchtigen können, etwa durch manipulierte, diskriminierende Ergebnisse. Risiken aus dem bestimmungsgemässen Verhalten selbst behandelt dagegen das Risikomanagementsystem nach Art. 9 AI Act. Art. 13 Abs. 4 Satz 2 CRA erlaubt, die CRA-Risikobewertung in eine nach anderem Unionsrecht vorgeschriebene Risikobewertung einzubeziehen.

Vier Angriffsvektoren sollte eine CRA-Risikobewertung für KI-Produkte mindestens adressieren — die ersten beiden nennt Erwägungsgrund (51) ausdrücklich, die beiden weiteren dokumentiert die praktische KI-Sicherheitsliteratur:

Data Poisoning (Erwägungsgrund (51) CRA) — die gezielte Manipulation von Trainingsdaten, um das Verhalten eines KI-Modells zu verändern. Anders als bei einem klassischen Datenbank-Angriff geht es nicht um Datendiebstahl, sondern um die subtile Verzerrung der Entscheidungslogik. Ein vergiftetes Modell kann über Monate hinweg falsche Ergebnisse produzieren, ohne dass herkömmliche Monitoring-Systeme dies erkennen. Die CRA-Risikobewertung sollte deshalb die Integrität der Trainings-Pipeline adressieren: Woher kommen die Daten? Wie werden sie validiert? Welche Mechanismen verhindern nachträgliche Manipulation?

Adversarial Attacks (Erwägungsgrund (51) CRA) — gezielte Eingaben, die ein KI-Modell zu Fehlklassifikationen verleiten — etwa ein Bild, das für das menschliche Auge wie ein Stoppschild aussieht, vom KI-System aber als Vorfahrtsschild erkannt wird. Für die CRA-Risikobewertung bedeutet das: Die Robustheit des Modells gegen manipulierte Eingaben muss getestet und dokumentiert werden. MITRE ATLAS[3] — das Adversarial Threat Landscape for AI Systems — bietet hier einen strukturierten Angriffskatalog, der als Grundlage dienen kann.

Model Inversion (MITRE ATLAS[3], OWASP ML Top 10[4]) — Angriffe, bei denen aus den Ausgaben eines KI-Modells auf die Trainingsdaten rückgeschlossen wird. Das ist besonders dann problematisch, wenn die Trainingsdaten personenbezogene Informationen enthalten — etwa Gesundheitsdaten, Finanzdaten oder biometrische Merkmale. Für die CRA-Risikobewertung sollte dokumentiert werden, welche Massnahmen gegen Model Inversion und verwandte Angriffe auf die Vertraulichkeit von Trainingsdaten und Modell — etwa Membership Inference oder Modelldiebstahl durch Extraktion — umgesetzt sind.

Prompt Injection (MITRE ATLAS[3]; OWASP Top 10 for LLM Applications, LLM01[11]) — ein für LLM-basierte Produkte zentraler Angriffsvektor. Dabei werden in die Eingabe eines KI-Systems Anweisungen eingeschleust, die das Systemverhalten manipulieren — etwa um Sicherheitsschranken zu umgehen oder vertrauliche Systemprompts offenzulegen. Wer Large Language Models einsetzt, sollte Prompt Injection deshalb ausdrücklich in der CRA-Risikobewertung behandeln.

All diese Angriffsvektoren müssen nicht nur identifiziert, sondern auch mit konkreten Gegenmassnahmen adressiert werden. Die OWASP Machine Learning Security Top 10[4], die OWASP Top 10 for LLM Applications[11] und MITRE ATLAS[3] bieten strukturierte Kataloge, die als Ausgangspunkt für die KI-spezifische CRA-Risikobewertung dienen können.

Hürde 3: Harmonisierte Normen als Konformitätsmittel

Die dritte praktische Hürde ist die, auf die Unternehmen den geringsten Einfluss haben: Harmonisierte Normen oder gemeinsame Spezifikationen helfen bei der Konformitätsbewertung, sind aber nicht explizit in Art. 12 Abs. 1 CRA als Bedingung genannt[1].

Wichtig ist die Unterscheidung: Art. 27 Abs. 1 CRA begründet eine widerlegbare Vermutung, dass Produkte, die harmonisierte Normen erfüllen, die Anforderungen der Verordnung einhalten. Aber Art. 12 selbst nennt harmonisierte Normen nicht als Bedingung. Fehlt ihre Amtsblattfundstelle oder wendet der Hersteller sie nicht an, muss er die Erfüllung der Anforderungen im anwendbaren Konformitätsbewertungsverfahren anderweitig nachweisen; die gesetzliche Konformitätsvermutung des Art. 27 entsteht dadurch nicht.

Bis zum 11. Oktober 2026 ist keine Fundstelle einer CRA-harmonisierten Norm im Amtsblatt der Europäischen Union veröffentlicht worden. Die Europäische Kommission hat CEN, CENELEC und ETSI mit dem Standardisierungsauftrag M/606 (Durchführungsbeschluss C(2025) 618 final vom 3. Februar 2025)[5] beauftragt, harmonisierte Normen zur Konkretisierung der CRA-Anforderungen zu entwickeln. Nach der FAQ der Kommissionsdienststellen, Version 1.4, Abschnitt 6.10[9], waren die horizontalen Normen zu Design, Entwicklung, Herstellung und Schwachstellenbehandlung bis zum 30.08.2026 und die vertikalen Normen bis zum 30.10.2026 vorgesehen. Ein Entwurf zur Änderung des Normungsauftrags M/606 sieht eine Verschiebung auf den 31.10.2026 beziehungsweise 31.12.2026 vor, ist bis zum 11. Oktober 2026 aber nicht angenommen worden. Die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I ist weiterhin erst bis zum 30.10.2027 vorgesehen.

Leicht übersehen wird der Zeitpunkt, ab dem die Konformitätsvermutung nach Art. 27 CRA[1] tatsächlich greift. Sie entsteht erst mit der Veröffentlichung der Fundstelle im Amtsblatt der Europäischen Union, nicht schon mit der Verabschiedung oder Ratifizierung durch die Normungsorganisationen (Art. 27 Abs. 1 CRA). Zwischen beiden Daten liegt regelmässig ein weiterer Schritt. Bis dahin können Unternehmen die normgestützte Konformitätsvermutung formal nicht in Anspruch nehmen. Vorbereiten können sie sich dennoch, indem sie ihre Risikobewertung an den absehbaren Norminhalten ausrichten und alternative Konformitätsmittel dokumentieren.

Die zweite Compliance-Klammer: Art. 12 Abs. 2 und 3 CRA — das Konformitätsbewertungsverfahren

Während Art. 12 Abs. 1 CRA die Konformitätsfiktion regelt, setzen Art. 12 Abs. 2 und 3 CRA die zweite — in der Praxis mindestens ebenso wichtige — Klammer zur KI-VO: das Konformitätsbewertungsverfahren bei Hochrisiko-KI-Kombinationsprodukten[1][7][8]. Die Module selbst stellt Teil 9 dieser Serie vor.

Grundsatz (Art. 12 Abs. 2 CRA): Ist ein Produkt mit digitalen Elementen zugleich ein Hochrisiko-KI-System nach der KI-VO, verschiebt sich das Konformitätsbewertungsverfahren auf das Verfahren nach Art. 43 KI-VO. Es greift in diesem Fall nicht ein eigenständiges CRA-Modul (Modul A, B+C, H etc.), sondern das KI-VO-Verfahren wird das massgebliche Verfahren auch für die CRA-Cybersicherheitskonformität; in diesem Verfahren ist auch die Einhaltung der grundlegenden Cybersicherheitsanforderungen nach Anhang I CRA zu bewerten. Für die meisten Anhang-III-Systeme (Nr. 2 bis 8) ist das nach Art. 43 Abs. 2 KI-VO die interne Kontrolle nach Anhang VI — ohne notifizierte Stelle. Eine notifizierte Stelle wird vor allem bei biometrischen Systemen (Anhang III Nr. 1) relevant, bei Produkten nach Anhang I Abschnitt A je nach Sektorrecht.

Der Zuständigkeitsübergang ist bedingt. Eine nach der KI-VO notifizierte Stelle darf die CRA-Anforderungen nur prüfen, wenn in ihrem Notifizierungsverfahren nach der KI-VO auch bewertet wurde, ob sie die Anforderungen des Art. 39 CRA erfüllt (Art. 12 Abs. 2 Satz 2 CRA; ebenso NK-CRA/Hofmann Art. 12 Rn. 15[8]). Fehlt diese Prüfung, ist eine entsprechend qualifizierte Stelle zu wählen; ein eigenständiges CRA-Verfahren folgt nur in den Fällen des Art. 12 Abs. 3 CRA.

Ausnahme (Art. 12 Abs. 3 CRA): Abweichend von Abs. 2 gilt für die grundlegenden Cybersicherheitsanforderungen das CRA-Verfahren nach Art. 32, wenn das Produkt ein wichtiges Produkt ist, das Art. 32 Abs. 2 lit. a oder b oder Abs. 3 unterliegt, oder ein kritisches Produkt ist. Zusätzliche Voraussetzung für beide Produktgruppen ist, dass für das KI-System nach der KI-VO das Verfahren der internen Kontrolle nach Anhang VI KI-VO gilt. Für diese Cybersicherheitsanforderungen tritt das CRA-Verfahren an die Stelle des Verfahrens nach Art. 43 KI-VO; im Übrigen bleibt es beim Verfahren nach Art. 43 KI-VO. 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)[7]. Dieselben Cybersicherheitsanforderungen werden dabei nicht doppelt bewertet.

Die KI-VO kann ein Produkt nur in bestimmten Fällen „hochziehen“. Bei biometrischen Systemen nach Anhang III Nr. 1 KI-VO kann für ein Produkt, für das nach Art. 32 Abs. 1 CRA die interne Kontrolle zulässig wäre, über die KI-VO eine unabhängige Bewertung durch eine notifizierte Stelle erforderlich werden. Die Kommentierung von Hofmann im NK-CRA hält diesen Effekt für biometrische Systeme für plausibel[8, Art. 12 Rn. 16]. Wer den Verfahrensaufwand allein aus der CRA-Klassifizierung ableitet, kalkuliert deshalb unter Umständen zu knapp. Für Sicherheitsbauteile nach Anhang I Abschnitt A stellt Art. 43 Abs. 3 KI-VO seit dem KI-Omnibus dagegen klar, dass die Hochrisiko-Einstufung allein keine Drittprüfung erzwingt; massgeblich bleibt das Verfahren des jeweiligen Sektorrechts[10].

Die Frage „Welches Konformitätsverfahren gilt für mich?“ lässt sich bei einem Hochrisiko-KI-Kombinationsprodukt folglich nicht allein anhand des CRA beantworten. Zuerst sind die Klassifizierung nach Anhang III/IV CRA und parallel die Hochrisiko-Einstufung nach KI-VO vorzunehmen. Der massgebliche Verfahrenspfad ergibt sich erst aus ihrem Zusammenspiel.

Die praktische Konsequenz: Drei Compliance-Szenarien

Aus der kritischen Einschränkung, den drei Hürden und dem Verfahrensregime der Art. 12 Abs. 2 und 3 CRA ergeben sich in der Praxis drei Szenarien, die KI-Unternehmen kennen sollten.

Szenario 1: Hochrisiko-KI mit CRA-Produkt. Ihr KI-System ist nach Art. 6 KI-VO als hochriskant eingestuft[2][10] — über Anhang III oder über den Anhang-I-Weg des Art. 6 Abs. 1 KI-VO — und ist gleichzeitig ein CRA-pflichtiges Produkt mit digitalen Elementen. In diesem Fall sollten Sie Ihre CRA-Compliance von Anfang an auf die Konformitätsfiktion ausrichten: KI-spezifische Cyberrisiken und gegebenenfalls damit verbundene Grundrechtsrisiken in die Bewertung nach Art. 13 Abs. 2 und 3 CRA integrieren, prüfen, welche KI-bezogenen Softwareelemente — etwa Frameworks und Laufzeitbibliotheken — als Komponenten in die CRA-SBOM gehören, und Modelle, Trainingspipelines sowie Datenquellen ergänzend in der KI-VO-Dokumentation beziehungsweise einer ML-BOM erfassen. Ergänzen Sie ausserdem das Schwachstellenmanagement um KI-Angriffsvektoren (MITRE ATLAS[3], OWASP ML Top 10[4], OWASP Top 10 for LLM Applications[11]). Verfahrensseitig läuft die Konformitätsbewertung grundsätzlich über Art. 43 KI-VO. Unter den engen Voraussetzungen des Art. 12 Abs. 3 CRA gilt stattdessen für die grundlegenden Cybersicherheitsanforderungen das CRA-Verfahren nach Art. 32; dieselben Anforderungen werden dabei nicht doppelt bewertet. Prüfen Sie früh, ob bei der Notifizierung der vorgesehenen Stelle nach der KI-VO auch die Anforderungen des Art. 39 CRA bewertet wurden[8, Art. 12 Rn. 15]. Gleichzeitig müssen Sie ein separates Risikomanagementsystem für Genauigkeit und Robustheit unter dem AI Act aufbauen — diese Anforderungen sind von der Unbeschadet-Klausel ausgenommen. Harmonisierte Normen sind keine Voraussetzung der Konformitätsfiktion nach Art. 12 CRA; die normgestützte Konformitätsvermutung läuft separat über Art. 27 CRA.

Szenario 2: Nicht-Hochrisiko-KI mit CRA-Produkt. Ihr KI-Produkt ist nicht nach Art. 6 KI-VO als hochriskant eingestuft[2] — weder über Anhang III noch über den Anhang-I-Weg, oder weil die Ausnahme des Art. 6 Abs. 3 KI-VO greift —, fällt aber unter den CRA[1]. Hier gibt es keine Konformitätsfiktion — CRA und KI-VO laufen parallel. Allerdings sind die KI-VO-Pflichten für Nicht-Hochrisiko-KI deutlich geringer: möglicherweise nur Art. 50 KI-VO oder gar keine spezifischen Pflichten. Stützen Sie sich auf Art. 6 Abs. 3 KI-VO, denken Sie an die Dokumentations- und Registrierungspflicht des Art. 6 Abs. 4 i. V. m. Art. 49 Abs. 2 KI-VO[2]. Die CRA-Risikobewertung muss unabhängig davon nach Art. 13 Abs. 2 und 3 CRA alle für das Produkt relevanten Cyberrisiken erfassen.

Szenario 3: KI-System ohne CRA-Pflicht. Ihr KI-System ist eine reine SaaS-Lösung ohne lokale Komponente und fällt nicht unter den CRA[1]. In diesem Fall gelten nur die KI-VO-Pflichten — je nach Risikokategorie Art. 50 KI-VO (Transparenz), die Pflichten für Hochrisiko-KI aus Kapitel III KI-VO (Art. 8 ff., insbesondere Art. 15)[2] oder gar keine spezifischen Verpflichtungen. Die CRA-Meldepflichten für Schwachstellen gelten nicht; für den Anbieter kann aber NIS-2[6] einschlägig sein, wenn Dienst, Einrichtung und Grössen- oder Sonderkriterien der Richtlinie beziehungsweise des nationalen Umsetzungsrechts erfüllt sind.

Die SBOM als Klammer

Ein Element verbindet CRA und KI-VO auf der operativen Ebene: die Software-Stückliste. Der CRA[1] verlangt für jedes Produkt mit digitalen Elementen eine SBOM, aus der zumindest die obersten Softwareabhängigkeiten hervorgehen. Bei KI-Produkten gehören KI-bezogene Softwarekomponenten wie Frameworks und Laufzeitbibliotheken in die CRA-SBOM, soweit sie Bestandteile des Produkts sind. Modelle, Trainingspipelines und Datenquellen sind demgegenüber nicht allein wegen ihres KI-Bezugs automatisch Bestandteile der CRA-SBOM; sie sind je nach Fall in der technischen Dokumentation nach der KI-VO oder ergänzend in einer ML-BOM zu erfassen[2]. Pflichtinhalt und Formate der SBOM erläutert Teil 7 dieser Serie.

Eine abgestimmte CRA-SBOM und ergänzende KI-/ML-Dokumentation können gemeinsam die Datenbasis für die technische Dokumentation bilden, die die KI-VO für Hochrisiko-KI-Systeme verlangt[2]. Entscheidend ist, die unterschiedlichen Rechtsgrundlagen und Dokumentationszwecke kenntlich zu machen.

Der Blick nach vorn

Die duale Regulierung von KI-Produkten durch CRA und KI-VO ist komplex, aber nicht unbeherrschbar. Der Schlüssel liegt in der frühzeitigen Integration: aufeinander abgestimmte Risikomanagementsysteme nach beiden Verordnungen; eine CRA-SBOM für die erfassten Softwarekomponenten, ergänzt um gesonderte KI-/ML-Dokumentation; ein Schwachstellenmanagement, das neben CVEs auch KI-spezifische Schwachstellen erfasst; und eine klare Verfahrensplanung, die den Grundsatz des Art. 12 Abs. 2 CRA und den Verfahrenswechsel für Cybersicherheitsanforderungen nach Art. 12 Abs. 3 CRA frühzeitig berücksichtigt — einschliesslich der Prüfung, ob im KI-VO-Notifizierungsverfahren der vorgesehenen Stelle auch die Anforderungen des Art. 39 CRA bewertet wurden.

Dabei darf die Konformitätsfiktion nicht mit einer vollständigen Pflichtenübernahme verwechselt werden. Art. 12 CRA erfasst nur den Cybersicherheits-Teil von Art. 15 KI-VO; Genauigkeit und Robustheit bleiben aufgrund der Unbeschadet-Klausel ausgenommen. Der CRA ersetzt das Risikomanagementsystem der KI-VO daher nicht. Er ergänzt es auf der Cybersicherheitsseite und verschränkt sich über Art. 12 Abs. 2 und 3 CRA mit dem Verfahren der KI-VO.

Und noch eine Erkenntnis gehört an den Anfang jeder Prüfung, nicht an ihr Ende: Ob die Brücke des Art. 12 CRA überhaupt trägt, entscheidet sich an der Einstufung nach der KI-VO — beim Begriff des Sicherheitsbauteils (Art. 3 Nr. 14, Erwägungsgrund 55 KI-VO), bei der Ausnahme des Art. 6 Abs. 3 KI-VO und bei der Frage, wer nach Art. 25 KI-VO Anbieter ist. Diese drei Weichen werden früher gestellt, als die meisten Compliance-Projekte annehmen.

Unternehmen, die diese Integration jetzt anstossen, sind vorbereitet, wenn die CRA-Produktanforderungen ab dem 11. Dezember 2027 gelten, und können die Konformitätsfiktion des Art. 12 CRA[1] nutzen.

Das Wichtigste für Hersteller

  • Die Konformitätsfiktion des Art. 12 Abs. 1 CRA greift nur für Hochrisiko-KI-Systeme nach Art. 6 KI-VO; ob sie trägt, entscheidet sich am Sicherheitsbauteil-Begriff, an der Ausnahme des Art. 6 Abs. 3 KI-VO und an der Anbieterrolle nach Art. 25 KI-VO.
  • Sie erfasst den Cybersicherheitsteil des Art. 15 KI-VO einschliesslich der Widerstandsfähigkeit gegen Data Poisoning und Adversarial Examples; Genauigkeit und Robustheit gegenüber Fehlern und Störungen sind separat nach dem AI Act nachzuweisen.
  • Die CRA-Risikobewertung nach Art. 13 Abs. 2 und 3 CRA sollte KI-spezifische Angriffe und, soweit einschlägig, damit verbundene Grundrechtsrisiken ausdrücklich abbilden.
  • Verfahrensseitig gilt grundsätzlich Art. 43 KI-VO; bei wichtigen Produkten, die Art. 32 Abs. 2 lit. a oder b oder Abs. 3 CRA unterliegen, und bei kritischen Produkten gilt für die grundlegenden Cybersicherheitsanforderungen das CRA-Verfahren, wenn KI-seitig die interne Kontrolle nach Anhang VI KI-VO gilt (Art. 12 Abs. 3 CRA). Eine nach der KI-VO notifizierte Stelle prüft die CRA-Anforderungen nur, wenn ihre Notifizierung Art. 39 CRA einbezog.
  • Harmonisierte Normen sind keine Voraussetzung der Fiktion; die Konformitätsvermutung nach Art. 27 CRA entsteht erst mit der Veröffentlichung der Fundstelle im Amtsblatt.

Bei KI-Produkten müssen CRA-Produktklasse und Hochrisiko-Einstufung getrennt geprüft werden. Der CRA-Quick-Check bietet eine kostenlose und unverbindliche Ersteinschätzung zu den CRA-Pflichten und zur CRA-Produktklasse. Ob zugleich ein Hochrisiko-KI-System vorliegt und die Konformitätsfiktion greift, ist individuell zu beurteilen.

Hinweis zur Methodik

Alle Aussagen in diesem Artikel wurden gegen die Primärquellen geprüft: die Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 12 Abs. 1 bis 3, Art. 13 Abs. 2 bis 4, Art. 27, Art. 28, Art. 32 Abs. 1, Art. 39, Anhang V und Erwägungsgrund (51), sowie die Verordnung (EU) 2024/1689 (KI-VO/AI Act) in der durch die Verordnung (EU) 2026/1744 geänderten Fassung[2][10], insbesondere Art. 3 Nr. 12 und 14, Art. 6 Abs. 1 bis 5, Art. 9, Art. 15, Art. 16, Art. 25 Abs. 1 und 2, Art. 42 Abs. 3, Art. 43, Art. 49 Abs. 2, Art. 99 Abs. 4 lit. da, Anhang I Abschnitt A und B, Anhang III und Anhang VI.

Zur Abgrenzung des Sicherheitsbauteils: Der Satz „Komponenten, die für die ausschliessliche Verwendung zu Zwecken der Cybersicherheit vorgesehen sind, sollten nicht als Sicherheitsbauteile gelten“ stammt aus Erwägungsgrund 55 KI-VO. Die dort ebenfalls genannten Beispiele — Systeme für die Überwachung des Wasserdrucks und Feuermelder-Kontrollsysteme in Cloud-Computing-Zentren — sind im Verordnungstext Beispiele für Sicherheitsbauteile kritischer Infrastruktur und nicht Beispiele für die Cybersicherheits-Ausnahme; sie werden in diesem Artikel entsprechend eingeordnet. Erwägungsgründe sind Auslegungshilfe, nicht Normtext.

Ergänzend wurden zwei juristische Kommentare zum CRA herangezogen: Wiebe (Hrsg.), Das neue Recht der Cyberresilienz — Kommentar zur CRA, Nomos 2025, insbesondere Sörup, § 4 Rn. 59, 64–65, sowie NK-CRA/Hofmann Art. 12 Rn. 15 f., in: Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026. Für den Normungszeitplan wurde die FAQ der Kommissionsdienststellen zum CRA, Version 1.4 vom 4. September 2026, Abschnitt 6.10, herangezogen[9]. Sie ist ein „Living Document“ der Kommissionsdienststellen und gibt nach eigenem Hinweis keine offizielle Position der Europäischen Kommission wieder.

Die Zuordnung KI-spezifischer Angriffsvektoren erfolgt wie folgt:

  • Data Poisoning und Adversarial Attacks: ausdrücklich in Erwägungsgrund (51) CRA genannt.
  • Model Inversion: praxisrelevante Ergänzung auf Basis von MITRE ATLAS und OWASP ML Top 10.
  • Prompt Injection: praxisrelevante Ergänzung auf Basis von MITRE ATLAS und OWASP Top 10 for LLM Applications, LLM01[11].

Die Auslegung der Unbeschadet-Klausel folgt Art. 12 Abs. 1 CRA: Art. 15 KI-VO regelt Genauigkeit, Robustheit und Cybersicherheit gemeinsam, die CRA-Fiktion erfasst aber nur den Cybersicherheits-Teil. Zu diesem gehört nach Art. 15 Abs. 5 KI-VO auch die Widerstandsfähigkeit gegen KI-spezifische Angriffe wie Data Poisoning und Adversarial Examples.

Quellen

[1] Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates, angenommen 23. Oktober 2024, in Kraft getreten 10. Dezember 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 – CRA), insbesondere Art. 12 Abs. 1 (Konformitätsfiktion), Art. 12 Abs. 2 und 3 (Konformitätsbewertungsverfahren bei Hochrisiko-KI-Kombinationsprodukten), Art. 14 (Meldepflichten; Geltung ab 11. September 2026 nach Art. 71 Abs. 2), Art. 27 (Konformitätsvermutung bei harmonisierten Normen), Art. 28 (EU-Konformitätserklärung), Art. 32 Abs. 1 (anwendbare Konformitätsbewertungsverfahren), Art. 39 (Anforderungen an notifizierte Stellen), Anhang I Teil I (Cybersicherheitsanforderungen), Anhang III (wichtige Produkte), Anhang IV (kritische Produkte), Anhang V (Inhalt der EU-Konformitätserklärung), Anhang VIII (CRA-Konformitätsbewertungsverfahren) und Erwägungsgrund (51) (Zusammenspiel CRA und KI-VO bei Hochrisiko-KI, einschliesslich KI-spezifischer Anfälligkeiten und Grundrechte-Risiken). 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 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz (KI-VO/AI Act), in der durch die Verordnung (EU) 2026/1744 geänderten Fassung, insbesondere Art. 3 Nr. 12 und 14, Art. 6, Art. 9, Art. 15, Art. 16, Art. 25 Abs. 1 und 2, Art. 42 Abs. 3, Art. 43, Art. 49 Abs. 2, Art. 50, Art. 99 Abs. 4 lit. da, Art. 111 Abs. 2, Art. 113, Anhang I Abschnitt A und B, Anhang III und Anhang VI. Konsolidierter Text: https://eur-lex.europa.eu/eli/reg/2024/1689

[3] MITRE ATLAS (Adversarial Threat Landscape for AI Systems), abrufbar unter https://atlas.mitre.org – Eine öffentlich zugängliche Wissensdatenbank, die Angriffstechniken gegen KI-Systeme strukturiert katalogisiert, darunter Data Poisoning, Adversarial Attacks, Model Inversion und verwandte Angriffsmuster. Das Framework orientiert sich am bekannten MITRE ATT&CK-Modell und dient als Grundlage für Threat Modelling im KI-Kontext.

[4] OWASP Machine Learning Security Top Ten (ML Top 10), abrufbar unter https://owasp.org/www-project-machine-learning-security-top-10/ – Projekt der OWASP Foundation (Open Worldwide Application Security Project) zur Identifikation und Minderung der zehn kritischsten Sicherheitsrisiken in Machine-Learning-Systemen. Stand: Version 0.3 (Incubator Project).

[5] Standardisierungsauftrag M/606 der EU-Kommission an CEN, CENELEC und ETSI zum CRA (Durchführungsbeschluss C(2025) 618 final vom 3. Februar 2025) – Auftrag der Europäischen Kommission zur Erarbeitung harmonisierter Normen zur Konkretisierung der CRA-Anforderungen für Produkte mit digitalen Elementen (15 horizontale, 26 vertikale Standards). Status: Normungsarbeiten laufen; zum Zeitplan siehe [9]. CEN-CENELEC.

[6] Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Massnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union (NIS-2-Richtlinie) – Richtlinie mit verbindlichen Cybersicherheits-Risikomanagementmassnahmen und Meldepflichten für wesentliche und wichtige Einrichtungen, einschliesslich koordinierter Schwachstellenoffenlegung. ABl. L 333, 27.12.2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[7] Wiebe, G. (Hrsg.) — Das neue Recht der Cyberresilienz: Kommentar zur CRA, Verlag Nomos, Stand Juni 2025 — Sörup, § 4 Rn. 59 (Grundrechte-Risiken in der CRA-Risikobewertung mit Bezug auf Erwägungsgrund (51) CRA und die KI-VO; lebenszyklusübergreifende Bewertung in Planung, Entwurf, Entwicklung, Produktion, Lieferung und Wartung) und Rn. 64–65 (Konformitätsbewertungsverfahren nach Art. 12 Abs. 2 und 3 CRA, Verhältnis zu Art. 43 KI-VO und Rolle notifizierter Stellen unter Berücksichtigung von Art. 39 CRA; Rn. 65: parallele Anwendbarkeit der CRA-Verfahren bei wichtigen und kritischen Produkten).

[8] Schröder/Hartl (Hrsg.), Cyberresilienz-Verordnung, Nomos Kommentar, 1. Aufl. 2026, Stand Dezember 2025 (zit.: NK-CRA/Bearbeiter) — Hofmann, Art. 12 Rn. 15 (Zuständigkeit der nach der KI-VO notifizierten Stelle nach Art. 12 Abs. 2 CRA nur, wenn in ihrem KI-VO-Notifizierungsverfahren auch die Anforderungen des Art. 39 CRA bewertet wurden; Herleitung aus dem Wort „sofern“) und Rn. 16 (Wahl des Bewertungsverfahrens nach Art. 43 KI-VO; Wirkung bei biometrischen Systemen nach Anhang III Nr. 1 KI-VO).

[9] Europäische Kommission (Kommissionsdienststellen), „FAQs on the Cyber Resilience Act“, Version 1.4 vom 04.09.2026, insbesondere Abschnitt 6.10 (harmonisierte Normen und Zeitplan der Normungsarbeiten). Living Document; nach eigenem Hinweis nicht als offizielle Position der Europäischen Kommission zu verstehen.

[10] 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 lit. a, 8, 12, 18, 19, 38, 39, 40 und 41 sowie Art. 3 Nr. 1. https://eur-lex.europa.eu/eli/reg/2026/1744/oj

[11] OWASP, Top 10 for Large Language Model Applications, LLM01: Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[12] Europäische Kommission, „Targeted consultation on the draft guidelines for the classification of high-risk artificial intelligence systems“, veröffentlicht am 19.05.2026; Konsultation ursprünglich bis 23.06.2026, verlängert bis 23.07.2026 (Leitlinien nach Art. 6 Abs. 5 KI-VO). https://digital-strategy.ec.europa.eu/en/consultations/targeted-consultation-draft-guidelines-classification-high-risk-artificial-intelligence-systems

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. Herausgeberin: codAIx GmbH, Thayngen (Schweiz). Veröffentlicht am 27.04.2026, zuletzt geändert am 18.10.2026.

Im nächsten Artikel dieser Serie: SBOM nach dem CRA: Pflichten, BSI TR-03183 und Umsetzung — Pflichtbestandteile, Formatfragen (CycloneDX, SPDX) und die Abgrenzung zur ergänzenden KI-/ML-Dokumentation.