Claude Code im Stadtwerk: DSGVO-Setup Bedrock + IONOS

Pexon Consulting | 11 Min. Lesezeit | 01.06.2026

TL;DR

Claude Code im Stadtwerk DSGVO-konform zu betreiben heißt drei Entscheidungen treffen: Hosting-Pfad (Bedrock mit EU-Profil schlägt Anthropic Direct, Microsoft Foundry hat für Claude keine EU-Verarbeitung), Frontend-Architektur (IONOS-gehostetes Gateway ergänzt sovereignty) und Logging-Setup (KRITIS-konform nach BSI-Konkretisierung 2026). Pexon Consulting begleitet KRITIS-IT-Leiter durch diesen Stack, ohne Compliance-Folien.

Warum Stadtwerke kein Standard-KI-Setup haben

Wir sehen das Muster in fast jedem Erstgespräch mit einem Stadtwerk-IT-Leiter: Die Geschäftsführung hat Claude oder ChatGPT gesehen, will „auch was mit KI“, die IT zuckt zusammen. Der Grund ist nicht Innovationsfeindlichkeit — der Grund ist ein konkreter Stapel an Regularien, der bei einem normalen Mittelstandskunden nicht zusammenkommt: BSI-Konkretisierung KRITIS, NIS2-Umsetzung, BNetzA-Vorgaben zur Netzleitstellen-Trennung, der KRITIS-Dachgesetz-Vorlauf 2026, und ab Februar 2026 die ersten zwingenden Pflichten aus dem EU-AI-Act für Deployer.

Das wirkt nach außen wie Bürokratie. Aus IT-Sicht ist es eine klare Anforderung: Jede produktive KI-Komponente muss eine saubere Auftragsverarbeitungs-Lage haben, KRITIS-konformes Logging unterstützen, technisch zur OT-IT-Netztrennung passen und im Audit nachvollziehbar sein. Anthropic Direct als US-Vendor ohne EU-Niederlassung erfüllt das nicht out-of-the-box. Wer im April einfach pip install claude-agent-sdk macht und produktiv geht, hat bei der nächsten KRITIS-Auditprüfung ein Problem.

Die gute Nachricht: Die DSGVO- und KRITIS-konforme Variante ist seit Mitte 2025 technisch glatt umsetzbar. Sie heißt nicht „Claude Code irgendwie“, sie heißt „Claude Code auf AWS Bedrock mit EU-Profil und korrektem AVV, eigenem Logging-Stack und einem sovereignen Frontend-Gateway“. Wir bauen das aktuell für drei Stadtwerke und einen Regionalversorger.

Die AVV-Lage: drei Pfade, einer realistisch

Drei mögliche Pfade — nur einer trägt für KRITIS-relevante Workloads.

Pfad 1: Anthropic Direct (api.anthropic.com). Vertragspartner ist die Anthropic PBC mit Sitz in San Francisco. DSGVO-Datenverarbeitungsvereinbarung ist verfügbar (Version 1. Januar 2026 mit EU-Standardvertragsklauseln nach EU-Kommissions-Decision 2021/914). Verarbeitung läuft in US-Datacentern. Das geht für Free-Text-Use-Cases ohne Personenbezug. Es geht nicht für KRITIS-Workloads, weil die KRITIS-Konkretisierung des BSI klare Anforderungen an Sub-Auftragsverarbeitung und Vor-Ort-Audit-Rechte stellt, die ein US-Direktvertrag nur über SCC abbilden kann — und das wird in Audits regelmäßig beanstandet.

Pfad 2: AWS Bedrock mit EU-Profil. Vertragspartner ist AWS EMEA SARL mit Sitz in Luxemburg, AVV nach Art. 28 DSGVO direkt verfügbar, BSI-C5-Testat vorhanden, ISO 27001, SOC 2 Type II. AWS ist seit Juli 2025 als kritischer ICT-Drittanbieter (CTPP) unter DORA gelistet — was für regulierte Branchen Erleichterung bei der Drittparteien-Bewertung bedeutet. Die aktuellen Modelle Opus 5, Sonnet 5 und Haiku 4.5 laufen über das EU-Profil: Anfragen gehen in Frankfurt ein und werden in EU-Regionen verarbeitet, das weltweite Profil lässt sich per Richtlinie sperren. Claude Fable gibt es auf Bedrock nicht in der EU. Das ist der Pfad, den wir empfehlen.

