Was soll ein AI-System tun, wenn es etwas nicht weiß?

Die gefährlichste Antwort einer Automation ist oft: „Sieht gut aus“

Ein AI-System soll eine Rechnung prüfen, einen Supportfall priorisieren, einen Lieferanten freigeben oder einen Vertrag auf kritische Klauseln untersuchen. Das Modell liefert kein eindeutiges Ergebnis: Die Quelle ist nicht erreichbar, ein Dokument ist unlesbar, die Konfidenz liegt unter dem Schwellwert oder ein vorgeschalteter Prüfdienst antwortet mit Timeout.

Was passiert jetzt?

In vielen Automationen lautet die tatsächliche Antwort: Der Prozess läuft weiter.

Nicht, weil jemand bewusst entschieden hätte, dass das vertretbar ist. Sondern weil null, ein Timeout, ein leerer Wert oder ein nicht behandelter Ausnahmefall im Code, im Workflow-Tool oder in einer API-Integration wie „kein Einwand“ behandelt wird.

Das ist Fail-open: Wenn eine Prüfung nicht erfolgreich durchgeführt werden kann, wird trotzdem durchgelassen.

Die Alternative ist Fail-closed: Wenn die Prüfung nicht erfolgreich durchgeführt werden kann, wird blockiert, zurückgewiesen oder an eine menschliche Instanz eskaliert.

Beides kann richtig sein. Beides kann erheblichen Schaden verursachen. Deshalb ist die Frage keine technische Implementierungsfrage am Rand, sondern eine Geschäftsentscheidung über Risiko.

Der dritte Zustand: nicht entschieden

Viele Prozessmodelle kennen nur zwei Zustände:

• Erfolg
• Fehler

Für kontrollierende Automationen reicht das nicht. Sie brauchen mindestens drei fachliche Ergebnisse:

Der dritte Zustand ist nicht dasselbe wie ein technischer Fehler. Ein technischer Fehler kann seine Ursache sein, aber auch fachliche Unsicherheit führt dorthin:

• Das Modell erkennt die Sprache nicht zuverlässig.
• Ein hochgeladenes PDF enthält nur unvollständige Scans.
• Die Datenbasis ist älter als die erlaubte Aktualität.
• Der Fall liegt außerhalb des trainierten oder freigegebenen Anwendungsbereichs.
• Zwei Prüfschritte widersprechen sich.
• Eine Regel ist nicht anwendbar, weil eine notwendige Information fehlt.

Wer diesen Zustand nicht explizit modelliert, trifft trotzdem eine Entscheidung. Meist entscheidet dann ein Default der eingesetzten Technologie.

Fail-open und fail-closed sind unterschiedliche Risikopositionen

Die Begriffe stammen aus Security und Systemdesign, gelten aber genauso für AI-gestützte Geschäftsprozesse.

Fail-open bedeutet: Wenn die Kontrolle ausfällt oder unsicher ist, darf der Vorgang weiterlaufen.

Fail-closed bedeutet: Wenn die Kontrolle ausfällt oder unsicher ist, darf der Vorgang nicht automatisch weiterlaufen.

Wichtig ist die präzise Formulierung: Es geht nicht darum, ob das gesamte System „offen“ oder „geschlossen“ ist. Es geht um eine konkrete Entscheidung an einem konkreten Kontrollpunkt.

Ein Beispiel aus dem Einkauf:

1. Eine Rechnung wird automatisch extrahiert.
2. Beträge, Lieferant und Bestellnummer werden abgeglichen.
3. Ein AI-Modell bewertet Freitextpositionen.
4. Der Prozess entscheidet über Zahlung oder Klärung.

Fällt die AI-Bewertung aus, kann die fachlich richtige Strategie je nach Rechnung unterschiedlich sein:

• Bei einer wiederkehrenden Rechnung eines bekannten Versorgers unterhalb einer definierten Grenze kann ein Durchlauf mit nachgelagerter Stichprobe angemessen sein.
• Bei einer neuen Bankverbindung oder einer Zahlung oberhalb eines Schwellenwerts sollte der Vorgang stoppen und zur Prüfung gehen.

