Warum das Thema ein Multiplikator ist
Jedes deutsche B2B-Projekt, das ich begleite, hat irgendwann diese Sätze: „Können wir das überhaupt mit ChatGPT machen?" oder „Was sagt der Datenschutzbeauftragte dazu?". Wer hier keine Antwort hat, fliegt aus der Engeren Auswahl. Wer eine hat, gewinnt das Mandat.
Dieser Artikel zeigt die rechtliche Lage (Stand 2026), die technischen Optionen und Patterns aus laufenden Projekten.
Der Rechtsrahmen — kompakt
Drei Gesetze sind relevant:
- DSGVO — gilt für jede Verarbeitung personenbezogener Daten. Bei LLM-Calls zählen Prompts als Verarbeitung, wenn sie PII enthalten.
- EU-AI-Act — seit 02.02.2025 in Kraft, schrittweise Anwendung. Klassifiziert KI-Systeme nach Risiko (verboten / hochriskant / begrenzt / minimal). Für die meisten B2B-Use-Cases: „begrenztes Risiko" mit Transparenzpflicht.
- NIS2 / KritIS — falls dein Kunde Betreiber kritischer Infrastruktur ist, gelten zusätzliche Pflichten zu Resilienz und Lieferkette.
Praktisch heißt das: Sobald PII in Prompts geht, brauchst du (a) eine Rechtsgrundlage (Art. 6 DSGVO), (b) einen AVV mit dem KI-Provider, (c) idealerweise EU-Hosting oder genug Garantien zur Drittlandsübermittlung.
Option 1: EU-gehostete kommerzielle Modelle
Die pragmatischste Lösung für viele Mid-Size-Projekte:
| Provider | Modelle | Region | AVV-bereit |
|---|---|---|---|
| Azure OpenAI | GPT-4o, GPT-4o-mini, Embeddings | EU-Sweden, EU-France | Ja, mit MS-AVV |
| Mistral La Plateforme | Mistral Large, Pixtral, Codestral | EU (FR) | Ja, native |
| Aleph Alpha | Pharia-1, Luminous | EU (DE) | Ja, native |
| Anthropic via AWS Bedrock | Claude 4.x | EU-Frankfurt | Ja, via AWS-AVV |
Empfehlung für deutsche B2B-Kunden: Azure OpenAI EU oder Mistral. Beide bieten OpenAI-API-Kompatibilität (mit kleinen Anpassungen), AVV vom Tisch, Performance vergleichbar zur US-Cloud-Version.
Achtung: Nur weil dein Provider EU-Hosting anbietet, heißt das nicht, dass alle Features dort sind. Bei Azure OpenAI sind bestimmte neue Modelle erst in US verfügbar, dann mit Wochen Verzögerung in EU.
Option 2: On-Premise mit Open-Source-LLMs
Für maximale Datensouveränität oder regulierte Branchen (Gesundheit, Verteidigung):
# Ollama mit Llama 3.3 70B als API-Server
docker run -d --gpus all -v ollama:/root/.ollama -p 11434:11434 ollama/ollama
docker exec -it ollama ollama pull llama3.3:70b
Realistische Hardware-Anforderungen (2026):
- 8B-Modell: 16 GB VRAM (RTX 4090 / L4) — schnell genug für Customer-Support, ~50 tok/s
- 70B-Modell: 80 GB VRAM (A100 oder 2× RTX 4090 mit
--tensor-parallel) — Reasoning-tauglich, ~20 tok/s - Embeddings: jede konsumer-GPU reicht für
bge-m3odernomic-embed-text
Stromkosten in Deutschland (~0.35 €/kWh): Eine RTX 4090 unter Last zieht ~450 W → ~3.80 €/Tag = ~115 €/Monat. Eine A100 ~250 €/Monat. Vergleich: GPT-4o-API für gleichen Workload ~50–500 €/Monat je nach Last. On-Prem lohnt erst ab konstant hohem Durchsatz.
Quality-Gap: Llama 3.3 70B liegt für viele Tasks im Bereich von GPT-4o-mini, für komplexes Reasoning hinter Claude Opus. Für interne Klassifikation, Zusammenfassungen, Drafting reicht es absolut.
Option 3: Hybrid — On-Prem für PII, Cloud für Reasoning
Das ist meistens die wirtschaftlichste Lösung:
async function classify(text: string) {
// PII-Erkennung lokal
if (containsPII(text)) {
return await localLlama.classify(text); // bleibt on-prem
}
return await openai.classify(text); // public cloud
}
PII-Erkennung kannst du selbst mit presidio (Microsoft Open Source) oder einem feingetunten Mini-Modell machen. Genauigkeit für DE: ~95 % bei Namen, IBANs, Mail-Adressen.
Pattern: Anonymisierung VOR dem Prompt
function anonymize(text: string): { masked: string; map: Record<string, string> } {
const map: Record<string, string> = {};
let masked = text;
for (const match of text.matchAll(NAME_PATTERN)) {
const key = `PERSON_${Object.keys(map).length}`;
map[key] = match[0];
masked = masked.replace(match[0], `[${key}]`);
}
return { masked, map };
}
// Vor LLM-Call:
const { masked, map } = anonymize(userInput);
const llmResponse = await openai.complete(masked);
// Nach LLM-Call:
let finalResponse = llmResponse;
for (const [key, original] of Object.entries(map)) {
finalResponse = finalResponse.replace(`[${key}]`, original);
}
Funktioniert für Tasks wo der LLM die echten Namen nicht braucht (Zusammenfassung, Klassifikation). Bei Tasks wo Namen relevant sind (Brief-Generierung, personalisierte Antworten), ist On-Prem oder EU-Cloud nötig.
Audit-Trail — DSGVO Art. 30
Jeder LLM-Call sollte loggen:
- Zeitstempel
- User-ID (hashed)
- Prompt-Hash + Token-Count (nicht den Inhalt)
- Modell und Region
- Antwort-Hash + Token-Count
In Postgres-Tabelle llm_audit_log. Bei DSGVO-Auskunft kann man dann zeigen: „Daten von User X wurden zu Zeit Y an Provider Z geschickt".
Vertragsrecht: AVV & Drittlandsübermittlung
Auftragsverarbeitungsvertrag (AVV) muss mit jedem Provider abgeschlossen werden, der personenbezogene Daten verarbeitet. Anthropic, OpenAI, Mistral, Aleph Alpha — alle bieten Standard-AVV-Templates.
Bei US-Providern (OpenAI, Anthropic direkt): zusätzlich Standardvertragsklauseln (SCC) und Transfer-Impact-Assessment (TIA). Seit dem EU-US Data Privacy Framework (Juli 2023) ist's einfacher, aber TIA empfohlen.
Pitfalls aus der Praxis
- Provider-Wechsel nicht eingeplant — Vendor-Lockin durch propritäre Function-Calling-Syntax. Lieber LiteLLM oder eigener Abstraction-Layer.
- Embedding-Modell aus US, LLM aus EU — beide müssen DSGVO-konform sein.
- „KI-Klausel" in AGB vergessen — Nutzer müssen über die Verarbeitung durch KI informiert werden (EU-AI-Act, Transparenzpflicht).
- Logs mit Klartext-Prompts speichern — verstößt gegen Datensparsamkeit. Hashes reichen für Audit.
Wann lokales Hosting trotzdem schwierig wird
- Wenn du Multi-Modal brauchst (Vision, Audio) — die offenen Modelle sind 1–2 Jahre hinter Claude/GPT-4o
- Wenn dein Use-Case state-of-the-art Reasoning braucht (Claude Opus für komplexe Code-Reviews)
- Wenn du keine Ops-Kapazität für GPU-Server hast
Dann: Azure OpenAI EU oder Anthropic via AWS Bedrock EU-Frankfurt.
Nächste Schritte
- LLM-Integration in Bestandssysteme — RAG, Caching, Kostenkontrolle
- pgvector als RAG-Backbone — DB-Layer für deutsche RAG-Setups
Für DSGVO-Audit deiner KI-Integration oder ein maßgeschneidertes EU/On-Prem-Setup: Anfrage.
In Praxis
Verwandte Artikel
- KI / AI· 2 gemeinsame TagsLLM-Integration in Bestandssysteme — RAG, Caching & Kostenkontrolle
- KI / AIpgvector als RAG-Backbone — wann es reicht und wann du eine dedizierte Vector-DB brauchst
- DevOpsCoolify als Heroku-Replacement — Self-Hosted PaaS in der Praxis
- FullstackNext.js 16 + Supabase Auth — der saubere SSR-Flow ohne flackernde Login-States