NIS2 und Coding Agents: Was Teams jetzt dokumentieren müssen

Coding Agents sind längst Teil der Softwareentwicklung. Richtig eingesetzt, beschleunigen sie Entwicklung, Reviews und Sicherheitsarbeit. Sie lesen private Repositories, schlagen Änderungen vor, erstellen Pull Requests und unterstützen Security-Reviews. Unter NIS2 reicht dafür aber nicht mehr, dass einzelne Entwickler gute Ergebnisse erzielen. Teams müssen zeigen können, dass Agenten kontrolliert, nachvollziehbar und sicher in den Entwicklungsprozess eingebunden sind.

Das Gesetz nennt keine KI-Coding-Agents. Entscheidend ist aber nicht der Produktname, sondern die Funktion. Wer nach NIS2 betroffen ist, muss nachweisen können, dass Anbieter, Datenflüsse, Zugriffsrechte, Reviews und Sicherheitsmaßnahmen im Griff sind.

Der praktische Maßstab dafür ist § 30 BSIG: Lieferkettensicherheit, sichere Entwicklung und Wirksamkeitsbewertung. Dieser Artikel zeigt, was das für Teams konkret heißt.

Kurz gefasst: Teams sollten Coding Agents inventarisieren, Anbieter prüfen, Repository-Rechte begrenzen, Datenflüsse dokumentieren und KI-Code durch mindestens dieselben Sicherheitsprüfungen schicken wie menschlichen Code, mit einem benannten menschlichen Verantwortlichen für jeden Agenten-Pull-Request, nicht nur einem Leser. Entscheidend ist nicht, ob ein Agent schon ausdrücklich als „Diensteanbieter“ eingestuft wurde. Entscheidend ist, ob das Unternehmen seine Kontrollen belegen kann: Lieferantenprüfung, Berechtigungskonzept, CI-Scans, menschliche Reviews, Metriken und Ausstiegsplan.

Wer die regulatorische Dimension neben den übrigen Teilen einer Coding-Agent-Einführung einordnen will, findet im Leitfaden zur Governance von Coding Agents im Team Werkzeuge, Kennzahlen, Abläufe und Einführung im Zusammenhang.

Was das nicht heißt: NIS2 verbietet Coding Agents nicht, und ihr Einsatz wird auch nicht von selbst zum Compliance-Problem. Kritisch wird es erst, wenn Agenten private Repositories lesen, Pull Requests erstellen, Sicherheitsbefunde verarbeiten oder CI/CD-Kontext nutzen, ohne dass Rechte, Reviews und Nachweise geregelt sind.

Wer ist betroffen?

Die erste Frage jedes technischen Entscheiders ist banal und entscheidend zugleich: Gilt das für uns? NIS2 erfasst Einrichtungen auf zwei sehr unterschiedlichen Wegen, und die Verwechslung der beiden ist die häufigste Fehlerquelle.

Direkt. Anlage 1 BSIG führt im Sektor Digitale Infrastruktur eine Reihe von Diensten namentlich auf: Managed Services Provider (MSP), Managed Security Services Provider (MSSP), Cloud-Computing-Dienste, Rechenzentrumsdienste und Content-Delivery-Netzwerke. SaaS ist dabei kein Sonderfall, sondern in NIS2-Erwägungsgrund 33 ausdrücklich als Ausprägung des Cloud-Modells genannt. Reine Auftragsentwicklung ohne eigenes Hosting und ohne Cloud-Angebot ist dagegen kein eigener NIS2-Sektor.

Mittelbar. Wer einen NIS2-pflichtigen Kunden hat, bekommt dessen Anforderungen vertraglich weitergereicht: ein anerkannter Standard wie ISO 27001 oder BSI-Grundschutz, Auditrechte und die Meldung von Sicherheitsvorfällen. So wird ein formal nicht betroffenes Softwarehaus faktisch in die Pflicht genommen, ohne je in Anlage 1 zu stehen. Wie viele Unternehmen das genau betrifft, lässt sich nicht belastbar beziffern. Sicher ist nur die Richtung: deutlich mehr als die direkt erfassten.

