Selbstbetrieb vs. gehostet — wer betreibt die KI-Plattform?
Eine KI-Betriebsplattform selbst zu betreiben oder sie als verwalteten Dienst einzukaufen, sind zwei ehrlich verschiedene Abwägungen: die eine kostet Kontrolle, die andere Betriebskapazität. Diese Seite benennt die Abwägung offen und sagt am Ende, wo OperativeOps steht — ausschließlich im Selbstbetrieb, bewusst so entschieden.
- Die Frage ist nicht, welches Modell besser ist, sondern wer die Betriebslast trägt: Ein verwalteter Dienst trägt sie für Sie, beim Selbstbetrieb trägt sie Ihr Team.
- Verwaltete Dienste bedeuten tatsächlich weniger Arbeit — keine Updates, keine Backups, keine Rufbereitschaft. Das ist ein echter Vorteil, und ohne DevOps-Kapazität ist er sein Geld wert.
- Selbstbetrieb gewinnt dort, wo die Datengrenze die eigentliche Anforderung ist: regulierte Daten, Air-Gap-Netze oder ein bestehendes Compliance-Programm, das Sie lieber erweitern als ersetzen.
- Kosten entscheiden im ersten Jahr selten. Die Fixkosten des Selbstbetriebs schlagen nutzungs- oder platzbasierte Preise typischerweise erst ab etwa Jahr drei — und nur, wenn das Betriebsteam ohnehin existiert.
- OperativeOps gibt es ausschließlich im Selbstbetrieb. Es existiert keine verwaltete Instanz, mit der man starten oder zu der man migrieren könnte — wer den Betrieb abgeben muss, ist bei einem verwalteten Wettbewerber ehrlicherweise besser aufgehoben.
Die Abwägung, Kriterium für Kriterium
| Kriterium | Selbstbetrieb | Verwalteter Dienst | Tendenz |
|---|---|---|---|
| Datensouveränität | Vollständig. Daten bleiben innerhalb Ihrer Netzwerkgrenze — Ihre Schlüssel, Ihre Protokolle, Ihr Audit-Trail. | Vertraglich. Geregelt über AVV und die Datenhaltungszusagen des Anbieters. Auf dem Papier belastbar, aber nicht in Ihrer Hand. | Selbstbetrieb |
| Betriebsaufwand | Dauerhaft bei Ihnen. Updates, Backups, Monitoring, Patching und Incident Response sind eine stehende Aufgabe Ihres Teams. | Beim Anbieter. Das ist der größte und ehrlichste Vorteil eines verwalteten Dienstes. | Verwaltet |
| Zeit bis zum Produktivbetrieb | Typischerweise 1–4 Wochen — bestimmt durch Ihre Bereitstellung und Ihr Sicherheitsreview, nicht durch die Software selbst. | Stunden bis Tage. Registrieren, SSO anbinden, konfigurieren. | Verwaltet |
| Compliance-Nachweise | Ihr bestehendes Programm (ISO 27001, IT-Grundschutz, BSI C5) erstreckt sich auf das Deployment. Sie besitzen die Nachweise, und der Prüfer spricht mit Ihnen. | Sie übernehmen und prüfen die Kontrollzuordnung und Zertifikate des Anbieters. Weniger Aufwand für Sie, weniger Kontrolle für Sie. | Kommt darauf an |
| Kostenstruktur | Fix: Infrastruktur plus grob 0,25–0,5 VZÄ Betrieb. Bleibt konstant, während die Nutzung wächst. | Variabel: pro Platz oder nach Nutzung. Günstiger Einstieg, wächst mit der Verbreitung. | Kommt darauf an |
| Modellauswahl | Alles, was Sie selbst betreiben oder erreichen können — lokales Ollama oder vLLM auf eigenen GPUs ebenso wie gehostete Modell-APIs. | Was der Anbieter integriert hat. Vollständig lokale Inferenz ist in einem verwalteten Produkt selten. | Selbstbetrieb |
| Ausstiegskosten | Gering. Daten und Laufzeitumgebung liegen bereits bei Ihnen; ein Wechsel ist eine Konfigurationsänderung, keine Datenmigration. | Hängt vollständig von der Vollständigkeit des Exports und den Vertragsbedingungen ab. Klären Sie den Ausstiegspfad vor der Bindung. | Selbstbetrieb |
Selbst betreiben, wenn
- Regulierte Daten Ihr Netz nicht verlassen dürfen — BaFin-beaufsichtigte Finanzdienstleistung, MDR-regulierter Gesundheitsbereich oder öffentlicher Sektor mit Datenlokalisierungspflichten.
- Sie bereits ein Plattform- oder DevOps-Team haben, das Updates, Backups und Rufbereitschaft dauerhaft verantworten kann. Selbstbetrieb ohne dieses Team ist der Weg, auf dem Pilotprojekte still einschlafen.
- Sie ein bestehendes ISO-27001-, IT-Grundschutz- oder BSI-C5-Programm betreiben und Ihre eigene Compliance-Grenze lieber erweitern, als die eines Dritten zu prüfen.
- Air-Gap- oder Teil-Air-Gap-Netze im Spiel sind, in denen jede externe SaaS-Abhängigkeit disqualifiziert — unabhängig von der Qualität des AVV.
- Sie lokale Modellinferenz benötigen — Open-Weight-Modelle auf eigener GPU-Hardware, ohne dass ein Prompt das Haus verlässt.
- Der Zeithorizont lang ist (3+ Jahre), sodass fixe Infrastrukturkosten sich besser amortisieren als platzbasierte Preise, die mit der Belegschaft mitwachsen.
Einen verwalteten Dienst kaufen, wenn
- Keine DevOps-Kapazität vorhanden ist und auch keine realistische Aussicht besteht, sie aufzubauen. Ein verwaltetes Produkt nützt Ihnen dann mehr als eine selbst betriebene Plattform, für die niemand Zeit hat — das ist die richtige Entscheidung, kein Kompromiss.
- Time-to-Value die eigentliche Randbedingung ist: Sie brauchen etwas in dieser Woche produktiv, nicht nach Bereitstellungszyklus und Sicherheitsreview.
- EU-Only-Datenhaltung unter AVV Ihrem Datenschutzbeauftragten genügt und die Verarbeitung im eigenen Netz keine harte Anforderung ist.
- Sie den Anwendungsfall noch nachweisen und dafür kein Infrastrukturbudget binden möchten.
- Gehostete Modell-APIs Ihre Modellanforderungen abdecken und keine Datenklassifizierung dagegen spricht, ihnen Kontext zu übergeben.
- Elastische Skalierung wichtiger ist als Kontrolle — Lastspitzen sollen auf dem Pager eines anderen landen.
Wo OperativeOps steht
OperativeOps gibt es ausschließlich im Selbstbetrieb. Es wird als Software ausgeliefert, die Sie selbst bereitstellen — per Docker Compose auf einem einzelnen Host, on-premises auf Kubernetes oder vollständig air-gapped — in Infrastruktur, die Sie ohnehin kontrollieren. Eine verwaltete OperativeOps-Instanz existiert nicht: keine Umgebung, die für Sie betrieben wird, und damit auch keine Migration zwischen Betriebsmodi, die geplant werden müsste.
Das ist eine bewusste Einschränkung und keine Lücke auf einer Roadmap. Jede Designentscheidung setzt voraus, dass die Datenebene Ihnen gehört: Ihre Modell-Endpunkte und Schlüssel (OpenAI, Anthropic, Ollama, vLLM), Ihr Vektorspeicher, Ihre über MCP angebundenen Systeme und ein Append-only-Audit-Ledger, das in Ihrer Datenbank auf Ihrer Infrastruktur liegt.
Es bedeutet zugleich, dass OperativeOps für manche Leser die falsche Antwort ist. Wenn niemand da ist, der eine Container-Plattform betreiben kann, und auch kein Weg dorthin führt, gilt alles oben Gesagte über verwaltete Dienste für Sie — dann ist ein verwalteter Wettbewerber die bessere Wahl. Die Abwägung ist real, und etwas anderes zu behaupten würde die erste Rückfrage Ihres Betriebsteams nicht überstehen.
Frequently asked questions
Kann ich mit einem gehosteten OperativeOps starten und später in den Selbstbetrieb wechseln?
Nein — es gibt kein gehostetes OperativeOps, mit dem man starten könnte. Die Software wird ausschließlich für den Selbstbetrieb ausgeliefert; der einzige Weg führt in Infrastruktur, die Sie kontrollieren. Wenn der Reiz eines gehosteten Starts darin lag, sich nicht festzulegen, ist das nächste Äquivalent ein Wegwerf-Deployment: eine VM mit Docker Compose, die nach der Evaluierung wieder abgebaut wird.
Welche Infrastruktur setzt ein Selbstbetrieb voraus?
Mindestens: ein Linux-Host oder ein Kubernetes-Cluster mit Container-Runtime (Docker oder containerd), eine PostgreSQL-15+-Datenbank und — nur falls Agenten gehostete Modell-APIs aufrufen sollen — ausgehender Netzzugang über das Egress-Gate. Optional: ein oder mehrere GPU-Knoten für lokale Inferenz mit Ollama oder vLLM. Die Dimensionierung richtet sich nach der Zahl gleichzeitiger Nutzer und dem Umfang des Retrieval-Korpus.
Lässt sich das auch ohne Kubernetes-Cluster betreiben?
Ja. Docker Compose auf einer ausreichend dimensionierten VM oder einem dedizierten Server ist ein unterstützter Betriebsmodus und genügt für kleine und mittlere Deployments. Oberhalb dieser Größenordnung — oder wenn Hochverfügbarkeit und Rolling Updates gefordert sind — ist Kubernetes die bessere Wahl. In beiden Modi läuft dasselbe Release.
Bedeutet Selbstbetrieb, dass keine Daten mein Netz verlassen?
Nur wenn die konfigurierten Modell-Backends lokal laufen. Der Selbstbetrieb bestimmt, wo die Plattform und ihre Daten liegen; er hindert einen Agenten für sich genommen nicht daran, eine gehostete Modell-API aufzurufen. Ist ein gehosteter Anbieter konfiguriert, gehen Prompt und abgerufener Kontext unter dessen Bedingungen an diesen Anbieter. Erst Ollama oder vLLM auf eigener Hardware macht die Grenze absolut — und im Egress-Gate legen Sie pro Agent fest, welcher der beiden Fälle gilt.
Wie viel Betriebsaufwand verursacht eine selbst betriebene KI-Plattform realistisch?
Rechnen Sie im eingeschwungenen Zustand mit grob einem Viertel bis einer halben Entwicklerstelle für ein Produktivdeployment, zusätzlich zur anfänglichen Bereitstellung und zum Sicherheitsreview. Darin enthalten sind Versions-Upgrades, Datenbank-Backups samt Restore-Übungen, Zertifikats- und Abhängigkeits-Patching, Monitoring und Incident Response. Das ist keine Vollzeitstelle, muss aber namentlich jemandem gehören — selbst betriebene Deployments scheitern, wenn die Zuständigkeit bei niemandem liegt.
Verlangt die DSGVO den Selbstbetrieb?
Nein. Die DSGVO verlangt eine Rechtsgrundlage, geeignete technische und organisatorische Maßnahmen und einen gültigen Übermittlungsmechanismus für jede Verarbeitung außerhalb des EWR. Ein verwalteter Anbieter mit EU-Only-Datenhaltung und belastbarem AVV kann all das erfüllen. Selbstbetrieb ist ein Weg, diese Anforderungen zu erfüllen — häufig der kürzeste durch die Beschaffungsprüfung, weil kein Auftragsverarbeiter zu bewerten ist —, aber nicht der einzige.