Euer Erfolg beginnt nach dem Go-Live.
Für die meisten Plattformprojekte ist der Erfolg gleichbedeutend mit dem Go-Live. Bei uns fängt ab da die richtige Arbeit an.
Wir managen, ihr steuert
Managed Data & AI Services
Ein System, das live ist, braucht täglich Wartung, Überwachung, Sicherung und Weiterentwicklung. Cluster müssen skaliert, Security-Patches implementiert, Zugriffe auditiert und Kosten überwacht werden. Zur selben Zeit ist es notwendig, ML-Modelle zu überwachen, neu zu trainieren und zu versionieren: Aufgrund von Veränderungen der Daten, Weiterentwicklungen der Geschäftslogik und der Tatsache, dass Model Drift reale Business-Entscheidungen verfälschen kann.
Wir managen den Betrieb eurer Datenplattform und eurer AI-Workloads; transparent und automatisiert, basierend auf Infrastructure-as-Code. Keine Abhängigkeit von uns, kein Kontrollverlust und kein Vendor-Lock-in auf unsere Expertise. Im Co-Pilot-Modus arbeiten wir so, dass euer Team die Kontrolle über die Plattform behält und uns nur dann einsetzt, wenn ihr es wollt.
"Das Ziel ist nicht der Go-Live. Der Go-Live ist der Moment, an dem der Betrieb beginnt und der ROI eurer Plattform-Investition somit wirklich realisiert wird."
Alexander Rabe
Co-Founder & Head of Data & AI
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
Heading
This is some text inside of a div block.
This is some text inside of a div block.
AI Observability
Das unterschätzte Risiko nach dem Go-Live (Day 2)
Die gefährlichste Phase einer Datenplattform ist nicht der Aufbau, sondern es sind die Monate danach. Die Plattform ist betriebsbereit, das Projektteam löst sich auf und der externe Dienstleister zieht ab. Übrig bleibt ein System, das keiner im Team wirklich versteht. Obwohl Runbooks vorhanden sind, hat sie noch niemand getestet. Die Überwachung ist eingerichtet, aber die Alerts landen in einem Slack-Channel, den niemand beachtet. Die Cluster-Konfiguration läuft nach dem Go-Live weiterhin unverändert, obwohl sich die Workloads längst geändert haben.
Das Resultat: Eine schleichende Erhöhung der Cloud-Kosten, weil niemand die Compute-Nutzung optimiert. Sicherheitslücken entstehen, wenn Patches nicht implementiert werden. ML-Modelle, die unbemerkt falsche Vorhersagen produzieren, weil niemand die Data Drift überwacht.
Der Begriff "laufender Betrieb" wird häufig mit "Wartungsvertrag" verwechselt. Das ist hier nicht der Fall. Es ist wichtig, dass die Plattform konstant Wert liefert, und das geschieht nicht von alleine. Das erfordert Automatisierung, eine echte Observability und klare Verantwortlichkeiten. All das sollte man im Voraus klären, nicht wenn die Situation bereits eskaliert ist.
Proaktives Engineering
Operations ist kein Ticket-System, sondern Engineering
Die gefährlichste Phase einer Datenplattform ist nicht der Aufbau, sondern es sind die Monate danach. Die Plattform ist betriebsbereit, das Projektteam löst sich auf und der externe Dienstleister zieht ab. Übrig bleibt ein System, das keiner im Team wirklich versteht. Obwohl Runbooks vorhanden sind, hat sie noch niemand getestet. Die Überwachung ist eingerichtet, aber die Alerts landen in einem Slack-Channel, den niemand beachtet. Die Cluster-Konfiguration läuft nach dem Go-Live weiterhin unverändert, obwohl sich die Workloads längst geändert haben.
Das Resultat: Eine schleichende Erhöhung der Cloud-Kosten, weil niemand die Compute-Nutzung optimiert. Sicherheitslücken entstehen, wenn Patches nicht implementiert werden. ML-Modelle, die unbemerkt falsche Vorhersagen produzieren, weil niemand die Data Drift überwacht.
Der Begriff "laufender Betrieb" wird häufig mit "Wartungsvertrag" verwechselt. Das ist hier nicht der Fall. Es ist wichtig, dass die Plattform konstant Wert liefert, und das geschieht nicht von alleine. Das erfordert Automatisierung, eine echte Observability und klare Verantwortlichkeiten. All das sollte man im Voraus klären, nicht wenn die Situation bereits eskaliert ist.
- Infrastructure-as-Code: Terraform, Pulumi oder plattform-native Tools für vollständige Automatisierung. Keine manuellen Klicks in der Console, sondern reproduzierbare, auditierbare Deployments. Drift Detection stellt sicher, dass Realität und Code übereinstimmen.
- Monitoring & Observability: Zentrales Monitoring für Compute, Storage, Pipelines und Data Quality. Dashboards und Alerting, die zwischen Rauschen und echten Problemen unterscheiden.
- Incident Management & Runbooks: Definierte Eskalationspfade, automatisierte Runbooks für bekannte Failure Patterns und Post-Incident-Reviews. Nicht nur dokumentieren, was passiert ist, sondern was sich ändern muss.
- Security Operations: Kontinuierliches Patching, Zugriffsaudits, Vulnerability Scanning und Compliance-Monitoring. Security ist keine einmalige Konfiguration, sondern ein laufender Prozess.
- Platform Upgrades & Evolution: Upgrades planen und durchführen, ohne den laufenden Betrieb zu gefährden: Runtime-Versionen, Feature-Rollouts, Architekturveränderungen; mit Rollback-Strategien und Blue-Green-Deployments.
.avif)
Drift erkennen, bevor Schaden entsteht
Ein Modell deployen ist Engineering, es am Laufen halten ist Operations
Ein ML-Modell in Produktion zu bringen ist Engineering. Ein ML-Modell in Produktion zu halten ist Operations. Genau an dieser Stelle scheitern die meisten AI-Initiativen: Das Modell wird einmal deployed, liefert anfangs gute Ergebnisse, und dann passiert nichts mehr. Kein Monitoring, ob sich die Eingabedaten verändert haben. Keine automatisierte Pipeline für Retraining. Keine Versionierung, die nachvollziehbar macht, welches Modell gerade in Produktion läuft und warum.
Wir behandeln ML-Modelle wie Software: mit CI/CD, automatisierter Versionierung, Monitoring und definierten Lifecycle-Prozessen. Dasselbe gilt für Large Language Models, bei denen sich zusätzliche Herausforderungen stellen: Prompt Management, Token-Kosten-Optimierung, Guardrails gegen Halluzinationen und die Integration in bestehende Geschäftsprozesse.
Und für AI Agents, die eigene Komplexität mitbringen: Orchestrierung über mehrere Tools, Absicherung autonomer Entscheidungen, Monitoring von Kosten und Laufzeit pro Ausführung; und die Frage, was passiert, wenn ein Agent in einer Schleife hängt oder eine falsche Aktion triggert.
.avif)
- Model Deployment & Serving: Automatisierte Deployment-Pipelines: Staging, A/B-Testing, Production Rollout. Model Serving über REST-APIs, Batch Inference oder Streaming, je nach Latenzanforderung.
- Model Monitoring & Drift Detection: Kontinuierliches Monitoring von Model Performance, Data Drift und Concept Drift. Automatisierte Alerts, wenn die Modellqualität unter definierte Schwellenwerte fällt, bevor falsche Vorhersagen Business-Entscheidungen beeinflussen.
- Retraining & Lifecycle Management: Automatisierte Retraining-Pipelines, die bei Drift oder nach definierten Intervallen triggern. Modell-Registry mit Versionierung, Approval Workflows und Audit Trail. Definierte Prozesse für Model Retirement und Disposal.
- LLMOps & Agentic AI Ops: Prompt Management, Evaluation Pipelines und Guardrails für LLMs und AI-Agents in Produktion. Token-Kosten-Monitoring, Latenz-Optimierung und Safety-Checks, die Halluzinationen und Policy-Verstöße verhindern.
- CI/CD für ML: DevOps-Prinzipien für Machine Learning: automatisierte Tests für Datenqualität, Feature-Konsistenz und Modellperformance. Pull-Request-basierte Model Reviews und Validation Gates vor jedem Production Deployment.
.avif)
Security & Policy as Code
Governance und FinOps sind dasselbe Problem
Governance und Kostenkontrolle werden in vielen Organisationen als separate Themen behandelt; Governance beim CISO, FinOps beim CFO. In der Praxis hängen beide direkt zusammen: Ein Cluster, der ohne Tagging läuft, ist gleichzeitig ein Governance-Problem (keine Zuordnung) und ein FinOps-Problem (keine Kostentransparenz).
Ein Modell, das ohne Approval deployed wird, ist ein Compliance-Risiko und ein Kostenrisiko.Wir implementieren Guardrails, die beide Dimensionen abdecken; automatisiert, als Code, in die Plattform eingebaut. Keine manuellen Reviews, die den Delivery-Prozess bremsen, sondern Leitplanken, die verhindern, dass Teams versehentlich teure oder non-compliant Ressourcen starten.
- Policy-as-Code: Cluster-Policies, Workspace-Konfigurationen und Zugriffsregeln als versionierter Code. Automatisierte Enforcement-Mechanismen, die verhindern, dass Teams an den Guardrails vorbei arbeiten.
- Cost Management & Optimization: Automatisiertes Tagging, Budgetalerts und Usage-Reports pro Team, Projekt und Workload. Optimierungspotenzial identifizieren: überdimensionierte Cluster, fehlende Auto-Termination, ungenutzte Ressourcen. Typische Einsparung: 30-50%.
- AI Governance & Model Inventory: Zentrales Register aller ML-Modelle in Produktion: Wer hat gebaut? Mit welchen Daten trainiert? Wer hat das Deployment genehmigt? Welche Risikokategorie nach EU AI Act? Jedes Modell nachvollziehbar, auditierbar und compliant.
- Chargeback & Showback: Transparente Kostenverteilung auf Business Units, Teams und Projekte. Nicht die IT-Abteilung trägt die Cloud-Rechnung, sondern die Teams, die die Ressourcen verbrauchen, mit den richtigen Incentives für kosteneffizientes Arbeiten.
- Compliance Automation: Automatisierte Checks gegen regulatorische Anforderungen: DSGVO, EU AI Act, DORA, NIS2. Continuous Compliance statt jährlicher Audits, mit dokumentierten Evidence Trails.
.avif)
Enablement & Operations
Co-Pilot-Modus statt Abhängigkeit
Wir arbeiten im Co-Pilot-Modus: Wir übernehmen den Betrieb, solange euer Team noch nicht bereit ist und übergeben schrittweise.
Das bedeutet konkret: Jede Automatisierung, die wir bauen, ist dokumentiert und nachvollziehbar. Jeder Incident wird nicht nur gelöst, sondern als Lern-Opportunity genutzt. Jedes Runbook wird gemeinsam reviewed. Und jeder Prozess ist so gestaltet, dass euer Team ihn übernehmen kann, sobald die Kompetenz aufgebaut ist.
- Knowledge Transfer & Dokumentation: Kontinuierlicher Wissenstransfer im Tagesgeschäft statt Übergabe-Meetings mit 200-Seiten-PDFs. Living Documentation, die sich mit der Plattform weiterentwickelt.
- Pair Operations: Euer Team arbeitet mit unseren Engineers an realen Incidents und Changes. Learning-by-Doing, schrittweise Übernahme von Verantwortlichkeiten mit definierten Checkpoints.
- Maturity Assessment & Transition Plan: Operations-Reife regelmäßig messen und gemeinsam definieren, wann welche Verantwortlichkeiten übergeben werden. Kein abrupter Handover, sondern ein geplanter Übergang mit klaren Kriterien.
- On-Call & Eskalation: Auch nach der Übergabe als Eskalationsstufe verfügbar. Euer Team betreibt die Plattform, wir springen ein, wenn es komplex wird. Partnerschaft auf Augenhöhe, nicht Dauer-Support.
.avif){kind=spacer}
Jetzt Betrieb stabilisieren
Eure Plattform läuft; aber wer sorgt dafür, dass sie morgen noch den Wert liefert, für den sie gebaut wurde?
Ob ihr den Betrieb stabilisieren, ML-Modelle professionell managen oder euer Team für eigenständige Operations befähigen wollt: Lasst uns gemeinsam klären, wo das größte Potenzial liegt.
