Die vorherigen Beiträge haben unterschiedliche Governance-Fragen behandelt. Was gilt? Welches Wissen darf zählen? Ist die Grundlage ausreichend? Ist der Output für diese Verwendung gültig? Wer verfügt über Autorität? Sind die Bedingungen beim Commit noch gültig? Doch all diese Fragen teilen eine gemeinsame Anforderung: Jede Governance-Bedingung mit realen Konsequenzen braucht einen verantwortlichen Owner – nicht „Governance“ im abstrakten Sinn. Ein Fachverantwortlicher muss dafür einstehen, was gilt. Ein Wissensverantwortlicher muss die Autorität von Quellen verantworten. Ein Fachverantwortlicher muss die Kriterien für eine ausreichende Entscheidungsgrundlage festlegen. Ein Business Owner muss definieren, welche Verwendung zulässig ist. Eine institutionelle Rolle muss die Entscheidungs- oder Ausführungsautorität tragen. Und jemand muss den gestoppten Fall verantworten, wenn die Voraussetzungen für ein Fortfahren nicht mehr erfüllt sind. Diese Verantwortung muss festgelegt sein, bevor der Stopp eintritt – gemeinsam mit der Autorität und dem Lösungsweg, die für die Klärung erforderlich sind. Dieser letzte Punkt ist entscheidend. Governance wird nicht dadurch real, dass ein System stoppen kann. Sie wird real, wenn Lösungsweg, Reaktionsfenster und Kosten dieses Stopps im Voraus festgelegt wurden. Verzögerung, manuelle Arbeit und Nicht-Entscheidung sind keine technischen Nebeneffekte. Sie sind Konsequenzen, die das Betriebsmodell bewusst tragen muss. Über all dem steht eine letzte Anforderung: Zuordenbarkeit. Bei einem Ergebnis mit realen Konsequenzen sollte die Organisation feststellen können, wer die relevanten Bedingungen definiert hat, welche Versionen galten, wer für ungeklärte Fälle zuständig war und wer letztlich autorisiert hat, was geschehen ist. Wenn sich das nicht rekonstruieren lässt, wird Verantwortlichkeit zu nachträglicher Spekulation. Die praktische Lehre aus dieser Serie lässt sich deshalb vielleicht so zusammenfassen: Eine zentrale AI-Governance-Funktion muss nicht jede fachliche Antwort kennen. Sie muss sicherstellen, dass jede Bedingung mit realen Konsequenzen einen legitimen Owner hat, jede ungeklärte Bedingung einen definierten Zielpunkt besitzt und jedes folgenreiche Ergebnis eindeutig zugeordnet werden kann.

Ein Fall kann alle vorherigen Prüfungen bestanden haben und unmittelbar vor der Ausführung trotzdem unzulässig werden. Denn Gültigkeit ist nicht zeitlos. Die anwendbare Regel kann weiterhin klar sein. Die Evidenz kann ausreichend gewesen sein. Der Output kann für seinen vorgesehenen Zweck gültig gewesen sein. Die Autorität kann bestanden haben. Doch der relevante Zustand kann sich verändern, bevor eine reale Konsequenz eintritt. Eine um 14:00 Uhr genehmigte Zahlung kann um 16:00 Uhr nicht mehr zulässig sein, wenn sich zwischenzeitlich eine relevante Bedingung geändert hat. Die letzte Governance-Frage vor Eintritt der Konsequenz lautet deshalb nicht nur, ob die Handlung früher gültig war. Sie lautet: Was muss noch gelten, wenn die Handlung tatsächlich ausgeführt wird? Was muss vorhanden sein? Eine klare Definition der Bedingungen, die im Moment der Konsequenz weiterhin gültig sein müssen – und der Veränderungen, die eine erneute Prüfung des Falls erforderlich machen. Wer verantwortet den Inhalt? Der operative oder Prozessverantwortliche, der für die Konsequenz der Handlung verantwortlich ist. Governance sollte verlangen, dass diese Bedingungen und Verantwortlichkeiten explizit gemacht werden. Sie sollte nicht jede operative Bedingung zentral festlegen. Wer ist als zuständige Instanz benannt, bis wann muss sie reagieren und über welche Autorität verfügt sie? Die operative Rolle, die für die Konsequenz verantwortlich ist, muss im Voraus festgelegt, innerhalb des relevanten Ausführungsfensters erreichbar und autorisiert sein, die veränderte Bedingung neu zu bewerten oder zu bestätigen, dass die Ausführung nicht fortgesetzt werden darf. Welche Kosten entstehen, wenn der Prozess nicht fortgesetzt wird – und wo werden diese Kosten getragen? Ein gestoppter Commit kann zu Verzögerungen bei Abwicklung oder Settlement, SLA-Verletzungen, unterbrochenen Abläufen oder verlorener Automatisierung führen. Das Betriebsmodell muss vorab festlegen, wo diese Folgen getragen werden. Andernfalls wird die frühere Freigabe zum Weg des geringsten Widerstands.

