Von codAIx GmbH | 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.


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, bieten Art. 12 CRA und Art. 42 AI Act [1][2] eine 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 stoßen Unternehmen jedoch auf ein kritisches Risiko und drei praktische Hürden, die den vermeintlichen Automatismus relativieren.

Die kritische Einschränkung: "Without prejudice"

Art. 12(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 der AI-VO". Das bedeutet in der Praxis: Die CRA-Konformität presumiert nur die Cybersicherheitsanforderungen des AI Act, nicht die Anforderungen an Genauigkeit und Robustheit des Modells selbst.

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(1) CRA

Art. 12(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 wesentlichen Cybersicherheitsanforderungen nach Teil I des Anhangs I des CRA: Das Produkt mit digitalen Elementen — einschließlich 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 AI Act muss in der EU-Konformitätserklärung nach Art. 23 CRA nachgewiesen werden. 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 ausschließlich für KI-Systeme, die nach Art. 6 in Verbindung mit Anhang III des AI Act als hochriskant eingestuft sind [2]. Für alle anderen KI-Systeme — und das ist die große Mehrheit — existiert keine Brücke zwischen den beiden Verordnungen.

Die acht Kategorien des Anhang III [2] definieren, welche KI-Anwendungen als hochriskant gelten. Die Liste ist abschließend, aber innerhalb der Kategorien besteht Auslegungsspielraum.

Die erste Kategorie umfasst biometrische Identifizierung und Kategorisierung natürlicher Personen — also Gesichtserkennung, Stimmerkennung oder biometrische Zugangssysteme, soweit sie über reine Verifizierung (Abgleich 1:1) hinausgehen.

Die zweite Kategorie betrifft die Verwaltung und den Betrieb kritischer Infrastruktur: KI-Systeme, die als Sicherheitskomponente in der Steuerung von Wasser-, Gas-, Heizungs-, Strom- oder Verkehrsnetzen eingesetzt werden.

Die dritte Kategorie erfasst Bildung und Berufsausbildung: KI-gestützte Prüfungsbewertung, Zulassungsentscheidungen oder adaptive Lernsysteme, die den Bildungsweg einer Person wesentlich beeinflussen.

Die vierte Kategorie umfasst Beschäftigung und Arbeitnehmersteuerung: automatisierte Bewerbervorauswahl, KI-gestützte Kündigungsentscheidungen, Leistungsüberwachung und Aufgabenzuweisung.

Die fünfte Kategorie betrifft den Zugang zu wesentlichen privaten und öffentlichen Dienstleistungen: Kreditscoring, Versicherungs-Risikoprüfung, Triage in Notaufnahmen, Priorisierung von Rettungsdiensten.

Die sechste Kategorie erfasst Strafverfolgung: Risikoeinschätzung für potenzielle Straftäter, Polygraphen, Beweismittelbewertung, Kriminalitätsvorhersage.

Die siebte Kategorie betrifft Migration, Asyl und Grenzkontrolle: automatisierte Visumprüfung, Risikoeinschätzung irregulärer Migration, Identitätserkennung an Grenzen.

Die achte Kategorie 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. 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.

Hürde 2: KI-spezifische 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) des CRA [1] formuliert den Grund dafür: Die CRA-Anforderungen sollten "unter Berücksichtigung von KI-spezifischen Anfälligkeiten, wie Datenvergiftung (Data Poisoning) oder gegnerische Angriffe (Adversarial Attacks)" bestimmt werden. Diese beiden Angriffsvektoren sind im Erwägungsgrund explizit benannt.

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 Maßnahmen 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 Gegenmaßnahmen 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(1) CRA als Bedingung genannt [1].

Wichtig ist die Unterscheidung: Art. 27(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 April 2026 sind CRA-spezifische harmonisierte Normen noch nicht endgültig verabschiedet. CEN und CENELEC [5] entwickeln im Rahmen des Normungsauftrags M/606 der EU-Kommission 41 harmonisierte Standards (15 horizontale, 25 vertikale) für Produkte mit digitalen Elementen. Die Normenentwürfe befinden sich seit März 2026 in der öffentlichen Konsultation; die Veröffentlichung ist für Q3/Q4 2026 geplant. Bis die endgültigen Normen vorliegen, können Unternehmen die Konformitätsvermutung nach Art. 27 CRA [1] formal noch 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 praktische Konsequenz: Drei Compliance-Szenarien

Aus der kritischen Einschränkung und den drei Hürden ergeben sich in der Praxis drei Szenarien, die KI-Unternehmen kennen sollten.

Szenario 1: Hochrisiko-KI mit CRA-Produkt. Ihr KI-System fällt unter Anhang III des AI Act [2] 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 in die Bewertung nach Anhang I [1] integrieren, SBOM um KI-Komponenten (Modelle, Frameworks, Trainings-Pipelines) erweitern, Vulnerability Management um KI-Angriffsvektoren (MITRE ATLAS [3], OWASP ML Top 10 [4]) ergänzen. 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. Sobald harmonisierte Normen vorliegen, können Sie die Vermutungswirkung formal nutzen — und sparen sich den separaten Cybersicherheitsnachweis nach Art. 15 AI Act [2].

Szenario 2: Nicht-Hochrisiko-KI mit CRA-Produkt. Ihr KI-Produkt fällt nicht unter Anhang III [2], aber unter den CRA [1]. Hier gibt es keine Vermutungswirkung — CRA und AI Act laufen parallel. Allerdings sind die AI-Act-Pflichten für Nicht-Hochrisiko-KI deutlich geringer: Möglicherweise nur Art. 50 (Transparenzpflicht) [2] oder gar keine spezifischen Pflichten. Trotzdem empfiehlt sich, Erwägungsgrund (51) [1] ernst zu nehmen und KI-spezifische Risiken in die CRA-Risikobewertung aufzunehmen — auch ohne Vermutungswirkung. Das verschafft Ihnen einen Competitive-Advantage 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 AI-Act-Pflichten — je nach Risikokategorie Art. 50 (Transparenz) [2], Art. 6 ff. (Hochrisiko) [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 AI Act auf der operativen Ebene: die Software Bill of Materials. Der CRA [1] verlangt eine SBOM für jedes Produkt mit digitalen Elementen. Bei KI-Produkten bedeutet das: Neben den klassischen Software-Abhängigkeiten müssen auch KI-Komponenten erfasst werden — das verwendete Modell, die Version, die Trainings-Frameworks, die Datenquellen.

Diese erweiterte SBOM ist gleichzeitig die Grundlage für die technische Dokumentation, die der AI Act für Hochrisiko-KI-Systeme verlangt [2]. Wer seine SBOM von Anfang an KI-bewusst aufbaut, schafft damit eine gemeinsame Datenbasis für beide Compliance-Pfade.

Der Blick nach vorn

Die duale Regulierung von KI-Produkten durch CRA und AI Act ist komplex, aber nicht unbeherrschbar. Der Schlüssel liegt in der frühzeitigen Integration: ein Risikomanagementsystem, das beide Verordnungen adressiert [1][2]; eine SBOM, die klassische und KI-Komponenten erfasst; ein Vulnerability-Management-Prozess, der neben CVEs auch KI-spezifische Schwachstellen trackt.

Entscheidend ist auch: Den Unterschied zwischen der Vermutungswirkung (Art. 12, nur Cybersicherheit) und den ausgenommenen Anforderungen (Art. 15 "Without prejudice": Genauigkeit, Robustheit) ernst nehmen. Der CRA ersetzt nicht das AI-Act-Risikomanagementsystem — er ergänzt es auf der Cybersicherheitsseite.

Unternehmen, die diese Integration jetzt anstoßen, haben einen doppelten Vorteil: Sie sind vorbereitet, wenn die CRA-Produktanforderungen im Dezember 2027 in Kraft treten — und sie können die Vermutungswirkung des Art. 12 [1] nutzen, sobald harmonisierte Normen verfügbar sind. Wer dagegen CRA und AI Act 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, Art. 27 und Erwägungsgrund (51), sowie die Verordnung (EU) 2024/1689 (AI Act), insbesondere Art. 6, Art. 15, Art. 42 und Anhang III.

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(1) CRA: "Without prejudice to the requirements relating to accuracy and robustness set out in Article 15" — eine kritische Einschränkung der Vermutungswirkung, die in der deutschen Fachdiskussion oft übersehen wird.


Sie möchten wissen, ob Ihr KI-Produkt unter die Hochrisiko-Kategorie fällt und welche CRA-Pflichten für Sie gelten? Der crAIready Quick Check umfasst ein systematisches Anhang-III-Screening und zeigt Ihnen, wo sich CRA- und AI-Act-Pflichten überschneiden — und wo die Vermutungswirkung greift.


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 (Hochrisiko-KI-Systeme), Art. 27 (Konformitätsvermutung), Anhang I Teil I (Cybersicherheitsanforderungen) und Erwägungsgrund (51) (Zusammenspiel CRA und AI Act bei Hochrisiko-KI, einschließlich KI-spezifischer Anfälligkeiten wie Data Poisoning und Adversarial Attacks). 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 und zur Änderung der Verordnungen (EG) Nr. 300/2008, (EU) Nr. 167/2013, (EU) Nr. 168/2013, (EU) 2018/858, (EU) 2018/1139 und (EU) 2019/2144 und der Richtlinien 2014/90/EU, (EU) 2016/797 und (EU) 2020/1828 (AI Act), insbesondere Art. 6 (Einstufung von KI-Systemen als Hochrisiko), Art. 15 (Genauigkeit, Robustheit und Cybersicherheit für Hochrisiko-KI), Art. 42 (Konformitätsvermutung), Art. 50 (Transparenzpflichten) und Anhang III (Kategorien von Hochrisiko-KI-Systemen). 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] CEN (Europäisches Komitee für Normung) und CENELEC (Europäisches Komitee für Elektrotechnische Normung) – Europäische Normungsorganisationen, die im Auftrag der EU-Kommission (Normungsauftrag M/606) harmonisierte Normen zur Konkretisierung der CRA-Anforderungen für Produkte mit digitalen Elementen entwickeln. Status: Normenentwürfe in öffentlicher Konsultation seit März 2026, Veröffentlichung geplant für Q3/Q4 2026 (Stand April 2026). https://www.cencenelec.eu/

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


Aus der Theorie in die Praxis

codAIx automatisiert die hier beschriebenen CRA-Pflichten — Klassifizierung, SBOM, Schwachstellenmanagement, Dokumentation und Meldepflichten. In einer 30-Minuten-Demo zeigen wir Ihnen, wie das für Ihr Produkt aussieht.

Demo anfragen →