5 Gründe, warum agentenbasierte CMS-Workflows scheitern (und warum es nicht an der KI liegt)

Das Inhaltsmodell wurde nie für die menschliche Lesbarkeit konzipiert.

Die meisten heute verwendeten Inhaltsmodelle wurden für Menschen entwickelt. Ein Autor öffnet einen Eintrag, sieht Felder mit Namen wie „Textkörper“, „Werbeblock 2“ und „Bild (links oder rechts)“ und füllt sie basierend auf seinem intuitiven Wissen über die jeweilige Funktion aus.

Das funktioniert, weil der Autor weiß, was „Werbeblock 2“ an einem Dienstagmorgen in diesem Unternehmen bedeutet. Der Feldname muss diese Bedeutung nicht vermitteln. Die Person tut es.

Patrick, 2016: Was ist falsch an „Werbeblock 2“?

Eine ganze Menge. Aber du hättest sowieso nicht zugehört.

Patrick, 2016: Versuch’s doch.

In etwa acht Jahren wird ein KI-System diesen Feldnamen lesen. Es wird versuchen herauszufinden, was dort hineingehört. Es hat nur den Namen als Anhaltspunkt. „Werbeblock 2“ sagt ihm gar nichts – weder, was dort hineingehört, noch welchen Ton der Text haben soll, noch, welche Zielgruppe er anspricht, noch wie er mit „Werbeblock 1“ zusammenhängt.

Patrick, 2016: Muss es auch nicht. Mike weiß, was da reinkommt.

Mike geht 2020. Bis 2025 weiß nur noch ein externer Mitarbeiter, der letzten Monat angefangen hat und anhand der bestehenden Einträge rät, was „Werbeblock 2“ bedeutet. Der Agent macht dasselbe, nur schneller und in größerem Umfang.

Früher waren die Kosten eines unklaren Feldnamens gleich null, da der menschliche Leser die Lücke ausgleichte. Jetzt, mit einem Agenten als Lesegerät, entsprechen die Kosten eines unklaren Feldnamens der Qualität aller Inhalte, die mit diesem Feld in Berührung kommen – und zwar dauerhaft und in großem Umfang.

So gestalten Sie es kontraproduktiv

Behandeln Sie Feldnamen, Beschreibungen und Validierungsregeln wie Eingabeaufforderungen. Denn genau das sind sie. Unterziehen Sie Ihr Inhaltsmodell derselben Prüfung wie eine Systemeingabeaufforderung. Wenn ein Feldname einem Fremden nicht verrät, was dort hingehört, schreiben Sie ihn um. Wenn zwei Felder ähnliche Funktionen haben, fassen Sie sie zusammen oder grenzen Sie sie klarer voneinander ab. Diese Arbeit ist wenig glamourös und wird von den meisten Teams vernachlässigt. Genau deshalb lohnt sich die Behebung dieses Problems enorm.

Governance wurde als Richtlinie verfasst, obwohl sie als Durchsetzungsmaßnahme hätte formuliert werden müssen

Jedes Team, das ich bei der Einführung eines agentenbasierten Content-Workflows beobachtet habe, verfügt über ein Governance-Dokument. Drei Genehmiger. Rechtsprüfung. Das volle Programm. Das Dokument legt fest, was erlaubt ist, was nicht, wer was genehmigt und wie der Eskalationsweg aussieht.

Das Dokument ist das Problem.

Ein Richtliniendokument geht von einem Volumen und einer Geschwindigkeit aus, die der menschlichen Content-Produktion entsprechen. Ein Agent erstellt Entwürfe in einem Tempo, für das der menschliche Prüfprozess nie ausgelegt war. Eine Richtlinie, die drei Genehmiger und eine Rechtsprüfung erfordert, funktioniert bei 20 Beiträgen pro Woche. Bei 200 Punkten bricht das System zusammen. Teams geraten also entweder bei der Überprüfung in einen Engpass und verlieren die angestrebte Geschwindigkeit, oder sie umgehen die Richtlinie stillschweigend und verlieren die ihnen zugesicherte Governance.

Beide Optionen enden gleich: Es gibt keine Governance mehr. Man hat ein Dokument, das die Governance beschreibt, die man einmal hatte.

