Human-in-the-Loop: Freigaben und sichere Eingaben für KI-Agenten

connic approvals pausieren einen Agenten für eine menschliche Prüfung oder eine fehlende Eingabe. Ein mögliches Szenario: Ein KI-Agent löscht Kundendatensätze, nachdem er eine falsche ID erhalten hat. Der Tool-Aufruf kann gültig sein, obwohl die Eingabe falsch ist. Eine menschliche Prüfung vor der Ausführung bietet die Chance, den Fehler zu erkennen. Andere Workflows benötigen zunächst einen fehlenden Wert von einem Menschen, etwa einen MFA-Code, bevor der Agent fortfahren kann.

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. Je nach Regel für Ablehnungen wird der Run fortgesetzt oder beendet. Bei einer Eingabeanfrage liefert der Mensch einen Text, der zum Tool-Ergebnis wird. Der gespeicherte Gesprächsverlauf und Tool-Zustand ermöglichen die Fortsetzung, ohne abgeschlossene Tool-Aufrufe zu wiederholen.

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.

Mit connic approvals findet die Prüfung dort statt, wo der Workflow sie braucht. Tool-Aufrufe ohne Gate laufen ohne Freigabe. Konfigurierte Gates pausieren und warten auf eine menschliche Entscheidung. So können Teams für ausgewählte Aktionen eine Prüfung verlangen.

So 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. Gesprächsverlauf und Agentenstatus bleiben erhalten. Wenn die Entscheidung und die Regel für Ablehnungen eine Fortsetzung erlauben, fährt der Agent aus dem gespeicherten Zustand fort. Aufeinanderfolgende Freigaben und Ablehnungen bleiben beim Fortsetzen gewöhnlicher Runs und der Tests vor einem Deployment erhalten. Das gilt auch für spätere Aktualisierungen zum selben Eingabe-Tool.

Bei einer Freigabe wird das Tool mit exakt den geprüften Parametern ausgeführt. Bei einem generierten Eingabe-Tool wird stattdessen die menschliche Antwort zum Tool-Ergebnis. Alle weiteren Tool-Calls laufen normal weiter, bis erneut ein abgesichertes Tool oder ein Eingabe-Tool aufgerufen wird.

Bei einer Ablehnung beendet das Standardverhalten den Run mit einer Fehlermeldung, die einen angegebenen Ablehnungsgrund enthält. Das abgesicherte Tool wird nicht 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.

version: "1.0"
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 ohne Freigabe 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 from 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 ohne Freigabe ausgeführt. Ergibt sie true, ist eine Freigabe erforderlich. Kann die Bedingung nicht ausgewertet werden, etwa weil ein Parameter fehlt, verlangt connic eine Freigabe.

Menschliche Eingaben als Tool-Ergebnis

Eine Freigabe prüft eine Aktion, für die der Agent bereits alle nötigen Angaben hat. Eine Eingabeanfrage erfasst Informationen, die ihm noch fehlen, etwa einen MFA-Code, eine Bestellnummer oder einen Bestätigungstext. Bei einem LLM-Agenten erzeugt approval.inputs ein benanntes Tool ohne Python-Funktion oder zusätzlichen Eintrag im obersten tools-Abschnitt. Der Agent erhält die menschliche Antwort als Ergebnis dieses Tools.

approval:
  inputs:
    - get_mfa:
        prompt: Request the current MFA code when sign-in requires it.
        params:
          - reason: str
          - account_email: str
        label: MFA code
        sensitive: true
  timeout: 300
  on_rejection: fail

prompt beschreibt dem KI-Modell, wann es die Eingabe anfordern soll; label beschriftet das Feld für die prüfende Person. Hier übergibt der Agent reason und account_email als Kontext, der über dem Antwortfeld erscheint. Parameter unterstützen str, int, float und bool. Jeder definierte Parameter ist erforderlich; zusätzliche Argumente werden abgelehnt. Ohne params nimmt das Tool keine Argumente entgegen. Diese Typen beschreiben den Kontext der Anfrage. Die menschliche Antwort ist immer Text.

Namen für Eingabe-Tools müssen eindeutige ASCII-Bezeichner mit höchstens 64 Zeichen sein. Sie dürfen weder mit konfigurierten Tools kollidieren noch reservierte Namen der Tool-Suche verwenden. Eingabe-Tools zählen zum Limit von 100 Tools pro Agent. Die Approvals-Referenz beschreibt die Regeln für Namen und Parameter. Parameterwerte sind sichtbarer Kontext; Zugangsdaten gehören deshalb in das Antwortfeld.

