The EU AI Act’s high-risk clock.

Somewhere in your institution there is a model deciding who gets credit. The European Union has an opinion about it. Under the AI Act, AI systems used to evaluate creditworthiness or establish credit scores are classified as high-risk (Annex III, and Article 6(2)), which is the legal way of saying that this is one of the places where the machinery of the Act comes fully to bear.

Those obligations are set to apply from 2 August 2026. One honest caveat before anyone builds a programme around that date: a pending proposal could defer it. Treat the date as the current plan rather than a certainty. But treat the obligations as certain, because the argument about them is over. Only the calendar is in play.

The articles that reach into the architecture

Most coverage of the Act lists its obligations. It is more useful to read them as engineering requirements, because that is what they are.

Article 10 governs the data. Training, validation and testing sets must be relevant, sufficiently representative, and examined for bias. Note what this does to a comfortable industry habit: a credit dataset built only from applicants your policy happened to approve is anything but neutral raw material: it is a selection-biased record of your own past behaviour, and under Article 10 that is a finding to document and mitigate, never a strength to advertise.

Article 12 governs the record. High-risk systems must technically permit the automatic recording of events across their lifetime: logs adequate to trace how the system functioned. Adequate for whom, doing what, is the question worth asking. Logs assembled to satisfy an auditor after an incident are usually the logs that exist. Logs that let someone reconstruct why a particular decision came out the way it did are rarer, and much more expensive to produce retroactively.

Article 14 governs the human. High-risk systems must be designed so that natural persons can effectively oversee them, including the ability to intervene, and to interrupt. Read it carefully and it is a statement about timing. Oversight after the decision has landed on the customer is not oversight. It is commentary.

Why the calendar matters less than the lead time

Here is why the deferral debate is a distraction. Suppose the date moves a year. Nothing in that year changes the nature of what has to be built.

Documenting your data governance is a quarter of work. Standing up a genuine oversight surface is another matter entirely: a place where a named human can see a proposed decision, understand its basis, and hold it before it reaches a customer. That reaches into the action path of systems that were built on the assumption that decisions execute and are reviewed later. Retrofitting a control point into that path, everywhere, is the kind of programme that consumes years and gets quietly descoped into a dashboard.

Meanwhile the same demand is arriving from every direction at once. India’s Reserve Bank wants explainability thresholds and human command over AI models. The US CFPB holds that a complex model is no defence for failing to give a denied applicant specific reasons. The Federal Reserve’s SR 11-7 expects validation before reliance. Four regimes, four vocabularies, one sentence underneath: show that the action was permitted, before it acted, on a record someone else can read.

That is not the letter of any single one of these laws. It is the architecture that answers all of them at once — and it is the reason the institutions treating 2 August as a filing deadline will spend the next two years catching up with the ones who read it as a specification.