---
title: "KI-Workflow-Dokumentation: Was jedes System braucht"
description: "KI-Workflow-Dokumentation: Architektur, Rollen, Daten, Systeme, Kontrollen, Tests, Runbooks, Kennzahlen, Änderungen und Übergabenachweise sauber festhalten."
url: "https://kodokalabs.com/de/intelligence-hub/ai-marketing-operating-systems/ki-workflow-dokumentation/"
language: de
published: 2026-08-15
updated: 2026-11-07
---

# KI-Workflow-Dokumentation: Was jedes System braucht

## KI-Workflow-Dokumentation: Die Mindestanforderung an den Betriebsnachweis

KI-Workflow-Dokumentation ist der gesteuerte Nachweis über Zweck, Architektur, Eingaben, Systeme, Rollen, Kontrollen, Tests, Betriebsanweisungen, Änderungen und Verantwortlichkeiten eines Workflows.

### Zusammenfassung für die Geschäftsleitung

Viele Teams dokumentieren den Prompt, den ein KI-gestützter Workflow nutzt, und hören dort auf. Es fehlen der Zweck des Workflows, seine Datenabhängigkeiten, die tatsächliche Verantwortung für jeden Schritt, die Berechtigungen, unter denen er läuft, die Modellversion, gegen die er validiert wurde, die Tests, die seine Funktion belegen, der Umgang mit Ausnahmen und die vorhandene Überwachung. Dann wird jede Übergabe fragil: Wer neu im Team ist oder eine abwesende Kollegin oder einen abwesenden Kollegen vertritt, kann den Workflow weder verlässlich verstehen noch sicher betreiben. Und Vorfälle lassen sich kaum untersuchen, weil es keinen Nachweis darüber gibt, was der Workflow leisten und wie er sich verhalten sollte. Dokumentation schafft Betriebswissen und Übertragbarkeit. Am besten wirkt sie, wenn sie von Anfang an zum Workflow gehört und nicht nach dem Go-live in Eile rekonstruiert wird, sobald jemand sie endlich braucht. Dieser Leitfaden behandelt das zwölfteilige Minimum Workflow Documentation Pack, die Frage, wie die Dokumentationstiefe mit Risiko und Komplexität [skaliert](../../pages/en/ai-marketing-framework/scale-ai-marketing-workflows.md), und den direkten Bezug der Dokumentation zur Vorfallsuntersuchung und zum [Capability Transfer](../../pages/en/ai-marketing-framework/ai-marketing-enablement-and-capability-transfer.md).

### Die wichtigsten Erkenntnisse:

- Prompt-Dokumentation allein genügt nicht. Ein Workflow braucht auch dokumentierten Zweck, Architektur, Rollen, Daten, Tests, Ausnahmen und Überwachung.
- Das Minimum Workflow Documentation Pack legt zwölf Bestandteile fest, die für jeden KI-gestützten Workflow vorliegen sollten.
- Die Dokumentationstiefe sollte sich nach Tragweite, Komplexität und Datensensibilität richten und nicht pauschal für alle Fälle gleich ausfallen.
- Erst gute Dokumentation macht Vorfallsuntersuchung, Übergabe und Capability Transfer praktisch möglich.
- Dokumentation gehört neben den Workflow und nicht erst danach, wenn schon etwas schiefgegangen ist.

## Was ist KI-Workflow-Dokumentation?

KI-Workflow-Dokumentation ist der vollständige, gesteuerte Nachweis von allem, was nötig ist, um einen KI-gestützten Marketing-Workflow zu verstehen, zu betreiben, zu prüfen, zu verbessern, zu übertragen und irgendwann abzulösen. Sie entsteht als Teil des Workflow-Aufbaus und wird nicht nachträglich zusammengetragen, wenn eine Übergabe oder ein Vorfall die Frage erzwingt. Sie ist mehr als ein einzelnes Artefakt: Ein Prompt, ein Workflow-Diagramm und ein Testergebnis sind jeweils Teile davon, aber keines für sich ergibt eine vollständige Dokumentation.

