Claude Code lokal und DSGVO-konform: Rechte begrenzen, Secrets sichern, Kosten

TL;DR

Claude Code ist der produktivste Coding-Agent auf dem Markt — und genau deshalb das heikelste Werkzeug im Unternehmen: Das CLI nimmt sich Zugriff auf den gesamten Benutzerkontext, liest Config-Dateien mit und kann Secret-Verbindungsdaten sehen, ohne zu fragen. Die naheliegende Gegenwehr (Sandbox plus Remote Desktop) macht Visual Studio unbrauchbar und bremst das Team aus. Es gibt aber einen dritten Weg: Claude Code mit begrenztem Dateizugriff auf einem eigenen Server, lokale oder EU-gehostete Modelle über OpenAI-kompatible APIs und Secrets, die nie im Code liegen. Der Betrieb bleibt lokal bzw. in der EU, die Rechte sind per Permission-System und Sandboxing eingrenzbar, und die Kosten liegen bei einer eigenen GPU-Runtime meist unter den laufenden API-Kosten. Dieser Artikel zeigt, wie der Umbau konkret aussieht — inklusive Kosten-Tabelle, DSGVO-Einordnung und Entscheidungsmatrix.

Warum Claude Code im Unternehmen ein Kontrollproblem ist

Wer Claude Code in einem Unternehmen einführt, stößt schnell auf dasselbe Muster, das auch IT-Sicherheitsverantwortliche aus Kundengesprächen kennen: Die Chat-Variante von Claude lässt sich auf einen Ordner begrenzen — versucht das Modell mehr als erlaubt, kommt eine Abfrage. Claude Code dagegen arbeitet im vollen Benutzerkontext: Es liest Dateien, führt Befehle aus, schreibt Änderungen. Die Rechte, die es sich nimmt, hängen von den gesetzten Permissions ab — und im Standard-Setup sind die weit gefasst.

Drei konkrete Risiken fallen in der Praxis immer wieder:

1. Volle Kontext-Übernahme: Das Tool sieht alles, was der Entwickler sieht: Quellcode, interne Doku, Mails im Terminal, Konfigurationen.
2. Secrets im Code: Connection Strings, API-Keys und Passwörter liegen in vielen Unternehmen in Config-Dateien — direkt neben dem Code, den der Agent liest. Ein Zero-Trust-Zugriff auf die Datenbank nützt wenig, solange der Connection String im Repo liegt.
3. Kommunikation mit der Cloud: Standardmäßig sendet Claude Code Anfragen an Anthropics API. Welche Daten dabei den Rechner verlassen, hängt von der Konfiguration ab — für viele Datenschutzbeauftragte ist das bereits der Knock-out.

Deshalb wird in deutschen Unternehmen häufig der Ausweg gewählt, der alles schlimmer macht: Sandbox plus Remote Desktop. Der Entwickler arbeitet auf einem Server, der Zugriff ist gekapselt, aber die tägliche Arbeit wird unbrauchbar — lokale IDEs laufen nicht mehr, der Arbeitsweg ist umständlich, die Produktivität fällt. Das ist der falsche Hebel. Besser: Claude Code so konfigurieren, dass es die Rechte nicht bekommt.

Die drei Betriebsmodelle im Vergleich

Die dritte Variante ist der Sweet Spot: Claude Code bleibt als Werkzeug erhalten (Bedienung, Skills, Agenten-Loop), aber das Modell dahinter läuft über einen OpenAI-kompatiblen Endpunkt im eigenen Netz — etwa Ollama auf einer GPU-Workstation, vLLM auf einem kleinen GPU-Server oder ein EU-gehosteter Endpunkt. Für das Tool ist das nur eine Basis-URL, für Datenschutz und Revision die entscheidende Grenze: Personenbezogene Daten und Quellcode verlassen das Unternehmensnetz nicht mehr.

So begrenzen Sie die Rechte von Claude Code

1. Permissions hart setzen (nicht alles erlauben)

Claude Code bringt ein Permission-System mit. Im ersten Start fragt das Tool, ob es Befehle ausführen und Dateien schreiben darf. Wählen Sie nicht „Auto-accept", sondern:

