AI Agent Human Oversight: Was die EU-KI-Verordnung tatsächlich von Ihnen verlangt

Human Oversight im Sinne der EU-KI-Verordnung bedeutet: Eine namentlich bekannte Person kann verstehen, was Ihr Agent tut, ihn übersteuern oder stoppen – und im Nachhinein belegen, dass sie dazu in der Lage war. Für die meisten Agents läuft das auf vier Dinge hinaus, die Sie bauen müssen: ein Capability-Sheet, eine in Code erzwungene Entscheidungsgrenze, einen Stop-Mechanismus der das System wirklich anhält, und ein Protokoll, das jede folgenreiche Entscheidung samt Verantwortlichem dokumentiert. Artikel 14 gilt nur für Hochrisikosysteme – doch wenn Sie in Healthcare, HR, Kreditvergabe oder den öffentlichen Sektor verkaufen, sollten Sie davon ausgehen, dass Sie betroffen sind, und es jetzt einplanen, statt es später unter Beschaffungsdruck nachzurüsten.

Für wen das tatsächlich gilt

Artikel 14 steht in Kapitel III der Verordnung (EU) 2024/1689, dem Kapitel, das Pflichten für Hochrisiko-KI-Systeme festlegt. Ob Ihr Agent als Hochrisikosystem gilt, bestimmt sich nach zwei Anhängen. Anhang I erfasst KI als Sicherheitskomponente eines regulierten Produkts, einschließlich Medizinprodukte. Anhang III listet Anwendungsfälle auf: Biometrie, kritische Infrastruktur, Bildung, Beschäftigung und Arbeitnehmerverwaltung, Zugang zu wesentlichen privaten und öffentlichen Dienstleistungen, Strafverfolgung, Migration und Justizverwaltung.

Übersetzt auf Agent-Anwendungsfälle:

• Kein Hochrisiko: Ein WhatsApp-Agent, der Produktfragen beantwortet und eine Größenempfehlung gibt. Die Transparenzpflichten nach Artikel 50 gelten weiterhin – wir haben diese in Offenlegungspflichten für KI-Verkaufsagenten behandelt.
• Hochrisiko: Ein Agent, der Patientennachrichten triagiert, Stellenbewerber vorsortiert, Kreditakten bewertet oder über die Berechtigung zu einer öffentlichen Leistung entscheidet. Gleicher Stack, gleiches Modell – völlig andere Pflichten.

Die Pflichten aus Anhang III sollten ab dem 2. August 2026 gelten. Der Zeitplan war Gegenstand vorgeschlagener Änderungen – prüfen Sie den aktuellen konsolidierten Text, bevor Sie ein Datum vertraglich festlegen. Was nicht auf den gesetzlichen Termin gewartet hat, ist die Beschaffungspraxis: Krankenhäuser und Behörden verlangen bereits heute Oversight-Dokumentation in Ausschreibungen, weshalb das Thema kommerziell schon jetzt relevant ist.

Was Artikel 14 verlangt – in einfacher Sprache

Der Artikel verlangt, dass Hochrisikosysteme so gestaltet sind, dass natürliche Personen sie während des Betriebs wirksam beaufsichtigen können. Die aufsichtführende Person muss in die Lage versetzt werden:

• die Fähigkeiten und Grenzen des Systems zu verstehen und seinen Betrieb auf Anomalien zu überwachen
• sich des Automatisierungsbias bewusst zu bleiben – also der Tendenz, dem Output zu sehr zu vertrauen
• den Output korrekt zu interpretieren, mit den dafür notwendigen Hilfsmitteln
• zu entscheiden, das System nicht zu nutzen oder dessen Output zu ignorieren, zu übersteuern oder rückgängig zu machen
• in den Betrieb einzugreifen oder ihn durch einen Stopp-Schalter oder ein vergleichbares Verfahren zu unterbrechen

Zwei Dinge werden leicht übersehen. Erstens: Die Pflicht, diese Maßnahmen einzubauen, trifft den Anbieter – also Sie oder Ihre Agentur –, während die Pflicht, kompetente Personen einzusetzen, beim Betreiber liegt. Zweitens: Der Artikel verlangt nirgends, dass ein Mensch jede Aktion genehmigen muss. Die Maßnahmen müssen dem Risiko angemessen sein. Diese Verhältnismäßigkeit ist Ihr Gestaltungsspielraum – und dort liegen die meisten Engineering-Entscheidungen.

Die vier Dinge, die Sie bauen müssen

1. Ein Capability-Sheet

Ein einseitiges Dokument, das mit dem Produkt ausgeliefert wird und angibt, wofür der Agent gedacht ist, womit er getestet wurde, was er nachweislich falsch macht und was er unter keinen Umständen tun darf. Das klingt nach Papierkram – ist aber gleichzeitig die Spezifikation für die nächsten drei Punkte. Wer nicht aufschreiben kann, was der Agent niemals tun darf, kann es auch nicht in Code erzwingen.

2. Eine in Code erzwungene Entscheidungsgrenze – nicht im Prompt

Der häufigste Fehler, den wir in Agent-Demos sehen: ein System-Prompt, der sagt „sende nie eine Nachricht ohne Genehmigung" – und sonst nichts. Ein Prompt ist eine Empfehlung an ein probabilistisches Modell. Er ist kein Berechtigungssystem, und Anthropics eigene Berichte über unbeabsichtigte Agentenaktionen erinnern daran, dass Anweisungen bei ausreichendem Kontextdruck ignoriert werden.

