--- title: EU-Inference Migration Evaluation für Tier-3 Daten (ADR) type: audit tags: [dsgvo, gdpr, llm-routing, eu-residency, adr, kar-227] date: 2026-05-17 status: aktiv related: "[[aria-vvt-verzeichnis-verarbeitungstaetigkeiten]], [[01-Projekte/private-ops/CONTEXT]]" confidence: medium description: ADR-Style Decision-Doc für EU-resident LLM-Inference bei Tier-3-Daten. Vergleich AWS Bedrock Frankfurt, Mistral-only, Anthropic-Direct + ZDR, Hybrid. Empfehlung mit Phasenplan. --- # EU-Inference Migration Evaluation — Tier-3 Daten > **Status:** Decided (Hybrid empfohlen) > **Date:** 2026-05-17 > **KAR:** 227 (DSGVO Sub von KAR-219) > **Trigger:** VVT-Audit 2026-05-15 — Schrems-III-Risiko bei US-Drittland-Inference für Behördenpost / medizinische Briefe / Tier-3-Familien-Daten. ## 1. Kontext Aria + private-ops verarbeiten Tier-3 Daten (Definition siehe `private-ops/docs/03-PRIVACY-TIERS.md` §3): - Behördenkorrespondenz (Steuer, Sozialleistung, Aufenthaltstitel) - Versicherungspolicen + Schadensmeldungen - Beschäftigtendaten Restaurant Durrani (Lohn, AU-Bescheinigungen) - Familien-private Briefe ohne medizinische Diagnose Aktueller Stack ruft Anthropic Claude direkt (US-Inference) auch für solche Daten — abgedeckt durch DPF + SCCs, aber: - **Schrems-III-Risiko**: EuGH könnte DPF kippen, dann fehlt Rechtsgrundlage retroaktiv - **AVV-Bedingungen**: Anthropic Default-AVV speichert 30 Tage Server-Side-Logs (ZDR ist Enterprise-only, für Aria-Account nicht verfügbar — siehe VVT-Note, Antwort Sales 2026-05-14) - **Reputations-Risiko**: bei Daten-Subjekt-Anfrage Erklärungs-Druck "warum geht meine medizinische Korrespondenz nach Kalifornien?" Tier-1 und Tier-2 sind durch das berechtigte Interesse + DPF gut abgedeckt; Tier-3 ist der Engpass. Tier-4 wird ohnehin nicht extern verarbeitet (lokales Whisper, operator-mediated). ## 2. Bewertete Optionen ### Option A — AWS Bedrock Frankfurt (`eu-central-1`) EU-resident Hosting der Anthropic-Modelle. Inference läuft in Frankfurt, Bedrock-API als Proxy. Identische Model-Outputs (Claude 4.5 / 4.6 / Haiku 4.5). **Pro**: - Echtes EU-Inference-Residency — kein Datentransfer USA für Tier-3 - AWS Auftragsverarbeiter-AVV ist Standard, Tausende EU-Kunden, Schrems-III-resilient - Drop-in-Kompatibel: Aria-Code spricht weiterhin Anthropic-Wire-Format - Cost-Delta minimal (Bedrock-Markup ~5-10 %) **Contra**: - Claude **Opus 4.7 nicht** in Bedrock (Stand 2026-05-17) — nur 4.5 + 4.6 dort. Wenn Aria-Pipelines Opus 4.7 brauchen (z.B. AKP Deep), bleiben sie auf Direct-API - AWS-Account-Setup-Aufwand: Account, IAM-Roles, Bedrock Model Access (manuelle Provider-Approval pro Modell) - Cold-Start-Latenz bei seltenen Aufrufen höher als Direct-API - Zusätzliche Failure-Surface (AWS-Outage) **Setup-Aufwand**: 1-2 Tage (AWS-Account-Onboarding + IAM + Code-Switch) ### Option B — Mistral-only (FR-hosted, native EU) Mistral AI ist französisches Unternehmen, alle Modelle in EU gehostet (Paris / Frankfurt). API-Kompatibel mit OpenAI-Wire-Format, eigener `mistralai`-Client. **Pro**: - 100 % EU-Native, kein Transfer-Mechanismus nötig - AVV als EU-Vertragspartner Standardware, keine SCCs nötig - Mistral Large 2 (Stand 2026) qualitativ konkurrenzfähig zu Claude Sonnet 4.6 für Reasoning - Niedrigste Latenz aus Frankfurt-Inference **Contra**: - **Quality-Lücke** für High-Stakes-Drafts (Behörden, Recht): Mistral Large hat in Aria-internen Spot-Checks 2026-Q1 ~15 % höhere Hallucination-Rate als Opus 4.7 - Multi-LLM-Voting-Hallucination-Guard (vorgesehen in `private-ops/docs/01-ARCHITECTURE.md` §2.3) braucht **zwei verschiedene LLM-Familien** — nur Mistral = kein Voting möglich - Migration aller existierenden Prompts (~30 in AKP + private-ops) auf Mistral-Stil = nicht-trivial - Kein Tool-Use Parity mit Anthropic (Function-Calling-Format unterschiedlich) **Setup-Aufwand**: 3-5 Tage (Wire-Format-Adapter + Prompt-Re-Engineering) ### Option C — Status quo: Anthropic Direct + DPF + SCCs Beibehalten, dokumentieren in VVT, akzeptieren Schrems-III-Risiko bis es eintritt. **Pro**: - 0 Aufwand - Aktuelle Pipelines unverändert (Opus 4.7 verfügbar) - DPF + SCCs sind aktuell rechtskonform **Contra**: - Schrems-III-Risiko nicht mitigiert — Eintritt würde Aria + private-ops Tier-3 Pipelines binnen Tagen blockieren - Bei DSGVO-Anfrage "warum USA" schwerer zu argumentieren als "wir nutzen EU-Inference" - Anthropic 30-Tage Default-Logs (kein ZDR) bleibt **Setup-Aufwand**: 0 ### Option D — Hybrid (EMPFEHLUNG) Tier-spezifisches Routing: - **Tier 0-1** (öffentlich, low-sensitivity): Anthropic Direct API (Opus 4.7 / Haiku 4.5) — niedrigste Latenz, voller Model-Zoo - **Tier 2** (intern, vertraulich aber nicht personal): Anthropic Direct API mit Hinweis im Audit-Log - **Tier 3** (Behörden / Versicherung / Beschäftigtendaten / Familien-private Briefe): **AWS Bedrock Frankfurt** mit Claude Sonnet 4.6 + Haiku 4.5 als Workhorses. Wenn Opus-Level-Reasoning für T3-Tasks gebraucht wird: Mistral Large als Fallback ODER manueller Eskalations-Pfad an operator - **Tier 4-5** (Pässe / Steuer-IDs / IBAN): keine externe LLM überhaupt, operator-mediated Routing-Layer: kleiner `llm-router` Package in private-ops (heute spec'd in `docs/01-ARCHITECTURE.md` §2.3 als "Custom capability-aware router") wird realisiert. Router liest Tier aus capability-token, picked Provider entsprechend. **Pro**: - Schrems-III-Risiko für die kritischsten Daten gemitigt - Opus 4.7 bleibt für T0-T2 verfügbar (kein Quality-Regress dort) - Multi-LLM-Voting möglich: Bedrock-Claude + Mistral als Validation-Pair - Inkrementell baubar: Phase 1 nur T3 umlegen, Rest schrittweise **Contra**: - Höhere Code-Komplexität (zwei Provider gleichzeitig) - AWS + Anthropic-Account beide pflegen - Cost-Overhead durch Multi-Provider-Setup (~5-10 % gegenüber A oder C) **Setup-Aufwand**: Phase 1 ~3 Tage (Bedrock-Onboarding + Router-MVP), Phase 2 ~3 Tage (Mistral-Adapter) ### Option E — Self-host (Llama / Mistral auf Hetzner EU) Lokales Inference, kein externer Provider. **Verworfen** ohne tiefe Bewertung: - Hetzner GPU-Tier Cost-Modell macht ~6× teurer als Bedrock für Tier-3-Volumen - Operations-Last (Model-Update, GPU-Failures, Auto-Scaling) ist eigenes Projekt - Quality-Lücke (Llama 3 70B vs Claude Sonnet 4.6) zu groß für High-Stakes-Drafts Re-Evaluieren wenn Tier-3-Volumen > 10 M Token/Monat oder regulatorische Verschärfung Cloud verbietet. ## 3. Vergleichs-Matrix | Dimension | A: Bedrock EU | B: Mistral-only | C: Status quo | D: Hybrid (rec) | E: Self-host | |---|---|---|---|---|---| | EU-Residency T3 | ✅ | ✅ | ❌ | ✅ | ✅ | | Schrems-III-resilient | ✅ | ✅ | ❌ | ✅ | ✅ | | Opus-4.7-Verfügbarkeit | ❌ | ❌ | ✅ | ✅ (T0-T2) | ❌ | | Multi-LLM-Voting möglich | ⚠ (nur Claude)| ❌ | ⚠ | ✅ | ⚠ | | Migration-Aufwand | M (1-2 d) | L (3-5 d) | None | M+L (Phasen) | XL | | Operations-Last | niedrig | niedrig | niedrig | mittel | hoch | | Cost-Delta zu C | +5-10 % | -10 bis -20 % | Baseline | +5-15 % | +500-800 % | | Anthropic AVV nötig | nein (AWS) | nein | ja | ja (T0-T2) | nein | ## 4. Decision **Hybrid (Option D)** ist die empfohlene Architektur. Rationale: 1. Schrems-III-Risiko ist real und kann jederzeit eintreten — Tier-3-Daten brauchen EU-Residency 2. Opus 4.7 Quality-Gewinn bleibt für T0-T2 erhalten — keine Pipeline-Regression 3. Multi-Provider eröffnet Hallucination-Guard-Pfad (Voting) den wir ohnehin laut Architecture-Doc bauen wollen 4. Mehr-Komplexität ist überschaubar wenn der Router-Layer von Anfang an sauber abstrahiert wird ## 5. Phasenplan ### Phase 1 — Bedrock-Onboarding + Router-MVP (~3 Werktage) 1. AWS-Account anlegen, IAM-User für Bedrock-Access 2. Bedrock Model Access beantragen: `anthropic.claude-sonnet-4-6` + `anthropic.claude-haiku-4-5-20251001` 3. `packages/llm-router/` in private-ops scaffolden (Tier-Input → Provider-Select) 4. Default-Routing: Tier 3 → Bedrock, sonst Direct-API 5. ENV-Vars: `AWS_BEDROCK_REGION`, `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` 6. Smoke-Test: gleicher Prompt durch Direct + Bedrock, Output-Diff prüfen 7. Audit-Log-Felder ergänzen: `provider` + `region` (so wissen wir bei post-mortem wer was wohin sendete) **Akzeptanz**: Aria nutzt für jeden Tier-3-Call Bedrock Frankfurt. Audit-Log zeigt Provider/Region. Latenz-P95 < 1.5× Baseline. ### Phase 2 — Mistral als Tier-3-Voting-Partner (~3 Werktage) 1. Mistral-Account + API-Key, AVV verifizieren (KAR-226 Sub) 2. Mistral-Adapter in `packages/llm-router/` 3. Voting-Logic für High-Stakes-Drafts (Behörden, Steuer): Bedrock-Claude generiert, Mistral validiert, Mismatch → Operator-Eskalation 4. Cost-Cap pro Voting-Run **Akzeptanz**: High-Stakes-Drafts unter Tier-3 haben Voting aktiv. Hallucination-Spot-Check 2026-Q3 zeigt <2 % Mismatch-Rate. ### Phase 3 — Pipeline-Backfill (~2 Werktage) 1. AKP Deep (`aria-akp-deep.py`): wenn Stage-3-Brain-Note Tier-3-relevante Person nennt → Bedrock statt Direct 2. private-ops Letter-Replies (Phase 5 KAR-203): default Bedrock, optional Mistral-Voting 3. private-ops Inbox-Classification (Phase 3): default Bedrock für Tier-3-Items **Akzeptanz**: Alle Tier-3-Daten-Pfade gehen über Bedrock. Direct-API-Calls für Tier-3 in Audit-Log = 0 über 30 Tage. ### Phase 4 — Self-host Re-Evaluation (geplant 2026-Q4) Trigger: Volumen > 10 M Token/Monat ODER neue regulatorische Anforderung. Heute nicht relevant. ## 6. Out of Scope (für diesen ADR) - Tier-4 + Tier-5: bleiben operator-mediated, kein externer LLM - Aria-Side Provider-Hardblock (KAR-263 Gemini, KAR-266 DeepSeek): separate ADRs, nicht hier - Embedding-Provider Migration (OpenAI EU vs Voyage): separate Recherche - Self-hosted Whisper: Phase 3+ Tier-4 Operator-Tools ## 7. Offene Operator-Aktionen - [ ] AWS-Account anlegen (Kais) - [ ] Bedrock Model Access beantragen für Sonnet 4.6 + Haiku 4.5 (Kais) - [ ] Anthropic ZDR Enterprise-Verhandlung erneuern (optional, Cost-Vergleich gegen Bedrock — wenn ZDR-Preis < Bedrock-Markup, dann ZDR als zusätzliches Mitigation) - [ ] AVV Mistral verifizieren (KAR-226 Sub) ## 8. Risiken + Mitigations | Risiko | Wahrscheinlichkeit | Mitigation | |---|---|---| | Bedrock Frankfurt Modell-Update-Lag (z.B. neue Sonnet erscheint später als Direct) | mittel | Direct-API-Fallback für T0-T2 bleibt — Lag betrifft nur T3-Quality, akzeptabel | | AWS-Outage | niedrig | Direct-API-Fallback aktivierbar via Feature-Flag | | Voting-Cost-Spike | mittel | Cost-Cap pro Tag pro Tier; Auto-Pause bei Überschreitung | | Schrems-III tritt VOR Phase 1 ein | niedrig-mittel | Sofort-Notlösung: Tier-3-Pipelines pausieren bis Bedrock-Cutover (operativ tragbar 1-2 Wochen) | ## 9. Verwandte Notes - [[aria-vvt-verzeichnis-verarbeitungstaetigkeiten]] — Master-VVT mit allen Providern + AVV-Status - [[01-Projekte/private-ops/CONTEXT]] — Aseckzai OS Mission + Tier-Mapping - `private-ops/docs/01-ARCHITECTURE.md` §2.3 LLM-Layer - `private-ops/docs/03-PRIVACY-TIERS.md` Tier-Definitionen - KAR-219 DSGVO Master, KAR-225 VVT Done, KAR-226 AVV-Status-Check, KAR-228 Telegram-Tier-3, KAR-263 Gemini, KAR-264 OpenAI, KAR-265 NotebookLM, KAR-266 DeepSeek, KAR-267 Transkriptor ## 10. Versionierung - v1: 2026-05-17 (initial, ADR-Style mit Phasenplan)