Article 14 asks who the natural person was. Your logs do not know.
An oversight obligation phrased around natural persons meets a logging stack designed around events. The gap is not subtle: one asks who a person was, the other records that a field changed.
What does Article 14 need that your logs do not have?
The natural person. High-risk systems must be effectively overseen by people, and records must let you identify who verified what. Conventional logs record system state, model version and a user id — none of which establishes that an identified human saw the output and formed a view.
- Article 14 is about a natural person's capacity to oversee; Article 12 is about records that make oversight demonstrable. They work together.
- Typical application logs record a decision outcome and an account identifier, which does not identify a natural person or what they were shown.
- A signed statement recording the rendered output, the reviewer's credential and its verification state closes the gap with a small change to the review path.
Part of AI oversight and regulation
Reading the two articles together
| Provision | Substance |
|---|---|
| Article 14 — human oversight | High-risk systems are designed so natural persons can effectively oversee them during use |
| Article 14 — capacity | Oversight persons must be able to understand output, interpret it correctly, decide not to use it, and intervene or halt |
| Article 12 — record-keeping | Systems technically allow automatic recording of events over their lifetime, enabling traceability |
| Together | Oversight must be real, and there must be records that make it demonstrable |
An organisation can satisfy Article 14's design requirements — a person can intervene — while having no records that show anyone did. That is the common posture today.
What a typical log holds
{
"ts": "2026-09-11T14:22:01Z",
"event": "decision.reviewed",
"model": "risk-scorer-v4",
"case_id": "C-88213",
"outcome": "accepted",
"user_id": "u_4471"
}
# Establishes: a request reached the service with a session
# associated with account u_4471.
# Does not establish: a natural person was present,
# what they were shown, or that they read it.Three specific deficiencies. user_id is an account, not a person. outcome is a field, not a decision anyone attested to. And nothing records the rendered output the reviewer supposedly interpreted.
What a record that answers the question contains
{
"statement": {
"system": "risk-scorer-v4",
"case": "C-88213",
"model_output": {
"score": 0.83, "band": "decline",
"top_factors": ["payment_history", "debt_ratio", "tenure"]
},
"rendered_text_digest": "sha256:9c1f...a83e",
"reviewer_decision": "override_to_approve",
"reviewer_rationale": "[free text entered by the reviewer]",
"reviewed_at": "2026-09-11T14:22:01Z"
},
"signature": "...",
"credential": { "id": "...", "user_verified": true,
"enrolled": "2025-11-04" },
"issuer_countersignature": "..."
}The rendered_text_digest is the element that is almost always missing and the one that matters for Article 14's interpretation requirement. It binds the record to what was actually on screen, which is what a person could have interpreted.
Where this bites in practice
Not at deployment. At the first supervisory request or the first contested decision, when someone asks to see the oversight records for a specific case.
- A data subject contests an automated decision and asks what human review occurred
- A supervisory authority requests records for a sample of decisions
- An incident occurs and the question is whether oversight was operating at the time
- A conformity assessment examines whether the oversight design functions in use
In each case the answer "our logs show the decision was accepted by account u_4471" is unlikely to satisfy the person asking.
Scoping this so it stays workable
High-risk systems can produce large decision volumes, and requiring a signature on every one would collapse throughput and produce reflexive approval — which would itself undermine Article 14's effectiveness requirement.
| Decision type | Record |
|---|---|
| Automated, within configured bounds, no human review | System log; the oversight design is the control |
| Human confirms the system's output | Lightweight attestation |
| Human overrides the system | Signed record with rendered digest and rationale |
| Decision with legal or significant effect on a person | Signed record with rendered digest and rationale |
| Human halts or intervenes | Signed record |
The overrides and interventions are the cases that get examined, and they are a small fraction of volume. That is what makes this tractable.
Sequencing before the obligations bite
- Identify which of your systems are high-risk under the classification rules. This is a legal exercise and it gates everything else.
- For each, find the points where a natural person can override, halt or confirm.
- Determine what is currently recorded at those points. In most cases it is an account identifier and an outcome field.
- Add the rendered digest first — it is the cheapest change and the most commonly missing element.
- Add signatures on overrides, interventions and significant-effect decisions.
Step four alone materially improves the record and requires no change to authentication. It is a reasonable first move for organisations still working out their classification.
This describes regulatory structure at a general level and is not legal advice. Classification, applicability and timing are specific to your systems and deployment; take them to counsel.
A worked example: what a sufficient record contains
| Field | Why it is there |
|---|---|
| Identity of the natural person | The Article asks who, not which account |
| Hash of what was rendered to them | Establishes what they actually saw |
| The decision taken | Approve, reject, or escalate |
| Timestamp from an external source | So sequence survives challenge |
| Signature from a credential bound at enrolment | Converts a claim into evidence |
| Issuer countersignature | Ties it to your organisation, verifiable offline |
Rows two and five are the ones missing from every logging system in ordinary use, and they are the two the obligation actually turns on.
Objections and honest limits
“Our audit log already has a user id.” A user id records which session executed an action. It does not record that a person saw the output, and session hijack, shared accounts and automation all break the inference.
“This means approving everything.” No. Scope it to the high-risk decisions with irreversible effect. For most systems that is a small fraction of the volume, and scoping it badly is the main way these programmes fail.
This is a general reading of the structure, not legal advice. Classification and obligations depend on the system and the facts.
Sequencing before the obligations bite
- Classify which systems are high-risk. The scoping decision drives everything.
- Identify the oversight point in each. Where a person could actually intervene.
- Render the effect, not the prompt. The person must see what will happen.
- Capture a signature at that point. From a credential bound at enrolment.
- Keep records verifiable offline. So an authority can check without calling you.
Terms used here
- Natural person
- A human being, as distinct from an account, role or organisation.
- Effective oversight
- Oversight with real authority and real information — the ability to intervene, not just observe.
- Rendered effect
- What the system will actually do, shown to the overseer in terms they can judge.
Frequently asked questions
Does Article 14 require a signature? It does not specify a mechanism. It requires effective oversight by natural persons, and Article 12 requires records enabling traceability. A signature is one way to make the record demonstrable.
Why does the rendered digest matter? Article 14 requires that the person can correctly interpret the output. A record that does not capture what was displayed cannot show what there was to interpret.
Do all decisions need signed records? No, and requiring it would undermine effectiveness by producing reflexive approval. Overrides, interventions and significant-effect decisions are the cases that get examined.
What should we do first? Capture the rendered digest at oversight points. It is the cheapest change, requires no authentication work, and is the element most commonly absent.
Is a user id enough? No. It records which session acted. Shared accounts, session hijack and automation all break the link to a person.
Does this mean approving every output? No. Scope it to high-risk decisions with irreversible effect — usually a small fraction of volume.
Why must records verify offline? So an authority can check them without calling your systems, years later, possibly after the vendor is gone.
Where this fits in Manav
Manav captures exactly what Article 14 asks for: an identified natural person's signature over the rendered effect, countersigned and verifiable offline.
Sources and further reading
- Regulation (EU) 2024/1689 (AI Act) — consolidated text
- Regulation (EU) 2024/1689 — Article 6 and Annex III
- ISO/IEC 42001 — AI management systems
- Published supervisory authority commentary on automated decision oversight.