Ein KI-Agent hat gerade 2.000 Kundendatensätze gelöscht. Der Prompt war eindeutig, der Tool-Call gültig und der Agent tat genau das, wofür er entwickelt wurde. Doch der Input war falsch: ein fehlerhafter API-Request, ein halluzinierter Parameter oder ein Nutzer, der die falsche ID eingegeben hat. Als es jemand bemerkte, war der Schaden bereits entstanden.
Das ist die Realität beim Betrieb von KI-Agenten in Produktivsystemen. Sie sind schnell, autonom und zunehmend leistungsfähig. Autonomie ohne Aufsicht ist jedoch ein Risiko. Je mächtiger Agenten werden, desto wichtiger ist menschliche Aufsicht bei Aktionen, die sich nicht rückgängig machen lassen.
Connic Approvals lösen dieses Problem. Erreicht ein Agent einen sensiblen Tool-Call, wird die Ausführung pausiert. Ein Mensch prüft die Aktion und ihre Parameter, genehmigt oder verwirft sie und der Agent setzt den Run fort. Keine Daten gehen verloren, kein Kontext wird vergessen. Der Agent macht exakt dort weiter, wo er aufgehört hat.
Warum Agenten menschliche Aufsicht brauchen
KI-Agenten sind keine klassische Software. Sie treffen Entscheidungen durch probabilistisches Reasoning. Derselbe Input kann in verschiedenen Runs zu unterschiedlichen Tool-Calls führen. Auch ein perfekt geschriebener Prompt garantiert nicht jedes Mal eine perfekt ausgeführte Aktion. Anders als eine REST API, die einen 400-Fehler zurückgibt, nutzt ein Agent mit Zugriff auf einen Delete Endpoint diesen, wenn er das für die richtige Aktion hält.
| Art der Operation | Beispiele | Warum sie Aufsicht braucht |
|---|---|---|
| Destruktiv | Datensätze löschen, Abonnements kündigen, Zugriff entziehen | Unumkehrbar. Ein einziger falscher Tool-Call kann Tausende Nutzer betreffen. |
| Finanziell | Erstattungen verarbeiten, Geld überweisen, Billing ändern | Wenn Geld bewegt wird, sollte ein Mensch zuerst Betrag und Empfänger prüfen. |
| Extern | E-Mails senden, an Drittanbieter-APIs posten, Webhooks auslösen | Sobald eine Nachricht das System verlassen hat, lässt sie sich nicht zurückholen. |
| Compliance | Aktionen nach dem EU AI Act, der DSGVO oder branchenspezifischen Regeln | Vorschriften verlangen, dass qualifizierte Menschen KI-gestützte Entscheidungen prüfen. |
Mit Connic Approvals liegt die Grenze genau dort, wo der Workflow sie braucht. Tool-Calls mit geringem Risiko werden sofort ausgeführt. Riskante Aktionen pausieren und warten auf eine menschliche Entscheidung. Agenten bleiben schnell, wo Geschwindigkeit zählt, und sicher, wo Sicherheit entscheidend ist.
Bei sensiblen Aktionen pausieren Agenten bis zur menschlichen Entscheidung und setzen den Run anschließend automatisch fort. Zusätzlicher Integrationscode ist nicht erforderlich.
Connic kostenlos testenSo funktioniert es
Der Freigabeablauf ist in die Ausführungspipeline des Agenten integriert. Wird ein abgesichertes Tool aufgerufen, pausiert der Runner die Ausführung, erstellt einen Approval-Request, benachrichtigt das Team und wartet. Der vollständige Gesprächsverlauf und Agentenstatus bleiben erhalten. Sobald eine Entscheidung vorliegt, setzt der Agent die Ausführung exakt an der pausierten Stelle fort.
Bei einer Freigabe wird das Tool mit exakt den geprüften Parametern ausgeführt. Der Agent setzt seinen Workflow fort, als wäre nichts geschehen. Alle weiteren Tool-Calls laufen normal weiter, bis möglicherweise erneut ein abgesichertes Tool aufgerufen wird.
Bei einer Ablehnung beendet das Standardverhalten den Run mit einer eindeutigen Fehlermeldung, die den Ablehnungsgrund enthält. Nichts wird ausgeführt. Alternativ setzt on_rejection: continue den Run fort, und der Agent erhält die Ablehnung als Tool-Antwort. Dann kann er reagieren: den Nutzer informieren, einen anderen Weg versuchen oder die Aktion ganz überspringen. In beiden Fällen kann der Reviewer den Grund für die Ablehnung angeben; er wird für Audits protokolliert.
Wenn niemand antwortet, verhindert ein konfigurierbarer Timeout, dass der Run unbegrenzt hängt. Nach Ablauf endet der Run mit einer eindeutigen Timeout-Fehlermeldung. Mit on_rejection: continue setzt der Agent den Run stattdessen fort und behandelt den Timeout wie eine Ablehnung. Der Standardwert ist eine Stunde, lässt sich aber passend zum Workflow festlegen.
Konfiguration
Approvals werden in der YAML-Konfiguration des Agenten deklariert. Die Konfiguration bestimmt, welche Tools eine Freigabe brauchen, legt optional einen Timeout fest und ergänzt eine Nachricht, die den Reviewern erklärt, warum diese Aktion menschliche Aufsicht erfordert.
name: order-processor
model: connic/gpt-5.6-terra
description: "Processes customer orders and handles refunds"
system_prompt: |
You handle incoming customer orders...
tools:
- orders.process
- orders.delete_order
- orders.process_refund
- inventory.check
approval:
tools:
- orders.delete_order
- orders.process_refund
timeout: 600
message: "This order action requires manager approval before execution."In diesem Beispiel werden orders.process und inventory.check sofort ausgeführt. Ruft der Agent jedoch delete_order oder process_refund auf, pausiert der Run und wartet bis zu zehn Minuten auf eine menschliche Entscheidung.
Standardmäßig beenden abgelehnte Approvals den Run. Soll sich der Agent stattdessen anpassen, setze on_rejection: continue. Der Tool-Call liefert dann eine Ablehnungsnachricht zurück und der Agent kann einen anderen Ansatz versuchen oder den Nutzer informieren. Details stehen in der Dokumentation zum Verhalten bei Ablehnungen.
Bedingte Approvals
Nicht jede Erstattung braucht eine Freigabe. Eine Erstattung über 5 $ ist Routine, eine über 5.000 $ sollte ein zweites Paar Augen prüfen. Bedingte Approvals definieren Ausdrücke, die anhand der übergebenen Parameter oder des Request-Kontexts bestimmen, wann ein Tool-Aufruf geprüft werden muss.
approval:
tools:
# Always require approval for deletions
- orders.delete_order
# Only require approval for refunds over $50 or non-admin users
- orders.process_refund: param.amount > 50 and not context.is_admin
# Only require approval for bulk operations
- inventory.bulk_update: param.count > 100
timeout: 600
message: "High-value action detected. Please review before proceeding."Bedingungen greifen auf zwei Datenquellen zu: param.* für die Tool-Parameter und context.* für Werte aus der Middleware. Approvals lassen sich an Beträge, Nutzerrollen, Ressourcentypen oder beliebige Geschäftslogik knüpfen. Ergibt die Bedingung false, wird das Tool sofort ausgeführt. Ergibt sie true, ist eine Freigabe erforderlich.
Benachrichtigungen für die richtigen Personen
Ein Approval-Request hilft nur, wenn ihn jemand sieht. Sobald einer entsteht, benachrichtigt Connic das Team über drei Kanäle:
Das Benachrichtigungsrouting lässt sich pro Agenten und Teammitglied konfigurieren. Das Team für Bestellverarbeitung prüft Erstattungen, das Infrastrukturteam Deployment Approvals. Jede Gruppe sieht nur, was für sie relevant ist.
Vollständiger Audit Trail
Jede Approval-Entscheidung wird mit vollständigem Kontext erfasst: wer sie geprüft hat, wann die Entscheidung fiel, was freigegeben oder abgelehnt wurde und warum. Das ist mehr als Logging. Es ist ein Audit Trail für Compliance-Prüfungen.
EU AI Act: Warum das jetzt wichtig ist
Für Hochrisiko-KI-Systeme in der Europäischen Union ist wirksame menschliche Aufsicht eine ausdrückliche Anforderung. Im offiziellen Text des EU AI Act behandelt Artikel 14, wie Anbieter Aufsicht in Hochrisikosysteme integrieren. Artikel 26 verpflichtet Betreiber, kompetente und autorisierte Personen für diese Mechanismen zu benennen. Connic Approvals machen diese Anforderung zu einer operativen Kontrolle im Agenten-Run.
Die Transparenzpflichten aus Artikel 50 gelten ab dem 2. August 2026. Der AI Omnibus, der seit dem 27. Juli 2026 in Kraft ist, ließ dieses Datum unverändert und verschob die Regeln für Hochrisikosysteme auf Dezember 2027 für Systeme aus Anhang III und August 2028 für in regulierte Produkte eingebettete Systeme. Für betroffene Teams gehören zu den praktischen Aufsichtsmechanismen:
on_rejection wird der Run sauber beendet oder fortgesetzt, wobei sich der Agent an die Entscheidung anpasst.Approvals im Zusammenspiel mit weiteren Compliance-Funktionen
Menschliche Aufsicht ist eine von mehreren Compliance-Anforderungen. Der EU AI Act verlangt außerdem Risikominderung, Daten-Governance, Transparenz und kontinuierliches Monitoring. Wir liefern die Bausteine für all diese Bereiche:
Zusammen bilden diese Features einen Defense-in-Depth-Ansatz. Guardrails verhindern schädliche Inputs und Outputs, Approvals schützen riskante Aktionen durch menschliche Prüfung, Judges bewerten die Output-Qualität, Observability schafft Transparenz und A/B-Testing validiert Änderungen sicher. Das unterstützt solides Engineering und die von Regulierungsbehörden erwarteten Kontrollen.
Szenarien aus der Praxis
Diese Approval-Konfigurationen setzen Teams im Produktivbetrieb ein:
param.amount > 100 bildet die Logik ab, während das Operations-Team die Entscheidungen zu Geschäftszeiten prüft.Erste Schritte
Approvals lassen sich in wenigen Minuten zu einem bestehenden Agenten hinzufügen:
- 1.Die Tools des Agenten ermitteln, die destruktive, finanzielle oder unumkehrbare Aktionen ausführen
- 2.Das Agent-YAML um einen
approval-Block ergänzen, der diese Tools und optional Bedingungen auflistet - 3.Den Agenten bereitstellen. Beim nächsten Aufruf eines abgesicherten Tools pausiert die Ausführung und erstellt eine Freigabeanfrage
- 4.Die Seite Approvals im Dashboard öffnen, um offene Anfragen zu prüfen, freizugeben oder abzulehnen
- 5.Das Benachrichtigungsrouting konfigurieren, damit die richtigen Teammitglieder per E-Mail oder Webhook benachrichtigt werden
Als Ausgangspunkt eignet sich das Tool mit dem höchsten Schadenspotenzial. Nach einem Test des Approval-Flows kann die Absicherung bei Bedarf auf weitere sensible Operationen ausgeweitet werden.
Die vollständige Konfigurationsreferenz steht in der Approvals-Dokumentation. Für den Einstieg in Connic lässt sich mit dem Quickstart-Leitfaden ein erster Agent bereitstellen und anschließend dort um menschliche Aufsicht ergänzen, wo sie am wichtigsten ist.