Pfad 3: Azure mit Claude. Azure OpenAI Service hostet keine Anthropic-Modelle. Microsoft Foundry (vormals Azure AI Foundry) bietet Claude an, in Europa aber nur als weltweites Deployment in Sweden Central, ohne EU-Datenzone und mit Anthropic als eigenständigem Verarbeiter. Einen Termin für EU-Verarbeitung nennt Microsoft nicht. Wer im Stadtwerk auf Azure-Standardisierung sitzt und Claude einsetzen will, muss aktuell den Hybrid-Schritt machen: Azure für GPT-Workloads, Bedrock für Claude-Workloads. Wir haben das in zwei Setups so gebaut — funktioniert, kostet aber Vertragsmanagement.

Für den Fall, dass das Stadtwerk Microsoft 365 nutzt und einen Sovereignty-Reflex hat: IONOS Nextcloud Workspace ist seit Mai 2026 die sovereine Alternative für Office-Funktionen, mit IONOS AI Model Hub als sovereigner KI-Backbone-Option. Wir verlinken das mit Claude Code via Bedrock-Frontend — siehe Sektion IONOS-Frontend unten.

DPA-Templates: Was wirklich reingehören muss

Wir lesen DPAs nicht als Hobby, aber wir haben in den letzten zwölf Monaten Dutzende Anthropic-, AWS- und Azure-Vereinbarungen für Stadtwerke geprüft. Hier ist die kompakte Liste der Klauseln, die unverhandelbar drin sein müssen, wenn Claude im KRITIS-Kontext laufen soll.

Auftragsverarbeitung nach Art. 28 DSGVO: Klare Auflistung der verarbeiteten Datenarten, Zweckbindung, Weisungsbindung des Auftragnehmers. Bei AWS Bedrock ist das Standard im AWS Customer Agreement plus AWS Service Terms.

Sub-Auftragsverarbeitung mit Veto-Recht: Bei Bedrock ist AWS dein Auftragsverarbeiter, Anthropic sieht die Daten nicht. Du musst widersprechen können, wenn AWS weitere Sub-Verarbeiter hinzufügt — sonst entsteht eine schleichende Erweiterung der Daten-Reichweite, die du im Audit nicht erklärt bekommst.

Vor-Ort-Audit-Recht beim CTPP: Unter DORA und KRITIS-Konkretisierung ist das Audit-Recht ein zwingender Bestandteil. AWS bietet das in Form von CTPP-Auditberichten plus tiefergehender ISAE-3402-Reports. Anthropic Direct bietet das nicht in vergleichbarer Form.

Datenstandort-Garantien: Bei Bedrock muss die Region „EU only“ hard codiert sein. AWS lässt das per IAM-Policy konfigurieren — wir setzen standardmäßig eine SCP (Service Control Policy) auf Account-Ebene, die nicht-EU-Bedrock-Regionen blockiert. Das ist ein 20-Zeilen-JSON.

Incident-Reporting-SLA mit 24h-Notification: NIS2 und KRITIS fordern Meldung an BSI binnen 24h ab Kenntnis. Der Vendor-Vertrag muss garantieren, dass du in einem Zeitrahmen erfährst, der dir 24h-Compliance ermöglicht. AWS hat das in der Custom DPA für regulierte Industrien — das musst du gezielt anfordern, im Standard-AWS-Vertrag steht es nicht prominent.

Löschungs- und Export-Garantien beim Vertragsende: Wie kommen die in Bedrock verarbeiteten Daten zurück, falls du Vendor wechselst? Bedrock hat keine persistente Datenspeicherung im Default — Anfragen werden verarbeitet und vergessen. Aber dein Logging-Stack (CloudWatch, S3) und die in OpenSearch indexierten Embeddings sind anders. Klare Lösch-Klausel formulieren.

KRITIS-Logging: Was BSI 2026 wirklich fordert

Hier liegt die Komponente, die im Standard-Anthropic-Setup komplett fehlt — und die wir bei Stadtwerken immer custom aufbauen. Das BSI hat in der KRITIS-Konkretisierung (Stand 2026) explizit gefordert, dass sicherheitsrelevante Events von IT-Systemen geloggt und für mindestens 90 Tage retentioniert werden müssen, bei meldepflichtigen KRITIS-Anlagen oft länger. Für KI-Systeme gilt das analog.

