Zum Hauptinhalt springen

Alle Artikel

LLM selbst hosten oder Managed beziehen: die CIO-Entscheidung 2026

Self-Hosting klingt nach Datensouveraenitaet und Kostenkontrolle, ist fuer die meisten Mittelstaendler 2026 aber teurer und langsamer. Das 4-Achsen-Framework fuer CIOs.

Sebastian LangSebastian Lang21. Mai 202610 Min. Lesezeit
LLM selbst hosten oder Managed beziehen: die CIO-Entscheidung 2026

Sobald Datenschutz im Raum steht, faellt in jeder CIO-Runde der Satz: "Dann hosten wir das LLM eben selbst." Das ist 2026 in 9 von 10 Faellen die teure Antwort auf eine Frage, die EU-Hosting schon loest. Der Satz fuehlt sich richtig an, weil er Kontrolle verspricht: eigene Hardware, eigene Daten, keine US-Vertraege. Die Rechnung sieht anders aus, sobald man GPU-Beschaffung, MLOps-Team, Modell-Qualitaet und den Update-Treadmill in dieselbe Tabelle schreibt wie die gefuehlte Ersparnis. Dieser Post ist die ehrliche Entscheidungsgrundlage, die wir in 40 DACH-Workshops gegen die Realitaet getestet haben: drei Bezugs-Modelle, vier Entscheidungs-Achsen, vier teure Fallen.

Die 3 Bezugs-Modelle auf einer Seite

4-Achsen-Entscheidungs-Framework LLM Self-Hosted vs Managed fuer CIOs 2026

Es gibt 2026 praktisch drei Wege, ein LLM in eine produktive Anwendung zu bringen. Managed in einer US-Region, Managed in einer EU-Region, oder self-hosted als Open-Weight-Modell im eigenen VPC oder On-Prem. Die meisten CIO-Runden springen direkt von Modell 1 zu Modell 3 und ueberspringen Modell 2, obwohl genau das in den meisten Faellen die richtige Wahl ist. Die Tabelle als Orientierung, bevor wir die Modelle einzeln aufmachen:

Bezugs-ModellDatensouveraenitaetKosten-PatternTeam-BedarfLatenzModell-QualitaetUpdate-Aufwand
Managed US-RegionDatentransfer in Drittland, DSGVO-Pruefung noetigInferenz pro Token, keine FixkostenKeiner (API-Integration)Sehr gutFrontier (hoechste)Keiner (Anbieter aktualisiert)
Managed EU-RegionData-Residency in der EU, AuftragsverarbeitungInferenz pro Token, keine FixkostenKeiner (API-Integration)Sehr gutFrontier (hoechste)Keiner (Anbieter aktualisiert)
Self-Hosted Open-WeightVolle Kontrolle, air-gapped moeglichGPU-Capex oder -Opex plus Betrieb, keine Token-KostenMLOps-Team noetigAbhaengig von eigener InfraOpen-Weight-Gap zu FrontierLaufend (selbst aktualisieren)

Der wichtigste Satz zur Tabelle: Datensouveraenitaet und Self-Hosting sind nicht dasselbe. Die EU-Region loest den groessten Teil des Souveraenitaets-Problems, ohne dass du eine einzige GPU kaufst. Wer das verwechselt, kauft Infrastruktur, um ein Vertrags-Problem zu loesen.

Modell 1: Managed in einer US-Region

Das ist der Default-Einstieg fuer fast jeden. Du integrierst die API eines grossen Anbieters, schreibst in Tagen den ersten produktiven Prototyp und zahlst pro Token, ohne jede Fixkosten-Verpflichtung. Die Modell-Qualitaet ist die hoechste, die der Markt 2026 hergibt, weil du direkt auf die Frontier-Modelle zugreifst. Welcher Anbieter dabei fuer welchen Zweck vorne liegt, sortiert der KI-Vergleich ChatGPT, Claude, Gemini. Fuer nicht-sensible Daten und einen schnellen Start ist das schwer zu schlagen.

Die Grenze liegt nicht in der Technik, sondern in der Compliance. Wenn deine Anfrage in einer US-Region verarbeitet wird, ist das ein Datentransfer in ein Drittland, und der braucht eine saubere DSGVO-Grundlage (Auftragsverarbeitungsvertrag plus geeignete Transfer-Mechanismen). Das ist machbar und wird taeglich praktiziert, aber es ist ein Pruefschritt, kein Selbstlaeufer. Wichtig ist hier die Trainings-Frage, die oft mit dem Hosting-Ort verwechselt wird: Bei den grossen Anbietern bleibt deine Eingabe in der Default-Konfiguration vom Training getrennt (Claude default no-training, ChatGPT mit Trainings-Toggle default off in Business und Enterprise, Gemini opt-in mit default off im Enterprise-Tier, Stand Mai 2026). Wo die Daten verarbeitet werden und ob sie ins Training fliessen, sind zwei getrennte Fragen, und beide muessen beantwortet sein.

