Claude Code KRITIS: NIS-2-Audit im Stadtwerk bestehen

Pexon Consulting | 9 Min. Lesezeit | 01.06.2026

TL;DR

Claude Code KRITIS einsetzen ist machbar – aber nicht out-of-the-box. Stadtwerke müssen für den NIS-2-Audit drei Dinge nachweisen: vollständiger Audit-Trail, Quellcode bleibt in der EU, dokumentierte Mitarbeiter-Schulung. Dieser Artikel mappt Artikel 21 der NIS-2-Richtlinie auf ein konkretes Claude Code KRITIS-Setup für ein typisches Stadtwerk mit 80-300 Mitarbeitern.

Warum Stadtwerke jetzt nicht mehr drumrum kommen

Mit dem NIS-2-Umsetzungsgesetz (NIS2UmsuCG) fallen in Deutschland deutlich mehr Stadtwerke unter die KRITIS-Regulierung als unter der alten BSI-KritisV. Konkret: Schon ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz sind Energieversorger als „wesentliche Einrichtung“ einstufungspflichtig. Bei rund 900 Stadtwerken in Deutschland trifft das fast alle. Die Geschäftsführung haftet persönlich, Bußgelder gehen bis 10 Millionen Euro oder 2 % des Jahresumsatzes.

Gleichzeitig haben fast alle IT-Abteilungen in Stadtwerken in den letzten 12 Monaten angefangen, mit AI-Coding-Assistants wie Claude Code, GitHub Copilot oder Cursor zu experimentieren. Manchmal sanktioniert, oft als Schatten-IT. Das ist die Konstellation, in der die BSI-Aufsicht jetzt anfängt nachzufragen – und in der „Wir nutzen das nur als Tool, das ist nicht prüfungsrelevant“ als Antwort nicht durchgeht.

Aus unseren Audits bei drei deutschen Energieversorgern in den letzten sechs Monaten haben wir eine klare Position: AI-Coding-Tools sind ab dem Moment, in dem sie produktiv Code erzeugen, ein Asset im Sinne von Artikel 21 NIS-2 – mit allen Konsequenzen für Inventarisierung, Risikoanalyse und Lieferanten-Compliance.

Die EU-Residenz-Frage stellt sich dabei nicht nur für Claude Code, sondern für die gesamte Claude-Nutzung im Energieversorger: Claude EU für Energieversorger zeigt, welche Betriebsvarianten die NIS-2-Anforderungen aus Artikel 21 für den kompletten Claude-Einsatz erfüllen, nicht nur für Claude Code.

Die 10 Maßnahmen aus Art. 21 – was Claude Code wirklich betrifft

Artikel 21(2) NIS-2 listet zehn Mindestmaßnahmen. Nicht alle sind für ein AI-Coding-Setup gleich relevant. Die drei mit dem höchsten Audit-Risiko sind:

(d) Sicherheit der Lieferkette. Anthropic ist ein US-Sub-Prozessor. Wenn der Quellcode Ihres Smart-Meter-Gateways oder Ihres SCADA-Adapters über die Anthropic-Standard-API läuft, ist das eine Drittlandsübermittlung mit allen DSGVO- UND NIS-2-Implikationen. Lösung: Claude Code über AWS Bedrock oder Google Vertex in einer EU-Region – vertraglich abgesichert über Standard-Vertragsklauseln plus EU-AI-Act-konforme Auftragsverarbeitung.

(e) Sicherheit in Beschaffung, Entwicklung und Wartung. Jede Zeile AI-generierter Code ist potenzieller Angriffsvektor. Studien (z.B. Stanford 2023, Snyk State of AI Security 2026) zeigen Vulnerability-Raten in AI-Vorschlägen zwischen 40-55 %. Ohne SAST/SCA-Gate (z.B. SonarQube, Snyk, GitLab Secure) ist jeder Merge mit AI-Code ein NIS-2-Befund.

(g) Cyberhygiene und Schulung. Mitarbeiter dürfen Claude Code nicht ohne Schulung nutzen. Das ist nicht nur Compliance – die häufigste Fehlerquelle in unseren Audits war ein Werkstudent, der API-Keys aus dem .env in den Prompt kopiert hat, weil er das Tool „ausprobieren“ wollte.

