Ein Agentenprojekt über 12 Länder mit eigenen Sprachvarianten stand nach zwei Wochen produktiv, geprüft gegen den vollständigen Livebetrieb. Ein zweites, deutlich kleineres Projekt brauchte fünf Wochen und lieferte am Ende weniger. Die Reihenfolge ist also umgekehrt zur Projektgröße.
Was den Takt bestimmt hat, war die Dokumentation der Prozesse, die der Agent bedienen sollte.
Was hat den Unterschied gemacht?
Im ersten Projekt mussten wöchentlich Daten nach Regeln transformiert werden, die in jedem der 12 Länder anders aussahen. Diese Regeln waren über Jahre dokumentiert und immer wieder ergänzt und geprüft worden, auch die Sonderfälle. Der Agent ließ sich fast eins zu eins aus dieser Dokumentation bauen. Am Ende stand ein Fachgespräch mit einigen Rückfragen, danach lief ein System, das die passenden Regeln selbst ermittelte und das erwartete Ergebnis lieferte. Die Abnahme erfolgte gegen die laufende Produktion, mit vollständiger Übereinstimmung.
Im zweiten Projekt war der Umfang kleiner, die Grundlage aber nicht vorhanden. Vieles lag im Kopf einzelner Personen. Es entstanden deutlich mehr Abstimmungsschleifen, verteilt über fünf Wochen, jede ausgelöst von einer Regel, die vorher niemand erwähnt hatte. Nach der Auslieferung meldete sich ein Mitarbeiter verärgert und sprach von einem Fehler in der Anwendung. Es war kein Fehler. Das System tat, was ihm beschrieben worden war. Dazu fiel der Satz, der das Problem genauer beschreibt als jede Studie: Das muss ich nicht dokumentieren, ich weiß das ja auch ohne Dokumentation.
Die Lücke ließ sich schließen. Der eigentliche Unterschied lag woanders: statt die fehlende Doku nachzutragen und den Fall zu schließen, wurde der Prozess gemeinsam mit dem Team noch einmal durchgesprochen, auch die Teile, die nicht im Auftrag standen. Das kostet Zeit, die niemand eingeplant hatte. Es verhindert aber, dass die nächste Lücke erst beim nächsten Agenten wieder auffällt.
Was heißt dokumentierter Prozess im Marketing?
Der Fall oben ist ein Datenprozess. Im Marketing sieht dasselbe Problem anders aus, verhält sich aber gleich. Dokumentiert heißt hier: die Logik einer Kampagne, die Regeln, nach denen Segmente gebildet werden, die Freigabewege je Markt und die Vorgaben zur Tonalität liegen so vor, dass eine Person außerhalb des Teams sie nachvollziehen kann.
Der Standardfall ist dabei fast immer beschrieben. Was fehlt, sind die Abweichungen: der Kunde mit der eigenen Preislogik, die Region mit dem zusätzlichen Freigabeschritt, die Kampagne, die aus historischen Gründen anders läuft als alle anderen. Genau diese Abweichungen bestimmen, ob ein Agent brauchbare Ergebnisse liefert, denn sie sind der Grund, warum der Standardfall allein nicht reicht.
Warum liegt das nicht am Modell?
Weil die Modelle inzwischen genügen und der Rest Vorarbeit ist. Zwei Zahlen ordnen das ein.
Gartner erwartet, dass über 40 Prozent der agentischen KI Projekte bis Ende 2027 eingestellt werden, wegen steigender Kosten, unklarem Geschäftswert oder fehlender Kontrolle. Die Prognose beruht auf einer Befragung von rund 3.400 Webinar Teilnehmern, also keiner repräsentativen Stichprobe, taugt aber als Richtungsangabe. Die MIT NANDA Studie The GenAI Divide findet für generative KI insgesamt 95 Prozent Pilotprojekte ohne messbaren finanziellen Ertrag und führt das ausdrücklich nicht auf Modellqualität oder Regulierung zurück, sondern auf den Ansatz der Organisation.
Microsoft hat für die Agent Readiness Survey 500 Unternehmen befragt, überwiegend große und international aufgestellte, mit Selbstauskunft der Befragten. Ein Wert daraus ist trotz dieser Einschränkung aufschlussreich: nur 22 Prozent stimmen voll zu, dass ihre Schlüsselprozesse und Datenabhängigkeiten dokumentiert sind.
Für Deutschland zeigt Bitkom, dass die Frage nicht mehr theoretisch ist: 41 Prozent der Unternehmen ab 20 Beschäftigten setzen KI aktiv ein, weitere 48 Prozent planen oder diskutieren den Einsatz.
Ein verwandtes Muster haben wir an anderer Stelle beschrieben: dass der Single Customer View meist am Organigramm scheitert und nicht an der Integration. Dort geht es um Zuständigkeiten für Daten. Hier geht es um die Ebene darunter, um die Beschreibung der Abläufe selbst.
Wann kann ich anfangen, wenn die Dokumentation nicht fertig ist?
Sobald du weißt, wo die Lücken sind. Nicht, wenn es keine mehr gibt.
Auch im schnellen Projekt war die Dokumentation nicht vollständig, sonst hätte es das Fachgespräch mit den Rückfragen nicht gebraucht. Der Unterschied zum zweiten Projekt war nicht Vollständigkeit, sondern dass die offenen Punkte benennbar waren und innerhalb von Tagen beantwortet werden konnten. Im zweiten Fall tauchten sie einzeln auf, über fünf Wochen verteilt, jede als Überraschung.
Daraus folgt ein Startkriterium, das ohne Prozessaudit funktioniert. Du kannst bauen, wenn du für den betreffenden Prozess benennen kannst, welche Teile beschrieben sind, welche nur im Kopf einzelner Personen liegen und wer diese Personen sind. Wenn niemand diese Liste aufstellen kann, ist die erste Aufgabe nicht der Agent, sondern die Liste.
Drei Regeln machen den Start dann tragfähig.
Wähle den Piloten nach Dokumentationslage, nicht nach Hebel.
Der Reflex geht zum größten Business Case. Der erste Agent gehört aber dorthin, wo die Grundlage am saubersten ist, auch wenn der Nutzen kleiner bleibt. Der erste Pilot verkauft die Methode intern. Ein schneller, überprüfbarer Erfolg an einem mittelgroßen Prozess ist dafür mehr wert als ein zäher Kampf am wichtigsten.
Halte fest, was während des Bauens geklärt wird.
Ein Agentenprojekt erzwingt Fragen, die im Alltag niemand stellt, weil die Antwort implizit war. Das ist der günstigste Dokumentationsanlass, den eine Organisation bekommt. Im zweiten Projekt wurden diese Antworten in Abstimmungsrunden mündlich verbraucht. Deshalb stand nach fünf Wochen ein System, aber die Grundlage für das nächste Vorhaben war nicht besser als vorher.
Setz ein Abbruchkriterium.
Wenn nach mehreren Iterationsschleifen weiterhin neue Regeln auftauchen, liegt kein Dokumentationsproblem vor, sondern ein ungeklärter Prozess. Dann ist der richtige Schritt, den Agenten zu pausieren und den Prozess zu entscheiden. Ein Agent kann keine Regel ausführen, die es im Unternehmen nicht gibt.
Welche vier Fragen klären das vorab?
Kennt jemand außerhalb des Teams die Ausnahmen?
Testfrage in die Runde: Beschreibt mir den Prozess für den unangenehmsten Sonderfall der letzten drei Monate. Wenn nur eine Person antworten kann, ist das die Stelle, an der der Agent später falsch liegt.
Gibt es ein Ergebnis, gegen das geprüft werden kann?
Im ersten Projekt existierte eine laufende Produktion als Referenz, deshalb war eine vollständige Abnahme möglich. Viele Marketingprozesse haben diese Referenz nicht, weil das Ergebnis Ermessenssache ist. Dann muss die Abnahme vor dem Start definiert werden, sonst wird die erste Beschwerde zum Maßstab.
Wer entscheidet, wenn zwei Regeln sich widersprechen?
Ein Agent braucht eine Rangfolge. Fehlt sie im Unternehmen, verhandelt sie das Projektteam nebenbei mit, und zwar in jeder Schleife neu.
Wer trägt das Ergebnis, nicht den Rollout?
Für den Rollout reicht eine Projektleitung. Für das Ergebnis braucht es jemanden, der entscheiden darf, dass ein Prozess vor der Automatisierung geändert wird. Laut Microsoft hat etwa jedes dritte Unternehmen so eine Rolle benannt, bei den am schnellsten skalierenden sind es 61 Prozent.
Der schnellste Weg zu diesen Antworten ist ein Gespräch, nicht ein Dokument. Wenn dabei der Satz fällt, das wisse man auch ohne Dokumentation, ist die Vorarbeit noch nicht fertig.