Von Redaktion codAIx | 27. April 2026

Art. 12 des Cyber Resilience Act verspricht eine elegante Lösung: Wer die CRA-Cybersicherheitsanforderungen erfüllt, darf vermuten, dass auch die Cybersicherheitsanforderungen des AI Act erfüllt sind [1][2]. Klingt nach einem Freifahrtschein. Ist es aber nicht. Die rechtlichen Bedingungen und praktischen Hürden zur Nutzung dieser Vermutungswirkung sind anspruchsvoller, als sie auf den ersten Blick wirken — und ihre praktische Umsetzung verlangt ein Umdenken in der Risikobewertung, das auch Grundrechte-Risiken und das kombinierte Konformitätsbewertungs­verfahren nach Art. 43 KI-VO einschliesst.

Die Vermutungswirkung: Theorie und Realität

Im vorherigen Artikel dieser Serie haben wir das Zusammenspiel von CRA und AI Act im Überblick dargestellt. Die zentrale Erkenntnis: Für Hochrisiko-KI-Systeme, die gleichzeitig Produkte mit digitalen Elementen sind, bietet Art. 12 CRA in Verbindung mit Erwägungsgrund 77 AI Act [1][2] eine einseitige Vermutungswirkung, die Doppelarbeit bei der Cybersicherheit vermeiden soll.

Auf dem Papier ist der Mechanismus einfach: CRA-Compliance deckt AI-Act-Cybersicherheit ab. In der Praxis stossen Unternehmen jedoch auf eine kritische Einschränkung, drei praktische Hürden und ein verschachteltes Konformitätsbewertungs­verfahren, die den vermeintlichen Automatismus relativieren.

Die kritische Einschränkung: „Without prejudice“

Art. 12 Abs. 1 CRA enthält eine Einschränkung mit erheblichen Compliance-Implikationen: Die Vermutungswirkung gilt ohne Beeinträchtigung 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 Vermutungswirkung des Art. 12 CRA deckt jedoch nur den Cybersicherheits-Teil ab. Die Anforderungen an Modellgenauigkeit und Robustheit (insbesondere Bias- und Adversarial-Robustheit) bleiben separat unter dem AI Act zu erfüllen.

Für Hochrisiko-KI-Systeme bleibt daher das Risikomanagement für Modellgenauigkeit, Bias-Robustheit und Adversarial-Robustheit eine separate Compliance-Pflicht unter dem AI Act — auch wenn die Cybersicherheit durch CRA abgedeckt ist. Diese „Without prejudice“-Klausel wird von vielen Unternehmen übersehen und führt zu unvollständiger Risikoabdeckung.

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

Art. 12 Abs. 1 CRA formuliert unter drei explizit genannten Bedingungen die Konformitätsvermutung. Die häufige Interpretation dieser Bedingungen als „Hochrisiko-Einstufung, KI-spezifische Risiken, harmonisierte Normen“ ist eine editoriale Auslegung. Die tatsächlichen rechtlichen Bedingungen lauten:

(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) Verfahrenskonformität nach Teil II des Anhangs I des CRA: Die vom Hersteller eingerichteten Verfahren (Design, Dokumentation, Risikobeurteilung, Vulnerability Management) müssen den Anforderungen von Teil II des Anhangs I entsprechen. Dies ist die Compliance-Management-Bedingung.

(c) Konformitätsnachweis in der EU-Konformitätserklärung: Das Erreichen der erforderlichen Schutzstufe nach Art. 15 KI-VO 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 Beweis, nicht ein technisches Requirement an sich.

Diese drei Bedingungen sind Voraussetzungen, nicht „Hürden“. Hinzu kommen aber praktische Implementierungs-Hürden, die Unternehmen bewältigen müssen.

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

