Der Pilotfriedhof: sechs Gründe, warum agentische Projekte gestrichen werden
Die Demos werden jeden Monat besser. Jede Person kann an einem Nachmittag etwas aufsetzen, das wie ein autonomer Agent aussieht, und die Begeisterung im Vorstand ist echt. An der Oberfläche sieht die Einführung nach Beschleunigung aus.
Nur erzählen die Zahlen darunter eine härtere Geschichte. Rund 60 % der Unternehmen berichten keinen messbaren Nutzen aus KI (BCG), etwa 1 % halten sich für KI-reif (McKinsey QuantumBlack), und rund 40 % der agentischen KI-Projekte werden voraussichtlich bis 2027 gestrichen (Thoughtworks). Das ist ein Friedhof, und das Auffällige daran ist, wie wenig Vielfalt die Todesursachen zeigen. Projekte scheitern nicht auf tausend kreative Arten. Sie scheitern auf etwa sechs, und jede ist vermeidbar, wenn man vor dem Start dafür entwirft.
Hier sind die sechs und was stattdessen zu tun ist.
Grund 1: Sie skalierten eine Laptop-Automatisierung, keine Architektur
Die häufigste Todesursache ist, eine funktionierende Demo für ein Produktionssystem zu halten. Ein selbst gebautes Skript besteht die Demo, jemand ruft den Sieg aus, und der Plan wird "das skalieren wir".
Aber zwischen einer Laptop-Automatisierung und einem Agenten in Produktion liegt eine Kluft, die Skalierung nicht überquert. Die Automatisierung musste nie Identität, Least Privilege, Drift, Audit oder unzuverlässige Eingaben handhaben, weil auf einer Maschine nichts davon im Scope war. Das Skript zu skalieren skaliert nur seine fehlenden Grundlagen.
Wie man es vermeidet. Behandeln Sie die Demo als Beleg dafür, dass die Idee etwas taugt, nicht als das System. Fragen Sie vor der Skalierung, was das Ding braucht und der Laptop ihm nie gab: eine Identität, eine Grenze um das, was es liest, eine Aufzeichnung dessen, was es entscheidet. Fehlt das, skalieren Sie kein System, sondern eine Haftung.
Grund 2: Der Agent erreichte den nötigen Kontext nicht
Der zweite Friedhof ist stiller, denn der Agent funktioniert einwandfrei, er sieht nur zu wenig, um zu zählen. Sein Kontext lebt über CRM, Kernsystem, Dokumentenarchiv und den Menschen verteilt, der die eine Ausnahme kennt. Die Organisation hat die Schicht nie gebaut, über die ein Agent diesen Kontext sicher erreicht.
Das Projekt teilt sich also in zwei schlechte Optionen. Entweder bleibt der Agent zu isoliert, um nützlich zu sein, oder er wird mit breiten, stehenden Credentials verdrahtet, die das Sicherheitsgremium nicht freigibt. Beide Wege führen zur Streichung.
Wie man es vermeidet. Planen Sie die Kontextschicht als echte Arbeit ein, nicht als Installation. Der Agent sollte Ihre Systeme über typisierte, benannte Capabilities erreichen, unter seiner eigenen Least-Privilege-Identität handeln und strukturell unfähig sein, unzuverlässige Daten als Anweisung zu behandeln. Fehlt diese Schicht im Plan, ist die Modellwahl belanglos.
Grund 3: Er bestand das Sicherheitsgremium nicht
Viele Piloten sterben nicht in der Produktion, sondern im Freigabe-Review, und der Befund ist fast immer derselbe: Der Agent läuft unter dem persönlichen Token einer Entwicklerin mit stehendem Produktionszugriff. Das ist ein Generalschlüssel, und kein ernsthaftes Sicherheitsgremium zeichnet das ab.
Das Projekt war technisch beeindruckend und strukturell nicht freigebbar. Das Team optimierte auf "funktioniert es?" und fragte nie "besteht es das Review?", was in einem regulierten Unternehmen die Frage ist, die das Go-live wirklich freigibt.
Wie man es vermeidet. Entwerfen Sie vom ersten Tag an für das Sicherheitsgremium, nicht als letzte Hürde. Jeder Agent läuft unter seiner eigenen nicht-menschlichen Identität, mit kurzlebigen Least-Privilege-Credentials und einer expliziten Egress-Allow-List, sodass es kein statisches Geheimnis zu stehlen gibt und die Identität nur das Wenige kann, wofür sie zugeschnitten wurde. Bilden Sie jedes agentische Risiko auf ein benanntes, testbares Control ab, damit das Gremium ein Control abzeichnet, keine Zusicherung.
Grund 4: IT-Governance konnte ein driftendes System nicht governen
Manche Projekte bestehen das Sicherheitsgremium und werden Monate später gestrichen, wenn die Governance entdeckt, dass sie das Ding nicht halten kann. Das Change Board wurde für deterministische Software gebaut: gleiche Eingabe, gleiche Ausgabe, änderungskontrollierte Releases. Es hat keinen Mechanismus für ein System, das sich geändert hat, weil ein Modell über Nacht aktualisiert wurde und niemand etwas ausgeliefert hat.
Das Ergebnis ist ein Projekt, das governt aussah, weil es den normalen Prozess durchlief, und sich in der Praxis als ungovernbar erweist. Es hat das falsche Gate passiert.
Wie man es vermeidet. Stellen Sie eine für Agenten gebaute Governance-Schicht neben Ihre IT-Governance, nicht darüber. Agenten verdienen Autonomie auf einer abgestuften Leiter, die von Evals freigegeben wird, Drift-Überwachung kann einen Agenten automatisch zurückstufen, sobald er seine Schwelle verlässt, und die Governance-Einheit wird jede Entscheidung, nicht jedes Release. Deterministische Governance macht weiter, worin sie gut ist. Die neue Schicht verantwortet die Drift.
Grund 5: Der Risikoausschuss konnte keine Blackbox freigeben
Der fünfte Friedhof ist ein Gremium, das immer wieder Nein sagt. Das System mag funktionieren, aber niemand kann im Nachhinein erklären, warum es eine bestimmte Entscheidung traf. Ohne das kann ein Risikoausschuss es nicht freigeben, und ein Projekt ohne Freigabe kann nicht skalieren.
Hier hört "das Modell ist beeindruckend" auf zu zählen. Das Gremium bewertet nicht das Modell. Es bewertet, ob es das System vor einer Aufsicht verteidigen kann, und es kann nicht verteidigen, was es nicht prüfen kann.
Wie man es vermeidet. Machen Sie jede Entscheidung prüfbar, bevor sie bindet. Jede hinterlässt eine append-only, hash-verkettete Nachweisaufzeichnung, geschrieben bevor die Entscheidung wirkt, sodass die Entscheidung nicht stattfindet, wenn der Nachweis nicht geschrieben werden kann. Folgenschwere Entscheidungen lösen sich per Policy zu einem Menschen auf, und die Compliance-Regeln sind Code, der Ihrem Compliance-Team gehört und von ihm signiert wird. Dann zeichnet das Gremium ein dokumentiertes, testbares Control ab, und das ist ein Ja, das es tatsächlich geben kann.
Grund 6: Sie setzten groß, maßen nichts und hatten keinen Ausstieg
Die letzte Todesursache ist ein Fehler im Zuschnitt des Projekts, und sie tötet gute wie schlechte Architekturen. Die Organisation verpflichtet sich vorab auf einen breiten Rollout, etabliert nie eine prüfbare Baseline, setzt nie ein Go/No-Go-Gate und hat damit keinen ehrlichen Weg zu sagen, ob das Ding funktioniert. Monatelang laufen Kosten auf, ohne Möglichkeit, Rendite zu belegen, und irgendwann zieht jemand den Stecker bei einem Projekt, das vielleicht in Ordnung war, weil niemand zeigen konnte, dass es das war.
Wie man es vermeidet. Setzen Sie nicht das Unternehmen aufs Spiel, um die Architektur zu testen. Verpflichten Sie sich stattdessen auf eine Foundation: ein Prozess mit hoher Konsequenz, in etwa sechs bis acht Wochen zu einem governten Agenten in Produktion gebracht, gemessen an einer prüfbaren Baseline, mit einem expliziten Go/No-Go-Gate, bevor sich jemand auf Skalierung festlegt.
Eine grobe Abfolge macht es greifbar. In den ersten 30 Tagen belegen Sie die Grenze: Kontextschicht und Identitäten für diesen einen Prozess aufsetzen, mit dem Agenten im Shadow, der vorschlägt, während Menschen entscheiden. Von Tag 30 bis 60 belegen Sie die Governance: Nachweisspur und Policy-Entscheidungspunkt einschalten, den Agenten auf Supervised heben und den Risikoausschuss ein echtes Control statt einer Folie prüfen lassen. Von Tag 60 bis 90 belegen Sie den Wert am Gate: Kosten pro Einheit, Latenz, Qualitätsgewinn und Übereinstimmung mit der menschlichen Prüfung gegen die Baseline messen und auf Basis von Belegen über die Skalierung entscheiden.
Übersteht es die Latte, skalieren Sie auf Beweis. Wenn nicht, haben Sie acht Wochen verbracht und etwas Echtes gelernt, ohne Produktionsrisiko, was ein weit besseres Ergebnis ist, als es nach einem breiten Rollout zu entdecken.
Die Umdeutung
Beachten Sie, was die sechs Gründe gemeinsam haben. Keiner lautet "das Modell war nicht gut genug". Jeder Tod auf dem Friedhof ist architektonisch oder prozedural: eine fehlende Schicht, eine nicht freigebbare Identität, ein Governance-Modell, das Drift nicht sieht, eine unprüfbare Entscheidung oder eine Wette, platziert bevor irgendetwas belegt war.
Die Frage lautet also nicht "hinken wir bei KI hinterher?". Sie lautet: haben wir für unseren folgenschwersten Prozess eine Identität für den Agenten, eine Grenze um das, was er liest, eine Aufzeichnung dessen, was er entscheidet, eine Governance-Schicht, die ihn driften sieht, und ein vorab gesetztes Gate? Und wenn nicht, was ist die kleinste Foundation, mit der wir das wirklich herausfinden, bevor wir auf den zweiten Prozess setzen?
Wenn Sie eine ehrliche Einschätzung wollen, wo einer Ihrer Prozesse landen würde, buchen Sie einen Termin.