Vom Workshop zum Prototyp: wie ein KI-Sprint in zwei Wochen abläuft
Wer einen KI-Prototyp entwickeln will, verliert die meiste Zeit nicht am Bauen, sondern davor: am Zuschnitt des Use-Cases und am Datenzugang. Ein KI-Sprint macht daraus einen festen Zweiwochen-Ablauf mit fünf Phasen und einem klaren Ergebnis. Das Bauen selbst ist heute schnell, sobald der Fall eng genug geschnitten und die Daten erreichbar sind. Der wichtigste Hebel ist der Use-Case-Schnitt: ein enger, echter Fall schlägt jede breite Ideensammlung. Ein Prototyp beweist Machbarkeit an echten Daten, er ist noch kein Betrieb. Der Sprint endet deshalb mit einer Entscheidung, nicht mit einer Demo, die niemand mehr anfasst.
Was ein KI-Sprint ist, und was nicht
Ein KI-Sprint ist ein fester, kurzer Bauabschnitt, der einen einzigen Fall von der Idee zu einem lauffähigen Prototyp bringt. Zwei Wochen, ein Team, ein Ergebnis, das man am Ende bedienen kann. Er ist kein Beratungsprojekt mit Folienstapel und kein offener Innovationsworkshop, aus dem zwanzig Ideen und kein Code herauskommen.
Der Unterschied liegt im Zuschnitt. Ein Sprint funktioniert nur, wenn der Fall eng genug ist, dass man ihn in zwei Wochen wirklich bauen kann. Nicht das gesamte Rechnungswesen, sondern das Auslesen einer Rechnungsart. Nicht den kompletten Support, sondern die häufigste eingehende Frage. Je enger der Schnitt, desto ehrlicher das Ergebnis.
Die meiste Zeit im KI-Sprint geht nicht ins Bauen. Sie geht in die Frage, welchen Fall wir überhaupt bauen und ob wir an die Daten kommen.
Das Bauen selbst ist heute der schnelle Teil. Was ein Sprint langsam oder wertlos macht, sind die Fragen davor: Ist der Fall klar abgegrenzt, kommen wir an die Daten, gibt es eine Person, die das Ergebnis am Ende verantwortet. Wer diese drei Punkte vor dem Sprint klärt, hat den halben Erfolg schon in der Tasche.
Der Ablauf in zwei Wochen
Der Sprint hat fünf Phasen. Sie überlappen an den Rändern, aber die Reihenfolge steht fest, weil jede Phase auf dem Ergebnis der vorigen aufbaut.
Discovery und Use-Case-Schnitt. Wir setzen uns hin und schneiden den Fall so eng, dass er in zwei Wochen baubar ist. Das heißt: der heutige Ablauf wird gemessen, eine Ausgangslinie dokumentiert und ein Erfolgskriterium festgelegt. Ohne diese Baseline lässt sich am Ende nicht sagen, ob der Prototyp etwas taugt.
Datenzugang klären. Hier entscheidet sich oft, ob der Sprint überhaupt fliegt. Welche Daten brauchen wir, dürfen wir sie nutzen, kommen wir technisch dran, und sind sie aktuell genug. Diese Phase ist unspektakulär und wird trotzdem am häufigsten unterschätzt.
Bauen. Jetzt entsteht der Prototyp am echten Fall. Kein Wegwerf-Mockup mit Fantasiedaten, sondern ein Ding, das die abgegrenzte Aufgabe an realen Beispielen erledigt. Diese Phase ist kürzer, als die meisten erwarten.
Testen mit echten Fällen. Wir werfen bewusst die schwierigen, seltenen und unangenehmen Fälle gegen den Prototyp, solange das noch billig ist. Was hier scheitert, kostet fast nichts. Was erst im Betrieb scheitert, kostet richtig.
Übergabe. Am Ende steht nicht nur der lauffähige Prototyp, sondern eine Entscheidung: Trägt der Fall einen Betrieb, was wäre dafür nötig, und was ist der nächste sinnvolle Ausbau. Diese Phase ist kurz, aber sie entscheidet, ob aus dem Prototyp etwas wird oder ob er in einem Ordner verschwindet.
Prototyp ist nicht Produktion
Ein Prototyp beweist Machbarkeit an echten Daten. Er zeigt, dass der Fall grundsätzlich funktioniert und ob sich der weitere Weg lohnt. Was er nicht ist: ein System, auf das sich am Montagmorgen die halbe Abteilung verlässt. Zwischen beiden liegen Rechte, Monitoring, Fehlerbehandlung und eine benannte Verantwortung.
Der Fehler entsteht, wenn ein gelungener Prototyp mit einem fertigen Produkt verwechselt wird. Ein Prototyp darf im Ausnahmefall scheitern, solange ein Mensch danebensteht. Ein Betrieb darf das nicht. Deshalb ist die ehrliche Frage am Ende des Sprints nicht "läuft es", sondern "was fehlt noch bis zum Betrieb, und lohnt sich dieser Weg".
| Aspekt | KI-Prototyp | KI-Betrieb |
|---|---|---|
| Ziel | Machbarkeit an echten Daten zeigen | verlässlich im Alltag arbeiten |
| Umgang mit Fehlern | Mensch fängt Ausnahmen ab | Fehlerpfad und Monitoring definiert |
| Datenzugang | eng, für den Test freigegeben | dauerhaft, geprüft, rechtlich belastbar |
| Verantwortung | Sprint-Team | benannte fachliche Ownership |
Was du in den KI-Sprint mitbringst
Ein Sprint ist kein Auftrag, den man abgibt und zwei Wochen später abholt. Er lebt von dem, was aus dem Unternehmen kommt. Diese fünf Dinge entscheiden, ob er trägt.
- Ein enger, echter Fall, kein Themenfeld. Je konkreter die Aufgabe, desto belastbarer das Ergebnis.
- Zugang zu echten Daten, geklärt und freigegeben, nicht erst am dritten Tag beantragt.
- Eine fachliche Person, die den Fall kennt und für zwei Wochen ansprechbar ist.
- Ein Erfolgskriterium, an dem sich der Prototyp messen lässt, festgelegt vor dem Bau.
- Die schwierigen Fälle, die typischen Ausnahmen und Sonderwege, gesammelt für den Test.
Kernsatz: Ein KI-Sprint ist zu einem kleinen Teil unser Bauen und zu einem großen Teil eure Klärung. Was ihr vorher klärt, wird im Sprint zu Code. Was ihr offen lasst, wird im Sprint zur Verzögerung.
Häufige Irrtümer
- Zwei Wochen sind zu kurz für etwas Echtes.
- Für ein fertiges Produkt ja, für einen lauffähigen Prototyp an echten Daten nein. Der Zeitrahmen zwingt zum engen Schnitt, und der enge Schnitt ist der eigentliche Wert.
- Der Prototyp geht danach direkt in den Betrieb.
- Selten. Zwischen Prototyp und Betrieb liegen Rechte, Monitoring, Fehlerbehandlung und eine benannte Verantwortung. Der Sprint beweist, ob sich dieser Weg lohnt, er ersetzt ihn nicht.
Fragen und Antworten
- Warum dauert ein KI-Sprint gerade zwei Wochen?
- Der Rahmen ist kurz genug, um zum engen Schnitt zu zwingen, und lang genug, um einen echten Fall an echten Daten zu bauen und zu testen. Wird es länger, wächst der Umfang, und der Umfang ist der Feind eines belastbaren Ergebnisses.
- Was passiert, wenn wir im Sprint nicht an die Daten kommen?
- Dann ist genau das das Ergebnis, und es ist ein wertvolles. Fehlender Datenzugang ist eine der häufigsten Ursachen, warum spätere Projekte scheitern. Ihn früh und billig zu finden, ist besser, als ihn nach Monaten teuer zu entdecken.
- Bekommen wir am Ende Code oder eine Empfehlung?
- Beides. Einen lauffähigen Prototyp am echten Fall und eine ehrliche Aussage, ob der Fall einen Betrieb trägt und was der nächste Schritt wäre. Ohne die Empfehlung ist der Prototyp nur eine Demo.
Sources and evidence
Es werden keine externen Marktwerte oder ungeprüften Kundenergebnisse behauptet. Rechts- und Datenfragen werden vor dem Bau mit dem realen Stack geprüft.