Wann sollte ein Mensch eine KI-Aktion freigeben?

Benennen Sie die Entscheidung, die die Person trifft.

Ein Button mit der Aufschrift «Freigeben» sagt der prüfenden Person nicht, was sie autorisiert. Nimmt sie einen Entwurf an, stimmt sie einer Klassifizierung zu, erlaubt sie eine externe Nachricht oder gibt sie eine Änderung an einem Geschäftsdatensatz frei? Diese Entscheidungen haben unterschiedliche Folgen und gehören womöglich zu unterschiedlichen Personen.

Trennen Sie zuerst Vorbereitung von Ausführung. Ein Workflow kann Dokumente sammeln, Pflichtfelder prüfen und eine Empfehlung entwerfen, bevor jemand eine folgenreiche Aktion freigibt. Die Freigabe sollte unmittelbar vor der Aktion stehen, die sie kontrolliert; weitere Prüfungen des empfangenden Systems bleiben bestehen.

Bei einer Offerte könnte die Entscheidung lauten: diese Version zum Versand an diesen Empfänger zu diesen Bedingungen freigeben. Bei Document Intelligence könnte sie lauten: dieses Vergleichspaket als bereit für die rechtliche Prüfung akzeptieren. Die Annahme eines Pakets darf nicht stillschweigend zur Vertragsunterzeichnung werden. Bei Process Intelligence bestätigt die Freigabe eines Leitfadens dessen geprüften Inhalt; sie gibt der lesenden Person weder Ausgabenbefugnis noch Zugriff auf ein ERP-System.

Geben Sie der prüfenden Person ein Nachweispaket.

Ein guter Prüfbildschirm verringert den Aufwand für die Kontrolle des Ergebnisses, ohne Unsicherheit zu verbergen. Stellen Sie die vorgeschlagene Aktion neben die Nachweise, die sie stützen. Zeigen Sie die ursprüngliche Eingabe, die relevanten Quellenreferenzen, die Änderungen gegenüber der Vorversion und alle fehlgeschlagenen Prüfungen.

Das Paket sollte diese Fragen beantworten:

• Was genau geschieht, wenn ich freigebe?
• Welchen Datensatz, welches Dokument, welchen Empfänger oder welche Berichtsperiode betrifft das?
• Welche Quellenversionen wurden verwendet, und sind sie für diese Entscheidung aktuell genug?
• Was hat der Workflow berechnet, und was hat die KI abgeleitet oder entworfen?
• Welche Grenzen, Ausnahmen oder ungelösten Konflikte bleiben bestehen?
• Was geschieht, wenn ich ablehne oder Änderungen verlange?

Machen Sie den Konfidenzwert eines Modells nicht zum einzigen Nachweis. Eine selbstsichere Antwort kann trotzdem die falsche Quelle verwenden oder die beabsichtigte Aktion missverstehen. Muss die prüfende Person mehrere Systeme durchsuchen, um die Grundlage jedes Vorschlags zu rekonstruieren, hat die Freigabeoberfläche die Arbeit verlagert statt erleichtert.

Ein Beispiel ist die Document-Intelligence-Demo: Der Vergleich identifiziert Quellklauseln und Regelprüfungen vor der Prüfung. Er ist ein synthetisches Beispiel für ein Paket, keine Rechtsberatung und keine Behauptung, dass ein echter Vertrag geprüft wurde.

Binden Sie die Freigabe an Person, Version und Aktion.

Ein Freigabeprotokoll braucht genug Kontext, damit es später nicht auf eine andere Aktion angewendet werden kann. Definieren Sie in einer echten Implementierung die befugte Rolle, die genaue vorgeschlagene Aktion, die Ein- oder Ausgabeversion und ein allfälliges Ablaufdatum. Nutzen Sie die Identitäts- und Zugriffskontrollen des Kunden, um festzulegen, wer freigeben darf; der Besitz eines Links allein sollte kein Freigaberecht bedeuten.

Ändert sich der Vorschlag nach der Freigabe, deckt die alte Entscheidung den geänderten Vorschlag nicht mehr ab. Ändert sich ein Empfänger, prüfen Sie erneut. Werden Quelldaten aktualisiert, entscheiden Sie, ob diese Änderung die frühere Prüfung entwertet. Diese Regeln sollten explizit sein und nicht von einem KI-Schritt erschlossen werden.

Auch die Ausführung braucht eine eigene Kontrolle. Ein Freigabeereignis und eine erfolgreiche Aktion sind verschiedene Datensätze. Ein Netzwerk-Timeout nach dem Senden einer Nachricht beweist nicht, dass die Nachricht nicht gesendet wurde. Verwenden Sie eine Vorgangskennung und den vom empfangenden System unterstützten Abgleich- oder Idempotenzmechanismus, um eine folgenreiche Aktion nicht blind zu wiederholen.