Die anderen sieben Maßnahmen sind ebenfalls relevant, aber technisch weniger AI-spezifisch – sie betreffen Backup, MFA, Asset-Management und Kryptografie, die der Stadtwerke-CISO sowieso schon adressieren muss.

Setup-Pattern – Claude Code KRITIS-konform aufstellen

Drei Komponenten machen den Unterschied zwischen „Schatten-IT“ und „auditfest“:

+-------------------+     +------------------+     +---------------+
| Entwickler-Laptop |     | Pexon Proxy /    |     | AWS Bedrock   |
| Claude Code CLI   |---->| Audit-Gateway    |---->| EU-Frankfurt  |
| --no-telemetry    |     | (Audit-Log,      |     | (Claude       |
| Bedrock-Backend   |     |  Token-Cap,      |     |  Sonnet 4.6)  |
+-------------------+     |  Source-Filter)  |     +---------------+
                          +------------------+              |
                                  |                         v
                                  v                  +---------------+
                          +---------------+          | KEIN Daten-   |
                          | SIEM / Splunk |          | Abfluss in    |
                          | (NIS-2-Audit) |          | die USA       |
                          +---------------+          +---------------+

Konkret sieht das so aus:

• Claude Code CLI mit --no-telemetry plus Bedrock-Backend in eu-central-1. Damit verlässt kein Source-Code-Snippet die EU.
• Audit-Gateway als HTTP-Proxy vor Bedrock. Loggt jeden Request (User, Datei, Prompt-Hash, Token-Verbrauch, Antwort-Hash) in ein dediziertes Log. Wir nutzen einen schlanken FastAPI-Proxy mit asyncio-streaming, weil Standard-API-Gateways die Server-Sent-Events von Bedrock nicht sauber durchreichen.
• SIEM-Anbindung an das bestehende Splunk / Elastic / Wazuh des Stadtwerks. Das ist der Audit-Trail, den der BSI-Prüfer sehen will. Nicht der Bedrock-Cloudwatch-Log, sondern der Log im Sicherheits-SIEM des Stadtwerks.

Bei Stadtwerken ohne AWS-Footprint funktioniert die gleiche Architektur mit Azure OpenAI auf Azure als Backend, sofern das Anthropic-Modell dort verfügbar ist, oder mit selbst gehostetem Llama 3.3 / Qwen 2.5 auf Private KI-Infrastruktur. Letzteres ist die einzige Option für Stadtwerke, die regulatorisch absolut keine Cloud-LLMs einsetzen dürfen.

Audit-Trail und Logging – was der BSI-Prüfer sehen will

Aus drei BSI-Prüfungen, bei denen wir den IT-Verantwortlichen begleitet haben, gibt es einen klaren Pflicht-Katalog. Pro Tool-Call müssen Sie nachweisen können:

1. Wer hat den Prompt abgesetzt (User-ID, gekoppelt an Entra ID oder LDAP)
2. Wann (Zeitstempel auf die Millisekunde, UTC)
3. Welche Datei / welches Repository wurde im Kontext mitgeschickt
4. Welche Tools hat der Agent verwendet (Read, Edit, Bash, etc.)
5. Welcher Output wurde zurückgegeben (Hash reicht, nicht der volle Output)
6. Welches Modell hat geantwortet (Modell-ID + Version, für Reproduzierbarkeit)
7. Token-Verbrauch (Input + Output, für Kosten- und Anomalie-Erkennung)

Das in eine simple Tabelle:

Speicherfrist: Unsere Default-Empfehlung sind 12 Monate für Audit-Logs und 24 Monate für Sicherheitsvorfälle – abgestimmt mit dem internen DSB des Stadtwerks. Längere Aufbewahrung lohnt sich selten, kürzere wird vom BSI in der Regel als unzureichend bewertet.

Was wir aktuell nicht empfehlen: Den vollen Prompt-Inhalt im Hauptlog zu speichern. Das macht Datenschutz und Geheimhaltungsbruch-Risiken zu groß. Stattdessen Prompt-Hash im SIEM, Volltext in einem separaten, restriktiv zugegriffenen Cold-Storage mit kurzer Retention.

