DSGVO-konforme KI-gestützte Softwareentwicklung mit Claude Code: Eine Referenzarchitektur für Deutschland

Wie lässt sich Claude Code DSGVO-konform betreiben, also so, dass schützenswerter Quellcode und personenbezogene Daten nicht unkontrolliert in eine US-Cloud fließen? Dieser Beitrag beschreibt eine herstellerneutrale Referenzarchitektur für Deutschland, von vollständig lokal bis EU-resident.

KI-gestützte Coding-Agenten wie Claude Code sind in der Entwicklung zu einem Produktivitätswerkzeug ersten Ranges geworden. Sie lesen ganze Codebasen, rufen Werkzeuge auf, bearbeiten Dateien und orchestrieren mehrstufige Aufgaben. Für Organisationen mit erhöhten Datenschutzanforderungen, also regulierte Branchen, der öffentliche Sektor, Berufsgeheimnisträger oder schlicht jeder mit schützenswertem Quellcode und personenbezogenen Daten, entsteht damit ein Zielkonflikt: Im Standardbetrieb fließt all das in eine US-Cloud.

Dieser Artikel beschreibt eine hypothetische, herstellerneutrale Referenzarchitektur, mit der sich Claude Code in Deutschland datenschutzkonform betreiben lässt, im Einklang mit den Kriterien, die sich aus öffentlich einsehbaren KI-Leitfäden der deutschen Verwaltung und aus der DSGVO ableiten lassen. Es geht ausdrücklich nicht um eine konkrete Organisation, sondern um die technischen Bausteine und die konkrete Konfiguration.

1. Das Kernproblem: Was eigentlich nach außen fließt

Bevor man über Compliance redet, muss man verstehen, welche Daten ein Coding-Agent überhaupt an das Modell sendet. Es ist deutlich mehr als der Prompt.

flowchart TD
    P[Prompt des Nutzers] --> M((An das Modell
gesendet))
    F[Dateiinhalte,
Quellcode, Diffs] --> M
    T[Werkzeug-Ergebnisse] --> M
    S[System-Kontext:
globale Anweisungen,
MCP-Tool-Schemas,
Skill- und Agenten-
Beschreibungen] --> M
    H[Konversationshistorie
bei Resume/Continue] --> M
    M --> R{Wohin?}
    R -- Standard --> US[(US-Cloud)]
    R -- Ziel --> EU[(EU / lokal)]

Der System-Kontext ist der am häufigsten übersehene Anteil: Selbst wenn man keine sensible Datei öffnet, sendet der Agent in jeder Runde globale Anweisungen, Werkzeug-Schemas und Agenten-Beschreibungen mit. Enthalten diese interne Prozess- oder Systeminformationen, verlässt all das die Organisation, ganz unabhängig vom eigentlichen Auftrag. Die Compliance-Frage lautet also nicht nur „Welches Modell nutze ich”, sondern auch „Wohin fließen Verarbeitung und Kontext, und was ist überhaupt im Kontext”.

2. Die Kriterien: Was öffentliche deutsche KI-Leitfäden gemeinsam fordern

Mehrere öffentlich einsehbare KI-Leitfäden für die deutsche Verwaltung sowie die DSGVO und der EU AI Act ergeben einen erstaunlich konsistenten Kriterienkatalog. Verdichtet:

Ein wichtiger, oft missverstandener Punkt: Pseudonymisierung ist keine Anonymisierung. Reversibles Maskieren personenbezogener Daten (Art. 4(5) DSGVO) bleibt personenbezogen, weil eine Re-Identifizierung möglich ist. Maskierung ist Verteidigung in der Tiefe, nicht der Freifahrtschein, Daten an einen beliebigen Anbieter zu senden.

Wer tiefer in die regulatorische Seite einsteigen möchte, findet ergänzende Grundlagen in meinem Beitrag zu Compliance in der Cloud.

3. Datenklassifizierung zuerst: Ein Entscheidungsbaum

Die Architektur folgt der Datenklasse, nicht umgekehrt. Erst klassifizieren, dann das Backend wählen.