Das Wort „gesteuert“ trägt in dieser Definition echtes Gewicht. Es trennt echte Dokumentation von einer losen Sammlung aus Notizen und Screenshots, die in dem Tool liegen, das gerade offen war, als jemand etwas festhalten wollte. Gesteuerte Dokumentation hat einen festen Ablageort, eine benannte Verantwortliche oder einen benannten Verantwortlichen, eine Versionshistorie und einen Prüfprozess. Diese Eigenschaften machen sie auch nach Monaten oder Jahren auffindbar und belastbar, wenn die Person, die den Workflow gebaut hat, vielleicht nicht mehr dabei ist. Dokumentation, die zwar irgendwo existiert, aber nicht verlässlich zu finden ist oder für deren Aktualität niemand einsteht, liefert kaum etwas von dem Betriebswissen, um das es hier geht, auch wenn sie den Haken hinter „Dokumentation vorhanden“ erlaubt.

## Warum Prompt-Dokumentation allein nicht genügt

Ein gespeicherter Prompt zeigt, welche Anweisung ein Modell bekommen hat. Er sagt nicht, warum der Workflow existiert, auf welche Daten er zugreifen darf, wer bei einem fehlerhaften Ergebnis verantwortlich ist, gegen welche Modellversion er getestet wurde, was bei einer Ausnahme passiert oder woran jemand merken würde, dass seine Leistung nachlässt. Teams, die nur den Prompt dokumentieren und das für ausreichend halten, entdecken die Lücke genau dann, wenn sie die Dokumentation am dringendsten brauchen: bei einer Übergabe, einer Vorfallsuntersuchung oder einem Audit. Dann stellt sich heraus, dass der Prompt allein fast keine der tatsächlich gestellten Fragen beantwortet.

Diese Lücke bleibt überraschend lange verborgen. Ein Workflow kann monatelang reibungslos mit reiner Prompt-Dokumentation laufen, bis sich etwas außerhalb der Logik des Prompts ändert: Eine neue Kollegin oder ein neuer Kollege kommt ins Team, das zugrunde liegende Modell wird aktualisiert, ein Kunde verlangt einen Nachweis, wie der Workflow validiert wurde, oder ein Ergebnis verursacht ein Problem, das untersucht werden muss. In jedem dieser Momente braucht man genau die Informationen, die reine Prompt-Dokumentation nie erfasst hat: wer verantwortlich ist, wovon der Workflow abhängt, was getestet wurde und was bei einer Störung geschehen soll. Die Lücke in diesem Moment und unter Zeitdruck zu entdecken, kostet deutlich mehr, als die vollständigere Dokumentation von Anfang an parallel zum Workflow aufzubauen.

## Was gute Dokumentation ermöglicht

Vollständige Dokumentation macht mehrere Dinge möglich, die sonst schwierig oder unmöglich sind: Wer neu im Team ist, kann den Workflow betreiben, ohne ganz auf die informelle Einarbeitung durch die Person angewiesen zu sein, die ihn gebaut hat. Wer einen Vorfall untersucht, kann rekonstruieren, was der Workflow leisten sollte, und das mit dem tatsächlichen Verlauf vergleichen. Eine Auditorin, ein Auditor oder die Prüfung eines Kunden im Rahmen einer Due Diligence kann verifizieren, dass der Workflow die zugesagten Standards erfüllt. Und die Verantwortlichen können den Workflow selbstbewusst übergeben, ablösen oder auf einen neuen Kontext ausweiten, wie es die Disziplin der [Scale](../../pages/en/ai-marketing-framework/scale-ai-marketing-workflows.md)-Phase von kōdōkalabs beschreibt. Nichts davon ist möglich, wenn der einzige Nachweis über den Workflow im Kopf einer einzelnen Person und in einem gespeicherten Prompt steckt.

## Das Minimum Workflow Documentation Pack

