Claude DSGVO-konform einrichten

Ziel: Claude nutzen ohne dass Daten die EU verlassen. Kein SCC-Geturne, kein USA-Transfer. Backend ist AWS Bedrock in Frankfurt, Frontend ist selbst-gehostetes LibreChat.

Zielzeit für Erstinstallation: 20-30 Minuten, wenn AWS-Account bereits existiert.

Warum dieser Stack

  • AWS Bedrock eu-central-1 (Frankfurt) — echte EU-Datenverarbeitung, kein Drittlandtransfer. AVV (Data Processing Addendum) ist Standard-Bestandteil des AWS Customer Agreement, muss nicht separat verhandelt werden.
  • LibreChat — Open Source, Docker-basiert, fühlt sich an wie claude.ai (Chats, Projects, File-Upload). Läuft lokal oder auf Hetzner.
  • Kosten — pay-per-token, keine Abo-Falle. Typischer Einzelnutzer: 5-20 €/Monat.

Was das NICHT löst: Wenn du Kundendaten in Chats packst, brauchst du trotzdem AVV mit dem Kunden + Verarbeitungsverzeichnis nach Art. 30 DSGVO. Dieser Setup macht nur den technischen Unterbau sauber.

Voraussetzungen

  • AWS-Account (neu anlegen: aws.amazon.com — Kreditkarte nötig, Free-Tier deckt Login aber nicht Bedrock ab)
  • Docker + Docker Compose lokal installiert (macOS: brew install --cask docker)
  • Terminal-Grundkenntnisse
  • Ca. 30 Min Zeit beim ersten Mal

Schritt 1 — Bedrock Model Access in Frankfurt freischalten

  1. In AWS-Console einloggen und Region oben rechts auf „Europa (Frankfurt) eu-central-1” umstellen. Wichtig: wenn du in einer anderen Region freischaltest, nützt das für DSGVO nichts.
  2. Direkt-Link: console.aws.amazon.com/bedrock/home?region=eu-central-1#/modelaccess
  3. Bei „Anthropic” auf Manage model access → Haken setzen bei Claude 3.5 Sonnet und Claude 3.7 Sonnet (bzw. was aktuell in EU verfügbar ist — die Liste ändert sich).
  4. Use case ausfüllen: „Internal productivity tool, no personal data without consent, EU-only processing.” — kurzer Text reicht.
  5. Request model access → meist in 1-5 Minuten genehmigt. Status wird „Access granted”.

Wichtig zu wissen: Nicht alle Claude-Modelle sind in Frankfurt verfügbar. Opus-Varianten kommen oft Wochen bis Monate später. Für 95 % der Arbeit reicht Sonnet.

Schritt 2 — IAM-User mit Bedrock-Rechten

  1. In die IAM-Console wechseln.
  2. Users → Create user → Name z.B. librechat-bedrock.
  3. Permissions → Attach policies directlyAmazonBedrockLimitedAccess auswählen (reicht für Inference). Wer es strikter will: Custom Policy mit nur bedrock:InvokeModel auf die Claude-Modell-ARNs.
  4. User erstellen → Security credentials → Create access key → Use case: „Application running outside AWS” → Access Key ID und Secret Access Key sofort speichern (Secret wird nur einmal angezeigt).

Keys gehen später in .env — nie ins Git, nie in die librechat.yaml hardcoden.

Schritt 3 — LibreChat via Docker starten

Einen neuen Ordner anlegen:

mkdir -p ~/source/librechat-dsgvo && cd ~/source/librechat-dsgvo

docker-compose.yml und Default-Config holen:

curl -o docker-compose.yml https://raw.githubusercontent.com/danny-avila/LibreChat/main/docker-compose.yml
curl -o .env.example https://raw.githubusercontent.com/danny-avila/LibreChat/main/.env.example
cp .env.example .env

In .env diese Werte setzen (rest unverändert lassen):

# AWS Bedrock
BEDROCK_AWS_ACCESS_KEY_ID=AKIA...
BEDROCK_AWS_SECRET_ACCESS_KEY=...
BEDROCK_AWS_DEFAULT_REGION=eu-central-1
 
# Registrierung auf dich selbst beschränken
ALLOW_REGISTRATION=false
ALLOW_EMAIL_LOGIN=true

