Implementation Sprint
2–4 Wochen typischer Start
- Von der Idee in Produktion
- Ein Use Case, End-to-End geliefert
Woche 1Woche 7Woche 12
So arbeitet ihr mit uns
Von der Idee in Produktion · gebaut für echte Nutzer
Das Modell ist
das Einfache.
Produktion heißt Daten, Integrationen, Berechtigungen, Monitoring und ein Owner. Wir bauen all das, in euren Systemen.
Ein System durchläuft auf dem Weg in die Produktion sieben Gates: Demo, Daten, Integrationen, Guardrails, Evals, Monitoring, Produktion.
01 · Warum Demos sterben
Die glanzlosen
80 Prozent.
KI-Projekte scheitern selten am Modell. Sie scheitern an allem drumherum.
Warum Demos sterben
Eine Demo läuft mit zwölf handverlesenen Beispielen, einem Laptop und jemandem, der weiß, welche Fragen man stellen muss. Produktion läuft mit Tausenden echten Inputs, in Systemen mit Berechtigungen, an einem Dienstag, an dem die Person, die es gebaut hat, Urlaub hat.
Was Produktion wirklich braucht
Echte Daten, die hereinfließen, auch die hässlichen Fälle. Integrationen in die Systeme, in denen die Arbeit passiert. Guardrails und Fallbacks für den Fall, dass das Modell falsch liegt oder unsicher ist. Evals bei jeder Änderung. Monitoring, auf das jemand schaut, und ein Owner, der angerufen wird, wenn es bricht. Recht und Security von Anfang an dabei, nicht erst zum Launch.
Wie wir arbeiten
Wir starten mit den Rahmenbedingungen: Daten, Systeme, Regeln, Menschen. Dann Architektur und Modellwahl, getestet an euren Daten statt an Benchmarks. Wir bauen in Sprints in eurem Stack, wo möglich mit euren Engineers, und bleiben die ersten Wochen nach dem Launch, bis das System langweilig ist.
Langweilig ist das Ziel.
- Typischer Start
- Implementation Sprint, 2–4 Wochen
- Nach dem Launch
- Launch & Stabilize, 30 Tage
- Ihr behaltet
- Code, Evals, Dashboards, Runbooks
02 · Die Lücke
Demo versus
Produktion.
Auf beiden Seiten dasselbe Modell. Alles andere ist anders, und alles andere ist die Arbeit.
| Aspekt | Produktion | |
|---|---|---|
| Inputs | Zwölf handverlesene Beispiele | Tausende echte Inputs, auch die hässlichen |
| Umgebung | Ein Laptop | Eure Systeme, mit ihren Berechtigungen |
| Betrieb durch | Die Person, die es gebaut hat | Euer Team, an einem Dienstag, während die Person, die es gebaut hat, Urlaub hat |
| Wenn das Modell falsch liegt | Jemand startet es neu | Guardrails, Fallbacks und ein Mensch für folgenreiche Schritte |
| Qualität | Sieht im Meeting gut aus | Evals bei jeder Änderung, mit Gate |
| Wenn es bricht | Merkt niemand | Monitoring, Alerts und ein Owner |
| Recht & Security | Tauchen zum Launch auf | Von Anfang an dabei |
| Kosten | Hat niemand gefragt | Kosten pro Transaktion, sichtbar, mit Alerts |
- DatenEs starb an echten Daten.
In der Demo lief es, dann fiel es bei den Inputs um, die Produktion tatsächlich bekommt.
- ZuständigkeitKeiner ist zuständig.
Kein Owner, kein Monitoring, kein Feedback-Loop, also weiß niemand, dass es kaputt ist.
- RechtKurz vor dem Ziel blockiert.
Recht und Security sehen es zum Launch zum ersten Mal und stoppen es.
- KostenErst kam die Rechnung.
Die Nutzung wurde nie gemessen. Die Kosten explodierten, bevor sich ein Nutzen zeigte.
- IntegrationDas Modell läuft, die Leitungen nicht.
Gute Antworten, schwache Integrationen. Die Arbeit passiert weiter von Hand.
- SicherheitUngesicherte Halluzinationen.
Falsche Antworten erreichen die Nutzer, ohne Guardrail und ohne Fallback.
03 · Ablauf
Fünf Schritte
zu echten Nutzern.
Erst die Rahmenbedingungen, dann der Code. Sicherheit vor dem Launch, nicht nach dem ersten Incident.
- 01Discovery & Rahmenbedingungen
Daten, Systeme, Regeln und Menschen. Was es gibt, wem es gehört, was nicht passieren darf.
- Ergebnis
- Technische Analyse und eine Karte der Rahmenbedingungen
- Wir brauchen
- Zugang zu Systemen und Menschen
- 02Architektur & Modelle
Systemdesign und Modellwahl, getestet an euren Daten statt an Benchmarks.
- Ergebnis
- Systemdesign und Modellempfehlungen
- Wir brauchen
- Ein Architektur-Review
- 03Build & Integration
Sprints in eurem Stack, angebunden an die Systeme, in denen die Arbeit passiert.
- Ergebnis
- Funktionierendes System und Integrationscode
- Wir brauchen
- Testdaten und Feedback
- 04Sicherheit & Kontrollen
Guardrails, Fallbacks und eine Evaluation-Suite, die jede Änderung durch ein Gate schickt.
- Ergebnis
- Guardrails und eine Evaluation-Suite
- Wir brauchen
- Freigabe durch die Security
- 05Launch & Iteration
Go-live mit Monitoring, dann Iteration, bis das System langweilig ist.
- Ergebnis
- Monitoring-Dashboards und ein Iterationsplan
- Wir brauchen
- Einen Owner
04 · Ergebnisse & Formate
Was ihr am
Ende habt.
Drei Dinge, egal welches Format ihr wählt. Das Format entscheidet, wie viel Wissen in eurem Team bleibt.
- Ein System in Produktion.
Aktive Nutzer, echte Transaktionen, messbare Wirkung.
- Klare Zuständigkeit.
Euer Team kann ohne uns debuggen und iterieren.
- Kontrollierte Kosten.
Kosten pro Transaktion, sichtbar, mit Alerting.
Build With Your Team
4–8 Wochen
- Eingebettet bei euren Engineers
- Lernen und Wissenstransfer
Woche 1Woche 7Woche 12
Launch & Stabilize
die ersten 30 Tage nach dem Go-live
- Optimierung und Support
- Bis es langweilig ist
Woche 1Go-liveWoche 12
Voll: das Minimum. Schraffiert: die Spanne, je nach Umfang. Die Streifen sind illustrativ.
05 · Selbstcheck
Wie weit bis
zur Produktion?
Vier Fragen, die entscheiden, wie der erste Sprint aussieht.
Ergebnis0 / 4 beantwortet
- Erst der Scope.
Die Idee braucht ein schärferes Problem und einen Daten-Check vor dem Code. Ein Strategie-Sprint erspart euch einen gescheiterten Build.
- Implementation Sprint.
Zwei bis vier Wochen vom Piloten in die Produktion, für einen Use Case.
- Build With Your Team.
Vier bis acht Wochen eingebettet bei euren Engineers, damit das Wissen bleibt.
01Was gibt es heute?
Wo ihr startet, entscheidet über den ersten Sprint.
02Sind die Daten zugänglich?
Die meisten Verzögerungen liegen am Datenzugang, nicht an der Modellierung.
03Sind Security und Recht eingebunden?
Späte Einbindung ist der häufigste Launch-Blocker.
04Habt ihr Engineers, mit denen wir bauen können?
Gemeinsam bauen hält das Wissen im Haus.
06 · Passt es?
Bauen, wenn.
Warten, wenn.
Umsetzung beginnt mit einem Use Case, der es wert ist, gebaut zu werden. Ohne einen kommt anderes zuerst.
Passt gut
- Ihr habt einen validierten Use Case, der einen ordentlichen Produktions-Build braucht.
- Eurem Produktteam fehlt Erfahrung mit KI in Produktion.
- Eine frühere KI-Demo hat es nie in Produktion geschafft.
- Es muss mit euren bestehenden Systemen funktionieren.
- Security und Compliance sind wichtig.
- Ihr wollt in Wochen liefern.
07 · Fragen
Bevor
wir bauen.
Welche Modelle nutzt ihr?
Was zu euren Rahmenbedingungen passt: gehostete Modelle über EU-Endpunkte, offene Modelle in eurer eigenen Cloud oder eine Mischung. Wir wählen pro Aufgabe, testen gegen euer Eval-Set statt gegen Benchmarks und halten das Modell austauschbar.
Verlassen unsere Daten das Unternehmen?
Nur wo euer Vertrag und eure Richtlinien es erlauben. Standardmäßig planen wir für Verarbeitung in der EU und für Tenant-interne Setups, wo die Daten es verlangen.
Baut ihr mit unseren Engineers?
Wo möglich, ja. Mit Build With Your Team sind wir vier bis acht Wochen Teil eures Teams, damit das Wissen bleibt, wenn wir gehen.
Was passiert nach dem Go-live?
Launch & Stabilize deckt die ersten 30 Tage ab, bis das System langweilig ist. Danach gehört es eurem Team: Code, Evals, Dashboards und Runbooks.
Könnt ihr eine Demo für unsere Investoren bauen?
Nein. Wir bauen Systeme für echte Nutzer. Eine Demo, die beeindrucken soll, ist genau das, was in Produktion stirbt.
Wir haben noch keinen Use Case.
Startet mit einem Workshop oder mit KI-Strategie. Umsetzung beginnt mit einem validierten Use Case.
08 · So arbeitet ihr mit uns
Drei Einstiege.
Wählt danach, wo ihr steht: vor einer Entscheidung, festgefahren mit einem Live-System oder bereit zum Bauen.
01 / 03Workshop02 / 03Beratung
Halber oder ganzer Tag. Endet mit Entscheidungen, Verantwortlichen und nächsten Schritten.
Wenn ihr entscheiden müsst
Retainer, Fix-it-Sprints, Hilfe direkt im Team. Für Systeme, die live sind und wehtun.
Wenn ein Live-System wehtut
03 / 03ihr seid hierUmsetzung
Builds von zwei bis acht Wochen. Von der validierten Idee zu echten Nutzern.
Wenn ihr bereit zum Bauen seid
Was hängt zwischen Demo und Produktion fest?
Macht es
langweilig.
Erzählt uns, was es heute gibt: eine Idee, eine Demo, einen Piloten mit echten Nutzern. Wir melden uns mit dem ersten Sprint.