![Geschlossener schwarzer Ringordner mit orangefarbenem Gummiband und zwölf Registerreitern an der Seite, beschriftet mit Summary, Map, Roles, Data, Systems, Prompts, Controls, Tests, Runbook, Monitoring, Change Log und Handover](https://kodokalabs.com/assets/media/2026/08/kodokalabs-intelligence-hub-ai-marketing-operating-systems-ai-workflow-documentation-documentation-pack-architecture.webp)

*Aufbau des Documentation Packs*

Das **Minimum Workflow Documentation Pack** von kōdōkalabs legt zwölf Bestandteile fest, die jeder KI-gestützte Marketing-Workflow dokumentiert haben sollte, unabhängig davon, wie weit die Detailtiefe innerhalb der einzelnen Bestandteile mit dem Risiko wächst.

| # | Bestandteil | Inhalt |
| --- | --- | --- |
| 1 | Einseitige Zusammenfassung | Zweck, Verantwortliche und Status auf einen Blick |
| 2 | Workflow-Karte | Die Abfolge der Stufen und Übergaben |
| 3 | Rollen- und Entscheidungsmatrix | Wer oder was jeden Schritt ausführt und freigibt |
| 4 | Daten- und Wissensregister | Auf welche Informationen der Workflow zugreift und woher sie stammen |
| 5 | System- und Integrationsinventar | Welche [Tools](../../pages/en/tools.md) und Systeme der Workflow berührt |
| 6 | Verweise auf Prompt- und Agenten-Registry | Links auf die konkret eingesetzten gesteuerten Prompts oder Agent Contracts |
| 7 | Kontroll- und Freigabematrix | Was von wem geprüft wird und welcher Nachweis dabei entsteht |
| 8 | Test- und Evaluationsprotokoll | Welche Tests durchgeführt wurden und mit welchem Ergebnis |
| 9 | Runbook für Ausnahmen und Vorfälle | Was zu tun ist, wenn etwas schiefgeht |
| 10 | Definition von Überwachung und Messung | Was erfasst wird und wie |
| 11 | Änderungsprotokoll | Eine Aufzeichnung, was sich seit dem ersten Aufbau des Workflows geändert hat |
| 12 | Übergabedokument | Was eine neue Betreiberin oder ein neuer Betreiber braucht, um sicher zu übernehmen |

Ein Workflow, dem mehrere dieser Bestandteile fehlen, ist nicht undokumentiert in dem Sinn, dass gar nichts vorläge. Er ist so dokumentiert, dass bestimmte, vorhersehbare Lücken bleiben, und genau dort entstehen Übergabeprobleme und Schwierigkeiten bei der Untersuchung.

## Workflow-Karte und Architekturnachweis

![Netzdiagramm mit einem großen Knoten „Workflow“ in der Mitte: Pfeile laufen von einer Datenquelle und einem vorgelagerten Workflow hinein, ein orangefarbener Pfeil führt zu einem nachgelagerten Workflow, ein weiterer zu einem System](https://kodokalabs.com/assets/media/2026/08/kodokalabs-intelligence-hub-ai-marketing-operating-systems-ai-workflow-documentation-workflow-dependency-map.webp)

*Abhängigkeitskarte des Workflows*

Die Workflow-Karte hält dieselbe Struktur fest, die beim [KI-Marketing-Workflow-Design](../en/ai-marketing-workflow-design-a-practical-framework.md) entsteht (Stufen, Übergaben und Entscheidungspunkte), und zwar als dauerhaftes Artefakt statt als einmalige Planungsübung. Sie sollte aktuell bleiben, wenn sich der Workflow weiterentwickelt, und nicht als Momentaufnahme aus der Entwurfsphase stillschweigend veralten.

## Rollen, Entscheidungsrechte und menschliche Freigaben

Die Rollen- und Entscheidungsmatrix dokumentiert, wer oder was jeden Schritt ausführt und wer an jeder menschlichen Freigabestelle freigeben, ablehnen oder eskalieren darf. Sie folgt der Verantwortungsdokumentation, die in den [KI-fähigen Marketing-SOPs](../en/ai-ready-marketing-sops-structure-and-governance.md) beschrieben ist. Dieser Nachweis erlaubt es neuen Beteiligten, die Verantwortlichkeiten nachzuvollziehen, ohne sich durchfragen zu müssen.

## Daten, Wissen, Tools und Abhängigkeiten

Dieser Bestandteil inventarisiert, auf welche Daten und Wissensquellen sich der Workflow stützt, mit welchen Systemen und Tools er integriert ist und von welchen anderen Workflows oder Komponenten er abhängt. So lässt sich eine Änderung an einer dieser Abhängigkeiten bis zu jedem Workflow zurückverfolgen, den sie betreffen könnte, statt erst aufzufallen, wenn weiter unten im Prozess unerwartet etwas ausfällt.

## Prompts, Agenten, Modelle und Konfiguration

Statt das Verhalten von Prompts oder Agenten informell zu beschreiben, sollte die Dokumentation auf die konkret eingesetzten, gesteuerten Versionen verweisen: die Registry-ID aus der [Prompt-Architektur im Unternehmen](../en/enterprise-prompt-architecture-governance-and-design.md), den Agent Contract aus einer Multi-Agenten-Architektur und die konkrete Modell- oder Anbieterkonfiguration, gegen die der Workflow validiert wurde. So bleibt die Workflow-Dokumentation mit den gesteuerten Assets im Hintergrund synchron und driftet nicht in eine eigene, separat gepflegte Verhaltensbeschreibung ab, die womöglich nicht mehr der Realität entspricht.

## Tests, Evaluationen und Abnahmenachweise

Dieser Bestandteil hält fest, welche Tests tatsächlich durchgeführt wurden (welche Szenarien verwendet wurden, auch Rand- und Fehlerfälle) und welche Ergebnisse sie brachten. Er hängt direkt mit den Nachweisen zusammen, die ein Workflow vor einer breiteren Einführung im [Pilot Review](../../pages/en/methodology/ai-marketing-pilot-review.md) erbringen muss. Anhand des dokumentierten Testprotokolls kann eine spätere Prüfung unterscheiden, ob „dies unter realistischen Bedingungen validiert wurde“ oder ob „es in einer kurzen Demonstration gut aussah“.

## Runbooks für Ausnahmen, Vorfälle und Wiederherstellung

Das Runbook für Ausnahmen und Vorfälle legt fest, was zu tun ist, wenn der Workflow auf einen bekannten Ausnahmetyp stößt, und getrennt davon, was zu tun ist, wenn etwas Unerwartetes eintritt, das das Runbook nicht abdeckt. Dazu gehört, wen man [kontaktieren](../../pages/en/contact-kodokalabs.md) muss und wie sich der Workflow bei Bedarf sicher anhalten oder zurückrollen lässt. Ist das nicht vorab dokumentiert, muss bei einem echten Vorfall jemand unter Zeitdruck improvisieren, und das führt tendenziell zu schlechteren Entscheidungen als ein in Ruhe entworfenes Runbook.

Ein Runbook lohnt sich selbst für Ausnahmen, die unwahrscheinlich wirken, denn sein Wert ist gerade in dem Moment am höchsten, mit dem niemand gerechnet hat. Ein gutes Runbook muss nicht jede mögliche Störung vorwegnehmen. Es muss eine klare Standardreaktion festlegen (wen man kontaktiert, wie man den Workflow sicher anhält, was man für die spätere Untersuchung sichert), die auch für eine Störung gilt, die das Dokument nie ausdrücklich benannt hat. Dieser allgemeine Rückfall ist oft wertvoller als eine erschöpfende Liste konkreter Szenarien, denn das Szenario, das tatsächlich eintritt, ist überproportional oft eines, an das vorher niemand gedacht hat.

## Überwachung und Messdefinitionen

Dieser Bestandteil legt genau fest, was überwacht wird, wie, und welcher Schwellenwert oder welches Muster Aufmerksamkeit auslösen soll. Er schließt an die [Messung](../../pages/en/ai-marketing-framework/ai-marketing-measurement-and-value-realization.md) an, die in der Measure-Phase von kōdōkalabs beschrieben ist. Ohne eine dokumentierte Definition kann „wir überwachen diesen Workflow“ fast alles bedeuten, vom konsequent gepflegten Dashboard bis zur lockeren Gewohnheit, hin und wieder nachzusehen.

## Versionierung und Änderungskontrolle

Jede wesentliche Änderung am Workflow (eine neue Prompt-Version, eine angepasste Berechtigung, ein überarbeiteter Freigabeschritt) sollte in einem Änderungsprotokoll festgehalten werden, im Einklang mit der Change-Record-Disziplin aus [Data-Led Iteration](../../pages/en/methodology/data-led-iteration.md). So kann später nachvollzogen werden, nicht nur wie der Workflow aktuell arbeitet, sondern auch, wie er dorthin gekommen ist und warum bestimmte Änderungen vorgenommen wurden.

## Dokumentationstiefe nach Risiko

Der **Documentation Depth Test** von kōdōkalabs skaliert, wie viel Detail jeder Dokumentationsbestandteil tatsächlich braucht. Maßgeblich sind mehrere Faktoren: Tragweite, Komplexität, Datensensibilität, ob der Workflow Aktionen nach außen auslöst, wie viele Abhängigkeiten er hat, wie häufig er sich ändert und wie wahrscheinlich eine Übertragung an neue Verantwortliche ist. Ein einfacher, risikoarmer, selten veränderter interner Workflow kommt mit einer schlankeren Fassung jedes Bestandteils aus als ein komplexer, risikoreicher, häufig geänderter Workflow, der Aktionen nach außen auslöst und sensible Daten verarbeitet. Beide mit demselben aufwendigen Standard zu dokumentieren, verschwendet beim ersten Aufwand und lässt beim zweiten Risiken offen.

Die Kalibrierung geht meist in eine vorhersehbare Richtung schief: Unter Zeitdruck neigen Teams dazu, durchgängig leichter zu dokumentieren, weil weniger zu schreiben sich im Moment immer schneller anfühlt. Die Kosten dieser Abkürzung werden aber nur verschoben, nicht vermieden. Ein risikoreicher Workflow, der beim ersten Aufbau zugunsten der Zeit unterdokumentiert wurde, kostet später deutlich mehr, wenn eine Übergabe, ein Vorfall oder ein Kundenaudit erzwingt, Informationen zu rekonstruieren, die beim ersten Mal hätten erfasst werden sollen, oft ohne Zugriff auf den ursprünglichen Kontext, der die Rekonstruktion einfach gemacht hätte. Wer den Documentation Depth Test als echte Hürde behandelt, ehrlich angewendet und nicht unter Termindruck wegdiskutiert, verhindert, dass sich diese aufgeschobenen Kosten im Workflow-Portfolio eines Unternehmens ansammeln.

| Risikofaktor | Folge für die Dokumentation |
| --- | --- |
| Hohe Tragweite | Umfangreichere Abnahmenachweise und Ausnahme-Runbooks |
| Hohe Komplexität | Detailliertere Architektur- und Abhängigkeitsnachweise |
| Hohe Datensensibilität | Umfangreichere Dokumentation von Zugriffen und Berechtigungen |
| Aktionen nach außen | Umfangreichere Dokumentation zu Überwachung und Rollback |
| Viele Abhängigkeiten | Umfangreichere Abhängigkeits- und Auswirkungsnachweise bei Änderungen |
| Häufige Änderungen | Aktivere Versionskontrolle und Änderungsprotokollierung |
| Hohe Übertragungswahrscheinlichkeit | Von Anfang an ein umfangreicheres Übergabedokument |

## Verantwortung, Prüfung und Aktualität

Dokumentation braucht dieselbe benannte Verantwortung und denselben Prüfrhythmus, die in diesem Cluster für SOPs und Wissensobjekte beschrieben sind. Dokumentation ohne Verantwortliche veraltet ebenso unbemerkt wie eine SOP oder ein Eintrag in der Wissensbasis ohne Verantwortliche, und aus demselben Grund: Niemand ist dafür zuständig, zu bemerken, dass sie nicht mehr aktuell ist.

## Übergabe und Capability Transfer

Das Übergabedokument dient gezielt der echten Übertragung von Verantwortung, wie sie die Enable-Phase von kōdōkalabs beschreibt: Es hält fest, was eine neue Betreiberin oder ein neuer Betreiber wissen muss, um sicher zu übernehmen. Es unterscheidet sich von den tieferen Architektur- und Testnachweisen, die sich an Auditierende oder Untersuchende richten. Ein Workflow mit ausgezeichneter technischer Dokumentation, aber ohne übergabespezifische Zusammenfassung kann eine neue Betreiberin oder einen neuen Betreiber dennoch ratlos zurücklassen, weil sich die nötigen Informationen auf mehrere dichte technische Unterlagen verteilen, statt zu einem brauchbaren Einstiegspunkt gebündelt zu sein.

Das liegt daran, dass gründliche und brauchbare Dokumentation nicht automatisch dasselbe sind. Man kann jeden Bestandteil des Minimum Workflow Documentation Pack in erschöpfender technischer Tiefe erfüllen und einer neuen Betreiberin oder einem neuen Betreiber trotzdem etwas übergeben, das am ersten Tag praktisch nicht zu gebrauchen ist, schlicht weil niemand die Auswahl an Informationen zusammengestellt hat, die jemand beim Übernehmen tatsächlich braucht: was zuerst zu prüfen ist, wen man fragt, wie die häufigsten Ausnahmen in der Praxis aussehen. Das Übergabedokument löst genau dieses Zusammenstellungsproblem. Es lohnt sich, es als eigenes Arbeitsergebnis zu behandeln und nicht darauf zu vertrauen, dass es von selbst entsteht.

## Häufige Fehlerbilder

- **Reine Prompt-Dokumentation:** einen gespeicherten Prompt mit vollständiger Workflow-Dokumentation verwechseln.
- **Statische Momentaufnahmen:** Dokumentation, die einmal beim ersten Entwurf entsteht und bei der Weiterentwicklung des Workflows nie aktualisiert wird.
- **Einheitliche Tiefe unabhängig vom Risiko:** für jeden Workflow denselben aufwendigen (oder schlanken) Dokumentationsstandard anwenden, gleichgültig wie groß die Tragweite ist.
- **Kein Ausnahme-Runbook:** ein Workflow ohne dokumentierte Reaktion auf bekannte oder unerwartete Störungen.
- **Undokumentierte Abhängigkeiten:** kein Nachweis darüber, auf welche anderen Systeme oder Workflows sich ein Workflow stützt oder welche er beeinflusst.
- **Dokumentation ohne Verantwortliche:** Unterlagen, die vorhanden sind, aber niemanden haben, der sie aktuell hält.
- **Keine übergabespezifische Zusammenfassung:** technische Dokumentation, die existiert, aber so aufgebaut ist, dass eine neue Betreiberin oder ein neuer Betreiber damit nicht übernehmen kann.

## Checkliste zur Dokumentation

Bevor ein Workflow als ausreichend dokumentiert gilt, prüfen Sie: Alle zwölf Bestandteile des Minimum Workflow Documentation Pack liegen in einer Form vor, die zu Risiko und Komplexität des Workflows passt; Workflow-Karte und Rollenmatrix sind aktuell; Daten, Systeme und Abhängigkeiten sind inventarisiert; Prompts und Agent Contracts werden referenziert und nicht informell beschrieben; Test- und Evaluationsnachweise sind festgehalten; ein Runbook für Ausnahmen und Vorfälle existiert; Überwachung und Messung sind ausdrücklich definiert; ein Änderungsprotokoll wird geführt; eine benannte Verantwortung und ein Prüfrhythmus sind festgelegt; und es gibt ein übergabespezifisches Dokument, getrennt von der tieferen technischen Dokumentation.

## Häufig gestellte Fragen

### Welche Dokumentation braucht Ihr KI-gestützter Marketing-Workflow wirklich?

Mehr als einen gespeicherten Prompt: die zwölf Bestandteile des Minimum Workflow Documentation Pack. Das sind Zusammenfassung, Workflow-Karte, Rollenmatrix, Datenregister, Systeminventar, Prompt- und Agentenverweise, Kontrollmatrix, Testprotokoll, Ausnahme-Runbook, Überwachungsdefinition, Änderungsprotokoll und Übergabedokument.

### Warum reicht es nicht, nur den Prompt zu dokumentieren?

Weil ein Prompt zeigt, welche Anweisung gegeben wurde, aber nicht, warum der Workflow existiert, wovon er abhängt, wer verantwortlich ist, was getestet wurde oder wie mit Ausnahmen umgegangen wird. Genau diese Fragen sind bei einer Übergabe oder Vorfallsuntersuchung entscheidend.

### Wie tief muss die Dokumentation Ihres Workflows gehen?

Sie sollte sich nach Tragweite, Komplexität, Datensensibilität, Aktionen nach außen, Zahl der Abhängigkeiten, Änderungshäufigkeit und Übertragungswahrscheinlichkeit richten und nicht pauschal gelten, unabhängig vom tatsächlichen Risikoprofil des Workflows.

### Was gehört in ein Runbook für Ausnahmen?

Konkrete Reaktionen auf bekannte Ausnahmetypen, Hinweise für unerwartete Situationen, die das Runbook nicht abdeckt, Eskalationskontakte und ein sicherer Weg, den Workflow anzuhalten oder zurückzurollen.

### Wie hilft Dokumentation bei der Untersuchung von Vorfällen?

Sie liefert einen Nachweis darüber, was der Workflow leisten und wie er sich verhalten sollte. So können Untersuchende Soll und Ist vergleichen, statt bei null anzufangen.

### Wer sollte Ihre Workflow-Dokumentation verantworten?

Eine benannte Person, die dafür zuständig ist, sie aktuell zu halten, mit einem festen Prüfrhythmus. Es ist dieselbe Disziplin, die in diesem Cluster für SOPs und Objekte der Wissensbasis gilt.

### Wie unterstützt Dokumentation Übergabe und Capability Transfer?

Durch ein eigenes Übergabedokument, das bündelt, was eine neue Betreiberin oder ein neuer Betreiber braucht, um sicher zu übernehmen, und das sich von den tieferen technischen Unterlagen für Auditierende oder Untersuchende unterscheidet.

### Wie verweisen Sie in der Workflow-Dokumentation auf Prompts und Agenten?

Mit Verweisen auf ihre gesteuerten Registry-Einträge oder Agent Contracts statt mit einer informellen Verhaltensbeschreibung. So bleibt die Dokumentation synchron mit den tatsächlich eingesetzten gesteuerten Assets.

### Was passiert, wenn Sie die Dokumentation bei Änderungen am Workflow nicht aktualisieren?

Sie driftet von der tatsächlichen Praxis ab. Diese Lücke bleibt meist unsichtbar, bis ein Audit, ein Vorfall oder die Verwirrung einer neuen Kollegin oder eines neuen Kollegen sie offenlegt.

### Sollten Sie für jeden Workflow dasselbe Dokumentationsformat verwenden?

Nein. Die Struktur aus zwölf Bestandteilen gilt grundsätzlich, aber die Tiefe innerhalb der einzelnen Bestandteile sollte sich nach dem Documentation Depth Test an Risiko und Komplexität des jeweiligen Workflows richten.

## Fazit

Dokumentation macht aus einem funktionierenden KI-gestützten Workflow ein dauerhaftes Unternehmensasset und keine fragile Abhängigkeit von der Person, die ihn zufällig gebaut hat. Sie ist die verbindende Schicht zwischen den SOPs, Prompts und dem Wissen, die dieser Cluster beschreibt, und dem [Marketing Operating Manual](../en/marketing-operating-manual-for-ai-enabled-teams.md), das alles auf Organisationsebene zusammenführt.

## Sind Sie bereit, Ihre KI-Workflows zu dokumentieren und zu übertragen?

[Executive Readiness Review anfragen](#contact)