Schwellenwerte: „Wichtig“ wird eine Einrichtung in der Regel, wenn sie einer erfassten Einrichtungsart zuzuordnen ist und mindestens 50 Beschäftigte hat oder sowohl mehr als 10 Mio. Euro Jahresumsatz als auch mehr als 10 Mio. Euro Jahresbilanzsumme aufweist. „Besonders wichtig“ gilt in vielen Fällen ab 250 Beschäftigten oder bei mehr als 50 Mio. Euro Umsatz und zugleich mehr als 43 Mio. Euro Bilanzsumme (§ 28 BSIG). Daran hängt die Bußgeldobergrenze nach § 65 BSIG: bis zu 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes bei besonders wichtigen, bis zu 7 Mio. Euro oder 1,4 Prozent bei wichtigen Einrichtungen.

Für die Praxis ist die Unterscheidung am Ende weniger wichtig, als sie klingt. Beide Wege führen zur selben operativen Frage, und der Maßstab dafür steht in einem einzigen Paragrafen: § 30 BSIG.

Was § 30 BSIG praktisch verlangt

Für Coding Agents sind drei Nachweise zentral:

1. Lieferkette: Wer ist der Anbieter, welche Daten fließen ab, welche Subprozessoren sind beteiligt?
2. Sichere Entwicklung: Läuft KI-Code durch dieselben Prüfungen wie menschlicher Code?
3. Wirksamkeit: Misst das Team, ob diese Kontrollen funktionieren?

Diese drei Punkte lassen sich auf § 30 Abs. 2 Nr. 4, 5 und 6 BSIG zurückführen. Der Paragraf ist technologieoffen formuliert, und genau deshalb greift er auch dort, wo der Gesetzgeber 2023 noch nicht an autonome Agenten im Pull Request gedacht hat. Ein Wort entscheidet dabei über alles Weitere: Die Einhaltung der Maßnahmen ist zu dokumentieren. Nicht die Existenz einer Kontrolle zählt, sondern ihre Nachweisbarkeit. Eine Maßnahme, die Sie nicht belegen können, existiert für die Aufsicht nicht.

Ein Agent berührt alle drei Nachweise. Er liest Quellcode, erzeugt Pull Requests, verarbeitet Build-Informationen und greift in vielen Setups per MCP oder Plugin auf interne Systeme zu. Damit verändert er die Vertraulichkeit von Quellcode, die Integrität von Änderungen und die Verfügbarkeit von Review-Prozessen. Die praktische Frage lautet deshalb nicht „Darf KI Code schreiben?“, sondern: Kann das Unternehmen belegen, dass KI-Code denselben sicheren Entwicklungspfad durchläuft wie menschlicher Code, dass der Agent nur freigegebene Rechte nutzt und dass ein Modellausfall den Sicherheitsprozess nicht aushebelt? Das ist eine Nachweisfrage, keine Erlaubnisfrage. „Derselbe Pfad“ ist dabei das Minimum, nicht das Maximum: Ein Agenten-Pull-Request braucht zusätzlich einen benannten Menschen, der ihn verantwortet, nicht nur liest. Warum gerade diese Konstellation eine eigene Regel verlangt, zeigt der Beitrag dazu, wer im KI-Code-Review wen prüft.

Warum KI-Code zusätzliche Kontrollen braucht

Drei Befunde reichen, um die Notwendigkeit zu zeigen. Sie zeigen zugleich, warum es laufende Kontrollen braucht und keine einmalige Werkzeugentscheidung.

KI-Code kompiliert zuverlässig, ist aber nicht automatisch sicher. Veracode misst im Spring 2026 GenAI Code Security Update weiter eine Quote bestandener Sicherheitstests von rund 55 Prozent, während die Syntax-Korrektheit über 95 Prozent erreicht. Der Code läuft also zuverlässiger, die Sicherheitsqualität zieht aber nicht im selben Maß nach. In den Veracode-Daten schneidet Java besonders schwach ab. Gemessen wurde mit statischer Analyse an synthetischen Aufgaben, von einem Anbieter, der Sicherheitswerkzeuge verkauft. Das ist eher ein günstiger Messpunkt, nicht der schlimmste Fall.