Teilen Sie die Aktionen des Agents in zwei Listen auf. Autonom: abrufen, klassifizieren, zusammenfassen, entwerfen, retrieven. Gesperrt: an einen Patienten senden, einen Datensatz aktualisieren, eine Bewerbung ablehnen, eine Erstattung über einem Schwellenwert auslösen. Erzwingen Sie diese Trennung dann im Tool-Layer. Der Agent erhält ein request_approval-Tool und bekommt send_message gar nicht erst. Der Approval-Service ist gewöhnlicher deterministischer Code mit gewöhnlichen Tests. Wir gehen in Eskalationspfade für AI Agents tiefer auf Routing und Fallbacks ein; die vollständige Härtungsliste findet sich in unserer AI Agent Security Checklist.

3. Ein Stop-Mechanismus, der wirklich stoppt

Artikel 14 ist in Bezug auf Unterbrechung eindeutig. Ein echter Stop-Mechanismus besteht aus drei Teilen: einem Flag, das der Agent vor jedem Tool-Aufruf prüft, der Stornierung bereits laufender Runs und dem Abarbeiten der Warteschlange, sodass nichts von selbst wieder aufgenommen wird, wenn jemand das Flag zurücksetzt. Testen Sie ihn regelmäßig – so wie Sie Backups testen. Wenn das Stoppen des Agents heute bedeutet, DevOps zu bitten, ein Deployment auf null zu skalieren, haben Sie keinen Stopp-Schalter, sondern eine Ausfallprozedur.

4. Ein Aufsichtsprotokoll, das etwas beweist

Das Protokoll ist der Teil, den ein Regulierer, ein Prüfer oder ein Gericht tatsächlich lesen wird. Für jeden folgenreichen Output sollte es Ihnen ermöglichen, fünf Fragen zu beantworten:

• Was hat der Agent gesehen? Inputs, abgerufene Dokumente, Modellversion, Prompt-Version.
• Was hat er vorgeschlagen? Den Entwurf, die Klassifizierung, die empfohlene Entscheidung.
• Was hat der Mensch getan? Genehmigt, bearbeitet, abgelehnt oder gar nicht angesehen.
• Wer war der Mensch? Eine Identität, kein geteilter Service-Account.
• Wann, und wie lange? Eine in unter einer Sekunde erteilte Genehmigung ist ein Stempel ohne Prüfung – das Protokoll sollte das sichtbar machen.

Speichern Sie es append-only, mit der gleichen Sorgfalt, die wir in gerichtsfester Architektur für Healthcare-KI beschreiben.

Unser eigenes Outreach-System liegt weit entfernt vom Hochrisikobereich, ist aber dennoch so gebaut – weil das Protokoll unabhängig von regulatorischen Anforderungen nützlich ist. Es scrapt die Website jedes Prospects mit einer selbst gehosteten Firecrawl-Instanz, und ein lokales LLM extrahiert die relevanten Fakten und schreibt in einem einzigen Call pro Unternehmen eine individuell zugeschnittene E-Mail. Dieses Single-Call-Muster hat eine mehrstufige Chain sowohl in Kosten als auch in Outputqualität übertroffen – und hatte einen Nebeneffekt, den wir nicht geplant hatten: Die Fakten, auf die sich das Modell gestützt hat, und der daraus entstandene Entwurf entstammen demselben Call, sodass der Reviewer die Belege direkt neben der Schlussfolgerung sieht. Außerdem gibt es pro E-Mail genau einen Input und einen Output zu speichern, statt nachträglich eine Kette von Zwischenzuständen rekonstruieren zu müssen.

Automatisierungsbias ist die Anforderung, die übersprungen wird

Die Verordnung nennt Automatisierungsbias explizit – und es ist die Maßnahme, die nahezu kein Agent-Produkt umsetzt. Wenn der Genehmigen-Button standardmäßig fokussiert ist, der Reviewer nur die finale Antwort sieht und die Warteschlange lang ist, ist Ihre Oversight ein Theater – und das Protokoll wird es zeigen.

Drei Design-Entscheidungen beheben das Problem weitgehend:

• Zeigen Sie die Belege, nicht nur die Antwort. Den abgerufenen Abschnitt, den extrahierten Fakt, die ausgelöste Regel.
• Verbergen Sie den Vorschlag bei einer Stichprobe. Lassen Sie den Reviewer bei einem Teil der Fälle ohne Vorinformation entscheiden und vergleichen Sie.
• Verfolgen Sie die Override-Rate pro Reviewer. Null Overrides über Wochen ist ein Warnsignal, kein Erfolgsindikator.

Was das kostet und wie man es einplant

Von Anfang an eingeplant ist Oversight ein überschaubarer Anteil eines Agent-Builds: Der Approval-Service, das Flag und das Log-Schema sind kleine, gut verstandene Komponenten. Nachträglich eingebaut bedeutet es einen Rewrite des Tool-Layers und eine Migration aller historischen Runs, die Sie sich nun wünschen aufgezeichnet zu haben. Wenn Sie einen Hochrisiko-Agenten kalkulieren, setzen Sie diese vier Punkte explizit in den Leistungsumfang, anstatt zu hoffen, dass sie unter „Security" auftauchen.

Wenn Sie eine Agentur für diese Art von Arbeit evaluieren, trennen vier Fragen eine echte Implementierung von einer Folienpräsentation:

1. Zeigen Sie mir den Stop-Mechanismus – und wann er zuletzt getestet wurde.
2. Zeigen Sie mir einen vollständigen Protokolleintrag für eine reale Entscheidung.
3. Welche Aktionen sind gesperrt, und wo im Code wird das erzwungen?
4. Wie erkennen Sie, dass Reviewer aufgehört haben zu reviewen?

Wenn Sie einen Agenten für ein Krankenhaus, ein HR-Team, einen Kreditgeber oder eine Behörde bauen und möchten, dass er den Beschaffungsfragebogen und das anschließende Audit übersteht, sprechen Sie mit uns.