Von codAIx GmbH | April 2026

Wer ein KI-Produkt auf dem EU-Markt anbietet, muss sich ab 2027 mit zwei Verordnungen gleichzeitig auseinandersetzen: dem Cyber Resilience Act für die Cybersicherheit und dem AI Act für die KI-spezifischen Risiken. Das klingt nach doppeltem Aufwand. In der Praxis gibt es jedoch Vermutungswirkungen und Querverweise, die Synergien ermöglichen — wenn man sie kennt. Dieser Artikel ordnet das Zusammenspiel beider Regulierungen ein.


Zwei Verordnungen, ein Produkt

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

Beide Verordnungen haben unterschiedliche Regelungsgegenstände. Der AI Act adressiert KI-spezifische Risiken: Bias, Transparenz, menschliche Aufsicht, Datenqualität [2]. Der CRA adressiert Cybersicherheit im Lebenszyklus: Schwachstellenmanagement, Security by Design, SBOM, Incident Response [1]. Und doch überschneiden sich ihre Anwendungsbereiche — denn ein KI-System, das als Software lokal installiert oder als Datenfernverarbeitungslösung (RDPS) betrieben wird, ist gleichzeitig ein „Produkt mit digitalen Elementen" im CRA-Sinne und ein „KI-System" im AI-Act-Sinne. (Ob Ihr Produkt ein solches Produkt mit digitalen Elementen ist, klären der Drei-Elemente-Test und die Grauzone-Analyse aus den vorherigen Teilen dieser Serie.)

Das Ergebnis: Duale Compliance. Ein KI-Unternehmen muss beide Verordnungen gleichzeitig erfüllen, mit unterschiedlichen Anforderungen, unterschiedlichen Fristen und unterschiedlichen Aufsichtsbehörden. Aber — und das ist die gute Nachricht — der Gesetzgeber hat Mechanismen eingebaut, die Doppelarbeit vermeiden sollen.

Der AI Act im Schnelldurchlauf

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

Der AI Act unterscheidet vier Risikokategorien [2]. KI-Systeme mit unannehmbarem Risiko — etwa Social Scoring durch Behörden oder Echtzeit-Biometrie im öffentlichen Raum — sind verboten. Hochrisiko-KI-Systeme, die in Anhang III des AI Act aufgelistet sind [2], unterliegen umfangreichen Anforderungen: Risikomanagementsystem, Daten-Governance, technische Dokumentation, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit. KI-Systeme mit Transparenzrisiko — etwa Chatbots oder Deepfake-Generatoren — müssen die Nutzerinteraktion offenlegen. Und alle übrigen KI-Systeme fallen in die Kategorie „minimales Risiko" mit freiwilligen Verhaltenskodizes.

Die acht Hochrisikokategorien des Anhang III umfassen Biometrie und Identifizierung, kritische Infrastruktur, Bildung und Berufsausbildung, Beschäftigung und Arbeitnehmersteuerung, Zugang zu wesentlichen Dienstleistungen, Strafverfolgung, Migration und Grenzschutz sowie Justiz und demokratische Prozesse [2].

Für die CRA-Schnittstelle ist die Hochrisiko-Einstufung entscheidend. Denn nur bei Hochrisiko-KI-Systemen greifen die besonderen Verbindungsmechanismen zwischen beiden Verordnungen.

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

Art. 12 CRA [1] ist die zentrale Schnittstellennorm. Er regelt, unter welchen Bedingungen ein Hochrisiko-KI-System, das gleichzeitig ein Produkt mit digitalen Elementen ist, eine Konformitätsvermutung für die Cybersicherheitsanforderungen des AI Act erhält.

Konkret: Wenn ein Hochrisiko-KI-System die Cybersicherheitsanforderungen des CRA erfüllt, dann wird vermutet, dass es auch die Cybersicherheitsanforderungen des AI Act (Art. 15 KI-VO: Cybersicherheit) [2] einhält. Wichtig: Diese Vermutung gilt unbeschadet der Anforderungen an Genauigkeit und Robustheit gemäß Art. 15 AI Act. Das heißt: Die CRA-Compliance schafft eine Konformitätsvermutung nur für das Cybersicherheits-Element von Art. 15. Die Anforderungen an Genauigkeit und Robustheit müssen separat nachgewiesen werden.

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

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

