EU AI Act Annex III: What a Record-Keeping Obligation Actually Requires
Credit scoring and insurance pricing are Annex III high-risk. Articles 12 and 14 turn that into two artefacts: a log, and an oversight trail.
Who this guide is for
AI vendors and risk teams in credit, lending and insurance
Date check first, because most published guidance is stale. The EU AI Act's high-risk obligations for Annex III systems were deferred by the Digital Omnibus of May 2026 and now apply from December 2027 — not August 2026. If an article dated 2026 still says August 2026, it was written before that change.
That deferral is real relief on the statutory clock and almost none on the commercial one. DORA has applied since January 2025, supervisors are asking now, and bank procurement teams are already requesting AI documentation. The Act sets the horizon; the questionnaire on your desk sets the schedule.
Whether Annex III reaches you
Annex III of the AI Act lists the use cases classified as high-risk. Two of them matter for financial services: evaluating the creditworthiness of natural persons or establishing their credit score, and risk assessment and pricing in life and health insurance.
Two things about that scope catch people out. First, it is about the use, not the technology — a modest model doing credit scoring is in scope, and a sophisticated one doing document summarisation is not. Second, high-risk classification does not require the AI to make the final decision on its own. A system that materially informs a human decision-maker is still performing the function.
There is a well-known exclusion for systems used to detect financial fraud. It is narrower than it is usually quoted as being — worth reading against your actual use case rather than assuming it covers anything adjacent to risk.
Article 12 — records, not logs
Article 12 requires high-risk AI systems to allow for the automatic recording of events over the system's lifetime, at a level that supports traceability appropriate to the system's purpose. The wording is functional rather than prescriptive: it does not hand you a schema.
Working backwards from what traceability has to support, a record needs to answer one question about a single past decision: what happened, and can we show it. That implies a stable set of fields.
- When the system ran, on a clock you can defend.
- Which version of the system and of the model produced the output — not merely which model family.
- What went in and what came out, at a fidelity that makes the decision reconstructable.
- Which identity triggered the run — a person, a service, or an autonomous agent acting with delegated permissions.
- Which reference data or configuration was in force, where it materially shaped the outcome.
- Whether a human reviewed, overrode or escalated — the link into Article 14.
The failure mode is almost never 'we have no logs'. It is that the logs were built for debugging: high volume, short retention, sampled under load, and rotated well before the period a reviewer asks about. A record-keeping obligation is a different artefact with a different lifetime, even if it starts from the same event stream.
Retention is where the difference bites. The Act ties retention to a period appropriate to the system's purpose and to applicable law, and in financial services the applicable law is rarely generous. Days of debug logs will not answer a question about last quarter.
Article 14 — oversight that is evidenced, not designed
Article 14 requires high-risk systems to be designed so they can be effectively overseen by natural persons — people who can understand the system's capacities and limits, stay alert to automation bias, interpret the output, decide not to use it, and intervene or halt it.
Read that list closely and notice how much of it is about a person's actual capability rather than a feature's existence. This is why oversight is the hardest cluster to evidence. A product can ship an approval step, a supervisor can be nominated on an org chart, and a reviewer will still ask the awkward question.
| The claim | The question that tests it |
|---|---|
| A human reviews high-risk outputs. | How many were reviewed last quarter, and how many were overridden? |
| Reviewers can halt the system. | Has anyone ever done so? What happened, and how long did it take? |
| Reviewers are trained on its limits. | What were they told the limits are, and when was that last updated? |
| Oversight is meaningful, not rubber-stamping. | What is the median time between output and approval? |
| The mechanism is active in production. | Show the instances for the last 90 days. |
That last row is not a hypothetical. An oversight step that is enabled in staging and disabled in production, or that silently stopped firing after a refactor, looks identical from the outside to one that works — right up until somebody asks for instances.
Provider or deployer
The Act assigns different obligations to the provider of a high-risk system and to its deployer. If you build and supply the system, you are the provider. If you use one in your own operations, you are the deployer. Many companies are both, for different systems.
One consequence is easy to miss: substantially modifying a high-risk system, or putting it on the market under your own name, can make you the provider of it — including where you built it on top of somebody else's model. Being the provider is a considerably heavier position than being a deployer, and it is not always chosen deliberately.
Non-compliance with the obligations applying to high-risk systems carries administrative fines of up to €15 million or 3% of total worldwide annual turnover, whichever is higher. The higher tier — €35 million or 7% — applies to prohibited practices, which is a different chapter of the Act.
What to do with the extra time
Decide, in writing, whether each AI system you build or operate falls under Annex III — and record the reasoning. The reasoning is the artefact; a conclusion with no reasoning behind it does not survive a challenge.
Take one real decision from last month and try to reconstruct it from what you retain today. The fields you cannot fill are your Article 12 gap list.
Count your oversight interventions for the last quarter. If the count is zero, establish whether that is because nothing needed intervention or because the mechanism is not firing.
Separate record-keeping retention from debug-log retention, so that an operational change to logging cannot quietly shorten the compliance record.
Where Dobby fits
Dobby connects to your AI activity out-of-band — reading run telemetry from CrewAI, LangChain, OpenAI, Google ADK or a custom SDK — and never sits in the request path. It scans each run against the frameworks you activate, including EU AI Act Article 12 record-keeping and Article 14 human oversight, and exports an evidence pack: executive summary, control matrix, a severity-ranked gap report with remediation, findings, framework coverage and a SHA-256 manifest.
Because Article 12 is fundamentally a question about whether a record exists and is sufficient, the four-state verdict does real work here. Where the telemetry cannot demonstrate a control, Dobby returns unverifiable rather than compliant. A record-keeping control that quietly passes on absent evidence is precisely the failure this obligation exists to prevent.
This guide is a practitioner's summary, not legal advice. The obligations are set out in Regulation (EU) 2024/1689 and its implementing acts, and how they apply to a specific system is a question for counsel.