Claude Code DSGVO‑konform nutzen

Begleit‑Repository zum YouTube‑Video „Claude Code DSGVO konform nutzen: nur SO!".

Dieses Repo zeigt an einem winzigen Beispiel (app.py – eine fehlerhafte Flask‑Fakultäts‑App), wie du Claude Code nutzen kannst, ohne dass dein Code an Anthropic in den USA wandert. Du bekommst vier vorbereitete Konfigurationen, zwischen denen du per Skript umschalten kannst:

#	Variante	Wo läuft das Modell?	DSGVO‑Tauglichkeit
1	AWS Bedrock (EU)	AWS‑Region eu-central-1 (Frankfurt)	✅ AVV mit AWS möglich
2	Azure OpenAI über LiteLLM	Azure‑Region z. B. „Germany West Central"	✅ AVV mit Microsoft möglich
3	Self‑hosted Ollama auf dedizierter GPU (z. B. Trooper AI)	Eigener Server in Deutschland	✅ Volle Kontrolle
4	Lokales Ollama auf deinem Rechner	Dein Laptop	✅ Daten verlassen den Rechner nie

⚠️ DSGVO ist mehr als „Server in Europa". Du brauchst zusätzlich einen Auftragsverarbeitungsvertrag (AVV/DPA) mit dem jeweiligen Anbieter, ein TOMs‑Konzept und ggf. einen Eintrag im Verarbeitungsverzeichnis. Dieses Repo zeigt nur den technischen Teil.

---

Inhalt des Repos

.
├── app.py                          # Beispiel-Flask-App mit Bugs
├── prompt.txt                      # Prompt, den du Claude Code geben sollst
├── pyproject.toml                  # Python-Dependencies (flask, litellm)
├── .claude/
│   ├── settings.aws-bedrock.json   # Template AWS Bedrock
│   ├── settings.azure-openai.json  # Template Azure OpenAI (über LiteLLM)
│   ├── settings.ollama-local.json  # Template lokales Ollama
│   └── settings.ollama-remote.json # Template self-hosted Ollama
├── litellm/
│   └── config.yaml                 # LiteLLM-Proxy-Config für Azure
├── setenv-azure-openai.example.sh  # Template für Azure-Secrets
├── use-config.sh                   # Helper: aktive Config umschalten
├── start-litellm.sh                # Helper: LiteLLM-Proxy starten
└── README.md

---

Voraussetzungen

1. Claude Code installieren

   # Mac / Linux
   curl -fsSL https://claude.ai/install.sh | bash
   
   # Windows (PowerShell)
   irm https://claude.ai/install.ps1 | iex

2. Repo klonen

   git clone <URL-deines-Forks>
   cd code-quality-check

3. Python‑Umgebung (nur nötig für die Azure‑Variante mit LiteLLM)

   # Empfohlen: uv  (https://docs.astral.sh/uv/)
   uv sync
   source .venv/bin/activate

---

Konfiguration aktivieren – das gemeinsame Prinzip

Claude Code liest seine Provider‑Einstellungen aus .claude/settings.json. Im Repo findest du eine vorbereitete Vorlage je Variante. Aktivieren tust du sie mit:

./use-config.sh aws-bedrock      # oder
./use-config.sh azure-openai     # oder
./use-config.sh ollama-local     # oder
./use-config.sh ollama-remote

Das Skript kopiert .claude/settings.<name>.json nach .claude/settings.json. .claude/settings.json ist in .gitignore – deine Secrets landen also nicht im Repo.

Danach öffnest du Claude Code im Projektverzeichnis:

claude

und gibst den Prompt aus prompt.txt ein:

Finde bis zu 5 problematische Stellen in der app.py Datei und fasse diese kurz zusammen mit Begründung und was man besser machen sollte.

---

Variante 1 – AWS Bedrock (EU)

Use case: Du willst echte Claude‑Modelle (Sonnet, Haiku, Opus) nutzen, aber DSGVO‑konform über die EU‑Region.

Setup

1. AWS‑Account anlegen und auf einen bezahlten Tarif upgraden. Reines Free‑Tier reicht für Anthropic‑Modelle nicht.

2. In der AWS‑Konsole oben rechts Region auf „Europe (Frankfurt) – eu-central-1" stellen.

