KI-Workflow: fünf menschliche Freigaben, bevor ein Agent veröffentlicht

Ein KI-Workflow zum Veröffentlichen braucht fünf menschliche Freigaben, nicht einen Prompt und einen Veröffentlichen-Button. Eine Person entscheidet weiterhin, was geschrieben wird, welche Aussagen erlaubt sind, was der Entwurf sagen darf, wer veröffentlicht und ob die Live-Seite dem freigegebenen Stand entspricht. Mit diesen fünf Freigaben wird ein Agent nützlich. Ohne sie wird er nur ein schnellerer Weg, einen Fehler zu veröffentlichen.

Dieses Kapitel setzt voraus, dass du bereits ein Content-Brief und eine Methode zur Faktenprüfung hast. Wenn das Brief noch aus Thema und Wortzahl besteht, beginne mit einem Content-Brief schreiben. Wenn die Prüfung die schwache Stelle ist, ist das Aussagenregister aus KI-generierte Inhalte prüfen das passende Werkzeug. Hier geht es enger zu: wo die Person sitzt, wenn ein Skript oder ein KI-Assistent die Übergabe macht.

Warum ein KI-Workflow Freigaben braucht und keine Prompts

Eine Freigabe ist eine Entscheidung, die festgehalten wird, bevor der nächste Schritt beginnt. Ein Prompt beeinflusst nur die nächste Ausgabe. Der Unterschied zählt, weil ein Agent ein Werkzeug aufrufen, Credits ausgeben und einen Datensatz schreiben kann, ohne erneut zu fragen. Das Protokoll legt diese Verantwortung beim Host. Die MCP-Spezifikation sagt, Hosts „müssen die ausdrückliche Zustimmung des Nutzers einholen, bevor sie ein Werkzeug aufrufen“ (Model Context Protocol Spezifikation, gelesen am 2026-11-02). Diese Zustimmung ist eine Freigabe und gehört in deinen Ablauf, nicht in einen Dialog, den niemand liest.

Die meisten Teams haben bereits das Gegenstück. Eine Redaktion gibt ein Brief frei. Jemand zeichnet eine Aussage ab. Eine verantwortliche Person drückt auf Veröffentlichen. Der Fehler entsteht, wenn diese Entscheidungen in eine automatisierte Übergabe wandern und niemand die Reihenfolge neu schreibt. Der Agent bekommt dann alle fünf Aufgaben auf einmal, und die einzige Kontrolle ist das Vertrauen in die Ausgabe.

Die dritte Zeile baut dieses Kapitel. Sie macht den Anfang langsamer und das Ende schneller, weil die Korrektur kommt, solange sie noch günstig ist.

Es gibt drei Beteiligte, und sie sollten nicht dieselbe Identität teilen. Das Modell schreibt. Das Skript bewegt Daten und notiert, was passiert ist. Die Person gibt frei. Mit einem gemeinsamen Schlüssel sagt der Datensatz nicht mehr, wer gehandelt hat, und die erste wichtige Prüfung wird zur Untersuchung. Getrennte Schlüssel sind keine Bürokratie, sondern halten die Veröffentlichungsfreigabe sichtbar.

Die fünf Freigaben eines KI-Workflows, in dieser Reihenfolge

Führe sie in dieser Reihenfolge aus. Jede hat eine beobachtbare Bedingung und erzeugt einen Datensatz, den die nächste Person bekommt. Ohne Datensatz gilt die Freigabe als gescheitert.

