DECISION TOOLKIT · DELIVERY-GATES
Jede Transition muss die nächste verdienen
Die neun Phasen sind keine Checkliste. Sie sind Nachweispflichten: Jede Transition reduziert eine andere Unsicherheit und schützt die nächste Investition.
Keine Evidenz, keine Transition. Ein früheres Gate erneut zu öffnen ist Lernen, kein Scheitern.
Die meisten Post-mortems gescheiterter KI-Projekte beschuldigen den falschen Verdächtigen. Der Abschlussbericht verurteilt das Modell: nicht präzis genug, nicht zuverlässig genug, «nicht bereit für unser Geschäft». In unseren Mandaten beobachten wir fast immer etwas anderes. Das Modell funktionierte. Was fehlte, war eine ganze Projektphase: Niemand hatte den Workflow vermessen, bevor er verändert wurde. Niemand hatte definiert, was einen Abbruch rechtfertigen würde. Niemand hatte eine Evaluationsumgebung gebaut, bevor echte Nutzer:innen das System erreichten.
Wenn ein KI-Projekt scheitert, suchen Sie zuerst die übersprungene Phase — und erst danach das fehlerhafte Modell. Sie finden fast immer zuerst die Phase.
Das Problem ist kein genereller Mangel an Methode — Organisationen wissen, wie man Projekte liefert. KI verschiebt das Risiko jedoch an ungewohnte Stellen: Qualität ist probabilistisch, Beweise brauchen eine Baseline, Berechtigungen werden zur Architekturfrage, und Wert überlebt nicht ohne Governance. Daraus entstand dieses Framework aus unserer Mandatspraxis: die vollständige Anatomie eines Enterprise-KI-Projekts in neun Phasen.
Das Framework im Überblick
Ein KI-Projekt durchläuft von Anfang bis Ende neun Phasen. Drei betreffen das Entscheiden: Absicht, Diagnose, Portfolio. Drei betreffen das Bauen: Architektur, Fundamente, Pilot. Drei betreffen den Wert: Evidenz, Industrialisierung, kontinuierlicher Wert. Jede Phase erzeugt identifizierbare Liefergegenstände, birgt eine wiederkehrende Falle und endet mit einem überprüfbaren Exit-Kriterium. Solange dieses Kriterium nicht erfüllt ist, beseitigt der Übergang zur nächsten Phase die Arbeit nicht — er verschiebt sie nach hinten, dorthin, wo sie mehr kostet.
Die Sequenz verbietet Iteration nicht: Ein Pilot kann zurück in die Architektur führen, Evidenz kann das Portfolio neu öffnen. Die Entscheide selbst sind jedoch geordnet: Man wählt kein technisches Pattern vor dem Problem, und man skaliert kein System, bevor man seine Fehler gezählt hat.
Das Framework gilt für einen Dokumentenassistenten ebenso wie für einen Agenten mit Zugriff auf produktive Systeme; nur das relative Gewicht der Phasen ändert sich. Ein risikoarmer Fall durchläuft die neun Phasen in wenigen Wochen mit schlanken Liefergegenständen; ein Fall, der Kundenentscheide beeinflusst, verbringt mehr Zeit in Architektur, Fundamenten und Pilot. Eine Phase zu überspringen spart nie Zeit: Es verschiebt Schulden in die Produktion.
Phase 1 — Der Absichtsentscheid
Jedes Projekt beginnt mit einer Absicht; wenige beginnen mit einem Entscheid. Phase 1 macht aus «wir brauchen KI» eine explizite Wahl: welches Problem, getragen von welchem Sponsor, mit welchem Abbruchkriterium. Der letzte Punkt ist der wichtigste Liefergegenstand — und der am seltensten produzierte. Vor der Investition zu entscheiden, was einen Abbruch rechtfertigen würde, kostet eine Stunde Klarheit; es nachträglich zu entscheiden, kostet eine politische Verhandlung.
Liefergegenstände. Eine einseitige Absichtsnotiz: das Problem als zu veränderndes Workflow-Ergebnis formuliert, ein benannter Sponsor mit tatsächlich reservierter Zeit, das Budget der Beweisphase und das schriftliche Abbruchkriterium.
Die klassische Falle. Das Spiegelprojekt: gestartet, weil die Konkurrenz etwas angekündigt hat, ohne eigenes Problem. Der Sponsor ist ein Name auf einer Folie, keine Person, die im Ernstfall entscheidet.
Exit-Kriterium. Sie können in die nächste Phase wechseln, wenn der Sponsor ohne Notizen das zu verändernde Ergebnis und die Abbruchbedingungen nennen kann — und beides in einem von ihm unterzeichneten Dokument steht.
Phase 2 — Diagnose und Baseline
Einen Workflow, den man nicht vermessen hat, kann man nicht verbessern — nur verändern. Phase 2 dokumentiert den realen Workflow, nicht den offiziellen Prozess: wer was tut, wo Zeit verloren geht, wo sich Nacharbeit konzentriert, welche Daten unter welchen rechtlichen Auflagen fliessen. Hier wird auch die Baseline eingefroren, die jeden späteren Beweis erst möglich macht.
Liefergegenstände. Eine Karte des tatsächlich gelebten Workflows; bezifferte Baselines — Durchlaufzeit, Nacharbeitsquote, Ausnahmequote, Stückkosten, Qualitätsschwankung; ein Inventar der betroffenen Daten und Systeme mit ihren Verantwortlichen.
Die klassische Falle. Nachträglich messen. Ohne Baseline muss das Team den Wert des Piloten gegen Erinnerungen beweisen — und Erinnerungen verlieren immer gegen einen skeptischen CFO. Häufige Variante: den theoretischen Prozess aus dem Qualitätshandbuch dokumentieren, dem niemand folgt.
Exit-Kriterium. Sie können weitergehen, wenn Sie mit Zahlen wissen, was der Workflow heute kostet — und die Person, die ihn betreibt, diese Zahlen als ihre eigenen anerkennt.
Phase 3 — Portfolio und erster Fall
Auch wenn das Mandat nur einen Use Case umfasst, muss er gegen Alternativen gewählt werden. Phase 3 baut ein Portfolio von Kandidaten und bewertet sie auf zwei Achsen: Potenzial — wirtschaftliche Relevanz, Nutzerwirkung, strategische Bedeutung — und Umsetzbarkeit — Datenzugang, Integrationsaufwand, Kontrollbedarf, Evaluierbarkeit. Der erste Fall ist nicht der mit dem grössten Versprechen, sondern der, der relevanten Wert mit dem kürzesten Weg zu vertrauenswürdiger Evidenz verbindet.
Liefergegenstände. Ein Portfolio, bewertet nach Potenzial × Umsetzbarkeit; ein gewählter, dokumentierter erster Fall; die Liste der zurückgestellten Fälle mit Begründung — sie verhindert, dass dieselbe Debatte jedes Quartal neu geführt wird.
Die klassische Falle. Den spektakulärsten Fall wählen: oft kundennah, oft risikoreich, fast immer am langsamsten zu beweisen. Ein sichtbarer erster Fehlschlag kostet mehr Glaubwürdigkeit, als drei stille Erfolge einbringen.
Exit-Kriterium. Sie können weitergehen, wenn Sponsor, Workflow-Verantwortliche und Technikteam denselben ersten Fall vertreten — aus denselben Gründen.
Phase 4 — Architektur und Grenzen
Vor dem Bauen werden die Grenzen gezogen: welche Daten hineinfliessen, welche Berechtigungen gelten, welches technische Pattern den Fall trägt und was reversibel bleibt. Bei der Pattern-Wahl deckt sich unsere Regel mit den von Anthropic publizierten Engineering-Leitlinien zum Bau von Agenten: mit dem einfachsten ausreichenden Pattern beginnen — ein Aufruf mit Werkzeugen, eine Prompt-Kette, ein Router — und erst dann Richtung Agentik gehen, wenn der Fall es nachweislich verlangt. Bei der Integration reduzieren offene Standards wie das Model Context Protocol die Anbieterbindung und bereiten die Reversibilität vor.
Liefergegenstände. Ein Datenflussdiagramm mit Verantwortlichen; ein Berechtigungsmodell, in dem das System die Rechte der Nutzer:innen erbt — nie mehr; eine schriftlich begründete Pattern-Wahl; eine Reversibilitätsanalyse: was ein Modell- oder Anbieterwechsel kosten würde.
Die klassische Falle. Überarchitektur: einen autonomen Agenten bauen, wo eine Prompt-Kette genügt hätte, und danach Monate mit dem Debugging einer Autonomie verbringen, die niemand brauchte. Die umgekehrte Falle existiert auch: Berechtigungen ignorieren und im Pilot entdecken, dass der Assistent Dokumente zeigt, die Nutzer:innen nie hätten sehen dürfen.
Exit-Kriterium. Sie können weitergehen, wenn jede Dateneinheit, die ins System hinein- und hinausfliesst, einen dokumentierten Pfad, eine verantwortliche Person und eine überprüfbare Berechtigungsgrenze hat.
Phase 5 — Die Fundamente
Phase 5 baut, was in keiner Demo sichtbar ist: sauber provisionierte Identitäten und Zugänge, verlässliche Datenkonnektoren, operative Kontrollen und vor allem die Evaluationsumgebung. Sie unterscheidet ein steuerbares Projekt von einem Blindflug: ein Set realer, repräsentativer, bewusst unbequemer Fälle, das nach jeder Änderung neu abgespielt werden kann. Das NIST AI Risk Management Framework sagt dasselbe in seinem eigenen Vokabular: Steuern lässt sich nur, was kartiert und gemessen wird.
Liefergegenstände. Service-Konten mit minimalem Umfang; operative, protokollierte Datenzugänge; ein Evaluationsset aus realen Fällen inklusive Grenzfällen; die Basiskontrollen — Protokollierung, Alarmschwellen, Incident-Prozedur.
Die klassische Falle. Die Evaluationsumgebung überspringen, um «schneller zum Pilot» zu kommen. Das Team justiert Prompts danach nach Gefühl, kann Verbesserung nicht von Regression unterscheiden, und der Pilot wird zu einer Abfolge widersprüchlicher Eindrücke.
Exit-Kriterium. Sie können weitergehen, wenn Sie Ihr Evaluationsset abspielen und einen reproduzierbaren Score erhalten — bevor eine einzige echte Nutzerin das System berührt hat.
Phase 6 — Der überwachte Pilotbetrieb
Der Pilot testet nicht die Technologie: Er testet den veränderten Workflow, seine Kontrollen und seine Menschen. Phase 6 exponiert das System einem eng begrenzten, benannten Kreis — mit systematischer menschlicher Validierung am Anfang, später stichprobenweise, sobald Vertrauen auf Fakten gebaut ist. Jeder Fehler wird typisiert: Schweregrad, Ursache, Erkennbarkeit. Diese Fehlerbuchhaltung — nicht der Enthusiasmus der ersten Nutzer:innen — speist den Entscheid der Phase 7. Überwachung ist kein Misstrauen gegenüber dem System: Sie ist das Instrument, um sie mit Evidenz schrittweise abzubauen.
Liefergegenstände. Ein schriftlicher Perimeter: benannte Nutzer:innen, abgedeckte Fälle, explizit ausgeschlossene Fälle; ein menschlicher Validierungskreislauf mit Stichprobenregeln; ein Register typisierter Fehler; Qualitätsschwellen, die vor dem Start fixiert wurden — nicht danach.
Die klassische Falle. Der Demo-Pilot: drei begeisterte Nutzer, kein Fehlerregister und ein Skalierungsentscheid auf Basis von Anekdoten. Fehler, die im Pilot nicht gezählt werden, werden später als Incidents gezählt.
Exit-Kriterium. Sie können weitergehen, wenn Sie eine nach Falltyp gemessene Fehlerrate haben, verglichen mit der menschlichen Baseline aus Phase 2 — nicht ein allgemeines Gefühl.
Phase 7 — Evidenz und Skalierungsentscheid
Phase 7 ist ein Entscheidungsraum, keine Feier. Drei Ausgänge sind legitim: Scale — die Schwellen sind erreicht, es wird ausgeweitet; Adapt — der Wert existiert, aber anderswo oder anders, es wird rekonfiguriert; Stop — die Evidenz fehlt, es wird gestoppt und das Gelernte gesichert. Ein evidenzbasierter Stopp ist ein Governance-Erfolg; Skalierung aus Trägheit ist ein aufgeschobener Fehlschlag. Grössenordnungen bleiben Bandbreiten — etwa 30 bis 50 Prozent kürzere Bearbeitungszeit bei Standardfällen — und erst Ihre Baseline aus Phase 2 macht aus einer Bandbreite einen Fakt.
Liefergegenstände. Ein Evidenzdossier: Delta gegenüber der Baseline, vollständige Kosten — Aufbau, Betrieb, Überwachung —, Incidents und ihre Behebung, tatsächliche Adoption; ein schriftlicher Entscheid — Scale, Adapt oder Stop — vom Sponsor unterzeichnet.
Die klassische Falle. Skalierung aus Trägheit: «Der Pilot lief gut», also wird ausgeweitet — ohne Vergleich mit den Schwellen, oft weil in Phase 6 keine fixiert wurden. Stop war nie eine echte Option, nur eine Zeile auf einer Folie.
Exit-Kriterium. Sie können weitergehen, wenn der Entscheid auf Zahlen beruht, unterzeichnet ist und Stop tatsächlich zur Wahl stand.
Phase 8 — Industrialisierung
Der Produktionsstart ist nicht das Ende des Projekts, sondern der Anfang des Betriebs. Phase 8 macht aus einem funktionierenden Piloten einen tragfähigen Service: Observability — Traces, Kosten pro Anfrage, Qualitätsdrift —, ein klares Betriebsmodell — wer reagiert bei Störungen, mit welchen Zusagen —, Kostensteuerung und die Schulung der Teams im neuen Workflow, nicht nur im Werkzeug. Hier entscheidet sich auch die wirtschaftliche Tragfähigkeit: Kosten pro Anfrage, die im Pilot akzeptabel waren, können in der Skalierung unhaltbar werden, wenn niemand sie beobachtet.
Liefergegenstände. Observability-Dashboards in der Produktion; ein Betriebs-Runbook mit benanntem Owner; Budgets und Kostenalarme; ein im Workflow verankerter Schulungsplan; das Sicherheitsreview vor dem Produktionsstart.
Die klassische Falle. Die Phantomübergabe: Das Projektteam wendet sich dem nächsten Thema zu, niemand hat Pikettdienst, die Kosten driften still, die Qualität erodiert unbeobachtet. Das System stirbt in der Produktion — langsam und ohne Totenschein.
Exit-Kriterium. Sie können weitergehen, wenn das System einen benannten operativen Owner, ein verfolgtes Budget und eine kontinuierlich gemessene Qualität hat — nicht nur an Incident-Tagen.
Phase 9 — Wert im Dauerbetrieb
Die letzte Phase hat kein Ende: Sie ist der Dauerzustand. Die Baselines werden wieder lebendig — in regelmässigen Abständen neu gemessen, weil sich Workflow, Volumen und Modelle verändern. Eine kurze monatliche Governance-Runde prüft Wert, Kosten, Risiken und Abwägungen. Und nachgewiesene Gewinne finanzieren die nächsten Fälle des Portfolios: Reinvestition, nicht Enthusiasmus, macht aus einem ersten Projekt ein Programm.
Liefergegenstände. Neu gemessene, datierte Baselines; ein monatliches Review mit fester Agenda — Wert, Kosten, Incidents, Risiken, Entscheide; eine Reinvestitionslogik, die nachgewiesene Gewinne mit den nächsten Fällen des Portfolios verbindet.
Die klassische Falle. Beim Go-live den Sieg erklären und aufhören zu messen. Sechs Monate später weiss niemand, ob das System noch Wert schafft — oder je welchen geschaffen hat. Das nächste Budget wird dann auf Treu und Glauben verhandelt, gegenüber einem CFO, der beides nicht hat.
Exit-Kriterium. Diese Phase wird nicht verlassen, sondern gehalten. Sie sind im richtigen Rhythmus, wenn jedes monatliche Review mindestens einen Entscheid produziert: ausweiten, anpassen, stoppen oder reinvestieren.
Die neun Exit-Kriterien in einer Tabelle
| Phase | Sie können weitergehen, wenn… |
|---|---|
| 1. Absichtsentscheid | Der Sponsor nennt ohne Notizen das Zielergebnis und das Abbruchkriterium. |
| 2. Diagnose & Baseline | Die heutigen Workflow-Kosten sind beziffert und vom Verantwortlichen bestätigt. |
| 3. Portfolio & erster Fall | Sponsor, Fachbereich und Technik vertreten denselben Fall, aus denselben Gründen. |
| 4. Architektur & Grenzen | Jede Dateneinheit hat Pfad, Verantwortliche und überprüfbare Berechtigung. |
| 5. Fundamente | Das Evaluationsset liefert einen reproduzierbaren Score vor jedem echten Nutzer. |
| 6. Überwachter Pilot | Die Fehlerrate ist nach Falltyp gemessen und mit der menschlichen Baseline verglichen. |
| 7. Evidenz & Skalierung | Der Entscheid Scale, Adapt oder Stop beruht auf Zahlen und ist unterzeichnet. |
| 8. Industrialisierung | Benannter operativer Owner, verfolgtes Budget, laufend gemessene Qualität. |
| 9. Wert im Dauerbetrieb | Jedes monatliche Review produziert mindestens einen Entscheid. |
Vom Framework zum Umsetzungsplan
Neun Phasen passen in einen Artikel; ihre Umsetzung passt in einen Plan. Um konkret zu zeigen, was jede Phase produziert, haben wir einen vollständigen Implementierungsplan von rund fünfzig Seiten aus einem realen Mandat anonymisiert: Er führt durch die neun Phasen, Liefergegenstand für Liefergegenstand — von der Absichtsnotiz der Phase 1 bis zu den monatlichen Reviews der Phase 9, mit den verwendeten Dokumentvorlagen und Schwellenwerten.
Zwei Regeln fassen den Gebrauch des Frameworks zusammen. Überspringen Sie keine Phase: Jede existiert, weil ihr Fehlen dokumentierte Kosten hat. Und machen Sie daraus keine Bürokratie: In einem einfachen Fall passt eine Phase in ein Meeting und zwei Seiten. Entscheidend ist nicht die Dauer einer Phase, sondern dass ihr Exit-Kriterium erfüllt ist.
Womit Sie am Montag beginnen
- Benennen Sie den Sponsor und lassen Sie ihn das Abbruchkriterium schreiben — vor jedem Gespräch über Werkzeuge.
- Wählen Sie einen Workflow und vermessen Sie ihn ein bis zwei Wochen lang: Durchlaufzeit, Nacharbeit, Ausnahmen, Stückkosten.
- Bewerten Sie drei bis fünf Kandidaten nach Potenzial × Umsetzbarkeit — und behalten Sie nur einen.
- Zeichnen Sie Datenflüsse und Berechtigungsmodell des gewählten Falls auf eine Seite.
- Bauen Sie ein Evaluationsset aus realen Fällen — inklusive der unbequemen —, bevor Sie einen einzigen Prompt schreiben.
- Fixieren Sie schriftlich die Qualitätsschwellen des Piloten und das Datum des Entscheids Scale, Adapt oder Stop.
- Reservieren Sie das monatliche Review jetzt in den Agenden: Governance, die nicht terminiert ist, existiert nicht.
Der Unterschied zwischen einem KI-Projekt, das beweist, und einem, das verspricht, entscheidet sich selten bei der Modellwahl. Er entscheidet sich in der Disziplin der neun Phasen — und er zeigt sich ab der ersten Woche.