Der Agent hat grün. Wer unterschreibt? KI-Governance für Hersteller von KRITIS-Software

Seit dem 11. September 2026 muss jeder Hersteller, dessen Software als Produkt mit digitalen Elementen in der EU auf dem Markt ist, eine aktiv ausgenutzte Schwachstelle innerhalb von 24 Stunden als Frühwarnung über die einheitliche Meldeplattform der ENISA melden. Das gilt auch für Software, die seit zehn Jahren in einer Leitwarte läuft. Nach 72 Stunden folgt die ausführliche Meldung, spätestens 14 Tage nach Verfügbarkeit einer Abhilfe der Abschlussbericht. Bei Herstellern mit Hauptniederlassung in Deutschland landen die Meldungen beim BSI, das nach dem geplanten Durchführungsgesetz auch die Marktüberwachung nach dem Cyber Resilience Act (CRA) übernehmen soll.

Für Hersteller, die ihre Software mit KI-Agenten entwickeln oder KI-Funktionen ins Produkt einbauen, beginnt mit dieser Meldepflicht die KI-Governance. Die Frist läuft gleich, ob ein Mensch oder ein Agent den fehlerhaften Code geschrieben hat. Beim Netzbetreiber wird aus einem Softwarefehler schnell ein Fehler im Stromnetz.

CRA, AI Act und NIS-2 treffen denselben Hersteller

Vereinfacht schützt der CRA das Produkt, der AI Act die Betroffenen und NIS-2 den Betrieb. Wer Software für Betreiber kritischer Infrastruktur herstellt, hat mit allen drei zu tun. NIS-2 richtet sich an Organisationen und nicht an Produkte. Die Netzbetreiber reichen ihre Pflichten aber über die Lieferkette weiter, und wer an Stadtwerke liefert, findet sich in deren Ausschreibungen als Nachweispflichtiger wieder.

Beim AI Act hat der Gesetzgeber im Sommer mehr Zeit gegeben. Seit dem 27. Juli 2026 gilt der Digital Omnibus (Verordnung (EU) 2026/1744). Die Hochrisiko-Pflichten nach Anhang III, zu denen KI als Sicherheitsbauteil kritischer Infrastruktur zählt, greifen damit ab dem 2. Dezember 2027, für KI in regulierten Produkten nach Anhang I ab dem 2. August 2028. Die Anforderungen an Risikomanagement, Protokollierung, Transparenz, menschliche Aufsicht und Robustheit (Artikel 9 und 12 bis 15) bleiben unverändert. Bei Daten-Governance (Artikel 10) und technischer Dokumentation (Artikel 11, vereinfachte Angaben für KMU und kleine Midcap-Unternehmen) gibt es Erleichterungen in Einzelpunkten.

Mit der ersten KI-Funktion wird der Hersteller zum Anbieter

Für einen klassischen Softwarehersteller ist die Anbieterrolle die teuerste Stelle im AI Act. Sobald GIS-, Asset- oder Netzsoftware eine KI-Funktion ausliefert, trägt der Hersteller nach dem AI Act die Pflichten eines Anbieters, auch wenn die Funktion auf einem zugekauften Modell beruht. Wer ein zugekauftes Hochrisiko-KI-System wesentlich ändert oder unter eigenem Namen vertreibt, wird ebenfalls zum Anbieter. Ob daraus Hochrisiko-Pflichten folgen, hängt an der Abgrenzung zwischen Sicherheitsbauteil und Unterstützung. Mit einer KI, die Instandhaltungsmaßnahmen priorisiert, lebt es sich regulatorisch anders als mit einer KI, die in die Netzführung eingreift.

Ein weiterer Termin fehlt in vielen Roadmaps. Für alles, was nach dem 9. Dezember 2026 in Verkehr gebracht wird, gilt Software nach der neuen EU-Produkthaftungsrichtlinie als Produkt. Der Hersteller haftet dann auch für Fehler, die auf ein fehlendes Sicherheitsupdate zurückgehen, soweit das Update in seiner Hand liegt. Ersatz gibt es nach der Richtlinie allerdings nur für Schäden natürlicher Personen, und Sachen, die ausschließlich beruflich genutzt werden, sind ausgenommen. Für Schäden beim Netzbetreiber selbst bleibt deshalb der Vertrag maßgeblich. Bei Wartungsverträgen über fünfzehn Jahre stellt sich damit eine unangenehme Frage: Was sichert man für eine Funktion zu, deren Modell der Anbieter im Hintergrund austauscht?