flowchart TD
    A([Welche Daten verarbeitet
die Session?]) --> B{Personenbezogen
oder besonders
sensibel?}
    B -- Ja --> T1[[Tier A lokal
zero egress
oder Tier B mit
ausdrücklicher Freigabe]]
    B -- Nein --> C{Interner Code /
Interna?}
    C -- Ja --> T2[[Tier A oder Tier B
EU-resident + DPA]]
    C -- Nein --> T3[[Jedes Backend,
auch direkt]]

Faustregel: Ein Arbeitsverzeichnis = ein Backend = eine Datenklasse. Sensible Repositories und unkritische Projekte werden physisch und konfigurativ getrennt (Abschnitt 5).

4. Die drei Architektur-Wege

4.1 Tier A: Vollständig lokal (Zero Egress)

Das Modell läuft auf der eigenen Maschine bzw. im eigenen Netz. Nichts verlässt das Gerät. Datenschutzrechtlich die sauberste Variante.

Wichtige Einschränkung vorweg: Auf einem typischen Entwickler-Laptop (16 bis 36 GB Speicher) ist dieser Weg in der Praxis prototypisch. Ein dort lauffähiges Modell der 30B-Klasse ist für interaktive agentische Schleifen schlicht zu langsam, sobald Kontextfenster und Werkzeug-Aufrufe ins Spiel kommen. „Vollständig lokal in Sonnet-Qualität” ist auf solcher Hardware eher eine hypothetische Zielmarke als ein Arbeitsmodus. Realistisch braucht es dafür dedizierte Hardware (siehe unten).

flowchart LR
    CC[Claude Code
Harness] -- localhost,
Anthropic-kompatibel --> OL[Lokaler Server
offenes Modell]
    CC -. lokale Werkzeuge
IDE-Index, Grep .-> CC
    OL -. nichts verlässt
das Gerät .-> OL

Moderne lokale Laufzeiten sprechen direkt die Anthropic Messages API, ein Übersetzungs-Proxy ist nicht nötig:

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="http://localhost:11434"   # lokaler Server
export ANTHROPIC_AUTH_TOKEN="local"
claude --model <lokales-coder-modell>

Ehrliche Einordnung: Stark bei Code-Verständnis und werkzeuggestützter Analyse, vorausgesetzt das Modell arbeitet über einen IDE-Index (per MCP) mit echten Referenzen statt aus dem Gedächtnis. Schwächer bei tiefem, mehrstufigem Korrektheits-Reasoning und großen Refactorings. Lokale Modelle rufen Werkzeuge zudem weniger zuverlässig auf, im agentischen Betrieb muss man expliziter prompten.

Welche Hardware bräuchte es wirklich?

Ein Modell, das einem Cloud-Flaggschiff für Coding nahekommt, ist ein großes offenes Modell, etwa ein 70B-Dense-Modell oder eine große MoE-Architektur. Der entscheidende Engpass ist nicht die Rechenleistung, sondern Speichermenge und Speicherbandbreite: Das Modell muss vollständig in den (unified) Speicher passen, und die Token-Geschwindigkeit skaliert mit der Bandbreite. Stand Mitte 2026 gibt es auf dem deutschen Markt einige bezahlbare Optionen:

Ehrliche Einordnung dazu:

• Preiseinstieg liegt bei rund 2.000 bis 2.500 Euro für ein Strix-Halo-Mini-PC mit 128 GB. Das ist derzeit das beste Preis-Leistungs-Verhältnis, um ein 70B-Modell überhaupt vollständig im Speicher zu halten.
• Bandbreite ist der Flaschenhals. Strix Halo und GB10 liegen bei rund 256 GB/s, der Mac Studio M3 Ultra bei etwa dem Dreifachen, deshalb ist er in dieser Klasse bei großen Modellen am schnellsten, aber auch deutlich teurer.
• 5 bis 15 Token/s reichen für asynchrone oder Batch-Analyse, sind für flüssige interaktive Agenten-Schleifen aber grenzwertig.
• 128 GB reichen nicht für echte Flaggschiff-Parität. Bei Q4-Quantisierung braucht ein 70B-Modell rund 40 GB, eine 235B-MoE schon an die 120 GB, und die Modelle, die einem Cloud-Flaggschiff wirklich nahekommen (die 400B+-Klasse, etwa ein 405B-Dense-Modell mit rund 230 GB), passen erst ab 256 GB. In 128 GB läuft also bestenfalls bis ~235B-MoE, plus KV-Cache wird es schnell eng. Das ergibt einen sehr fähigen Analyse- und Coding-Assistenten, aber kein Sonnet-Äquivalent.

