Wer ein Produkt mit digitalen Elementen und KI-Funktionen auf dem EU-Markt anbietet, muss sowohl den Cyber Resilience Act (CRA) als auch den AI Act (KI-Verordnung) beachten. Wir erklären an konkreten Beispielen, wo CRA und AI Act zusammentreffen, wo sie sich grundlegend unterscheiden – und wie Hersteller ein bestehendes AI-Management-System (AIMS) nach ISO 42001 effizient um CRA-Anforderungen erweitern.
In aller Kürze
- Cyber Resilience Act (Verordnung (EU) 2024/2847) und AI Act (Verordnung (EU) 2024/1689) überschneiden sich bei KI-fähigen Produkten mit digitalen Elementen.
- Überschneidungen betreffen vor allem Risikobewertung, Dokumentation, Konformitätsbewertung und laufende Pflichten.
- Ein bestehendes AIMS kann gezielt für den CRA erweitert werden.
- Wer die Umsetzung beider Normen in einem integrierten Managementsystem steuert, profitiert von Synergieeffekten.
Warum gelten für Produkte mit digitalen Elementen und KI zwei Verordnungen gleichzeitig?
Künstliche Intelligenz (KI) ist längst kein Nischenthema mehr: Predictive-Maintenance-Module in Industriesoftware, Anomalie-Erkennungssysteme in Netzwerksicherheitsprodukten, Sprachmodelle in Kundendienst-Plattformen – KI-Komponenten finden sich heute in einer wachsenden Zahl vernetzter Produkte. Genau diese Produkte können gleichzeitig in den Anwendungsbereich beider Verordnungen fallen:
- Der AI Act regelt KI-Systeme und KI-Modelle mit allgemeinem Verwendungszweck (GPAI). Er knüpft Pflichten vor allem an das Risikopotenzial der KI-Anwendung – von verbotenen Praktiken über Hochrisiko-KI-Systeme bis zu Systemen mit begrenztem Risiko.
- Der CRA reguliert demgegenüber die Cybersicherheit von Produkten mit digitalen Elementen: die sichere Konzeption, Entwicklung, Bereitstellung und Pflege vernetzter Hard- und Software.
Enthält ein Produkt eine KI-Komponente und ist es zugleich ein vernetztes Produkt mit digitalen Elementen, greifen beide Verordnungen – mit unterschiedlichem Fokus, aber erheblichen Überschneidungen in der praktischen Umsetzung.
Tipp: Bei unserer Paretnerkanzlei activeMind.legal Rechtsanwälte finden Sie jeweils eine ausführliche Vorstellung des Cyber Resilience Acts und des AI Acts.
Was haben CRA und AI Act gemeinsam?
Risikobasierter Ansatz über den gesamten Lebenszyklus
Beide Verordnungen verlangen eine systematische Risikoanalyse, die nicht einmalig, sondern lebenszyklus-begleitend durchzuführen ist. Neue Erkenntnisse über Schwachstellen, Bedrohungen oder unerwartetes Systemverhalten müssen laufend eingearbeitet werden.
Der wesentliche Unterschied liegt im Risikofokus:
- Die Cybersicherheits-Risikobeurteilung nach Art. 13 CRA richtet sich auf Cyberbedrohungen, Angriffsflächen, Authentifizierungs- und Autorisierungsrisiken sowie Schwachstellen in Softwarekomponenten.
- Das Risikomanagementsystem nach Art. 9 AI Act für Hochrisiko-KI-Systeme adressiert dagegen KI-spezifische Risiken: Modellfehler, Bias, mangelnde Erklärbarkeit und den Verlust menschlicher Kontrolle.
Beide Perspektiven sind komplementär – sie können in einem gemeinsamen Risikoregister zusammengeführt werden, sollten konzeptionell aber sauber getrennt dokumentiert sein.
Technische Dokumentation und Konformitätsbewertung
Beide Verordnungen verlangen eine umfangreiche technische Dokumentation, die vor der Markteinführung vorliegen muss und über den gesamten Lebenszyklus aktuell zu halten ist.
- Im CRA-Kontext ist das die technische Dokumentation nach Art. 31 i.V.m. Anhang VII CRA.
- Für Hochrisiko-KI-Systeme verlangt der AI Act eine technische Dokumentation nach Anhang IV, die unter anderem eine Systembeschreibung, Angaben zum Entwicklungsprozess, Informationen zur menschlichen Aufsicht sowie Testberichte umfasst.
Die inhaltlichen Überschneidungen – insbesondere bei der Produktbeschreibung, der Risikoanalyse und den Konformitätsnachweisen – sind erheblich.
Beide Verordnungen münden zudem in eine CE-Kennzeichnung als sichtbaren Marktfreigabeakt. Für KI-Produkte, bei denen beide Verordnungen eine externe Konformitätsbewertung durch eine notifizierte Stelle erfordern, müssen diese Verfahren koordiniert werden. Die EU-Kommission hat angekündigt, hierzu gesonderte Orientierungshilfen zu veröffentlichen.
Parallele Melde- und Überwachungspflichten
Der CRA enthält detaillierte Pflichten zum Schwachstellenmanagement und zur Meldung aktiv ausgenutzter Schwachstellen sowie schwerer Sicherheitsvorfälle. Diese gelten seit September 2026 und auch für bereits auf dem Markt befindliche Produkte.
Tipp: Beachten Sie dazu unseren Ratgeber zu den Meldepflichten unter dem CRA.
Der AI Act verlangt für Hochrisiko-KI-Systeme nach Art. 72 ein Post-Market-Monitoring-System sowie die Meldung schwerwiegender Vorfälle nach Art. 73 (etwa solche, die den Tod oder schwere Verletzungen verursacht haben).
Bei einem KI-Produkt mit digitalen Elementen können beide Meldepflichten gleichzeitig relevant werden – etwa wenn eine ausgenutzte Schwachstelle in einem KI-Modell zugleich einen schwerwiegender Vorfall im Sinne des AI Act auslöst.
Wo unterschieden sich CRA und AI Act grundlegend?
Produktbezug vs. Systembezug: unterschiedliche Anwendungsbereiche
Der CRA ist produktbezogen: Er gilt für Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden. Entscheidend ist die Bereitstellung auf dem Markt, nicht der Betrieb.
Der AI Act ist systemorientiert und greift zum Teil auch für KI-Systeme, die selbst entwickelt und intern betrieben werden, ohne auf dem Markt bereitgestellt zu werden – etwa wenn ein Unternehmen ein Hochrisiko-KI-System für den eigenen Betrieb einsetzt.
Unternehmen, die KI-Systeme intern entwickeln und nutzen, fallen somit unter den AI Act, aber nicht unter den CRA.
Unterschiedliche Risikosystematik: Cybersicherheit vs. gesellschaftliches KI-Risiko
Der CRA kategorisiert Produkte nach ihrem Cybersicherheitsrisiko in drei Klassen: Standardprodukte, wichtige Produkte (Klasse I und II) sowie kritische Produkte.
Der AI Act kategorisiert KI-Systeme nach ihrem gesellschaftlichen Risikopotenzial: verboten, Hochrisiko (Anhang II und Anhang III AI Act), KI-Systeme mit begrenztem Risiko und solche mit minimalem Risiko.
Diese Kategorisierungen sind unabhängig voneinander: Ein KI-System kann gleichzeitig Hochrisiko-KI nach dem AI Act und ein kritisches Produkt nach dem CRA sein – oder nur unter eine der beiden Verordnungen fallen. Die Einstufung muss für jedes Regelwerk separat vorgenommen werden.
Unterschiedliche Pflichtenträger in der Lieferkette
Der CRA adressiert Hersteller, Einführer und Händler von Produkten.
Der AI Act kennt zusätzlich die Rolle des Betreibers (Deployer): Unternehmen, die ein Hochrisiko-KI-System im eigenen Betrieb nutzen, tragen eigene Pflichten – etwa zur Risikobewertung, Datenkontrolle und menschlichen Aufsicht. Diese Betreiberpflichten haben im CRA keine direkte Entsprechung.
Umgekehrt kennt der CRA Pflichten für Händler und Einführer, die im AI Act in dieser Form nicht bestehen.
Bei KI-Produkten im B2B-Kontext können Anbieter und Betreiber gleichzeitig Pflichten aus beiden Verordnungen tragen.
Welche Verordnung gilt bei KI-Produkten vorrangig?
Für Hochrisiko-KI-Systeme, die zugleich Produkte mit digitalen Elementen sind, gilt grundsätzlich: Beide Verordnungen gelten nebeneinander und ergänzen sich. Eine Befreiung von CRA-Pflichten durch AI-Act-Konformität gibt es nicht – und umgekehrt.
Allerdings erkennt der AI Act in Art. 8 an, dass Anforderungen aus anderen Rechtsakten der Union, die Informationssicherheits-Anforderungen enthalten, als erfüllt gelten können, wenn die darin enthaltenen Anforderungen mindestens den wesentlichen Cybersicherheitsanforderungen des AI Acts entsprechen.
In der Praxis bedeutet dies: CRA-Konformität kann dazu beitragen, bestimmte Sicherheitsanforderungen des AI Act zu erfüllen – eine vollständige Substitution der AI-Act-Anforderungen durch CRA-Compliance ist jedoch nicht möglich.
Tipp: Lesen Sie auch unsere Vergleiche:
Praxisbeispiele für die Geltung von CRA und AI Act
Die folgenden Beispiele erläutern an drei ganz verschiedenen Kontexten, wieso Produkte sowohl unter den AI Act als auch den CRA fallen können – und was das in der Praxis bedeuten kann:
KI-gestütztes Brandmeldekontrollsystem in Cloud-Rechenzentren
Ein Hersteller entwickelt ein vernetztes Brandmeldekontrollsystem für den Einsatz in kommerziellen Cloud-Rechenzentren. Das System besteht aus einer Hardwareeinheit (Steuergerät mit eingebetteter Software), die Sensordaten von Rauch-, Wärme- und Gasmeldern in Echtzeit auswertet, Alarmstufen klassifiziert und automatisch Löschanlagen, Evakuierungsalarme sowie Abschaltsequenzen für kritische IT-Infrastruktur auslöst. Die Steuereinheit ist über ein Netzwerkinterface mit dem Gebäudemanagementsystem und einer Fernwartungsplattform des Herstellers verbunden.
Warum ist das KI-Modul ein Hochrisiko-KI-System nach Anhang III Nr. 2 AI Act?
Anhang III Nr. 2 AI Act stuft KI-Systeme als hochriskant ein, die als Sicherheitskomponenten im Management und Betrieb kritischer digitaler Infrastruktur eingesetzt werden. Ein kommerzielles Cloud-Rechenzentrum, das IT-Infrastruktur für Drittunternehmen betreibt, qualifiziert als kritische digitale Infrastruktur im Sinne des AI Act (Art. 3 Nr. 62 AI Act i.V.m. Art. 2 Nr. 4 der CER-Richtlinie (EU) 2022/2557).
Das KI-Modul übernimmt eine direkte Sicherheitsfunktion: Es klassifiziert in Echtzeit Brandereignisse und löst darauf aufbauend automatische Schutzmaßnahmen aus – sowohl zum Schutz der physischen Infrastruktur des Rechenzentrums als auch zum Schutz von Personen, die sich im Gebäude befinden. Erwägungsgrund 55 AI Act stellt ausdrücklich klar, dass KI-Systeme mit einer solchen unmittelbaren Sicherheitsfunktion als Hochrisiko-KI-Systeme einzustufen sind.
Die Ausnahmetatbestände des Art. 6 Abs. 3 AI Act greifen nicht: Das System trifft keine bloß unterstützenden oder vorbereitenden Entscheidungen, sondern löst unmittelbar sicherheitsrelevante physische Prozesse aus (Löschanlage, Evakuierungsalarm, IT-Abschaltung). Angesichts des direkten Schadenspotenzials – für die physische Infrastruktur des Rechenzentrums wie für anwesende Personen – scheidet eine Einstufung als nicht hochriskant nach Art. 6 Abs. 3 AI Act aus.
Warum fällt das Produkt unter den CRA?
Das Brandmeldekontrollsystem ist ein Hardware-Softwareprodukt mit dauerhafter Netzwerkverbindung (Gebäudemanagementsystem, Fernwartungsschnittstelle des Herstellers) und wird gewerblich auf dem EU-Markt bereitgestellt. Es erfüllt damit die Voraussetzungen eines Produkts mit digitalen Elementen nach Art. 2 Abs. 1 CRA.
Die Ausnahmen nach Art. 2 Abs. 4 CRA greifen nicht: Das System ist kein Medizinprodukt (MDR), kein Kraftfahrzeug und kein Luftfahrzeug. Es unterfällt keinem der in Art. 2 Abs. 4 CRA genannten Sektorregelwerke, die den CRA verdrängen würden.
Was bedeutet die doppelte Regulierung in der Praxis?
CRA und AI Act gelten damit gleichzeitig und nebeneinander. Ein Cyberangriff, der das KI-Modul mit manipulierten Sensordaten versorgen wurde und dadurch einen Brandalarm unterdrückt oder eine ungerechtfertigte IT-Abschaltung auslöst, würde gleichzeitig einen CRA-Meldetatbestand (aktiv ausgenutzte Schwachstelle, Art. 14 CRA) und einen AI-Act-Meldetatbestand (schwerwiegender Vorfall eines Hochrisiko-KI-Systems, Art. 73 AI Act) darstellen.
KI-gestützte Schutzeinrichtung für eine Hydraulikpresse
Ein Hersteller bringt eine hydraulische Presse für die Kaltbearbeitung von Metall auf den Markt. Die Presse verfügt über ein KI-gestütztes, kamerabasiertes Schutzsystem. Das System erkennt, ob sich eine Hand oder ein anderer Körperteil im Gefahrenbereich der Presse befindet. Erkennt es eine Person im Gefahrenbereich, verhindert es den Schließvorgang oder löst unverzüglich einen sicheren Stopp der Presse aus.
Warum ist das KI-System ein Hochrisiko-KI-System nach Hochrisiko nach Art. 6 Abs. 1 AI Act i.V.m. Anhang I AI Act?
Das KI-System erfüllt damit eine unmittelbare Sicherheitsfunktion. Es dient nicht lediglich der Bedienerunterstützung, der Leistungsoptimierung oder der Automatisierung eines Produktionsschritts, sondern verhindert konkret Verletzungen. Es ist daher als Sicherheitsbauteil der Presse anzusehen.
Bei der konkreten Presse werden die einschlägigen harmonisierten Normen nicht vollständig angewendet beziehungsweise decken sie die KI-basierte Sicherheitsfunktion nicht vollständig ab. Deshalb ist für die Presse ein Konformitätsbewertungsverfahren unter Einbindung einer notifizierten Stelle erforderlich. Die Maschinenrichtlinie sieht für bestimmte Maschinenkategorien, darunter bestimmte Pressen, eine solche Drittprüfung vor, wenn die Voraussetzungen für eine interne Fertigungskontrolle nicht erfüllt sind (Anhang I Teil B Nummer 9., Art. 25 Abs. 3 Maschinenverordnung).
Das KI-System ist somit nach Art. 6 Abs. 1 AI Act als Hochrisiko-KI-System einzustufen. Es ist ein Sicherheitsbauteil einer von der Maschinenrichtlinie erfassten Maschine, und die Maschine muss vor dem Inverkehrbringen oder der Inbetriebnahme wegen ihrer Gesundheits- und Sicherheitsrisiken einer Konformitätsbewertung durch einen Dritten unterzogen werden.
Die Ausnahme für Produkte, deren Drittprüfung ausschließlich auf Risiken für die Funkfrequenzverteilung oder auf elektromagnetische Störungen ohne Auswirkungen auf Gesundheit und Sicherheit beruht, greift nicht. Die Drittprüfung erfolgt in diesem Beispiel gerade wegen der konkreten Verletzungs- und Quetschrisiken der Presse.
Warum fällt das Produkt unter den CRA?
Die Presse und ihre KI-gestützte Schutzlösung bestehen aus Hardware, Software und einer vom Hersteller verantworteten Datenfernverarbeitungslösung. Die bestimmungsgemäße Verwendung umfasst eine logische und physische Datenverbindung zwischen Kameras, Steuerung und Hersteller-Backend. Ohne die Datenfernverarbeitungslösung könnte die KI-basierte Gefahrenerkennung nicht ausgeführt werden.
Achtung: Die Maschinenrichtlinie 2006/42/EG bleibt bis zum 19. Januar 2027 anwendbar. Ab dem 20. Januar 2027 wird sie grundsätzlich durch die Maschinenverordnung (EU) 2023/1230 ersetzt. Für Produkte, die danach in Verkehr gebracht oder in Betrieb genommen werden, ist die dann anwendbare Maschinenverordnung zugrunde zu legen.
Lesen Sie dazu auch den Beitrag von activeMind.legal zur Maschinenverordnung.
KI-gestützte Hindernis- und Körperschutzerkennung bei einem Roboterspielzeug
Ein Hersteller bringt ein vernetztes, autonom fahrendes Roboterspielzeug für Kinder ab acht Jahren auf den Markt. Das Spielzeug verfügt über Kameras und Sensoren, die Daten über die Umgebung und die Position des Kindes erfassen. Diese Daten werden an eine vom Hersteller entwickelte und betriebene KI-gestützte Software übertragen. Dort analysiert ein KI-Modell die Daten und ermittelt, ob sich ein Kind, eine Hand oder ein anderer Gegenstand im Bewegungs- oder Greifbereich des Roboters befindet. Das Ergebnis wird an die Steuerung des Roboters zurückübermittelt. Wird eine mögliche Kollision oder Einklemmgefahr erkannt, reduziert das Spielzeug seine Geschwindigkeit, stoppt die Bewegung oder fährt seine beweglichen Teile in eine sichere Position.
Warum ist das KI-System ein Hochrisiko-KI-System nach Hochrisiko nach Art. 6 Abs. 1 AI Act i.V.m. Anhang I AI Act?
Das KI-System dient damit nicht lediglich der Unterhaltung, der Sprachausgabe, der Personalisierung des Spielerlebnisses oder der Komfortsteigerung. Es erfüllt vielmehr eine konkrete Schutzfunktion zur Vermeidung körperlicher Verletzungen und ist deshalb als Sicherheitsbauteil des Spielzeugs anzusehen.
Für die konkrete Produktkonfiguration ist eine EG-Baumusterprüfung durch eine notifizierte Stelle erforderlich. Grund dafür ist, dass die einschlägigen harmonisierten Normen die KI-basierte Sicherheitsfunktion nicht vollständig abdecken und der Hersteller deshalb nicht ausschließlich auf eine interne Fertigungskontrolle zurückgreifen kann. Nach Artikel 19 und Artikel 20 der Spielzeugrichtlinie wird die EG-Baumusterprüfung durch eine notifizierte Stelle durchgeführt, die bei erfolgreicher Prüfung eine EG-Baumusterprüfbescheinigung ausstellt.
Das KI-System ist somit nach Art. 6 Abs. 1 AI Act i.V.m. Anhang I AI Act als Hochrisiko-KI-System einzustufen. Es ist ein Sicherheitsbauteil eines von der Spielzeugrichtlinie erfassten Spielzeugs, und das Spielzeug muss vor dem Inverkehrbringen wegen der mit seiner Bewegung und seinen beweglichen Teilen verbundenen Gesundheits- und Sicherheitsrisiken einer Drittprüfung unterzogen werden.
Die Ausnahme für KI-Systeme, die ausschließlich der Nutzerunterstützung, der Leistungsoptimierung, der Serviceeffizienz, der Automatisierung, dem Komfort oder der Qualitätskontrolle dienen, greift nicht. Die KI steuert in diesem Beispiel unmittelbar eine Schutzfunktion, die bei erkannter Gefahr eine Bewegung stoppt oder begrenzt.
Warum fällt das System unter den CRA?
Das Roboterspielzeug umfasst digitale Hardware, Software, Sensoren, Kommunikationsschnittstellen und eine vom Hersteller verantwortete Datenfernverarbeitungslösung. Ohne diese Lösung könnte das Spielzeug die konkrete Funktion der KI-basierten Hindernis- und Körperschutzerkennung nicht ausführen.
Achtung: Die Spielzeugrichtlinie bleibt bis zum 31. Juli 2030 anwendbar. Ab dem 1. August 2030 wird sie grundsätzlich durch die Spielzeugverordnung (EU) 2025/2509 ersetzt.
Wie kann ein bestehendes AIMS für den CRA erweitert werden?
Viele Unternehmen, die KI-Systeme entwickeln oder einsetzen, haben im Zuge der AI-Act-Umsetzung bereits ein AI-Management-System (AIMS) aufgebaut – häufig auf Basis der ISO 42001. Ein AIMS nach AI Act und ISO 42001 deckt bereits wesentliche Strukturelemente ab, die auch für CRA-Compliance relevant sind. Die gute Nachricht: Diese Strukturen können gezielt um CRA-spezifische Elemente erweitert werden, ohne ein paralleles Compliance-System von Grund auf neu aufzubauen.
Was ein AIMS nach ISO 42001 bereits abdeckt
Ein gut aufgebautes AIMS nach ISO 42001 und AI Act enthält in der Regel bereits:
- ein Risikomanagementsystem mit Risikoregister und dokumentierten Behandlungsmaßnahmen,
- eine technische Dokumentation der KI-Systeme einschließlich Systembeschreibung und Entwicklungsprozess,
- ein Datenmanagement-Framework (Trainings-, Validierungs- und Testdatensätze),
- eine Dokumentation der menschlichen Aufsichtsmechanismen (Human Oversight),
- Prozesse für Post-Market-Monitoring und Vorfallsmeldung,
- ein Lieferkettenmanagement mit Anforderungen an KI-Komponentenlieferanten.
Alle diese Elemente haben direkte oder zumindest strukturelle Entsprechungen in den CRA-Anforderungen – sie bilden damit eine tragfähige Ausgangsbasis.
Was für den CRA ergänzt werden muss
Trotz dieser Überschneidungen fehlen in einem reinen AIMS nach AI Act typischerweise folgende CRA-spezifische Elemente:
- Cybersicherheits-Risikobeurteilung nach Art. 13 CRA: Die AI-Act-Risikoanalyse konzentriert sich auf KI-spezifische Risiken (Modellfehler, Bias, Erklärbarkeit). Die CRA-Risikobeurteilung muss zusätzlich Cyberbedrohungen, Angriffsflächen, Authentifizierungs- und Autorisierungsrisiken sowie Schwachstellen in Softwarekomponenten adressieren. Beide Risikoanalysen können in einem gemeinsamen Risikoregister zusammengeführt werden, sollten aber konzeptionell sauber getrennt dokumentiert sein.
- Secure Development Lifecycle (SDLC) und Vulnerability-Handling-Prozesse: Der AI Act fokussiert auf Qualität und Robustheit des Entwicklungsprozesses für KI-Modelle, adressiert aber keinen vollständigen SDLC im Sinne von Anhang I Teil II CRA. Für CRA-Compliance müssen Prozesse für Vulnerability Disclosure, Triage, Patch-Management und Nutzerinformation ergänzt werden.
- Software Bill of Materials (SBOM): Der CRA verlangt eine systematische Erfassung aller im Produkt enthaltenen Softwarekomponenten und Abhängigkeiten. Der AI Act kennt keine vergleichbare SBOM-Anforderung; entsprechende Prozesse zur Komponentenverfolgung und Schwachstellenüberwachung müssen für CRA-Zwecke ergänzt werden.
- Secure-by-default-Konfiguration: Die Anforderung, Produkte so auszuliefern, dass die Standardkonfiguration bereits sicher ist (Anhang I Teil I CRA), hat im AIMS nach AI Act keine Entsprechung. Konfigurationsmanagement und Hardening-Richtlinien für das Produkt müssen ergänzt werden.
- Erweiterte technische Dokumentation nach Anhang VII CRA: Die technische Dokumentation nach Anhang IV AI Act und nach Anhang VII CRA überschneiden sich in Teilen (Produktbeschreibung, Risikoanalyse, Konformitätsnachweise), unterscheiden sich aber in den spezifischen Nachweisanforderungen. Eine konsolidierte Dokumentationsstruktur, die beide Anhänge systematisch abbildet, reduziert den Aufwand erheblich.
- Meldepflichten nach Art. 14 CRA: Die Meldung aktiv ausgenutzter Schwachstellen und schwerer Sicherheitsvorfälle an ENISA und die zuständige nationale Behörde ist eine CRA-spezifische Pflicht mit eigenem Meldekanal und eigenen Fristen (24-Stunden-Erstmeldung, 72-Stunden-Meldung, Abschlussbericht). Sie muss als eigenständiger Prozess etabliert und von der AI-Act-Vorfallsmeldung nach Art. 72 AI Act konzeptionell abgegrenzt werden – auch wenn operative Überschneidungen (z. B. gemeinsames Incident-Response-Team) sinnvoll sind.
Achtung: Die Maschinenrichtlinie 2006/42/EG bleibt bis zum 19. Januar 2027 anwendbar. Ab dem 20. Januar 2027 wird sie grundsätzlich durch die Maschinenverordnung (EU) 2023/1230 ersetzt. Für Produkte, die danach in Verkehr gebracht oder in Betrieb genommen werden, ist die dann anwendbare Maschinenverordnung zugrunde zu legen.
Lesen Sie dazu auch den Beitrag von activeMind.legal zur Maschinenverordnung.
Wie hilft ein integriertes Compliance-Management bei der Erfüllung beider Normen?
Die effizienteste Herangehensweise für Hersteller von KI-Produkten ist ein integriertes Compliance-Management-System, das CRA und AI Act als Anforderungsebenen eines gemeinsamen Rahmens behandelt – ähnlich wie die bekannte Integration von ISO 27001 (Informationssicherheit) und ISO 42001 (KI-Management). Konkret bedeutet das:
- ein gemeinsames Risikoregister mit klarer Markierung, welche Risiken CRA-relevant, AI-Act-relevant oder beides sind;
- eine konsolidierte technische Dokumentation, die sowohl Anhang IV AI Act als auch Anhang VII CRA abdeckt;
- gemeinsame Review-Zyklen für Risikobewertungen und technische Dokumentation;
- koordinierte Incident-Response-Prozesse, die gleichzeitig CRA-Meldepflichten und AI-Act-Vorfallsmeldungen adressieren.
Fazit: Zwei Verordnungen, ein Produkt – gemeinsam denken zahlt sich aus
CRA und AI Act sind keine Konkurrenten, sondern zwei Perspektiven auf denselben Gegenstand: das sichere und vertrauenswürdige digitale Produkt. Der CRA fragt: Ist das Produkt vor Cyberangriffen geschützt und werden Schwachstellen verantwortungsvoll behandelt? Der AI Act fragt: Ist das KI-System transparent, fair und unter menschlicher Kontrolle?
Für Hersteller von KI-Produkten mit digitalen Elementen bedeutet das nicht zwangsläufig doppelten Aufwand – vorausgesetzt, beide Anforderungsebenen werden von Anfang an integriert geplant. Wer ein bestehendes AIMS gezielt um die beschriebenen CRA-Elemente erweitert, schafft eine solide, zukunftsfähige Compliance-Grundlage.