Ein System kann technisch in der Lage sein, etwas zu tun, ohne irgendein Recht dazu zu haben. Das klingt selbstverständlich. Bei agentischen Systemen kann diese Unterscheidung jedoch leicht verloren gehen. Tool-Zugriff ist keine Autorität. Eine Modellempfehlung ist keine Autorität. Und auch ein Mensch irgendwo im Workflow beantwortet die Frage nicht, solange dieser Mensch nicht tatsächlich über das erforderliche Mandat verfügt. Welche Autorität erforderlich ist, hängt außerdem vom vorgesehenen Verwendungszweck ab. Für Triage kann ein anderes Mandat genügen als für eine verbindliche Ablehnung. Was muss vorhanden sein? Eine explizite Definition von Entscheidungsrechten, Ausführungsrechten, Geltungsbereich, Delegationsgrenzen und den Bedingungen, unter denen Autorität gültig ist. Wer verantwortet den Inhalt? Der institutionelle Mandatsträger oder Prozessverantwortliche, der legitim berechtigt ist, diese Rechte festzulegen oder zu delegieren. AI Governance sollte verlangen, dass Autorität explizit gemacht wird. Sie sollte das Mandat nicht selbst erzeugen. Autorität muss deshalb als eigenständige institutionelle Verantwortung behandelt werden. Wer ist als zuständige Instanz benannt, bis wann muss sie reagieren und über welche Autorität verfügt sie? Der Mandatsträger oder eine autorisierte delegierende Rolle muss im Voraus benannt sein, innerhalb des erforderlichen Prozessfensters erreichbar sein und entweder selbst entscheiden oder die benötigte Autorität legitim übertragen können. Welche Kosten entstehen, wenn der Prozess nicht fortgesetzt wird – und wo werden diese Kosten getragen? Fehlende Autorität führt zu Wartezeiten, manuellen Eingriffen und geringerer Autonomie agentischer Systeme. Der Prozessverantwortliche muss festlegen, wo diese Kosten getragen werden. Sie dürfen nicht dadurch vermieden werden, dass Tool-Zugriff stillschweigend als Berechtigung behandelt wird. Was muss im Nachhinein eindeutig zugeordnet werden können? Wer die relevante Autorität für welche Entscheidung oder Handlung und innerhalb welchen Geltungsbereichs innehatte – und wer diese Autorität erteilt oder verändert hat.

