Cyber Resilience Act: Die erste Meldepflicht seit 11. September 2026 – auch für KI-Software

11. September 2026: Der Stichtag, der KI-Software neu betrifft

Während weite Teile des deutschen Mittelstands ihre Compliance-Kapazitäten fast vollständig auf den EU AI Act ausgerichtet haben, ist am 11. September 2026 in einem zweiten, parallel laufenden Regelwerk eine erste scharfe Pflicht wirksam geworden. Der Cyber Resilience Act (CRA) verlangt seither von Herstellern vernetzter Produkte mit digitalen Elementen, aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle unverzüglich an die zuständigen Behörden zu melden. Keine Übergangsfrist, keine Schonzeit für Nachzügler – die Pflicht gilt ab diesem Datum unmittelbar.

Für klassische Hersteller vernetzter Hardware – Router, IoT-Sensorik, Industriesteuerungen – war dieser Stichtag seit Monaten im Kalender markiert. Weniger präsent ist er bei Anbietern und Betreibern von Software mit KI-Komponenten, obwohl der Wortlaut des CRA hier keine Ausnahme vorsieht. Ein LLM-basierter Assistent mit Netzwerkanbindung, ein KI-Agent mit Zugriff auf externe Schnittstellen oder eine KI-gestützte Steuerungssoftware in einer Maschine sind im Sinne der Verordnung „Produkte mit digitalen Elementen" – und damit meldepflichtig, sobald eine ihrer Schwachstellen aktiv ausgenutzt wird.

Dieser Beitrag ordnet den Stichtag rechtlich ein, erklärt die konkreten Melde- und Fristanforderungen, zeigt anhand von Beispielen, warum KI-Software ausdrücklich erfasst ist, grenzt den CRA gegenüber den Cybersicherheitspflichten des AI Act ab, fasst die aktuellen Praxisbefunde von TÜV Rheinland zusammen und schließt mit einer konkreten Checkliste sowie einer Roadmap bis zur vollen CRA-Konformität im Dezember 2027.

Der Cyber Resilience Act im Überblick: VO (EU) 2024/2847

Rechtsgrundlage ist die Verordnung (EU) 2024/2847, besser bekannt als Cyber Resilience Act. Sie wurde am 20. November 2024 im Amtsblatt der Europäischen Union veröffentlicht und trat gemäß dem üblichen Mechanismus zwanzig Tage später, am 10. Dezember 2024, in Kraft. Wie bei den meisten EU-Verordnungen dieser Größenordnung liegt zwischen Inkrafttreten und tatsächlicher Anwendung der Pflichten allerdings ein mehrjähriger, gestufter Übergangszeitraum – und genau in diesem Zeitraum befinden wir uns aktuell.

Der Anwendungsplan des CRA sieht drei zentrale Stichtage vor, von denen der erste bereits hinter uns liegt:

Datum	Was gilt	Relevanz für KI-Software
20.11.2024	Veröffentlichung der VO (EU) 2024/2847 im Amtsblatt	informativ
10.12.2024	Inkrafttreten der Verordnung (20 Tage nach Veröffentlichung)	informativ
11.06.2026	Meldestellen für Konformitätsbewertungsstellen nehmen Betrieb auf	mittelbar
11.09.2026	Melde-/Reporting-Pflichten für Schwachstellen & Vorfälle treten in Kraft	sehr hoch – ab sofort geltend
11.12.2027	Volle Anwendung inkl. Konformitätsbewertung und CE-Kennzeichnung	sehr hoch – Hauptpflichten

Erfasst sind Hersteller, Importeure und Händler von „Produkten mit digitalen Elementen" – ein bewusst breiter Begriff, der Hardware und Software gleichermaßen umfasst, sofern das Produkt eine direkte oder indirekte logische oder physische Datenverbindung zu einem Gerät oder Netzwerk hat. Der CRA ist damit horizontal angelegt: Er gilt branchenübergreifend und produktkategorienübergreifend, anders als der AI Act, der spezifisch auf KI-Systeme zugeschnitten ist.