Wenn ich an funktionsübergreifender Governance für Content-Lifecycles gearbeitet habe, lagen die Vorteile nicht in einer besseren Richtlinie. Sie lagen darin, Governance so zu behandeln, wie ein Entwicklerteam Code-Reviews behandelt. Die meisten Prüfungen werden automatisiert. Die Mitarbeiter konzentrieren sich auf die, die eine Beurteilung erfordern. Das System übernimmt die einfachen Aufgaben, damit die Mitarbeiter die schwierigen bewältigen können.

Wie man dem entgegenwirkt

Betrachten Sie Governance nicht länger als Richtliniendokument. Betrachten Sie sie stattdessen als Code-Review. Was kann automatisch durchgesetzt werden? Markenrichtlinien, verbotene Ausdrücke, Compliance-Prüfungen, Zitiervorschriften. Was erfordert wirklich menschliches Eingreifen? Strategische Positionierung, sensible Themen, markenprägende Aussagen. Das System sollte so einfach sein, dass die Durchsetzung erfolgt, bevor ein Mensch den Entwurf überhaupt zu Gesicht bekommt, und die menschliche Überprüfung den zehn Prozent vorbehalten ist, bei denen es tatsächlich auf Urteilsvermögen ankommt.

Die Taxonomie war für die Navigation gut genug, aber nicht für die Analyse.

Ich habe agenturseitig etwa 2017 eine strukturell elegante Inhalts-Taxonomie eingeführt. Website-Besucher konnten darin navigieren. Autoren konnten neue Einträge hinzufügen. Die Suchmaschinenoptimierung war zufrieden.

Sie war nicht für die Analyse durch einen Mitarbeiter konzipiert.

Patrick, 2017: Die Taxonomie funktioniert. Besucher können darin navigieren, Autoren können Inhalte hinzufügen, die Suchmaschinenoptimierung ist zufrieden.

In zehn Jahren wird ein System, das weder navigiert noch Dateien verwaltet oder sich um SEO kümmert, versuchen, das zu erklären.

Patrick, 2017: Und?

Ihre Kategorien schließen sich nicht gegenseitig aus. „Lifestyle“ überschneidet sich mit „Abenteuer“, das sich wiederum mit „Performance“ überschneidet. Sie lösen diese Unklarheit mit redaktionellem Urteilsvermögen auf, das ausschließlich in Ihrem Kopf existiert. Ein Autor weiß einfach, wo ein Beitrag hingehört – und wenn nicht, fragt er im Chat nach. Dieses implizite Wissen wird nicht an einen Agenten weitergegeben.

Der Agent liest die Taxonomie wörtlich. Bei Überschneidungen der Kategorien schwankt die Zuordnung. Bei Unklarheiten wählt er mit Überzeugung die falsche. Die Website-Navigation sieht gut aus. Die agentenbasierten Workflows erzeugen subtil fehlerhafte Ergebnisse, die sich mit der Zeit verstärken.

Patrick, 2017: Es hat zwei Jahre lang funktioniert.

Genau das ist das Problem. Es hat funktioniert, weil Sie dafür gesorgt haben, dass es funktioniert.

Wie man dem entgegenwirkt

Überprüfen Sie Ihre Taxonomie auf Mehrdeutigkeiten. Wählen Sie zehn Inhaltselemente aus und fragen Sie drei Teammitglieder unabhängig voneinander, wo jedes Element einzuordnen ist. Erhalten Sie nicht dreimal dieselbe Antwort, ist Ihre Taxonomie mehrdeutig – und Ihr Agent übernimmt diese Mehrdeutigkeit. Entweder präzisieren Sie die Bezeichnungen oder fügen Sie dem Modell selbst Regeln zur Auflösung von Mehrdeutigkeiten hinzu. Die Arbeit ähnelt eher der Erstellung eines Thesaurus als der Inhaltsentwicklung. Content-Teams sträuben sich dagegen. Führen Sie die Aufgabe trotzdem durch.

Es gibt keinen Eskalationsweg, weil niemand einen für nötig hielt

Bei Arterra war ich auf Kundenseite für die technische Steuerung des digitalen Lösungsportfolios über Intranet-, B2B- und DTC-Kanäle hinweg verantwortlich. Dabei habe ich etwas Wichtiges über Eskalationswege gelernt: Sie fühlen sich nur so lange optional an, bis sie es nicht mehr sind. Sobald es zu einer Eskalation kommt, ist das Fehlen eines solchen Weges das Teuerste, was man zu verantworten hat.