(b) Konformität der Herstellerprozesse mit Teil II Anlage I: Die vom Hersteller eingeleiteten Verfahren müssen den wesentlichen Cybersicherheitsanforderungen des zweiten Teils des Anhangs entsprechen — dies sind vor allem die Prozess- und Governance-Anforderungen wie Vulnerability Management, Security by Design und Incident Response.

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

Eine kritische Voraussetzung: Die CRA-Konformitätsbewertung muss die KI-spezifischen Cybersicherheitsrisiken ausdrücklich abdecken. Erwägungsgrund (51) CRA nennt dabei zwei KI-spezifische Schwachstellenarten ausdrücklich beim Namen: Daten-Vergiftung (Data Poisoning) und gegnerische Angriffe (Adversarial Attacks) [1]. Darüber hinaus dokumentieren praxisorientierte Frameworks wie MITRE ATLAS [3] und OWASP ML Top 10 [4] weitere relevante Angriffsvektoren — insbesondere Model Inversion und Prompt Injection —, die zwar nicht namentlich im CRA-Text stehen, aber im Scope einer vollständigen KI-Risikobewertung berücksichtigt werden sollten. Die Standard-CRA-Compliance reicht also nicht aus — die Risikobewertung nach Anhang I muss KI-spezifische Angriffsvektoren systematisch adressieren.

Darüber hinaus müssen harmonisierte Normen oder Common Specifications vorliegen, die die CRA-Anforderungen im KI-Kontext konkretisieren. Stand April 2026 sind diese Normen noch in Arbeit — die europäischen Normungsorganisationen CEN und CENELEC haben den Auftrag, entsprechende Standards zu entwickeln.

Art. 95 AI Act: Die Gegenrichtung

Die Vermutungswirkung funktioniert auch in die andere Richtung — und hier wird es für die Praxis besonders interessant.

Art. 95 des AI Act [2] enthält eine reziproke Vermutungsregelung: Wenn ein Hochrisiko-KI-System die Konformitätsbewertung nach dem CRA erfolgreich durchlaufen hat und dabei die Cybersicherheitsanforderungen des CRA erfüllt, dann wird vermutet, dass auch die Cybersicherheitsanforderungen des AI Act (Art. 15) [2] erfüllt sind. Diese Vermutung ist die Spiegelung von Art. 12 CRA aus der Perspektive des AI Act.

Warum ist das relevant? Weil es die Prüfungsreihenfolge festlegt. Für Unternehmen, die ein Hochrisiko-KI-System mit CRA-relevanter Produktarchitektur herstellen, bedeutet es: Investiert zuerst in die CRA-Compliance. Wenn die CRA-Konformitätsbewertung sauber ist und die KI-spezifischen Risiken abdeckt, entsteht automatisch eine Konformitätsvermutung für den AI Act im Bereich Cybersicherheit. Das spart nicht den gesamten AI-Act-Aufwand — Transparenz, menschliche Aufsicht und Datenqualität müssen weiterhin separat nachgewiesen werden —, aber es entlastet beim Thema Cybersicherheit erheblich.

Ein wichtiger Hinweis zur Einschränkung: Beide Vermutungswirkungen — Art. 12 CRA [1] und Art. 95 AI Act [2] — gelten ausschließlich für Hochrisiko-KI-Systeme. Wer ein KI-Produkt herstellt, das nicht unter Anhang III des AI Act [2] fällt, bekommt keine Vermutungswirkung. Er muss die CRA-Anforderungen und die eventuell anwendbaren AI-Act-Anforderungen (etwa Art. 50 Transparenzpflichten) [2] unabhängig voneinander erfüllen.

Die Zeitachse: Wann was gilt

Die beiden Verordnungen treten gestaffelt in Kraft, was die Komplexität zusätzlich erhöht.

Seit 2. Februar 2025 gilt Art. 4 des AI Act [2]: die Pflicht zur KI-Kompetenz. Unternehmen, die KI-Systeme einsetzen oder bereitstellen, müssen sicherstellen, dass ihr Personal über ausreichende KI-Kompetenz verfügt.

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

Ab August 2026 gelten die Hochrisiko-KI-Pflichten und die Transparenzpflichten des Art. 50 AI Act [2]. Letzterer ist für viele Unternehmen relevanter als gedacht: Jedes KI-System, das direkt mit natürlichen Personen interagiert, muss diese darüber informieren, dass sie mit einem KI-System kommunizieren — es sei denn, dies ist aus den Umständen offensichtlich.