Die drei Rollen des CRA – Hersteller, Importeur, Händler – sind dabei nicht gleichwertig belastet. Die Hauptlast der Meldepflichten liegt beim Hersteller, also bei dem Unternehmen, das das Produkt entwickelt oder unter eigenem Namen in Verkehr bringt. Für Software mit KI-Komponenten heißt das in der Praxis: Wer ein eigenes KI-Produkt – etwa eine Agentenplattform, einen Chat-Assistenten oder eine KI-gestützte Fachanwendung – unter eigener Marke vertreibt, trägt die volle Meldeverantwortung, selbst wenn die zugrunde liegenden Modelle oder Frameworks von Dritten stammen. Wer lediglich Open-Source-Komponenten intern nutzt, ohne ein eigenes Produkt daraus zu vermarkten, ist in erster Linie über das eigene IT-Sicherheitsmanagement betroffen, nicht über die CRA-Meldepflicht selbst – die Grenze verläuft hier entlang der Frage, ob ein Produkt tatsächlich in Verkehr gebracht wird.

Was genau gemeldet werden muss – und in welcher Frist

Die seit dem 11. September 2026 geltende Meldepflicht unterscheidet zwei Kategorien meldepflichtiger Ereignisse: aktiv ausgenutzte Schwachstellen (also Sicherheitslücken, für die bereits ein realer Angriff nachgewiesen ist – nicht jede theoretische CVE) und schwerwiegende Sicherheitsvorfälle, die die Netz- und Informationssicherheit des Produkts beeinträchtigen. Für beide Kategorien gilt dieselbe Fristenkaskade.

Meldestufe	Frist	Inhalt
Frühwarnung	24 Stunden	Erste Kenntnisnahme, betroffenes Produkt, grobe Einschätzung der Ausnutzung
Detaillierte Meldung	72 Stunden	Schweregrad, Angriffsvektor, verfügbare Gegenmaßnahmen, Aktualisierungsstand
Abschlussbericht	nach Behebung	Ursachenanalyse, ergriffene Korrekturmaßnahmen, betroffene Nutzerbasis

Der Meldeweg führt über die nationalen CSIRT (Computer Security Incident Response Teams) beziehungsweise die zentrale ENISA-Meldeplattform, die für den grenzüberschreitenden Informationsfluss zwischen den Mitgliedstaaten sorgt. Für Unternehmen bedeutet das in der Praxis: ein Formular, ein Zugang, aber eine Frist, die in Kalendertagen kaum Luft lässt – 24 Stunden schließen ein Wochenende oder einen Feiertag ausdrücklich nicht aus.

Genau diese Frist ist es, die laut Berichten von TÜV Rheinland für einen Großteil der befragten Industrieunternehmen die größte operative Hürde darstellt – ein Befund, den wir weiter unten im Detail einordnen.

Wichtig für die interne Klassifizierung: Nicht jede in einem CVE-Feed veröffentlichte Schwachstelle löst automatisch die Meldepflicht aus. Maßgeblich ist die aktive Ausnutzung – also der belegte Fall, dass ein Angreifer eine konkrete Schwachstelle in Ihrem Produkt tatsächlich ausgenutzt hat oder ein schwerwiegender Sicherheitsvorfall die Netz- und Informationssicherheit beeinträchtigt. Eine rein theoretische Lücke ohne bekannten Exploit begründet noch keine Meldepflicht, sollte aber selbstverständlich trotzdem im Rahmen des allgemeinen Patch-Managements geschlossen werden. Wer diese Unterscheidung nicht sauber trifft, läuft Gefahr, entweder die Meldeplattform mit Bagatellfällen zu überlasten oder umgekehrt einen tatsächlich meldepflichtigen Vorfall fälschlich als „nur theoretisch" einzustufen.

Warum Software mit KI-Komponenten ausdrücklich eingeschlossen ist

Der CRA kennt keine Ausnahme für Künstliche Intelligenz. Er gilt horizontal für alle vernetzten Produkte mit digitalen Elementen, unabhängig davon, ob die verarbeitende Logik ein klassischer Algorithmus, ein regelbasiertes System oder ein Sprachmodell ist. Drei Konstellationen begegnen uns in Kundenprojekten immer wieder:

• LLM-basierte Assistenten mit Netzwerkanbindung. Ein Chat-Assistent, der über eine API erreichbar ist, Nutzeranfragen entgegennimmt und mit Backend-Systemen kommuniziert, ist ein vernetztes digitales Produkt – unabhängig davon, ob das zugrunde liegende Modell in der eigenen Infrastruktur oder bei einem Cloud-Anbieter läuft.
• KI-Agenten mit Tool-Use und API-Zugriff. Sobald ein KI-Agent eigenständig Werkzeuge aufruft, Dateien schreibt oder mit externen Systemen interagiert, vergrößert sich die Angriffsfläche gegenüber einem reinen Frage-Antwort-System erheblich – jede angebundene Schnittstelle ist ein potenzieller Vektor für eine aktiv ausgenutzte Schwachstelle.
• KI-gestützte Steuerungssoftware in Maschinen und IoT-Geräten. Wo neuronale Netze heute Anomalieerkennung, Qualitätskontrolle oder Prozessoptimierung übernehmen, ist die KI-Komponente in ein vernetztes Produkt eingebettet, das ohnehin unter den CRA fällt – die KI macht das Produkt nicht sicherer vor der Meldepflicht, sondern potenziell komplexer in der Bewertung.

Eine zusätzliche Schwachstellenquelle, die in vielen KI-Projekten unterschätzt wird, sind die eingesetzten Open-Source-Komponenten des KI-Stacks selbst: Basismodelle, Inferenz-Frameworks, Vektordatenbanken und Orchestrierungs-Bibliotheken. Eine Schwachstelle in einem weit verbreiteten Inferenz-Server betrifft nicht nur den ursprünglichen Entwickler, sondern jeden Hersteller, der die Komponente in ein eigenes vernetztes Produkt integriert hat – und macht auch ihn potenziell meldepflichtig, sobald diese Schwachstelle in seinem Produkt aktiv ausgenutzt wird.

CRA und EU AI Act: zwei Pflichtenkataloge, eine Schnittmenge

Für Anbieter und Betreiber von KI-Software stellt sich unweigerlich die Frage, wie sich der CRA zum bereits laufenden AI-Act-Compliance-Programm verhält. Die Antwort: Beide Regelwerke verfolgen unterschiedliche Ansätze, überschneiden sich aber an einer entscheidenden Stelle.

Artikel 15 des AI Act verlangt von Hochrisiko-KI-Systemen ein angemessenes Niveau an Genauigkeit, Robustheit und Cybersicherheit über den gesamten Lebenszyklus. Diese Anforderung ist spezifisch auf KI-Systeme zugeschnitten und knüpft an deren Risikoklassifizierung an. Der CRA dagegen definiert horizontale Basisanforderungen an Schwachstellenmanagement und Meldewesen für sämtliche digitalen Produkte – unabhängig davon, ob KI beteiligt ist oder nicht.

Wo sich beide Regelwerke treffen, ist bei Hochrisiko-KI-Systemen, die zugleich ein „Produkt mit digitalen Elementen" im Sinne des CRA sind. Für diese Konstellation ist im Gesetzgebungsverfahren ausdrücklich vorgesehen, dass die CRA-Konformitätsbewertung die Cybersicherheitsanforderungen des AI Act mit abdecken soll – mit dem Ziel, doppelte und damit ressourcenbindende Parallelprüfungen zu vermeiden. Praktisch bedeutet das: Wer sein Hochrisiko-KI-System ohnehin auf CRA-Konformität prüfen lässt, muss die Art.-15-Anforderungen nicht zusätzlich in einem separaten Verfahren nachweisen.

Was diese Entlastung bei der Konformitätsbewertung nicht abdeckt, ist das laufende Meldewesen. Hier bestehen zwei parallele Meldewege, die im Ernstfall beide bedient werden müssen: die AI-Act-eigene Vorfallmeldepflicht nach Artikel 73 einerseits und die CRA-Meldepflicht nach Artikel 14 andererseits. Beide Fristenregime laufen unabhängig voneinander, auch wenn der auslösende Vorfall identisch sein kann. Wie die AI-Act-Vorfallmeldung im Detail funktioniert und wo sie sich mit der CRA-Meldung überschneidet, haben wir in einem eigenen Beitrag zu Artikel 73 des AI Act beschrieben.

TÜV Rheinland: „Stresstest der CRA-Readiness" zeigt Nachholbedarf

Anlässlich des Stichtags hat sich TÜV Rheinland mit einer Einschätzung zu Wort gemeldet, die als Marktbeobachtung und Expertenstimme einzuordnen ist – nicht als eigene, methodisch offengelegte Studie dieses Blogs. Stefan Eigler von TÜV Rheinland bezeichnete den 11. September 2026 als „Stresstest der CRA-Readiness" für die deutsche Industrie, und die berichteten Praxisbefunde stützen diese Einschätzung.