Je realistischer gemessen wird, desto schlechter steht der Agenten-Code da. Auf echten Repositories fallen die Werte deutlich tiefer. CMU SusVibes meldet beim besten Agenten nur rund 10,5 Prozent sicheren Code, SecureVibeBench (ACL 2026, peer-reviewed) rund 23,8 Prozent „korrekt und sicher“, wobei Menschen weniger Schwachstellen einführten als die Agenten. Diese Werte messen andere Schwachstellenklassen als Veracode, die Richtung ist aber überall dieselbe.

Agenten bringen eigene Risiken mit. Sprachmodelle erfinden reproduzierbar Paketnamen, die es nicht gibt, gemessen wurden rund 5,2 Prozent halluzinierte Pakete bei kommerziellen und 21,7 Prozent bei offenen Modellen (USENIX Security 2025). Weil dieselbe Halluzination bei Wiederholung oft wiederkehrt, lässt sie sich vorab registrieren, ein Angriffspfad, den Seth Larson „Slopsquatting“ nennt. Eine allein dadurch ausgelöste Massen-Kompromittierung ist öffentlich bis 2026 nicht belegt, der Pfad selbst aber demonstriert. Dazu kommt die Angreifbarkeit der Agenten selbst: Adaptive Prompt-Injection-Angriffe erreichen gegen aktuelle Abwehr Erfolgsraten über 85 Prozent, bei über 30 dokumentierten CVEs quer über Claude Code, Copilot, Cursor und Codex.

Diese Befunde sprechen nicht gegen Coding Agents, sondern gegen ihren blinden Einsatz. Die gemeinsame Aussage ist nicht, dass eine einzelne Studie endgültig recht hat. Sie ist robuster: Funktionalität und Sicherheit fallen bei Agent-Code auseinander, unabhängig von Anbieter und Messmethode. Der professionelle Weg ist deshalb nicht Verzicht, sondern derselbe sichere Entwicklungspfad wie bei menschlichem Code: Review, Tests, Scans, Nachvollziehbarkeit. Genau dafür braucht es laufende Sicherheitskontrollen statt einer einmaligen Werkzeugentscheidung.

Ein Punkt gehört unmittelbar zu § 30 Abs. 2 Nr. 6: Neuere Modelle schneiden nicht sicherer ab, die Veracode-Werte verbessern sich über Modellgenerationen kaum. Das spricht klar gegen die Hoffnung „Das räumt die nächste Modellversion auf“. Es bleibt eine Kontrollschleife: laufend messen, ob die Kontrollen noch wirken, und nachjustieren. Sichere Softwareentwicklung mit Agenten ist deshalb ein Prozess, kein Beschaffungsvorgang.

Die Kontrollen, die Sie dokumentieren müssen

Hier liegt der praktische Kern. Jede Zeile verbindet eine Kontrolle mit ihrem Bezug zu § 30 und einem Nachweis, den Sie der Aufsicht vorlegen können. Das ist der Schritt von „wir machen DevSecOps“ zu „wir machen es nachweisbar so“.

Ist der Agent ein Diensteanbieter?

Hier liegt die ehrlichste Lücke des Themas. Es gibt keine öffentliche BSI-Verlautbarung, kein Urteil und keine etablierte deutsche Kommentarliteratur, die KI-Coding-Agents ausdrücklich als unmittelbare Anbieter oder Diensteanbieter nach § 30 Abs. 2 Nr. 4 einordnet. Rechtlich ist nicht entschieden, ob jeder Coding-Agent ein Diensteanbieter in diesem Sinne ist. Wer etwas anderes behauptet, verkauft Interpretation als Rechtslage.

Praktisch ist die Risikolinie trotzdem klar: Je tiefer ein cloudbasierter Agent in Repositories, Tickets, Sicherheitsbefunde oder CI/CD-Prozesse eingebunden ist, desto eher sollte er wie ein sicherheitsrelevanter Dienst in der Lieferkette behandelt werden. Haltbar ist deshalb der Satz: Ein solcher Agent sollte mindestens risikobasiert wie ein sicherheitsrelevanter Diensteanbieter geführt werden. Schlicht unbelegt, und in einer Prüfung wertlos, ist dagegen „NIS2 stuft Coding-Agents ausdrücklich als Lieferanten ein“.