Wann Modell 1 reicht: Die Daten sind nicht besonders sensibel (oeffentliche Inhalte, interne Texte ohne Personenbezug, allgemeine Recherche), du willst maximale Geschwindigkeit beim Start, und der Datentransfer in ein Drittland ist mit deinem Datenschutz vertretbar oder durch Pseudonymisierung entschaerft. Sobald aber personenbezogene oder geschaeftskritische Daten regelmaessig durch die US-Region laufen, wird Modell 2 zur ehrlicheren Wahl. Die rechtlichen Details dazu stehen im DSGVO-Agentic-AI-Production-Post.

Modell 2: Managed in einer EU-Region

Das ist der unterschaetzte Mittelweg, und fuer den DACH-Mittelstand 2026 in den meisten Faellen die richtige Antwort. Die grossen Anbieter bieten EU-Data-Residency-Optionen an, bei denen die Verarbeitung in EU-Rechenzentren stattfindet (Stand Mai 2026, Verfuegbarkeit je nach Anbieter, Tier und Modell unterschiedlich). Du bekommst dieselbe Frontier-Modell-Qualitaet, dieselbe Token-Abrechnung ohne Fixkosten und denselben Null-Aufwand bei Updates wie in Modell 1, aber die Daten verlassen die EU nicht.

Hier ist die Praezision wichtig, weil Marketing und Recht oft auseinanderfallen. Data-Residency in der EU bedeutet, dass die Verarbeitung in einem EU-Rechenzentrum stattfindet. Das ist ein starkes Argument, aber es ist nicht automatisch gleichbedeutend mit "DSGVO-konform". DSGVO-Konformitaet braucht zusaetzlich einen Auftragsverarbeitungsvertrag, definierte Zwecke, Loeschkonzepte und die Klaerung, ob ein US-Mutterkonzern theoretisch Zugriff haette. Souveraenitaet im juristischen Sinn (kein Drittland-Zugriff unter keiner Rechtsgrundlage) ist eine schaerfere Anforderung als Data-Residency. Fuer die allermeisten Mittelstands-Use-Cases reicht saubere EU-Data-Residency plus Auftragsverarbeitung vollkommen aus. Fuer einen sehr kleinen Kreis hochregulierter Faelle (bestimmte Behoerden, kritische Infrastruktur, militaerische Kontexte) reicht sie nicht, und genau dieser Kreis ist es, fuer den Modell 3 ueberhaupt existiert.

Der entscheidende Punkt fuer die CIO-Runde: EU-Hosting loest das Souveraenitaets-Bedenken, das die Self-Hosting-Diskussion ausgeloest hat, ohne den Self-Hosting-Aufwand. Wer in der Runde "wir hosten selbst" sagt, sollte zuerst die Frage beantworten, ob eine EU-Region das eigentliche Bedenken nicht schon abdeckt. In neun von zehn Faellen tut sie das.

Modell 3: Self-Hosted Open-Weight

Self-Hosting bedeutet, dass du ein Open-Weight-Modell (offene Gewichte, kein API-Zugriff auf ein fremdes Frontier-Modell) in deinem eigenen VPC oder On-Prem betreibst. Was es wirklich bringt, ist real und sollte nicht kleingeredet werden: volle Datenkontrolle, kein externer Datenfluss, air-gapped-Betrieb ist moeglich, und es fallen keine Token-Kosten pro Anfrage an. Fuer eine air-gapped-Umgebung, in der buchstaeblich kein Paket nach aussen darf, ist Self-Hosting nicht eine Option unter mehreren, sondern die einzige.

