Agent & Tool-Calling Operations

Produkte und Entscheidungen

Agent-Ops braucht nicht „eine Copilot-Suite“, sondern geschnittene Produkte.

Laufzeit-Identität und Pfad

Dieses Produkt beschreibt:

• Agent-ID; Zweck; Nutzerpopulation; verbotene Ziele; Umgebung; Laufzeitkonto; Prompt- und Modellversion; verantwortliche Person; Review-Datum.

Entscheidungen:

• Welche Business Unit teilt kein Bot-Konto?; Wer darf den Pfad an eine Sanctioned-Pfad-ID koppeln?; Welche Shadow-Agenten (Slack-Plugin, inoffizieller GPT) gehören ins Register?

Permission- und Tool-Scope

Inventar vor Power.

Entscheidungen:

• Welche Tools, Datenklassen und Side-Effect-Stufen sind erlaubt — auch wenn die Liste leer startet?; Wer nimmt ein neues Tool als denselben Pfad oder als neuen Agenten an?; Welche „temporären Admin-Tools“ haben Ablauf?

HITL und Audit

Wirkungsstarke Aktionen brauchen einen Menschen und eine Spur.

Entscheidungen:

• Welche Aktion ist High-Impact (Refund-Limit, Identität, Write)?; Wer gibt frei, und welches Limit gilt?; Welche Logs binden Call an technische Laufzeit-Identität und müssen den Incident überstehen?

Cost Caps und Abuse Controls

Ein Loop ohne Cap ist ein offener Scheck.

Entscheidungen:

• Welches Spend- oder Call-Limit stoppt den Pfad?; Wer wird alarmiert, und wer darf den Cap heben?; Welche Abuse-Muster (Wiederhol-Writes, Prompt-Injection) gelten als Incident?

Incident-Rollback

Der Reverse-Pfad muss vor dem Incident existieren.

Entscheidungen:

• Was wird zurückgerollt — Tickets, Zahlungen, Writes, Freigabeliste, Prompt-Version?; Wer führt den Drill?; Welcher Nachweis geht an Assurance, ohne dass die erste Inventur während des Incidents startet?

Wo Governance hängt

Zwischen Demo-Credentials und Produktionspfad

Eine Demo mit Prod-Secrets ist kein Pilot. Der erste Write ist ein Produktionsereignis.

Zwischen geteilter Bot-Identität und Blast Radius

Ein Konto über Support, Finance und HR macht Rollback unmöglich. Jeder Pfad braucht eine eigene Laufzeit-Identität.

Zwischen Prompt-Edit und Change-Regel

Ein stiller Hotfix am Prompt kann Tools und Limits ändern. Materielle Prompt-Änderungen brauchen Steward-Notice.

Zwischen HITL-Folie und unbeaufsichtigtem Refund

„Wir haben HITL“ ohne Gate am Zahlungs-Tool ist Theater. Der Call läuft.

Zwischen Cost-Dashboard und Cap

Eine schöne Spend-Kurve ohne Stopp beobachtet den Loop. Die Rechnung läuft über Nacht.

Zwischen Gateway-Admin und Process Owner

Wer Allowlist und Secrets setzen kann, entscheidet damit nicht, ob Refunds ohne Mensch erlaubt sind.

Rollen-Mapping

Data Owner (Process / Channel)

Head of Support, Head of Payments Operations oder benannter Channel Owner ist accountable für Zweck, verbotene Ziele, HITL-Limits und Residualrisiko des Blast Radius. Der Owner entscheidet nicht die Gateway-Verkabelung.

Data Steward

AI Operations oder Workplace AI Governance führt Agent- und Tool-Register, Change-Notices, Cap-Überwachung und eskaliert Shadow-Pfade.

Data Product Owner

Priorisiert Pfad-Releases, HITL-Gates und Rollback-Drills. Nutzen und Lieferbarkeit — nicht die Modellwahl allein.

Data Architect

Schützt Pfad-Grain (Zweck ≠ Tool ≠ Umgebung), Lineage von Prompt zu Side Effect und Breaking Changes, wenn der Agent denselben Namen behält, aber ein Write-Tool dazubekommt.

Data Custodian

