Artikel
Azure AI Foundry oder selbst gehostete OSS-Modelle? Eine Entscheidungshilfe für IT-Entscheider
SOTA-Modelle aus der Microsoft-Cloud gegen selbst betriebene Open-Weight-Modelle auf eigener Hardware – mit ehrlicher 3-Jahres-TCO für 400 Nutzer und einem klaren Blick auf DSGVO und US CLOUD Act.
Azure AI Foundry oder selbst gehostete OSS-Modelle? Eine Entscheidungshilfe für IT-Entscheider
Stand: Juni 2026. Preise, Modellgenerationen und die Rechtslage zu transatlantischen Datentransfers bewegen sich derzeit im Monatstakt. Die Zahlen in diesem Beitrag sind Planungsgrößen, keine Angebote – verifizieren Sie sie vor einer Investitionsentscheidung.
Wenn ein 400-Personen-Unternehmen heute einen internen LLM-Assistenten einführen will, fällt die Frage fast reflexartig: Cloud oder selbst betreiben? Und meist folgt sofort die zweite, ebenso reflexartige Annahme: „Selbst hosten ist auf Dauer billiger, und nur so bekommen wir die Daten in den Griff.”
Beide Annahmen sind bei dieser Unternehmensgröße falsch – zumindest in dieser Pauschalität. Dieser Beitrag rechnet die Total Cost of Ownership über drei Jahre durch und ordnet die DSGVO- und CLOUD-Act-Frage so ein, dass am Ende eine begründbare Entscheidung steht statt eines Bauchgefühls.
Die Kurzfassung vorweg: Bei 400 Nutzern entscheidet nicht die Kostentabelle. Sie entscheidet die Frage, wie viel Datensouveränität Sie tatsächlich brauchen.
Die zwei Optionen im Klartext
Option A – Azure AI Foundry mit SOTA-Modellen. Microsofts Plattform bündelt über 11.000 Modelle, darunter die OpenAI-GPT-Reihe, Mistral, Meta Llama, DeepSeek und xAI Grok, abrechenbar pro Token (Pay-as-you-go) oder über reservierte Kapazität (Provisioned Throughput). „SOTA-Zugang” ist dabei kein Einzelmodell, sondern eine Bandbreite: vom effizienten Flaggschiff bis zum Frontier-Modell – ein Unterschied, der sich, wie wir sehen werden, massiv in der Rechnung niederschlägt.
Option B – Selbst gehostete Open-Weight-Modelle. Modelle wie Qwen3 (Apache 2.0), Mistral (EU-Jurisdiktion), GLM-5.1 (MIT) oder gpt-oss laufen auf eigener GPU-Hardware im eigenen Rechenzentrum oder Serverraum. Der Qualitätsabstand zu den geschlossenen Frontier-Modellen ist 2026 auf grob sechs bis neun Monate geschrumpft – für die meisten internen Anwendungsfälle (Recherche, Zusammenfassung, Entwurf, RAG über eigene Dokumente) längst ausreichend.
Das Mengengerüst: von Nutzern zu Token
Der häufigste Dimensionierungsfehler ist, „400 Nutzer” oder „200 wöchentlich Aktive” für eine Lastgröße zu halten. Das sind sie nicht. Relevant ist erstens die Gleichzeitigkeit (für die Hardware-Dimensionierung beim Self-Hosting) und zweitens das monatliche Token-Volumen (für die Cloud-Rechnung).
Für diesen Beitrag rechne ich mit folgenden, bewusst transparent gehaltenen Annahmen:
- 400 registrierte Nutzer, davon 200 wöchentlich aktiv
- Realistische Spitzenlast: 5–10 gleichzeitige Generierungen, Headroom bis ~20
- Rund 60 Mio. Token pro Monat (ca. 45 Mio. Input, 15 Mio. Output) bei einem RAG-gestützten internen Assistenten mit gehobenem Nutzungsgrad
Diese Zahl skaliert linear: Verdoppelt sich die Nutzung, verdoppeln sich die Cloud-Tokenkosten – die Fixkosten des Self-Hostings kaum. Genau das ist später der Hebel.
Die Kostenrechnung über drei Jahre
Option A: Azure AI Foundry
Die Tokenpreise (Global Standard, pro 1 Mio. Token, Stand Juni 2026) spreizen sich erheblich. Das effiziente Flaggschiff GPT-5 liegt bei rund 1,25 USD Input / 10,00 USD Output. Das Frontier-Modell GPT-5.5 dagegen bei etwa 5,00 USD / 30,00 USD. Genau hier wird die Modellwahl zur kostenbestimmenden Entscheidung.
Dazu kommen zwei Aufschläge, die in keiner Tabellenkalkulation fehlen dürfen: ein Aufschlag für Datenresidenz (regionale bzw. EU-Data-Zone-Deployments sind teurer als Global Standard, Größenordnung rund 10 %) und ein Betriebs-Overhead von 15–40 % über den reinen Tokenkosten – Support-Plan (ab ca. 100 USD/Monat für Produktivbetrieb faktisch Pflicht), privates Networking, Monitoring, Datenabfluss.
Für 60 Mio. Token/Monat ergibt sich (USD grob mit 0,92 in EUR umgerechnet):
| Modell | Tokenkosten/Jahr | + Residenz & Overhead | CapEx | 3-Jahres-TCO |
|---|---|---|---|---|
| GPT-5 (effizientes Flaggschiff) | ~€2.700 | ~€1.200/Jahr | €0 | ~€11.700 |
| GPT-5.5 (Frontier) | ~€7.450 | ~€1.800/Jahr | €0 | ~€27.800 |
Der Reiz: keine Investition, sofort startklar, immer das aktuellste Modell, lineare Skalierung. Der Haken: Die Rechnung wächst proportional zur Nutzung – und weil Output-Token das Vier- bis Achtfache der Input-Token kosten, können agentische oder sehr generierungsintensive Workloads die Kosten schnell treiben.
Option B: Self-Hosting auf eigener Hardware
Für die genannte Last genügt eine moderne GPU mit viel Speicher. Die NVIDIA RTX PRO 6000 Blackwell mit 96 GB ist der Sweet Spot: Ein 32B-Modell (FP8/AWQ) belegt rund 35 GB, der Rest steht als KV-Cache für 15–20 parallele Sessions zur Verfügung.
CapEx (einmalig):
| Position | Betrag |
|---|---|
| RTX PRO 6000 Blackwell 96 GB | ~€9.500 |
| Server (CPU, 256 GB RAM, NVMe, PSU, Gehäuse, Kühlung) | ~€4.500 |
| Einrichtung & Integration (einmalig) | ~€2.000 |
| CapEx gesamt | ~€16.000 |
OpEx (pro Jahr):
| Position | Betrag |
|---|---|
| Strom (~3.000 kWh @ €0,25) | ~€750 |
| Wartung, Ersatzteile, Tooling | ~€500 |
| Betrieb / DevOps (~4 h/Monat, vollkostenbasiert) | ~€3.500 |
| OpEx/Jahr | ~€4.750 |
3-Jahres-TCO Self-Hosting: ~€30.250 (realistische Bandbreite €26.000–€36.000, abhängig von der Server-Edition der GPU und davon, wie ehrlich Sie die eigene Betriebszeit bepreisen).
Der größte und am häufigsten unterschätzte Posten ist nicht die GPU, sondern die Betriebszeit. Patching, Modell-Updates, Incident Response, Kapazitätsplanung – das verschwindet nicht auf der Hardware-Rechnung, sondern in der Personalbindung.
Der direkte Vergleich
| Option | CapEx | OpEx/Jahr | 3-Jahres-TCO |
|---|---|---|---|
| Azure GPT-5 (EU Data Zone) | €0 | ~€3.900 | ~€11.700 |
| Azure GPT-5.5 (Frontier) | €0 | ~€9.250 | ~€27.800 |
| Self-Hosting OSS (RTX PRO 6000) | ~€16.000 | ~€4.750 | ~€30.250 |
Das ist das kontraintuitive Ergebnis: Bei 400 Nutzern ist Self-Hosting nicht die günstige Option. Azure mit einem effizienten SOTA-Modell ist mit Abstand am billigsten. Self-Hosting erreicht erst gegenüber der teuren Frontier-Stufe ungefähre Parität – und auch das nur, wenn man die eigene Betriebszeit großzügig wegrechnet.
Wann kippt die Rechnung zugunsten von Self-Hosting? Es ist eine Volumenfrage. Die Self-Hosting-Kosten sind weitgehend fix und wachsen kaum mit der Nutzung. Bei deutlich höherem Token-Durchsatz – etwa dem Fünf- bis Zehnfachen, oder bei dauerhaft hoher Auslastung durch agentische Workloads – amortisiert sich die Hardware, und die eigene GPU gewinnt. Bei 400 Nutzern mit moderater Nutzung ist dieser Punkt noch nicht erreicht.
Damit ist die Kostenfrage bei dieser Größe entschieden – aber nicht entscheidend. Die eigentliche Weiche stellt die Compliance.
DSGVO und US CLOUD Act: der eigentliche Knackpunkt
Zunächst eine Begriffsklärung, die in der Praxis oft schiefgeht: Einen „EU Cloud Act” gibt es nicht. Gemeint ist der Konflikt zwischen dem US CLOUD Act (2018) und der DSGVO. Der EU Data Act regelt separat den Zugriff auf nicht-personenbezogene Daten.
Warum Datenresidenz das Problem nicht löst
Der entscheidende Punkt: Der CLOUD Act knüpft an die Kontrolle des Anbieters an, nicht an den Speicherort der Daten. Ein US-Unternehmen ist verpflichtet, auf gültige Anordnung einer US-Behörde Daten herauszugeben – unabhängig davon, ob die Server in Frankfurt, Dublin oder Iowa stehen. Genau das war der Ausgangsfall 2018: Microsoft musste klären, ob in Irland gespeicherte Daten an US-Behörden gehen müssen. Die Antwort: ja, weil Microsoft ein US-Konzern ist.
Microsofts EU Data Boundary verarbeitet Daten innerhalb der EU/EFTA (u. a. Deutschland, Frankreich, Niederlande, Schweden, Schweiz). Das adressiert die Residenz – also wo Daten liegen. Es adressiert nicht die Jurisdiktion – also wer rechtlich Zugriff erzwingen kann. Die Muttergesellschaft bleibt US-Recht unterworfen. Damit bleibt die CLOUD-Act-Exposition bestehen, auch in der EU-Region.
Artikel 48 DSGVO ist an dieser Stelle unmissverständlich: Anordnungen ausländischer Behörden zur Datenübermittlung sind nur über ein völkerrechtliches Abkommen (etwa ein MLAT) anerkennungsfähig. Daraus folgt ein struktureller Normkonflikt – nicht wegen eines konkreten Vorfalls, sondern bauartbedingt.
Die Rechtsgrundlage steht 2026 auf wackeligem Fundament
Das EU-U.S. Data Privacy Framework (DPF) sollte den Transfer seit 2023 absichern. Doch nach dem Schrems-II-Urteil verlangt die DSGVO ohnehin Transfer Impact Assessments, die CLOUD-Act- und FISA-702-Risiken ehrlich bewerten, sowie technische Zusatzmaßnahmen. Die EDPB-Empfehlung 01/2020 nennt als primäre Maßnahme kundengesteuerte Verschlüsselung mit Schlüsseln außerhalb der Anbieter-Infrastruktur.
Mehrere Aufsichtsbehörden – darunter die österreichische, französische und italienische – haben bestimmte US-Cloud-Modelle als DSGVO-widrig eingestuft. Und das DPF selbst steht politisch unter Druck: Die im Frühjahr 2025 erfolgten Entlassungen im PCLOB (jenem Gremium, das die US-Datenschutzzusagen überwachen soll) wurden zwar gerichtlich für rechtswidrig erklärt, illustrieren aber die politische Steuerbarkeit der Grundlage. Dass der CLOUD Act keine theoretische Größe ist, zeigen die Transparenzberichte: Microsoft verzeichnete allein im ersten Halbjahr 2025 mehrere tausend Anfragen von US-Strafverfolgungsbehörden.
Hinzu kommt für regulierte Branchen: NIS2 und DORA verschärfen die Anforderungen an das Drittanbieter-Risikomanagement zusätzlich.
Was Self-Hosting hier leistet
Eine eigene Hardware im eigenen Rechenzentrum ist die einzige Architektur, die echte Datensouveränität bietet: kein Drittlandtransfer, kein Anbieter, der einer fremden Jurisdiktion unterliegt, kein „Kill-Switch”-Risiko durch geopolitisch motivierte Zugriffssperren. Für hochsensible Datenklassen – Gesundheits-, Personal- oder Mandantendaten in großem Umfang – ist das oft kein Kostenargument, sondern eine nicht verhandelbare Voraussetzung.
Die Entscheidungsmatrix
Statt einer Pauschalantwort hilft eine Einordnung nach Datenklasse:
| Profil | Empfehlung |
|---|---|
| Geringe Sensibilität, kostenbewusst, beste Modellqualität gewünscht | Azure GPT-5 in der EU Data Zone, mit kundengesteuerten Schlüsseln, TIA und DSFA |
| Hohe Sensibilität, Souveränität nicht verhandelbar, NIS2-/DORA-Scope | Self-Hosting mit Qwen3-32B oder Mistral |
| Gemischter Bedarf | Hybrid / Routing nach Datenklasse: sensible und einfache Anfragen lokal auf OSS, komplexe und unkritische an Azure-SOTA |
Der Hybrid-Ansatz ist für die meisten 400-Personen-Häuser die pragmatischste Lösung: Man bezahlt die teuren Frontier-Token nur dort, wo sie wirklich gebraucht werden, und hält die sensiblen Daten im Haus.
Fazit
Wer bei 400 Nutzern allein auf die Kostentabelle schaut, wird überrascht: Self-Hosting ist hier nicht der Spargewinn, als der es gilt. Azure mit einem effizienten SOTA-Modell ist günstiger – solange man nicht aus Reflex das teuerste Frontier-Modell wählt.
Die wirklich tragende Entscheidung liegt eine Ebene höher. Sie lautet nicht „11.700 € oder 30.000 €”, sondern: Können wir es uns leisten, dass unsere sensibelsten Daten einer fremden Jurisdiktion ausgesetzt sind? Wer diese Frage für bestimmte Datenklassen mit Nein beantwortet, hat seine Architektur bereits gewählt – und der Aufpreis fürs Self-Hosting ist dann kein Mehrkosten-, sondern ein Versicherungsposten.
Beginnen Sie mit einer Datenklassifizierung und einer Datenschutz-Folgenabschätzung. Erst danach ist die Kostenrechnung mehr als eine schöne Tabelle.
Hinweis: Dieser Beitrag ersetzt keine Rechtsberatung. Für eine verbindliche Bewertung der DSGVO-Konformität konsultieren Sie Ihren Datenschutzbeauftragten oder eine fachkundige Kanzlei.
