CRA für KI- & ML-Produkte

KI im Produkt heißt: Der CRA gilt neben dem AI Act

Wer heute ein Gerät mit On-Device-Inferenz, einen ML-gestützten Regler, einen KI-Assistenten in der Firmware oder eine Kamera mit Objekterkennung in der EU auf den Markt bringt, verkauft aus Sicht des Cyber Resilience Act (Verordnung (EU) 2024/2847) grundsätzlich ein Produkt mit digitalen Elementen (PDE). Die KI-Fähigkeit macht das Produkt nicht zu einem Sonderfall - sie verschärft die Fragen, die der CRA ohnehin stellt: Wie sicher ist die Software? Woher stammen die Abhängigkeiten? Wie lange wird gepatcht? Der Reflex „für uns ist doch der AI Act zuständig" ist gefährlich unvollständig.

Der reale Schmerz dieser Branche ist die Doppelbelastung bei gleichzeitig unscharfer Faktenlage. Teams, die ihr Modell trainieren, feintunen oder aus dem Open-Source-Ökosystem (Hugging Face, PyTorch, ONNX Runtime) beziehen, brauchen eine verlässliche Antwort auf drei Fragen: Ist unser KI-Produkt überhaupt ein PDE? Gehört das Modell in die SBOM? Und wie verhält sich das alles zum AI Act, der parallel umzusetzen ist? Dazu kommen KI-eigene Angriffsflächen - Prompt-Injection, Modell-Extraktion, Data-Poisoning, adversariale Eingaben - die in klassischen Software-Sicherheitsprozessen schlicht nicht vorgesehen sind.

Blackfort Technology arbeitet genau an dieser Schnittstelle: Das Unternehmen wirkt im Expertenkreis KI-Sicherheit der Allianz für Cyber-Sicherheit mit und hat am dort erschienenen Leitfaden für Penetrationstests von Large Language Models mitgewirkt. Ein amtliches Mandat ist das nicht. Dieser Text ordnet Ihre Situation schematisch ein und ersetzt keine Rechtsberatung im Einzelfall.

Wann ein KI-/ML-Produkt ein PDE ist - und welche Anhang-Klasse wahrscheinlich greift

Faustregel: Ein Produkt ist grundsätzlich erfasst, wenn es im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird und sein bestimmungsgemäßer Zweck oder seine vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt (Art. 2 Abs. 1) - unabhängig davon, ob das Modell lokal (On-Device) oder in einer Companion-App läuft. Rein extern gehostete KI-Dienste (SaaS-Inferenz ohne mitgeliefertes Produkt) sind gesondert einzuordnen, u. a. über den AI Act. KI-Produkte ohne Anhang-III- oder Anhang-IV-Funktion fallen in die Standard-Kategorie und werden per Selbstbewertung (Modul A) bewertet. Für die Einstufung zählt die Funktion des Produkts nach Anhang III/IV; ob KI verbaut ist, spielt dafür keine Rolle.

Die technischen Beschreibungen der wichtigen und kritischen Kategorien stehen in der Durchführungsverordnung (EU) 2025/2392. Die KI-Komponente ändert die Klasse nicht - sie erhöht aber den Nachweisaufwand innerhalb der jeweiligen Klasse.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Für die Software-Sicherheit gelten die CRA-Anhang-I-Anforderungen; harmonisierte Normen zum CRA sind beauftragt (M/606), am 9. Oktober 2026 aber noch nicht im Amtsblatt veröffentlicht. Für die SBOM ist BSI TR-03183-2 (v2.1.0) eine verbreitete technische Referenz. KI-spezifisch wird ein „AI-BOM/Model-BOM" als Erweiterung der klassischen SBOM diskutiert. Wichtig ist die saubere Trennung der Regime:

• AI Act (VO (EU) 2024/1689): gilt neben dem CRA und adressiert Risiken der KI-Nutzung - Hochrisiko-Klassifizierung, Transparenz, Daten-Governance. Für Hochrisiko-KI-Systeme verknüpft Art. 12 CRA beide: Wer Anhang I erfüllt und das in der EU-Konformitätserklärung nachweist, erfüllt insoweit die Cybersicherheitsanforderungen von Art. 15 AI Act, und die Konformitätsbewertung richtet sich grundsätzlich nach Art. 43 AI Act; wichtige und kritische Produkte, für die nach dem AI Act nur eine interne Kontrolle vorgesehen wäre, bleiben bei den CRA-Verfahren (Art. 12 Abs. 3). Die Cybersicherheits-Risikobewertung kann Teil der Risikobewertung nach dem AI Act sein (Art. 13 Abs. 4).
• CRA: adressiert die Cybersicherheit des Produkts - Security-by-Design, Schwachstellen-Handling, SBOM. Das ist die Ebene, auf der „ist das Modell verwundbar?" gehört.
• RED-Delegierte-VO 2022/30: relevant, wenn Ihr KI-Gerät funkfähig ist und über das Internet kommunizieren kann; hier kann es bis zur Aufhebung der VO zum 11.12.2027 zur Überlappung mit dem CRA kommen, die abzugrenzen ist.
• NIS2 / DORA: betreffen Einrichtungen (wesentliche/wichtige Einrichtungen bzw. Finanzsektor), nicht die Produkt-Herstellerpflicht. Hersteller elektronischer Erzeugnisse können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Nicht mit dem CRA gleichsetzen.
• Ausnahmen: Ausgenommen sind Produkte, auf die MDR, IVDR oder die Typgenehmigungsverordnung (EU) 2019/2144 Anwendung finden, nach der Verordnung (EU) 2018/1139 zertifizierte Luftfahrtprodukte und Schiffsausrüstung (Art. 2 Abs. 2 bis 4) - wer ein KI-Diagnosegerät nach MDR baut, unterliegt hier nicht dem CRA.

SBOM- und Lieferketten-Realität: das Modell ist eine Abhängigkeit

Der typische KI-Stack besteht aus mehr als Ihrem eigenen Code: vortrainierte Modelle und Gewichte, ML-Frameworks (PyTorch, TensorFlow), Inferenz-Runtimes (ONNX Runtime, TensorRT), Tokenizer, Datenpipelines und ein tiefer Baum an Python-Abhängigkeiten. Jedes dieser Elemente ist eine Software-Abhängigkeit mit eigenem Schwachstellen- und EOL-Risiko - ein aufgegebenes OSS-Framework oder eine Modellversion mit bekannter Vergiftung ist genauso ein Supply-Chain-Problem wie eine veraltete C-Bibliothek.

Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1), als Teil der technischen Dokumentation - eine allgemeine Veröffentlichungspflicht besteht nicht. Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. Für KI-Produkte ist es sinnvoll, Modell, Gewichte und Framework mit Herkunft (Provenance), Version und bekannten Schwachstellen zu führen. CycloneDX unterstützt hierfür bereits ML-/AI-Komponententypen; die genaue Ausgestaltung des AI-BOM konkretisiert sich noch. Wer das früh aufsetzt, hat die Stückliste bis zum 11.12.2027 im Regelbetrieb.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade richtig verstanden

Seit dem 11.09.2026 gelten die Melde- und Berichtspflichten nach Art. 14, die erste harte Herstellerpflicht. Wird eine aktiv ausgenutzte Schwachstelle oder ein schwerwiegender Sicherheitsvorfall bekannt (bei KI-Produkten etwa ein ausgenutzter Prompt-Injection-Pfad, eine Modell-Extraktion oder eine kompromittierte Update-Pipeline), läuft folgende Kaskade über die einheitliche Meldeplattform (Art. 16), über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat Ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, bei aktiv ausgenutzter Schwachstelle.
• 1 Monat - Abschlussbericht nach der 72-h-Meldung, bei einem schwerwiegenden Sicherheitsvorfall.