Gateway-, IAM- und Secrets-Admin setzen Allowlist, Telemetrie, Caps und Stop-Switch um. Wer das Tool schalten kann, darf nicht entscheiden, ob der Call erlaubt ist.

Data Consumer

Support-Agenten, Kundenkanäle, interne Assistenten — wer den Pfad fachlich braucht. Tool-Erweiterungen laufen über denselben Anfrageweg.

Mini-Fall

Symptom: Ein Support-Agent schließt Tickets und löst Erstattungen aus. In der Demo nutzte er ein gemeinsames technisches Konto mit Produktiv-Zugangsdaten. Erstattungen über 50 € laufen ohne menschliche Freigabe. Eine Endlosschleife verursacht über Nacht 4.000 € Kosten. Danach kann niemand sicher sagen, welche Tickets der Agent geschlossen hat.

Typischer Fehlstart: Agent-Plattform kaufen und Katalog-Tag ai=sanctioned setzen, ohne Inventar der nutzbaren Werkzeuge, ohne menschliche Freigabe bei Erstattungen und ohne Rückbau-Liste.

Vereinbarung: Eigene technische Laufzeit-Identität; Freigabeliste ohne Schreibrechte, bis menschliche Freigabe steht; Erstattungslimit mit menschlicher Freigabe; Kostengrenze mit Abschalter; Prüfspur; Rückbau-Liste für Tickets und Zahlungen vor dem nächsten Vorfall.

Kritische Übergaben

Anti-Patterns

• Demos mit Produktions-Credentials ausliefern
• Eine gemeinsame Bot-Identität über Business Units
• Prompt-Edits als Zero-Governance-Änderungen behandeln
• Inventar überspringen, weil „es nur Slack ist“
• Das Plattformteam default als verantwortliche Person für den Agenten benennen
• High-Impact-Actions ohne menschliche Freigabe und ohne Risikoakzeptanz
• Cost beobachten, aber den Loop nicht stoppen
• Rückbau mit „Prompt zurücksetzen“ verwechseln

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

Schritt 1: Rahmen und Entscheidung klären

Die drei wichtigsten Produktionsagenten registrieren. Zweck, verbotene Ziele, Tools und Side-Effect-Stufen aufnehmen. Process- oder Channel-Owner benennen. Einen undokumentierten Tool-Pfad deaktivieren.

Schritt 2: Control und Nachweis umsetzen

Eine Laufzeit-Identität und eine Allowlist für einen Pfad produktiv setzen. HITL für eine Write- oder Zahlungsaktion schalten. Einen Cost Cap mit Alarm zuweisen. Den Agenten an die Sanctioned-Path-ID koppeln.

Schritt 3: Testen und Ausnahmen sichtbar machen

Negativtest: ein Write ohne HITL oder ein Cap-Bruch muss den Pfad stoppen oder eskalieren. Einen Rollback-Drill (Ticket oder Testzahlung) fahren. Einen Shadow-Agenten nachträglich ins Register holen.

Schritt 4: Messen und begrenzt ausrollen

Aufwand und Lücken messen. Nur bestandene Muster (Identität, Scope, HITL, Cap, Rollback-Liste) auf einen zweiten Kanal oder ein zweites Tool übertragen.

Exit-Kriterien

• Jeder produktive Pfad hat technische Laufzeit-Identität, Zweck, Tool-Inventar und verantwortliche Person.
• menschliche Freigabe gilt für High-Impact; Prüfspur bindet Call an Identität.
• Cost Caps können stoppen; Abuse ist ein Incident.
• Rückbau-Liste existiert vor dem Incident; technischer Betreiber liefert Konfigurationsnachweis.
• Gateway-Admin ist technischer Betreiber; Process Owner trägt Blast-Radius-Risiko.

Weiterlesen

• Freigegebene KI betreiben
• Workplace KI Governance
• KI Assurance Ops
• KI Foundations

Breite „Admin“-Tools machen aus einem freigegebenen Agenten einen nicht freigegebenen Schreibpfad. Scopes sind der Vertrag zwischen Geschäftszweck und technischer Fähigkeit.

