„Wir müssen selbst hosten wegen Datensouveränität" ist die häufigste KI-Infrastruktur-Aussage in DACH-Vorstandsetagen. Sie ist auch die am häufigsten falsche.
Datensouveränität ist eine berechtigte Anforderung. Self-Hosting ist ein Weg, sie zu erreichen — aber nicht der einzige und oft nicht der beste. Die Entscheidung verdient ein Framework, keinen Reflex.
Der Entscheidungsbaum
Drei Fragen bestimmen, ob Self-Hosting notwendig ist.
Frage 1: Müssen Ihre Daten wirklich On-Premise bleiben?
Die meisten Unternehmen verwechseln „Daten dürfen nicht in die USA" mit „Daten müssen auf unseren eigenen Servern bleiben". Das sind unterschiedliche Anforderungen mit unterschiedlichen Lösungen.
Die DSGVO verlangt, dass personenbezogene Daten, die von Dritten verarbeitet werden, durch angemessene Schutzmaßnahmen gesichert sind. Für EU-gehostete API-Endpunkte — Azure West Europe, AWS Frankfurt, Google Cloud Belgien — erfüllen Standard-Auftragsverarbeitungsverträge diese Anforderung. Der EU AI Act fordert dokumentierte Data Governance; er schreibt keine On-Premise-Verarbeitung vor.
Self-Hosting ist tatsächlich notwendig, wenn Ihre Branchenaufsicht ausdrücklich On-Premise-Datenverarbeitung vorschreibt (selten im DACH-Raum, existiert aber in spezifischen Verteidigungs- und KRITIS-Sektoren), wenn Ihre Datenklassifikationsrichtlinie — nicht nur Präferenz — jegliche Drittverarbeitung verbietet, oder wenn Sie Daten verarbeiten, die spezifischen nationalen Sicherheitsklassifikationen unterliegen.
Für die überwiegende Mehrheit der DACH-Mittelständler erfüllen EU-gehostete APIs die Datensouveränitätsanforderungen zu einem Bruchteil der Self-Hosting-Kosten.
Frage 2: Können Sie sich die operative Realität leisten?
Self-Hosting ist keine einmalige Hardware-Anschaffung. Es ist eine fortlaufende operative Verpflichtung.
Laut der DevTk.AI-Kostenanalyse 2026 erfordert ein vollständig selbst gehosteter LLM-Betrieb — von Infrastruktur-Provisionierung über Monitoring und Modell-Updates bis hin zu Security-Patching und Incident Response — 1,5 bis 2 dedizierte ML Engineers. Auf dem DACH-Arbeitsmarkt kosten ML-Infrastruktur-Engineers 100.000 bis 150.000 Euro jährlich — und die Besetzung dauert drei bis sechs Monate.
Die Infrastruktur selbst erfordert GPU-Hardware oder Cloud-GPU-Reservierungen (2.500 bis 5.000 Dollar monatlich für ein minimales Produktions-Setup), Networking und Storage (500 bis 1.000 Dollar monatlich), Monitoring- und Alerting-Systeme, Security-Patching und Compliance-Dokumentation sowie Modell-Update-Zyklen alle sechs bis acht Wochen.
Die Braincuber-Analyse 2026 beziffert die Gesamtbetriebskosten auf das 2,5- bis 3-fache der reinen GPU-Kosten. Ein Setup, das nach 3.000 Dollar monatlich Compute aussieht, kostet tatsächlich 7.500 bis 9.000 Dollar monatlich, wenn alles eingerechnet wird.
Frage 3: Rechtfertigt das Volumen die Fixkosten?
Self-Hosting hat hohe Fixkosten und niedrige Grenzkosten. APIs haben niedrige Fixkosten und lineare Grenzkosten. Der Break-Even hängt vom Volumen ab.
Unter 50 Millionen Tokens pro Tag — was die meisten Mittelstands-Anwendungsfälle abdeckt — ist API-basiertes Deployment günstiger, selbst nach Berücksichtigung des Datensouveränitäts-Aufschlags EU-gehosteter Endpunkte.
Über 200 Millionen Tokens pro Tag spart Self-Hosting typischerweise 50 bis 70 Prozent bei den Inferenzkosten und rechtfertigt den operativen Aufwand.
Dazwischen hängt die Entscheidung von der Team-Fähigkeit, der Wachstumstrajektorie und der Anzahl der Use Cases ab, die über die Infrastruktur laufen sollen.
Der Mittelweg: Managed Private Deployment
Zwischen vollem Self-Hosting und öffentlichen APIs hat sich 2025 und 2026 eine Zwischenoption deutlich weiterentwickelt: Managed Private Deployments.
Anbieter wie Azure AIs Private Endpoints, AWS Bedrocks VPC-Konfigurationen und spezialisierte europäische Inference-Provider bieten Modelle auf dedizierter Infrastruktur in EU-Rechenzentren — mit Datenisolationsgarantien, ohne die operative Last, die Infrastruktur selbst zu betreiben.
Sie zahlen einen Aufschlag gegenüber Shared-API-Pricing — typischerweise 30 bis 50 Prozent mehr — eliminieren aber den ML-Engineering-, Hardware-Management- und operativen Aufwand. Für DACH-Unternehmen, deren primäre Anforderung Datenisolation und nicht vollständige Infrastrukturkontrolle ist, ist dies oft die optimale Architektur.
Das Empfehlungsframework
Wenn Ihr primärer Treiber DSGVO-Compliance ist: EU-gehostete APIs mit Standard-AVVs reichen für die meisten Use Cases aus. Self-Hosting erhöht die Kosten, ohne den Compliance-Nutzen zu steigern.
Wenn Ihr primärer Treiber Branchenregulierung ist: Prüfen Sie den spezifischen Regulierungstext. Die meisten DACH-Branchenregulierungen fordern Datenschutz, nicht On-Premise-Verarbeitung. Wo On-Premise tatsächlich erforderlich ist, erfüllen Managed Private Deployments oft die Anforderung.
Wenn Ihr primärer Treiber Kostenoptimierung bei Skalierung ist: Self-Hosting wird oberhalb des Volumen-Break-Even sinnvoll — aber nur, wenn Sie das ML-Engineering-Team haben oder aufbauen können, um es zu betreiben. Ohne operative Fähigkeit lösen sich die Einsparungen in Incident Response und Ausfallzeiten auf.
Wenn Ihr primärer Treiber Latenz ist: Kleine Modelle (3B bis 7B Parameter), selbst gehostet auf einer einzelnen GPU, liefern Sub-100ms-Inferenz — über APIs nicht erreichbar. Für Echtzeit-Produktionsanwendungen kann dies unabhängig von den Kosten der entscheidende Faktor sein.
Buchen Sie einen Fit Call, um Ihre Self-Hosting-Entscheidung zu evaluieren. Wir bewerten Ihre regulatorischen Anforderungen, Datensensitivität, Volumenprojektionen und Team-Fähigkeit — und empfehlen die Deployment-Architektur, die Ihre Anforderungen erfüllt, ohne zu überbauen. Fit Call buchen →
Referenzen: DevTk.AI, "Self-Host LLM vs API: Real Cost Breakdown 2026"; Braincuber, "Self-Hosted LLM vs API: Breakeven Cost & GPU Math," 2026; Effloow, "Self-Hosting LLMs vs Cloud APIs: Cost, Performance & Privacy Compared," 2026; GDPR Art. 28 (processor obligations); EU AI Act Art. 10–15 (data governance requirements).