Die Vermutungswirkung greift ausschliesslich für KI-Systeme, die nach Art. 6 KI-VO als hochriskant eingestuft sind [2] — entweder nach Art. 6 Abs. 1 i. V. m. Anhang I KI-VO (Sicherheitskomponenten drittzertifizierungspflichtiger Produkte, z. B. Maschinen oder Medizinprodukte) oder nach Art. 6 Abs. 2 i. V. m. Anhang III KI-VO. Für alle anderen KI-Systeme — und das ist die grosse Mehrheit — existiert 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“ [2]. 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 ist an dieser Stelle eine Aussage aus Erwägungsgrund 55 KI-VO relevant, die in der Diskussion häufig untergeht. Der Erwägungsgrund beschreibt zunächst, was Sicherheitsbauteile kritischer Infrastruktur sind: Systeme, die die physische Integrität kritischer Infrastruktur oder die Gesundheit und Sicherheit von Personen und Eigentum schützen sollen, „die aber nicht notwendig sind, damit das System funktioniert“. Und dann folgt der Satz, auf den es hier ankommt: „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:

Erstens: 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. Er ist ein starkes Argument in der Auslegung, aber kein Tatbestand, auf den man sich unmittelbar beruft.

Zweitens: „Ausschliesslich“ ist wörtlich zu nehmen. Die Entlastung greift nur bei Komponenten, die für die ausschliessliche Verwendung zu Cybersicherheitszwecken vorgesehen sind. Wer mit demselben Modul zugleich in einen operativen Steuerungsablauf eingreift — etwa Anlagenparameter verändert, Prozesse abschaltet oder physische Zugänge steuert —, kann sehr wohl ein Sicherheitsbauteil bereitstellen. Die Grenze verläuft nicht am Produktnamen, sondern an der tatsächlichen Funktion im Zielsystem. Ein Intrusion-Detection-System, das ausschliesslich detektiert und meldet, liegt anders als eine Lösung, die im Ernstfall aktiv in die Prozessführung einer Wasser- oder Stromversorgung eingreift.

**Drittens: Die im Erwägungsgrund genannten Beispiele 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 Beispiele von Sicherheitsbauteilen kritischer Infrastruktur [2]. Sie illustrieren also, was erfasst ist — und grenzen dadurch mittelbar ab, was der Gesetzgeber unter einem Sicherheitsbauteil verstand: Schutz physischer Integrität, nicht Schutz von Daten und Systemen vor Angriffen.

Viertens: Die Entlastung betrifft nur eine von zwei Türen. Wer nach Erwägungsgrund 55 kein Sicherheitsbauteil bereitstellt, ist damit dem Weg über Art. 6 Abs. 1 i. V. m. Anhang I KI-VO entgangen — nicht aber automatisch der Einstufung über Anhang III KI-VO, die eigenen Kriterien folgt. Beide Wege sind getrennt zu prüfen.

Die praktische Konsequenz für Anbieter von Sicherheitssoftware: Die Einordnung ist zu dokumentieren, nicht zu unterstellen. Wer sich darauf stützt, dass seine Komponente ausschliesslich Cybersicherheitszwecken dient, sollte genau das nachvollziehbar festhalten — Funktionsbeschreibung, Schnittstellen zum Zielsystem, ausgeschlossene Eingriffsmöglichkeiten.

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 Identifizierung und Kategorisierung natürlicher Personen — also Gesichtserkennung, Stimmerkennung oder biometrische Zugangssysteme. Die Hochrisiko-Einstufung trifft hier nicht alle biometrischen Systeme gleichermassen: Anhang III Nr. 1 lit. a KI-VO erfasst biometrische Fernidentifizierung als Hochrisiko und enthält die Ausnahme für reine biometrische Verifizierung (Abgleich 1:1, deren einziger Zweck die Identitätsbestätigung ist) — diese 1:1-Ausnahme gilt ausschliesslich für lit. a, nicht für lit. b oder lit. c. Anhang III Nr. 1 lit. b (biometrische Kategorisierung anhand sensibler Merkmale) und lit. c (Emotionserkennung) fallen ohne diese Ausnahme unter Hochrisiko.

Der zweite Bereich (Anhang III Nr. 2) betrifft die Verwaltung und den Betrieb kritischer Infrastruktur: KI-Systeme, die als Sicherheitskomponente in der Steuerung kritischer digitaler Infrastruktur oder von Wasser-, Gas-, Heizungs-, Strom- oder Verkehrsnetzen 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 und Arbeitnehmersteuerung: 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, Versicherungs-Risikoprüfung, Triage in Notaufnahmen, 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.