1. Eingabe: die Frage freigeben. Das Brief nennt eine Leserin, eine Suchintention und eine Seite, die die Antwort besitzen soll. Bestanden, wenn das Brief die bestehenden Seiten verlinkt, die nicht dupliziert werden dürfen. Suchintention erkennen zeigt, wie du die eigentliche Frage liest.
2. Belege: die Quellen freigeben. Jede Tatsachenbehauptung hat eine URL und ein Abrufdatum oder eine eigene Stichprobe und ein Zeitfenster. Bestanden, wenn keine Zeile mehr „zu prüfen“ ist und die prüfende Person die Quellen geöffnet hat, nicht nur die Zitate.
3. Entwurf: das Argument freigeben. Der Entwurf antwortet im ersten Absatz, hält eine Idee pro Abschnitt und nennt seine Grenze. Bestanden, wenn die prüfende Person den Satz zeigen kann, der sagt, was die Seite nicht abdeckt.
4. Veröffentlichung: die Handlung freigeben. Eine namentlich genannte Person drückt den Button im eigenen Konto. Bestanden, wenn der Datensatz URL, Zeit und Konto enthält. Ein Agent bereitet den Inhalt vor; er wird nicht Kontoinhaber.
5. Kontrolle: das Ergebnis freigeben. Die Live-Seite wird abgerufen und mit dem freigegebenen Entwurf verglichen. Bestanden, wenn Titel, Canonical, strukturierte Daten und interne Links übereinstimmen und die URL 200 zurückgibt.

Wie die Übergabe über API oder MCP aussieht

Die Übergabe ist eine Menge von Berechtigungen plus eine schriftliche Spur, keine einzelne Integration. Ob REST oder MCP: Der Aufrufer braucht einen Schlüssel, dessen Bereiche zu der Freigabe passen, die er berühren darf. Die Entwicklerdokumentation von QueryWin trennt read, publish und spend und sagt, dass publish nicht spend enthält (QueryWin Entwicklerdokumentation, gelesen am 2026-11-02). Diese Trennung ist die technische Fassung der Veröffentlichungsfreigabe: Ein Schlüssel, der einen Entwurf liest, wird nicht automatisch ein Schlüssel, der einen anderen bezahlt.

Dieselbe Seite listet neunzehn MCP-Werkzeuge und sagt, dass Werkzeuge nach Bereich gefiltert werden. Ein reiner Leseschlüssel zeigt dem Assistenten die Generierungswerkzeuge also gar nicht. Sie dokumentiert außerdem 120 Anfragen pro Minute und Schlüssel, ein Tageslimit für Generierung und den Unterschied zwischen einer von dir gemeldeten veröffentlichten Listung und einer von QueryWin nach etwa 72 Stunden geprüften Listung. Das sind Kontrollen, keine Garantien. Sie sagen, was das System festhalten kann; sie entscheiden nicht, ob der Entwurf wahr ist.

Gib dem Agenten einen eigenen Schlüssel. Ein geteilter Schlüssel macht aus einer kompromittierten Integration alle Freigaben auf einmal und den Veröffentlichungsdatensatz wertlos, weil du nicht mehr weißt, wer gehandelt hat.

Das Ergebnis: eine Übergabetabelle auf einer Seite

Kopiere diese Tabelle in dasselbe Dokument wie das Brief. Sie ist die gesamte Kontrollfläche: fünf Zeilen, eine verantwortliche Person pro Zeile und ein Ort für den Beleg. Eine Freigabe ohne Verantwortung ist nur ein Vorschlag.

Bevor der Agent läuft:
[ ] das Brief verlinkt die Seite, die nicht dupliziert werden darf
[ ] jede Aussage hat URL und Datum oder Stichprobe und Zeitfenster
[ ] die prüfende Person hat die Quellen geöffnet
[ ] der Agent hat einen eigenen Schlüssel, begrenzt auf diese Aufgabe
[ ] die Veröffentlichung nennt eine Person und ein Konto

Nach der Rückgabe des Agenten:
[ ] der Entwurf nennt seine Grenze in einem Satz
[ ] nach der Belegfreigabe wurde keine Aussage ergänzt
[ ] die Live-URL gibt 200 zurück
[ ] Titel, Canonical, strukturierte Daten und Links stimmen
[ ] der Datensatz sagt, wer wann gehandelt hat

Zwei Zeilen lassen sich leicht fälschen. „Die prüfende Person hat die Quellen geöffnet“ beschreibt ein Verhalten, kein Häkchen: Notiere die URL neben der Aussage. „Die Seite stimmt“ ist ein Vergleich: Behalte die Version oder den Hash des freigegebenen Entwurfs. Wenn du keinen dieser Datensätze zeigen kannst, hat die Freigabe nicht stattgefunden. Ein Entwurf ist keine Entscheidung.