Demnach hat ein erheblicher Teil der befragten Industrieunternehmen nach eigener Aussage wenig bis keine Kenntnis der konkreten CRA-Anforderungen. Parallel dazu äußert ein relevanter Anteil der Unternehmen Sorge, die verbleibende Zeit bis zur vollständigen CE-Kennzeichnungspflicht 2027 nicht rechtzeitig zu nutzen. Am konkretesten wird der Befund bei der 24-Stunden-Meldefrist: Für einen Großteil der befragten Unternehmen stellt sie eine erhebliche organisatorische Hürde dar, weil sie belastbare interne Prozesse für Schwachstellenerkennung, Eskalation und Freigabe voraussetzt, die in vielen mittelständischen Organisationen schlicht noch nicht existieren.

Die Einordnung, die sich daraus für KI-Anbieter und -Betreiber ableiten lässt, ist eindeutig: Meldeprozesse, klare Verantwortlichkeiten und ein kontinuierliches Schwachstellen-Monitoring müssen jetzt stehen – nicht erst im Vorfeld der vollen Anwendung 2027. Wer heute erstmals von einer aktiv ausgenutzten Schwachstelle in seiner KI-Software erfährt und keinen definierten Meldeprozess hat, verliert wertvolle Stunden der ohnehin knappen 24-Stunden-Frist allein mit der Frage, wer intern überhaupt zuständig ist.

Bemerkenswert an den kolportierten Zahlen ist weniger die absolute Höhe als die Verteilung: Es sind nicht in erster Linie Kleinstunternehmen ohne IT-Abteilung, die von der eigenen Unkenntnis überrascht wurden, sondern auch etablierte Industrieunternehmen mit gewachsenen, aber auf klassische IT-Sicherheit zugeschnittenen Prozessen. Der CRA verlangt keine neue Technologie, sondern eine neue Geschwindigkeit – und genau die Geschwindigkeit ist es, an der viele bestehende Meldewege aus dem klassischen Incident-Management scheitern, wenn sie unverändert auf die 24-Stunden-Frist übertragen werden.

Was On-Premise-KI-Betreiber jetzt konkret tun sollten

Aus der Beratungspraxis heraus lässt sich der Handlungsbedarf auf sechs konkrete Schritte herunterbrechen, die sich unabhängig von Unternehmensgröße umsetzen lassen:

1. Inventar aller vernetzten KI-Komponenten und -Produkte führen. Welche Modelle, Frameworks und Middleware-Komponenten sind im Einsatz, welche davon sind vernetzt, welche werden als Produkt an Dritte vertrieben? In vielen Unternehmen existiert diese Liste bislang nur in den Köpfen einzelner Entwickler – ein zentrales, gepflegtes Register ist die Grundvoraussetzung für jeden der folgenden Schritte.
2. SBOM für eingesetzte Open-Source-KI-Stacks aufbauen. Eine Software Bill of Materials schafft die Grundlage, um bei einer neu bekannt gewordenen Schwachstelle in wenigen Minuten statt Tagen zu wissen, ob und wo man betroffen ist. Für KI-Stacks gehören dazu nicht nur klassische Bibliotheken, sondern auch Modellgewichte, Tokenizer und die verwendeten Versionen von Inferenz- und Orchestrierungs-Frameworks.
3. Internen Meldeprozess mit klaren Verantwortlichkeiten definieren. Wer entscheidet innerhalb welcher Zeit über die Einstufung als „aktiv ausgenutzt", wer formuliert die Frühwarnung, wer reicht sie über welchen Kanal ein? Das muss vor dem Ernstfall feststehen, nicht während der laufenden 24-Stunden-Uhr. Eine schriftliche Eskalationsmatrix mit Vertretungsregelung für Urlaubs- und Krankheitszeiten gehört ausdrücklich dazu.
4. Kontinuierliches Schwachstellen-Monitoring etablieren. CVE-Feeds für die eingesetzten Modelle, Frameworks und Bibliotheken laufend auswerten, statt sich auf sporadische manuelle Prüfungen zu verlassen. Ein automatisierter Abgleich zwischen SBOM und CVE-Datenbank reduziert die Zeit von „Schwachstelle bekannt" bis „eigene Betroffenheit geklärt" von Tagen auf Stunden.
5. Zusammenspiel mit bestehenden AI-Act-Compliance-Prozessen dokumentieren. Wo CRA- und AI-Act-Meldewege parallel laufen, sollte dokumentiert sein, welcher Vorfall welchen Prozess auslöst – idealerweise mit einem gemeinsamen internen Erstkontaktpunkt, der beide Fristenregime im Blick behält und doppelte Meldearbeit vermeidet.
6. Vorteil kontrollierter On-Premise-Architekturen nutzen, ohne sich in falscher Sicherheit zu wiegen. Eine kleinere, besser kontrollierte Angriffsfläche verringert das Eintrittsrisiko spürbar – die Meldepflicht bleibt jedoch bestehen, sobald das Produkt vermarktet oder vernetzt betrieben wird. On-Premise ersetzt kein Schwachstellenmanagement, es macht dessen Ergebnisse nur belastbarer, weil die relevanten Systeme unter eigener Kontrolle stehen.