Die beste verfügbare Übersetzung dessen, was die Lieferketten- und Entwicklungspflichten praktisch meinen, liefert die ENISA Technical Implementation Guidance v1.0 vom 26. Juni 2025. Sie verlangt einen sicheren Entwicklungsprozess mit in CI/CD integriertem SAST und DAST, eine Vulnerability-Disclosure-Policy, eine gestufte Lieferantenklassifizierung und vertragliche Auditrechte. Bindend ist das Dokument nicht, aber es zeigt die Richtung. Damit verschiebt sich die eigentliche Frage: nicht „Hat ein Gericht entschieden?“, sondern „Kann das Team belegen, dass es Agent, Anbieter, Datenfluss und Review-Prozess im Griff hat?“. Wer diesen Nachweis führt, steht für eine Prüfung deutlich besser da, ganz gleich, wie die Einordnung am Ende ausfällt.

Geschäftsleitung und Haftung

Nicht jeder IDE-Assistent braucht eine Vorstandsvorlage. Für die Governance relevant wird der Einsatz aber, sobald ein Agent private Repositories liest, Pull Requests erstellt, Sicherheitsbefunde verarbeitet, CI/CD-Kontext nutzt oder für sicherheitskritische Reviews eingesetzt wird. Dann gehört die Entscheidung in ISMS, Lieferanten- und Datenschutzprüfung und in die Management-Berichterstattung, nicht weil ein Tool eingeführt wird, sondern weil es das Risikoprofil der Organisation verändert.

§ 38 BSIG zieht die Verantwortung dafür nach oben: Die Geschäftsleitung muss die § 30-Maßnahmen umsetzen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen. „Das war Sache des Teams“ ist als Verteidigung schwächer geworden. Und der teure Befund in einer Prüfung ist selten „ihr habt kein Tool kontrolliert“. Er lautet „ihr könnt nicht belegen, dass ihr es kontrolliert habt“. NIS2-Compliance ist in diesem Punkt eine Bringschuld bei den Nachweisen, nicht bei den Absichten.

Nicht verwechseln: NIS2 ist hier der praktischere Hebel. Der AI Act macht ein Team, das Copilot, Cursor oder Claude Code nutzt, nicht automatisch zum Anbieter eines Hochrisiko-Systems; seine späteren Fristen gelten ohnehin erst ab dem 2. August 2027 für bestimmte Altmodelle und ab dem 2. August 2028 für in regulierte Produkte eingebettete Hochrisiko-Systeme, die GPAI-Pflichten gelten seit dem 2. August 2025 (Fristen der EU-Kommission). Die DSGVO greift bei personenbezogenen Daten in Prompts, Logs oder Tickets; was der Agent überhaupt sehen darf, ist eine eigene Architekturfrage. DORA, die EU-Verordnung zur digitalen operationalen Resilienz im Finanzsektor, ist vor allem für Finanzunternehmen relevant und liefert gute Vorlagen, um Anbieterabhängigkeiten zu steuern; was die Aufsicht dort konkret erwartet, ordnet der Beitrag zu BaFin, MaRisk und Coding Agents ein. Der CRA betrifft Produktsicherheit. Für Coding Agents im Alltag bleibt die praktische Frage meist § 30 BSIG.

Wenn das Modell verschwindet

Ein aktuelles Beispiel zeigt, warum Modellverfügbarkeit kein Detail ist: Anthropic entfernte Fable 5 und Mythos 5 im Juni 2026 nach einer US-Exportkontroll-Direktive für Kunden außerhalb der USA (WIRED); Stand dieses Artikels ist der Fall nicht abgeschlossen. Das ist kein Sicherheitsvorfall und kein allgemeines Argument gegen Cloud-Modelle. Als Warnsignal reicht der Fall trotzdem: Sobald ein Team Security-Reviews, Fixes oder Release-Freigaben auf ein bestimmtes Modell stützt, wird dessen Verfügbarkeit zu einem Lieferketten- und Kontinuitätsrisiko, das § 30 ausdrücklich nennt. Deshalb gehört ein Ausstiegsplan in die NIS2-Nachweise: Alternativmodell, manueller Fallback, Export von Logs und Konfigurationen, getestetes Runbook.

Die ersten 90 Tage