Ab 11. September 2026 gelten die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen [1].

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

Für KI-Unternehmen ergibt sich daraus ein klares Timing: Die AI-Act-Pflichten kommen zuerst. Die CRA-Pflichten folgen. Aber die Vorbereitung auf beide muss parallel laufen, weil die CRA-Compliance-Infrastruktur — insbesondere SBOM, Vulnerability Management und Risikobewertung — Vorlaufzeit von 12 bis 18 Monaten erfordert.

Was KI-Unternehmen jetzt tun sollten

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

Der erste Schritt ist die Klassifizierung. Fallen Ihre KI-Funktionen unter eine der acht Hochrisiko-Kategorien des Anhang III AI Act [2]? Diese Frage entscheidet über den gesamten Compliance-Aufwand. Bei Hochrisiko profitieren Sie von der Vermutungswirkung — müssen aber die KI-spezifische CRA-Risikobewertung entsprechend ausgestalten. Bei Nicht-Hochrisiko entfällt die Vermutungswirkung, aber auch ein großer Teil der AI-Act-Pflichten.

Der zweite Schritt ist die Risikobewertung mit KI-Fokus. Auch wenn Ihr Produkt nicht als Hochrisiko eingestuft ist: Erwägungsgrund (51) des CRA [1] verlangt, dass KI-spezifische Angriffsvektoren in der CRA-Risikobewertung berücksichtigt werden. Daten-Vergiftung und Adversarial Attacks — die beiden im CRA-Erwägungsgrund namentlich genannten Schwachstellenarten — gehören in jede CRA-Risikobewertung, die KI-Komponenten enthält, unabhängig von der AI-Act-Klassifizierung. Darüber hinaus sollten Model Inversion und Prompt Injection als praxisrelevante Angriffsvektoren adressiert werden, auch wenn sie im CRA-Text selbst nicht namentlich erwähnt sind — sie sind in MITRE ATLAS [3] und OWASP ML Top 10 [4] als zentrale KI-Sicherheitsrisiken dokumentiert und gehören zum Stand der Technik einer vollständigen KI-Risikobewertung.

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


Enthält Ihr Produkt KI-Komponenten? Der crAIready Quick Check identifiziert nicht nur Ihre CRA-Pflichten, sondern auch die relevanten AI-Act-Schnittstellen — einschließlich der Frage, ob Ihr KI-System als Hochrisiko einzustufen ist und ob die Vermutungswirkung des Art. 12 CRA für Sie greift.


Im nächsten Artikel dieser Serie: Hochrisiko-KI unter dem CRA — Art. 12 CRA im Detail, warum die drei Bedingungen der Konformitätsvermutung anspruchsvoller sind, als sie auf den ersten Blick wirken, und was das für Ihre Compliance-Strategie bedeutet.


Hinweis zur Methodik

Alle Aussagen in diesem Artikel sind direkt gegen die Primärquellen verifiziert: die Verordnung (EU) 2024/2847 (CRA), insbesondere Art. 12 und Erwägungsgrund (51), sowie die Verordnung (EU) 2024/1689 (AI Act), insbesondere Art. 6, Art. 15, Art. 50, Art. 95 und Anhang III.

Die Zuordnung KI-spezifischer Angriffsvektoren erfolgt differenziert: Data Poisoning und Adversarial Attacks sind in Erwägungsgrund (51) CRA namentlich benannt. Model Inversion und Prompt Injection sind dort nicht namentlich erwähnt, werden aber als praxisrelevante Ergänzungen auf Basis von MITRE ATLAS und OWASP ML Top 10 empfohlen.


Quellen

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

[2] Verordnung (EU) 2024/1689 des Europäischen Parlaments und des Rates vom 13. Juni 2024 zur Festlegung harmonisierter Vorschriften für künstliche Intelligenz und zur Änderung der Verordnungen (EG) Nr. 300/2008, (EU) Nr. 167/2013, (EU) Nr. 168/2013, (EU) 2018/858, (EU) 2018/1139 und (EU) 2019/2144 und der Richtlinien 2014/90/EU, (EU) 2016/797 und (EU) 2020/1828 (Verordnung über künstliche Intelligenz). ABl. L, 12.07.2024. https://eur-lex.europa.eu/eli/reg/2024/1689/oj

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

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


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 →