On-Premise vs. EU-Cloud für AI Agents: Die Entscheidungsmatrix für DACH

On-Premise vs. EU-Cloud für AI Agents beschreibt die Wahl des Betriebsmodells für produktive KI-Agenten: dedizierte eigene Hardware in einem deutschen, österreichischen oder Schweizer Rechenzentrum (On-Premise), souveräne EU-Cloud-Provider oder eine Hybrid-Kombination aus beidem. Entscheidend sind sechs Kriterien: Datensensibilität und Compliance (DSGVO, Branchenrecht), Kosten (CapEx/OpEx, GPU- gegen Token-Ökonomie), Latenz, Skalierung, Betriebsaufwand und Know-how sowie Modell-Verfügbarkeit. Dieser Artikel liefert die Entscheidungsmatrix und konkrete Empfehlungen je Szenario.

Die drei Kernaussagen vorab:

• Standort ist nicht Souveränität. Eine Frankfurt-Region eines US-Hyperscalers liefert Datenresidenz, nicht Datensouveränität. Die Konzernmutter bleibt dem US CLOUD Act (2018) unterworfen. Für regulierte Branchen reicht das in der Regel nicht.
• Hybrid ist das dominierende DACH-Muster. Sensible Dokumente, Embeddings und Vektor-Store bleiben on-premise oder in souveräner Cloud, nur der Generierungs-Schritt ruft eine EU-Region oder souveräne API.
• Der Kosten-Crossover liegt bei rund 8-12 H100-GPUs. Darunter dominieren Managed APIs, darüber wird Selbst-Hosting pro Token günstiger, allerdings mit 6-9 Monaten Engineering-Vorlauf (Stand 2026).

Datenresidenz versus Datensouveränität: die zentrale Unterscheidung

Die häufigste konzeptionelle Verwechslung in DACH-Kundengesprächen betrifft zwei Begriffe, die nicht dasselbe meinen. Datenresidenz ist der physische Ort, an dem Daten gespeichert und verarbeitet werden. Datensouveränität ist die rechtliche Jurisdiktion, die über die Daten herrscht, einschließlich extraterritorialer Reichweite wie dem US CLOUD Act von 2018. Eine souveräne Cloud erfüllt beides: Betreiber, Infrastruktur und rechtliche Kontrolle sitzen in der gewählten Jurisdiktion. Residenz ist also notwendig, aber nicht hinreichend.

Praktisch heißt das: Selbst wenn Daten ausschließlich in Frankfurt liegen, bleibt der Betreiber eines US-Hyperscalers eine US-Rechtsperson unter dem CLOUD Act. Souveränität im strengen, CLOUD-Act-resistenten Sinn erfordert eines von drei Modellen: die dedizierte souveräne Cloud eines Hyperscalers (etwa die AWS European Sovereign Cloud in Brandenburg mit Start Ende 2025, oder Microsoft Sovereign Cloud mit betreiberkontrolliertem Zugriff), einen partnerbetriebenen Stack (T-Systems mit Google, Bleu mit Microsoft in Frankreich) oder einen Nicht-US-Anbieter.

Hinzu kommt eine DACH-Eigenheit: On-Premise meint im Mittelstand selten den Server im Büro, sondern meist eine dedizierte Umgebung in einem carrier-neutralen Colocation-Rechenzentrum in Deutschland, Österreich oder der Schweiz (Equinix Frankfurt, Interxion, Digital Realty Zürich, NTT Vienna). Echtes Bare-Metal im Kundenbesitz bleibt für große Industriegruppen, verteidigungsnahe Organisationen und BFSI-Kunden mit expliziter Aufsichtsanweisung relevant.

Die sechs Entscheidungskriterien

1. Datensensibilität und Compliance

Kundenstammdaten, Mitarbeiterdaten, medizinische Akten oder exportkontrolliertes IP schieben die Architektur in Richtung souverän oder on-premise. Neben DSGVO und der Schweizer FADP/revDSG (in Kraft seit 1. September 2023) wirken Branchenregeln: BaFin/FINMA für BFSI, KRITIS/NIS2 für kritische Infrastruktur, TISAX für Automotive sowie DigiG und § 393 SGB V für Gesundheitsdaten. Ein konkretes, bindendes Datum: Seit 1. Juli 2025 ist BSI C5 Typ 2 verpflichtend für die Cloud-Verarbeitung von Patientendaten. Manche Hyperscaler-Dienste halten diese Attestierung noch nicht, was bei der Beschaffung zu prüfen ist. Dieser Hinweis ersetzt keine Rechtsberatung.

2. Kosten: CapEx/OpEx, GPU gegen Token

