jovd83/eu-ai-act-hitl-monitor-skill

EU AI Act HITL Aufsichts-Skill (Human-in-the-Loop)

Nutzen Sie dieses Skill, um einen lose gesteuerten Agenten-Workflow in ein überprüfbares, unterbrechbares und auditierbares Betriebsmodell zu verwandeln.

Behandeln Sie dies als ein Skill der Aufsichtsebene. Erstellen Sie konkrete technische Artefakte wie Richtlinien, Schemata, Übergaben, prüferorientierte Berichte, Zustandsautomaten und Audit-Flows. Verfassen Sie nicht standardmäßig einen generischen Compliance-Aufsatz.

Mission

Entwerfen Sie eine Aufsicht, die ein echter Prüfer unter Zeitdruck nutzen kann:

• erklären, warum die Aktion pausiert wurde
• Beweise, Unsicherheiten und bekannte Risiken in verständlicher Sprache darlegen
• maschinenlesbare Verträge für Richtlinien, Übergaben und Entscheidungsfindung bereitstellen
• Pfade für Genehmigen, Ändern, Ablehnen, Abbrechen und Mehr-Kontext-Anfordern unterstützen
• Timeout-, Eskalations- und veraltete-Überprüfungs-Verhalten explizit definieren
• Laufzeitausführung, skill-lokale Persistenz und gemeinsam genutzte Speicherinfrastruktur trennen

Aufgabenaufnahme

Bevor Sie Artefakte erstellen, ermitteln Sie das minimale Betriebsbild:

• Ziellaufzeit oder Orchestrierungsframework
• Nebenwirkungen, die der Agent auslösen kann
• risikobehaftete Bereiche wie Geld, Identität, Zugriff, Sicherheit oder regulierte Daten
• bestehende Checkpoint-, Speicher- oder Eskalationsfläche
• erwartete Prüferrolle, falls bekannt
• angeforderter Ergebnistyp

Wenn die Anfrage unterspezifiziert ist, stellen Sie nur die minimal notwendigen Fragen, um ein irreführendes Design zu vermeiden. Fahren Sie andernfalls mit konservativen Standardeinstellungen fort und kennzeichnen Sie diese deutlich.

Ergebnismodi

Wählen Sie den engsten sinnvollen Ausgabemodus und kombinieren Sie Modi nur, wenn die Aufgabe dies erfordert.

1. Findings-zuerst-Review

Verwenden Sie diesen Modus, wenn der Benutzer nach einer Überprüfung, Kritik oder einer Retrofitting-Bewertung fragt.

Zurückgeben:

• nach Schweregrad geordnete Findings zuerst
• unsichere Standardeinstellungen und Automatisierungs-Bias-Risiken
• fehlende Kontrollgrenzen
• fehlende Vertrags- oder Prüffelder
• den minimal realisierbaren Korrekturpfad

2. Architekturpaket

Verwenden Sie diesen Modus, wenn der Benutzer einen Systementwurf oder ein Betriebsmodell benötigt.

Zurückgeben:

• Komponenten- und Vertrauensgrenzen
• Pausieren- und Fortsetzen-Ablauf
• Timeout- und Eskalationsverhalten
• Zustandsübergänge
• Speicher- und Prüfannahmen

3. Vertragspaket

Verwenden Sie diesen Modus, wenn der Benutzer typisierte Artefakte oder implementierungsbereite Nutzlasten benötigt.

Zurückgeben:

• Abfangrichtlinie ausgerichtet an ../schemas/interception-policy.schema.json
• Übergabepaket ausgerichtet an ../schemas/handover-packet.schema.json
• Überprüfungsentscheidung ausgerichtet an ../schemas/review-decision.schema.json
• feldebene Annahmen, wenn die Repository-Verträge die Antwort nicht vollständig bestimmen

4. Prüferpaket

Verwenden Sie diesen Modus, wenn der Benutzer einen menschenlesbaren Bericht oder eine Genehmigungsoberfläche wünscht.

Zurückgeben:

• eine neutrale Markdown-Übergabe ausgerichtet an ../examples/handover-report.template.md
• das passende maschinenlesbare Paket, wenn Implementierungsdetails im Umfang sind
• Prüferfragen, Nicht-Genehmigungs-Pfade und Fristen- oder Eskalationsmetadaten

5. Implementierungspaket

Verwenden Sie diesen Modus, wenn der Benutzer Code, Pseudocode, APIs oder stackspezifische Integrationsanleitungen wünscht.

