The EU AI Act entered into force on 1 August 2024 with a 24-month transition for its high-risk rules, which put the headline date at 2 August 2026. That date is no longer settled. In 2026 the EU institutions reached a provisional agreement on the Digital Omnibus that defers the high-risk obligations for stand-alone Annex III systems, credit scoring among them, to 2 December 2027, largely because the harmonised standards needed to assess conformity were not ready in time. The deferral still has to be formally adopted, so treat the timeline as contingent rather than final.
What does not move is the substance. Whether the obligations bind in August 2026 or December 2027, they are obligations about how the system is built and operated, and the evidence they call for has to be produced while you build, not assembled afterward. The extra runway is a reason to do the engineering properly, not a reason to wait.
This is not legal advice. It is a read of the regime as an engineering problem, because that is where most of the work actually lands.
Which finance systems are in scope
The high-risk category for EU AI Act financial services covers uses that decide something material about a person. In practice that means:
- Creditworthiness assessment and credit scoring of natural persons
- Risk assessment and pricing in life and health insurance
- AML and fraud-detection systems
If your model assigns a score that gates a loan, sets a premium, or flags a transaction for review, assume it is high-risk AI and plan accordingly. The specifics matter, and the line between exempt and in-scope is exactly the kind of question to put to counsel. For the build, treat these systems as in scope and work backwards from the deadline that ends up applying to you.
The provider’s side: conformity before deployment
If you build or substantially modify one of these systems, you are a provider, and before deployment you have to run an AI conformity assessment, prepare technical documentation, affix CE marking where it is required, and register the system in the EU database. That sequence has direct consequences for the codebase.
A conformity assessment is a claim about the system that has to survive scrutiny, which means the supporting evidence has to exist while you build rather than get written up at the end. Risk management runs across the lifecycle, so the controls and their rationale need a trail, the same way a model-validation function expects a record of what was tested and why.
Training data is where credit scoring compliance gets concrete. The Act expects data that is representative and documented. For a scoring model that means knowing the population each feature was learned from, and catching point-in-time errors so the model is not trained on information that did not exist at decision time. A lookahead in a backtest is a methodology bug. In a high-risk system it is also a documentation gap you will have to explain.
Proxy discrimination is the next concern. A model can reconstruct a protected characteristic from postcode, occupation, or transaction patterns without ever seeing the attribute directly. Bias checks have to look for those proxies, not just confirm that the protected field was dropped. That is an eval problem: held-out sets sliced by the characteristics you are not allowed to discriminate on, run on a schedule, with the results kept rather than glanced at.
The deployer’s side: oversight that actually works
If you operate someone else’s system, you carry obligations too: human oversight that means something, data-governance checks, monitoring in operation, staff training, and reporting of serious incidents.
The word doing the work there is human oversight. A reviewer who rubber-stamps a score under time pressure is not exercising it, and a regulator can tell the difference. Oversight has to be designed in. The interface shows the reviewer what drove the decision, the volume leaves room to actually look, and the path to override is real. Monitoring in operation is drift detection by another name. A scoring model degrades as the population shifts, and you want the alert before the loss does.
Logging ties both sides together. Serious-incident reporting and any after-the-fact review depend on an audit trail that reconstructs what the system saw and decided. If that logging is bolted on late, it tends to miss the inputs that mattered.
The penalties give the timeline its weight. For breaches of the high-risk obligations, the cap is up to 15 million EUR or 3% of global annual turnover, the tier below the 35 million EUR / 7% reserved for prohibited practices under Article 5. You do not need that number to justify the work, though it does tend to focus attention.
The practical takeaway is the one we apply to any finance system. Lineage, representative training data, evaluation you can defend, and audit logging that exists from the first commit are what let the system stand up to a reviewer. A later deadline does not change that work. It just gives you time to do it without cutting corners, which is the better reason to start now.