Die pauschale Verkürzung auf „24h/72h/14 Tage" ist falsch - der Abschluss unterscheidet zwischen Schwachstelle (14 Tage) und Vorfall (1 Monat). Praktisch braucht Ihr Haus dafür einen PSIRT-/CVD-Prozess: einen definierten Eingangskanal, ein Triage-Team, das KI-spezifische Meldungen bewerten kann, und geprobte Abläufe für Frühwarnung und Meldung über den gesamten Unterstützungszeitraum (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8).

Fristen: was zuerst kommt

Zwei Daten strukturieren Ihre Roadmap. Seit dem 11.09.2026 greift die Melde-/Berichtspflicht (Art. 14); PSIRT, CVD-Policy und die Anbindung an die einheitliche Meldeplattform müssen also bereits stehen. Am 11.12.2027 folgen die vollen Produktanforderungen (Security-by-Design, SBOM, technische Dokumentation, CE-Kennzeichnung, Konformitätsbewertung). Zuerst also die Meldefähigkeit, dann die volle Produkt-Compliance - wobei SBOM und Threat-Model so viel Vorlauf brauchen, dass beides parallel begonnen gehört. Die technische Dokumentation ist mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum aufzubewahren (Art. 13 Abs. 13).

Durchgespieltes Szenario: Hersteller einer smarten Inspektionskamera

Ein mittelständischer Hersteller bringt eine Industriekamera mit On-Device-Objekterkennung auf den Markt; das Modell basiert auf einem vortrainierten OSS-Netz, läuft über die ONNX Runtime und wird per OTA-Update versorgt. Die Funktion ist keine Kategorie nach Anhang III - das Produkt ist Standard und wird per Modul A selbstbewertet. Der Hersteller erstellt eine CycloneDX-1.6-SBOM, die neben dem Firmware-Stack auch ML-Runtime und Modellversion mit Provenance führt. Im Threat-Model bewertet er adversariale Eingaben (manipulierte Bilder), Data-Poisoning des Update-Pfads und Modell-Extraktion und leitet daraus Härtungsmaßnahmen ab. Er richtet einen PSIRT-Eingang und eine CVD-Policy ein, probt die Kaskade (Frühwarnung unverzüglich, spätestens nach 24 Stunden, Meldung spätestens nach 72 Stunden) und plant Modell- wie Framework-Sicherheitsupdates über den gesamten Unterstützungszeitraum. Bekommt eine ONNX-Runtime-Version eine aktiv ausgenutzte Schwachstelle, greift seit September 2026 exakt diese Kaskade. Parallel prüft er die AI-Act-Einordnung getrennt und stimmt beide Nachweise aufeinander ab.

Was Blackfort für Sie tut

Blackfort Technology begleitet KI-/ML-Hersteller und -Importeure entlang der gesamten CRA-Kette, mit Erfahrung aus der Mitarbeit am Leitfaden für Penetrationstests von Large Language Models der Allianz für Cyber-Sicherheit:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, ob Ihr KI-Produkt ein PDE ist, welche Anhang-Klasse plausibel ist und wo CRA und AI Act ineinandergreifen.
• SBOM-/AI-BOM-Setup: maschinenlesbare SBOM, etwa in CycloneDX oder SPDX, inklusive Modell, Gewichten und Frameworks.
• PSIRT & CVD: Meldeprozesse und Art.-14-Kaskade, geprobt und an die einheitliche Meldeplattform angebunden.
• Risikobewertung & Threat-Modeling: inklusive KI-eigener Bedrohungen (Prompt-Injection, Poisoning, Modell-Extraktion), gestützt auf unsere Mitarbeit am Leitfaden der Allianz für Cyber-Sicherheit.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13).

Starten Sie mit der Betroffenheits-Analyse, lesen Sie die Grundlagen im CRA-Überblick und den KMU-Leitfaden - oder sprechen Sie uns direkt an über Kontakt.