Das Problem liegt selten beim Agenten

Gartner prognostiziert, dass ein Großteil der KI-Agenten-Projekte im kommenden Jahr eingestellt wird. Wird diese Zahl zitiert, lautet die implizite Schlussfolgerung meist, die Technologie sei schlicht noch nicht ausgereift.

Unsere Praxiserfahrung zeigt ein anderes Bild. In den meisten gescheiterten Projekten tat das Modell im Wesentlichen genau das, was von ihm verlangt wurde. Das Problem lag darin, was von ihm verlangt wurde – und in welchem Prozesskontext dies geschehen sollte.

Dr. Daniel Tiarks, Mitgründer und CTO von Cambrion, hat diese These kürzlich in einem Beitrag für InformationWeek über das Scheitern von Agenten-Projekten dargelegt. Der dortige Artikel bot Raum für die Kurzfassung. Dies ist die ausführliche Version – denn der spannende Aspekt ist nicht, dass das Prozessdesign über den Erfolg entscheidet. Es ist die Frage, welche Designentscheidungen den Ausschlag geben und wann Sie diese treffen müssen.

Der falsche erste Prozess

Der häufigste Fehler passiert, noch bevor die eigentliche Entwicklung beginnt.

Ein Team sucht nach einem ersten Anwendungsfall und wählt den spektakulärsten aus. Etwas, das viel Abwägung erfordert, nach „Intelligenz“ klingt und vor dem Lenkungsausschuss Eindruck macht. Die Demo ist brillant. Alle Beteiligten im Raum nicken zustimmend.

Danach geht das System in den Produktivbetrieb und trifft auf den realen Workflow. Dieser hält plötzlich undokumentierte Ausnahmen bereit, offenbart zwei Verantwortliche, die uneins über die Zuständigkeit für Schritt vier sind, und einen Kollegen, der als Einziger weiß, wie es wirklich funktioniert, dies aber nie aufgeschrieben hat.

Der KI-Agent füllt diese Lücken nicht. Er hat keine Möglichkeit zu wissen, dass sie existieren. Er wird ein Ergebnis liefern, das zwar selbstbewusst formuliert, aber falsch oder unberechenbar ist – und das in genau der Frequenz, auf die Sie ihn eingestellt haben.

Prozesse, bei denen sich Agenten tatsächlich auszahlen, sehen anders aus: Hohes Volumen. Klar abgegrenzt. Und, ganz entscheidend, sie besitzen ein eindeutiges, überprüfbares Ergebnis. Eine Rechnung enthält entweder die korrekten Positionen oder nicht. Ein Prüfprotokoll überträgt den Messwert korrekt oder nicht. Für solche Demos gibt es keinen Applaus. Aber es sind genau die Projekte, die den Kontakt mit der Praxis überleben.

Sechs Entscheidungen, die über den Erfolg bestimmen

Keine dieser Entscheidungen betrifft die Modellwahl. Alle müssen getroffen werden, bevor der erste Prompt geschrieben wird.

1. Starten Sie mit einem klar abgegrenzten Prozess, der ein eindeutiges Ergebnis liefert.

   „Abgegrenzt“ bedeutet, dass Sie den Input und den erwarteten Output beschreiben können, ohne dass ein „Es kommt darauf an“ nötig ist. Ein „eindeutiges Ergebnis“ bedeutet, dass die Richtigkeit objektiv überprüfbar ist und keine Geschmacksfrage darstellt. Wenn Sie nicht zweifelsfrei feststellen können, ob der Agent korrekt gearbeitet hat, können Sie auch nicht messen, ob er funktioniert. In der Folge erfahren Sie von Fehlern erst durch Kundenreklamationen statt über Ihr eigenes Monitoring.

2. Sichern Sie das Modell durch deterministische Validierung ab und nutzen Sie den Faktor Mensch für Sonderfälle.

   Ein Sprachmodell ist eine probabilistische, also auf Wahrscheinlichkeiten basierende Komponente. Das ist völlig unproblematisch, solange Sie seine Ergebnisse nicht ungeprüft als final betrachten. Um das Modell herum gehört eine deterministische Logik: Schema-Validierungen, logische Konsistenzprüfungen, mathematische Kontrollen und Abgleiche mit führenden Systemen, die die Wahrheit bereits kennen. Alles, was diese Prüfungen nicht besteht, geht nicht in die nachgelagerten Systeme, sondern an einen Mitarbeiter.

   Diesen Schritt lassen Teams besonders häufig aus, da es sich um unspektakuläre Integrationsarbeit statt um glanzvolle KI handelt. Doch genau das macht aus einer netten Demo ein System, das die IT-Abteilung tatsächlich produktiv schalten lässt.