Wenn Ihr Unternehmen NIS2-pflichtig ist und Coding Agents nutzt oder einführen will, sieht ein belastbarer Einstieg so aus. Drei Phasen, jede mit einem klaren Ergebnis. Ziel ist nicht Bürokratie, sondern dass Teams Coding Agents weiter nutzen können, nur mit klaren Regeln, messbaren Ergebnissen und weniger Bauchgefühl. Kein perfekter Stand in 90 Tagen also, sondern ein prüfbarer: Sie wissen, was läuft, haben die größten Risiken eingegrenzt und können es belegen.

Tage 0 bis 30: Geltungsbereich, Sofortmaßnahmen und Inventar. Betroffenheitsstatus mit Legal und Compliance klären, nicht im Team allein. Ein Inventar aller Agenten, Modelle, IDE-Plugins, MCP-Server und Integrationen erstellen und Repositorys nach Datenkategorien einstufen. Unkontrollierten Einsatz in regulierten Repositorys befristet einfrieren. Verantwortliche für Technik, Security und Recht benennen und eine Mindestvorgabe veröffentlichen: keine Secrets in Prompts, keine ungeprüften Agent-PRs, keine Schreibrechte ohne Genehmigung.

Tage 31 bis 60: Lieferantenprüfung und Entwicklungs-Kontrollen. Anbieter prüfen: Datenverarbeitung, Aufbewahrung, Subprozessoren, Zertifikate, Meldung von Sicherheitsvorfällen, Lebenszyklus des Modells. Repository-Rechte begrenzen, Branch Protection und Code Owners aktivieren. Netzzugriff in der Sandbox standardmäßig sperren und auf eine Liste erlaubter Domains beschränken. Die Prüfungen in der CI-Pipeline so erweitern, dass sie auch für KI-Code greifen: SAST, DAST, SCA, Secrets Scanning, SBOM. Festlegen, dass der Agent Änderungen vorbereiten darf, sicherheitskritische Änderungen aber einen menschlichen Review brauchen.

Tage 61 bis 90: Managemententscheidung, Tests und Ausstieg. Die Entscheidung mit Risikoannahmen, Restrisiken und Verantwortlichen dokumentieren. Wirksamkeitsmetriken einführen: Scan-Abdeckung, Durchrutschquote, Zeit bis zur Behebung. Notfälle durchspielen, von der Modellabschaltung bis zur Prompt Injection über ein Ticket oder Issue. Den Ausstieg testen, nicht nur aufschreiben. Und alles in einem Nachweisordner sammeln: Risikobewertung, Lieferantenliste, Verträge, Richtlinien, Scanberichte, Notfalltests.

Eine Einordnung der Aufsicht gehört dazu: Uns ist kein öffentlich belastbarer erster deutscher oder EU-NIS2-Bußgeldfall bekannt. Belegt ist dagegen, dass das BSI sein Registrierungsportal ausgebaut hat und die Registrierungsfrist abgelaufen ist (BSI-Pressemitteilung, Juni 2026). Entscheidend ist derzeit vor allem die Nachweisfähigkeit, nicht ein Musterurteil.

Fazit

NIS2 macht Coding Agents nicht unmöglich, es macht ihren Einsatz professioneller. Einen KI-Sonderparagrafen braucht es dafür nicht. Entscheidend ist § 30 BSIG: Lieferkette, sichere Entwicklung und Wirksamkeitsbewertung. Ein Agent, der Repositories liest, Pull Requests erstellt oder Security-Reviews unterstützt, verändert den Entwicklungsprozess und damit das Risikoprofil des Unternehmens. Wer ihn beherrscht, braucht keine KI-Sonderregeln, sondern saubere Engineering-Governance: Inventar, Rechte, Reviews, CI-Prüfungen, Metriken und Fallbacks. Damit wird der Agent nicht ausgebremst, sondern verlässlich einsetzbar. Die praktische Frage lautet deshalb nicht, ob KI Code schreiben darf. Sie lautet: Kann das Team nachweisen, dass Agent, Anbieter, Rechte, Datenflüsse, Reviews und Fallbacks geregelt und nachweisbar sind? Wer diese Nachweise hat, steht deutlich besser da. Wer sie nicht hat, beginnt mit drei Nachweisen: Agenten-Inventar, Berechtigungsmatrix, Nachweisordner für CI-Prüfungen. Erst danach lohnt die Diskussion über die Modellauswahl.