KURZ ERKLÄRT
Ein KI-Runbook erklärt, wie ein freigegebener Ablauf betrieben, geprüft, angehalten und wieder aufgenommen wird. Es muss auch für berechtigte Kollegen funktionieren, die ihn nicht gebaut haben. Dafür braucht ihr mehr als eine Sammlung technischer Einstellungen. Die Anleitung verbindet sichtbare Zustände mit erlaubten Handlungen, klaren Grenzen und einer Übergabe an Menschen, wenn der nächste sichere Schritt nicht feststeht.
Wie ihr einzelne KI-Anwendungen in verlässliche Marketingabläufe einordnet, zeigt der übergeordnete Guide KI-Transformation im B2B-Marketing: Von einzelnen Prompts zu verlässlichen Abläufen.
Mit Zweck und erkennbaren Zuständen beginnen
Beschreibt knapp, was der Ablauf erledigt, welche Ergebnisse er liefern darf und welche Aktionen ausgeschlossen sind. Zeigt den normalen Startpunkt und die sichtbaren Zustände bis zur bestätigten Fertigstellung. Ein Status wie läuft genügt nicht, wenn niemand erkennen kann, ob bereits externe Änderungen stattgefunden haben. Benennt die Belege für jeden wichtigen Übergang, etwa eine gespeicherte Entwurfskennung oder eine bestätigte Aufgabenreferenz. So kann ein Betreiber den tatsächlichen Zustand prüfen, statt aus der letzten sprachlichen Meldung des Agenten auf erfolgreiche Arbeit schließen zu müssen. Mehr dazu im Leitfaden Agentenstatus dokumentieren: Was ist wirklich erledigt?.
Zugriff und Abhängigkeiten ohne Geheimnisse dokumentieren
Listet benötigte Systeme, erlaubte Rollen, Quellenbestände und technische Abhängigkeiten auf. Beschreibt, wo berechtigte Betreiber ihren Zugriff erhalten und wie dessen Funktion geprüft wird. Schreibt keine Zugangsdaten in die Anleitung. Verlinkt die zuständigen Verwaltungswege und nennt einen verantwortlichen Ansprechpartner. Haltet außerdem fest, welche Quelle für welche Aussage maßgeblich ist. Wenn ein Ergebnis falsch erscheint, muss der Betreiber unterscheiden können, ob eine veraltete Quelle, ein Zugriffsproblem oder eine ungeeignete Verarbeitung vorliegt. Diese Orientierung verkürzt die Untersuchung wesentlich stärker als eine unkommentierte Liste von Systemnamen.
Diagnose nach Beobachtungen statt Vermutungen ordnen
Beginnt jeden Fehlerpfad mit einem sichtbaren Symptom und einer begrenzten Prüfung. Google SRE beschreibt Fehlersuche als Abfolge von Hypothesen und Tests auf Grundlage des Systemzustands. Für euren Ablauf kann das heißen: Bei fehlendem Ergebnis zuerst Laufstatus und Eingabe prüfen, danach Quellenzugriff und erst anschließend die Verarbeitung. Notiert erwartete und abweichende Ergebnisse dieser Prüfungen. Vermeidet pauschale Anweisungen wie Modell neu starten. Ein Neustart löst nicht jede Ursache und kann bei unklarem Schreibzustand zusätzliche Aktionen oder verlorenen Diagnosekontext verursachen.
Pause und Wiederaufnahme als getrennte Verfahren schreiben
Eine Pause muss definieren, welche neuen Aufgaben gestoppt werden und was mit laufenden Schritten geschieht. Die Wiederaufnahme braucht dagegen eine Prüfung des erreichten Zustands und möglicher offener Folgen. Ein unterbrochener Schreibzugriff darf nicht automatisch wiederholt werden. Beschreibt, wie vorhandene Ergebnisse gesucht und bestätigt werden, bevor neue Aktionen beginnen. Benennt außerdem die Person, die eine Fortsetzung freigeben darf. Wenn ihr keine sichere Wiederaufnahme anbieten könnt, ist die korrekte Anleitung eine begrenzte manuelle Übergabe mit dokumentiertem Status und nicht ein optimistischer Neustart desselben Laufs.
Ein hypothetisches CRM-Problem durchspielen
Angenommen, ein Agent meldet nach einer Aufgabenanlage keine Antwort des CRM zurück. Der Betreiber findet im Runbook zunächst den Schritt, den vorhandenen CRM-Zustand anhand der bekannten Gesprächsreferenz zu prüfen. Eine Aufgabe ist bereits vorhanden. Er dokumentiert die Kennung und beendet die Wiederholung, statt eine zweite Aufgabe anzulegen. Wäre keine Aufgabe eindeutig auffindbar, würde der beschriebene Eskalationsweg greifen. Das Beispiel zeigt, dass ein gutes Runbook nicht nur Fehler behebt. Es verhindert auch, dass eine unsichere Reparaturhandlung den ursprünglichen Vorfall durch zusätzliche Datensatzänderungen verschärft.
Die Übergabe an eine unbeteiligte Person testen
Lasst einen berechtigten Kollegen einen normalen Lauf und einen ausgewählten Fehlerfall allein anhand der Anleitung bearbeiten. Die Ersteller beobachten, geben aber zunächst keine Hinweise. Prüft, wo unklare Begriffe, fehlende Rechte oder unsichtbare Zustände den Ablauf blockieren. Ein Runbook besteht diesen Test nicht allein dadurch, dass alle Links erreichbar sind. Der Kollege muss die richtige Entscheidung treffen und seine Begründung am Systemzustand zeigen können. Ergänzt anschließend die tatsächlich fehlenden Informationen und wiederholt gezielt den betroffenen Schritt, statt die Anleitung nur um weitere allgemeine Hinweise zu verlängern. Mehr dazu im Leitfaden KI-Verantwortung im Team: Wer entscheidet, prüft und betreibt?.
Die Anleitung mit Änderungen gemeinsam pflegen
Jede relevante Änderung an Tools, Quellen, Berechtigungen oder Zuständen kann die Betriebsanleitung betreffen. Verbindet ihre Aktualisierung deshalb mit der Änderungsfreigabe. Kennzeichnet letzte Prüfung, zuständigen Eigentümer und getestete Version des Ablaufs. Entfernt veraltete Reparaturwege, die nach einer Umstellung nicht mehr gelten. Bewahrt bei Bedarf die historische Fassung für frühere Vorfälle auf, macht aber die aktuelle Anleitung eindeutig erkennbar. Das Runbook ist dann ein überprüftes Arbeitsmittel für verlässlichen Betrieb und Vertretung, nicht lediglich ein Dokument, das nach dem erfolgreichen Pilot irgendwann abgelegt wurde.
INTERAKTIV / VOM LESEN ZUR ANWENDUNG
Drei Prüfpunkte für eure Umsetzung
Wähle einen Punkt und halte deinen persönlichen Lesefortschritt fest. Die Häkchen werden weder gespeichert noch übertragen und sind keine Bewertung eures Unternehmens.
PRÜFPUNKT 01
Diagnose nach Beobachtungen statt Vermutungen ordnen
Beginnt jeden Fehlerpfad mit einem sichtbaren Symptom und einer begrenzten Prüfung.
Im Artikel vertiefen ↗PRÜFPUNKT 02
Pause und Wiederaufnahme als getrennte Verfahren schreiben
Eine Pause muss definieren, welche neuen Aufgaben gestoppt werden und was mit laufenden Schritten geschieht.
Im Artikel vertiefen ↗PRÜFPUNKT 03
Ein hypothetisches CRM-Problem durchspielen
Angenommen, ein Agent meldet nach einer Aufgabenanlage keine Antwort des CRM zurück.
Im Artikel vertiefen ↗Häufige Fragen
Wie technisch muss ein Runbook sein?
So konkret, dass die vorgesehene Betriebsrolle den Zustand prüfen und zulässige Schritte ausführen kann. Unnötige Implementierungsdetails helfen dabei nicht.
Reicht eine Architekturzeichnung?
Nein. Zusätzlich braucht ihr beobachtbare Zustände, Diagnosepfade, Pause, Wiederaufnahme und Zuständigkeit für offene Entscheidungen.
Wie testen wir Vertretbarkeit?
Eine berechtigte Person ohne Entwicklerwissen bearbeitet einen Normal- und Fehlerfall allein anhand der Anleitung. Beobachtete Lücken werden gezielt geschlossen.
Wie lässt sich „Mit Zweck und erkennbaren Zuständen beginnen“ praktisch umsetzen?
Beschreibt knapp, was der Ablauf erledigt, welche Ergebnisse er liefern darf und welche Aktionen ausgeschlossen sind. Zeigt den normalen Startpunkt und die sichtbaren Zustände bis zur bestätigten Fertigstellung. Ein Status wie läuft genügt nicht, wenn niemand erkennen kann, ob bereits externe Änderungen stattgefunden haben.
Was ist bei „Zugriff und Abhängigkeiten ohne Geheimnisse dokumentieren“ besonders wichtig?
Listet benötigte Systeme, erlaubte Rollen, Quellenbestände und technische Abhängigkeiten auf. Beschreibt, wo berechtigte Betreiber ihren Zugriff erhalten und wie dessen Funktion geprüft wird. Schreibt keine Zugangsdaten in die Anleitung.