Die technische Ursache ist in beiden Fällen identisch: Das Modell konnte nicht entscheiden. Die geschäftliche Konsequenz ist bewusst verschieden.

Die falsche Frage: „Wie behandeln wir Exceptions?“

Teams diskutieren Fail-open und fail-closed häufig erst bei der Fehlerbehandlung:

• Was tun wir bei HTTP 500?
• Sollen wir bei Timeout dreimal wiederholen?
• Was passiert, wenn das Modell kein JSON liefert?

Das sind notwendige technische Fragen, aber sie beantworten nicht die fachliche Kernfrage:

Welche Handlung darf erfolgen, wenn die erforderliche Evidenz nicht vorliegt?

Ein Retry kann einen temporären Ausfall beheben. Er kann aber keine fehlende Quelle, eine unlesbare Eingabe oder eine niedrige Modellkonfidenz in eine belastbare Freigabe verwandeln.

Deshalb sollte ein Prozess nicht von Exceptions, sondern von Entscheidungszuständen und erlaubten Folgeschritten ausgehen. Technische Fehler werden dann in fachliche Zustände übersetzt, statt versehentlich in einen Erfolgszweig zu fallen.

Eine einfache Entscheidungslogik für die Praxis

Für jeden automatisierten Kontrollpunkt sollten Teams vier Fragen beantworten.

1. Was ist die geschützte Entscheidung?

Nicht „Was prüft das Modell?“, sondern „Welche irreversible oder risikobehaftete Handlung hängt daran?“

Beispiele:

• Zahlung auslösen
• Zugang gewähren
• Vertrag versenden
• Kunde ablehnen
• Ticket schließen
• Daten löschen
• Artikel veröffentlichen

Je konkreter die Folgehandlung beschrieben ist, desto besser lässt sich das Risiko bewerten.

2. Was kostet ein falsches Durchlassen?

Das ist der Schaden eines False Negative beziehungsweise eines zu großzügigen Fail-open:

• Betrug wird ausgezahlt.
• Eine sanktionierte Partei wird beliefert.
• Ein Angreifer erhält Zugriff.
• Eine unzulässige Entscheidung trifft einen Kunden.
• Falsche Informationen werden veröffentlicht.

Der Schaden umfasst nicht nur Geld. Auch regulatorische Folgen, Reputationsschäden, operative Nacharbeit und die Belastung betroffener Personen gehören dazu.

3. Was kostet ein falsches Blockieren?

Das ist der Schaden eines zu strengen Fail-closed:

• Umsatz verzögert sich.
• Ein Kunde kann einen legitimen Vorgang nicht abschließen.
• Ein Produktionsprozess steht.
• Ein Supportfall bleibt liegen.
• Mitarbeitende umgehen die Kontrolle über Schattenprozesse.

Fail-closed ist nicht automatisch „sicher“. Ein dauerhaft blockierender Prozess kann ebenfalls geschäftskritisch sein.

4. Gibt es eine sichere Zwischenbehandlung?

Die Wahl muss selten zwischen „vollautomatisch freigeben“ und „vollständig abbrechen“ liegen. Häufig ist eine dritte Aktion besser:

• in eine manuelle Prüfung routen,
• nur vorläufig freigeben,
• eine Zahlung bis zu einer Grenze erlauben,
• Zugriff mit reduzierten Rechten gewähren,
• eine zweite, unabhängige Prüfung starten,
• den Vorgang speichern und später erneut bewerten.

In der Praxis ist Fail-to-review oft das bessere Muster als ein pauschales Fail-closed. Der Prozess wird nicht als Erfolg fortgesetzt, aber der Geschäftsvorgang geht kontrolliert weiter.

Eine Risikomatrix ersetzt Bauchgefühl nicht, macht es aber sichtbar

Eine kompakte Matrix hilft, die Entscheidung mit Fachbereich, Compliance, Security und Betrieb gemeinsam zu treffen:

Diese Matrix ist keine Freigabeformel. Sie zwingt aber dazu, die implizite Annahme offenzulegen: Welcher Fehler ist im konkreten Prozess weniger akzeptabel?

