2026-08-04 · Regulation

The EU AI Act moved. What financial services still has to build.

The original schedule put obligations for Annex III high-risk systems, the category that includes creditworthiness assessment, at 2 August 2026. In 2026 the Digital Omnibus was agreed and moves that date to 2 December 2027, with AI embedded in regulated products under Annex I deferred to August 2028. Several teams have read the headline and concluded the programme can slip a year.

Three reasons that reading is expensive.

• The obligations did not change. The deferral moves a date. Record keeping, transparency, human oversight, and accuracy monitoring are the same duties with the same content.
• The transparency duties already apply. The rules that took effect in earlier phases, including telling people they are interacting with an AI system, were not part of the deferral.
• Evidence is slow. Ongoing monitoring means a history. A bank that starts collecting in mid-2027 will have months of it in December 2027; one that started in 2026 will have years. You cannot backfill an audit trail, and that is rather the point.

Is your agent actually high-risk? #

Most agent deployments in a bank are not. A support agent that answers balance queries and explains fees is not making a decision about access to an essential service. An agent that evaluates creditworthiness, or that materially shapes a decision about access to credit, is squarely in Annex III.

The uncomfortable middle is where most projects actually live: an agent that does not decide but does influence. If the agent summarises an applicant's case for the analyst who decides, the summary is part of the decision path. If it chases documents and explains rejection codes without touching the outcome, it is not. The onboarding use case is written around keeping that line clean, because staying clearly outside the category is cheaper than being marginally inside it.

Two practical notes. Classification is a decision you should record with reasons, because someone will ask how you reached it. And a lower-risk classification does not exempt you from the transparency duties, from GDPR, or from the sectoral supervisor who has their own view about model risk regardless of what the AI Act says.

Record-keeping: logs are not the same as records #

The record-keeping obligation is about traceability of the system's functioning over its lifetime. Application logs fail this in a specific way: they are mutable, usually retained for weeks rather than years, and they do not tie an interaction to the version of the configuration that produced it.

What passes is a record where each entry covers what came in, what the system did, what rules were applied, what went out, and under which version, and where tampering is detectable rather than merely discouraged. Hash chaining gets you the last property cheaply: each entry includes the hash of the previous one, so altering an old entry invalidates everything after it, and the head hash is a single anchor you can verify or publish.

Zolva writes every bus step, message, tool call, guardrail decision, and handover, into that chain by default, with config hashes pinning the exact agent definition, instructions, and policy in force. zolva scorecard audit.db verifies the chain. The audit trail article goes through the contents field by field.

Transparency: two different duties #

They get conflated. One is disclosure to the person: they should know they are interacting with an AI system, which is a product decision about first-message copy and one of the easiest things on this list to get right.

The other is transparency to the deployer and the supervisor: the system's capabilities, limitations, and intended purpose have to be documented well enough that a person operating it can understand what it does. Here declarative configuration earns its keep. An agent defined as YAML plus a Markdown instructions file plus a policy file is the documentation, and it cannot drift from the running system because it is the running system. A compliance officer can read the policy file and see the rules. That is not true of an agent whose behaviour is spread across a Python graph, a prompt template, and three environment variables.

Human oversight: a path, not a paragraph #

The oversight requirement asks for effective supervision by people, with the ability to intervene or interrupt. The common failure is a policy document asserting that humans review outputs, with no mechanism that produces evidence of it happening.

Make the mechanism real and the evidence is a by-product. Declare a handoff on the agent, route it somewhere your team already works, whether a Slack desk or your ticketing system, resume the session with the human's resolution, and record all of it. Then test it: a handoff-graded eval cohort passes only when a session actually escalated, so "escalates on hardship" becomes a gate rather than an aspiration.

Handover also has to be the failure mode. Provider errors and tool crashes should degrade to a human rather than to a vague apology, because an agent that silently fails is an agent with no oversight at exactly the moment oversight matters.

Accuracy and ongoing monitoring #

This is the obligation teams underestimate, and it overlaps almost exactly with what SR 11-7 has asked of model risk management for years: documented validation before deployment, and monitoring that continues afterwards.

Three habits cover it, and each produces its own evidence:

• Gate releases on the worst cohort. Not an average. Define cohorts around the behaviours that must never regress, require a full pass, and run zolva eval evals/ --gate in CI so a prompt change that breaks one cannot ship.
• Keep running after release. A scheduled drift run and adversarial synthetics against staging turn monitoring into a time series rather than a snapshot.
• Close the loop. Every production failure becomes a permanent regression case, so the same defect cannot return quietly. That loop is also the clearest evidence of a functioning quality management process.

Packaging the evidence #

If the controls above are in place, the artefacts already exist; the remaining work is presenting them. That is what zolva compliance does:

zolva compliance audit.sqlite --agents agents/ --eval-report eval.json --out pack.json --gate

It maps the hash-chained audit to record-keeping, the config hashes to the traceable system definition, handover events to human oversight, and eval gates plus the scorecard to accuracy and ongoing monitoring, all against named articles. The chain's head hash is the tamper-evidence anchor, bundle_sha256 self-seals the report, and --gate exits non-zero unless every control passes, which makes it usable in CI.

To be clear about what it is: packaging of evidence you already produce, not a compliance guarantee. Your own mapping and your own sign-off decide adequacy.

Where to start #

1. Classify each agent, write down the reasoning, and keep it with the config.
2. Turn on a tamper-evident audit store now, because retention starts when you start.
3. Move every rule that matters out of the prompt and into policy config.
4. Make handover real and testable, and route it where humans already look.
5. Write the worst-cohort evals and gate CI on them.
6. Run zolva compliance --gate weekly so gaps surface as build failures rather than as findings.

None of this is faster to do in December 2027 than it is now, and the monitoring history is worth more the earlier it starts.

← All posts