Konkret heißt das: Jeder Claude-Aufruf produziert mindestens diese Log-Entries — Caller-Identity (welche Person, welcher Service-Account), aufgerufenes Tool, übergebene Parameter (hash-basiert, wenn personenbezogen), Modell-Antwort (volltext oder Hash je nach Sensitivität), Cost in USD, Latenz, Confidence-Marker bei strukturiertem Output, Fehler-Codes.

Im AWS-Bedrock-Setup fließen diese Logs in CloudWatch (mit KMS-encrypted Customer-Managed Keys), von dort in S3 Glacier Deep Archive für Retention. Für die Auswertung kippen wir die Logs in OpenSearch oder einen On-Prem-Loki-Stack. Wichtig: Die Logging-Pipeline muss selbst KRITIS-konform sein — also keine US-Exports der Log-Daten, kein Default-Datadog-Sink-to-US.

Ein weiterer BSI-Punkt aus der LLM-Designprinzipien-Veröffentlichung: AI-Systeme dürfen „kritische Entscheidungen“ nicht autonom treffen, Human-in-the-Loop ist Pflicht. Für Claude Code im Stadtwerk heißt das: Bei jedem Aufruf, der eine schreibende Aktion in OT-nahe Systeme triggert (Netzleitstelle, Bilanzkreis-Reporting, Marktstammdatenregister-Update), muss vor der Ausführung eine menschliche Freigabe stehen. Wir implementieren das technisch als Sperrlager-Pattern, vergleichbar zu unseren Document-Intelligence-Pipelines.

IONOS als sovereignes Frontend

Hier kommt die Pexon-spezifische Empfehlung, die wir Stadtwerken regelmäßig geben: Lege ein Frontend-Gateway zwischen die Stadtwerk-Mitarbeiter und das Claude-Bedrock-Backend, und hoste dieses Gateway bei IONOS.

Warum nicht direkt aus dem Stadtwerk-Netz auf Bedrock zugreifen? Drei Gründe.

Erstens: Sovereignty-Optik. Stadtwerk-Aufsichtsräte und kommunale Verwaltungsräte mögen es nicht, wenn auf der ersten Folie eines KI-Projekts „AWS“ steht. Selbst wenn das EU-Setup technisch sauber ist. Ein IONOS-Frontend, das die AWS-Bedrock-Calls weiter im Hintergrund routet, ändert die Optik — du sprichst eine deutsche URL an, die auf eine deutsche Cloud-Adresse zeigt. Politisch macht das einen Unterschied.

Zweitens: zentrale Authentifizierung und Berechtigung. Das Gateway terminiert TLS, übernimmt OAuth/Keycloak-Anbindung an dein Stadtwerk-IdP, setzt Rate-Limits pro User, loggt KRITIS-konform vor der Weitergabe an Bedrock. Das spart dir einen Wildwuchs an Direct-AWS-IAM-Berechtigungen für Endnutzer.

Drittens: Tool-Allowlist auf Gateway-Ebene. Du definierst zentral, welche Claude-Tools (MCP-Server, Custom Tools) für welche User-Gruppe verfügbar sind. Operative Mitarbeiter in der Bilanzkreis-Abteilung bekommen die Marktstammdatenregister-Tools, Netzleitstellen-Operatoren bekommen nur Read-Only-Tools auf bestimmte OT-Datenquellen. Das Gateway erzwingt das, nicht der einzelne Claude-Aufruf.

Wir nutzen für solche Gateways bevorzugt Litellm-Proxy oder einen Custom-FastAPI-Wrapper, deployed auf einem IONOS-Cloud-Compute-Cluster mit IONOS-Managed-Postgres als Audit-Store. IONOS hat seit Mai 2026 ein eigenes AI Model Hub mit OpenAI-kompatibler API — für Stadtwerke, die zusätzlich zu Claude noch lokale Modelle für unkritische Workloads brauchen, ist das die natürliche Erweiterung.

Praxis-Setup in 6 Wochen

Wir liefern den DSGVO-konformen Claude-Stack für Stadtwerke als 6-Wochen-Sprint, festes Volumen, fester Preis.

Wochen 1-2: AVV-Review mit deinem Datenschutzbeauftragten, AWS-Bedrock-Account-Setup im eigenen AWS-Organizations-Account (oder verwaltetem AWS-Tenant), Service-Control-Policy zur EU-only-Bedrock-Restriktion, IAM-Roles-Skelett.

Wochen 3-4: IONOS-Gateway-Deployment, Anbindung an dein IdP (Keycloak, Entra ID, Open-Source-Alternative), Logging-Pipeline CloudWatch → S3 → On-Prem-Loki, KRITIS-konformes Audit-Schema.