Eine Sonderrolle spielt der M3 Ultra mit großem Speicher: Mit 256 oder sogar 512 GB unified memory liegen ganz andere Modellgrößen drin, bis zu 400B+-Parametern lokal, was Setups für autonome Agenten erst möglich macht. Solche Maschinen kosteten allerdings rund 6.000 bis 12.000 Euro, und Apple hat die 256- und 512-GB-Stufen inzwischen, im Zuge der globalen Speicherknappheit, aus dem Verkauf genommen. Neu bestellbar ist derzeit nur die 96-GB-Variante; größere Konfigurationen gibt es nur noch gebraucht oder man wartet auf eine kommende Generation. Für ein bezahlbares System mit mehr als 96 GB bleibt damit aktuell der Strix-Halo-Weg mit 128 GB die praktikabelste Option, bei allerdings deutlich geringerer Bandbreite.

Fazit für Tier A, ehrlich: Ein vollständig lokales Setup in echter Sonnet-Qualität ist auf bezahlbarer Hardware derzeit nicht zu haben. Standard-Entwicklerhardware ist dafür prototypisch, eine bezahlbare 128-GB-Maschine (ab rund 2.000 Euro) liefert einen starken lokalen Analyse- und Coding-Assistenten, aber keinen Flaggschiff-Ersatz, und die Hardware-Klasse, die der 400B+-Modellgröße und damit echter Flaggschiff-Nähe entspricht, beginnt bei 256 GB unified memory und damit bei mehreren Tausend Euro, sofern überhaupt neu beschaffbar. Der reale Gegenwert von Tier A ist nicht „Sonnet zum Nulltarif”, sondern vollständige Datenhoheit ohne jeden Egress, bei bewusst akzeptierten Abstrichen bei Modellgröße und Geschwindigkeit.

4.2 Tier B: EU-residentes Flaggschiff über einen Hyperscaler

Die echten Flaggschiff-Modelle, aber über eine Cloud mit EU-Region und Auftragsverarbeitungsvertrag. Höchste Qualität bei belastbarer Datenresidenz.

flowchart LR
    CC[Claude Code
Harness] --> HS[Hyperscaler-Endpunkt
EU-Region
DPA, EU Data Boundary]
    HS --> LLM[Flaggschiff-LLM
in EU-Region]

Claude Code unterstützt das nativ über Umgebungsvariablen:

export CLAUDE_CODE_USE_BEDROCK=1            # bzw. Schalter des jeweiligen Providers
export AWS_REGION="eu-central-1"           # EU-Region
export ANTHROPIC_MODEL="<eu-inferenzprofil-des-modells>"
export ANTHROPIC_SMALL_FAST_MODEL="<eu-inferenzprofil-kleines-modell>"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1   # Telemetrie minimieren
claude

Details: Neueste Modelle sind oft nur in bestimmten EU-Regionen „in-region”, andere laufen über ein EU-übergreifendes Inferenzprofil (bleibt in der EU, aber nicht in einer einzigen Region). Für strikte Single-Country-Anforderungen vorab im Provider-Portal verifizieren. Kosten lassen sich über Prompt-Caching (Abschnitt 7) stark senken.

4.3 Tier C: EU-natives Modell über ein Gateway mit PII-Maskierung

Wer ein in der EU ansässiges Modell bevorzugt, schaltet ein Gateway zwischen, das die Anthropic-API auf das Provider-Format übersetzt und optional PII maskiert.

flowchart LR
    CC[Claude Code] --> GW[Gateway lokal
Format-Übersetzung
PII-Maskierung pre_call
De-Maskierung response]
    GW --> EU[EU-Modell-Anbieter]