Bei AI-Systemen kommt ein weiterer Punkt hinzu: Die Unsicherheit ist nicht einheitlich. Ein Modell kann bei klaren Standardfällen sehr zuverlässig und bei seltenen, mehrdeutigen oder sprachlich ungewöhnlichen Fällen deutlich schwächer sein. Eine einheitliche Default-Strategie für alle Fälle ist daher meist zu grob.

Beispiel: AI-gestützte Dokumentenprüfung

Nehmen wir ein System, das Vertragsdokumente vor dem Versand prüft. Es soll feststellen, ob eine Freigabe für kritische Klauseln vorliegt.

Ein naiver Workflow könnte so aussehen:

if ai_check(document) == "critical":
    block()
else:
    send()

Das Problem: Was liefert ai_check() bei Timeout, fehlendem Dokument, ungültigem Modelloutput oder niedriger Konfidenz? Wenn in all diesen Fällen nicht "critical" zurückkommt, wird versendet. Das System ist implizit fail-open.

Eine belastbarere Modellierung trennt Ergebnis und Entscheidungsfähigkeit:

check = ai_check(document)
 
if check.status == "passed":
    send()
elif check.status == "failed":
    block_and_request_correction()
elif check.status == "undetermined":
    route_to_legal_review()
else:
    raise_process_incident()

Entscheidend ist nicht die Syntax. Entscheidend ist, dass undetermined ein fachlich gültiger und beobachtbarer Zustand ist.

Für die Freigabe sollten außerdem mindestens dokumentiert werden:

• welche Eingaben geprüft wurden,
• welche Modell- und Prompt-Version verwendet wurde,
• welche Regeln und Schwellenwerte galten,
• welche Evidenz zur Entscheidung vorlag,
• warum der Fall als unentschieden eingestuft wurde,
• welche Person oder Rolle anschließend entschieden hat.

Das ist nicht nur für Auditierbarkeit relevant. Ohne diese Daten lässt sich später kaum unterscheiden, ob ein Problem vom Modell, von der Datenqualität, von einer externen Abhängigkeit oder vom Prozessdesign stammt.

Architekturprinzipien für robuste Automationen

Fachliche Zustände von technischen Zuständen trennen

HTTP 429, timeout, invalid JSON und confidence < 0.8 sind technische oder modellnahe Signale. Sie sollten nicht direkt die Geschäftslogik bestimmen.

Übersetzen Sie sie in einen begrenzten fachlichen Zustandssatz, etwa:

• approved
• rejected
• review_required
• not_evaluable

So bleibt die Prozessentscheidung verständlich, testbar und unabhängig vom jeweiligen Modellanbieter.

Keine Wahrheit aus Abwesenheit ableiten

„Kein Treffer gefunden“ ist nur dann ein positives Ergebnis, wenn tatsächlich vollständig und mit aktueller Datenbasis gesucht wurde.

Das gilt für:

• Sanktions- und Watchlist-Prüfungen,
• Betrugserkennung,
• Sicherheits-Scans,
• Vertrags- und Compliance-Prüfungen,
• Berechtigungsentscheidungen.

Ein leeres Ergebnis ohne bestätigte erfolgreiche Prüfung ist kein Freigabesignal.

Zeitgrenzen und Datenfrische definieren

Ein Ergebnis kann formal vorhanden und trotzdem nicht mehr verwendbar sein. Legen Sie fest:

• Wie alt darf eine Datenquelle sein?
• Wie lange gilt eine AI-Bewertung?
• Wann muss nach einem Retry eskaliert werden?
• Welche Fälle dürfen asynchron nachbearbeitet werden?

Ohne diese Regeln wird aus einer temporären Störung leicht eine stille Dauerfreigabe.

Freigaben begrenzen

Wenn Fail-open fachlich notwendig ist, begrenzen Sie die Wirkung:

• Betrags- oder Volumenlimits,
• reduzierte Berechtigungen,
• zeitlich begrenzte Freigaben,
• höhere Logging-Tiefe,
• verpflichtende nachgelagerte Prüfung,
• automatische Rückabwicklung, soweit möglich.

Eine begrenzte Freigabe ist etwas anderes als ein uneingeschränktes Durchlassen.

Den Pfad für manuelle Prüfung gestalten