Entscheidend für die Praxis: Viele KI-Produkte, die intuitiv als „wichtig“ oder „sensibel“ wahrgenommen werden, fallen nicht unter Anhang III — und sind auch keine Sicherheitskomponenten drittzertifizierungspflichtiger Produkte nach Art. 6 Abs. 1 i. V. m. Anhang I KI-VO. Ein KI-gestütztes Textverarbeitungstool, ein Chatbot für den Kundenservice, eine KI-basierte Übersetzungssoftware, ein Coding-Assistent — all das ist in der Regel kein Hochrisiko-KI-System. Für diese Produkte gibt es keine Vermutungswirkung, und die CRA-Compliance und die AI-Act-Compliance (soweit letztere überhaupt Pflichten auslöst) laufen 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 Unterabs. 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 Unterabs. 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. Ergänzend sieht Art. 6 Abs. 5 KI-VO vor, dass die Kommission Leitlinien zur praktischen Umsetzung dieses Artikels samt einer Liste praktischer Beispiele bereitstellt.

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 Vermutungswirkung 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 vernünftigerweise 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]. Diese Mitwirkungspflicht entfällt nach dem letzten Satz 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.

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 Satz 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 — die Vermutungswirkung greift nur, wenn die CRA-Konformitätsbewertung die KI-spezifischen Cybersicherheitsrisiken ausdrücklich abdeckt. 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: Die CRA-Anforderungen sollen unter Berücksichtigung von KI-spezifischen Anfälligkeiten wie Datenvergiftung (Data Poisoning) und gegnerischen Angriffen (Adversarial Attacks) bestimmt werden. Diese beiden Angriffsvektoren sind im Erwägungsgrund explizit benannt.

Grundrechte-Risiken als integraler Bestandteil der CRA-Risikobewertung. Erwägungsgrund (51) CRA verlangt — über die reinen Cyber-Risiken hinaus — auch die Berücksichtigung von Grundrechte-Risiken, soweit einschlägig („gegebenenfalls“), nach den Vorgaben der KI-VO [1][7]. Konkret bedeutet das: Die CRA-Risikobewertung für Hochrisiko-KI-Kombinationsprodukte muss lebenszyklus-übergreifend (Planung, Entwurf, Entwicklung, Produktion, Lieferung und Wartung) prüfen, ob das Produkt Grundrechte (etwa Diskriminierungsfreiheit, Datenschutz, Menschenwürde) durch Cyber-Vorfälle oder durch sein bestimmungsgemässes Verhalten beeinträchtigen kann. Diese Verschränkung von Cyber- und Grundrechte-Risiken ist eine der substanziellsten Neuerungen, die der CRA für KI-Produkte einführt — und sie wird in der Praxis oft übersehen, weil klassische Cybersecurity-Frameworks Grundrechte nicht abbilden.

Darüber hinaus dokumentiert die praktische KI-Sicherheitsliteratur weitere relevante Vektoren, die in einer CRA-Risikobewertung Berücksichtigung finden sollten:

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 muss 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 muss dokumentiert werden, welche Massnahmen gegen Membership-Inference und Model-Extraction-Angriffe implementiert sind.

Prompt Injection (MITRE ATLAS [3], OWASP ML Top 10 [4]) — der jüngste und in der Praxis häufigste KI-Angriffsvektor. Dabei werden in die Eingabe eines KI-Systems Anweisungen eingeschleust, die das Systemverhalten manipulieren — etwa um Sicherheitsschranken zu umgehen oder vertrauliche Systemprompts offenzulegen. Für Produkte, die Large Language Models (LLMs) einsetzen, ist Prompt Injection ein zentrales Risiko, das die CRA-Risikobewertung adressieren muss.