Wo dieser Workflow scheitert

Drei Fehler erklären fast den gesamten Schaden. Alle bestehen ein flüchtiges Lesen, deshalb werden Freigaben festgehalten statt erinnert.

1. Der Agent schreibt das Brief. Die Eingabefreigabe wird zur Zusammenfassung dessen, was das Modell ohnehin sagen wollte. Die Seite beantwortet eine leichte Frage, nicht die der Leserin. Korrektur: Das Brief wird vor dem Generierungsaufruf freigegeben und dem Agenten als Eingabe übergeben.
2. Die Belegfreigabe wird zur Linkprüfung. Jemand bestätigt, dass Links existieren, nicht dass sie den Satz stützen. Eine Quelle kann echt sein und trotzdem nicht sagen, was der Entwurf behauptet. Korrektur: Die prüfende Person formuliert die Aussage neben der Quelle neu und vergleicht sie dann mit dem Entwurf.
3. Die Veröffentlichungsfreigabe wird an das Werkzeug delegiert. Die Integration hat den Bereich publish, also veröffentlicht sie. Technisch ist nichts kaputt, und der Datensatz sagt, ein Agent habe gehandelt. Korrektur: publish bleibt auf einem Schlüssel, den eine Person benutzt; der Agent bekommt read und spend.

Wir haben nicht gemessen, wie oft ein Agent eine Freigabe überspringt, weil eine übersprungene Freigabe keinen Datensatz hinterlässt. Das ist der Punkt: Der Fehler ist in der Ausgabe unsichtbar und nur in der Übergabe sichtbar.

Wir kennen auch deine Prüfkapazität nicht. Fünf Freigaben können zu einer Warteschlange werden, die niemand leert. Wenn die Warteschlange der Engpass ist, reduziere die Zahl der Artikel, nicht die Freigaben. Weniger freigegebene Seiten zu veröffentlichen ist besser, als mehr ungelesene zu veröffentlichen.

Häufige Fragen

Was ist ein KI-Workflow für Inhalte?

Ein KI-Workflow für Inhalte ist die Reihenfolge, die aus einer Suchchance eine freigegebene Seite macht, mit einer verantwortlichen Person bei jeder Übergabe. Er umfasst Brief, Belege, Entwurf, Veröffentlichung und Kontrolle. Das Modell kann einen Teil schreiben; die Entscheidungen gehören ihm nicht.

Darf ein Agent ohne Prüfung veröffentlichen?

Nein, wenn die Seite Tatsachen über dein Produkt, deinen Markt oder deine Kunden behauptet. Ein Entwurf ist keine Entscheidung. Wenn die Ausgabe risikoarm und umkehrbar ist, kann eine leichtere Freigabe reichen, aber der Datensatz muss weiterhin das handelnde Konto nennen.

Wie prüft man KI-generierte Inhalte?

Prüfe die Aussagen, nicht die Prosa. Lege jeden Tatsachensatz in ein Register, füge Quelle und Datum hinzu und prüfe, ob die Quelle diesen Satz sagt. Das zuvor beschriebene Register findet erfundene Zahlen, über die ein erneutes Lesen hinweggleitet.

Ersetzt MCP einen Freigabeprozess?

Nein. MCP standardisiert, wie ein Assistent Werkzeuge aufruft; es entscheidet nicht, welche Aufrufe eine Person freigegeben hat. Die Spezifikation legt die Zustimmung beim Host ab, und dein Prozess muss das Ja weiterhin festhalten. Je mehr Werkzeuge der Agent hat, desto wichtiger wird der Datensatz, weil zwischen zwei Prüfungen mehr passieren kann.

Dieses Kapitel behandelt die Übergabe, nicht das Schreiben oder die Prompts. Es behauptet auch nicht, dass eine Freigabe einen Entwurf wahr macht; sie macht die Entscheidung sichtbar. Das reicht, um die teuren Fehler zu stoppen, und lässt das Urteil dort, wo es hingehört.