Entwickler schätzten sich mit KI schneller ein, als sie waren

Die zweite Baustelle ist die eigene Entwicklung. In der METR-Studie von 2025 schätzten sich erfahrene Open-Source-Entwickler mit KI-Unterstützung im Nachhinein um 20 % schneller ein, gemessen brauchten sie 19 % länger. Die Werkzeuge sind seitdem besser geworden. Eine belastbare neue Messung fehlt. Im Februar 2026 hat METR angekündigt, das Design der Folgestudie zu ändern. Die neuen Daten hielt METR für verzerrt, unter anderem weil viele Entwickler nicht mehr ohne KI arbeiten wollten.

Der DORA-Report 2025 von Google (DevOps Research and Assessment, nicht die gleichnamige EU-Verordnung) beschreibt KI als Verstärker des Engineering-Systems, in dem sie läuft. Ein gutes System wird besser, in einem schwachen verschärfen sich die vorhandenen Probleme. Code erzeugt der Agent in Sekunden, die Prüfung dauert so lange wie vorher. In der Entwicklerumfrage von Sonar vom Januar 2026 ist Sicherheit die größte Sorge: 57 % fürchten, dass KI sensible Unternehmens- oder Kundendaten offenlegt. Von den Befragten, deren Team KI-Agenten nutzt, setzen aber nur 28 % die Agenten zum Schließen von Sicherheitslücken ein. Bei KRITIS-Software bestimmt deshalb die Prüfkapazität das Tempo der Entwicklung.

Vier Bausteine für KI-Governance in der Pipeline

Wirksame KI-Governance steckt in der Build- und Release-Pipeline. Dafür empfehlen wir vier Bausteine.

• Autonomie je Produkt begrenzen. Bei einer internen Reporting-App darf ein Agent selbst mergen. Bei der Netzleitsoftware schreibt er höchstens einen Merge Request, den ein Mensch freigibt. Sensible Code-Pfade werden grundsätzlich nicht automatisch gemergt, und jede Änderung der Autonomiestufe landet im Audit-Log.

• Freigaben messen. KI-Funktionen streuen in ihren Ergebnissen. Eine Freigabe braucht deshalb Eval-Datensätze mit Schwellwerten, und jeder Wechsel von Modell, Prompt oder Daten gilt als Release.

• Modelle austauschbar halten. Ein Gateway, Versionspinning und ein Fallback-Modell sorgen dafür, dass die Abkündigung eines Modells beim Anbieter nicht zum Wartungsfall beim Kunden wird.

• Das PSIRT auf KI ausrichten. Eine ausnutzbare Prompt Injection ist eine Schwachstelle. Wird sie aktiv ausgenutzt, gilt die 24-Stunden-Frist des CRA. Im Vorwort der KI-Sicherheitsstudie 2026 von BSI und TÜV-Verband, vorgestellt am 7. Oktober 2026, schreibt TÜV-Verbandspräsident Dirk Stenkamp, klassische IT-Sicherheit sei auf die neuen Bedrohungen durch KI nicht ausreichend ausgelegt.

Als organisatorischer Rahmen eignet sich ISO/IEC 42001 mit einem KI-Inventar, das jede Funktion einer Risikoklasse zuordnet. Im Kern ist das eine Tabelle mit drei Spalten: in welcher Funktion KI steckt, welche Rolle der Hersteller nach dem AI Act hat und welche Frist gilt.

Die Frage für die nächste GF-Runde

Bis zum 2. Dezember 2027 sollte jeder Hersteller für jede KI-Funktion klären, ob sie ein Sicherheitsbauteil ist und wer die Freigabe unterschreibt, wenn der Agent grünes Licht gibt. Diese Unterschrift leistet ein Mensch mit Namen und Rolle. Fällt der Hersteller selbst unter NIS-2, etwa als Anbieter von Cloud- oder Managed Services, haftet seine Geschäftsleitung nach § 38 BSIG dem eigenen Unternehmen für schuldhaft verursachte Schäden, wenn sie das Risikomanagement nicht umsetzt oder nicht überwacht.