All diese Angriffsvektoren müssen nicht nur identifiziert, sondern auch mit konkreten Gegenmassnahmen adressiert werden. Der OWASP Machine Learning Security Top 10 [4] und MITRE ATLAS [3] bieten strukturierte Frameworks, 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 Common Specifications 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. Hersteller können also die Vermutungswirkung auch mit anderen Konformitätsnachweisen begründen — etwa durch Sicherheitszertifikate Dritter, technische Dokumentation oder konservative Sicherheitsarchitektur-Reviews.

Stand August 2026 sind CRA-spezifische harmonisierte Normen noch nicht verabschiedet. 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 (15 horizontale, 26 vertikale Standards). Der Zeitplan ist gestaffelt: Nach der FAQ der Kommissionsdienststellen (Abschnitt 6.10) [9] sollen die horizontalen Normen zu Design, Entwicklung und Herstellung sowie zur Schwachstellenbehandlung bis zum 30.08.2026 von den europäischen Normungsorganisationen verabschiedet werden, die 26 vertikalen Normen bis zum 30.10.2026 — die horizontale Norm zu den Produkteigenschaften nach Anhang I Teil I aber erst bis zum 30.10.2027, also rund sechs Wochen vor Geltungsbeginn der CRA-Produktanforderungen.

Entscheidend ist dabei ein Punkt, der leicht übersehen wird: Die Konformitätsvermutung nach Art. 27 CRA [1] entsteht erst mit der Veröffentlichung der Fundstelle im Amtsblatt der Europäischen Union, nicht bereits mit der Verabschiedung durch die Normungsorganisationen. Zwischen beiden Zeitpunkten liegt regelmässig ein weiterer Schritt. Bis dahin können Unternehmen die normgestützte Konformitätsvermutung formal nicht in Anspruch nehmen — sie können sich aber bereits darauf vorbereiten, 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ätsbewertungs­verfahren

Während Art. 12 Abs. 1 CRA die Vermutungswirkung regelt, setzen Art. 12 Abs. 2 und 3 CRA die zweite — in der Praxis mindestens ebenso wichtige — Klammer zur KI-VO: das Konformitätsbewertungs­verfahren bei Hochrisiko-KI-Kombinationsprodukten [1][7][8].

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ätsbewertungs­verfahren 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 — vorausgesetzt, die Cybersicherheits­anforderungen des CRA werden im Rahmen dieses Verfahrens mitgeprüft. Eine nach KI-VO notifizierte Stelle ist auch für die CRA-relevanten Aspekte zuständig, sofern bei ihrer Notifizierung nach KI-VO auch die Anforderungen aus Art. 39 CRA an die notifizierte Stelle geprüft wurden.

Der Zuständigkeitsübergang ist bedingt — und das hat unmittelbare Folgen für die Auswahl der Prüfstelle. Der juristische Kommentar von Schröder/Hartl arbeitet heraus, dass die Bündelung der Bewertung bei der nach der KI-VO zuständigen notifizierten Stelle nur dann fachgerecht funktioniert, wenn diese Stelle zusätzlich das Notifizierungsverfahren nach Art. 39 CRA durchlaufen hat und die dort festgelegten Anforderungen an notifizierte Stellen unter dem CRA erfüllt. Fehlt diese CRA-Notifizierung, geht die Zuständigkeit für das CRA-Bewertungsverfahren nach dieser Auslegung nicht über — hergeleitet wird das aus dem Wort „sofern“ in Art. 12 Abs. 2 CRA [8, Art. 12 Rn. 15].

Für Hersteller ist das eine praktische Prüfaufgabe mit Terminwirkung: Es genügt nicht, irgendeine unter der KI-VO notifizierte Stelle zu beauftragen. Ist die Stelle nicht auch CRA-notifiziert, bleibt die CRA-Konformitätsbewertung als eigener Strang zu führen — mit entsprechendem Zusatzaufwand in Zeitplan und Budget. Der Notifizierungsstatus nach Art. 39 CRA gehört deshalb in die Auswahlkriterien für die Prüfstelle, nicht erst in die Vertragsverhandlung.

