Risk-by-Design: Thresholds, Eskalation, Auditability

Sobald KI mehr tut als zu antworten, brauchst du Risk-by-Design.
Der Kern ist simpel:
Definiere, wann ein System handeln darf und wann es eskalieren muss.

Viele Unternehmen investieren viel in Modelle und Plattformen, aber vergessen die entscheidende Zeile in ihrer Roadmap: Schwellenwerte.
Schwellenwerte (Thresholds) verbinden Modellverhalten mit operativer Verantwortung. Sie beschreiben, ab welcher Confidence oder unter welchen Bedingungen eine Aktion erlaubt ist.

Beispiel:
Ein System darf eine Priorisierung vorschlagen, aber wenn Daten widersprüchlich sind oder der potenzielle Schaden hoch ist, muss es eskalieren. Ohne solche Regeln bleibt Verhalten situativ und nicht steuerbar.

Risk-by-Design besteht aus vier Bausteinen:
1) Thresholds: act vs. escalate

• Was ist „Unsicherheit“? (z. B. fehlende Daten, widersprüchliche Signale)
• Was ist „Risiko“? (z. B. Kosten, Service-Level, Compliance)
• Welche Schwellen trennen Autonomie von Eskalation?

2) Eskalation: Wer entscheidet bei Unsicherheit?
Eskalation ist nur dann wirksam, wenn sie operationalisiert ist:

• An wen geht sie?
• In welcher Form?
• Mit welchem Kontext?

Ein gutes Eskalationspaket enthält:

• Kontext (Was ist passiert?)
• Auswirkungen (Was steht auf dem Spiel?)
• Optionen (Welche Alternativen gibt es?)
• Empfehlung (Was würde das System tun?)

3) Override & Stop Mechanisms
Ein System darf nur dann autonom handeln, wenn es stopbar ist.

• Wer darf stoppen?
• Wie wird zurückgerollt?
• Wie wird verhindert, dass ein Agent wiederholt dieselben Fehler macht?

Overrides sind kein Zeichen von Misstrauen, sondern die Voraussetzung für produktive Autonomie.

4) Auditability / Nachvollziehbarkeit

In Enterprise-Umgebungen reicht „das Modell sagt es“ nicht. Akzeptanz entsteht, wenn Entscheidungen nachvollziehbar sind: Datenbasis, Regeln/Policies, Alternativen, sowie ein Log der Aktionen. Auditability ist nicht nur Compliance, sondern ein Trust-Mechanismus.
Ein typischer Fehler ist, Risk-by-Design als großen Governance-Block zu planen. Besser ist ein inkrementeller Ansatz:

• Beginne mit einem Use Case
• definiere ein kleines Set an Thresholds, einen Eskalationsweg und Logging.
• Lerne daraus.
• Erweitere die Regeln, wenn Autonomie wächst.

Wichtig ist dabei die Unterscheidung zwischen „Suggestion“ und „Action“. Vorschläge benötigen weniger Leitplanken. Aktionen benötigen zwingend Thresholds, Eskalation und Auditability.

Fazit Teil 2:
Risk-by-Design ist die operative Übersetzung von „Responsible AI“. Ohne Schwellenwerte, Eskalation, Overrides und Auditability bleibt Autonomie entweder Pilot oder Risiko.

Diskussionsfrage: Wie definiert ihr heute „Unsicherheit“, und wer entscheidet, wenn sie auftritt?