· 7 Min. Lesezeit

Hunderte Prompts später immer noch kein funktionierendes System: Warum ein KI-Agenten-Projekt einen Business Analysten braucht

Warum Unternehmen nach der Datenaufbereitung KI-Anfragen verbrennen und trotzdem kein verlässliches Ergebnis bekommen — und warum das fehlende Stück ein Mensch ist, der den Prozess verantwortet.

Kurzfassung

FrageKurze Antwort
Wir haben unsere Daten sauber aufbereitet — warum ist der Agent immer noch unzuverlässig?Weil Datenaufbereitung die Eingaben repariert. Den Prozess zu spezifizieren — jede Ausnahme, jeden Sonderfall — ist eine separate Aufgabe, die das Werkzeug bei jemandem voraussetzt, der sie schon erledigt hat
Sind die Modelle also nicht gut genug?Sie sind exzellent und werden besser (Claude Opus 5, GPT-5.x). Der Flaschenhals ist vom Modell zur Spezifikation gewandert
Für wen baut OpenAI diese Werkzeuge?Die AgentKit-Ankündigung sagt es offen: „Entwickler und Unternehmen” — Leute, die ein System bereits spezizieren können
Was macht die fehlende Person?Schlichtet Widersprüche, entscheidet Sonderfälle, baut die Abnahmetests, verantwortet den Änderungsprozess
Wann reicht DIY?Persönliche Produktivität, einmalige Dokumente, Wegwerf-Prototypen
Wie sieht „fertig” aus?Ein System mit Rollen, Prüfpfad, Tests und Scoreboard — siehe die Live-Demo auf demo.kamensky.dev

Das ist die zweite Hälfte einer Geschichte. In der ersten Hälfte haben wir die Daten bereinigt: eine kanonische Preisliste, kontrollierte Status, dokumentierter Prozess, ein Testset. Diese Arbeit ist echt und zahlt sich aus. Und dennoch verharren bemerkenswert viele Teams danach monatelang an derselben Stelle: prompten, neu prompten, für Agenten zahlen, die in der Demo glänzen und am Montag fallen.

Der Fehler liegt nicht in der Vorbereitung. Er liegt in dem, was kein Prompt liefern kann.

Zuerst: gebührendes Lob

Die Werkzeuge sind wirklich gut geworden. OpenAIs AgentKit liefert einen visuellen Agent Builder; eigene GPTs verbinden sich mit dem Drive; Claudes Projekte und Workspaces nehmen Dokumente auf und bauen daraus funktionierende Apps; die Frontier-Modelle klettern weiter — Claude Opus 5 kam im Juli 2026, ausdrücklich getunt für langlaufende Agenten. Für technisch versierte Menschen ist die Strecke von der Idee zum laufenden Prototyp auf Stunden geschrumpft.

Lies die AgentKit-Ankündigung allerdings nochmals und beachte die Zielgruppe: „ein vollständiger Werkzeugsatz für Entwickler und Unternehmen, um Agenten zu bauen, bereitzustellen und zu optimieren.” Entwickler und Unternehmen. Das Werkzeug setzt voraus, dass jemand auf deiner Seite das System spezifizieren kann: was der Prozess ist, wo die Ausnahmen leben, was „richtig” bedeutet, was bei Fehlern passiert. Kann das auf deiner Seite niemand — und in einem typischen KMU kann es niemand —, beseitigt das Werkzeug diesen Bedarf nicht. Es lässt ihn einfach unbesetzt.

Sieben Ausfallmodi, die weiteres Prompten nicht beheben kann

1. Jemand muss Widersprüche schlichten. Dein Vertriebsleiter sagt: Rückgaben 14 Tage; dein Operatonsleiter sagt: 30; beide haben für verschiedene Kundengruppen „recht”. Ein Agent mit beiden Regeln eskaliert den Konflikt nicht — er wählt eine, unsichtbar. Die Kernkompetenz eines Business Analysten ist, aus „beides, kommt drauf an” eine geschriebene Regel mit benannten Ausnahmen zu machen. Diese Entscheidung ist Geschäftsarbeit, keine Prompt-Arbeit.

2. Die Sonderfälle sind das System. Der Happy Path ist 20 % des Prozesses und 100 % der Demo. Der Wert steckt im langen Schwanz: der Kunde mit zwei rechtlichen Entitäten, die Bestellung um 23:58 am 31. Dezember, die Teillieferung, die Währungsumbewertung mitten in der Rechnung. Die stehen in keiner Datei — sie leben in den Köpfen deiner zwei erfahrensten Leute. Sie zu extrahieren heißt Interviews, Whiteboards, Entscheidungen. Anfragen an das Modell holen sie nicht hervor; Fragen an deine Leute schon.

3. Lesen ist einfach; sicheres Schreiben ist Engineering. Chat-Agenten lesen deine Sheets problemlos. Zurückschreiben — ohne doppelte Zeilen zu erzeugen, wenn zwei Personen gleichzeitig editieren, ohne ein Update zu verlieren, wenn das Netz mitten im Speichern abbricht, ohne dass der Agent „hilfreich” einen Preis überschreibt — verlangt Transaktionen, Sperren und Konfliktbehandlung. Kein Chat-Produkt kann das, weil es kein Chat-Problem ist; es ist ein Datenplattform-Problem. (Das ist dieselbe Wand, an die Sheets beim Skalieren stößt, in neuem Gewand.)