Wochen 5-6: Erste produktive Use-Cases mit deinen Fachbereichen, Sperrlager-Workflows für OT-relevante Aktionen, Schulung von 8-12 Power-Usern. Übergabe inkl. Doku, Audit-fähigem Runbook und Konfigurations-Code (Terraform).

Investment je nach Scope und bestehender AWS-Maturity: 45.000-75.000 EUR.

Häufig gestellte Fragen

Reicht ein Standard-AVV von Anthropic für KRITIS-Workloads?

Nein. Anthropic Direct bietet einen DPA mit EU-Standardvertragsklauseln, aber kein BSI-C5-Testat, keine CTPP-Listung, kein direkt audit-fähiges Datacenter in Deutschland. Für KRITIS-Anlagen-Operatoren mit § 8a-BSIG-Pflichten ist das in der Praxis nicht tragfähig. Bedrock mit EU-Profil ist der Standard-Pfad, weil AWS als CTPP gelistet ist und alle drei Komponenten (BSI-C5, direkte AVV, EU-Verarbeitung) abdeckt.

Können wir Claude Code im eigenen Netz laufen lassen?

Das Modell nicht — Claude ist nicht open-source. Das SDK plus das Frontend-Gateway laufen aber komplett in deinem Netz oder bei IONOS. Die einzige externe Verbindung ist die TLS-Verbindung zu Bedrock-eu-central-1, abgesichert mit VPC-PrivateLink, sodass der Traffic AWS-Backbone nicht verlässt. Aus Netzwerk-Audit-Sicht ist das eine kontrollierte Outbound-Verbindung zu einem CTPP-gelisteten Provider, kein „offenes Internet“.

Wie passt das mit unserer OT-IT-Netztrennung zusammen?

Claude Code läuft in der IT-Zone. Aktionen, die OT-Daten lesen wollen (Netzleitstellen-Tags, SCADA-Werte), gehen über vorgefertigte, auditierte Read-Only-MCP-Server in der OT-IT-DMZ. Schreibende Aktionen auf OT-Systeme schließen wir auf Tool-Ebene kategorisch aus — das ist eine Default-Konfiguration, die wir Stadtwerken nicht zur Disposition stellen. Diese Architektur haben wir bereits im Workshop-Format dokumentiert: Claude Cowork Stadtwerke Workshop.

Was passiert, wenn Anthropic die Bedrock-Verfügbarkeit einstellt?

Vertraglich abgesichert über AWS Bedrock: AWS ist Vertragspartner und Auftragsverarbeiter, Anthropic sieht die Daten nicht. Bei Wegfall müsste AWS Migration anbieten. Praktisch: Open-Source-Modelle (Qwen 3.5, Llama 3.3) sind über das gleiche IONOS-Gateway nutzbar, das Switching-Effort wäre 1-2 Wochen Engineering. Wir bauen Stadtwerke-Setups standardmäßig so, dass das Modell austauschbar ist.

Sind die laufenden Kosten transparent kalkulierbar?

Ja, mit Caveat. Bedrock-Modell-Tokens sind klar kalkulierbar (Sonnet 4.6: 3 USD/MTok Input, 15 USD/MTok Output). IONOS-Gateway-Hosting kostet 200-500 EUR/Monat je nach Cluster-Größe. CloudWatch + S3 Glacier für Retention liegt unter 100 EUR/Monat bei typischen Stadtwerk-Volumina. Was variabel ist: Heavy-User-Behavior — ein Power-User, der Claude Code für tägliche Daten-Analysen nutzt, kann 30-80 EUR/Monat allein verursachen. Wir bauen Per-User-Cost-Caps standardmäßig in die Gateway-Konfiguration.

Nächster Schritt

Wenn dein Stadtwerk oder Regionalversorger ernsthaft Claude evaluiert und du wissen willst, wie der DSGVO-konforme Setup konkret bei euch aussieht: Wir machen einen 60-Minuten-Call. Du beschreibst Ist-Stack und Compliance-Anforderungen, wir skizzieren Architektur und Festpreis.

Verwandte Themen

Wer denselben Weg geht, sollte vorher die Aufbewahrungsfristen durchgehen: Zero Data Retention für Claude zeigt je Plattform, wer was wie lange speichert, und warum Fable auf jeder Plattform 30 Tage behält. Die Plattformwahl selbst behandelt unsere Hosting-Übersicht.