Ein menschliches Admin-Token wandert auf den Agenten, das Wiki beschreibt enge Scopes, das Gateway gibt tenant-weit aus. Dieser Teil bindet jedes Tool auf der Allowlist an Zweck, Datenklasse und Least Privilege — bevor HITL und Caps darauf aufsetzen.

Vorher: Agenten als gesteuerte Betriebsoberflächen. Weiter: Audit-Trail und Human-in-the-Loop-Gates.

zwischen Geschäftszweck und technischer Fähigkeit.

Lösung: Jedes Tool auf der Agent-Allowlist erhält Zweck, Datenklassen, Side-Effect-Stufe, ressourcengebundene Permission Scopes, Default Deny für alles Nichtgelistete sowie Data Owner, Steward und Custodian für Freigabe, Pflege und Durchsetzung.

In einem Satz: Kein Tool auf der Allowlist ohne Zweck, Least-Privilege-Scope, Side-Effect-Stufe und benannten Freigabepfad.

Entscheidung

Für jedes Tool auf der Agent-Allowlist:

1. Zweck, Datenklassen, Side-Effect-Stufe (read / write / money / identity / external) festlegen;
2. Permission Scopes (Ressourcen, Aktionen, Umgebungen) mit Least Privilege binden;
3. Data Owner genehmigt Tools mit hohen Side Effects; Steward pflegt die Allowlist; Custodian setzt Scopes im Gateway durch;
4. Default Deny für nicht gelistete Tools und Scopes;
5. Dual Control oder HITL-Anforderungen werden hier erklärt und in Teil 3 durchgesetzt.

Kein produktiver Tool-Call außerhalb eines genehmigten, ressourcengebundenen Scopes.

Scope-Workflow

1. Fähigkeiten inventarisieren

Der Steward schreibt eine Tool Card: erlaubte Verben, berührte Ressourcen, Datenklassen und undokumentierte Admin-Pfade. Der Custodian prüft das Gateway gegen die Card — nicht gegen das Vendor-Marketing. Wird das Inventar übersprungen, erbt der Agent menschliche Admin-Rechte und jeder spätere HITL-Gate prüft die falsche Fläche.

2. Scopes schneiden

Der Data Owner genehmigt ressourcengebundene Scopes: eine Queue, ein Schema, ein Payment-Limit — keine tenant-weiten Tokens. Artefakt ist die Scope-Config mit Umgebung (dev / prod) und Ablauf. Ein gemeinsames OAuth-Token für alle Tools macht Least Privilege zur Folie.

3. Auf Risikoklasse mappen

Money- und Identity-Änderungen erben Owner-Freigabe und HITL aus Teil 3; Read-only kann auto-allow-with-log bleiben. Die Tool Card trägt die Stufe, nicht ein Kommentar im Prompt. Ohne Mapping entscheidet das Modell zur Laufzeit, was „harmlos“ ist.

4. Rotieren und befristen

Der Custodian rotiert Secrets nach Policy und setzt Ablaufdaten auf temporäre Scopes. Incident-Bereitschaft heißt ein befristeter Break-Glass-Pfad, kein dauerhaft erhöhtes Token. Permanente Extra-Rechte „für den Notfall“ sind das nächste Leak.

5. Negative Pfade testen

Out-of-Scope-Calls müssen scheitern; Bypass-Accounts stehen im Inventar. Der Custodian liefert Negative-Test-Evidenz an den Steward, bevor die Allowlist live geht. Wer nur den Happy Path testet, entdeckt den Admin-Verb erst in Produktion.

Handoffs

Anti-Patterns

• Ein OAuth-Token für alle Tools
• Menschliche Admin-Rollen auf Agenten kopieren
• Scopes im Wiki dokumentieren, aber breitere Tokens ausgeben
• Permanent erhöhte Scopes „für Incident-Bereitschaft“
• Negative Tests überspringen

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Tool Cards für alle Tools eines Produktionsagenten veröffentlichen.
2. Ein zu breites Token auf einen ressourcengebundenen Scope reduzieren.
3. Ein ungenutztes Tool default-denyen.
4. Data-Owner-Freigabe für jedes money-/identity-Tool dokumentieren.