Ausnahme (Art. 12 Abs. 3 CRA): Bei wichtigen Produkten mit digitalen Elementen (Anhang III CRA, Klasse I und Klasse II) und bei kritischen Produkten mit digitalen Elementen (Anhang IV CRA) greift zusätzlich die CRA-eigene Konformitätsbewertung — sofern für sie KI-VO-seitig an sich nur die interne Kontrolle nach Anhang VI KI-VO gälte. Es entsteht ein kombiniertes Verfahren: Die KI-VO-Konformitätsbewertung nach Art. 43 KI-VO wird mit der CRA-Konformitätsbewertung nach Anhang VIII CRA verschränkt. Hersteller solcher Kombinationsprodukte müssen daher beide Verfahrensstränge organisatorisch und dokumentarisch zusammenführen.

Die KI-VO kann ein Produkt auch „hochziehen“. Welches Bewertungsverfahren gewählt werden kann, richtet sich auch ohne gebündelte Zuständigkeit nach Art. 43 KI-VO — und die KI-VO lässt die interne Kontrolle deutlich öfter zu als der CRA. Bei biometrischen Systemen nach Anhang III Nr. 1 KI-VO kann sich die Richtung aber umkehren: Für ein Produkt, für das nach Art. 32 Abs. 1 CRA die interne Kontrolle zulässig wäre, kann über die KI-VO die unabhängige Bewertung durch eine notifizierte Stelle erforderlich werden. Der Kommentar von Schröder/Hartl hält diesen Effekt für plausibel: Mit der Einstufung als KI-System zur biometrischen Fernidentifizierung oder als Sicherheitsbauteil in einem System nach Anhang I KI-VO gehe die Wertung einher, dass auch verschärfte allgemeine Cybersicherheitsanforderungen gelten [8, Art. 12 Rn. 16].

Praktisch heisst das: Ein Produkt, das isoliert betrachtet unter dem CRA im Modul A bliebe, kann über die KI-VO in ein Drittprüfverfahren geraten. Wer nur die CRA-Klassifizierung prüft und daraus auf den Verfahrensaufwand schliesst, kalkuliert unter Umständen zu knapp.

Für Hersteller bedeutet das: Die Frage „Welches Konformitäts­verfahren gilt für mich?“ lässt sich bei einem Hochrisiko-KI-Kombinationsprodukt nicht allein über den CRA beantworten. Der erste Schritt ist die Klassifizierung nach Anhang III/IV CRA und parallel die Hochrisiko-Einstufung nach KI-VO. Erst aus dem Zusammenspiel beider Klassifizierungen ergibt sich der massgebliche Verfahrenspfad.

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] — ü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 Vermutungswirkung ausrichten: KI-spezifische Risiken und Grundrechte-Risiken in die Bewertung nach Anhang I CRA [1] 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 Vulnerability Management um KI-Angriffsvektoren (MITRE ATLAS [3], OWASP ML Top 10 [4]). Verfahrensseitig läuft die Konformitätsbewertung über Art. 43 KI-VO; bei Anhang-III- oder Anhang-IV-Produkten nach CRA kommt zusätzlich die CRA-Konformitäts­bewertung als kombiniertes Verfahren hinzu. Prüfen Sie dabei früh, ob die vorgesehene notifizierte Stelle auch nach Art. 39 CRA notifiziert ist [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 „Without prejudice“-Klausel ausgenommen. Harmonisierte Normen sind keine Voraussetzung der Vermutungswirkung nach Art. 12 CRA — sie erleichtern aber den Nachweis der Bedingungen; die normgestützte Konformitätsvermutung läuft separat über Art. 27 CRA. Liegen die Bedingungen des Art. 12 Abs. 1 CRA vor, sparen Sie sich den separaten Cybersicherheitsnachweis nach Art. 15 KI-VO.

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 Vermutungswirkung — 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 (Transparenzpflicht) 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]. Trotzdem empfiehlt sich, Erwägungsgrund (51) CRA [1] ernst zu nehmen und KI-spezifische Risiken sowie Grundrechte-Risiken in die CRA-Risikobewertung aufzunehmen — auch ohne Vermutungswirkung. Das verschafft Ihnen einen Compliance-Vorsprung bei der Produktsicherheit.

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, wohl aber die NIS-2-Pflichten [6], sofern der Anbieter die Schwellenwerte erreicht.