3. Definieren Sie Genauigkeit und Durchsatz, bevor Sie starten.

   Legen Sie die Zielwerte vorab schriftlich fest. Nicht als schwammige „hohe Präzision“, sondern als konkrete Schwellenwerte, abgestimmt darauf, was nachgelagerte Prozesse verarbeiten können. Messen Sie die Leistung kontinuierlich anhand realer Dokumente – nicht an den zehn idealen Beispielen aus der Pilotphase.

   Teams, die dies versäumen, enden in endlosen Diskussionen darüber, ob das System „gut genug“ ist, ohne jemals definiert zu haben, was „gut genug“ überhaupt bedeutet.

4. Fordern Sie lückenlose Nachvollziehbarkeit.

   Jeder extrahierte Wert muss exakt auf seine Quelle zurückgeführt werden können: Welches Dokument, welche Seite, welche Position. Das ist kein optionales Feature für das Debugging. In einem regulierten oder auditierungsrelevanten Umfeld ist ein Ergebnis, das niemand erklären kann, ein Ergebnis, das niemand verteidigen kann.

   Das ist heute wichtiger denn je. Wenn eine Entscheidung Monate später angefochten wird, ist „Das Modell hat das so ausgegeben“ keine gültige Antwort. Die richtige Antwort lautet: „Hier ist das Datenfeld, hier ist die Quellseite, das ist die angewendete Validierungsregel und dieser Mitarbeiter hat es freigegeben.“

5. Betrachten Sie das Modell als austauschbare Infrastruktur.

   Die technologische Entwicklung schreitet rasant voran. Wer seine Architektur fest an das Modell eines einzelnen Anbieters koppelt, macht sich von dessen Preisen, Verfügbarkeiten, Roadmap und rechtlichen Rahmenbedingungen abhängig. Halten Sie das Modell hinter einer standardisierten Schnittstelle. Planen Sie den Wechsel fest ein, denn er wird kommen.

   Dies ist zudem eine Frage der digitalen Souveränität, nicht nur des Engineerings. Wo das Modell betrieben wird und welcher Gesetzgebung es unterliegt, ist eine Designentscheidung von erheblichem Gewicht.

6. Gestalten Sie den Prozess um die Stärken des Agenten herum neu.

   Dieser letzte Schritt ist der schwerste, da er organisatorische und nicht technische Veränderungen erfordert. Wenn ein Workflow heute nur funktioniert, weil erfahrene Mitarbeiter dessen Schwachstellen manuell umgehen, führt eine reine Automatisierung nur dazu, dass Sie diese Workarounds automatisieren. Die Aufgabe besteht darin, den Teil des Prozesses zu isolieren, in dem eine Maschine absolut zuverlässig arbeitet, sie genau dort einzusetzen und die umliegenden Schritte sowie die Übergabepunkte zum Menschen neu zu strukturieren.

Was das in der Praxis bedeutet

Die Dokumenten-Workflows, die wir optimieren, sind bewusst unspektakulär. Handelsrechnungen in der Zollabwicklung. Handschriftliche Prüfprotokolle im Labor. Technische Datenblätter für Ingenieursberechnungen. Patentschriften, die in ein durchsuchbares Schema überführt werden müssen.

Keiner dieser Anwendungsfälle ist glamourös. Aber alle sind hochvolumig, klar abgegrenzt und verifizierbar – genau deshalb funktionieren sie. Die verantwortlichen Teams stellen jedes Mal dieselben drei Fragen: Ist das Ergebnis korrekt? Kann ich nachvollziehen, wie es zustande kam? Und was passiert mit Grenzfällen, bei denen sich das System unsicher ist?

Das ist der Kern der Diskussion. Welches Modell im Hintergrund rechnet, ist dabei fast Nebensache.

Das ungeschminkte Fazit

Wenn Ihr Prozess heute nur funktioniert, weil Ihre Mitarbeiter die Schwachstellen manuell ausgleichen, wird ein KI-Agent das Problem nicht lösen. Er wird das Scheitern lediglich beschleunigen und skalieren.

Die gute Nachricht lautet: Das Prozessdesign liegt in Ihrer Hand. Sie bestimmen das Tempo und arbeiten mit den Menschen, die das Geschäft bereits verstehen. Sie müssen nicht auf das nächste, noch bessere KI-Modell warten. Die meisten erfolgreichen Projekte haben schlicht den unspektakulären Teil zuerst gelöst.