3. Bedrock → Model access öffnen, die gewünschten Anthropic‑Modelle anfragen (Anthropic fragt nach einem Use Case – z. B. „Code Quality Check").

4. IAM‑User mit Policy AmazonBedrockFullAccess (oder enger) anlegen und Access Key + Secret Access Key erzeugen.

5. Template aktivieren und Schlüssel eintragen:

   ./use-config.sh aws-bedrock
   # dann .claude/settings.json öffnen und DEIN_AWS_ACCESS_KEY_ID /
   # DEIN_AWS_SECRET_ACCESS_KEY ersetzen

6. Claude Code starten:

   claude

💡 In den Settings ist bereits konfiguriert:

• CLAUDE_CODE_USE_BEDROCK=true
• Default‑Modelle: eu.anthropic.claude-sonnet-4-6, …haiku-4-5, …opus-4-7
• Region: eu-central-1

---

Variante 2 – Azure OpenAI über LiteLLM

Use case: Dein Unternehmen hat bereits einen Azure‑Tenant inkl. AVV mit Microsoft. Claude Code spricht aber nur das Anthropic‑Protokoll. Lösung: ein lokaler LiteLLM‑Proxy, der Anthropic‑Calls in Azure‑OpenAI‑Calls übersetzt.

┌────────────┐   Anthropic API      ┌─────────────┐   Azure OpenAI API   ┌──────────────┐
│ Claude Code│ ───────────────────▶ │   LiteLLM   │ ───────────────────▶ │ Azure OpenAI │
└────────────┘ http://0.0.0.0:4000  └─────────────┘                      └──────────────┘

Setup

1. Azure‑Deployment für ein Chat‑Modell (z. B. gpt-4.1-mini) in einer EU‑Region anlegen.

2. Endpoint + Key aus dem Azure‑Portal kopieren.

3. Secrets‑Skript vorbereiten:

   cp setenv-azure-openai.example.sh setenv-azure-openai.sh
   # setenv-azure-openai.sh öffnen und Werte eintragen:
   #   AZURE_API_KEY        – aus Azure Portal
   #   AZURE_API_BASE       – vollständige URL inkl. /chat/completions?api-version=…
   #   LITELLM_MASTER_KEY   – frei wählbares Token (z. B. sk-1234567890)

   Die Datei setenv-azure-openai.sh ist gitignored.

4. Variablen laden + LiteLLM‑Proxy starten (in Terminal A):

   source ./setenv-azure-openai.sh
   ./start-litellm.sh

   LiteLLM lauscht jetzt auf http://0.0.0.0:4000. Die Modell‑Definitionen liegen in litellm/config.yaml.

5. Claude‑Code‑Config aktivieren (in Terminal B):

   ./use-config.sh azure-openai
   claude --model azure-gpt-4.1-mini

   Der Modellname azure-gpt-4.1-mini muss zu einem model_name in litellm/config.yaml passen. Weitere Modelle einfach dort ergänzen.

---

Variante 3 – Self‑hosted Ollama (z. B. Trooper AI)

Use case: Du willst Open‑Source‑Modelle (Qwen3, Llama, …) auf einer eigenen GPU laufen lassen – z. B. einer dedizierten Cloud‑GPU bei Trooper AI.

Setup auf dem Server

1. SSH auf den Server:

   ssh user@dein-server -p <port>

2. Ollama installieren (einmalig):

   curl -fsSL https://ollama.com/install.sh | sh

3. Ollama so starten, dass es von außen erreichbar ist:

   export OLLAMA_HOST=0.0.0.0:37036       # Port, den dein Provider freigegeben hat
   export OLLAMA_CONTEXT_LENGTH=32000     # größerer Kontext, sonst wird Code abgeschnitten
   ollama serve

4. Gewünschtes Modell ziehen (in einer zweiten Shell auf dem Server):

   ollama pull qwen3.6:27b

Setup lokal

1. Template aktivieren:

   ./use-config.sh ollama-remote

2. .claude/settings.json öffnen und anpassen:

   • ANTHROPIC_BASE_URL → http://<dein-server>:<port> (z. B. http://connect02.trooper.ai:37036)
   • ANTHROPIC_MODEL → exakt der Modellname, den du gepullt hast (z. B. qwen3.6:27b)

3. Starten:

   claude --model qwen3.6:27b

🔒 Sicherheits‑Hinweis: Mit OLLAMA_HOST=0.0.0.0 ist deine Ollama‑Instanz offen. Schütze sie über Firewall, VPN oder einen Reverse‑Proxy mit Auth (z. B. Caddy + Basic Auth).

---

Variante 4 – Lokales Ollama (auf deinem Rechner)

Use case: Maximaler Datenschutz, kein Server, kein Cloud‑Account. Geht nur mit kleineren Modellen (RAM/VRAM‑abhängig).

Setup

1. Ollama installieren:

   # Mac / Linux
   curl -fsSL https://ollama.com/install.sh | sh
   
   # Windows (PowerShell)
   irm https://ollama.com/install.ps1 | iex

2. Modell pullen (Beispiel – wähle ein für deine Hardware passendes):

   ollama pull qwen3.5:4b

3. Ollama läuft als Service automatisch auf http://localhost:11434. Falls nicht: ollama serve starten.

4. Template aktivieren und ggf. den Modellnamen in .claude/settings.json anpassen:

   ./use-config.sh ollama-local

5. Claude Code starten:

   claude --model qwen3.5:4b

---

Zwischen Konfigurationen wechseln

Das Helper‑Skript macht das Umschalten in einem Befehl möglich:

./use-config.sh                  # zeigt alle verfügbaren Configs
./use-config.sh ollama-local
./use-config.sh aws-bedrock

Die jeweils aktive Datei ist immer .claude/settings.json.

---

Den Test ausführen

Egal welche Variante aktiv ist – im Projektverzeichnis:

claude

Dann den Inhalt aus prompt.txt reinpasten:

Finde bis zu 5 problematische Stellen in der app.py Datei und fasse diese kurz zusammen mit Begründung und was man besser machen sollte.

So kannst du die Antwortqualität und Geschwindigkeit verschiedener Modelle direkt vergleichen.

---

Sicherheits‑Checklist vor dem git push

• Keine echten API‑Keys in .claude/settings.*.json (Templates) – nur DEIN_*‑Platzhalter.
• setenv-azure-openai.sh existiert nur lokal (gitignored), committed wird ausschließlich setenv-azure-openai.example.sh.
• .claude/settings.json ist in .gitignore und wird nicht committet.
• Ein git status vor dem ersten Push zeigt keine der oben genannten Dateien an.
• Falls du jemals einen echten Key committet hast: Key sofort beim Anbieter rotieren und Git‑Historie bereinigen (z. B. mit git filter-repo).

---

Lizenz

MIT