Ein KI-Agent braucht vor der Ausführung eine Genehmigung, wenn die vorgeschlagene Aktion eine Schwelle der Organisation für Befugnis, Tragweite, Umkehrbarkeit, Daten, Neuartigkeit, Konfidenz oder nachgelagerte Auswirkungen überschreitet. Routineaktionen innerhalb ausdrücklicher Befugnisse können zugelassen werden. Eine erlaubte Aktion mit einem Prüfsignal kann mit Warnung weiterlaufen. Eine folgenreiche Ausnahme muss für eine befugte Person anhalten. Eine verbotene, unbefugte, fehlerhafte, veraltete oder nicht überprüfbare Aktion muss gestoppt werden.
Dieser Leitfaden beantwortet die operative Frage branchenübergreifend. Er nutzt allow, warn, require_approval und block als praktisches Entscheidungsmodell für einzelne Agentenaktionen. Der Leitfaden zu Artikel 14 der KI-Verordnung behandelt die gesonderte, regulatorisch getriebene Aufgabe: die Umsetzung der Funktionen für menschliche Aufsicht, die Hochrisiko-KI-Systeme haben müssen. Dieser Leitfaden enthält allgemeine Informationen mit Stand 8. Oktober 2026 und ersetzt keine rechtliche, risikobezogene oder technische Beratung.
Die Genehmigungsregel mit vier Ergebnissen
Bewerten Sie die vorgeschlagene Seitenwirkung, bevor sie das Tool oder das nachgelagerte System erreicht. Wenden Sie jede relevante Regel an und behalten Sie das stärkste Ergebnis. Ein block lässt sich nicht durch eine zutreffende allow-Regel abschwächen, und eine erforderliche Genehmigung entfällt nicht, nur weil der Betrag unter einer bestimmten finanziellen Schwelle liegt.
Das Ergebnis beschreibt das Ausführungsverhalten. allow gibt die Aktion im Rahmen der aktuellen Befugnis frei. warn gibt sie frei und erzeugt eine festgelegte Nachbearbeitung. require_approval hält genau diese Aktion an, bis ein befugter Mensch entscheidet. block verhindert, dass die Aktion die kontrollierte Seitenwirkung erreicht.
| Ergebnis | Einsetzen, wenn | Ausführungsverhalten | Ausnahmen und Vorrang |
|---|---|---|---|
| allow | Die Aktion ist Routine, liegt innerhalb der delegierten Befugnis, hat geringe Tragweite, ist umkehrbar, nutzt freigegebene Daten, stammt aus einem bekannten Release und hat vollständigen Kontext. | Ausführen und den gewöhnlichen Aktions- und Policy-Datensatz aufbewahren. | Jeder Auslöser für block, Genehmigung oder Warnung hat Vorrang vor allow. Fehlender Identitäts-, Policy- oder Nachweiskontext führt nie zu allow. |
| warn | Die Aktion bleibt erlaubt und umkehrbar, liegt aber nahe an einer Schwelle, ist ungewöhnlich, neu beobachtet oder für eine Stichprobe der Qualitätssicherung ausgewählt. | Ausführen, das Signal erfassen und die festgelegte Nachbearbeitung anstoßen, ohne die Seitenwirkung anzuhalten. | require_approval verwenden, wenn eine Verzögerung nach der Ausführung eine wesentliche oder schwer umkehrbare Wirkung hinterließe. block verwenden, wenn Befugnis oder erforderlicher Kontext fehlen. |
| require_approval | Die Aktion ist wesentlich, schwer umkehrbar, berührt Rechte, liegt nahe an einer Befugnisgrenze, ist sensibel, neuartig, hat geringe Konfidenz oder kann eine erhebliche nachgelagerte Wirkung erzeugen. | Genau diese Aktion mit ihren Parametern anhalten. Erst fortsetzen, wenn eine berechtigte prüfende Person vor Ablauf genehmigt und der gebundene Kontext aktuell bleibt. | Eine prüfende Person kann keine verbotene Aktion genehmigen. Eine abgelaufene oder wesentlich geänderte Anfrage erfordert eine neue Bewertung und einen neuen Decision Request. |
| block | Die Aktion ist verboten, liegt außerhalb der Befugnis, zielt auf eine verbotene Datengrenze, besteht eine Pflichtkontrolle nicht, trägt ungültigen Kontext oder lässt sich nicht sicher bewerten oder nachweisen. | Vor der kontrollierten Seitenwirkung stoppen und den Grund erfassen. | Aktion oder Policy über den kontrollierten Änderungsprozess ändern. Break-Glass-Befugnis muss ein eigener, befristeter Policy-Pfad mit eigenen Nachweisen und nachträglicher Prüfung sein. |
Die sieben Genehmigungskriterien auf die Policy abbilden
Schwellenwerte gehören der Organisation, der die Aktion gehört. Beginnen Sie mit einem Aktionsinventar und definieren Sie prüfbare Bänder für alle sieben Kriterien. Der Betrag allein genügt nicht: Eine Berechtigungsänderung ohne Geldwert oder die Offenlegung eingeschränkter Daten kann mehr Risiko tragen als eine große, umkehrbare Überweisung zwischen kontrollierten Konten.
Halten Sie die Kriterien als getrennte Regeln. Ein kombinierter Score kann eine entscheidende Tatsache verdecken. Ein verbotenes Ziel muss blockiert bleiben, auch wenn alle anderen Kriterien nach Routine aussehen.
| Kriterium | Band für allow oder warn | Band für require_approval | Band für block |
|---|---|---|---|
| Risiko und betroffene Rechte | Geringe Tragweite im freigegebenen Zweck; warn bei einer begrenzten Auffälligkeit. | Wesentliche Folgen für Kunden, Beschäftigte, Patienten, Bürger, Sicherheit oder Compliance. | Verbotene Verwendung, inakzeptables Restrisiko oder Aktion außerhalb des freigegebenen Zwecks. |
| Betrag oder Exposition | Innerhalb einer ausdrücklichen Grenze je Aktion, je Tag und je Ziel. | Nahe an oder über einer Maker-Grenze, oder eine Schwelle für die Gesamtexposition wird überschritten. | Über absoluten Grenzen für Befugnis, Liquidität, Sanktionen oder Gegenparteien. |
| Umkehrbarkeit | Lesen, Entwurf, Simulation oder zuverlässig umkehrbare interne Aktualisierung. | Externe Kommunikation, Zahlung, Löschung, Einreichung, Berechtigungsänderung oder kostspieliger Ausgleichsweg. | Kein sicherer Rückweg unter den aktuellen Bedingungen. |
| Datensensibilität | Freigegebene Felder innerhalb der zugewiesenen Data Boundary. | Zugriff auf eingeschränkte Daten, Offenlegung, Export, Risiko der Re-Identifizierung oder neuer Empfänger. | Verbotene Kategorie, verbotenes Ziel, verbotener Zweck oder verbotene Region, oder fehlende Rechtsgrundlage. |
| Neuartigkeit und Änderung | Bekanntes Release, Tool, Route, Ziel und Betriebsmuster. | Hochlauf eines neuen Release, erste Nutzung eines Tools oder Ziels, ungewöhnliche Abfolge oder wesentliche Konfigurationsänderung. | Nicht freigegebene Komponente, unbekanntes Ziel oder nicht überprüfbare Version. |
| Konfidenz und Qualität der Nachweise | Validiertes Konfidenzband mit vollständigen, aktuellen Quellennachweisen. | Grenzwertiger Score, widersprüchliche Quellen, fehlende optionale Nachweise oder Signal außerhalb der Verteilung. | Pflichtnachweise fehlen, sind über die Policy hinaus veraltet, Eingabe ist fehlerhaft oder es gibt keine vertrauenswürdige Entscheidungsgrundlage. |
| Nachgelagerte Auswirkungen | Interne, begrenzte Wirkung ohne externe Verpflichtung. | Erzeugt eine rechtliche, finanzielle, sicherheitsbezogene, kundenbezogene, betriebliche oder systemübergreifende Verpflichtung. | Kaskadierende oder unkontrollierte Wirkung, verbotene Abhängigkeit oder Eindämmung lässt sich nicht bestätigen. |
Human in the loop, on the loop und in command
Diese Bezeichnungen beschreiben Betriebsmodelle. Sie sind nützliche Gestaltungsbegriffe und keine in der KI-Verordnung definierten Ergebnisse. Wählen Sie das Modell, das der verantwortlichen Person genug Zeit, Kontext und Befugnis für das Risiko der Aktion gibt.
| Modell | Rolle des Menschen | Geeignet für | Kontrolltest |
|---|---|---|---|
| Human in the loop | Entscheidet über eine bestimmte vorgeschlagene Aktion vor ihrer Seitenwirkung. | Folgenreiche, schwer umkehrbare, außergewöhnliche oder rechtsberührende Aktionen. | Die Aktion bleibt angehalten, bis die richtige Person den gebundenen Kontext prüft und vor Ablauf entscheidet. |
| Human on the loop | Überwacht eine begrenzte Ausführung und kann eingreifen, pausieren, rückgängig machen oder eskalieren. | Wesentliche, aber umkehrbare Tätigkeit mit zuverlässiger Erkennung und einem getesteten Eingriffsfenster. | Eine realistische Übung zeigt, dass die Person den Zustand erkennt und den sicheren Zustand erreicht, bevor der Schaden wesentlich wird. |
| Human in command | Verantwortet Mandat, Risikotoleranz, Policy, Betriebsgrenzen, Stoppbefugnis, Neustart und Rechenschaft. | Jedes eingesetzte Agentensystem, auch Systeme, deren Routineaktionen nicht einzeln geprüft werden. | Benannte Verantwortliche können Befugnisse ändern, das System aussetzen, eine Prüfung beauftragen, Beschwerden anhören und diese Entscheidungen nachweisen. |
Maker-Checker-Trennung für folgenreiche Aktionen
Der Maker erstellt oder verantwortet die Anfrage. Bei einer Agentenaktion sollte der Maker-Datensatz den Agenten, seinen Verantwortlichen, den anfragenden Prinzipal und genau die vorgeschlagene Seitenwirkung benennen. Der Checker ist eine andere, qualifizierte Person mit Befugnis für diese Aktionsklasse. Der Checker prüft die Nachweise und wählt genehmigen, ablehnen, Änderungen anfordern oder eskalieren.
Setzen Sie die Trennung zum Entscheidungszeitpunkt durch. Ein Gruppenname in einer Workflow-Definition beweist nicht, dass die handelnde Person berechtigt oder unabhängig war. Ermitteln Sie bei der Entscheidung die aktuelle Identität, Rolle, Delegation, Interessenkonflikte und Herkunft der Anfrage.
- Die Anfrage binden. Aktion, Parameter, Ziel, Policy-Eingaben und Nachweise für die prüfende Person per Hash oder auf andere Weise binden, damit eine Genehmigung nicht für eine geänderte Anfrage wiederverwendet werden kann.
- Berechtigung prüfen. Identität, aktive Rolle, Befugnisgrenze, Schulungsstand und etwaige Konflikte oder Beziehungen zur anfragenden Person prüfen.
- Unabhängiges Urteil ermöglichen. Quellenfakten, Unsicherheit, Grenzen, Policy-Gründe, Alternativen und nachgelagerte Folgen zeigen, ohne die Genehmigung vorauszuwählen.
- Eine Entscheidung erfassen. Identität, Rollen-Snapshot, Entscheidung, Grund, Verweis auf die Begründung, Zeit und den Digest der Nachweise festhalten, die der Checker gesehen hat.
- Vor der Freigabe erneut prüfen. Eine veraltete Genehmigung zurückweisen, wenn sich Aktion, Nachweise, Policy, Identität, Befugnis, Ziel oder relevanter Geschäftsstand geändert haben.
- Das Ergebnis anhängen. Den tatsächlichen Ausführungsbeleg und die nachgelagerte Wirkung unter denselben Ausführungs- und Entscheidungskennungen aufbewahren.
Der prüfenden Person den nötigen Kontext geben
Ein brauchbarer Decision Request beantwortet die Entscheidungsfrage in einer kurzen Darstellung und bietet strukturierte Details zur Überprüfung. Die prüfende Person sollte verstehen, was geschehen wird, warum die Policy die Aktion weitergeleitet hat, welche Fakten unsicher bleiben, welche Befugnis sie hat und wann die Anfrage veraltet.
| Kontext | Mindestens nützlicher Inhalt | Warum er die Entscheidung verändert |
|---|---|---|
| Aktion und Folge | Genaue Aktion, Ziel, wesentliche Parameter, betroffene Partei, nachgelagerte Systeme und erwartete geschäftliche Wirkung. | Die prüfende Person sieht die Verpflichtung, die sie genehmigt. |
| Identität und Befugnis | Anfragender Prinzipal, Agent, Verantwortlicher, erforderliche Prüferrolle, Befugnisgrenze und Maker-Checker-Regel. | Die prüfende Person kann testen, ob Anfrage und Entscheidung befugt sind. |
| Policy-Ergebnis | Ergebnis, zutreffende Regeln, Grundcodes, Policy-Version, bewertete Werte und sichere Alternativen. | Die prüfende Person sieht, warum die Aktion angehalten wurde und welche Vorgaben weiter gelten. |
| Nachweise und Unsicherheit | Quellenverweise, Aktualität, fehlende oder widersprüchliche Fakten, Konfidenz, Grenzen und Interpretationshilfen. | Die prüfende Person kann die Empfehlung hinterfragen und Automatisierungsbias erkennen. |
| Zeit und Wiederherstellung | Anfragezeit, Ablauf, Service-Level, Eskalationsweg, Umkehrbarkeit, Ausgleichsweg und Verfahren für den sicheren Zustand. | Die prüfende Person kennt das Entscheidungsfenster und die Kosten von Verzögerung oder Fehler. |
Service-Level, Ablauf, Delegation und Neuzuweisung festlegen
Ein Service-Level ist ein Betriebsziel. Der Ablauf ist eine Grenze der Autorisierung. Legen Sie beide nach Tragweite, Umkehrbarkeit, Volatilität der Nachweise und der verfügbaren Zeit zur Schadensverhütung fest. Keine einheitliche Dauer passt für jede Aktion.
Ein Notstopp muss einer befugten Bedienperson sofort zur Verfügung stehen und darf nicht hinter einer Genehmigungswarteschlange warten. Für gewöhnliche Anfragen sind die folgenden Beispielbänder Ausgangspunkte für einen Policy-Workshop. Ersetzen Sie sie durch systemspezifische Werte und testen Sie sie unter realer Personalbesetzung.
- Delegation: einer namentlich benannten Person eine enge Aktionsklasse, Wertgrenze, Umgebung, Geltungsdauer und einen Eskalationsweg übertragen. Festhalten, wer die Befugnis delegiert hat.
- Neuzuweisung: eine berechtigte Vertretung verlangen, die vorherige zugewiesene Person und den Grund erfassen und die ursprünglichen Nachweise und den Ablauf sichtbar halten.
- Ablauf: die Genehmigungsfähigkeit ungültig machen. Eine Zeitüberschreitung in der Warteschlange wird nie zur stillschweigenden Genehmigung.
- Veralten: vorzeitig ablaufen lassen, wenn sich wesentliche Eingaben, Policy, Identität, Ziel, Betrag oder angefragte Parameter ändern.
- Kontrolle nicht verfügbar: gemäß der Fail-closed-Policy der Aktion anhalten oder blockieren und die verantwortliche Bedienperson alarmieren.
| Klasse | Beispielhaftes Reaktionsziel | Verhalten bei Ablauf | Aktion in der Warteschlange |
|---|---|---|---|
| Eindämmung im Notfall | Sofortige Aktion der Bedienperson; die verantwortliche Vorfallrolle alarmieren. | Die Stoppbefugnis ist kurzlebig, und die Wiederherstellung erfordert eine gesonderte aktuelle Genehmigung. | Die gewöhnliche Warteschlange über den kontrollierten Vorfallpfad umgehen und Break-Glass-Nachweise sichern. |
| Folgenreiche Entscheidung vor der Ausführung | Minuten oder Stunden, je nach sicherem Haltefenster. | Ausführung bei Ablauf zurückweisen. Neu bewerten und einen neuen Decision Request ausstellen. | Vor Ablauf an einen gleich oder höher befugten Checker eskalieren. |
| Wesentliche umkehrbare Ausnahme | Stunden innerhalb des Betriebstags. | Ablaufen lassen, wenn Nachweise oder Geschäftsstand nicht mehr als aktuell gelten können. | Mit vollständigem Verlauf neu zuweisen; ursprünglich zugewiesene Person und Grund behalten. |
| Nicht blockierende Prüfung der Qualitätssicherung | Festgelegtes Ziel in Geschäftstagen. | Den Prüfpunkt schließen oder eskalieren, ohne die bereits erlaubte Aktion zu ändern. | Überfällige Prüfungen als Versagen der Qualitätssicherung verfolgen. |
Entscheidungsmatrix für Genehmigungen
Schreiben Sie eine Zeile je kontrollierter Aktionsklasse. Jede Zeile beantwortet acht Fragen, bevor die erste Anfrage eine prüfende Person erreicht: welche Aktion, welche Schwelle sie an einen Menschen leitet, wer entscheiden darf, wie lange die Entscheidung gilt, welche Änderungen der Eingaben sie ungültig machen, was eine Ablehnung bewirkt, was geschieht, wenn niemand entscheidet, und welche Nachweise der Datensatz enthalten muss.
Die folgenden Zeilen sind synthetische Ausgangspunkte für einen Policy-Workshop. Jede Schwelle, Rolle und Dauer darin ist eine konfigurierbare Betriebsregel. Ersetzen Sie sie durch Werte aus Ihrer eigenen Risikobereitschaft, Personalbesetzung und Ihren Annahmeschlusszeiten.
| Aktion | Schwelle | Prüferrolle | Ablauf | Wesentliche Änderung der Eingaben | Ablehnung | Prüfende Person nicht verfügbar | Nachweise |
|---|---|---|---|---|---|---|---|
| Zahlung an einen bestehenden Begünstigten | Über EUR 50.000 je Zahlung oder EUR 200.000 je Tag | Treasury-Checker außerhalb des anfragenden Teams | 2 Stunden und nie nach dem Annahmeschluss für Zahlungen | Betrag, Konto des Begünstigten, Valutadatum oder Währung | Die Zahlung wird nicht gesendet; der Agent erfasst den Grund und stoppt diesen Pfad | Vor Ablauf an den stellvertretenden Checker eskalieren; bei Ablauf wird nichts gesendet | Digest der Anweisung, Policy-Version, Sanktionsergebnis, Checker und Rolle, Entscheidungszeit, Bankreferenz |
| Zahlung an einen in den letzten 30 Tagen hinzugefügten Begünstigten | Jeder Betrag | Treasury-Checker, über EUR 10.000 zusätzlich Fraud Operations | 1 Stunde | Jedes Feld des Begünstigten, einschließlich des Namens | Die Zahlung wird nicht gesendet; der Begünstigte geht in die Verifizierung | Ablaufen lassen; eine aufgeteilte Zahlung zählt zur selben Anfrage | Datensatz der Änderung am Begünstigten, Referenz des Rückrufs, beide Entscheidungen |
| Aktualisierung einer Kreditentscheidung | Über der Maker-Grenze (EUR 20.000 im Rechenbeispiel unten) | Senior Underwriter | 1 Stunde | Betrag, Antragsdaten, Auskunfteiergebnis oder Policy-Version | Der Antrag geht mit dem Grund zurück in die Underwriting-Warteschlange | Mit vollständigem Verlauf an einen berechtigten Underwriter neu zuweisen | Digest des Antrags, zutreffende Regel, prüfende Person, Verweis auf die Begründung, Beleg des Kernsystems |
| Kundenschreiben mit einer nachteiligen Entscheidung | Jedes nachteilige Ergebnis | Fallverantwortliche Person mit Befugnis für die Entscheidung | Ende des Geschäftstags | Entscheidung, Gründe, Empfänger oder Kanal | Der Entwurf geht mit den Korrekturen der prüfenden Person an den Agenten zurück | Das Schreiben anhalten und bei Ablauf die Teamleitung alarmieren | Digests von Entwurf und endgültigem Text, gezeigte Gründe, Änderungen der prüfenden Person, Versandbeleg |
| Änderung der Agentenberechtigung: neues Tool, größerer Datenbereich oder höhere Grenze | Jede Änderung | Verantwortlicher, zusätzlich eine genehmigende Person aus der Zugriffs-Governance, die die Änderung nicht beantragt hat | 24 Stunden | Tool, Bereich, Grenze, Umgebung oder Dauer | Die Berechtigung bleibt unverändert | Ablaufen lassen; die anfragende Person stellt eine neue Anfrage | Berechtigung vorher und nachher, anfragende Person, beide genehmigenden Personen, Wirksamkeitsdatum, Datum der nächsten Prüfung |
| Export eingeschränkter Kundendaten | Jeder Export außerhalb der zugewiesenen Data Boundary | Dateneigentümer und Datenschutzbeauftragter | 4 Stunden | Felder, Zeilenzahl, Empfänger, Zweck oder Region | Kein Export; Anfrage und Grund werden erfasst | Ablaufen lassen; weitere Exporte für diesen Zweck warten auf die Prüfung | Feldliste, Zeilenzahl, Empfänger, Zweck, Verweis auf die Rechtsgrundlage, Entscheidung |
Rechtliche Pflichten und Betriebsregeln getrennt halten
Eine Matrix enthält zwei Arten von Anforderungen. Eine rechtliche Pflicht stammt aus einem Gesetz oder einer verbindlichen Vorschrift und gilt unabhängig von den Präferenzen der Organisation. Eine Betriebsregel ist ein Wert, den die Organisation gewählt hat, um diese Pflicht oder ihre eigene Risikobereitschaft zu erfüllen. Führen Sie beide in getrennten Spalten, damit die Änderung einer Schwelle nie als Änderung des Rechts gelesen wird.
Nach der KI-Verordnung legt Artikel 14 die Aufsichtsfunktionen fest, die ein Hochrisiko-KI-System unterstützen muss, und Artikel 26 Absatz 2 verpflichtet Betreiber, die menschliche Aufsicht Personen zu übertragen, die über die nötige Kompetenz, Ausbildung und Befugnis verfügen und die erforderliche Unterstützung erhalten. Die Verordnung (EU) 2026/1744 hat den Geltungsbeginn dieser Pflichten aus Kapitel III für Systeme nach Anhang III auf den 2. Dezember 2027 und für Systeme nach Anhang I auf den 2. August 2028 gelegt. Keiner der beiden Artikel legt einen Betrag, eine Zahl prüfender Personen oder eine Ablaufzeit fest. Diese Werte bestimmt die Organisation.
| Element der Matrix | Art | Quelle oder Verantwortlicher |
|---|---|---|
| Menschen können ein Hochrisiko-KI-System überwachen, interpretieren, übersteuern und unterbrechen | Rechtliche Pflicht für Anbieter (Artikel 14) und Betreiber (Artikel 26) von Hochrisiko-Systemen, ab den oben genannten Daten | KI-Verordnung |
| Aufsicht durch kompetente, geschulte Personen mit Befugnis | Rechtliche Pflicht für Betreiber von Hochrisiko-Systemen (Artikel 26 Absatz 2) | KI-Verordnung |
| Betragsschwellen, Tagesgrenzen und Zeitfenster für neue Begünstigte | Betriebsregel | Verantwortlicher für die Risikobereitschaft, Treasury, Fraud Operations |
| Ablaufzeiten und Eskalationspunkte | Betriebsregel | Prozessverantwortlicher |
| Vier-Augen-Genehmigung für Zahlungen | Betriebsregel, sofern Branchenvorschriften oder die interne Kontrollrichtlinie sie nicht vorschreiben | Interne Kontrollrichtlinie; Branchenanforderungen bestätigen |
| Nachweisfelder und Aufbewahrungsfrist | Gemischt: Aufzeichnungspflichten setzen das Minimum, die Feldliste ist eine betriebliche Entscheidung | Aufzeichnungspflichten und Verantwortlicher für die Nachweise |
Ausnahmefälle und was danach geschieht
Die meisten Fehler bei Genehmigungen passieren an den Rändern der Matrix. Spielen Sie jeden der folgenden Fälle mit einer echten Anfrage durch, bevor die Matrix live geht, und bewahren Sie das Ergebnis auf.
Zwei dieser Fälle sind in unseren eigenen Test-Mandanten aufgetreten. Eine prüfende Person, die nicht entscheiden konnte, sah nur „Nur ansehen“. Die Ursache war eine korrekte Funktionstrennung: Die Person gehörte zu einer Prüfgruppe, der Fall war aber an eine andere Genehmigungsgruppe geleitet. Wir haben Decision Desk so geändert, dass es den Grund nennt, etwa dass die Person nicht zur erforderlichen Genehmigungsgruppe gehört. Sagen Sie einer blockierten prüfenden Person, warum sie blockiert ist.
In denselben Mandanten fiel eine vorbefüllte Policy, deren Regeln nicht zur tatsächlichen Eingabe des Agenten passten, auf ihre Standardentscheidung zurück und lehnte die Ausführung ab. Fail-closed war das richtige Ergebnis, doch der Genehmigungspfad, den wir testen wollten, lief nie. Testen Sie jede Zeile der Matrix mit einer aufgezeichneten Eingabe, bevor Sie sich darauf verlassen. Wir haben auch gelernt, gewöhnliche Weiterleitungen aus den Vorfallwarteschlangen herauszuhalten: Zeitweise waren die meisten unserer Vorfälle gewöhnliche require_approval-Weiterleitungen an Decision Desk, deshalb haben wir den Vorfallauslöser so geändert, dass er nur bei block-Entscheidungen Vorfälle eröffnet.
| Fall | Was geschehen sollte | Verhalten von KLA im aktuellen Code | Nachweise |
|---|---|---|---|
| Der Agent ändert den Betrag nach der Genehmigung | Die Genehmigung deckt nur die geprüften Parameter ab. Die geänderte Anfrage braucht eine neue Bewertung. | Das Governance-Gateway vergleicht einen Hash der Tool-Argumente mit dem genehmigten Hash und blockiert den Aufruf, wenn sie abweichen. | Beide Argument-Digests, die ursprüngliche Entscheidung, der Blockiergrund |
| Die anfragende Person versucht, ihre eigene Anfrage zu genehmigen | Die Entscheidung wird abgelehnt und an eine andere berechtigte Person geleitet. | Decision Desk lehnt Entscheidungen der erfassten anfragenden Person oder des Makers ab und teilt ihnen mit, dass eine andere genehmigende Person entscheiden muss. | Abgelehnter Versuch, die berechtigte prüfende Person, die endgültige Entscheidung |
| Niemand entscheidet vor der Fälligkeit | Die Aktion läuft nicht. Ablauf zählt nie als Genehmigung. | Decision Desk lehnt Genehmigung und Ablehnung nach der Fälligkeit ab. Ein berechtigter Checker kann eskalieren; das startet das Entscheidungsfenster neu und erfasst die Eskalation. Eine Workflow-Genehmigung, die in die Zeitüberschreitung läuft, markiert die Ausführung als TIMEOUT, sofern der Workflow nicht so konfiguriert ist, dass er den Schritt überspringt. | Fälligkeit, Eskalationsverlauf, Endzustand |
| Die prüfende Person lehnt ab | Die Aktion läuft nicht, und der Agent erhält den Grund. | Die Ablehnung wird mit prüfender Person, Rollen zum Entscheidungszeitpunkt und einer Pflichtnotiz erfasst. | Entscheidung, Grund, prüfende Person, Zeit |
| Die Policy-Auswertung schlägt fehl oder läuft in eine Zeitüberschreitung | Die Aktion läuft nicht weiter. Eine folgenreiche Aktion schlägt geschlossen fehl. | Der Eingang für Agentenaktionen gibt einen Fehler zurück, der besagt, dass die Aktion nicht ausgeführt wurde. Das Gateway wendet in der Produktion block und anderswo require_approval an, niemals allow. | Fehlercode, Zeit, Zustand des Policy-Dienstes |
| Ein Vorfall stoppt die Ausführung, während eine Anfrage offen ist | Eine späte Genehmigung darf die Ausführung nicht fortsetzen. | Ein Kill-Signal veranlasst die wartende Ausführung, ihre offene Anfrage zu stornieren und zu enden, ohne die Aktion fortzusetzen. | Vorfallbefehl, stornierte Anfrage, Zustand der Ausführung |
| Der Agent teilt eine Zahlung auf, um unter der Schwelle zu bleiben | Gesamtgrenzen erfassen die Aufteilung. | Konfigurieren Sie in der Policy eine Grenze je Tag oder je Ziel. KLA bewertet jede Aktion gegen die Regeln, die Sie veröffentlichen. | Zutreffende Gesamtregel und die zugehörigen Aktionen |
| Das nachgelagerte System weist eine genehmigte Aktion zurück | Den Fehler erfassen. Ein erneuter Versuch mit geänderten Eingaben braucht eine neue Anfrage. | Genehmigung und Tool-Ergebnis sind getrennte Datensätze unter derselben Ausführung. | Genehmigung, fehlgeschlagenes Tool-Ergebnis, Entscheidung über den erneuten Versuch |
Übersteuerung, Beschwerde und Notstopp als getrennte Pfade gestalten
Eine Übersteuerung ändert eine Entscheidung oder Ausgabe unter ausdrücklicher Befugnis. Eine Beschwerde bittet eine andere befugte Rolle, eine Entscheidung zu prüfen. Ein Notstopp unterbricht laufenden oder eingereihten Betrieb und bringt das System in einen definierten sicheren Zustand. Wer alle drei in einer Admin-Schaltfläche zusammenfasst, verwischt Befugnis, Zeitpunkt und Nachweise.
| Pfad | Befugnis und Zeitpunkt | Erforderliche Nachweise |
|---|---|---|
| Übersteuerung | Benannte Befugnis für die Aktionsklasse, mit Grund und gegebenenfalls Vier-Augen-Regel. Bewertung, bevor die geänderte Aktion ausgeführt wird. | Ursprüngliches Ergebnis, ersetzende Entscheidung, Verweis auf die Befugnis, Grundcode, Begründung, Bindung an die Aktion, Zeit und resultierender Zustand. |
| Beschwerde | Eine von der ursprünglichen Entscheidung unabhängige Rolle, wo die Policy das verlangt. Sicheren Zwischenzustand und Reaktionsziel festlegen. | Ursprüngliche Anfrage und Entscheidung, beschwerdeführende Person, Gründe, zugewiesene prüfende Person, berücksichtigte Nachweise, Ergebnis, Abhilfe und Benachrichtigung. |
| Notstopp | Eine befugte Bedienperson kann sofort handeln. Die Wiederherstellung folgt einer gesonderten Genehmigung, nachdem die Eindämmung bestätigt ist. | Stoppende Person, Grund, Zeit, Bereich, Ausbreitung, stornierte und laufende Arbeit, Maßnahmen an Zugangsdaten, Rückstände in nachgelagerten Systemen, sicherer Zustand und Genehmigung des Neustarts. |
Fehlermodi im Genehmigungsworkflow erkennen
Ein Genehmigungsbildschirm kann existieren, während die Kontrolle versagt. Testen Sie den gesamten Pfad von der Erstellung der Anfrage bis zur nachgelagerten Wirkung, einschließlich Ausfällen, Wiederholungen, Lastspitzen und Wiederherstellung.
- Durchwinken: Prüfende Personen genehmigen zu schnell oder wiederholen identische Gründe. Messen Sie Latenz, Zustimmungsquote, Übersteuerungen und Arbeitslast; nutzen Sie unabhängige Stichproben.
- Selbstgenehmigung: Die anfragende Person, der Sponsor des Agenten oder eine Bedienperson mit Interessenkonflikt kann genehmigen. Identitäten und Konflikte zum Entscheidungszeitpunkt ermitteln.
- Veraltete Genehmigung: Nachweise, Betrag, Ziel, Policy oder Parameter ändern sich nach der Prüfung. Die Anfrage binden und vor der Ausführung erneut prüfen.
- Verwaiste Wartezeit: Keine berechtigte prüfende Person ist für den Vorgang zuständig, oder die Warteschlange verliert ihn. Zuweisung, Alter, Eskalation und Ablauf als Gesundheitszustand der Kontrolle überwachen.
- Wiederverwendung oder doppelte Ausführung: Eine Genehmigung gibt mehrere Aufrufe frei, oder ein erneuter Versuch wiederholt die Seitenwirkung. Einmal verwendbare Entscheidungen und Idempotenzschlüssel nutzen.
- Teilweise nachgelagerte Wirkung: Eine mehrstufige Aktion scheitert nach einer externen Verpflichtung. Jede Wirkung erfassen und den Ausgleichs- oder Vorfallpfad ausführen.
- Zu spät geschriebene Nachweise: Die Seitenwirkung wird festgeschrieben, bevor der Policy- oder Genehmigungsdatensatz dauerhaft ist. Geschlossen fehlschlagen, wenn der erforderliche Datensatz nicht geschrieben werden kann.
- Scheinbarer Stopp: Die Oberfläche zeigt „gestoppt“, während Worker, Warteschlangen, Zugangsdaten oder Wiederholungen weiterlaufen. Die Ausbreitung testen und jede laufende Operation abgleichen.
Rechenbeispiel: eine synthetische Kreditentscheidung
Das öffentliche AI Agent Audit Log Schema enthält einen vollständigen synthetischen Datensatz für einen Kreditprüfungsagenten, der eine Aktualisierung der Kreditentscheidung über EUR 24.000 vorschlägt. Das Beispiel zeigt, wie die Genehmigung mit der tatsächlichen nachgelagerten Wirkung verbunden ist. Zahlen und Identitäten sind synthetisch.
| Phase | Beobachteter Datensatz | Bedeutung für die Kontrolle |
|---|---|---|
| Anfrage | Ein Kreditprüfungsagent schlägt credit.application.set_disposition für einen tokenisierten Antrag innerhalb einer eingeschränkten EU-Kredit-Data-Boundary vor. | Angefragte Aktion, Zweck, Ressource, Betrag, Umgebung, Agenten-Release sowie Versionen von Modell, Prompt und Orchestrator sind an eine Ausführung gebunden. |
| Policy | Policy-Version 4.2.1 trifft manual-review-above-20000 und gibt require_approval mit dem Grund amount_requires_senior_underwriter zurück. | Der Betrag von EUR 24.000 überschreitet die Maker-Grenze. Die Ausführung bleibt für die erforderliche Rolle senior_underwriter angehalten. |
| Kontext für die prüfende Person | Der Decision Request enthält genau den Aktionskontext, das Policy-Ergebnis, den Bereich eingeschränkter Daten, die Komponentenversionen und einen Digest der gezeigten Nachweise. | Der Checker kann die Anfrage überprüfen und einen späteren Austausch des Nachweispakets erkennen. |
| Ablauf | Die Anfrage wird um 09:14:29 UTC erstellt und läuft um 10:14:29 UTC ab. | Die Genehmigungsbefugnis gilt eine Stunde. Eine Ausführung danach erfordert eine neu bewertete Anfrage. |
| Entscheidung | Ein über die Mitarbeiteranmeldung authentifizierter Senior Underwriter genehmigt um 09:14:31 UTC mit dem Grund verified_application_evidence und einem Verweis auf die Begründung. | Der Datensatz bindet prüfende Person, erforderliche Rolle, Entscheidung, Grund, Nachweis-Digest und Zeit. |
| Ausführung | Der kontrollierte Tool-Aufruf startet nach der Genehmigung, nutzt einen Idempotenzschlüssel und gelingt mit Digests für Argumente und Ergebnis. | Die Genehmigung geht der Seitenwirkung des Tools voraus und kann nur die gebundene Aktion freigeben. |
| Nachgelagerte Wirkung | Der synthetische Core-Banking-Datensatz meldet credit_disposition_updated mit Digests für den Zustand vorher und nachher. | Der Genehmigungspfad enthält nach der Policy-Entscheidung einen ausdrücklichen Datensatz zum Geschäftsergebnis. |
| Nachweise | Eine geordnete Herkunftskette verbindet Ereignisse für Anfrage, Policy, Genehmigung, Tool und Abschluss. Der Datensatz verlinkt Policy- und Tool-Artefakte und trägt ein gültiges Ergebnis der Integritätsprüfung. | Eine Prüferin kann Reihenfolge, Identität, Bindung an die Aktion, Ergebnis und Integrität des Datensatzes testen. Die Vollständigkeit der Quellen bleibt ein gesonderter Prüftest. |
Ein Mindestschema für Nachweise verwenden
Verwenden Sie stabile Kennungen und maschinenlesbare Felder, damit prüfende Personen oder Auditoren die Entscheidung mit der Ausführung verknüpfen können, ohne sich auf Zeitstempel oder Screenshots zu verlassen. KLA veröffentlicht für diesen Datensatz ein herstellerneutrales JSON Schema mit Beispielen und Verifier.
| Nachweisgruppe | Mindestfelder | Beantwortete Frage |
|---|---|---|
| Umschlag und Bereich | schema_version, event_id, occurred_at, recorded_at, sequence, correlation_id, execution_id, Organisation, Umgebung, Aufbewahrungsklasse | Welcher Datensatz und welche Betriebsgrenze werden geprüft? |
| Akteure und Versionen | requester, agent, accountable_owner, delegierter Nutzer oder Dienstidentität, Agenten-Release, Modell, Prompt, Orchestrator | Wer oder was hat gehandelt, unter wessen Verantwortung und mit welchen Versionen? |
| Angefragte Aktion | action, purpose, resource, Data Boundary, gegebenenfalls Betrag, Ziel, requested_at, Digest der Argumente | Welche Seitenwirkung genau wurde vorgeschlagen? |
| Policy | decision_id, policy_id und Version, Digests von Policy und Eingaben, allow oder warn oder require_approval oder block, zutreffende Regeln, Grundcodes, evaluated_at | Warum hat die Kontrolle dieses Ergebnis erzeugt? |
| Genehmigung | request_id, requested_at, expires_at, required_role, Digest der gezeigten Nachweise, prüfende Person, Entscheidung, Grund, Verweis auf die Begründung, decided_at, Neuzuweisung, gegebenenfalls Übersteuerung oder Beschwerde | Hat ein berechtigter Mensch vor der Ausführung auf Basis aktueller Nachweise entschieden? |
| Ausführung und Wirkung | Tool und Version, Idempotenzschlüssel, Start- und Abschlusszeit, Ergebnis-Digest, Verweise auf nachgelagerte Wirkungen, Digests vorher und nachher, Geschäftsergebnis, Verweis auf Rollback oder Vorfall | Was wurde ausgeführt, und was hat sich außerhalb der Control Plane geändert? |
| Herkunft und Integrität | Geordnete Ereignis-IDs, Nachweismanifest und Artefakt-Digests, Datenschutzbehandlung, Datensatz-Hash, Signatur, Prüfstatus und Fehlercodes | Lässt sich der Datensatz nachvollziehen, korrekt behandeln und auf Änderungen prüfen? |
Wie KLA den Genehmigungspfad umsetzt
KLA Control Plane steuert instrumentierte Agentenaktionen. KLA Policy Engine bewertet einen vorgeschlagenen Tool-Aufruf gegen veröffentlichte Regeln und gibt allow, warn, require_approval oder block zurück. Ein require_approval-Ergebnis hält den vorgeschlagenen Aufruf an und erstellt einen Decision Request für Decision Desk. Ein block verhindert, dass der kontrollierte Aufruf das Tool erreicht.
Für Decision Requests der Control Plane prüft Decision Desk die Entscheidungsberechtigung, die erforderliche Prüferrolle, den offenen Status, die Identität von anfragender Person und Maker sowie die Fälligkeit. Es verhindert, dass erfasste anfragende Personen und Maker über ihre eigene Anfrage entscheiden, und weist Genehmigungen oder Ablehnungen nach der Fälligkeit zurück. Ein berechtigter Checker kann eine überfällige Anfrage eskalieren. Es erfasst die entscheidende Person, einen Rollen-Snapshot, das Ergebnis, den Grund und die Zeit. Diese Kontrollen für Trennung und Ablauf setzen voraus, dass die Anfrage aktuelle Maker-Identitäten und eine Fälligkeit enthält. Stellen Sie sicher, dass jeder erzeugende Pfad sie liefert, und testen Sie den gesamten Kontrollpfad.
Lineage Explorer und Audit Trail zeigen die Datensätze zu Policy, menschlicher Entscheidung und Ausführung. Evidence Room kann ausgewählte Datensätze in ein Sealed Evidence Bundle mit Signaturen, Artefakt-Hashes und einer Merkle-Wurzel packen, die Integritätsprüfungen offline ermöglicht. Die Organisation bleibt verantwortlich für die Klassifizierung der Aktionen, die Kompetenz der prüfenden Personen, die Personalbesetzung, die rechtliche Analyse, vollständige Instrumentierung, Vollständigkeit der Quellen, Eingriffe über alle Worker und nachgelagerten Systeme hinweg und die Gestaltung des sicheren Zustands.
Technische Referenzen
Lesen Sie die Komponentenverträge und den verknüpften Ausführungsdatensatz hinter dem hier beschriebenen Genehmigungspfad.
Primärquellen und Aktualität
Quellenprüfung abgeschlossen am 8. Oktober 2026. Artikel 14 der KI-Verordnung verlangt eine wirksame menschliche Aufsicht über Hochrisiko-KI-Systeme und nennt Funktionen für Überwachung, Bewusstsein für Automatisierungsbias, Interpretation, Nichtbeachtung, Übersteuerung, Rückgängigmachen, Eingreifen und sicheres Unterbrechen. Artikel 26 Absatz 2 verpflichtet Betreiber von Hochrisiko-Systemen, die menschliche Aufsicht Personen mit der nötigen Kompetenz, Ausbildung und Befugnis zu übertragen und ihnen die erforderliche Unterstützung zu geben. Erwägungsgrund 73 erläutert die Rolle informierter Eingriffe und eingebauter Betriebsbeschränkungen.
Die Verordnung (EU) 2026/1744 hat den Geltungsbeginn der Hochrisiko-Vorschriften aus Kapitel III für Systeme nach Artikel 6 Absatz 2 und Anhang III auf den 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 und Anhang I auf den 2. August 2028 geändert. Den Kontrolltext von Artikel 14 hat sie nicht ersetzt.
Der NIST AI RMF Core verlangt differenzierte Rollen für Mensch und KI, dokumentierte Aufsichtsprozesse, unabhängige Prüfung sowie Mechanismen für Beschwerde, Übersteuerung, Außerbetriebnahme, Vorfallreaktion und Wiederherstellung. NIST Appendix C hält fest, dass der Bedarf an menschlicher Aufsicht vom Kontext abhängt. Das OECD-KI-Prinzip zu menschenzentrierten Werten verlangt Schutzvorkehrungen für menschliche Handlungsfähigkeit und Aufsicht, die dem Kontext und dem Stand der Technik entsprechen.
Die Tabelle mit vier Ergebnissen, das Raster der sieben Kriterien, die Service-Level-Beispiele und das Nachweisschema in diesem Leitfaden sind Umsetzungsmuster. Sie enthalten keine allgemeingültige rechtliche Schwelle. Prüfen Sie geltendes Recht, aufsichtliche Leitlinien, Branchenvorschriften, Systemfakten und den aktuellen Quelltext erneut, bevor Sie sich darauf stützen.
Häufig gestellte Fragen
Welche Aktionen von KI-Agenten erfordern eine menschliche Genehmigung?
Verlangen Sie eine Genehmigung, wenn eine Aktion wesentlich, schwer umkehrbar, rechtsberührend, sensibel, neuartig, nahe an einer Befugnisgrenze ist, geringe Konfidenz hat oder eine erhebliche nachgelagerte Wirkung erzeugen kann. Blockieren Sie verbotene, unbefugte, veraltete, fehlerhafte oder nicht überprüfbare Aktionen.
Was ist der Unterschied zwischen Human in the loop, Human on the loop und Human in command?
Human in the loop entscheidet vor der Ausführung über eine bestimmte Aktion. Human on the loop überwacht eine begrenzte Tätigkeit und kann innerhalb eines getesteten Fensters eingreifen. Human in command verantwortet Mandat, Grenzen, Policies, Stoppbefugnis, Neustart und Rechenschaft für das System.
Wie sollte die Maker-Checker-Trennung bei einem KI-Agenten funktionieren?
Benennen Sie Agent, Verantwortlichen und anfragenden Prinzipal als Maker-Seite. Leiten Sie genau die gebundene Anfrage an einen anderen, qualifizierten Checker. Prüfen Sie Identität, aktuelle Rolle, Befugnis, Delegation und Konflikte zum Zeitpunkt der Entscheidung und prüfen Sie die Anfrage vor der Ausführung erneut.
Welchen Kontext braucht eine Person, die Aktionen von KI-Agenten prüft?
Zeigen Sie genau die Aktion und ihre Folge, Identität von anfragender Person und Agent, Befugnisgrenzen, Policy-Ergebnis und Gründe, Quellennachweise und deren Aktualität, Unsicherheit und Grenzen, Alternativen, Ablauf, Eskalationsweg und Wiederherstellungspfad.
Wann sollte eine Genehmigung ablaufen?
Lassen Sie die Genehmigung ablaufen, wenn das sichere Haltefenster endet oder sich wesentliche Nachweise, Policy, Identität, Befugnis, Ziel, Betrag, Parameter oder der Geschäftsstand ändern. Eine abgelaufene Anfrage darf nicht ausgeführt werden; bewerten Sie die Aktion neu und stellen Sie eine neue Anfrage aus.
Kann ein Mensch eine block-Entscheidung übersteuern?
Eine prüfende Person sollte eine verbotene Aktion nicht innerhalb derselben Anfrage in eine Genehmigung umwandeln. Eine berechtigte Notfallausnahme braucht einen gesonderten, engen, befristeten Policy-Pfad mit benannter Befugnis, Grund, Nachweisen, Eindämmungsgrenzen und nachträglicher Prüfung.
Wie sollten Beschwerden und Notstopps funktionieren?
Leiten Sie eine Beschwerde an die von der Policy festgelegte unabhängige Rolle und halten Sie das System in einem sicheren Zwischenzustand. Lassen Sie eine befugte Bedienperson einen Notstopp sofort auslösen, erfassen Sie Ausbreitung und Rückstände und verlangen Sie vor dem Neustart eine gesonderte aktuelle Genehmigung.
Was belegt, dass die Genehmigung vor der Ausführung erfolgte?
Verwenden Sie einen korrelierten Datensatz mit geordneten Ereignissen für Anfrage, Policy, Genehmigung, Tool und Abschluss. Binden Sie Aktion und Nachweise mit Digests, erfassen Sie Befugnis der prüfenden Person und Ablauf, verwenden Sie einen Idempotenzschlüssel, hängen Sie den Beleg des nachgelagerten Systems an und prüfen Sie die Integrität des Datensatzes.
Die wichtigsten Erkenntnisse
Eine brauchbare Genehmigungskontrolle gibt jeder folgenreichen Aktion ein klares Ergebnis, hält genau die Anfrage an, wenn Urteilsvermögen gefragt ist, gibt dem Checker genug Kontext und Befugnis, lässt veraltete Entscheidungen ablaufen und hängt die tatsächliche nachgelagerte Wirkung an den Nachweisdatensatz. Laden Sie das Playbook zum Genehmigungsworkflow für KI-Agenten herunter, um die Regeln für eine Aktion festzulegen, und testen Sie dann den gesamten Pfad unter normalen Bedingungen sowie bei Ablauf, Neuzuweisung, Duplikaten, Ausfall und Notstopp.