Selbst-Hosting bei nachhaltiger Last ist pro Token günstiger, Managed APIs sind günstiger für spitze, explorative Workloads. Idle-GPU ist der teuerste CapEx. Die architektonischen Kostentreiber on-premise sind Abschreibung der GPU-Server (typisch 3-4 Jahre), Strom (DACH-Industrietarife rund 0,18-0,35 EUR/kWh), Kühlung (PUE 1,2-1,4 in modernen DACH-Rechenzentren), Konnektivität, Betrieb und Softwarelizenzen. Ein einzelnes 130-kW-Rack zieht in der Größenordnung von rund 1,1 GWh pro Jahr unter Volllast.

3. Latenz

Co-lokalisierte Inferenz (Engine in derselben Region wie die Agenten-Orchestrierung) liefert einstellige Millisekunden Netzwerklatenz. Transatlantische Aufrufe addieren rund 80-130 ms je Weg plus TLS-Handshake, und bei mehrstufigen Tool-aufrufenden Agenten multipliziert sich das. Für Sub-Sekunden-UX mit mehreren Tool-Call-Runden sind Transatlantik-Aufrufe nicht praktikabel.

4. Skalierung

Managed APIs skalieren elastisch ohne Kapazitätsplanung. Self-hosted Stacks brauchen Vorhalte: GPU-Memory-Math bestimmt die Hardware. Ein 70-B-Modell benötigt bei BF16 rund 140 GB nur für Gewichte, bei FP8 rund 70 GB, bei AWQ-INT4 rund 35 GB. Für niedrige Concurrency genügt 1x H200 (141 GB); für Produktions-Batchgrößen sind typisch 2x H100 oder 2x MI300X nötig. 405-B-Klasse-Modelle verlangen Multi-GPU-Tensor-Parallelität (etwa 8x H200 oder ein GB200-NVL72-Knoten). Trillionen-Parameter-Modelle liegen außerhalb fast aller DACH-Mittelstand-Footprints, hier führt der Weg über Managed APIs oder souveränes GPU-Bursting.

5. Betriebsaufwand und Know-how

Der Betrieb von vLLM, SGLang, Triton oder NVIDIA NIM in Produktionsskalierung erfordert Plattform-Engineering-Tiefe, die die meisten DACH-Mittelständler nicht in-house haben. Ein 24x7-Bereitschaftsteam, das NCCL-Stalls und GPU-Ausfallmodi beherrscht, ist in DACH knapp. Hinweis zur Inference-Engine-Wahl: Hugging Face hat TGI am 11. Dezember 2025 in den Maintenance-Modus überführt und verweist neue Deployments auf vLLM oder SGLang (Stand 2026).

6. Modell-Verfügbarkeit

Managed APIs gewinnen, wenn Modellvielfalt kritisch ist. Azure AI Foundry allein ergänzte 2025 unter anderem DeepSeek R1, GPT-4.1, Mistral Large 3, Claude Opus 4.5 und Llama 4. Souveräne APIs (IONOS AI Model Hub, Open Telekom Cloud AI Foundation Services, Swisscom Swiss AI Platform, Infomaniak) bedienen Open-Source-Modelle wie Teuken-7B, Llama 3/4, Mistral, DeepSeek und das offene Schweizer Apertus (EPFL/ETH/CSCS, veröffentlicht 2. September 2025). Wer ein bestimmtes Modell als permissives Open Weight benötigt, kann es identisch via NIM- oder OCI-Container über Clouds und on-premise hinweg betreiben.

Die Entscheidungsmatrix: Kriterium gegen Betriebsmodell

Die ergänzende Heuristik für die Tiefenentscheidung: Managed schiebt bei öffentlichen/internen Daten, spitzer Last, hoher Modellvielfalt und fehlendem Plattformteam. Selbst-Hosting schiebt bei vertraulichen/regulierten Daten, hoher Dauerlast, Sub-500-ms-Tail-Latenz und strenger Souveränität.

Konkretes Rechenbeispiel: der Kosten-Crossover

Eine in DACH-Plattformteams kursierende Faustregel macht die Entscheidung greifbar (Stand 2026): Ab nachhaltiger Inferenz-Last von etwa 8-12 H100-äquivalenten GPUs wird Selbst-Hosting in souveräner Cloud oder on-premise pro Token typischerweise günstiger als Managed-API-Ökonomie. Oberhalb von rund 30 H100-Äquivalenten öffnet sich die Lücke schnell.

Eine Migration vom Managed API zum Selbst-Hosting ist sinnvoll, wenn mindestens zwei der folgenden Bedingungen zutreffen:

```text
WENN monatliche Managed-API-Ausgaben > Run-Rate von ~10 H100 in souveräner Cloud
ODER neue Aufsichtsanweisung (BaFin/FINMA/BSI) verlangt nicht-nachweisbare Kontrolle
ODER abhängiges Modell wird als permissives Open Weight verfügbar (Llama, Mistral, Apertus)
ODER Roadmap erfordert Fine-Tuning, das auf der Managed API nicht möglich ist
ODER Legal-Review identifiziert Anbieter als Konzentrationsrisiko (DORA)
DANN (bei >= 2 erfuellten Bedingungen) Migration planen, ~6-9 Monate Vorlauf
```