Die SBOM als Klammer

Ein Element verbindet CRA und KI-VO auf der operativen Ebene: die Software Bill of Materials. 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].

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: ein Risikomanagementsystem, das beide Verordnungen — einschliesslich Grundrechte-Risiken — adressiert [1][2]; eine CRA-SBOM für die erfassten Softwarekomponenten, ergänzt um gesonderte KI-/ML-Dokumentation; ein Vulnerability-Management-Prozess, der neben CVEs auch KI-spezifische Schwachstellen trackt; und eine klare Verfahrensplanung, die Art. 43 KI-VO und gegebenenfalls die zusätzliche CRA-Konformitätsbewertung nach Anhang III/IV CRA frühzeitig berücksichtigt — einschliesslich der Frage, ob die vorgesehene notifizierte Stelle auch unter dem CRA notifiziert ist.

Entscheidend ist auch: Den Unterschied zwischen der Vermutungswirkung (Art. 12 CRA, nur Cybersicherheits-Teil von Art. 15 KI-VO) und den ausgenommenen Anforderungen (Art. 15 KI-VO „Without prejudice“: Genauigkeit und Robustheit) ernst nehmen. Der CRA ersetzt nicht das KI-VO-Risikomanagementsystem — er ergänzt es auf der Cybersicherheitsseite und verschränkt sich verfahrensseitig über Art. 12 Abs. 2 und 3 CRA mit 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, haben einen doppelten Vorteil: Sie sind vorbereitet, wenn die CRA-Produktanforderungen ab dem 11. Dezember 2027 gelten — und sie können die Vermutungswirkung des Art. 12 CRA [1] nutzen; harmonisierte Normen sind dafür keine Voraussetzung, sie erleichtern aber den Nachweis der Bedingungen (die normgestützte Konformitätsvermutung läuft separat über Art. 27 CRA). Wer dagegen CRA und KI-VO als getrennte Compliance-Silos aufbaut, riskiert Redundanz, Inkonsistenz und unnötige Kosten.

Hinweis zur Methodik