Was es wirklich kostet, ist die Seite, die in der CIO-Runde meist fehlt. Erstens GPU-Infrastruktur: produktive LLM-Inferenz braucht GPUs, entweder als Capex (Kauf, Abschreibung, Rechenzentrum) oder als Opex (gemietete GPU-Kapazitaet in der Cloud), und in beiden Faellen muss die Auslastung stimmen, sonst zahlst du fuer Leerlauf. Zweitens ein MLOps-Team: jemand muss das Modell deployen, monitoren, skalieren, absichern und auf dem aktuellen Stand halten. Das ist eine dauerhafte Personal-Verpflichtung, keine einmalige Aufgabe. Drittens der Modell-Qualitaets-Gap: Open-Weight-Modelle haben 2026 stark aufgeholt, aber die jeweils besten Frontier-Modelle der grossen Anbieter liegen in anspruchsvollen Aufgaben weiterhin vorn (Groessenordnung, Stand Mai 2026, ohne konkrete Benchmark-Zahl, weil die sich monatlich verschiebt). Viertens der Update-Treadmill: Wenn ein neues, besseres Open-Weight-Modell erscheint, musst du es selbst evaluieren, deployen und in Produktion bringen, waehrend Managed-Kunden das Update geschenkt bekommen.

Wann Modell 3 die richtige Wahl ist: Wenn die Daten so sensibel sind, dass selbst eine EU-Region mit Auftragsverarbeitung nicht ausreicht, oder wenn das Volumen so hoch und gleichfoermig ist, dass die GPU-Fixkosten unter den Token-Kosten liegen, und in beiden Faellen nur dann, wenn ein MLOps-Team bereits existiert oder bewusst aufgebaut wird. Self-Hosting ohne dieses Team ist kein Sparmodell, sondern ein verschleppter Aufwand, der spaeter teurer zurueckkommt.

Das 4-Achsen-Entscheidungs-Framework

Die Entscheidung haengt an vier Achsen, und sie ist bewusst einfach gehalten, weil sie in der Hektik einer CIO-Runde funktionieren muss.

Achse 1: Datenklassifizierung. Wie sensibel sind die Daten, die durch das Modell laufen? Oeffentliche oder pseudonymisierte Daten erlauben Modell 1. Personenbezogene oder geschaeftskritische Daten verlangen mindestens Modell 2. Nur die haerteste Klasse (Daten, bei denen kein externer Zugriff unter keiner Rechtsgrundlage akzeptabel ist) drueckt in Richtung Modell 3.

Achse 2: Volumen. Wie viele Anfragen, wie konstant? Niedriges oder schwankendes Volumen spricht klar fuer Managed, weil du nur das zahlst, was du nutzt, und keine GPU im Leerlauf finanzierst. Erst sehr hohes, gleichfoermiges Volumen kippt die Kosten-Rechnung in Richtung eigener Infrastruktur.

Achse 3: Team-Reife. Hast du ein MLOps-Team, das GPUs betreiben, Modelle deployen und absichern kann? Ohne dieses Team ist Self-Hosting keine ehrliche Option, egal wie die anderen Achsen stehen. Mit diesem Team wird Modell 3 ueberhaupt erst diskutierbar.

Achse 4: Latenz und Compliance. Brauchst du air-gapped-Betrieb oder eine harte Latenz-Garantie im eigenen Netz? Das sind die Spezialfaelle, in denen Self-Hosting nicht Kosten-Optimierung, sondern Anforderung ist.

Die Heuristik fasst die vier Achsen in einem Satz zusammen: Self-Hosting lohnt erst bei (sehr sensible Daten ODER sehr hohes konstantes Volumen) UND vorhandenem MLOps-Team. Fehlt eine der beiden Bedingungen, ist Managed (in der Regel EU-Region) die guenstigere, schnellere und ruhigere Wahl. Wer die Modell-Entscheidung innerhalb der Anwendung danebenlegt, findet die Logik im RAG-vs-Fine-Tuning-Post, denn Hosting und Hebel-Wahl gehoeren zusammen.

Kosten-Realitaet aus 40 DACH-Workshops

Die folgenden Groessenordnungen sind anonymisierte Aggregate aus 40 Sentient-Dynamics-Workshops zwischen Sommer 2025 und Mai 2026, Mitarbeiterzahl 80 bis 4.000 (Sentient-Dynamics-Workshop-Aggregat, Groessenordnungen):

Managed-Start: Tage. Ein produktiver Prototyp gegen eine Managed-API ist eine Sache von Tagen, mit minimalen Fixkosten und reiner Token-Abrechnung. Der Wechsel von US- auf EU-Region ist in den meisten Faellen eine Konfigurations- und Vertragsfrage, kein Re-Build. Das ist der Grund, warum Managed fast immer der erste produktive Schritt sein sollte: Der Lerneffekt ist billig und schnell.

