# Eu AI Act Hitl Oversight Skill

> Design, review, and retrofit human-oversight controls for autonomous agent systems with pause, review, resume, reject, or halt behavior. Use for EU AI Act Article 12/14 logging, human handovers, typed review-decision contracts, reviewer reports, timeout/escalation rules, or critiques of unsafe approval flows.

- Skill: `jovd83/eu-ai-act-hitl-oversight-skill` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add jovd83/eu-ai-act-hitl-oversight-skill`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jovd83/eu-ai-act-hitl-oversight-skill/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: jovd83 (https://skillmd.com/u/jovd83)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jovd83/eu-ai-act-hitl-oversight-skill

---


# EU AI Act HITL Oversight Skill

> **Version:** 1.0.1  

> **Compatibility:** Designed for Agent Skills compatible coding agents. Repository validation assumes Python 3.11+ and optional Node.js for TypeScript reference typechecking.


Use this skill to turn a loosely governed agent workflow into a reviewable, interruptible, auditable operating model.

Treat this as a supervisory-layer skill. Produce concrete engineering artifacts such as policies, schemas, handovers, reviewer-facing reports, state machines, and audit flows. Do not default to a generic compliance essay.

## Mission

Design oversight that a real reviewer can use under pressure:

- explain why the action is paused
- show evidence, uncertainty, and known risks in plain language
- preserve machine-readable contracts for policy, handover, and decision handling
- support approve, modify, reject, kill, and request-more-context paths
- define timeout, escalation, and stale-review behavior explicitly
- keep runtime execution, skill-local persistence, and shared-memory infrastructure separate

## Task Intake

Before producing artifacts, establish the minimum operating picture:

- target runtime or orchestration framework
- side effects the agent can trigger
- risk-bearing domains such as money, identity, access, safety, or regulated data
- existing checkpoint, storage, or escalation surface
- expected reviewer role if known
- requested deliverable type

If the request is underspecified, ask only the minimum questions needed to avoid a misleading design. Otherwise continue with conservative defaults and label them clearly.

## Deliverable Modes

Choose the narrowest useful output mode and combine modes only when the task calls for it.

### 1. Findings-first review

Use when the user asks for a review, critique, or retrofit assessment.

Return:

- severity-ordered findings first
- unsafe defaults and automation-bias risks
- missing control boundaries
- missing contract or audit fields
- the minimum viable correction path

### 2. Architecture package

Use when the user needs a system design or operating model.

Return:

- component and trust boundaries
- pause and resume flow
- timeout and escalation behavior
- state transitions
- storage and audit assumptions

### 3. Contract package

Use when the user needs typed artifacts or implementation-ready payloads.

Return:

- interception policy aligned to `../schemas/interception-policy.schema.json`
- handover packet aligned to `../schemas/handover-packet.schema.json`
- review decision aligned to `../schemas/review-decision.schema.json`
- field-level assumptions where repository contracts do not fully determine the answer

### 4. Reviewer package

Use when the user wants a human-readable report or approval surface.

Return:

- a neutral markdown handover aligned with `../examples/handover-report.template.md`
- the matching machine-readable packet when implementation detail is in scope
- reviewer questions, non-approval paths, and deadline or escalation metadata

### 5. Implementation package

Use when the user wants code, pseudocode, APIs, or stack-specific integration guidance.

Return:

- stack-aligned code or pseudocode
- validated policy, handover, and decision shapes
- redaction and audit rules
- timeout, stale-review, and replay-safety handling

## Operating Workflow

### 1. Establish the boundary

Identify the runtime, side effects, persistence surface, and the exact artifact the user needs.

If the framework is unknown, design a runtime-agnostic supervisor boundary and mark assumptions explicitly.

### 2. Ground the design in the legal control goals

Read [legal-controls.md](./references/legal-controls.md) before drafting the control model.

Translate the control goals into engineering behavior:

- the human can understand what is pending
- the human can detect uncertainty, anomalies, and limitations
- the human can modify, reject, reverse, or halt the action
- the event can be reconstructed later from policy, packet, decision, and trace evidence

Do not optimize the design for fastest confirmation.

### 3. Define the interception policy

When the task needs operational rules, produce a typed policy contract aligned to [../schemas/interception-policy.schema.json](../schemas/interception-policy.schema.json).

Cover at least these trigger families:

- low confidence or insufficient evidence
- sensitive or irreversible actions
- anomalies or unstable behavior
- repeated failures or loops
- policy violations such as missing provenance, redaction, reviewer role, or review prerequisites

If thresholds are missing, choose conservative defaults and label them as defaults.

### 4. Build the handover packet

When the task needs a machine-readable pause payload, align to [../schemas/handover-packet.schema.json](../schemas/handover-packet.schema.json).

At minimum, preserve:

- run, trace, and policy identifiers
- the pending action summary
- redacted machine arguments
- evidence summary
- uncertainty summary
- known risks
- reviewer questions and recommended actions
- reviewer role, deadline, and timeout fallback
- audit references and redaction notes

Do not require disclosure of hidden chain-of-thought. Prefer concise reasoning summaries and evidence references.

### 5. Define the decision contract

When the task needs resume or override behavior, align to [../schemas/review-decision.schema.json](../schemas/review-decision.schema.json).

Support the closed decision set:

- `approve`
- `modify`
- `reject`
- `kill`
- `request_more_context`

For `modify`, require structured replacements and keep the original action blocked unless the reviewer explicitly allows otherwise.

### 6. Implement pause and resume safely

Read [hitl-patterns.md](./references/hitl-patterns.md) when designing runtime flow.

Prefer native checkpoint or interrupt primitives over ad hoc polling.

Make these states explicit:

- running
- paused awaiting review
- approved
- modified
- rejected
- halted
- timed out
- resumed

Never resume from free-form reviewer text alone.

### 7. Design auditability and observability

Read [observability-and-logging.md](./references/observability-and-logging.md) when choosing telemetry.

Tie together:

- original request or run
- policy evaluation
- handover creation
- human decision
- resumed or halted execution
- final outcome

Prefer append-only or tamper-evident storage when the environment supports it.

## Required Response Contract

Follow these response rules unless the user explicitly asks for something narrower:

- Keep policy logic, handover payload, and review decision separate. Do not collapse them into one undifferentiated object.
- Pair machine-readable output with a short human explanation whenever a reviewer must act on it.
- For critique or review tasks, present findings first.
- For implementation tasks, prefer typed artifacts over prose-only guidance.
- Label assumptions instead of silently inventing missing product or legal requirements.
- If a requested field is unavailable, say it is unavailable. Do not fabricate it.

## Minimum Safe Checklist

If you are producing a handover or review package under time pressure, do not omit these:

- policy reference and why review is required
- pending action summary
- why the action is being proposed now
- evidence summary
- uncertainty summary
- known risks
- reviewer questions
- reviewer actions beyond approval
- reviewer role and deadline
- timeout or escalation behavior
- audit or trace references
- review-required status

## Memory Boundaries

Use memory deliberately:

- Runtime memory: active run state, trace context, evidence snapshot, and pending review payload for the current execution only.
- Skill-local memory: repository artifacts such as schemas, examples, evaluation fixtures, and reference docs.
- Shared memory: external cross-agent infrastructure for durable reusable knowledge. Do not implement that infrastructure inside this skill unless the user explicitly asks for an integration boundary.

Promotion rules:

- do not automatically persist runtime state
- do not automatically promote project-local patterns into shared memory
- promote only stable, auditable, and appropriately scoped knowledge

## Guardrails

- Do not claim legal compliance from skill use alone.
- Do not collapse oversight into an approve button plus a confidence score.
- Do not expose secrets, credentials, or unrestricted internal telemetry to reviewers.
- Do not blur runtime control logic with shared-memory infrastructure.
- Do not invent product requirements that materially change risk without labeling them as assumptions.
- Do not present a machine-readable packet as sufficient human explanation on its own.
- Do not leave timeout or stale-review behavior undefined when the workflow can pause across time.
- Do not let reviewer identity or reviewer role disappear from the decision trail.

## Common Gotchas

Avoid these frequent implementation traps:

- **Automation Bias**: Reviewers often default to clicking "Approve" without reading the handover. Combat this by requiring a "Modifier" or asking a specific question in the `handover_packet`.
- **The Stale State Trap**: A review might happen minutes or hours after the pause. Ensure the system checks if the original conditions (e.g., price, inventory, or security context) are still valid before resuming.
- **Context Gap**: If the handover is too technical, the reviewer can't exercise meaningful oversight. Always pair machine arguments with a human-readable `evidence_summary`.
- **Implicit Approvals**: Never treat a "Timeout" as an implicit "Approve" in high-risk scenarios. Timeouts should usually trigger a `kill` or `escalate` path to remain compliant.
- **Data Leakage in Handovers**: Be careful not to include PII or secrets in the handover packet that the reviewer shouldn't see, even if that data was part of the agent's internal reasoning.
- **The "Busy Wait" Anti-pattern**: Avoid blocking the agent process or maintaining a continuous run state while waiting for manual review. Use frameworks with native interrupt support or durable state snapshots to avoid resource exhaustion and allow for cross-day review sessions.
- **UI-Only Validation**: Never rely solely on front-end buttons for "Approve" or "Modify" actions in high-risk domains. Always validate the final `review-decision` payload against the server-side `handover-packet` to ensure a tamper-proof audit trail of what was actually reviewed.
- **Trace Context Deletion**: Do not delete the intermediate tool-calls or internal reasoning once a decision is made. Retain enough trace metadata (Article 12 compliance) so that a post-event auditor can reconstruct the exact environment the agent was in when it proposed the action.
- **The Conversational Approval Trap**: Avoid resuming the agent based on a simple chat message like "looks good" or "ok". Force human feedback into a structured `review-decision` contract to preserve typed rationale and maintain accountability for the override.

## Failure Handling

If the task is underspecified or the environment is weak, degrade gracefully:

- unknown framework: use a supervisor-wrapper design and label assumptions
- missing storage plan: describe the minimum persistence boundary before continuing
- broken or missing policy: draft a typed starter policy and mark it as proposed
- unknown reviewer role: use a conservative placeholder role and call it out
- no observability stack: use correlation IDs and append-only audit events as the fallback baseline
- existing unsafe workflow: return findings first and show the minimum viable correction path

## References

Read only what the task needs:

- [legal-controls.md](./references/legal-controls.md): control requirements and legal grounding
- [hitl-patterns.md](./references/hitl-patterns.md): pause, resume, state-machine, and timeout patterns
- [handover-schema.md](./references/handover-schema.md): contract guidance for policy, packet, and decision artifacts
- [observability-and-logging.md](./references/observability-and-logging.md): audit and telemetry design