Wenn Sie nicht rekonstruieren können, wer welchen Tool-Call freigegeben hat, können Sie den Agenten nicht steuern. HITL ohne Audit-Trail ist Theater; ein Audit-Trail ohne HITL für wirkungsstarke Actions ist Fahrlässigkeit.

Ein Slack-„LGTM“ ohne Call-ID, Timeout wird Auto-Approve, HITL läuft nur in der Demo. Dieser Teil macht Trail und Gate zumselben Betriebsvertrag — auf den Scopes aus Teil 2.

Vorher: Permission Scopes je Tool. Weiter: Cost Caps und Abuse Controls.

In einem Satz: Kein wirkungsstarker Tool-Call ohne Audit-Record und, wo die Matrix es verlangt, menschliche Freigabe vor der Ausführung.

Entscheidung

Für jeden Produktionsagenten:

1. speichert der Audit-Trail Prompt-/Kontext-Hash (soweit Policy erlaubt), Tool-Name, Parameterklasse, Entscheidung, Actor, Zeitstempel und Outcome;
2. gelten HITL-Gates nach Side-Effect-Stufe und Risikoklasse vor der Ausführung;
3. legt der Data Owner fest, welche Actions menschliche Freigabe brauchen; der Steward pflegt die Matrix; der Custodian setzt Hold-and-Resume im Gateway um;
4. sind Freigaben befristet und ohne Re-Auth nicht übertragbar;
5. ist fehlgeschlagenes oder übersprungenes HITL ein Incident, keine Konfigurationsvorliebe.

Kein write-/money-/identity-Call ohne die in der Matrix benannte Freigabe.

Audit- und HITL-Workflow

1. Matrix definieren

Der Data Owner mappt Side-Effect-Stufen auf approve, dual-control oder auto-allow-with-log. Artefakt ist die HITL-Matrix je Tool, nicht ein Slack-Kanal. Der Steward pflegt die Matrix; ohne sie entscheidet der Operator zur Laufzeit, was „schon okay“ ist.

2. Minimale Evidenz erfassen

Der Custodian speichert genug zur Rekonstruktion der Action — Call-ID, Actor, Parameterklasse, Outcome — und redaktiert Secrets sowie unzulässige Inhalte nach Policy. Der Audit-Store selbst braucht Retention und Access Control. Roh-Payloads ohne Redaction erzeugen einen zweiten Leak.

3. Wirkungsstarke Calls halten

Das Gateway parkt write-/money-/identity-Calls, bis eine benannte Person freigibt. Der Freigeber sieht eine Kontext-Summary, gebunden an die Call-ID — kein „LGTM“ in einem privaten Chat. Ohne Hold-and-Resume läuft HITL nur in Demos.

4. Loop schließen

Approve, Reject und Timeout werden geloggt und an die ursprüngliche Call-ID gebunden. Timeout ist Reject oder Incident, nie Auto-Approve. Ein gemeinsames Freigeber-Konto macht den Actor wertlos.

5. Samples reviewen

Der Steward sampelt HITL-Entscheidungen wöchentlich auf Rubber-Stamping und eskaliert Muster an den Data Owner. Artefakt ist der Audit-Export mit Begründung je Sample. Wer nie sampelt, hält ein Gate, das niemand mehr liest.

Handoffs

Anti-Patterns

• Slack-„LGTM“ ohne Bindung an Call-ID
• Auto-Approve nach Timeout
• Secrets im Klartext loggen
• menschliche Freigabe nur für Demos, in Produktion aus
• Ein gemeinsames Freigeber-Konto

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. HITL-Matrix für einen Agenten veröffentlichen.
2. Hold-and-Resume für ein write- oder money-Tool aktivieren.
3. Prüfen, dass Audit-Records Call-ID, Actor und Outcome enthalten.
4. Zehn Freigaben auf Rubber-Stamping samplen.

Agenten können Budget verbrennen und APIs missbrauchen, bevor Menschen es merken. Cost Caps und Abuse Controls sind Governance-Controls — nicht nur FinOps-Nachgedanken.

Ein Pilot-Key ohne Limit, Caps nur auf dem LLM, Rekursion zwischen zwei Agenten: die Rechnung läuft über Nacht, der Alert hat keinen Owner. Dieser Teil setzt verschachtelte Caps und Stopp-Bedingungen auf den HITL-Pfad aus Teil 3 — bevor das Incident-Playbook greift.