Schritt 4 — librechat.yaml mit Bedrock-Endpoint

Im gleichen Ordner librechat.yaml anlegen:

version: 1.2.8
cache: true
 
endpoints:
  bedrock:
    availableRegions:
      - "eu-central-1"
    models:
      default:
        - "anthropic.claude-3-5-sonnet-20241022-v2:0"
        - "anthropic.claude-3-7-sonnet-20250219-v1:0"
    streamRate: 35
    titleModel: "anthropic.claude-3-5-sonnet-20241022-v2:0"

Die Model-IDs in AWS Bedrock Console unter Model catalog rauskopieren — die ändern sich manchmal wenn neue Versionen kommen.

Schritt 5 — Starten und erster Chat

docker compose up -d

Nach ca. 30 Sekunden läuft LibreChat auf http://localhost:3080. Account anlegen, einloggen, oben im Model-Dropdown Bedrock → Claude 3.5 Sonnet auswählen.

Der Beweis-Moment fürs Video: In AWS CloudTrail (console.aws.amazon.com/cloudtrail/home?region=eu-central-1) siehst du den InvokeModel-Call mit awsRegion: eu-central-1. Das ist der visuelle Payoff — der Request geht nachweislich nach Frankfurt und nirgendwo anders.

Schritt 6 — Compliance-Aufräumarbeit

Technisch fertig, aber für echte DSGVO-Konformität noch:

  1. AWS AVV bestätigen — im AWS Artifact (console.aws.amazon.com/artifact) das „AWS GDPR Data Processing Addendum” herunterladen und ablegen.
  2. Verarbeitungsverzeichnis ergänzen — Eintrag „KI-gestützte Textverarbeitung, Auftragsverarbeiter AWS EMEA SARL, Rechenzentrum Frankfurt”.
  3. Zweckbindung dokumentieren — wofür nutzt du Claude, welche Datenkategorien landen da. Kurze Notiz reicht für Ein-Mann-Firma.
  4. Keine personenbezogenen Kundendaten ohne AVV mit dem Kunden. Bedrock-Setup alleine legitimiert das nicht.

Deployment-Optionen

  • Lokal — nur für einen Nutzer (dich). Keine öffentliche URL. Am sichersten.
  • Hetzner Cloud — CX22 für ~5 €/Monat, Docker installiert, LibreChat drauf, Traefik + Let’s Encrypt für HTTPS. Sinnvoll wenn du mobil drauf willst oder ein Team mitnutzt. Siehe claude-remote-server.md für SSH/Reverse-Proxy-Muster.
  • Firmen-Setup — mit LDAP/SSO-Integration, Multi-User, Audit-Logs. Für Kunden wie Becker Stahl oder Vibe Factory wäre das die nächste Ausbaustufe.

Fallstricke

  • Falsche Region gewählt. Wenn du versehentlich us-east-1 freischaltest, geht der DSGVO-Vorteil flöten. Immer eu-central-1 verifizieren.
  • Model nicht verfügbar. Fehler AccessDeniedException: You don't have access to the model → Schritt 1 nicht abgeschlossen oder falsche Region.
  • Throughput-Limits. Bedrock hat per Default niedrige Quotas in EU (ca. 20 RPM für Sonnet). Für intensive Nutzung: Service Quotas → Request increase.
  • Modell-Aktualität. Opus 4.x kommt in EU immer später als in US. Wenn du zwingend das neueste Modell brauchst, ist Bedrock EU nicht der richtige Weg — dann aber auch keine EU-Lösung möglich.
  • LibreChat-Version. Config-Syntax ändert sich zwischen Versionen. Bei Problemen Git-History der LibreChat-Docs checken.

Was dieser Setup NICHT ist

  • Kein Ersatz für Rechtsberatung. Die Setup-Mechanik ist sauber, die juristische Würdigung im konkreten Kundenkontext (Datenkategorien, Betroffenenrechte, Löschkonzept) braucht ggf. einen DSB.
  • Kein automatischer Schutz vor Prompt-Leaks. Wenn du Mandantendaten in einen Prompt schreibst, bleiben die in den Logs von LibreChat. Log-Retention in .env begrenzen.
  • Kein Schutz gegen Halluzinationen. DSGVO-Konformität sagt nichts über Output-Qualität.