Legen Sie fest, was geschieht, wenn niemand freigibt.

Eine unbeantwortete Anfrage sollte gemäss der vereinbarten Regel offen bleiben oder verfallen. Sie darf nicht zur Freigabe werden, wenn ein Timer abläuft. Eine abgelehnte Aktion sollte einen Grund und einen klaren nächsten Schritt haben: überarbeiten, an eine andere verantwortliche Rolle weiterleiten oder stoppen.

Die Eskalation verdient dieselbe Sorgfalt. Eine Erinnerung zu senden ist etwas anderes, als das Freigaberecht weiterzugeben. Ist eine Stellvertretung erlaubt, definieren Sie diese Rolle im Voraus. Bewahren Sie den ursprünglichen Kontext, wenn ein Fall zwischen Personen wechselt, damit die neue prüfende Person dieselben offenen Punkte sieht.

Bei einem nicht verfügbaren Freigabedienst oder einer ungültigen Antwort stoppen Sie die kontrollierte Aktion und behalten genug Zustand für den Wiederanlauf. Bitten Sie niemanden, ein altes Paket freizugeben, wenn bereits neuere Eingaben eingetroffen sind. Halten Sie klar auseinander: auf einen Menschen warten, einen technischen Schritt wiederholen und ein unsicheres Ausführungsergebnis untersuchen.

Testen Sie Versuche, die Freigabe zu umgehen.

Der Idealfall ist nur ein Fall. Abnahmetests sollten die Situationen abdecken, in denen der Workflow die Fortsetzung verweigern muss:

1. Eine prüfende Person lehnt die Aktion ab; die Ausführung bleibt blockiert.
2. Die Freigabe läuft vor der Ausführung ab; eine neue Entscheidung ist nötig.
3. Die Eingabe ändert sich nach der Prüfung; die frühere Freigabe kann nicht wiederverwendet werden.
4. Dieselbe Freigabenachricht trifft zweimal ein; die Aktion wird nicht dupliziert.
5. Jemand ohne die passende Rolle versucht freizugeben; der Versuch wird abgelehnt.
6. Ein System läuft nach einer versuchten Aktion in ein Timeout; der Wiederanlauf prüft das Ergebnis, bevor er es erneut versucht.
7. Der Workflow wird erneut abgespielt; der alte Freigabezustand wandert nicht in den neuen Durchlauf.

Die lokalen Demos testen das Verhalten bei Pause, Freigabe und Reset. Sie authentifizieren keine echten Freigebenden und nutzen nicht das Berechtigungsmodell eines Kunden. Dafür braucht es Integrationstests gegen die gewählten Systeme und den Identitätsanbieter. Behalten Sie diese Unterscheidung in den Nachweisen, mit denen Sie über die Einführung entscheiden.

Machen Sie die Prüfung verhältnismässig und die Aufmerksamkeit der Person wert.

Eine Freigabe für jeden harmlosen Formatierungsschritt zu verlangen, erzeugt eine Warteschlange von Klicks. Für extern sichtbare Aktionen keine zu verlangen, erzeugt ein anderes Problem. Bündeln Sie Vorbereitungsarbeit mit geringen Folgen, und setzen Sie einen klaren Freigabeschritt vor die bedeutsame Entscheidung.

Messen Sie, wie lange die Prüfung dauert, wie oft prüfende Personen den Entwurf ändern und wie viele Fälle eskaliert werden müssen. Hohe Freigabequoten allein zeigen nicht, dass der Prozess funktioniert: Menschen geben womöglich ohne ausreichende Nachweise frei. Prüfen Sie stichprobenartig die Qualität der Entscheidungen, nicht nur den Durchsatz.

In grösseren Unternehmen kann eine Aufteilung der Prüfverantwortung sinnvoll sein. Eine fachlich prüfende Person bestätigt die Richtigkeit, während eine befugte Person aus dem Geschäft die Freigabe erteilt. In kleineren Teams übernimmt vielleicht dieselbe Person beide Rollen; die beiden Entscheidungen sollten trotzdem nachvollziehbar bleiben.

Das Ziel ist eine Oberfläche, die klar zeigt, wer was freigeben darf. Lesen Sie die Engineering-Grundsätze, das Beispiel Process Intelligence oder nutzen Sie den Workflow Fit Checker – er zeigt, wo Ihre eigene Freigabeschritt noch unklar ist.