• editing und bash auf „Ask" stellen, bis der Workflow steht
• Benutzerdefinierte Regeln (CLAUDE.md) nutzen, die festlegen, welche Pfade gelesen und geschrieben werden dürfen
• Bei strengen Lagen: nur lesenden Zugriff auf Produktionspfade, Schreiben nur in Arbeitsverzeichnisse

2. Sandboxing ohne Remote Desktop

Statt den Entwickler auf einen Remote-Desktop zu verbannen, kapselt man die Ausführung:

• Eigene GPU-Workstation im Büro oder RZ: Claude Code läuft lokal, der Dateizugriff bleibt auf die Projektordner begrenzt, die IDE bleibt lokal.
• Container- oder VM-Sandbox: Ein schlanker Container (z. B. mit Podman oder Docker) begrenzt, was der Agent im Netzwerk und Dateisystem darf. Der Entwickler nutzt seine lokale IDE, der Agent rechnet daneben.

Wichtig ist der Unterschied: Die Sandbox begrenzt die Umgebung, das Permission-System begrenzt die Rechte des Modells. Beide zusammen ergeben die Kontrolle, die ein Datenschutzbeauftragter sehen will.

3. Secrets aus dem Code holen

Der wunde Punkt, der in Kundengesprächen am häufigsten auftaucht: Connection Strings liegen in Config-Dateien, Claude Code liest sie mit. Die Lösung ist keine Datenbank-Feuerwehr, sondern ein sauberer Umgang mit Zugangsdaten:

• Zentrale Speicherung: Secrets in einen zentralen Vault (z. B. HashiCorp Vault, cloudflared, oder ein einfacher, abgesicherter Secrets-Store) legen — nicht in Config-Dateien des Repos.
• Keyword-Store je Umgebung: Entwicklung, Test, Produktion haben getrennte Zugangsdaten, die nur die jeweilige Umgebung zur Laufzeit erhält.
• Härtung: Secrets aus den Repos entfernen (History prüfen!), Tokens rotieren, Zugriff per Rollen statt pro Person.

Dann kann Claude Code aus dem Code keine Zugangsdaten mehr lesen — schlicht, weil keine mehr dort liegen.

4. Netzwerk kontrollieren

Standardmäßig telefoniert Claude Code mit der Anthropic-API. Wenn das Modell lokal läuft, entfällt dieser Verkehr. Der einfachste Nachweis für die Revision: ausgehende Verbindungen protokollieren. Bei lokalem Betrieb sieht die Firewall-Liste nur noch den eigenen Server — kein Traffic zu US-Endpunkten. Wer ganz sicher gehen will, blockiert auf dem Entwickler-Rechner ausgehende Verbindungen zu Fremd-Endpunkten per Firewall-Regel und erlaubt nur das lokale Gateway.

DSGVO-Einordnung: lokal statt Drittland

Der zentrale DSGVO-Vorteil des lokalen Betriebs ist struktureller Natur:

• Kein Drittlandtransfer (Art. 44 ff. DSGVO): Verlassen personenbezogene Daten (Quellcode enthält oft Namen, Kundendaten, Betriebsgeheimnisse) das Unternehmensnetz nicht, gibt es keinen Transfer in die USA und keine Notwendigkeit für Standardvertragsklauseln oder Angemessenheitsbeschlüsse, deren Bestand politisch wackelt.
• Keine Auftragsverarbeitung mit dem Modellanbieter: Bei lokalem Modell entfällt die AVV mit dem Cloud-Anbieter für die Verarbeitung; die Verantwortung bleibt vollständig beim Unternehmen.
• Kein Training mit Ihren Daten: Bei Cloud-Nutzung hängt es vom Vertrag ab, ob Eingaben zum Training verwendet werden. Lokal ist diese Frage vom Tisch.

Wo Sie trotzdem aufpassen müssen:

• CLAUDE.md und Logs: Auch lokale Systeme schreiben Protokolle. Stellen Sie sicher, dass Agent-Logs keine Secrets oder personenbezogenen Daten dauerhaft speichern.
• AVV bei externem Betrieb: Betreibt ein IT-Dienstleister den Server, brauchen Sie mit ihm einen Auftragsverarbeitungsvertrag (Art. 28 DSGVO) — unabhängig vom Modell.
• Betriebsrat (BetrVG § 87): Agentic-Coding-Systeme protokollieren Tätigkeiten; sobald Leistungs- oder Verhaltenskontrolle möglich ist, ist die Einführung mitbestimmungspflichtig. Details: Claude Code und Betriebsrat: Mitbestimmung.

Kosten-Tabelle: lokal vs. API

Die Ersparnisrechnung: Ein 8-köpfiges Entwicklungsteam mit Pro-Abos kostet ~160–800 EUR/Monat plus API-Verbrauch — bei intensiver Nutzung schnell 1.000+ EUR. Eine gebrauchte RTX 3090/4090 (500–2.000 EUR einmalig) trägt ein starkes lokales Coder-Modell für das gesamte Team; amortisiert ist sie nach 2–4 Monaten. Wer keine eigene Hardware will, mietet: der GPU-Server-Vergleich zeigt die Preisspanne. Wichtig für die Modellwahl: Nicht jedes lokale Modell erreicht Opus-Qualität beim Coding. Für Routine-Aufgaben (Refactoring, Tests, Boilerplate) reichen lokale Coder-Modelle in der Praxis sehr oft — für komplexe Architektur-Aufgaben behält man sich eine kontrollierte Cloud-Lizenz mit AVV vor. Ausführlicher Vergleich: Claude Code vs. OpenCode im Praxistest.

Praxis-Setup: Claude Code mit lokalem Modell in einem Tag

Der Umbau ist kein mehrtägiges Projekt, sondern ein Tag Arbeit — das bestätigt auch die Erfahrung aus Kundengesprächen, in denen ein „Tag Klarheit" vor dem großen Programm gewünscht war:

1. Hardware klären: GPU mit 24 GB VRAM (RTX 3090/4090) oder Miet-GPU-Server (Details: Eigener KI-Server: Hardware-Guide 2026). Alternativ EU-Modell-API.
2. Ollama oder vLLM installieren und ein starkes Coder-Modell laden (z. B. Qwen-3.5-Coder-30B, DeepSeek-Coder-V2, Llama-3.3-70B bei 2×24 GB). Ollama stellt eine OpenAI-kompatible API bereit — genau das, was Claude Code als Endpunkt erwartet. Anleitung: Ollama installieren (Ubuntu, 2026).
3. Secrets bereinigen: Connection Strings aus Config-Dateien in einen Vault ziehen, Tokens rotieren, Repo-History prüfen.
4. Claude Code auf den lokalen Endpunkt zeigen lassen (ANTHROPIC_BASE_URL beziehungsweise OpenAI-kompatible Konfiguration) und Permissions auf „Ask" setzen.
5. Firewall prüfen: Ausgehenden Verkehr zu Anthropic blockieren, Log zeigen lassen, Test-Session mit einem echten Projekt fahren.
6. Nachweis dokumentieren: Wer welche Rechte hat, welche Daten wohin fließen, wer das Risiko trägt. Das ist die Checkliste, die der Chef und der Datenschutzbeauftragte sehen wollen.

Entscheidungsmatrix

Fazit

Claude Code muss im Unternehmen weder verboten noch durch Remote-Desktop-Sandboxen unbrauchbar gemacht werden. Der saubere Weg ist: Rechte hart setzen, Secrets aus dem Code holen, Modell lokal oder in der EU betreiben. Damit bleibt die Produktivität des Tools erhalten, während Datenverarbeitung und Vertragslage DSGVO-konform werden. Der Umbau kostet einen Tag und eine GPU — und erspart die Diskussion mit dem Datenschutzbeauftragten, die jedes Cloud-Coding-Tool im Standard-Setup auslöst.

Sie wollen Claude Code sicher einführen oder den lokalen Betrieb aufsetzen? Wir unterstützen bei Hardware-Auswahl, Secrets-Migration und DSGVO-Ausgestaltung — auch als eintägiger Workshop mit klarer Checkliste für die Entscheidung.