Alle Aussagen in diesem Artikel sind direkt gegen die Primärquellen verifiziert: die Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 12 Abs. 1, 2 und 3, Art. 27, Art. 28, Art. 32 Abs. 1, Art. 39, Anhang V (Inhalt der EU-Konformitätserklärung) und Erwägungsgrund (51), sowie die Verordnung (EU) 2024/1689 (KI-VO/AI Act), insbesondere Art. 3 Nr. 12 (Zweckbestimmung), Art. 3 Nr. 14 (Sicherheitsbauteil), Art. 6 Abs. 1 bis 5 (Einstufungsvorschriften einschliesslich der Ausnahme nach Abs. 3, der Profiling-Rückausnahme nach Abs. 3 Unterabs. 3 und der Dokumentations- und Registrierungspflicht nach Abs. 4), Kapitel III (Art. 8 ff.), Art. 15, Art. 16 (Anbieterpflichten), Art. 25 Abs. 1 und 2 (Verantwortlichkeiten entlang der KI-Wertschöpfungskette), Art. 43, Art. 49 Abs. 2 (Registrierung), Anhang III und Anhang VI sowie die Erwägungsgründe 53, 54 und 55.

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.), Cyber Resilience Act, Nomos 2025, insbesondere Sörup, § 4 Rn. 59 (Grundrechte-Risiken in der CRA-Risikobewertung) und Rn. 64–65 (Art. 12 Abs. 2 und 3 CRA, Verschränkung mit Art. 43 KI-VO), sowie Schröder/Hartl (Hrsg.), Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos, dort die Kommentierung von Art. 12 CRA durch Hofmann, insbesondere Rn. 15 (CRA-Notifizierung als Bedingung des Zuständigkeitsübergangs) und Rn. 16 (Verfahrenswahl nach Art. 43 KI-VO bei biometrischen Systemen). Die Kommentierung von Hofmann gliedert Art. 12 CRA in erfasste Produkte (Rn. 5–7), Cybersicherheitsanforderungen nach Abs. 1 (Rn. 8–13), Bündelung des Konformitätsbewertungsverfahrens nach Abs. 2 (Rn. 14–16), Ausnahmen von der Bündelungswirkung nach Abs. 3 (Rn. 17–20) und Reallabore nach Abs. 4 (Rn. 21–22). Für den Normungszeitplan wurde die FAQ der Kommissionsdienststellen zum CRA (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: Explizit benannt in Erwägungsgrund (51) CRA - Model Inversion und Prompt Injection: Praxisrelevante Ergänzungen auf Basis von MITRE ATLAS und OWASP ML Top 10, nicht namentlich in Erwägungsgrund (51) erwähnt, aber im Scope moderner KI-Sicherheitsbewertungen

Die Interpretation der „Without prejudice“-Klausel folgt dem englischen Wortlaut von Art. 12 Abs. 1 CRA — eine kritische Einschränkung der Vermutungswirkung, die in der deutschen Fachdiskussion oft übersehen wird, weil Art. 15 KI-VO Genauigkeit, Robustheit und Cybersicherheit gemeinsam regelt, die CRA-Vermutung aber nur den Cybersicherheits-Teil abdeckt.

Stand dieser Fassung: v11, 12.08.2026. Das Erscheinungsdatum wurde im Rahmen des festgelegten Veröffentlichungsrhythmus auf den 27.04.2026 gesetzt; zeitabhängige Formulierungen bleiben unverändert.

Stand dieser Fassung: v10, 06.08.2026. Änderungen gegenüber v9: Neuer Abschnitt zum Begriff des Sicherheitsbauteils (Legaldefinition Art. 3 Nr. 14 KI-VO, Ausnahme für ausschliesslich der Cybersicherheit dienende Komponenten nach Erwägungsgrund 55 KI-VO, Klarstellung der Beispielfunktion von Wasserdruck-Überwachung und Feuermelder-Kontrollsystemen, Hinweis auf Erwägungsgrund 54 KI-VO für biometrische Cybersicherheitssysteme); neuer Abschnitt zur Ausnahme des Art. 6 Abs. 3 KI-VO einschliesslich der vier Fallgruppen, der Profiling-Rückausnahme und der Dokumentations- und Registrierungspflicht nach Art. 6 Abs. 4 i. V. m. Art. 49 Abs. 2 KI-VO; neuer Abschnitt zum Rollenwechsel nach Art. 25 Abs. 1 und 2 KI-VO mit der Zweckbestimmung nach Art. 3 Nr. 12 KI-VO und einem Hinweis zur Grenze vertraglicher Gestaltung; Aktualisierung des Normungszeitplans nach der FAQ der Kommissionsdienststellen (Abschnitt 6.10) mit den Terminen 30.08.2026, 30.10.2026 und 30.10.2027 sowie Klarstellung, dass die Konformitätsvermutung nach Art. 27 CRA erst mit Veröffentlichung der Fundstelle im Amtsblatt entsteht; Ergänzung von Szenario 2 um Art. 6 Abs. 3 und 4 KI-VO; Aufnahme der Quelle [9]; Erweiterung von Teaser, Tags, Methodik und Quellenverzeichnis; Aktualisierung des Prüfdatums.

Sie möchten wissen, ob Ihr KI-Produkt unter die Hochrisiko-Kategorie fällt und welche CRA-Pflichten für Sie gelten? Der CRA-Quick-Check liefert eine orientierende Einschätzung Ihrer CRA-Pflichten und Ihrer CRA-Produktklasse. Ob Ihr Produkt ein Hochrisiko-KI-System ist und ob die Vermutungswirkung greift, bedarf einer individuellen Prüfung.

Im nächsten Artikel dieser Serie: Software Bill of Materials (SBOM) unter dem CRA — Pflichtbestandteile, Formatfragen (CycloneDX, SPDX) und die Abgrenzung zur ergänzenden KI-/ML-Dokumentation.

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 (Vermutungswirkung), Art. 12 Abs. 2 und 3 (Konformitätsbewertungs­verfahren bei Hochrisiko-KI-Kombinationsprodukten), Art. 27 (Konformitätsvermutung bei harmonisierten Normen), Art. 28 (EU-Konformitätserklärung), Art. 32 Abs. 1 (anwendbare Konformitätsbewertungs­verfahren), 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ätsbewertungs­verfahren) 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, angenommen 13. Juni 2024, veröffentlicht 12. Juli 2024, in Kraft getreten 1. August 2024, zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz (KI-VO/AI Act), insbesondere Art. 3 Nr. 12 (Zweckbestimmung), Art. 3 Nr. 14 (Sicherheitsbauteil), Art. 6 (Einstufungsvorschriften für Hochrisiko-KI-Systeme, insbesondere Abs. 1 und 2 zu den beiden Einstufungswegen, Abs. 3 zur Ausnahme von Anhang III einschliesslich der Profiling-Rückausnahme in Unterabs. 3, Abs. 4 zur Dokumentations- und Registrierungspflicht und Abs. 5 zu den Leitlinien der Kommission), Kapitel III (Hochrisiko-KI-Systeme, Art. 8 ff.), Art. 15 (Genauigkeit, Robustheit und Cybersicherheit für Hochrisiko-KI), Art. 16 (Pflichten der Anbieter von Hochrisiko-KI-Systemen), Art. 25 Abs. 1 und 2 (Verantwortlichkeiten entlang der KI-Wertschöpfungskette, Rollenwechsel zum Anbieter und Mitwirkungspflichten des Erstanbieters), Art. 43 (Konformitätsbewertungs­verfahren), Art. 49 Abs. 2 (Registrierung bei Verneinung der Hochrisiko-Einstufung), Art. 50 (Transparenzpflichten), Anhang III (acht Bereiche von Hochrisiko-KI-Systemen), Anhang VI (interne Kontrolle) sowie die Erwägungsgründe 53 (Beispiele zu den Bedingungen des Art. 6 Abs. 3), 54 (biometrische Systeme zu Cybersicherheitszwecken) und 55 (Sicherheitsbauteile kritischer Infrastruktur; Komponenten zur ausschliesslichen Verwendung zu Zwecken der Cybersicherheit). ABl. L, 2024/1689, 12.7.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