Self-Hosting-Setup: Monate plus dediziertes Team. Eine belastbare self-hosted Inferenz-Infrastruktur mit GPU-Beschaffung oder -Anmietung, Deployment, Monitoring, Skalierung, Absicherung und einer Eval-Harness liegt in der Groessenordnung von Monaten, nicht Wochen, und sie braucht ein dediziertes Team, das sie dauerhaft betreibt. Dazu kommen GPU-Capex oder -Opex, deren Wirtschaftlichkeit an der Auslastung haengt. Das ist keine Tool-Entscheidung mehr, das ist eine Kapital- und Headcount-Allokation. Wer diese Groessenordnung gegen die gefuehlte Token-Ersparnis stellt, kommt im Mittelstand fast immer zum Schluss, dass Managed denselben Geschaeftswert frueher und billiger liefert. Die volle Rechnung ueber 12 Monate steht im TCO-Post.

4 Self-Hosting-Fallen, die CIOs 2026 unterschaetzen

GPU-Beschaffung und -Auslastung. GPUs sind 2026 nicht beliebig schnell verfuegbar, und gekaufte GPUs verlieren ihren Wert, sobald die naechste Generation kommt. Die groessere Falle ist die Auslastung: Eine GPU, die nachts und am Wochenende leer laeuft, kostet trotzdem voll. Self-Hosting rechnet sich nur bei hoher, gleichmaessiger Auslastung, und genau die hat der typische Mittelstands-Use-Case selten.

Modell-Update-Treadmill. Bei Managed bekommst du Modell-Verbesserungen geschenkt, der Anbieter aktualisiert im Hintergrund. Self-hosted musst du jedes neue Open-Weight-Modell selbst evaluieren, gegen deine Use-Cases testen, deployen und in Produktion bringen. Das ist eine laufende Aufgabe, die nie endet, weil der Markt sich monatlich bewegt. Wer das nicht einplant, friert auf einem alten Modell ein und verliert genau den Qualitaets-Vorsprung, fuer den Managed bezahlt wird.

Eval und Safety selbst bauen. Bei Managed kommen Safety-Filter, Missbrauchs-Schutz und ein Teil der Eval-Infrastruktur mit. Self-hosted baust du das selbst: Prompt-Injection-Schutz, Output-Filterung, Eval-Harness, Monitoring auf Halluzinationen. Das ist eine eigene Engineering-Disziplin, kein Nebenprodukt des Deployments. Wer den Schritt von Pilot zu Production unterschaetzt, sollte die 5 Architekturfehler im Mittelstand kennen.

Total-Cost-of-Ownership vs gefuehlte Ersparnis. Die gefuehlte Ersparnis ist "keine Token-Kosten mehr". Die echten Kosten sind GPU-Capex oder -Opex, MLOps-Personal, Update-Aufwand, Eval- und Safety-Aufbau und das Risiko, auf einem schwaecheren Modell festzuhaengen. In der Mehrzahl der Mittelstands-Faelle ist die TCO von Self-Hosting hoeher als die kumulierten Token-Kosten von Managed, und sie kommt mit deutlich mehr operativem Risiko. Wer ueberhaupt nicht in eine Lock-in-Falle laufen will, sollte die Vertragsseite im Vendor-Lock-in-Post mitlesen, denn auch Managed hat seine Bindungen, nur andere. Den ganzen Strauss vermeidbarer Fehler zeigt der Ueberblick zu den Anti-Pattern hinter 40 Prozent gescheiterten Projekten.

FAQ

Reicht EU-Hosting fuer die DSGVO?

EU-Data-Residency ist ein starker Baustein, aber nicht automatisch gleich DSGVO-Konformitaet. Du brauchst zusaetzlich einen Auftragsverarbeitungsvertrag, definierte Zwecke und Loeschkonzepte, und du solltest klaeren, ob ein US-Mutterkonzern theoretisch Zugriff haette. Fuer die allermeisten Mittelstands-Use-Cases reicht saubere EU-Data-Residency plus Auftragsverarbeitung vollkommen aus. Data-Residency ist eine notwendige, aber keine hinreichende Bedingung, und genau diesen Unterschied sollte die CIO-Runde bewusst treffen.

Was kostet eine GPU-Inferenz-Infra realistisch?