Roadmap bis 2027: Von der Meldepflicht zur vollen CRA-Konformität

Der 11. September 2026 ist der erste, aber bei Weitem nicht der letzte Stichtag. Ab dem 11. Dezember 2027 gelten die vollständigen CRA-Hauptpflichten: grundlegende Cybersicherheitsanforderungen über den gesamten Produktlebenszyklus hinweg, eine technische Dokumentation einschließlich Software Bill of Materials, eine formale Konformitätsbewertung sowie die CRA-Cybersicherheitskomponente der CE-Kennzeichnung. Ohne diese CE-Konformität dürfen betroffene vernetzte Produkte – ausdrücklich auch solche mit KI-Komponenten – ab diesem Datum nicht mehr in der EU vermarktet werden.

Zwischen dem jetzigen Meldepflicht-Stichtag und der vollen Anwendung 2027 liegen gut 15 Monate, die sinnvoll genutzt werden sollten, um schrittweise aufzubauen, was ab Dezember 2027 verpflichtend nachgewiesen werden muss: ein vollständiges SBOM je Produktvariante, ein dokumentierter Secure-Development-Lifecycle, eine belastbare technische Dokumentation und – je nach Produktkategorie – die Einbindung einer notifizierten Konformitätsbewertungsstelle. Wer die jetzt bereits verpflichtenden Meldeprozesse und das Schwachstellen-Monitoring sauber aufsetzt, hat den arbeitsintensivsten Teil der Vorarbeit für 2027 bereits erledigt – die Konformitätsbewertung baut auf denselben Datenquellen auf.

Für KI-Anbieter kommt eine zusätzliche Dimension hinzu, die bei klassischer Hardware in dieser Form nicht existiert: Modelle und Adapter ändern sich häufiger als klassische Firmware-Versionen. Ein Wechsel des zugrunde liegenden Sprachmodells, ein Update des Inferenz-Frameworks oder das Nachladen eines neuen Adapters kann die Sicherheitseigenschaften eines Produkts spürbar verändern. Die technische Dokumentation und das SBOM, die der CRA ab 2027 verlangt, müssen deshalb als lebende Dokumente geführt werden, die bei jeder relevanten Modelländerung aktualisiert werden – nicht als einmalig erstelltes Compliance-Artefakt, das mit der Zeit veraltet.

Der Handlungsdruck ist dabei nicht abstrakt: Bei Nichteinhaltung der CRA-Pflichten drohen Bußgelder von bis zu 15 Millionen Euro oder alternativ 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Für ein Unternehmen mit dreistelligem Millionenumsatz kann allein die prozentuale Bemessungsgrundlage schnell den absoluten Höchstbetrag übersteigen. Einen breiteren Überblick über verwandte Fristen und Pflichten geben wir im Beitrag zum EU AI Act 2026.

Fazit: Meldepflicht ist der Realitätscheck vor der großen CRA-Welle

Der 11. September 2026 ist kein Randthema für klassische Hardware-Hersteller, sondern ein Weckruf für jeden, der vernetzte Software mit KI-Komponenten anbietet oder betreibt. Wer bislang ausschließlich den EU AI Act auf dem Schirm hatte, hat mit dem CRA einen zweiten, horizontal wirkenden Pflichtenkatalog übersehen, der bereits heute scharf geschaltet ist – nicht erst 2027.