Im Dashboard bietet eine Eingabeanfrage die Aktionen Provide response und Submit and continue. Über die API wird eine Anfrage mit response_label genehmigt, indem eine Antwort in response an POST /projects/{project_id}/approvals/{approval_id}/decide gesendet wird. Sie darf weder leer sein noch ausschließlich aus Leerraum bestehen:

{"status": "approved", "response": "001234"}

Führende Nullen sowie Leerzeichen am Anfang und Ende einer gültigen Antwort bleiben erhalten. Das Feld reason enthält einen Kommentar zur Entscheidung. Bei gewöhnlichen Freigaben und Ablehnungen entfällt response. Abgelaufene Eingabeanfragen akzeptieren keine nachträgliche Antwort. Eine Feldbeschriftung, die einen bestimmten Bestätigungstext verlangt, prüft diesen nicht; der Workflow muss den eingegebenen Wert weiterhin prüfen. Jede spätere Eingabeanfrage benötigt eine eigene Antwort.

Sensible Antworten, Speicherung und Logs

connic speichert übermittelte Antworten verschlüsselt im Freigabedatensatz. Mit sensitive: true zeigt das Dashboard die Eingabe zusätzlich verdeckt an. connic verschlüsselt betroffene Run- und Session-Daten und ersetzt den unveränderten Antworttext in erfassten Logs und Traces durch [REDACTED]. Ohne diese Einstellung bleibt der Text im Feld sichtbar; die zusätzliche Maskierung entfällt.

Das KI-Modell erhält die Antwort weiterhin als Tool-Ergebnis. Die Maskierung erfasst weder umgeformte Kopien noch Daten, die eigene Tools an externe Systeme senden. Die Browser Automation Demo nutzt dieses Verfahren für eine sensible Passwortabfrage. Eine Prüfung mit einem nur dafür vorgesehenen Testwert sollte die verdeckte Eingabe sowie die Logs und Traces nach dem Fortsetzen des Runs umfassen. Ein verdecktes Eingabefeld allein belegt nicht, dass der unveränderte Wert in den Aufzeichnungen des Runs fehlt.

Benachrichtigungen für die richtigen Personen

connic kann Projektmitglieder und konfigurierte Projektkanäle benachrichtigen, wenn eine Freigabeanfrage eingeht. Die Zustellung hängt von den Einstellungen der Mitglieder und der Weiterleitung an Kanäle ab:

Für Projektkanäle lassen sich bestimmte Agenten auswählen; Mitglieder steuern ihre persönlichen Benachrichtigungen über ihre Einstellungen. Die Weiterleitung erteilt keine Entscheidungsberechtigung. Zum Anzeigen von Anfragen ist approvals.view erforderlich, für Entscheidungen approvals.decide und für die Konfiguration der Weiterleitung approvals.configure.

Vollständiger Audit Trail

Jede Approval-Entscheidung erfasst die prüfende Person, den Entscheidungszeitpunkt, die freigegebene oder abgelehnte Aktion und eine optionale Begründung. Zusammen dokumentieren diese Einträge die menschlichen Entscheidungen während der Agentenausführung.

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 können diese Aufsichtsmaßnahmen innerhalb eines Agenten-Runs unterstützen.

Die Transparenzpflichten aus Artikel 50 gelten grundsätzlich ab dem 2. August 2026. Der AI Omnibus, der seit dem 27. Juli 2026 in Kraft ist, verschob die Regeln für Hochrisikosysteme auf den 2. Dezember 2027 für Systeme aus Anhang III und den 2. August 2028 für in regulierte Produkte eingebettete Systeme. Der Zeitplan der Kommission zur Umsetzung nennt außerdem eine Übergangsfrist bis zum 2. Dezember 2026 für die Pflichten aus Artikel 50 Absatz 2 bei bestimmten Systemen für synthetische Inhalte, die vor dem 2. August 2026 in Verkehr gebracht wurden. Für betroffene Teams gehören zu den praktischen Aufsichtsmechanismen:

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, die ihre konfigurierten Prüfungen erfassen, Approvals sichern ausgewählte Aktionen durch menschliche Prüfung ab, Judges bewerten die Output-Qualität, Observability schafft Transparenz und A/B-Testing validiert Änderungen mit einem kontrollierten Anteil des Traffics. Welche Kontrollen erforderlich sind, hängt weiterhin vom System, seinen Risiken und den geltenden Regeln ab.

Szenarien aus der Praxis

Beispielhafte Approval-Konfigurationen für Workflows im Produktivbetrieb:

Freigabe, Ablehnung, Timeout und Eingaben testen

Tests können Entscheidungen über approval_decisions vorgeben. Das Feld tool verweist auf ein bestehendes Tool oder den Namen eines generierten Eingabe-Tools. Optional schränkt params die Zuordnung anhand der Parameter der ausstehenden Anfrage ein. In diesen Testausdrücken heißt der Zugriff params.*; Freigabebedingungen verwenden dagegen param.*.

defaults:
  strict_approval_decisions: true

tests:
  - name: supplies_mfa_code
    payload: Request an MFA code for demo@example.com, then report completion.
    approval_decisions:
      - tool: get_mfa
        params: params.account_email == "demo@example.com"
        decision: approve
        response: "001234"
    expected_result: status == "completed"

  - name: rejects_mfa_request
    payload: Request an MFA code for demo@example.com.
    approval_decisions:
      - tool: get_mfa
        decision: reject
        reason: Sign-in declined by the test
    expected_result: status == "failed"

  - name: times_out_mfa_request
    payload: Request an MFA code for demo@example.com.
    approval_decisions:
      - tool: get_mfa
        decision: timeout
    expected_result: status == "failed"

Dieses Beispiel bezieht sich auf die obige Eingabekonfiguration mit on_rejection: fail. Die Antwort in Anführungszeichen ist ein Testwert, dessen führende Nullen erhalten bleiben. Bei Ablehnung und Timeout entfällt response. Für eine gewöhnliche Aktionsfreigabe genügt decision: approve ohne Antwort. Anschließend sollte der Test das beabsichtigte Ergebnis der Aktion in einer isolierten Testumgebung prüfen.

Im strikten Modus schlägt ein Testfall fehl, wenn zu einer ausstehenden Anfrage keine Entscheidung passt oder eine vorgegebene Entscheidung ungenutzt bleibt. Ohne passende Entscheidung im nicht strikten Modus endet der Testaufruf mit status == "awaiting_approval". Jeder Entscheidungseintrag wird pro Testaufruf höchstens einmal verwendet. Die Referenz zu Freigabetests erläutert die Zuordnungsregeln.

1. Prüfe, ob eine freigegebene Aktion mit den geprüften Parametern ausgeführt wird und eine Eingabe den vorgesehenen nächsten Schritt erreicht.
2. Teste Ablehnung und Timeout mit der konfigurierten Regel. Prüfe bei continue neben dem Endstatus auch das Verhalten nach der Ablehnung.
3. Teste zwei Pausen in einem Run und prüfe, ob spätere Entscheidungen erhalten bleiben und abgeschlossene Arbeit nicht wiederholt wird. Beziehe die Tests vor dem Deployment ein, falls das Projekt sie nutzt.
4. Verwende einen nur dafür vorgesehenen sensiblen Testwert. Suche nach dem Fortsetzen in den aufgezeichneten Logs und Traces nach dessen unverändertem Text. Prüfe externe Ziele gesondert.

Ein erfolgreicher Endstatus allein belegt nicht, dass der Agent die Antwort korrekt verwendet hat. Ergänze Prüfungen für die Ausgabe oder die Tool-Aufrufe des Workflows. Wo es sinnvoll ist, helfen Mocks für eigenen Code, Seiteneffekte zu kontrollieren. Vorgegebene Entscheidungen ersetzen die menschliche Antwort; sie ersetzen nicht automatisch die nachfolgenden Tools durch Mocks.

Erste Schritte

Approvals lassen sich in wenigen Minuten zu einem bestehenden Agenten hinzufügen:

1. 1

   Die Tools des Agenten ermitteln, die destruktive, finanzielle oder unumkehrbare Aktionen ausführen, und Werte bestimmen, die der Agent von einem Menschen anfordern muss

2. 2

   Das Agent-YAML um einen approval-Block ergänzen, der freigabepflichtige Tools unter tools und benannte Eingabeanfragen unter inputs auflistet, bei Aktionsfreigaben optional mit Bedingungen

3. 3

   Den Agenten bereitstellen. Beim nächsten Aufruf eines abgesicherten Tools pausiert die Ausführung und erstellt eine Freigabeanfrage. Generierte Eingabe-Tools pausieren für den angeforderten Text

4. 4

   Die Seite Approvals im Dashboard öffnen, um offene Anfragen zu prüfen, freizugeben, abzulehnen oder eine Antwort einzugeben

5. 5

   Persönliche Benachrichtigungseinstellungen festlegen und in Enterprise-Projekten die Weiterleitung von Freigabeanfragen an Projektkanäle konfigurieren

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.