Source-Code-Schutz – keine Telemetrie nach USA

Der häufigste Versteck-Befund in unseren Audits: Claude Code in der Standard-Konfiguration sendet Telemetrie an Anthropic. Das ist per se nicht böse – aber für ein KRITIS-Stadtwerk ist es ein NIS-2-Verstoß gegen Artikel 21(2)(d), weil unkontrollierte Datenabflüsse zu einem US-Sub-Prozessor stattfinden.

Drei konkrete Konfigurationen, die jedes Stadtwerk vor dem ersten Rollout setzen muss:

# 1. Telemetrie hart abschalten
export DISABLE_TELEMETRY=1
export DISABLE_ERROR_REPORTING=1
export DISABLE_NON_ESSENTIAL_MODEL_CALLS=1

# 2. Bedrock-Backend in EU-Region statt Anthropic-API
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-central-1
export ANTHROPIC_MODEL=eu.anthropic.claude-sonnet-4-20250514-v1:0

# 3. Eigenes Audit-Gateway statt direkter Bedrock-Aufruf
export ANTHROPIC_BASE_URL=https://claude-proxy.intern.stadtwerk.de

Aus unseren Pen-Tests wissen wir: Punkt 3 ist der wirksamste Hebel. Ein Audit-Gateway im eigenen Netz kann den Output zusätzlich filtern (Beispiel: keine API-Keys in Prompts, keine Datenbanken-Connection-Strings, keine Kunden-Personendaten). Ohne Gateway müssen Sie auf jedem Entwickler-Laptop die Konfiguration revisionssicher dokumentieren – was in der Praxis selten gelingt.

Mitarbeiter-Schulungspflicht – Art. 21(2)(g) erfüllen

NIS-2 Artikel 21(2)(g) verlangt „grundlegende Cyberhygiene-Praktiken und Schulungen im Bereich der Cybersicherheit“ – verbindlich, nicht freiwillig. Für AI-Coding-Tools heißt das: Jeder User braucht vor dem ersten Prompt eine dokumentierte Schulung mit Unterschrift, jährliche Auffrischung und ein Mini-Quiz, das den Lernerfolg belegt.

Pexon liefert für Stadtwerke ein 4-stündiges Curriculum mit fünf Pflicht-Modulen:

1. Was ist ein Prompt – und warum Code-Snippets, Pfade und Logs zum Prompt zählen
2. Was darf rein und was darf nicht rein (Personendaten, Geheimnisse, Kunden-IDs, Smart-Meter-Stammdaten)
3. AI-Output ist Vorschlag, nicht Wahrheit – Review-Pflicht für jeden Merge, SAST-Gate als Backstop
4. Eskalations-Pfade bei Verdacht auf Halluzinierung, Datenabfluss oder Modell-Manipulation
5. Was im Audit passiert – welche Logs der BSI-Prüfer sehen wird und warum

Das ist kein Marketing-Modul, sondern Mindestumfang. Wer das einsparen will, fällt im ersten Audit durch – und das Bußgeld ist deutlich teurer als die zwei Schulungstage pro Jahr.

Fallstricke aus echten Stadtwerk-Projekten

Drei wiederkehrende Probleme aus unserer Praxis – wir geben sie hier vor, damit Sie sie nicht selbst erleben müssen:

1. SCADA-Repos auf einem Entwickler-Laptop mit Standard-Claude-Code. Aufgefallen bei einem süddeutschen Stadtwerk, als ein internes Audit den Telemetrie-Header in den Anthropic-Standard-API-Logs gefunden hat. Quellcode für die Leitsystem-Anbindung war 6 Wochen lang inoffizieller US-Datenexport. Lösung: Sofortige Sperre der direkten Anthropic-API per Firewall-Regel, Rollout über Bedrock-Proxy.

2. Schatten-IT mit privaten API-Keys. Drei Entwickler hatten persönliche Anthropic-Keys aus dem Web-Account, weil „der Bestellprozess zu lange dauert“. Konsequenz: Kein Audit-Trail, keine Token-Limits, keine Vertragsgrundlage. Lösung: Single Sign-On gegen Entra, persönliche Keys über DLP-Regel blockieren.