Zurückgeben:

• stackausgerichteter Code oder Pseudocode
• validierte Richtlinien-, Übergabe- und Entscheidungsformen
• Schwärzungs- und Prüfregeln
• Timeout-, veraltete-Überprüfungs- und Wiederholungssicherheits-Handling

Arbeitsablauf

1. Grenze festlegen

Identifizieren Sie die Laufzeit, die Nebenwirkungen, die Persistenzfläche und das genaue Artefakt, das der Benutzer benötigt.

Wenn das Framework unbekannt ist, entwerfen Sie eine laufzeitagnostische Aufsichtsgrenze und kennzeichnen Sie Annahmen explizit.

2. Design an den rechtlichen Kontrollzielen ausrichten

Lesen Sie legal-controls.md vor dem Entwurf des Kontrollmodells.

Übersetzen Sie die Kontrollziele in technisches Verhalten:

• der Mensch kann verstehen, was ansteht
• der Mensch kann Unsicherheiten, Anomalien und Einschränkungen erkennen
• der Mensch kann die Aktion ändern, ablehnen, rückgängig machen oder anhalten
• das Ereignis kann später anhand von Richtlinien, Paketen, Entscheidungen und Spurennachweisen rekonstruiert werden

Optimieren Sie das Design nicht für die schnellste Bestätigung.

3. Abfangrichtlinie definieren

Wenn die Aufgabe operative Regeln benötigt, erstellen Sie einen typisierten Richtlinienvertrag, der an ../schemas/interception-policy.schema.json ausgerichtet ist.

Decken Sie mindestens diese Auslöserfamilien ab:

• geringes Vertrauen oder unzureichende Beweise
• sensible oder irreversible Aktionen
• Anomalien oder instabiles Verhalten
• wiederholte Fehler oder Schleifen
• Richtlinienverstöße wie fehlende Herkunft, Schwärzung, Prüferrolle oder Überprüfungsvoraussetzungen

Wenn Schwellenwerte fehlen, wählen Sie konservative Standardwerte und kennzeichnen Sie diese als Standardwerte.

4. Übergabepaket erstellen

Wenn die Aufgabe eine maschinenlesbare Pausennutzlast benötigt, richten Sie diese an ../schemas/handover-packet.schema.json aus.

Bewahren Sie mindestens Folgendes auf:

• Ausführungs-, Ablaufverfolgungs- und Richtlinienkennungen
• Zusammenfassung der anstehenden Aktion
• geschwärzte Maschinenargumente
• Beweiszusammenfassung
• Unsicherheitszusammenfassung
• bekannte Risiken
• Prüferfragen und empfohlene Aktionen
• Prüferrolle, Frist und Timeout-Fallback
• Prüfreferenzen und Schwärzungshinweise

Verlangen Sie keine Offenlegung einer verborgenen Denkkette. Bevorzugen Sie prägnante Begründungszusammenfassungen und Beweisreferenzen.

5. Entscheidungsvertrag definieren

Wenn die Aufgabe Fortsetzungs- oder Überschreibungsverhalten benötigt, richten Sie diesen an ../schemas/review-decision.schema.json aus.

Unterstützen Sie den geschlossenen Entscheidungssatz:

• approve (genehmigen)
• modify (ändern)
• reject (ablehnen)
• kill (abbrechen)
• request_more_context (mehr Kontext anfordern)

Für modify sind strukturierte Ersetzungen erforderlich, und die ursprüngliche Aktion bleibt blockiert, es sei denn, der Prüfer erlaubt explizit etwas anderes.

6. Pausieren und Fortsetzen sicher implementieren

Lesen Sie hitl-patterns.md beim Entwurf des Laufzeitablaufs.

Bevorzugen Sie native Checkpoint- oder Interrupt-Primitive gegenüber Ad-hoc-Polling.

Machen Sie diese Zustände explizit:

• running (läuft)
• paused awaiting review (pausiert, wartet auf Überprüfung)
• approved (genehmigt)
• modified (geändert)
• rejected (abgelehnt)
• halted (angehalten)
• timed out (zeitüberschreitung)
• resumed (fortgesetzt)

Setzen Sie nie allein aus freiem Prüfertext fort.

7. Auditierbarkeit und Beobachtbarkeit entwerfen

Lesen Sie observability-and-logging.md bei der Wahl der Telemetrie.

Verknüpfen Sie:

• ursprüngliche Anfrage oder Ausführung
• Richtlinienbewertung
• Übergabeerstellung
• menschliche Entscheidung
• fortgesetzte oder angehaltene Ausführung
• endgültiges Ergebnis

Bevorzugen Sie Append-Only- oder manipulationssicheren Speicher, wenn die Umgebung dies unterstützt.

Erforderlicher Antwortvertrag

Befolgen Sie diese Antwortregeln, es sei denn, der Benutzer fordert explizit etwas Engeres an:

• Halten Sie Richtlinienlogik, Übergabenutzlast und Überprüfungsentscheidung getrennt. Fassen Sie sie nicht zu einem undifferenzierten Objekt zusammen.
• Kombinieren Sie maschinenlesbare Ausgabe mit einer kurzen menschlichen Erklärung, wenn ein Prüfer darauf handeln muss.
• Präsentieren Sie bei Kritik- oder Überprüfungsaufgaben zuerst die Findings.
• Bevorzugen Sie bei Implementierungsaufgaben typisierte Artefakte gegenüber reiner Prosa-Anleitung.
• Kennzeichnen Sie Annahmen, anstatt fehlende Produkt- oder Rechtsanforderungen stillschweigend zu erfinden.
• Wenn ein angeforderter Wert nicht verfügbar ist, sagen Sie, dass er nicht verfügbar ist. Erfinden Sie ihn nicht.

Minimale Sicherheitscheckliste

Wenn Sie unter Zeitdruck ein Übergabe- oder Überprüfungspaket erstellen, lassen Sie Folgendes nicht aus:

• Richtlinienreferenz und warum eine Überprüfung erforderlich ist
• Zusammenfassung der anstehenden Aktion
• warum die Aktion jetzt vorgeschlagen wird
• Beweiszusammenfassung
• Unsicherheitszusammenfassung
• bekannte Risiken
• Prüferfragen
• Prüferaktionen über die Genehmigung hinaus
• Prüferrolle und Frist
• Timeout- oder Eskalationsverhalten
• Audit- oder Ablaufverfolgungsreferenzen
• Überprüfung-erforderlich-Status

Speichergrenzen

Verwenden Sie Speicher bewusst:

• Laufzeitspeicher: aktiver Ausführungsstatus, Ablaufverfolgungskontext, Beweisschnappschuss und ausstehende Überprüfungsnutzlast nur für die aktuelle Ausführung.
• Skill-lokaler Speicher: Repository-Artefakte wie Schemata, Beispiele, Evaluierungs-Fixtures und Referenzdokumente.
• Gemeinsam genutzter Speicher: externe agentenübergreifende Infrastruktur für dauerhaftes wiederverwendbares Wissen. Implementieren Sie diese Infrastruktur nicht innerhalb dieses Skills, es sei denn, der Benutzer fordert explizit eine Integrationsgrenze an.

Beförderungsregeln:

• Laufzeitzustand nicht automatisch persistieren
• projektspezifische Muster nicht automatisch in den gemeinsam genutzten Speicher befördern
• nur stabiles, auditierbares und angemessen abgegrenztes Wissen befördern

Leitplanken

• Behaupten Sie keine Rechtskonformität allein durch die Nutzung des Skills.
• Reduzieren Sie Aufsicht nicht auf einen Genehmigungsbutton plus einen Konfidenzwert.
• Legen Sie keine Geheimnisse, Anmeldeinformationen oder uneingeschränkte interne Telemetrie gegenüber Prüfern offen.
• Verschmelzen Sie nicht die Laufzeitsteuerungslogik mit der gemeinsam genutzten Speicherinfrastruktur.
• Erfinden Sie keine Produktanforderungen, die das Risiko wesentlich verändern, ohne sie als Annahmen zu kennzeichnen.
• Präsentieren Sie ein maschinenlesbares Paket nicht als ausreichende menschliche Erklärung.
• Lassen Sie das Timeout- oder veraltete-Überprüfungs-Verhalten nicht undefiniert, wenn der Workflow über die Zeit pausieren kann.
• Lassen Sie nicht zu, dass die Prüferidentität oder die Prüferrolle aus dem Entscheidungsprotokoll verschwindet.

Häufige Fallstricke

Vermeiden Sie diese häufigen Implementierungsfallen:

• Automationsbias: Prüfer neigen dazu, standardmäßig auf „Genehmigen“ zu klicken, ohne die Übergabe zu lesen. Bekämpfen Sie dies, indem Sie einen „Änderer“ verlangen oder eine spezifische Frage im handover_packet stellen.
• Die Falle des veralteten Zustands: Eine Überprüfung kann Minuten oder Stunden nach der Pause erfolgen. Stellen Sie sicher, dass das System prüft, ob die ursprünglichen Bedingungen (z. B. Preis, Bestand oder Sicherheitskontext) vor der Fortsetzung noch gültig sind.
• Kontextlücke: Wenn die Übergabe zu technisch ist, kann der Prüfer keine sinnvolle Aufsicht ausüben. Kombinieren Sie Maschinenargumente immer mit einer menschenlesbaren evidence_summary.
• Implizite Genehmigungen: Behandeln Sie ein „Timeout“ in Hochrisikoszenarien niemals als implizites „Genehmigen“. Timeouts sollten in der Regel einen kill- oder escalate-Pfad auslösen, um konform zu bleiben.
• Datenlecks in Übergaben: Achten Sie darauf, keine personenbezogenen Daten (PII) oder Geheimnisse in das Übergabepaket aufzunehmen, die der Prüfer nicht sehen sollte, selbst wenn diese Daten Teil der internen Überlegungen des Agenten waren.
• Das Anti-Pattern „Aktives Warten“: Vermeiden Sie es, den Agentenprozess zu blockieren oder einen kontinuierlichen Ausführungszustand aufrechtzuerhalten, während Sie auf eine manuelle Überprüfung warten. Verwenden Sie Frameworks mit nativer Interrupt-Unterstützung oder dauerhaften Zustands-Snapshots, um Ressourcenerschöpfung zu vermeiden und mehrtägige Überprüfungssitzungen zu ermöglichen.
• Nur-UI-Validierung: Verlassen Sie sich in risikoreichen Bereichen niemals ausschließlich auf Frontend-Buttons für „Genehmigen“ oder „Ändern“. Validieren Sie die endgültige review-decision-Nutzlast immer gegen das serverseitige handover-packet, um eine manipulationssichere Audit-Spur dessen zu gewährleisten, was tatsächlich überprüft wurde.
• Löschung des Ablaufverfolgungskontexts: Löschen Sie die zwischengeschalteten Tool-Aufrufe oder internen Überlegungen nicht, sobald eine Entscheidung getroffen wurde. Behalten Sie genügend Ablaufverfolgungsmetadaten (Konformität mit Artikel 12), damit ein Prüfer nach einem Vorfall die genaue Umgebung rekonstruieren kann, in der sich der Agent befand, als er die Aktion vorschlug.
• Die Falle der gesprächsweisen Genehmigung: Vermeiden Sie es, den Agenten basierend auf einer einfachen Chat-Nachricht wie „sieht gut aus“ oder „ok“ fortzusetzen. Erzwingen Sie menschliches Feedback in einem strukturierten review-decision-Vertrag, um eine typisierte Begründung zu erhalten und die Verantwortlichkeit für die Überschreibung zu wahren.

Fehlerbehandlung

Wenn die Aufgabe unterspezifiziert ist oder die Umgebung schwach ist, deglieren Sie elegant:

• unbekanntes Framework: Verwenden Sie ein Supervisor-Wrapper-Design und kennzeichnen Sie Annahmen
• fehlender Speicherplan: Beschreiben Sie die minimale Persistenzgrenze, bevor Sie fortfahren
• defekte oder fehlende Richtlinie: Entwerfen Sie eine typisierte Startrichtlinie und kennzeichnen Sie diese als vorgeschlagen
• unbekannte Prüferrolle: Verwenden Sie einen konservativen Platzhalter für die Rolle und weisen Sie darauf hin
• kein Observability-Stack: Verwenden Sie Korrelations-IDs und Append-Only-Audit-Ereignisse als Fallback-Basislinie
• bestehender unsicherer Workflow: Geben Sie zuerst Findings zurück und zeigen Sie den minimal realisierbaren Korrekturpfad

Referenzen

Lesen Sie nur, was die Aufgabe benötigt:

• legal-controls.md: Kontrollanforderungen und rechtliche Grundlage
• hitl-patterns.md: Pausen-, Fortsetzungs-, Zustandsmaschinen- und Timeout-Muster
• handover-schema.md: Vertragsanleitung für Richtlinien-, Paket- und Entscheidungsartefakte
• observability-and-logging.md: Audit- und Telemetriedesign