Belastbare Zahlen haengen so stark an Modellgroesse, Volumen und Auslastung, dass eine pauschale Eurozahl mehr Schaden als Nutzen anrichtet. Die ehrliche Antwort ist eine Groessenordnung, kein Preis: GPU-Capex oder -Opex plus dediziertes MLOps-Team plus laufender Update-, Eval- und Safety-Aufwand (Sentient-Dynamics-Workshop-Aggregat, Groessenordnung). Der entscheidende Hebel ist die Auslastung. Rechne nicht die Listenpreise einer GPU, rechne die Kosten pro tatsaechlich genutzter Inferenz-Stunde ueber ein realistisches Lastprofil, und stelle das gegen die kumulierten Token-Kosten von Managed.

Sind Open-Weight-Modelle 2026 gut genug?

Fuer viele Standard-Aufgaben ja, fuer die anspruchsvollsten Aufgaben liegen die besten Frontier-Modelle der grossen Anbieter weiterhin vorn (Groessenordnung, Stand Mai 2026, ohne Benchmark-Prozent, weil sich der Abstand monatlich verschiebt). Die ehrliche Vorgehensweise ist eine Eval gegen deine eigenen Use-Cases, nicht ein generischer Benchmark aus einer Praesentation. Wenn ein Open-Weight-Modell deine konkreten Aufgaben in deiner Eval gut genug loest, ist die Qualitaetsfrage beantwortet. Wenn nicht, ist sie es auch, und dann hilft kein Souveraenitaets-Argument darueber hinweg.

Ist ein Hybrid moeglich (sensible Daten self-hosted, Rest managed)?

Ja, und fuer einen Teil der Faelle ist das die sauberste Architektur. Du routest die wenigen wirklich hochsensiblen oder air-gapped-pflichtigen Anfragen auf ein self-hosted Open-Weight-Modell und alles andere auf eine Managed-EU-Region. So zahlst du den Self-Hosting-Aufwand nur fuer den schmalen Teil, der ihn wirklich braucht, und bekommst fuer den Rest Frontier-Qualitaet ohne eigene Infra. Die Voraussetzung bleibt dieselbe: ein MLOps-Team fuer den self-hosted Teil. Hybrid spart nicht den Aufwand, es begrenzt ihn.

Wie passt diese Entscheidung in eine Engineering-Roadmap?

Genau in der Reihenfolge der Achsen: Datenklassifizierung zuerst, dann Volumen, dann Team-Reife, dann die Spezialfaelle Latenz und Compliance. In der Praxis startet fast jeder Use-Case auf Managed (oft EU-Region), und nur die wenigen Faelle, die die Heuristik klar erfuellen, wandern in Richtung self-hosted. Welche Tools im Stack drumherum 2026 wirklich produktiv laufen, sortiert die KI-Tools-Landschaft 2026.


Sources:

  • Sentient-Dynamics-Workshop-Aggregate, 40 DACH-Workshops 2025-2026 (Mitarbeiterzahl 80 bis 4.000; Kosten- und Dauer-Groessenordnungen)
  • Bitkom KI-Studie 2025 (deutsche Unternehmen mit 20+ MA: 41 Prozent Adoption; deutsche Unternehmen ab 500 MA: 89 Prozent Adoption)
  • McKinsey State of AI, November 2025
  • Gartner Press Release, Juni 2025
  • MIT NANDA Report 2025: "GenAI Divide: State of AI in Business 2025"
  • Anthropic Terms 2025 (default no-training on user prompts)
  • OpenAI Business / Enterprise Settings 2025/2026 (Trainings-Toggle default off)
  • Google Workspace Gemini Enterprise Tier Settings 2025/2026 (default off)

Naechster Schritt: Wenn du fuer einen konkreten Use-Case entscheiden willst, ob Managed-EU-Region oder Self-Hosting der richtige Weg ist, buch dir 30 Minuten ueber unsere Demo-Seite. Wir bringen das 4-Achsen-Framework, die 40-Workshop-Aggregation und drei Fragen, kein Vendor-Deck. Wer parallel den Coding-Teil seines Stacks vergleicht, findet ihn im Coding-Agent-Vergleich, und wer den August-Stichtag im Blick behalten muss, im AI-Act-90-Tage-Compliance-Plan.

Sebastian Lang

Über den Autor

Sebastian Lang

Co-Founder · Business & Content Lead

Co-Founder von Sentient Dynamics. 15+ Jahre Business-Strategie (u.a. SAP), MBA. Schreibt über AI-Act-Compliance, ROI-Messung und wie Mittelstand-CTOs agentische KI tatsächlich einführen.

Weiterlesen

Einmal im Monat. Nur Substanz.

Keine Motivationssprüche. Keine Tool-Listen. Nur was CTOs, COOs und Geschäftsführer in DACH über KI-Adoption wirklich wissen müssen.