CRA für KI- & ML-Produkte

KI im Produkt heißt: Der CRA gilt — zusätzlich, nicht statt 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) in aller Regel 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 verbreitete 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, haben oft keine belastbare 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, den viele Häuser parallel gerade erst umsetzen? 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. Christian Gebhardt ist Mitglied der ACS-KI-Facharbeitsgruppe und Mitautor eines öffentlichen Leitfadens zum Pentest von LLMs — inhaltliche Autorität an der Naht zwischen Produktsicherheit und KI, kein amtliches Mandat. 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: Sobald KI/ML als Software Teil eines auf dem EU-Markt bereitgestellten Produkts mit direkter oder indirekter Datenverbindung ist, greift der CRA voraussichtlich — 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. Die meisten KI-Produkte fallen in die Standard-Kategorie und werden per Selbstbewertung (Modul A) konform gemacht. Entscheidend für die Einstufung ist nicht „ist KI drin", sondern die Funktion des Produkts nach Anhang III/IV.

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 und die noch entstehenden harmonisierten Normen; für die SBOM ist BSI TR-03183-2 (v2.1.0) die maßgebliche technische Referenz. KI-spezifisch verdichtet sich der Fachkonsens auf ein „AI-BOM/Model-BOM" als Erweiterung der klassischen SBOM. Wichtig ist die saubere Trennung der Regime:

• AI Act (VO (EU) 2024/1689): adressiert Risiken der KI-Nutzung — Hochrisiko-Klassifizierung, Transparenz, Daten-Governance. Getrennter Rechtsakt, gilt parallel zum CRA. Ein KI-Produkt kann beiden unterliegen; die Nachweise sind zu koordinieren, nicht zu verschmelzen.
• 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; hier kann es zur Überlappung mit dem CRA kommen, die abzugrenzen ist.
• NIS2 / DORA: betreffen Betreiber (wesentliche/wichtige Einrichtungen bzw. Finanzsektor), nicht die Produkt-Herstellerpflicht. Nicht mit dem CRA gleichsetzen.
• Ausnahmen: KI in MDR/IVDR-Medizinprodukten, in der Kfz-Typgenehmigung, ziviler Luftfahrt oder Schiffsausrüstung ist vom CRA ausgenommen — 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.

Die maschinenlesbare SBOM muss nach CRA (Anhang I) und BSI TR-03183-2 in CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1 vorliegen, mindestens die Top-Level-Abhängigkeiten abbilden und Teil der technischen Dokumentation sein — eine allgemeine Veröffentlichungspflicht besteht nicht. Für KI-Produkte heißt das konkret: Modell, Gewichte und Framework mit Herkunft (Provenance), Version und bekannten Schwachstellen führen. CycloneDX unterstützt hierfür bereits ML-/AI-Komponententypen; die genaue Ausgestaltung des AI-BOM konkretisiert sich noch. Wer das jetzt sauber aufsetzt, muss es 2027 nicht nachrüsten.

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

Ab dem 11.09.2026 gelten die Melde- und Berichtspflichten nach Art. 14 — die erste harte Herstellerpflicht. Wird eine aktiv ausgenutzte Schwachstelle oder ein schwerer Sicherheitsvorfall bekannt (bei KI-Produkten typischerweise ein ausgenutzter Prompt-Injection-Pfad, eine Modell-Extraktion oder eine kompromittierte Update-Pipeline), läuft folgende Kaskade über die ENISA Single Reporting Platform:

• 24 Stunden — Frühwarnung ab Kenntnisnahme.
• 72 Stunden — vollständige Meldung inkl. Korrektur- bzw. Minderungsmaßnahmen.
• 14 Tage — Abschlussbericht nach Verfügbarkeit einer Korrekturmaßnahme, bei aktiv ausgenutzter Schwachstelle.
• 1 Monat — Abschlussbericht nach der 72-h-Meldung, bei einem schweren 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 24/72-Stunden-Abläufe über den gesamten Support-Zeitraum (Leitlinie mindestens fünf Jahre, orientiert an der erwarteten Produktlebensdauer).

Fristen: was zuerst kommt

Zwei Daten strukturieren Ihre Roadmap. Am 11.09.2026 greift die Melde-/Berichtspflicht (Art. 14) — PSIRT, CVD-Policy und die Anbindung an die SRP müssen dann 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.

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 Sicherheitsfunktion 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 24/72-Stunden-Kaskade und plant Modell- wie Framework-Sicherheitsupdates über mindestens fünf Jahre. Bekommt eine ONNX-Runtime-Version eine aktiv ausgenutzte Schwachstelle, greift ab September 2026 exakt diese Kaskade. Parallel prüft er die AI-Act-Einordnung getrennt — beides koordiniert, nichts vermischt.

Was Blackfort für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet KI-/ML-Hersteller und -Importeure entlang der gesamten CRA-Kette — mit dem seltenen Zusatz echter KI-Sicherheitskompetenz:

• Betroffenheits- und Scope-Analyse: Ist Ihr KI-Produkt ein PDE, welche Anhang-Klasse ist plausibel, wo endet CRA und beginnt AI Act?
• SBOM-/AI-BOM-Setup: maschinenlesbare SBOM in CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1 inklusive Modell, Gewichten und Frameworks.
• PSIRT & CVD: Meldeprozesse und Art.-14-Kaskade, geprobt und SRP-ready.
• Risikobewertung & Threat-Modeling: inklusive KI-eigener Bedrohungen (Prompt-Injection, Poisoning, Modell-Extraktion) — auf Basis der ACS-KI-/LLM-Pentest-Expertise.
• Technische Dokumentation: Anhang-I-konform, prüffest, 10 Jahre aufbewahrbar.

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.