[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 Open Worldwide Application Security Project (OWASP) Foundation zur Identifikation und Mitigation 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 (Hrsg.), Cyber Resilience Act, Kommentar, Nomos 2025, insbesondere 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ätsbewertungs­verfahren nach Art. 12 Abs. 2 und 3 CRA, Verschränkung mit Art. 43 KI-VO, Rolle notifizierter Stellen unter Berücksichtigung von Art. 39 CRA, kombiniertes Verfahren bei Anhang-III- und Anhang-IV-Produkten).

[8] Schröder, M./Hartl, K. (Hrsg.) — Cyber Resilience Act: CRA, 1. Auflage 2026, Nomos (zitiert als NK-CRA/Bearbeiter). Artikelweiser Kommentar zur Verordnung (EU) 2024/2847; Art. 12 kommentiert von Hofmann. Herangezogen: NK-CRA/Hofmann, 1. Aufl. 2026, CRA Art. 12 Rn. 15 (Zuständigkeitsübergang nach Art. 12 Abs. 2 CRA nur bei zusätzlicher Notifizierung nach Art. 39 CRA; 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.3 vom 01.07.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.

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. Veröffentlicht am: 27.04.2026. Zuletzt geprüft am: 13.08.2026. Herausgeberin: codAIx GmbH, Thayngen (Schweiz).

Stand: 13.08.2026 (v12 — freigegebene Schlusskorrektur: Zitierweise von Art. 12 Abs. 1 vereinheitlicht; CRA-SBOM von ergänzender KI-/ML-Dokumentation abgegrenzt; Grammatik und Zeichensetzung korrigiert. Vorherige Fassung: v11; zeitabhängige Formulierungen unverändert.)