Sprechen Sie uns an →

FAQ

Ist Claude Code mit lokalen Modellen nutzbar?

Ja. Claude Code akzeptiert OpenAI-kompatible Endpunkte. Ollama und vLLM stellen solche APIs bereit; damit läuft Claude Code gegen ein lokales Modell (z. B. Qwen-3.5-Coder, DeepSeek, Llama-3.3), ohne dass Daten zu Anthropic fließen. Die Bedienung und die Agenten-Funktionen bleiben gleich.

Was bedeutet „Claude Code nimmt sich alle Rechte"?

Claude Code arbeitet im Benutzerkontext: Es kann Dateien im erlaubten Umfang lesen/schreiben und Befehle ausführen. Ohne harte Permissions und ohne Sandbox sieht es auch Config-Dateien mit Secrets. Die Lösung: Permission-System voll ausschöpfen, Arbeitsverzeichnisse festlegen, Secrets aus dem Code entfernen und die Ausführung bei Bedarf in einen Container kapseln.

Sind Sandbox und Remote Desktop nötig?

Nein. Sandboxing der Ausführung (Container/VM) ist sinnvoll, aber das Remote-Desktop-Konstrukt — IDE auf dem Server, Arbeiten über RDP — ist keine DSGVO-Pflicht, sondern eine Komfort-Abschaltung. Besser: lokale IDE plus gekapselte Agent-Ausführung plus lokales Modell. Mehr dazu im Artikel zur Sandbox im eigenen Netz und zu DGX Spark: Claude Code lokal mit 128 GB.

Ist Claude Code mit der US-Cloud DSGVO-konform?

Grundsätzlich ja, wenn ein Auftragsverarbeitungsvertrag (Art. 28 DSGVO) geschlossen wird und die Datenübertragung auf einen anerkannten Mechanismus (SCCs oder Angemessenheitsbeschluss für die USA) gestützt wird. In der Praxis scheitert die Freigabe aber oft an der Unsicherheit des Drittlandtransfers und daran, dass Quellcode als Geschäftsgeheimnis gilt. Lokaler Betrieb umgeht diese Diskussion vollständig. Vertiefung: Claude Enterprise: DSGVO und AVV in der Praxis.

Was kostet Claude Code lokal?

Die einmaligen Kosten dominieren: gebrauchte RTX 3090/4090 für 500–2.000 EUR oder Miet-GPU-Server ab ~250 EUR/Monat in Deutschland. Laufend kommen nur Strom, Wartung und ggf. der Server-Hoster hinzu. Gegenüber Cloud-APIs (20–150 EUR pro Entwickler plus Verbrauch) amortisiert sich eigene Hardware meist nach wenigen Monaten. Hardware-Auswahl: KI-Server: GPU-VRAM-Rechner.

Wie komme ich an die Connection Strings, bevor Claude Code sie sieht?

Ein Vault mit zentraler Speicherung (z. B. HashiCorp Vault, Secrets-Manager oder schlicht ein restriktiv berechtigtes Netzlaufwerk mit Verschlüsselung), getrennte Credentials je Umgebung, Rotation nach der Migration und Repo-History-Bereinigung. Dann kann kein Agent mehr Zugangsdaten aus dem Code lesen — und Zero Trust an der Datenbank wird erst damit wirklich wirksam. Anleitung zur sicheren Verwaltung: Claude Vault: Zugangsdaten sicher verwalten.

Weiterführende Artikel:

• DGX Spark: Claude Code lokal mit 128 GB — das Hardware-Setup für Private AI
• Claude im Unternehmen: die CISO-Checkliste — die sieben Kontrollpunkte vor der Freigabe
• Ollama Cloud vs. lokal: Kosten und DSGVO — Cloud-API oder eigener Server?
• Claude Code vs. OpenCode: Praxistest — welche Coding-Agenten im Unternehmen zählen
• Claude Enterprise: DSGVO und AVV in der Praxis — Vertragslage für Firmenkunden
• Eigener KI-Server: Hardware-Guide 2026 — vom Office-PC bis zum RZ-Server