4. Ohne Evaluierungsschleife ist „besser” von „anders” nicht zu unterscheiden. Du schärfst den Prompt; die Antworten ändern sich. Sind sie korrekter? Niemand weiß es, denn es gibt kein eingefrorenes Testset und niemanden, dessen Job das Messen ist. Die Schleife wird zur Geschmackssache: prompten, zusammenkneifen, wieder prompten. So entstehen „hunderte Anfragen” — nicht weil das Modell schwach ist, sondern weil nichts Erfolg definiert. Das Testset aus der Vorbereitungsphase ist die halbe Lösung; die andere Hälfte ist ein Mensch, der es nach jeder Änderung ausführt und das Ergebnis abzeichnet.

5. Ein Geschäftsprozess muss jedes Mal gleich laufen. Agenten sind probabilistisch; deine Auftragsabwicklung darf es nicht sein. „Er genehmigt meist den richtigen Rabatt” ist kein Betriebsstandard — es ist ein Schadensbericht ohne Datum. Zuverlässigkeit entsteht, indem man den Agenten in deterministische Schienen bettet: Validierung, Wiederholungen, Idempotenz, ein Prüfpfad darüber, wer was geändert hat. Diese Schienen zu bauen ist Ingenieursarbeit um den Agenten herum, kein Gespräch mit ihm.

6. Jemand muss den Änderungsprozess verantworten. Die Preisliste ändert sich am Dienstag. Wenn die Referenzdaten einen Eigentümer und eine Änderungsregel haben, ist der Agent in Minuten wieder korrekt. Wenn nicht, bleibt er zuversichtlich falsch, bis ein Kunde es merkt. Jedes echte System braucht diesen Eigentümer — eine Person, die dafür geradesteht, dass die Wahrheit wahr bleibt. Die Anbieter verkaufen dir den Agenten; der Eigentümer ist in keinem Plan enthalten.

7. Vertrauen muss verdient und dann erhalten werden. Ein Team wirft ein System nach ungefähr zwei schlechten Antworten weg — und das zu Recht. Vertrauen wieder aufzubauen verlangt genau das, was ein Analyst liefert: den Vorfall ausgewertet, die Regel an einer Stelle korrigiert, den Test um genau diesen Fall erweitert und die Korrektur vorgeführt — nicht einen weiteren hoffnungsvollen Prompt.

Die Ökonomie des Prompt-Iterierens

Auf Prompts zu iterieren fühlt sich kostenlos an, weil jede Anfrage billig ist. Ist sie nicht: Zum abgerechneten Tarif der Chat-Werkzeuge skaliert eine 40-Registerkarten-Mappe, die pro Sitzung neu gelesen wird, plus exploratives Prompten mit der Aktivität, nicht mit den Ergebnissen — und der echte Kostenblock sind die Monate, in denen dein Operativteam halb im alten Prozess, halb beim Agenten hängt. Die Alternative ist kein besserer Prompt. Es ist eine Spezifikation: das Prozessdokument, das Sonderfall-Register, das Testset und die Abnahmekriterien aus der Vorbereitungs-Checkliste — einmalig produziert, von einem Menschen, in Wochen — wonach Agenten billig und zuverlässig werden.

Warum die fehlende Rolle zuerst Business Analyst ist

Beachte: Von den sieben Ausfallmoden oben sind nur Nr. 3 und Nr. 5 im Wesentlichen Engineering. Die anderen fünf sind Business-Analyse: Regeln schlichten, ungeschriebenes Wissen extrahieren, messbare Korrektheit definieren, Referenzdaten verantworten, die Abnahme fahren. Deshalb rettet „stell einen Prompt-Engineer ein” diese Projekte so selten — der Flaschenhals waren nie die Prompts.

Es ist zugleich die ehrliche Beschreibung meiner Arbeit. Ich habe 17 Jahre innen in Geschäftsoperationen gearbeitet, bevor ich Software gebaut habe: VWL-Diplom, Industrie-Analytik, Business Analysis, SAP- und Excel-Automatisierung in realen Unternehmen. Heute führe ich diese Discovery-Diziplin als Schritt eins jedes Automatisierungsprojekts — und baue dann die Agenten und die Plattform drumherum, sodass das Ergebnis Rollen, Berechtigungen, Prüfpfad, Backups und eine Testsuite hat. Derselbe Prozess, auf deine Daten angewandt, ist Ende-zu-Ende sichtbar auf demo.kamensky.dev: die Migrations-Pipeline, die authentifizierte Operativ-Plattform, die dein Team tatsächlich nutzen würde, und das Scoreboard, das die Stunden und Dollars zeigt.

Wenn dein Team im Prompt-Loop feststeckt, ist der günstigste nächste Schritt keine weitere Anfrage. Buche eine 20-Minuten-Fit-Gespräch — bring den Prozess mit, der wehtut; du wirst wissen, ob es ein Daten-, ein Spezifikations- oder ein Plattform-Problem ist und was die Behebung jeweils kostet.

Wann DIY wirklich reicht

Die ehrliche Grenze: persönliche Produktivität (zusammenfassen, entwerfen, übersetzen), einmalige Analyserfragen über eine einzige saubere Datei und Wegwerf-Prototypen, die eine Idee validieren, bevor man investiert. Dafür sind die eingebauten Werkzeuge hervorragend, und dieser Artikel gilt nicht. Sobald ein Prozess wöchentlich läuft, Geld oder Kunden berührt oder braucht, dass zwei Personen sich über die Zahlen einig sind — erscheint die fehlende Rolle, ob jemand sie geplant hat oder nicht.

Quellen und weiterführende Lektüre