„Dann prüft eben jemand“ ist kein Architekturkonzept. Ein Review-Pfad braucht Eigentümer, Priorität, SLA, Kontext und eine Rückmeldung in den Prozess.

Wenn ein Reviewer erst Dokumente zusammensuchen, Modellantworten interpretieren und Fachwissen improvisieren muss, wird die Automation lediglich in eine schlecht skalierende Warteschlange verlagert.

AI Governance beginnt vor dem Modell

AI Governance wird oft auf Modellfreigaben, Datenschutzprüfungen oder Richtlinien zur Prompt-Nutzung reduziert. Diese Elemente sind wichtig, greifen aber zu kurz, wenn die Automationsarchitektur Ungewissheit nicht korrekt behandelt.

Governance zeigt sich an konkreten Prozessfragen:

• Für welche Entscheidungen darf ein Modell eine automatische Freigabe auslösen?
• Welche Mindestqualität muss die Eingabe erfüllen?
• Welche Konfidenz oder welche Evidenz ist ausreichend – und wer hat das festgelegt?
• Wann ist eine menschliche Prüfung zwingend?
• Wer verantwortet die Risiken eines Durchlassens?
• Wie wird sichtbar, dass die Zahl unentschiedener Fälle steigt?

Diese Fragen gehören in die Prozess- und Risikoentscheidung, nicht nur in das technische Backlog.

Besonders problematisch sind Systeme, die eine AI-Komponente nur als Komfortfunktion einführen und später schrittweise an kritische Aktionen koppeln. Erst werden Texte zusammengefasst, dann priorisiert das Modell Tickets, später schließt es Tickets automatisch und irgendwann löst ein Score eine Zahlung oder Sperrung aus. Mit jeder Stufe ändert sich die Schadensklasse. Die Fail-open-/Fail-closed-Entscheidung muss dann neu bewertet werden.

Was Teams konkret beschließen sollten

Für jeden relevanten automatisierten Prozess empfehle ich eine kurze, versionierte Entscheidungsnotiz. Sie muss kein umfangreiches Governance-Dokument sein. Eine Seite genügt, wenn sie die richtigen Punkte festhält:

1. Entscheidung und Folgehandlung: Was wird automatisch ausgelöst?
2. Kontrollziel: Welches Risiko soll die Prüfung reduzieren?
3. Zulässige Ergebnisse: Positiv, negativ, unentschieden – klar definiert.
4. Default bei Unentschiedenheit: Durchlassen, blockieren oder eskalieren.
5. Begründung: Welche Risiken wurden gegeneinander abgewogen?
6. Begrenzungen: Limits, Berechtigungen, Fristen und Kompensationsmaßnahmen.
7. Verantwortung: Wer besitzt die fachliche Entscheidung und wer den technischen Betrieb?
8. Messgrößen: Quote unentschiedener Fälle, Eskalationszeit, Fehlentscheidungen, Overrides und Ausfallraten.
9. Review-Anlass: Wann wird die Entscheidung neu bewertet, etwa bei Modellwechsel, Prozessänderung oder Incident?

Damit wird aus einem impliziten Default eine überprüfbare Geschäftsregel.

Fazit

Ein System, das etwas nicht weiß, hat nicht automatisch Erfolg und nicht automatisch Fehler. Es befindet sich in einem Zustand der Ungewissheit.

Ob ein Prozess in diesem Zustand weiterlaufen darf, ist eine Entscheidung über Risiko, Kundenwirkung, Compliance und Betrieb. Technik implementiert diese Entscheidung; sie sollte sie nicht stillschweigend treffen.

Die praktische Konsequenz ist einfach:

• Modellieren Sie „nicht entschieden“ explizit.
• Legen Sie Fail-open, Fail-closed oder Eskalation pro Kontrollpunkt fest.
• Begrenzen Sie die Wirkung dort, wo Durchlassen notwendig ist.
• Messen Sie, wie oft und warum das System keine belastbare Entscheidung treffen kann.

Dann wird AI Governance konkret: nicht als Richtlinie über Modelle, sondern als nachvollziehbares Design der Entscheidungen, die Ihre Automation im Unsicherheitsfall trifft.