Unterhalb dieser Schwelle dominieren Managed APIs auf TCO-Basis. Konkrete Token-Preise und die H100-gegen-H200-gegen-B200-Rechnung gehören in eine separate FinOps-Betrachtung.

Empfehlung je Szenario

KMU (200-2.000 Mitarbeitende, gemischte Datensensibilität, M365-Umgebung, kein ML-Plattformteam): Das Hybrid-Modell deckt erfahrungsgemäß über 70 Prozent der DACH-Mittelstand-Greenfield-Projekte. Empfehlung: Azure West Europe oder Germany West Central mit Azure OpenAI im Data-Zone-EUR-Deployment, eine On-Prem- oder Colocation-RAG-Schicht mit Vektor-DB für vertrauliche Dokumente, angebunden über ExpressRoute und Private Endpoint. Vertrauliche Chunks verlassen Deutschland nie, nur bereits redigierte Snippets werden Teil des LLM-Prompts. Eine selbst gehostete LiteLLM-Gateway-Schicht steuert Budgets und ermöglicht Fallback auf eine EU-Plattform wie Mistral La Plateforme. Nicht geeignet für BFSI-Kernsysteme, klassifiziertes IP oder Patientendaten nach dem 1. Juli 2025.

Regulierte Branche (BFSI, Healthcare, Public Sector, verteidigungsnah, volle Souveränität): souveräne Cloud als Primärweg. Empfehlung: STACKIT oder Open Telekom Cloud / T Cloud Public mit deutschem Rechtsträger-Vertrag und Betreiberkontrolle. LLM via PhariaAI-as-a-Service auf STACKIT oder offene Modelle (Llama 3/4, Mistral, Teuken-7B, Apertus) über vLLM/NIM auf dedizierten GPU-Instanzen. Vektor-DB (Weaviate, Qdrant, pgvector) in derselben souveränen Cloud, Secrets in HashiCorp Vault mit HSM-Seal gegen Utimaco-HSM, Egress deny-by-default mit Allowlist. Für die höchste Datenklasse optional On-Prem-Inferenz via NVIDIA NIM auf Red Hat OpenShift AI im Kunden-DC. Realer Trade-off: noch bestehende Feature-Lücke zu Hyperscalern, die T-Systems bis Ende 2026 schließen will (Roadmap-Zusage).

Konzern (DAX 40, SMI 20, ATX prime, formale Cloud-Exit-Policy unter DORA/MaRisk/FINMA): Multi-Cloud-Resilienz mit souveränem Tier. Primär-Cloud (Azure Germany/EU) für das Gros, Sekundär-Cloud (AWS oder Google) für Resilienz, die Modell-APIs durch ein AI-Gateway abstrahiert. Modell-Portabilität über offene Modelle (Llama 4, Mistral, Apertus, Teuken) als NIM-/OCI-Container, die identisch über alle Clouds und on-premise laufen. Optionaler souveräner Tier (STACKIT oder T Cloud Public) für die sensibelsten Workloads mit dokumentierten Migrationspfaden. Höchste Kostenklasse, passt fast nie zum Mittelstand.

Schweiz-Hinweis: FADP/revDSG ist nicht DSGVO und darf nicht vermischt werden. Die November-2025-Verschärfung der Schweizer Aufsicht ("privatim") empfiehlt öffentlichen Stellen internationale SaaS für sensible Daten nur mit Ende-zu-Ende-Verschlüsselung und kundengehaltenen Schlüsseln. CLOUD-Act-Exposition bleibt für US-Anbieter auch bei Schweizer Datenresidenz bestehen.

Für Agenturen und B2B-Entscheider

Die Wahl zwischen On-Premise, EU-Cloud und Hybrid ist keine reine IT-Frage, sondern eine Geschäfts- und Compliance-Entscheidung, die früh im Projekt fällt und Architektur, Kosten und Vertriebsfähigkeit über Jahre prägt. Für Agenturen, die KI-Agenten für DACH-Kunden bauen, ist die saubere Trennung von Datenresidenz und Datensouveränität das stärkste Argument in der Beschaffungsdiskussion mit Einkauf und Rechtsabteilung.

Blck Alpaca begleitet DACH-B2B-Unternehmen von der Entscheidungsmatrix bis zum produktiven Stack mit EU-Datenresidenz und nachweisbarer Souveränität. In einem kompakten Proof of Concept klären wir an Ihrem realen Use Case Datenklassen, Latenzbudget, Kosten-Crossover und das passende Betriebsmodell, bevor Sie in Infrastruktur investieren. Sprechen Sie uns für einen B2B-PoC an.