Eine sinnvolle KI-Portfolio-Review sollte jedes Pilotprojekt zu einer von drei Entscheidungen zwingen: skalieren, eine klar benannte Unsicherheit beheben oder stoppen. Alles, was als „pausiert“ gilt, braucht eine benannte Abhängigkeit, eine verantwortliche Person und einen Entscheidungstermin. Ohne diese Angaben ist eine Pause nur eine Stoppentscheidung, die niemand treffen will.
Genau das meine ich mit einer Streichliste. Sie ist weder eine Quote für gescheiterte Projekte noch eine Waffe gegen die Menschen, die sie vorgeschlagen haben. Sie macht sichtbar, bei welchen Vorhaben der nächste investierte Euro nicht mehr überzeugend zu rechtfertigen ist. Richtig eingesetzt gibt sie Kapital, knappe technische Kapazität und Risikobudget für bessere Chancen frei.
Der Ansatz schließt den Kreis zwischen der Planung eines KI-Budgets, der Messung der vollständigen Wirtschaftlichkeit von KI und dem Handeln, sobald sich die Evidenz ändert. Ein Portfolio, das Experimente starten, aber nicht stoppen kann, lernt nicht. Es häuft Verpflichtungen an.
Auch Weitermachen ist eine Entscheidung
KI-Piloten lassen sich leicht genehmigen, weil jeder für sich klein wirkt. Die Kosten des Portfolios verstecken sich in der Summe: Modell- und Plattformverbrauch, Datenarbeit, Sicherheitsprüfung, Integration, Evaluation, Support und die Aufmerksamkeit von Menschen, die ein anderes Problem lösen könnten.
Die Review muss deshalb den nächsten Ausgabenschritt mit der nächstbesten Verwendung dieser Ressourcen vergleichen. Bereits ausgegebenes Geld kann erklären, wie die Organisation gelernt hat, macht den nächsten Finanzierungsantrag aber nicht stärker. Das Green Book 2026 von HM Treasury trifft dieselbe Unterscheidung: Versunkene Kosten sollten die nächste Entscheidung nicht bestimmen; die Opportunitätskosten der weiteren Ressourcennutzung bleiben dagegen relevant.
Eine universelle Sechsmonatsfrist wäre falsch. Ein Dokumentenassistent und ein KI-gestützter klinischer Ablauf brauchen unterschiedliche Evidenz und Absicherung. Entscheidend ist, den Zeitrahmen vor Beginn festzulegen, ihn an der zu prüfenden Unsicherheit auszurichten und zu verhindern, dass das Team nach Sichtung des Ergebnisses die Ziellinie verschiebt.
Den Review-Vertrag vor dem Piloten schreiben
Jeder Pilot sollte mit einem kurzen Review-Vertrag ins Portfolio aufgenommen werden. Wenn das Team ihn nicht in verständlicher Sprache ausfüllen kann, ist es wahrscheinlich noch nicht bereit, Geld auszugeben.
| Review-Feld | Was das Portfolio wissen muss |
|---|---|
| Geschäftsergebnis | Was ändert sich für Kunden, Mitarbeitende, Betrieb, Umsatz oder Risikoexposition? |
| Ausgangswert | Wie funktioniert die Arbeit heute ohne das vorgeschlagene KI-System? |
| Evidenzziel | Welches Ergebnis rechtfertigt die nächste Stufe, und wie wird es gemessen? |
| Vollständige Kosten | Was erfordern Entwicklung, Betrieb, Prüfung, Kontrolle und Support? |
| Risikogrenze | Welcher Fehler oder welches Restrisiko würde eine Fortsetzung unvertretbar machen? |
| Sponsor | Wer verantwortet das Geschäftsergebnis und kann die Stoppentscheidung treffen? |
| Entscheidungstermin | Wann wird die Evidenz geprüft, statt nur darüber zu berichten? |
| Ausstiegsplan | Wie werden Zugänge, Daten, Integrationen, Anbieter und Infrastruktur stillgelegt? |
Damit wird Innovation nicht zum Papierwettbewerb. Der Vertrag sollte zu Kosten, Komplexität und möglichen Folgen passen. Er soll verhindern, dass das Portfolio Erfolgskriterien erst erfindet, nachdem das Experiment bereits ein uneindeutiges Ergebnis geliefert hat.
Das NIST AI Risk Management Framework unterstützt diese Lebenszyklus-Sicht. Seine Funktion Manage verlangt eine Entscheidung darüber, ob ein KI-System seinen vorgesehenen Zweck erfüllt und ob Entwicklung oder Bereitstellung fortgesetzt werden sollten. Außerdem fordert sie Mechanismen und klar zugewiesene Verantwortung, um Systeme abzuschalten oder zu deaktivieren, wenn Leistung oder Ergebnisse dem vorgesehenen Einsatz widersprechen.
Drei echte Ergebnisse verwenden
Wählen Sie bei der Review eines von drei Ergebnissen und halten Sie die Begründung fest.
- Skalieren, wenn der Pilot brauchbare Evidenz geliefert hat, die Betriebskosten belastbar sind, das Risiko innerhalb der Toleranz liegt und eine verantwortliche Person bereit ist, ihn als unterstütztes Produkt zu betreiben.
- Reparieren, wenn eine wichtige Unsicherheit durch eine konkrete, zeitlich begrenzte Änderung noch prüfbar ist. Reparieren ist keine Erlaubnis, den gesamten Piloten mit einer neuen Geschichte neu zu starten.
- Stoppen, wenn sich der Geschäftsbedarf verschoben hat, die Evidenz den Schwellenwert verfehlt, die Wirtschaftlichkeit nicht mehr trägt, das Risiko nicht innerhalb der Toleranz reduziert werden kann, der Sponsor fehlt oder eine einfachere Lösung ohne KI besser ist.
In der Reparaturkategorie verlieren Portfolios oft ihre Disziplin. Geben Sie ihr eine Hypothese, eine verantwortliche Person, eine Budgetgrenze und einen neuen Review-Termin. Kommt das Team mit einem anderen Anwendungsfall, anderen Nutzern und anderen Erfolgskriterien zurück, ist das ein neuer Vorschlag – kein Beleg dafür, dass der alte erfolgreich war.
Produktionsreife verdient außerdem eine höhere Hürde als eine überzeugende Demo. Das Minimum-Viable-Modell für KI-Governance liefert Risikostufen und Evidenz-Gates; Day-Two-Betrieb für KI macht Verantwortung, Überwachung, Incident Response und Wiederherstellung sichtbar. Wenn diese Pflichten die Wirtschaftlichkeit unattraktiv machen, hat das Portfolio etwas Wichtiges gelernt, bevor es die Haftung skaliert.
Lernen zählen, ohne ROI zu erfinden
Ein gestoppter Pilot braucht keinen erfundenen Return on Investment, um wertvoll zu sein. Berichten Sie ehrlich, was gelernt wurde:
- nach der Entscheidung vermiedene zukünftige Ausgaben;
- zurückgewonnene Kapazität in Engineering, Security, Daten und Fachbereichen;
- ein beseitigtes Risiko oder eine aufgelöste Abhängigkeit;
- eine widerlegte Annahme;
- wiederverwendbare Evaluationsdaten, Integrationsarbeit oder Kontrollmuster; und
- eine bessere Auswahlfrage für den nächsten Vorschlag.
Trennen Sie vermiedene zukünftige Kosten von bereits ausgegebenem Geld. Zählen Sie frei gewordene Arbeitszeit nur dann als Einsparung, wenn die Organisation zeigen kann, wohin diese Kapazität geflossen ist. Das Ziel ist ein Entscheidungsprotokoll, das die nächste Zuteilung verbessert – kein Rechentrick, der jedes Experiment erfolgreich aussehen lässt.
Die Streichliste sollte auch den Grund für den Stopp festhalten. Wiederkehrende Ursachen können mit der Zeit Probleme auf Portfolioebene sichtbar machen: Anwendungsfälle ohne Ausgangswert, fehlende Business Owner, unreife Daten, zu spät ergänzte Kontrollen oder Stückkosten, die unter realistischen Qualitätsanforderungen nicht tragen. Diese Evidenz ist nützlicher als ein Dashboard, das lediglich zeigt, wie viele Piloten noch aktiv sind.
Die Wahrheit muss sich sicher aussprechen lassen
Angst ist ein schlechtes Betriebsmodell. Wird das Stoppen eines Piloten als Makel für das Team behandelt, werden Menschen schwache Signale verbergen, die Messung verengen und um eine weitere Runde bitten. Das Governance-Design sollte die Qualität des Experiments von der Entscheidung über die Fortsetzung der Investition trennen.
Der Business Sponsor verantwortet das Ergebnis. Das technische Team verantwortet die Integrität der Evidenz. Das Portfolio-Gremium verantwortet den unternehmensweiten Zielkonflikt. Diese Aufteilung verhindert, dass ein Projektteam seine eigene Existenz verteidigen muss, und dass ein Bereich eine lokale Initiative auf Kosten des Gesamtunternehmens schützt.
Führungskräfte prägen den Ton mit der Frage: „Was haben wir gelernt, und wohin sollte diese Kapazität jetzt fließen?“ Das ist schwieriger und nützlicher als: „Wer ist gescheitert?“
Die nächste Review anders durchführen
Beginnen Sie mit allen aktiven KI-Piloten, nicht nur mit denen, die neues Geld beantragen. Jeder Sponsor erhält eine Seite mit Review-Vertrag, tatsächlicher Evidenz, verbleibender Unsicherheit, vollständigen Kosten der nächsten Stufe und dem empfohlenen Ergebnis.
Treffen Sie dann im Termin die Entscheidung: skalieren, reparieren oder stoppen. Veröffentlichen Sie intern die Streichliste mit Begründung, freigegebener Kapazität, wiederverwendbarem Wissen und der verantwortlichen Person für die Abschaltung. Prüfen Sie abschließend, ob Zugangsdaten, Datenkopien, Anbieterzusagen, Integrationen und Infrastruktur tatsächlich entfernt wurden. Eine Entscheidung in einer Präsentation ist noch keine Stilllegung.
Es geht nicht darum, mehr KI-Projekte zu beenden. Es geht darum sicherzustellen, dass jedes Projekt weiterläuft, weil die aktuelle Evidenz es rechtfertigt – nicht weil das Stoppen unangenehm ist.