Ein Ergebnis kann gut begründet sein und trotzdem ungeeignet für den Zweck, für den jemand es verwenden möchte. Genau darin liegt der Unterschied zwischen epistemischer Suffizienz und Output-Gültigkeit. Epistemische Suffizienz fragt: Gab es eine ausreichende Grundlage für die Schlussfolgerung? Output-Gültigkeit fragt: Ist diese Schlussfolgerung geeignet, für diesen konkreten Zweck verwendet zu werden? Derselbe KI-Output kann für eine Triage vollkommen akzeptabel und für eine verbindliche Entscheidung völlig ungeeignet sein. Eine Schadensbewertung kann beispielsweise gut genug sein, um einen Fall für eine menschliche Prüfung zu priorisieren – aber nicht gut genug, um einen Anspruch abzulehnen. Genau hier stößt eine generische Freigabe an ihre Grenzen. Was muss vorhanden sein? Explizite Grenzen dafür, wie unterschiedliche Klassen von Outputs verwendet werden dürfen. Wer verantwortet den Inhalt? Der Business- oder Fachverantwortliche, der für die Konsequenz dieser Verwendung verantwortlich ist. AI Governance sollte verlangen, dass diese Grenzen explizit festgelegt werden. Sie sollte sie nicht zentral definieren. Wer ist als zuständige Instanz benannt, bis wann muss sie reagieren und über welche Autorität verfügt sie? Die Rolle, die für eine Verwendung mit höherer Konsequenz autorisiert ist, muss im Voraus festgelegt sein, innerhalb des erforderlichen Reaktionsfensters erreichbar sein und entweder die weitergehende Entscheidung selbst treffen oder zusätzliche Prüfung verlangen können. Welche Kosten entstehen, wenn der Prozess nicht fortgesetzt wird – und wo werden diese Kosten getragen? Eine Verwendung mit höherer Konsequenz kann zusätzliche menschliche Prüfung, längere Bearbeitungszeiten oder weniger Automatisierung erfordern. Der Teil der Organisation, der diese weitergehende Verwendung wünscht, muss diese Kosten tragen. Wenn ein System nur für Triage qualifiziert ist, können die Kosten zusätzlicher menschlicher Prüfung nicht einfach wegdefiniert werden. Was muss im Nachhinein eindeutig zugeordnet werden können?

Sobald die anwendbare Struktur und die autoritativen Quellen geklärt sind, stellt sich eine weitere Frage: Wann ist die verfügbare Grundlage tatsächlich ausreichend, um sich darauf zu verlassen? Das kann ein zentrales AI-Governance-Team nicht für jeden Fachbereich festlegen. Eine Kreditentscheidung, eine Wartungsempfehlung und eine rechtliche Bewertung können völlig unterschiedliche Evidenzanforderungen haben. Der jeweilige Fachbereich muss definieren, was für den konkreten Anwendungsfall „ausreichend“ bedeutet. Modellevaluationen lösen dieses Problem nicht. Sie zeigen, wie ein System über einen Testdatensatz hinweg abschneidet. Sie sagen nicht, ob dieser konkrete Fall die Evidenz enthält, die diese konkrete Entscheidung voraussetzt. Was muss vorhanden sein? Explizite Kriterien für die Suffizienz der Evidenz: erforderliche Quellen, Aktualität, Vollständigkeit, ungelöste Widersprüche oder andere fachspezifische Bedingungen. Wer verantwortet den Inhalt? Die Fachrolle, die für die Qualität der zugrunde liegenden Entscheidungsbasis verantwortlich ist. Governance sollte verlangen, dass diese Kriterien existieren und gepflegt werden. Sie sollte sie nicht zentral erfinden. Wer ist als zuständige Instanz benannt, bis wann muss sie reagieren und über welche Autorität verfügt sie? Die Fachrolle, die für die Entscheidungsgrundlage verantwortlich ist, muss im Voraus festgelegt sein, innerhalb des relevanten Entscheidungsfensters erreichbar sein und entweder fehlende Evidenz beschaffen, Widersprüche klären oder die Entscheidung treffen können, die das automatisierte System selbst nicht treffen durfte. Welche Kosten entstehen, wenn der Prozess nicht fortgesetzt wird – und wo werden diese Kosten getragen? Unzureichende Evidenz kann zusätzliche Datenerhebung, manuelle Prüfung, Verzögerung oder eine echte Nicht-Entscheidung erforderlich machen. Das Betriebsmodell muss festlegen, wo diese zusätzlichen Daten-, Prüf- und Verzögerungskosten getragen werden. Wenn sie nicht ausdrücklich akzeptiert werden, entsteht der Anreiz, das Modell die Lücke füllen zu lassen.