Warum KI-Agentenprojekte abgebrochen werden: eine evidenzbasierte Prüfung

Im Juni 2025 prognostizierte Gartner, dass bis Ende 2027 mehr als 40 % der agentischen KI-Projekte wegen steigender Kosten, unklarem Geschäftswert oder unzureichenden Risikokontrollen abgebrochen würden. Das ist eine zukunftsgerichtete Analystenprognose, keine gemessene Abbruchquote und kein Befund über Wavect-Projekte. Lies die ursprüngliche Pressemitteilung von Gartner.

Gartner veröffentlichte im Mai 2026 eine separate Prognose: Bis 2027 würden 40 % der Unternehmen autonome KI-Agenten wegen Governance-Lücken, die nach Produktionsvorfällen erkannt wurden, zurückstufen oder außer Betrieb nehmen. Diese Aussage verwendet Unternehmen statt Projekte als Einheit und betrifft Rückstufung oder Außerbetriebnahme. Sie darf daher nicht mit der früheren Abbruchprognose zusammengeführt werden. Siehe Gartners Governance-Prognose von 2026.

Wavect hat keinen vollständigen, einheitlich codierten und unabhängig geprüften Portfoliodatensatz veröffentlicht, der Ursachen für den Abbruch von Agentenprojekten einordnet. Die folgenden acht Bereiche sind eine Prüfliste aus Engineering-Praxis und öffentlicher Risikoleitlinie, keine beobachteten Häufigkeiten, kein Kausalnachweis und keine Garantie für günstige Korrekturen.

1. Sind beabsichtigter Wert und Stoppregel explizit?

Beginne mit Aufgabe, betroffenen Personen, aktuellem Ausgangswert, erwartetem Nutzen, Risikotoleranz und verantwortlicher Person. Lege fest, welche Nachweise Skalierung, Neugestaltung, Pause oder Stopp rechtfertigen. Ein technisch leistungsfähiger Agent kann trotzdem die falsche Intervention sein, wenn gewöhnliche Automatisierung, Suche oder eine Neugestaltung des Ablaufs das Problem mit weniger Risiko löst.

Behandle die Fortsetzung eines Piloten nicht als Wertnachweis. Miss ein akzeptiertes Geschäfts- oder Nutzerergebnis, seine Datenquelle und die dafür nötigen Kosten. Dokumentiere Annahmen, die von Akzeptanz, Prozessänderung, Anbieterpreisen oder nachgelagerten Teams abhängen.

2. Sind Evaluationen für den Einsatz repräsentativ?

Eine Prompt-Demo oder eine kleine, handverlesene Stichprobe belegt keine Produktionsleistung. Definiere Testsätze, Kennzahlen und Akzeptanzschwellen für die reale Aufgabenverteilung, kritische Randfälle, Faktenfehler und Halluzinationen, Verweigerungsverhalten, Tool-Nutzung und betroffene Gruppen. Versioniere Evaluationen und prüfe Regressionen, wenn sich Modell, Prompt, Tools, Daten oder Richtlinien ändern.

Der Kern des NIST AI Risk Management Framework fordert dokumentierte Methoden für Tests, Evaluation, Verifizierung und Validierung, Messungen unter einsatzähnlichen Bedingungen, Produktionsüberwachung und definierte menschliche Aufsicht. Siehe den offiziellen AI RMF Core. Ein Eval-Harness ist nützlich, aber keine allgemeine Regel belegt, dass er im ersten Sprint fertig sein oder genau 20 Intents enthalten muss. Skaliere ihn nach Auswirkung, Unsicherheit und Änderungsrate. Unsere Software-QA-Praxis und das TDD-Glossar erläutern verwandte Testkonzepte, ersetzen aber keine agentenspezifische Evaluation.

3. Werden Tool-Zuverlässigkeit und Latenz durchgängig gemessen?

Miss die von Nutzern wahrgenommene Latenz und den Erfolg über den vollständigen Ablauf, nicht nur einen isolierten Median. Erfasse Latenz je Schritt, Timeouts, Wiederholungen, Ratenbegrenzungen, Teilfehler, doppelte Auswirkungen und Verfügbarkeit von Abhängigkeiten. Segmentiere nach Aufgabe und Umgebung. Es gibt keine universelle Latenzschwelle für Misserfolg; die Toleranz hängt vom Ablauf und der Alternative ab.

