EU AI Act Article 14, in practice: the working checklist

The EU AI Act is now in force, and the chapter most teams underestimate is Article 14 — Human Oversight. On paper it reads like a soft governance obligation. In the first wave of audits in late 2025 it is the obligation that showed up most frequently in findings.

Article 14 does three concrete things. It requires that a high-risk AI system can be effectively overseen by humans. It requires that each oversight person has the authority and the technical means to intervene. And it requires that the system itself records what it did, in a form the human can act on.

CALLOUT

If you cannot produce a specific decision, the policy version in effect at that moment, and the identity of the human who could have intervened — all cryptographically linked — you are not meeting Article 14 in the way an auditor will test it.

The ten-point checklist

This is the exact checklist our customers walk into their Notified Body conversations with. Nine out of ten items are evidence artifacts. One is a people decision.

• A written designation of the human oversight role, with the system's output types each person is accountable for.
• An intervention path from oversight console to running system that completes in under 60 seconds, documented and tested quarterly.
• A classifier (manual or automated) that labels each inference request with its risk category at request time, not post-hoc.
• A per-decision log containing: input prompt, decision output, policy version SHA, model identifier, and timestamp — all signed in a single record.
• A policy-version registry where every policy revision is content-addressable (SHA-256) and references the person who authored it.
• A retention schedule that satisfies the stricter of Article 12 (10 years for high-risk) or your sectoral regulation (HIPAA 6, GDPR variable).
• An incident reporting workflow routed to a specific inbox at the Market Surveillance Authority, with a stopwatch starting the moment severity thresholds are hit.
• A quarterly review log in which the oversight person signs off that the system continues to behave within its intended purpose.
• A training record for each person named as oversight — minimum one hour per quarter on the system's known failure modes.
• A fundamental rights impact assessment (FRIA) that is current — reviewed any time the system's purpose or model backbone changes.

How this maps to Sentry

Sentry was architected around the shape of this list. The Gateway is the choke-point that produces items 3 and 4 for every request. The Policy Plane is the content-addressable store that gives you item 5. Audit bundles roll up items 3 through 6 into a single tar.gz artifact per period, signed with HMAC-SHA256. The Observatory decision search gives your oversight person item 2 — a 60-second path from alert to decision replay.

Items 1, 7, 8, 9, and 10 are human workflow items. Sentry does not handle them, nor should it — but the alerts, webhooks, and audit bundles plug directly into whatever ticketing or GRC tool your organization runs.

What auditors actually ask for

A pattern we see across the first wave of audits: auditors will pick three random high-risk decisions from the past 90 days and ask you to produce the full evidence packet in the room. If that takes more than ten minutes, the finding writes itself.

The packet contains the prompt, the response, the policy SHA, the model/provider, the latency, and the oversight role for that decision. Our Regulator Response Kit button on each audit bundle produces exactly this packet as a signed JSON artifact. If the auditor wants PDF, we recommend producing the PDF server-side at request time rather than keeping PDFs around — PDFs drift from the signed source of truth.

Where teams go wrong

• Logging but not signing. If any decision log is not cryptographically bound to the policy that produced it, you have no proof the policy was in effect at that moment.
• Treating risk categorization as a design-time decision. Risk category must be stamped on each individual request, because your product's purpose scope will drift — and the audit will test the drift.
• Running oversight through email. Email chains don't satisfy the 60-second intervention requirement under any reasonable reading.
• Forgetting the FRIA. The fundamental rights impact assessment is a living document. A new model or a new prompt template is often enough to require a review.

Bottom line

Article 14 is the only AI Act obligation where your engineering platform is on the hook every day. If your Gateway doesn't produce signed per-request evidence, your audit will cost you four engineering weeks of fire-drilling the day the Notified Body shows up. If it does, the audit is the easiest hour of your quarter.