Interne KI-Plattformen: Aufbauen statt kaufen
Immer mehr Unternehmen entscheiden sich, eigene KI-Plattformen aufzubauen, statt auf fertige SaaS-Lösungen zu setzen. Die Gründe sind vielfältig: Datensouveränität, Flexibilität, Kosteneffizienz bei Skalierung. Doch der Aufbau einer internen Plattform ist anspruchsvoll – und die Entscheidung zwischen Build und Buy will gut kalkuliert sein. In diesem Beitrag zeige ich, wann sich eine eigene Plattform rechnet, wie Sie den Aufbau strukturieren und welche typischen Fehler Sie vermeiden sollten.
Warum eine eigene Plattform?
Vorteile
- Datensouveränität: Sensible Daten verlassen das Unternehmen nicht. Gerade in regulierten Branchen wie Finanzdienstleistungen, Gesundheitswesen oder der öffentlichen Verwaltung ist das ein entscheidendes Kriterium. Bei einer durchdachten KI-Strategie steht Datensouveränität oft an erster Stelle.
- Anpassbarkeit: Volle Kontrolle über Features und Integrationen. Sie sind nicht auf die Roadmap eines SaaS-Anbieters angewiesen und können Ihre Plattform exakt auf interne Workflows zuschneiden.
- Kosteneffizienz: Bei hohem Volumen deutlich günstiger als SaaS-Preismodelle. Ein Unternehmen mit 500 aktiven KI-Nutzern zahlt bei typischen SaaS-Lösungen schnell 15.000–30.000 € pro Monat. Eine eigene Plattform amortisiert sich in vielen Fällen bereits nach 12–18 Monaten.
- Vendor Independence: Keine Abhängigkeit von einzelnen Anbietern. Wenn ein SaaS-Provider die Preise erhöht, die API ändert oder den Dienst einstellt, stehen Sie nicht vor einem Migrationsproblem.
- Differenzierung: KI-Capabilities als Wettbewerbsvorteil. Proprietäre Pipelines, spezialisierte Modelle und unternehmenseigene Datenintegration sind schwer kopierbar.
Nachteile
- Aufwand: Signifikante initiale Investition. Rechnen Sie mit 150.000–400.000 € für den Aufbau einer produktionsreifen Plattform, je nach Umfang.
- Expertise: ML-Engineering-Know-how erforderlich. Sie brauchen mindestens 2–3 erfahrene Ingenieure, die sich mit Kubernetes, GPU-Orchestrierung und ML-Frameworks auskennen.
- Wartung: Laufende Pflege und Updates binden dauerhaft Ressourcen. Rechnen Sie mit 20–30% des initialen Aufwands als jährliche Betriebskosten.
- Time-to-Market: Längere Entwicklungszeit. Während eine SaaS-Lösung in Tagen einsatzbereit ist, dauert der Plattformaufbau typischerweise 3–6 Monate bis zum ersten produktiven Use Case.
Total Cost of Ownership: Build vs Buy über 3 Jahre
Die häufigste Fehleinschätzung bei der Build-vs-Buy-Entscheidung ist die Fokussierung auf initiale Kosten statt auf die Gesamtkosten über den Nutzungszeitraum. Hier ein realistischer Vergleich für ein mittelständisches Unternehmen mit 200 aktiven Nutzern und ca. 500.000 LLM-Anfragen pro Monat:
SaaS-Lösung (Buy)
| Kostenposition | Monat | 3 Jahre |
|---|---|---|
| SaaS-Lizenzkosten (200 Nutzer) | 8.000 € | 288.000 € |
| API-Kosten (OpenAI, Anthropic) | 6.000 € | 216.000 € |
| Integration & Customizing (intern) | 2.000 € | 72.000 € |
| Compliance & Audit (extern) | 500 € | 18.000 € |
| Gesamt | 16.500 € | 594.000 € |
Eigene Plattform (Build)
| Kostenposition | Monat | 3 Jahre |
|---|---|---|
| Initiale Entwicklung (einmalig) | – | 250.000 € |
| Cloud-Infrastruktur (GPU + Storage) | 4.500 € | 162.000 € |
| Plattform-Team (anteilig 1,5 FTE) | 12.000 € | 432.000 € |
| Open-Source-Modelle (Hosting) | 1.500 € | 54.000 € |
| API-Kosten (hybrid, reduziert) | 1.500 € | 54.000 € |
| Gesamt | – / 19.500 € | 952.000 € |
Auf den ersten Blick scheint Buy günstiger. Doch die Rechnung verschiebt sich drastisch bei wachsendem Volumen: Verdoppelt sich die Nutzung auf 1 Million Anfragen pro Monat, steigen die SaaS-Kosten nahezu linear auf über 1,1 Mio. € in 3 Jahren. Die eigene Plattform skaliert dagegen mit marginalen Mehrkosten auf rund 1,05 Mio. €. Ab ca. 800.000 Anfragen pro Monat kippt die Rechnung zugunsten von Build.
Dazu kommt ein Faktor, der sich schwer beziffern lässt: Bei der eigenen Plattform bauen Sie internes Know-how auf. Bei SaaS bleibt das Wissen beim Anbieter. Für Strategien zur Kostenoptimierung bei der LLM-Inferenz lohnt sich ein separater Blick auf Batch-Processing, Caching und Modellwahl.
Architektur einer KI-Plattform
Eine moderne interne KI-Plattform besteht aus mehreren Schichten, die aufeinander aufbauen. Jede Schicht hat spezifische Anforderungen an Technologie, Betrieb und Sicherheit.
1. Infrastruktur-Schicht
- Compute: Kubernetes-Cluster mit GPU-Nodes oder Cloud-GPU-Anbindung. Aktuelle Kosten: Eine NVIDIA A100 kostet bei AWS ca. 3,67 $/h (on-demand) oder 1,50–2,00 $/h mit Spot-Instanzen. Für Inferenz reichen oft NVIDIA L4-GPUs zu 0,81 $/h. Für viele Unternehmen ist ein hybrides Setup sinnvoll: On-Demand-GPUs für Spitzenlasten, Reserved Instances für Basislast.
- Storage: Object Storage (S3, MinIO) für Trainingsdaten (ca. 0,023 $/GB/Monat), Vector Databases (Qdrant, Weaviate, pgvector) für Embeddings, PostgreSQL für Metadaten. Bei 10 TB Trainingsdaten sind das rund 230 $/Monat – ein Bruchteil der Compute-Kosten.
- Networking: Sichere Verbindungen zwischen Komponenten mit Service Mesh (Istio, Linkerd), VPN-Tunnel zu On-Premises-Datenquellen, und mTLS für interne Kommunikation.
2. ML-Plattform-Schicht
- Experiment Tracking: MLflow (Open Source, self-hosted) oder Weights & Biases (SaaS). MLflow ist der De-facto-Standard für Self-Hosting und deckt Tracking, Modell-Registry und Deployment ab.
- Model Registry: Versionierung und Deployment-Management. Jedes Modell wird mit Herkunft, Metriken, Trainingsdaten und Lizenzinformationen versioniert.
- Feature Store: Wiederverwendbare Features für verschiedene Modelle. Feast (Open Source) oder Tecton (managed) sorgen dafür, dass Teams nicht dieselben Features doppelt berechnen.
- Training Pipelines: Automatisierte Trainingsworkflows mit Kubeflow, Airflow oder Prefect. Für den Übergang von Prototyp zu Produktion sind reproduzierbare Pipelines entscheidend.
3. Inference-Schicht
- Model Serving: vLLM, TGI (Text Generation Inference) oder Triton Inference Server für optimierte Inferenz. vLLM erreicht durch PagedAttention bis zu 24x höheren Durchsatz als naive Implementierungen.
- API Gateway: Rate Limiting, Authentication, Routing und Versionierung. Kong, Traefik oder ein eigenes Gateway auf Basis von FastAPI.
- Caching: Semantisches Caching mit Redis oder einer dedizierten Lösung reduziert Latenz um 60–80% für wiederkehrende Anfragen und senkt Kosten signifikant.
4. Anwendungs-Schicht
- Entwickler-APIs: Einheitliche Schnittstellen für interne Teams – idealerweise OpenAI-kompatibel, damit bestehende Tools und SDKs weiterverwendet werden können.
- Low-Code Tools: Für Business-Nutzer ohne Programmierkenntnisse. Interne Prompt-Builder, Workflow-Editoren oder Chatbot-Konfiguratoren senken die Einstiegshürde.
- Monitoring: Qualitäts- und Performance-Überwachung mit Prometheus, Grafana und spezialisierten LLM-Monitoring-Tools wie Langfuse oder Phoenix.
Build vs Buy: Die Entscheidungsmatrix
Nicht jede Komponente muss selbst gebaut werden. Die Kunst liegt darin, die richtige Mischung zu finden:
| Komponente | Build | Buy | Empfehlung | Begründung |
|---|---|---|---|---|
| GPU-Infrastruktur | ○ | ● | Cloud (außer bei sehr hohem Volumen) | Capex vermeiden, Flexibilität nutzen |
| Experiment Tracking | ○ | ● | MLflow (Open Source) | Industriestandard, kein Lock-in |
| Vector Database | ○ | ● | Managed Service oder Self-hosted OSS | pgvector reicht oft aus |
| LLM | ○ | ● | API-Zugang + Open-Source für spezielle Fälle | Mixtral, Llama für sensible Daten |
| RAG-Pipeline | ● | ○ | Custom (geschäftskritisch) | Differenzierung, Domänenwissen |
| Prompt Management | ● | ○ | Custom (IP) | Kernkompetenz, schnelle Iteration |
| Monitoring | ○ | ● | Bestehende Observability-Tools erweitern | Grafana + Langfuse |
| Security Layer | ● | ○ | Custom + OSS (Guardrails) | Unternehmensrichtlinien einhalten |
Faustregel: Bauen Sie das, was Sie differenziert. Kaufen Sie Infrastruktur und Commodity-Tools.
Das richtige Team zusammenstellen
Der Aufbau einer KI-Plattform scheitert selten an der Technologie – sondern am Team. Hier ist eine realistische Teamstruktur für den Start:
Kern-Team (Phase 1: Aufbau, 3–6 Monate)
- 1 Platform Engineer / DevOps: Kubernetes, GPU-Orchestrierung, CI/CD. Verantwortlich für die Infrastruktur-Schicht.
- 1 ML Engineer: Modell-Serving, Pipelines, Experiment Tracking. Brücke zwischen Data Science und Engineering.
- 1 Backend Developer: API-Design, Gateway, Integration in bestehende Systeme. Stellt sicher, dass die Plattform von anderen Teams genutzt werden kann.
Erweitertes Team (Phase 2: Betrieb und Skalierung)
- 1 Data Engineer: Datenpipelines, Feature Store, Datenqualität. Wird relevant, sobald mehrere Use Cases auf die Plattform kommen.
- 0,5 Security Engineer (anteilig): Security Reviews, Penetrationstests, Compliance. Kann auch aus dem bestehenden Security-Team kommen.
- 1 Product Owner / Platform Manager: Priorisierung, Stakeholder-Management, Roadmap. Sorgt dafür, dass die Plattform die richtigen Probleme löst.
Gesamtkosten für das Team: Rechnen Sie mit 400.000–700.000 € pro Jahr (voll beladen) in Deutschland. Das klingt viel, aber verteilt auf 10–20 interne Teams, die die Plattform nutzen, relativieren sich die Kosten schnell.
Migration von SaaS zu Self-Hosted
Viele Unternehmen starten mit SaaS-Lösungen und migrieren später auf eigene Infrastruktur. Dieser Übergang muss sorgfältig geplant werden.
Phase 1: Parallelbetrieb (Monat 1–3)
- Eigene Plattform aufbauen, während SaaS weiterläuft
- Erste Use Cases auf eigener Plattform implementieren (nicht die kritischsten)
- A/B-Vergleich: Qualität, Latenz und Kosten zwischen SaaS und eigener Lösung messen
- Team aufbauen und Erfahrung sammeln
Phase 2: Schrittweise Migration (Monat 3–6)
- Use Cases nach Risiko priorisieren: Low Risk zuerst, Mission Critical zuletzt
- API-Kompatibilitätsschicht bauen, sodass Anwendungen ohne Code-Änderung umziehen können
- SaaS als Fallback beibehalten – bei Problemen kann sofort zurückgeschaltet werden
- Monitoring intensivieren: Jede migrierte Anwendung wird engmaschig überwacht
Phase 3: Konsolidierung (Monat 6–9)
- SaaS-Verträge auslaufen lassen oder auf Minimum reduzieren
- Hybrid-Strategie finalisieren: Was bleibt bei SaaS (z. B. Frontier-Modelle wie GPT-4o), was läuft intern?
- Dokumentation und Onboarding für neue Teams erstellen
- Kosten validieren und TCO-Vergleich aktualisieren
Risikominimierung während der Migration
- Nie mehr als 20% der Use Cases gleichzeitig migrieren
- Feature Parity sicherstellen, bevor ein Use Case umgezogen wird
- Automatisierte Regressionstests für jeden migrierten Use Case
- Rollback-Plan für jede Migration dokumentieren
Operational Maturity Model
Nicht jede Organisation braucht eine voll ausgebaute Plattform. Das folgende Reifegradmodell hilft bei der Einordnung:
Stufe 1: Experimentiell
- Einzelne Data Scientists nutzen Notebooks und lokale GPUs
- Kein standardisierter Deployment-Prozess
- Modelle werden manuell bereitgestellt
- Typisch für: Unternehmen, die erste KI-Projekte starten
Stufe 2: Projektbasiert
- Dedizierte ML-Infrastruktur für einzelne Projekte
- Experiment Tracking ist eingeführt
- Deployment über CI/CD, aber projektspezifisch
- Typisch für: Unternehmen mit 2–5 KI-Projekten in Produktion
Stufe 3: Plattform
- Zentrales Plattform-Team betreibt gemeinsame Infrastruktur
- Self-Service für Data Scientists und Entwickler
- Standardisierte Pipelines und APIs
- Governance und Kostenallokation sind etabliert
- Typisch für: Unternehmen mit 10+ KI-Projekten und mehreren Teams
Stufe 4: Produktisiert
- KI-Plattform ist internes Produkt mit SLAs, Dokumentation und Support
- Automatisiertes Scaling und Multi-Tenancy
- Fortgeschrittenes Monitoring mit Business-KPIs
- Plattform-Team arbeitet wie ein internes Produktteam
- Typisch für: Technologieunternehmen und digitale Vorreiter
Die meisten Unternehmen, die eine eigene Plattform erwägen, befinden sich auf Stufe 2 und wollen zu Stufe 3. Der Sprung von Stufe 2 zu 3 ist der anspruchsvollste, weil er organisatorische Veränderungen erfordert, nicht nur technische.
Erfolgsfaktoren
1. Klarer Scope
Definieren Sie genau, welche Use Cases die Plattform unterstützen soll. Vermeiden Sie die “Plattform für alles”. Starten Sie mit maximal 3 konkreten Use Cases und erweitern Sie von dort. Ein mittelständisches Logistikunternehmen könnte z. B. mit Routenoptimierung, Dokumentenverarbeitung und internem Chatbot starten.
2. Iteratives Vorgehen
Starten Sie mit einem konkreten Use Case und erweitern Sie schrittweise. Kein Big Bang. Der erste Use Case sollte innerhalb von 6–8 Wochen produktiv sein. Das schafft Vertrauen bei Stakeholdern und liefert frühes Feedback für die Plattformarchitektur.
3. Developer Experience
Die Plattform ist nur wertvoll, wenn sie genutzt wird. Investieren Sie in Dokumentation, SDKs und Support. Messen Sie die Time-to-First-Deployment: Wie lange braucht ein neues Team, um seinen ersten Use Case auf der Plattform live zu bringen? Zielwert: unter 2 Wochen.
4. Governance von Anfang an
Etablieren Sie früh Richtlinien für Modellnutzung, Datenhandling und Kostenallokation. Wer darf welche Modelle nutzen? Wer trägt die GPU-Kosten? Wie werden Modelle freigegeben? Diese Fragen werden mit jedem weiteren Team schwieriger zu beantworten, wenn sie nicht früh geklärt sind.
5. Messbarer Mehrwert
Definieren Sie KPIs für die Plattform und tracken Sie diese konsequent:
- Adoption: Anzahl aktiver Teams und Nutzer pro Monat
- Time-to-Value: Durchschnittliche Zeit von der Idee bis zum produktiven Modell
- Kosteneffizienz: Kosten pro 1.000 Inferenzanfragen
- Verfügbarkeit: Uptime der Plattform (Ziel: 99,5%+)
- Nutzerzufriedenheit: Quartalsweise Umfrage bei internen Teams
Typische Fehler
- Overengineering: Zu viele Features zu früh. Sie brauchen keinen Feature Store in Monat 1. Bauen Sie, was heute gebraucht wird, nicht was in 2 Jahren vielleicht gebraucht wird.
- Isolation: Plattform-Team ohne Kontakt zu Business-Nutzern. Mindestens 30% der Zeit sollte in direkter Zusammenarbeit mit Anwenderteams verbracht werden.
- Fehlende Standards: Jedes Team macht seine eigene ML-Pipeline. Das führt zu Silos, Doppelarbeit und inkonsistenter Qualität. Golden Paths definieren und durchsetzen.
- Kostenkontrolle vergessen: GPU-Kosten können explosionsartig steigen. Eine einzige vergessene A100-Instanz kostet über 2.600 € pro Monat. Implementieren Sie Budgetgrenzen, automatisches Shutdown und Cost Dashboards vom ersten Tag an.
- Keine Mandantenfähigkeit: Wenn mehrere Teams die Plattform nutzen, brauchen Sie Isolation zwischen den Workloads. Namespace-basierte Trennung in Kubernetes ist das Minimum.
Fazit
Eine interne KI-Plattform ist eine strategische Investition, die sich bei entsprechendem Nutzungsvolumen deutlich auszahlt. Der Break-even liegt typischerweise bei 5–10 aktiven Use Cases oder 500.000+ monatlichen Inferenzanfragen. Der Schlüssel zum Erfolg liegt in pragmatischem Vorgehen: Open-Source-Komponenten nutzen, wo sinnvoll, Custom-Entwicklung auf die differenzierenden Elemente fokussieren, und das Team schrittweise aufbauen.
Beginnen Sie nicht mit der Plattform, sondern mit dem Problem. Identifizieren Sie die Use Cases, die den größten Business-Wert haben, und lassen Sie die Plattform organisch um diese Anforderungen herum wachsen. Das reduziert das Risiko und stellt sicher, dass Sie bauen, was tatsächlich gebraucht wird.
Planen Sie den Aufbau einer internen KI-Plattform? Kontaktieren Sie uns für Architekturberatung und eine realistische TCO-Analyse.