Parallelisiere nur unabhängige Arbeit, nutze Caches nur, wenn Aktualität und Autorisierung es zulassen, und gestalte Schreibvorgänge idempotent, sofern die Operation dies unterstützt. Wähle ein LLM und ein Reasoning-Budget je Aufgabe anhand gemessener Qualität, Latenz und Kosten. Ein günstigeres Modell gewinnt nicht, wenn es die Akzeptanz- oder Risikoschwelle verfehlt.

4. Berücksichtigt die Wirtschaftlichkeit akzeptierte Ergebnisse?

Anbieterrechnungen können sich mit Volumen, Modellwahl, Prompt-Länge, Wiederholungen, Tool-Aufrufen, Caching und Preisänderungen verändern. Behandle eine Rechnungsanekdote oder behauptete Architekturersparnis nur dann als Nachweis, wenn Ausgangswert, Arbeitslast, Qualitäts- und Risikoschwelle sowie vollständige Kosten dokumentiert sind.

Miss Kosten je Versuch, erfolgreiche Aktion, akzeptierte Lösung und menschliche Eskalation. Beziehe Modell-Tokens, Tools, Retrieval, Infrastruktur, Beobachtbarkeit, Prüfung, Support und Fehlerbehebung ein. Vergleiche Architekturen bei gleicher Qualitäts- und Risikoschwelle. RAG, kürzere Prompts, Caching oder andere Embedding- und Vektorspeicher können manchen Systemen helfen, garantieren aber ohne Messung keine niedrigeren Gesamtkosten.

5. Sind menschliche Aufsicht, Übergabe und Wiederherstellung vorgesehen?

Definiere, welche Entscheidungen eine Freigabe brauchen, wann das System zurückstellen muss, wer eine Eskalation erhält, welchen Kontext diese Person benötigt und wie Nutzer einen Fehler beheben können. Teste verweigerte Berechtigungen, nicht verfügbare Personen, unklare Verantwortung und fehlgeschlagene nachgelagerte Aktionen. Die erforderliche Aufsicht hängt von der Auswirkung der Aktion und dem anwendbaren Recht ab.

Protokolliere nicht standardmäßig den vollständigen Kontext. Logs können personenbezogene, vertrauliche oder sicherheitsrelevante Daten enthalten. Erfasse mit Zugriffskontrolle, Aufbewahrung, Integrität und Schwärzung nur die Nachweise, die für Betrieb, Untersuchung und rechtliche Pflichten nötig sind. Das aktualisierte Generative AI Profile von NIST ist eine freiwillige, sektorübergreifende Ressource zum Steuern, Erfassen, Messen und Verwalten generativer KI-Risiken. Es ist keine Zertifizierung oder Garantie.

6. Sind Quelldaten und Berechtigungen für die Aufgabe geeignet?

Falsche Ausgaben können aus Modellverhalten, Retrieval, Quellenqualität, Tool-Ergebnissen, Richtlinien oder Orchestrierung stammen. Diagnostiziere die Schicht, bevor du den Prompt änderst. Weise Quellen Verantwortliche, Herkunft, Aktualisierungsregeln, Konfliktbehandlung und Zugriffsprüfungen zu. Teste Retrieval mit aktuellen und gegnerischen Fällen.

Wende das Prinzip der geringsten Berechtigung auf Dokumente, APIs, Zugangsdaten und Aktionen an. Erhalte Autorisierung beim Abruf und bei der Aktion, nicht nur bei der Aufnahme. Prompt Engineering kann weder veraltete Quellen reparieren noch ein Autorisierungsmodell, das falsche Daten offenlegt.

7. Ist der Umfang durch Aufgaben und Vertrauensgrenzen begrenzt?

Ein einzelner Agent kann mehrere Fähigkeiten koordinieren, aber jede weitere Aufgabe, jedes Tool und jede Berechtigung vergrößert die Evaluations- und Fehlerfläche. Beginne mit einer begrenzten Aufgabe und expliziten Erfolgskriterien. Füge Fähigkeiten erst hinzu, wenn Nachweise die nächste Risikostufe stützen. "Ein Agent, eine Aufgabe, eine Evaluation" kann eine nützliche Heuristik sein, ist aber kein universelles Architekturgesetz.