model_list:
  - model_name: coder-default
    litellm_params:
      model: <eu-provider>/<coder-modell>
      api_key: os.environ/PROVIDER_API_KEY

guardrails:
  - guardrail_name: pii-mask
    litellm_params:
      guardrail: presidio
      mode: pre_call          # maskieren, bevor der Anbieter es sieht
      default_on: true
      output_parse_pii: true  # Originalwerte in der Antwort wiederherstellen

Ehrlich: Die Compliance-Grenze ist der EU-Anbieter, nicht die Maskierung. Quellcode lässt sich nicht sinnvoll anonymisieren, die Geschäftslogik geht an den Anbieter, deshalb muss dieser selbst EU-konform sein. Deutsche PII braucht ein deutsches NLP-Modell für den Maskierer; das englische Standardmodell übersieht viele deutsche Namen und Adressen.

5. Backend-Umschaltung und Kontext-Isolation

In der Praxis braucht man mehrere Wege parallel. Ein schlanker Wrapper wählt das Backend pro Aufgabe und setzt die passenden Umgebungsvariablen, bevor er den Agenten startet:

#!/usr/bin/env bash
case "$1" in
  local)    export ANTHROPIC_BASE_URL=http://localhost:11434
            export ANTHROPIC_AUTH_TOKEN=local ;;
  eu-flag)  export CLAUDE_CODE_USE_BEDROCK=1
            export AWS_REGION=eu-central-1
            export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 ;;
  eu-proxy) export ANTHROPIC_BASE_URL=http://localhost:4000
            export ANTHROPIC_AUTH_TOKEN=$GATEWAY_KEY ;;
  clean)    export CLAUDE_CONFIG_DIR="$HOME/.config-clean" ;;
esac
exec claude "${@:2}"

Hier liegt ein subtiler, aber wichtiger Fallstrick. Claude Code speichert Konfiguration und Konversationsverläufe pro Verzeichnis. Teilen sich mehrere Profile dasselbe Konfigurationsverzeichnis, werden globale Anweisungen, MCP-Tool-Schemas und Agenten-/Skill-Beschreibungen in jeder Session mitgesendet, auch in der, die „sauber” sein soll. Die Lösung ist ein isoliertes Konfigurationsverzeichnis pro Vertrauensstufe.

flowchart TB
    subgraph RISIKO[Geteiltes Verzeichnis: RISIKO]
        SH[~/.config
globale Anweisungen,
MCP-Schemas,
Agenten/Skills,
Verlauf] --> P1[Profil intern]
        SH --> P2[Profil sauber]
        P2 -. Leak .-> X[(falsches Backend)]
    end
    subgraph SAUBER[Isolierte Verzeichnisse: SAUBER]
        I1[~/.config-intern
voller Kontext] --> B1[sensibles Backend]
        I2[~/.config-clean
leer, nichts Internes] --> B2[öffentliches Backend]
    end

Empirisch bestätigt: Ein frisches, isoliertes Konfigurationsverzeichnis lädt null MCP-Server, keine globalen Anweisungen, keine Agenten/Skills und einen eigenen, getrennten Verlauf. Damit kann ein „sauberes” Profil keine internen Kontextbestandteile an ein anderes Backend weitergeben. Zwei weitere Fallstricke: Ein „Fortsetzen” der letzten Session in einem anderen Backend spielt deren Verlauf in das neue Backend ein, das niemals über Backends hinweg tun. Und die einfachste Regel, die beides entschärft, lautet: ein Verzeichnis, ein Backend.

6. Der agentische Workflow: MCP, Skills, Subagenten

Der Mehrwert entsteht erst im agentischen Zusammenspiel. Ein typischer Entwicklungs-Workflow komponiert sich aus mehreren Schichten:

flowchart TB
    O[Claude Code
Orchestrator]
    O --> MCP[MCP-Server / Werkzeuge]
    O --> SK[Skills /
wiederholbare Tasks]
    O --> SA[Subagenten /
Orchestrierung]
    MCP --> M1[Issue-Tracker]
    MCP --> M2[Git-Hosting / PRs]
    MCP --> M3[CI/CD]
    MCP --> M4[IDE-Index Semantik]
    MCP --> M5[Wiki / Mail]