Die naheliegende Konsequenz für KI-Anbieter und -Betreiber: CRA und AI Act nicht als zwei getrennte Projekte, sondern als ein zusammenhängendes Compliance-Paket denken, mit gemeinsamen Datenquellen für Inventar, SBOM und Vorfallmanagement. Wer diesen Zusammenhang jetzt herstellt, spart sich 2027 die doppelte Arbeit – und übersteht den nächsten „Stresstest" mit einem funktionierenden Prozess statt mit einer Ad-hoc-Reaktion unter Zeitdruck.

Wenn Sie einordnen möchten, wo Ihre KI-Systeme und -Produkte im Zusammenspiel von CRA und AI Act stehen, unterstützen wir Sie mit einem strukturierten Readiness-Check – On-Premise, DSGVO-konform und auf Ihre konkrete Produktlandschaft zugeschnitten.

Quellen & Primärbelege

Alle Zahlen, Fristen und Angaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Quellen geprüft.

1. Boerse Express: CRA-Meldepflichten ab 11. September Existiert und bestätigt Meldepflichten ab 11.9.2026, 24h-Frist, sowie Praxisdaten zu Unternehmens-Unwissenheit (per WebFetch verifiziert).
2. Finanznachrichten: CRA-Readiness-Stresstest (TÜV Rheinland) Per WebSearch bestätigt: identischer Artikeltitel und Inhalt zum TÜV-Rheinland-Stresstest, inkl. 24h/72h-Fristenkaskade und Zitat von Stefan Eigler.
3. all-electronics: CRA-Pflichten ab September 2026 Per WebSearch bestätigt: deckt Meldepflichten, betroffene Produkte und Zeitplan bis 2027 ab.
4. CMS Law: Cybersicherheit Hochrisiko-KI und CRA Per WebSearch bestätigt: existiert, behandelt genau die Schnittstelle AI-Act-Cybersicherheitsanforderungen (Art. 15) und CRA-Konformitätsbewertung.
5. BSI-Pressemitteilung: CRA-Meldepflicht startet (11.9.2026) Zusätzliche Behördenquelle zur Bestätigung der Meldepflicht.

Häufig gestellte Fragen zum CRA und zur Meldepflicht

Ab wann gelten die ersten CRA-Meldepflichten und wen betreffen sie?

Seit dem 11. September 2026 müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an die zuständigen Behörden (CSIRT/ENISA-Meldeplattform) melden. Betroffen sind Hardware- und Softwarehersteller gleichermaßen - explizit eingeschlossen ist Software mit KI-Komponenten, etwa LLM-basierte Anwendungen, KI-Agenten oder KI-gestützte Steuerungssoftware, sofern sie über Netzwerke oder Schnittstellen mit anderen Geräten verbunden ist.

Welche Fristen gelten für die Meldung einer Schwachstelle oder eines Sicherheitsvorfalls?

Der CRA sieht ein gestuftes Meldeverfahren vor: eine Frühwarnung binnen 24 Stunden nach Kenntnisnahme, eine detailliertere Meldung binnen 72 Stunden sowie ggf. einen Abschlussbericht. Für viele mittelständische Hersteller ist gerade die 24-Stunden-Frist eine erhebliche organisatorische Hürde, da sie belastbare interne Prozesse für Schwachstellenerkennung und Eskalation voraussetzt.

Was hat der Cyber Resilience Act mit dem EU AI Act zu tun?

Beide Regelwerke überschneiden sich bei KI-Software: Der AI Act verlangt in Artikel 15 von Hochrisiko-KI-Systemen ein angemessenes Cybersicherheitsniveau, während der CRA für Produkte mit digitalen Elementen horizontale Basisanforderungen an Schwachstellenmanagement und Meldewesen definiert. Für Hersteller, deren KI-System zugleich ein 'Produkt mit digitalen Elementen' ist, greifen beide Pflichtenkataloge parallel - die CRA-Konformitätsbewertung soll die AI-Act-Cybersicherheitsanforderungen mit abdecken.

Was ändert sich für Unternehmen zum 11. Dezember 2027?

Ab dem 11. Dezember 2027 gelten die vollständigen CRA-Hauptpflichten: grundlegende Cybersicherheitsanforderungen über den gesamten Produktlebenszyklus, technische Dokumentation inklusive Software Bill of Materials (SBOM), eine formale Konformitätsbewertung sowie die CRA-Cybersicherheitskomponente der CE-Kennzeichnung. Ohne diese CE-Konformität dürfen betroffene vernetzte Produkte - auch mit KI-Komponenten - dann nicht mehr in der EU vermarktet werden.