Die meisten agentenbasierten Content-Workflows sind ohne explizite Eskalationslogik aufgebaut. Man geht davon aus, dass ein Mensch eingreift, wenn etwas schiefgeht. Bei geringem Volumen ist das in Ordnung. Bei steigendem Volumen wird es jedoch zum Problem, da niemand die Ausgaben permanent überwacht. Der Agent liefert etwas aus, was er nicht hätte liefern sollen. Das Team erfährt es durch eine Kunden-E-Mail, einen Compliance-Beauftragten oder – noch schlimmer – … Ein Journalist.

Das Muster, das ich in der Entwickler-Community immer wieder beobachte: Teams entwickeln zuerst den optimalen Ablauf und versprechen sich, die Eskalationslogik später hinzuzufügen. Doch sie fügen sie nicht später hinzu, sondern erst nach dem ersten Vorfall.

Wie man dem entgegenwirkt

Entwickeln Sie den Eskalationspfad, bevor Sie den Workflow erstellen. Legen Sie explizit fest, was eine Warteschleife, die Einschaltung eines Mitarbeiters oder den Abbruch auslöst. Bestimmen Sie, wer für welche Stufe zuständig ist. Legen Sie fest, wie der Prüfpfad aussieht. Wenn Sie nicht genau beschreiben können, was der Mitarbeiter in unklaren Situationen tut, haben Sie keinen Workflow. Sie haben lediglich einen Entwurfsgenerator mit einem Veröffentlichungsbutton.

Niemand ist für den gesamten Workflow verantwortlich – daher kann ihn auch niemand reparieren, wenn er ausfällt.

Das sehe ich am häufigsten. Und es sieht am wenigsten nach einem KI-Fehler aus.

Patrick, 2016: Jeder ist dafür verantwortlich. Marketing Operations, der Entwickler, der Content Director, die IT.

Das ist dasselbe, als ob niemand dafür verantwortlich wäre.

Patrick, 2016: Das ist hart.

Das ist nicht hart. Es ist betrieblich. Wenn der Workflow ausfällt – und er wird ausfallen –, muss man wissen, wessen Kalender geöffnet ist. Aktuell haben Sie vier Kalender, die alle geschlossen bleiben, weil jeder davon ausgeht, dass jemand anderes darauf zugreift.

Der Workflow wird von einem Marketing Operations Lead erstellt, mit Input eines CMS-Ingenieurs, Freigabe durch einen Content Director und einer Sicherheitsprüfung durch die IT. Jeder arbeitet daran. Niemand ist dafür verantwortlich. Wenn er also nicht mehr funktioniert, verbringt das Team zwei Wochen damit, herauszufinden, wer zuständig ist, bevor überhaupt jemand mit der eigentlichen Problemlösung beginnt.

Ich beobachte dasselbe Muster bei der Mini-Lehre von Postgraduierten am Centennial College. Gruppenprojekte, bei denen die Zuständigkeit unklar ist, scheitern genauso wie unternehmensweite Workflows – nur eben innerhalb von sechs Wochen statt sechs Quartalen. Der Mechanismus ist identisch.

Patrick, 2016: Gut. Also ernenne ich jemanden.

Eine Person. Kein Komitee. Keine Arbeitsgruppe. Eine Person, die für das Verhalten des Workflows, seine Ergebnisse und seine Weiterentwicklung verantwortlich ist. Sie müssen nicht die technisch versierteste Person im Raum sein. Sie müssen diejenige sein, deren Telefon klingelt, wenn etwas schiefgeht.

Patrick, 2016: Und wenn niemand die Aufgabe übernehmen will?

Dann haben Sie keinen Workflow. Sie haben ein Organigramm mit verteilten Verantwortlichkeiten, was bedeutet, dass Sie nichts haben. Das gleiche Ergebnis wie bei „Promo Block 2“. Niemand wollte sich auch für diesen Feldnamen entscheiden.

Wie man dem entgegenwirkt

Bestimmen Sie einen Verantwortlichen, bevor Sie den Workflow veröffentlichen. Diese Person ist für das Verhalten des Workflows, seine Ergebnisse und seine Weiterentwicklung verantwortlich. Wenn sich niemand dafür bereit erklärt, ist der Workflow noch nicht bereit für die Veröffentlichung.