Vorher: Audit-Trail und Human-in-the-Loop-Gates. Weiter: Incident- und Rollback-Playbook.

In einem Satz: Kein Produktionsagent ohne Caps, Stop Switch und benannten Owner für Spend- und Abuse-Anomalien.

Entscheidung

Für jeden Produktionsagenten:

1. Cost- und Volumen-Caps je Agent, je Tool und je Zeitfenster definieren;
2. Abuse-Signale definieren (loopende Tool-Calls, Prompt-Injection-Muster, anomale Ziele);
3. Data Owner setzt geschäftlich akzeptablen Spend und Stopp-Bedingungen; Steward überwacht Schwellen; Custodian setzt Rate Limits, Stop Switches und Billing-Tags durch;
4. Soft Warn, dann Hard Stop — HITL-Override nur wenn die Matrix es erlaubt;
5. Anomalien öffnen Incidents nach Teil 5, keine stillen Slack-Threads.

Kein ungetaggter Traffic und kein Cap ohne Stopp.

Cap- und Abuse-Workflow

1. Spend taggen

Jeder Call trägt Agent-ID, Environment und Cost Center. Der Custodian blockiert oder quarantiniert ungetaggten Traffic; der Steward sieht damit, welches Cost Center den Burst zahlt. Ohne Tags landet die Rechnung bei niemandem — und der Data Owner kann keine Stopp-Bedingung setzen.

2. Verschachtelte Caps setzen

Tool-Rate pro Minute, tägliches Token-/Spend-Budget und Monatsdeckel. Artefakt ist die Threshold-Config mit Alert-Routen an den Steward. Caps nur auf dem LLM, nicht auf nachgelagerten Paid Tools, lassen den teuren Pfad offen.

3. Loops erkennen

Identische Tool-Sequenzen, explodierende Retries und rekursive Agent-zu-Agent-Calls brauchen automatische Circuit Breaker. Der Custodian verdrahtet den Breaker an denselben Stop Switch wie den Hard Stop. Wer Rekursion ignoriert, zahlt denselben Call in einer Schleife.

4. Prod und Experiment trennen

Experiment-Budgets dürfen Produktions-Stop-Switches nicht teilen — beide brauchen Caps. Der Data Owner genehmigt getrennte Stopp-Bedingungen, damit ein Lab-Burst Prod nicht „zum Schutz“ abschaltet. Unlimited Keys „für den Piloten“ sind der klassische Slow Burn.

5. An Owner reporten

Der Steward sendet wöchentliche Exception- und Near-Cap-Reports an den Data Owner. Near-Cap ist ein Steuerungsereignis, kein Dashboard-Schmuck. Caps ohne Digest und ohne Stop Switch lassen den Agenten nach dem Alert weiterlaufen.

Handoffs

Anti-Patterns

• Unbegrenzte Keys „für den Piloten“
• Caps nur auf dem LLM, nicht auf nachgelagerten Paid Tools
• Limits während Incidents dauerhaft abschalten
• Agent-zu-Agent-Rekursion ignorieren
• Kein verantwortliche Person für verwaisten High Spend

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Billing-Tags und Agent-IDs auf einem Produktionspfad anwenden.
2. Tägliche Spend- und Per-Tool-Rate-Caps mit dem Data Owner setzen.
3. Einen Circuit Breaker für wiederholte identische Tool-Sequenzen aktivieren.
4. Den ersten wöchentlichen Near-Cap-Digest liefern.

Wenn ein Agent den falschen Datensatz schreibt oder ein Budget leert, zählen Minuten. Improvisierte Chat-Triage verliert Evidenz und lässt Tools aktiv.

Root Cause im Slack, Tools bleiben an, jemand redeployt „latest“, Logs werden „aufgeräumt“. Dieser Teil schließt die Serie mit einem wiederholbaren Incident- und Rollback-Pfad — Contain zuerst, Evidence Pack zuletzt.

Vorher: Cost Caps und Abuse Controls. Bei Bedarf weiter in Freigegebene AI betreiben, Workplace AI Governance und AI Assurance Ops.

