„Wir müssen selbst hosten — wegen der Datensouveränität." Das ist die meistgehörte KI-Infrastruktur-Aussage in DACH-Vorstandsetagen. Und sie ist erstaunlich oft falsch.
Datensouveränität ist eine völlig berechtigte Anforderung. Self-Hosting ist ein Weg, sie zu erfüllen — aber weder der einzige noch in den meisten Fällen der beste. Wer die Entscheidung als Reflex trifft („sensible Daten gehören auf unsere Server"), kauft sich häufig eine teure, personalintensive Dauerverpflichtung ein, die die zugrunde liegende Anforderung gar nicht adressiert. Die Entscheidung verdient ein Framework, keinen Bauchgefühl-Reflex.
Drei Fragen, die die Entscheidung bestimmen
Bevor Sie über Hardware, GPUs oder Anbieter sprechen, beantworten Sie drei Fragen in dieser Reihenfolge. Erst die Regulatorik, dann die operative Realität, dann die Ökonomie. Die meisten Self-Hosting-Projekte scheitern, weil diese Reihenfolge umgekehrt wird.
Frage 1: Müssen Ihre Daten regulatorisch wirklich On-Premise bleiben?
Die häufigste Verwechslung im Maschinenraum der Entscheidung: „Daten dürfen nicht ungeschützt in die USA" wird mit „Daten müssen auf unseren eigenen Servern bleiben" gleichgesetzt. Das sind zwei verschiedene Anforderungen mit zwei sehr verschiedenen Preisschildern.
Die DSGVO schreibt keine Datenlokalisierung vor. Sie verlangt, dass personenbezogene Daten, die ein Dritter im Auftrag verarbeitet, durch geeignete technische und organisatorische Maßnahmen geschützt sind — und dass dies vertraglich abgesichert wird. Genau dafür existiert der Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Für einen EU-gehosteten Inference-Endpunkt — etwa in Frankfurt, in den Niederlanden oder in der Schweiz — erfüllt ein sauberer AVV mit Zero-Retention-Konfiguration diese Anforderung vollständig. Es gibt keine grenzüberschreitende Übermittlung, die abgesichert werden müsste, wenn die Verarbeitung den EWR nicht verlässt.
Auch der EU AI Act erzwingt keine On-Premise-Verarbeitung. Artikel 10 fordert für Hochrisiko-Systeme dokumentierte Data Governance — Datenqualität, Repräsentativität, Bias-Prüfung, nachvollziehbare Herkunft. Das ist eine Anforderung an Prozesse und Dokumentation, nicht an den physischen Standort der Server. Die Verordnung ist technologie- und infrastrukturneutral formuliert. Relevant wird das spätestens mit der Anwendbarkeit der Hochrisiko-Pflichten ab dem 2. August 2026 (für einzelne Kategorien hat die jüngste Omnibus-Einigung den Stichtag nach hinten verschoben) — aber „relevant" heißt: Sie brauchen Governance-Dokumentation, nicht zwingend einen eigenen Serverraum.
On-Premise ist tatsächlich zwingend nur in einer kleinen Zahl von Fällen: wenn eine Branchenaufsicht oder ein Vertrag die Verarbeitung im eigenen Haus ausdrücklich vorschreibt, wenn Ihre eigene, verbindlich verabschiedete Datenklassifizierung — nicht eine Präferenz, eine Richtlinie — jegliche Drittverarbeitung für eine bestimmte Datenklasse untersagt, oder wenn Sie als-Verschlusssache eingestufte Daten oder bestimmte KRITIS-/Verteidigungssachverhalte verarbeiten. Für die überwiegende Mehrheit der DACH-Mittelständler trifft keiner dieser Fälle zu. Dann erfüllt eine EU-gehostete API die Souveränitätsanforderung — zu einem Bruchteil der Kosten von Self-Hosting.
Frage 2: Können Sie die operative Realität tragen?
Self-Hosting ist keine Hardware-Anschaffung. Es ist eine Daueraufgabe. Der Server ist der billige Teil; teuer sind die Menschen, die ihn am Laufen halten — Patchen, Monitoring, Modell-Updates, Skalierung unter Last, Incident Response um drei Uhr nachts, wenn die Inferenz ausfällt und die Fachabteilung anruft.
Hier liegt der am häufigsten unterschätzte Posten. Aktuelle TCO-Analysen für 2026 sind sich über die Quellen hinweg einig: Die tatsächlichen Gesamtbetriebskosten eines selbst betriebenen LLM-Stacks liegen beim Drei- bis Fünffachen der reinen GPU-Kosten, sobald Personal, Wartung und Betrieb eingerechnet sind. Ein Setup, das auf dem Papier nach 3.000 Euro Compute im Monat aussieht, kostet real eher 9.000 bis 15.000 Euro — der Unterschied ist im Wesentlichen Engineering-Zeit. SitePoint beziffert allein den laufenden Wartungsaufwand auf einen mittleren zweistelligen Stundenbedarf pro Monat zum Satz eines Senior-DevOps- oder ML-Engineers.
Auf dem DACH-Arbeitsmarkt verschärft sich dieser Posten zusätzlich: Erfahrene ML-Infrastruktur-Engineers sind knapp, sechsstellig im Jahresgehalt und in der Regel nicht in Wochen, sondern in Monaten zu besetzen. Wer Self-Hosting wählt, ohne dieses Team verlässlich zu haben oder aufbauen zu können, verlagert das Risiko nur — von einer planbaren API-Rechnung hin zu unplanbaren Ausfällen und Bereitschaftsdienst.
Frage 3: Rechtfertigt Ihr Volumen die Fixkosten?
Self-Hosting hat hohe Fixkosten und niedrige Grenzkosten. APIs haben niedrige Fixkosten und lineare Grenzkosten. Wo sich die beiden Kurven schneiden, hängt allein vom Volumen ab — und der ehrliche Break-Even liegt höher, als die meisten Business Cases ansetzen.
Unterhalb von rund 50 Millionen Tokens pro Monat — was den allermeisten Mittelstands-Anwendungsfällen entspricht — gewinnt die API in nahezu jedem Szenario, selbst inklusive des Aufschlags für EU-gehostete oder zero-retention-konfigurierte Endpunkte. Der Bereich zwischen etwa 50 und 500 Millionen Tokens pro Monat ist die eigentliche Entscheidungszone: Hier kann Self-Hosting gegenüber Frontier-Modellen rechnen — aber nur mit vorhandener MLOps-Kapazität. Erst bei sehr hohem, stabilem Durchsatz deutlich darüber liefert Self-Hosting die oft zitierten Einsparungen, weil sich die Fixkosten dann über genügend Inferenz verteilen. Wichtig: Der Vergleich verschiebt sich massiv danach, welche API Sie ersetzen. Gegen ein günstiges Open-Model-Hosting eines spezialisierten Anbieters, der bereits zu Skalenkosten optimiert betreibt, erreichen Sie den Break-Even praktisch nie.
Der Mittelweg: Managed Private Deployment
Zwischen vollem Self-Hosting und der öffentlichen Shared-API liegt die Option, die für den DACH-Mittelstand am häufigsten die richtige ist und die in den vergangenen zwei Jahren erheblich gereift ist: das Managed Private Deployment.
Private Endpoints in Azure, dedizierte beziehungsweise Provisioned-Throughput-Konfigurationen in Amazon Bedrock sowie spezialisierte europäische Inference-Anbieter stellen Modelle auf isolierter Infrastruktur in EU-Rechenzentren bereit — mit vertraglich zugesicherter Datenisolation und ohne Vermischung mit fremdem Traffic. Sie tragen die Souveränitäts- und Isolationsanforderung, aber nicht die operative Last des Eigenbetriebs.
Dafür zahlen Sie einen Aufschlag gegenüber dem Shared-Pricing — in der Praxis grob ein Drittel bis die Hälfte mehr pro Token. Im Gegenzug entfallen GPU-Beschaffung, Patch-Zyklen, Kapazitätsplanung und der schwer zu besetzende ML-Betrieb. Für ein Unternehmen, dessen eigentliche Anforderung Datenisolation und nicht vollständige Infrastrukturkontrolle ist, ist das fast immer die ökonomisch und regulatorisch saubere Architektur — und der Punkt, an dem das reflexhafte „wir hosten selbst" auseinanderfällt.
Das Empfehlungs-Raster
Treiber ist DSGVO-Compliance: Eine EU-gehostete API mit Art.-28-AVV und Zero-Retention reicht für die große Mehrheit der Anwendungsfälle. Self-Hosting erhöht hier die Kosten, ohne den Compliance-Nutzen zu steigern — Sie zahlen für eine Anforderung, die der Vertrag bereits erfüllt.
Treiber ist Branchenregulierung: Lesen Sie den konkreten Regulierungstext, nicht die Zusammenfassung im Flurfunk. Die meisten branchenspezifischen Vorgaben im DACH-Raum fordern Schutz und Nachweisbarkeit, nicht physische Verarbeitung im eigenen Haus. Wo On-Premise tatsächlich verlangt wird, erfüllt häufig schon ein Managed Private Deployment die Auflage.
Treiber ist Kostenoptimierung bei Skalierung: Self-Hosting lohnt oberhalb des Volumen-Break-Even — aber nur mit dem Team, das es betreibt. Ohne diese operative Fähigkeit verschwinden die rechnerischen Einsparungen in Ausfällen und Incident Response, und der Business Case kippt ins Negative.
Treiber ist Latenz: Kleine, eng definierte Modelle, selbst gehostet nah am Use Case, können Antwortzeiten liefern, die eine entfernte API nicht erreicht. Für echtzeitkritische Produktionsanwendungen kann das — unabhängig von den Kosten — der ausschlaggebende Grund sein. Für alles andere ist Latenz selten das eigentliche Argument.
Ein Fit Call klärt Ihre Self-Hosting-Frage entlang dieser drei Fragen — bevor Sie sechsstellig in Hardware und ein Team binden, das eine API oder ein Managed Private Deployment Ihnen erspart hätte. Wir bewerten regulatorische Anforderung, Datensensitivität, Volumenprognose und Team-Fähigkeit und empfehlen die Architektur, die Ihre Anforderung erfüllt, ohne zu überbauen.
Referenzen: Art. 28 DSGVO, Auftragsverarbeiter (gdpr-info.eu/art-28-gdpr/); EU AI Act, Artikel 10 „Data and Data Governance" (artificialintelligenceact.eu/article/10/); EU AI Act Implementation Timeline (artificialintelligenceact.eu/implementation-timeline/); SitePoint, „Local LLMs vs Cloud APIs: 2026 Total Cost of Ownership Analysis" (sitepoint.com/local-llms-vs-cloud-api-cost-analysis-2026/).