KI-Hosting: EU-SaaS, deutsches RZ oder Self-Hosted?
Drei Hosting-Strategien für Enterprise-KI. Entscheidungsmatrix nach Datensensibilität, Kosten und Kontrolle.
„Wo läuft es?” – Die entscheidende Frage
Bevor Sie ein Modell auswählen, bevor Sie Agenten bauen, bevor Sie ein Interface ausrollen, steht eine Frage: Wo laufen Ihre KI-Modelle? Diese Entscheidung bestimmt, welche Datenschutzgarantien Sie geben können, welche regulatorischen Anforderungen Sie erfüllen, wie hoch Ihre laufenden Kosten sind und wie abhängig Sie von Drittanbietern werden.
Es gibt drei grundlegende Strategien – und eine vierte, die in der Praxis zum Standard geworden ist: die Hybrid-Architektur, die alle drei kombiniert.
Stufe 1: EU-SaaS – Cloud-APIs mit EU-Datenresidenz
Die einfachste und schnellste Variante: Sie nutzen die APIs der Modellanbieter direkt. Claude über die Anthropic-API (EU-Region), GPT-5.2 über Azure OpenAI (EU-Rechenzentrum), Gemini über Google Cloud Platform (EU-Region). Die Daten verlassen Ihr Netzwerk, werden aber in EU-Rechenzentren verarbeitet.
Vorteile
Schnellster Start: Keine Infrastruktur aufbauen, kein GPU-Server bereitstellen, keine ML-Ops-Expertise erforderlich. API-Key einrichten, AVV unterzeichnen, produktiv in Stunden.
Automatische Updates: Modellupdates, Sicherheitspatches und Performance-Verbesserungen werden vom Anbieter ausgerollt. Kein eigener Wartungsaufwand.
Skalierbarkeit: Kein Kapazitätsmanagement. Bei Lastspitzen skaliert der Cloud-Anbieter automatisch. Keine Überplanung, keine Unterkapazität.
Modellvielfalt: Zugriff auf alle Modellvarianten des Anbieters – Flaggschiff, Preis-Leistung und Budget – über dieselbe API.
Risiken und Einschränkungen
Daten verlassen das Unternehmensnetzwerk. Auch bei EU-Datenresidenz werden Ihre Anfragen auf Infrastruktur verarbeitet, die Sie nicht kontrollieren. Der Anbieter hat technisch Zugriff auf die Daten während der Verarbeitung.
CLOUD Act. US-amerikanische Anbieter – und dazu gehören Anthropic, OpenAI und Google – unterliegen dem US CLOUD Act. US-Behörden können unter bestimmten Bedingungen Zugriff auf Daten verlangen, auch wenn diese in EU-Rechenzentren gespeichert sind. Für die meisten Unternehmensdaten ist dieses Risiko bewertbar und akzeptabel. Für Geschäftsgeheimnisse, VS-NfD-Daten oder KRITIS-relevante Informationen nicht.
Vendor-Abhängigkeit. Bei einer Single-Provider-Strategie sind Sie von der Preispolitik, den API-Änderungen und der Verfügbarkeit eines einzelnen Anbieters abhängig. Eine modell-agnostische Architektur (siehe KI-Modelle Vergleich 2026) reduziert dieses Risiko.
AVV erforderlich. Für die DSGVO-konforme Nutzung ist ein Auftragsverarbeitungsvertrag (AVV) mit dem Anbieter zwingend. Alle drei großen Anbieter bieten Standard-AVVs an – prüfen Sie diese mit Ihrer Rechtsabteilung.
Geeignet für
- Standard-Aufgaben mit nicht-sensiblen Daten: Zusammenfassungen, Übersetzungen, allgemeine Fragebeantwortung
- Proof of Concepts und Pilotprojekte
- Aufgaben mit variablem Volumen, bei denen dedizierte GPU-Infrastruktur unwirtschaftlich wäre
- Unternehmen ohne ML-Ops-Expertise, die schnell produktiv werden wollen
Stufe 2: Deutsches IaaS – GPU-Hosting bei deutschen Anbietern
Die mittlere Variante: Sie mieten GPU-Server bei einem deutschen Infrastructure-as-a-Service-Anbieter – etwa Hetzner, IONOS oder einem spezialisierten GPU-Cloud-Provider. Darauf betreiben Sie Open-Source-Modelle wie gpt-oss, Llama 4 oder Mistral Medium 3.1 selbst.
Konkrete Hardware-Anforderungen und Kosten
| Modell | GPU-Anforderung | Geschätzte Kosten/Monat |
|---|---|---|
| gpt-oss-120b | 1x A100/H100 (80 GB) | ca. 1.200 € |
| gpt-oss-20b | CPU/16 GB RAM (oder kleine GPU) | ca. 200–400 € |
| Llama 4 Scout | 1x A100 (80 GB) | ca. 1.200 € |
| Llama 4 Maverick | 4x A100 (80 GB) | ca. 3.500 € |
| Mistral Medium 3.1 | 4x A100 (80 GB) | ca. 3.500 € |
Vorteile
Daten bleiben in Deutschland. Der Server steht in einem deutschen Rechenzentrum, betrieben von einem deutschen Anbieter. Kein CLOUD Act, kein transatlantischer Datentransfer. Für die DSGVO die sicherste Cloud-Variante.
Kein Anbieter-Lock-in. Sie betreiben Open-Source-Modelle unter Apache 2.0 oder Meta Llama License. Wenn Sie den Hosting-Anbieter wechseln wollen, migrieren Sie das Modell – ohne Lizenzfragen, ohne Vertragsverhandlungen.
Volle Modellkontrolle. Sie entscheiden, welches Modell in welcher Version läuft. Sie können Modelle fine-tunen, quantisieren oder durch neuere Versionen ersetzen – ohne auf den Anbieter zu warten.
Kalkulierbare Kosten. GPU-Server haben Fixkosten pro Monat. Keine variablen Token-Kosten, keine Überraschungen bei Lastspitzen. Für Unternehmen mit hohem, konstantem Volumen oft wirtschaftlicher als Cloud-APIs.
Anforderungen
ML-Ops-Kompetenz. Sie brauchen jemanden, der das Modell deployed, überwacht, aktualisiert und bei Problemen eingreift. Das kann ein interner ML-Engineer sein oder ein externer Dienstleister – aber es ist kein Null-Aufwand.
Kapazitätsplanung. Ein GPU-Server hat eine definierte Kapazität. Wenn Sie 500 gleichzeitige Anfragen haben, reicht eine einzelne GPU nicht. Sie müssen Lastprofile verstehen und Kapazitäten planen.
Kein automatisches Update. Wenn ein neues Modell erscheint, müssen Sie es selbst deployen. Wenn ein Sicherheitsproblem auftritt, müssen Sie selbst patchen.
Geeignet für
- Vertrauliche Unternehmensdaten (Stufe 2–3 nach BSI-Klassifikation)
- Unternehmen, die CLOUD-Act-Risiken ausschließen müssen
- Anwendungsfälle mit konstantem, hohem Volumen (Kostenvorteil gegenüber Cloud-APIs)
- Organisationen mit bestehender DevOps-/ML-Ops-Kompetenz
Stufe 3: On-Premises – KI auf eigener Hardware
Die maximal kontrollierte Variante: Sie betreiben GPU-Server in Ihrem eigenen Rechenzentrum oder in einem Colocation-Rack. Keine Daten verlassen Ihr Netzwerk – unter keinen Umständen.
Vorteile
Maximale Datensouveränität. Kein externer Zugriff, kein externer Anbieter, keine externe Abhängigkeit. Die Hardware gehört Ihnen, das Modell gehört Ihnen, die Daten verlassen nie Ihr Netzwerk.
Regulatorische Sicherheit. Für KRITIS-Unternehmen, Behörden, Verteidigungssektor und Organisationen mit VS-NfD-Daten ist On-Premises oft die einzige Option, die den Compliance-Anforderungen entspricht.
Keine laufenden Lizenz- oder API-Kosten. Nach der initialen Investition fallen nur Strom, Kühlung und Wartung an. Bei langjährigem Betrieb und hohem Volumen kann On-Premises die wirtschaftlichste Variante sein.
Herausforderungen
Hohe Initialinvestition. Ein produktiver GPU-Server mit NVIDIA H100 (80 GB) kostet 25.000–40.000 Euro. Für leistungsfähigere Setups (Multi-GPU, Redundanz) liegen die Kosten bei 60.000–120.000 Euro oder mehr.
ML-Ops-Team erforderlich. On-Premises bedeutet: Sie sind für alles verantwortlich. Hardware-Wartung, Modell-Deployment, Monitoring, Updates, Sicherheit. Das erfordert ein dediziertes Team oder einen erfahrenen Dienstleister.
Skalierung ist nicht trivial. Wenn die Last steigt, können Sie nicht per Knopfdruck eine weitere GPU hinzufügen. Hardware-Beschaffung dauert Wochen bis Monate.
Geeignet für
- KRITIS-Unternehmen und Behörden
- VS-NfD-Daten und höchste Geheimhaltungsstufen
- Organisationen mit eigenem Rechenzentrum und ML-Ops-Kompetenz
- Langfristige Investitionsbereitschaft bei sehr hohem Volumen
Der Entscheidungsbaum
Die folgende Entscheidungslogik hilft bei der Zuordnung:
Enthalten Ihre Daten PII oder Geschäftsgeheimnisse?
├── NEIN → EU-SaaS (Stufe 1)
└── JA → KRITIS oder VS-NfD?
├── JA → On-Premises (Stufe 3)
└── NEIN → Deutsches IaaS (Stufe 2) oder HybridIn der Praxis ist die Antwort selten eine einzelne Stufe. Die meisten Unternehmen haben Daten unterschiedlicher Sensibilität – und brauchen deshalb eine Architektur, die alle Stufen abdeckt.
Hybrid als Standard: Die Routing-Architektur
Die Hybrid-Strategie kombiniert alle drei Stufen in einer einzigen Architektur. Eine Routing-Schicht entscheidet automatisch, welche Anfrage über welchen Kanal läuft – basierend auf der Datensensibilität, nicht auf der Entscheidung einzelner Mitarbeitender.
So funktioniert das Routing
Datensensibilitäts-Stufe 1–2 (öffentlich, intern): Anfragen laufen über Cloud-APIs. Schnell, günstig, skalierbar. Beispiel: Zusammenfassung eines öffentlichen Whitepapers, Übersetzung einer Pressemitteilung, Entwurf einer allgemeinen E-Mail.
Datensensibilitäts-Stufe 3 (vertraulich): Anfragen werden an Self-Hosted-Modelle im deutschen Rechenzentrum geroutet. Kein Datenabfluss, kein CLOUD Act. Beispiel: Analyse interner Verträge, Verarbeitung von Personaldaten, Auswertung vertraulicher Finanzdaten.
Datensensibilitäts-Stufe 4 (streng vertraulich / reguliert): Anfragen laufen ausschließlich über On-Premises-Infrastruktur. Beispiel: VS-NfD-Dokumente, KRITIS-relevante Systeme, Daten unter besonderer Geheimhaltung.
Voraussetzung: Datenklassifikation
Damit das Routing funktioniert, muss das Unternehmen seine Daten klassifizieren. Das klingt aufwändig, ist aber in vielen Organisationen bereits vorhanden – etwa im Rahmen bestehender Informationssicherheits-Management-Systeme (ISMS) oder der BSI-Grundschutz-Klassifikation. Die Routing-Regeln bilden diese bestehende Klassifikation auf die KI-Infrastruktur ab.
Technische Umsetzung
Die Routing-Schicht sitzt zwischen dem Enterprise-AI-Portal (dem Interface, das Mitarbeitende nutzen) und den Modell-Endpunkten. Sie besteht aus drei Komponenten:
- Klassifikator: Erkennt automatisch die Datensensibilität einer Anfrage – basierend auf Schlüsselwörtern, Quellsystem oder expliziter Markierung durch den Nutzer.
- Routing-Engine: Ordnet die Anfrage dem passenden Modell-Endpunkt zu – Cloud-API, German IaaS oder On-Premises.
- Audit-Log: Protokolliert jede Routing-Entscheidung – welche Anfrage, welche Sensibilitätsstufe, welcher Endpunkt. Nachvollziehbar und exportierbar.
Kosteneffekt
Die Hybrid-Architektur optimiert nicht nur die Datensicherheit, sondern auch die Kosten. Cloud-APIs sind pro Anfrage günstig, aber variabel. Self-Hosted-Modelle haben Fixkosten, die sich bei hohem Volumen amortisieren. Die Kombination nutzt beides: günstige Cloud-APIs für das Gros der unkritischen Anfragen, Fixkosten-optimierte Self-Hosted-Modelle für das vertrauliche Volumen.
In der Praxis sehen wir bei Unternehmen mit 1.000+ Mitarbeitenden typischerweise folgende Verteilung: 60–70 % der Anfragen laufen über Cloud-APIs (Stufe 1–2), 25–35 % über deutsches IaaS (Stufe 3), und 5–10 % über On-Premises (Stufe 4). Die Gesamtkosten liegen dabei 30–40 % unter einer reinen Cloud-API-Strategie bei gleichzeitig höherer Datensouveränität.
Zusammenfassung: Die drei Stufen im Überblick
| Kriterium | EU-SaaS (Stufe 1) | Deutsches IaaS (Stufe 2) | On-Premises (Stufe 3) |
|---|---|---|---|
| Datensouveränität | EU-Region, AVV | Deutschland, kein CLOUD Act | Maximal |
| Initialkosten | Keine | Gering (Miete) | Hoch (60–120k €+) |
| Laufende Kosten | Variabel (Token) | Fix (GPU-Miete) | Fix (Strom, Wartung) |
| ML-Ops-Aufwand | Keiner | Mittel | Hoch |
| Skalierbarkeit | Automatisch | Manuell | Manuell, langsam |
| Geeignet für | Stufe 1–2 Daten | Stufe 2–3 Daten | Stufe 3–4 Daten |
Die richtige Strategie ist fast immer eine Kombination. Gosign implementiert die Routing-Schicht, die alle drei Stufen verbindet – so dass Ihre Mitarbeitenden ein einziges Interface nutzen und das System automatisch den richtigen Weg wählt.
Weiterführend: KI-Infrastruktur | Decision Layer & Shadow AI
📘 Enterprise AI-Infrastruktur Blueprint 2026 – Artikel-Serie
| ← Vorheriger | Übersicht | Nächster → |
|---|---|---|
| KI-Modelle 2026: Welches Modell für welchen Einsatz? | Zur Übersicht | Enterprise-AI-Portal: Vier Open-Source-Interfaces im Vergleich |
Alle Artikel dieser Serie: Enterprise AI-Infrastruktur Blueprint 2026
Sie wollen wissen, welche Hosting-Strategie für Ihre Datenlage die richtige ist? Gosign analysiert Ihre Datenklassifikation und entwirft die passende Hybrid-Architektur.
Termin vereinbaren – Wir klären in 30 Minuten, welche Hosting-Stufen Sie brauchen.