z schreibt oder ein Budget leert, zählen Minuten. Improvisierte Chat-Triage verliert Evidenz und lässt Tools aktiv.

Lösung: Materielle Agent-Incidents folgen Contain, Blast-Radius, Rollback und Evidence Pack — Steward koordiniert, Data Owner entscheidet Kommunikation und Restrisiko, Custodian führt Stop Switch, Restore und Secret-Rotation aus. Post-Incident-Actions aktualisieren Scopes, HITL-Matrix und Caps mit Owner und Fälligkeit.

In einem Satz: Erst contain und Logs sichern, dann rollbacken — kein Abschluss ohne Evidence Pack und benannte Follow-ups.

Entscheidung

Für materielle Agent-Incidents:

1. zuerst contain: Tools oder Agent-Identität deaktivieren, Logs erhalten;
2. Rollen: Steward koordiniert; Data Owner entscheidet Business-Kommunikation und Restrisiko; Custodian führt technisches Rollback und Secret-Rotation aus;
3. Rollback stellt Last Known Good Allowlist, Prompt-/Modellversion und betroffenen Systemzustand wieder her, soweit möglich;
4. Evidence Pack hält Timeline, Calls, Freigaben, Caps und Kunden-Impact fest;
5. Post-Incident-Actions aktualisieren Scopes, HITL-Matrix und Assurance-Findings — mit Ownern und Fälligkeiten.

Kein Incident-Abschluss, solange Tools aktiv bleiben oder das Pack unvollständig ist.

Incident-Workflow

1. Erkennen und deklarieren

Abuse-Alert, HITL-Fehler, User-Report oder Assurance-Finding öffnet den Fall. Der Steward deklariert Schwere und übernimmt als Incident Commander; der Custodian liefert den initialen Audit-Extract. Wer zuerst Root Cause diskutiert, statt zu deklarieren, verliert die ersten Minuten.

2. Contain

Stop Switch, Tokens revoken, Outbound-Tools einfrieren. Logs nicht löschen — der Custodian sichert sie, bevor irgendwer „aufräumt“. Contain ohne Autorisierung des Data Owner ist nur bei klarem High-Impact erlaubt und wird nachgezogen dokumentiert.

3. Blast Radius bewerten

Welche Systeme, Records, Identitäten und Kunden? Der Custodian zieht Audit-Trails; der Steward fasst Optionen für den Data Owner. Ohne Radius-Bewertung wird Rollback Hoffnung statt Plan.

4. Rollback und remediate

Last Known Good Allowlist, Prompt- und Modellversion pinnen — nicht „latest“ redeployen. Fehlerhafte Writes rückgängig machen oder kompensieren, Secrets rotieren, Kommunikation nach Data-Owner-Entscheidung. Artefakt ist Rollback-Evidenz plus Rotationsnachweis.

5. Lernen und härten

Playbook, Scopes, Caps und Red-Team-Fälle aktualisieren. Schließen erst bei vollständigem Evidence Pack und Actions mit Fälligkeit an Assurance oder Workplace AI. Monitoring dauerhaft abschalten, „damit der Bot läuft“, ist der nächste Incident.

Handoffs

Anti-Patterns

• Root Cause diskutieren, während Tools aktiv bleiben
• „Latest“ redeployen ohne Last Known Good zu pinnen
• Kunden-/Impact-Kommunikation überspringen, obwohl Data Owner sie verlangt
• Incidents ohne Nachweispaket schließen
• Monitoring dauerhaft abschalten, „damit der Bot läuft“

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Eingebettete KI-Oberflächen
• Lernpfad — Eingebettete KI-Oberflächen

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

1. Incident-Schwere-Tabelle und Rollenkontakte für einen Agenten veröffentlichen.
2. Contain → Revoke → Restore an einem Nonprod-Agenten proben.
3. Prüfen, dass Logs Stop-Switch-Events überleben.
4. Ein Tabletop-Finding in den HITL- oder Scope-Backlog legen.

Weiterlesen

• Prüfen vor dem nächsten Agent-Tool
• KI Assurance Ops
• Sanctioned KI Ops