Dokumentiere, welche Komponenten entscheiden, abrufen, ausführen und genehmigen. Trenne Lese- und Schreibpfade, wo es sinnvoll ist. Teste Wechselwirkungen zwischen Tools und Berechtigungsausweitungen. Die Map-Leitlinie des NIST AI RMF verlangt die Dokumentation des gezielten Anwendungsumfangs, der Komponentenrisiken und der menschlichen Aufsicht, statt alle Agenten gleich zu behandeln.

8. Sind Governance und Rechtspflichten dem Anwendungsfall zugeordnet?

Ein Audit-Trail ist nicht dasselbe wie das Speichern aller Ein- und Ausgaben. Lege fest, welche Entscheidungen und Aktionen nachvollziehbar sein müssen, auf welcher rechtlichen und sicherheitsbezogenen Grundlage Daten aufbewahrt werden, wer sie prüfen kann, wie lange sie bleiben und wie ihre Integrität geschützt wird. Bei MCP- oder anderen Tool-Aufrufen können Tool-Identität, Autorisierungskontext, Ergebnis, Zeitstempel und Softwareversion nützliche Betriebsnachweise sein, vorbehaltlich Minimierungs- und Sicherheitsanforderungen.

Artikel 22 DSGVO ist keine allgemeine Widerspruchsregel für KI. Er betrifft eine ausschließlich auf automatisierter Verarbeitung beruhende Entscheidung, die rechtliche Wirkung entfaltet oder die betroffene Person ähnlich erheblich beeinträchtigt, vorbehaltlich Ausnahmen und Schutzmaßnahmen. Artikel 22 Absatz 3 nennt bei bestimmten Ausnahmen menschliches Eingreifen, die Darlegung des eigenen Standpunkts und die Anfechtung der Entscheidung. Lies den offiziellen DSGVO-Text und hole Beratung für die konkrete Verarbeitung ein.

"Eine Agentenprüfung ist belastbar, wenn Aufgabe, Nachweise, Fehlergrenze, Verantwortung und Stoppregel explizit sind. Eine erfolgreiche Demo ist nur eine Beobachtung."

Welche Nachweise sollte die Projektprüfung enthalten?

Diese Bereiche können zusammenwirken, doch die Tabelle zeigt keine beobachtete Clusterhäufigkeit. Ein Timeout kann etwa Wiederholungen auslösen, Kosten erhöhen und doppelte Aktionen erzeugen. Halte die Kette im Vorfall- oder Evaluationsnachweis fest, statt ein universelles Fehlermuster zu benennen.

Wann sollte ein Team pausieren, neu gestalten oder stoppen?

Lege Schwellen fest, bevor Begeisterung und versunkene Kosten die Entscheidung verzerren. Pausiere den Einsatz bei ungelösten, schwerwiegenden Sicherheits-, Datenschutz-, Autorisierungs- oder Wiederherstellungsfehlern. Gestalte neu, wenn Aufgabe, Ablauf, Tool-Grenze oder Nachweisplan falsch sind. Stoppe, wenn der erwartete Wert die vollständigen Kosten und das Restrisiko nicht mehr rechtfertigt oder eine einfachere Intervention besser abschneidet.

Ein Abbruch kann ein solides Governance-Ergebnis sein und beweist nicht, dass Agententechnologie oder Engineering versagt haben. Umgekehrt belegt eine technische Bereitstellung keinen Geschäftserfolg. Bewahre Entscheidungsprotokoll, Nachweise, Verantwortung, Abhilfeoptionen und Bedingungen für eine erneute Prüfung auf.

Was belegt Wavects Erfahrung?

Wavects veröffentlichte Fallstudien zu Twinsoft AI, PromptID, Quivr und Hyperstate AI beschreiben ausgewählte Lieferprojekte. Sie bilden keine vollständige Kohorte von Agentenprojekten, ermitteln keine Abbruchquote und ordnen keine Ursachen. Aussagen über spätere Unternehmensentwicklungen benötigen gesonderte, datierte Nachweise und dürfen nicht aus einer Lieferfallstudie abgeleitet werden.

Wavect kann seine Erfahrung nutzen, um Tests, Kontrollen und Architekturoptionen vorzuschlagen. Die Projektverantwortlichen brauchen weiterhin aktuelle Nachweise für den konkreten Anwendungsfall, die Nutzer, Anbieter, Daten, Rechtslage und Betriebsumgebung.