MCP-Server binden externe Systeme als Werkzeuge ein, Skills kapseln wiederkehrende Abläufe, Subagenten übernehmen mehrstufige Aufgaben. Die Compliance-Implikation: Jede Schicht erhöht den mitgesendeten Kontext. Daher in regulierten Umgebungen den aktiven Kontext minimieren, nach Vertrauensstufe isolieren, lokale/EU-seitige Werkzeuge bevorzugen (ein lokaler IDE-Index liefert Grounding ohne Egress) und Deferred Loading nutzen, sodass Werkzeug-Schemas nur bei Bedarf geladen werden.

7. Kosten: Prompt-Caching als Haupthebel

Agentische Sessions sind input-lastig, der Agent sendet den wachsenden Kontext in jeder Runde erneut. Der größte Kostenhebel ist Prompt-Caching: Der stabile Präfix (System-Anweisungen plus Werkzeug-Schemas) wird zwischengespeichert, Cache-Lesezugriffe kosten nur einen Bruchteil des normalen Input-Preises. Weitere Hebel: günstige/kleine Modelle für Hintergrund- und Routine-Aufgaben, das Flaggschiff nur für die harten Fälle; frische Sessions pro Aufgabe, statt eine monatelange Session mitzuschleppen, die den Kontext und damit die Cache-Read-Menge aufbläht; und real messen statt schätzen.

8. Fallstricke in der Praxis

• Kontext-Leak über geteilte Verzeichnisse ist der häufigste Fehler. Lösung: Isolation pro Vertrauensstufe.
• Resume/Continue über Backends spielt Verlauf in das falsche Backend.
• Telemetrie: Auch bei EU-Inferenz kann der Harness Metadaten an den Anbieter senden, sofern nicht unterdrückt.
• Pseudonymisierung wird fälschlich für Anonymisierung gehalten.
• Tool-Calling lokaler Modelle ist weniger zuverlässig.
• Modell-Regions-Verfügbarkeit: neueste Modelle nicht überall „in-region”.
• Lieferkette der Werkzeuge: Gateway- und Proxy-Software auf bekannte, saubere Versionen pinnen.

9. Compliance-Checkliste

• Datenklasse pro Arbeitsverzeichnis festgelegt
• Backend passend zur Datenklasse (lokal / EU-Flaggschiff / EU-Proxy)
• DPA/AVV mit dem Modellanbieter vorhanden (Tier B/C)
• EU-Region bzw. EU-Datengrenze verifiziert (Tier B/C)
• Isoliertes Konfigurationsverzeichnis je Vertrauensstufe
• Kein Resume/Continue über Backends hinweg
• Nicht-essentielle Telemetrie deaktiviert
• Training-Opt-out, History/Protokollierung gemäß Vorgabe
• Menschliche Prüfpflicht etabliert
• Keine personenbezogenen Daten in nicht freigegebene Dienste
• Werkzeug-Lieferkette gepinnt und geprüft

10. Fazit

Claude Code DSGVO-konform zu betreiben ist machbar: KI-gestützte Entwicklung und deutscher Datenschutz schließen sich nicht aus, aber der Standardbetrieb eines Coding-Agenten ist für sensible Kontexte ungeeignet. Der Weg führt über drei Bausteine: die richtige Backend-Wahl je Datenklasse, eine konsequente Kontext-Isolation, damit interne Anweisungen und Werkzeug-Schemas nicht ungewollt abfließen, und eine ehrliche Einordnung dessen, was Maskierung leisten kann. Claude Code bringt die nötigen Schalter bereits mit: isolierte Konfigurationsverzeichnisse, EU-Endpunkte, deaktivierte Telemetrie und ein schlanker Umschalt-Wrapper ergeben ein Setup, das die Kriterien öffentlicher KI-Leitfäden erfüllt, ohne auf die Produktivität agentischer Workflows zu verzichten.

Dieser Artikel beschreibt eine allgemeine Referenzarchitektur und ersetzt keine rechtliche Beratung. Verbindlich sind die Vorgaben der jeweils zuständigen Datenschutz- und IT-Sicherheitsverantwortlichen.