3. Code-Review-Disziplin schleift. Nach drei Monaten Claude-Code-Nutzung haben Reviewer angefangen, AI-Pull-Requests mit „looks good“ durchzuwinken, ohne den Code wirklich zu prüfen. Drei Bugs in der Abrechnungslogik gingen so in Produktion. Lösung: Verpflichtende Marker für AI-generierte PRs („Co-Authored-By: Claude“) und gesonderte Review-Checkliste mit fachlichem Plausibilitäts-Check.

Konfidenz für alle drei Punkte: hoch – wir haben jedes davon mehrfach gesehen, nicht nur einmal.

Häufig gestellte Fragen

Ist Claude Code KRITIS-tauglich oder muss ich auf On-Prem-LLMs ausweichen?

Ja, Claude Code ist KRITIS-tauglich, sofern Sie es über AWS Bedrock oder Azure (mit Anthropic-Modell, wo verfügbar) in einer EU-Region betreiben, Telemetrie abschalten und ein Audit-Gateway davorsetzen. Reine On-Prem-LLMs (Llama 3.3, Qwen 2.5) sind eine Option für Stadtwerke mit absoluten Cloud-Verboten, leisten aktuell aber 20-40 % weniger Coding-Qualität als Claude Sonnet 4.

Was passiert konkret im NIS-2-Audit für ein Stadtwerk mit AI-Coding-Tools?

Der BSI-Prüfer fragt drei Dinge: (1) Asset-Inventar mit AI-Tools, (2) Audit-Logs der letzten 90 Tage mit konkretem User-Bezug, (3) Schulungsnachweise pro User mit Unterschrift. Wer keinen einzigen davon liefern kann, bekommt ein „wesentlicher Mangel“-Befund mit Nachweispflicht innerhalb von 90 Tagen. Bei Wiederholung droht ein Bußgeldverfahren. Dieselbe Nachweispflicht trifft Ihre Container-Plattform, weshalb wir getrennt beschrieben haben, wie Sie in Kubernetes-Umgebungen den Betrieb audit-fest machen.

Wie hoch ist der Mehraufwand für ein KRITIS-konformes Setup gegenüber Standard-Claude-Code?

Einmalig 15-25 Personentage für Audit-Gateway, SIEM-Anbindung und Schulungs-Curriculum. Laufend ca. 1-2 PT pro Monat für Log-Review, plus die jährliche Wiederholungsschulung. Gegenüber den eingesparten Entwicklungsaufwänden – wir messen pro Entwickler 8-15 % Produktivitätsgewinn – amortisiert sich das nach 3-4 Monaten.

Brauche ich eine separate Genehmigung vom internen Datenschutzbeauftragten?

Ja, und zwar zwingend. Auch bei rein internem Code-Einsatz ist eine Datenschutz-Folgenabschätzung (Art. 35 DSGVO) ratsam, weil Code-Kommentare und Variablennamen oft personenbezogene Daten enthalten. Wir liefern Stadtwerken eine Standard-DSFA-Vorlage als Teil des Setups.

Welche Tools brauche ich neben Claude Code noch zwingend?

Vier: SIEM (Splunk / Elastic / Wazuh), SAST/SCA (SonarQube + Snyk oder GitLab Secure), ein Secrets-Vault (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) und ein DLP-Tool, das Anthropic-API-Calls außerhalb des Audit-Gateways blockiert. Ohne diese vier ist die NIS-2-Compliance nicht herstellbar – auch dann nicht, wenn Sie nur 2-3 Entwickler mit Claude Code arbeiten lassen.

Nächster Schritt

Pexon Consulting deckt genau das mit einem externen Security-Audit ab: Konfigurationsanalyse aller Regelebenen, Telemetrie- und Source-Code-Pfade, priorisierter Befundbericht als Nachweis für den nächsten BSI-Prüftermin.

Vorher: Unser kostenloser NIS-2-Betroffenheits-Check mit 5-Schritte-Plan klärt in 10 Minuten, wo Ihr Stadtwerk regulatorisch steht.

Verwandte Themen