A customer in Dublin applies online for a personal loan and is declined within seconds. The decision came from a credit-scoring model, perhaps with a human glancing at the output, perhaps not.
It feels like one event, but in law it is at least five:
- data protection law governs the automated decision;
- consumer credit law governs the creditworthiness assessment behind it;
- prudential rules govern the model as a source of risk to the bank;
- operational resilience law governs the systems it runs on;
- the AI Act governs it as an AI system.
Each of those laws was written for a different purpose, and none was designed to fit the others. Until the AI Act's high-risk regime applies, much of the practical work of governing AI in banks, insurers, hospitals and utilities will run through older sectoral rulebooks and the supervisors who already know those firms.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since 27 July 2026, deferred the high-risk regime to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. A high-risk system already on the market before the relevant date is caught only if its design changes significantly, and systems intended for use by public authorities must comply by 2 August 2030 (Article 111(2)). It also moved machinery into Section B of Annex I, so the AI Act's requirements are to reach machinery through delegated acts under machinery law, and it allowed the Commission to limit some requirements for other product-embedded AI.
Eight provisions connect the Act to sectoral law. Article 17(4) treats most of the quality management system as satisfied for providers that are EU-regulated financial institutions, and Article 26(5) and (6) do similar work for deployer monitoring and log retention. Article 74 lets sectoral regulators act as market surveillance authorities, and Article 43(3), as amended, has AI Act requirements assessed within the sectoral conformity procedure.
Some requirements are deemed satisfied or integrated; others remain independently applicable. Several of the fault lines run along that divide.
Supervisors have filled the interval with readings of existing law. The EBA has mapped the AI Act against banking law for credit scoring, EIOPA has set out how insurance law applies to AI systems that are not high-risk, and the Medical Device Coordination Group and the AI Board have issued joint guidance. In the UK, the Mills Review has found the overall regulatory framework sound.
Automated credit decisions. Since 5 February 2026, the UK generally permits solely automated decisions with the safeguards Article 22C requires, unless Article 22B restricts them, while in the EU GDPR Article 22 remains a prohibition in principle. The second Consumer Credit Directive, which Member States must apply from 20 November 2026, adds rights to human intervention, an explanation and a review whenever a creditworthiness assessment involves automated processing. A human-reviewed decline can therefore sit outside the UK framework and still carry those rights in the EU.
Insurance. Only life and health insurance risk assessment and pricing is high-risk under the AI Act. EIOPA's Opinion covers other insurance uses and excludes the high-risk ones, so a motor pricing model already sits within EIOPA's sectoral expectations, while a life pricing model's AI Act high-risk obligations wait until 2 December 2027 (and, if it is already in service, apply only on a significant design change under Article 111(2)), possibly under a different authority.
Incident reporting. Article 73(9) narrows AI Act reporting where the provider is subject to equivalent reporting duties under other Union law, while DORA and NIS2 bind the regulated operator, usually the deployer. On the author's reading, a third-party provider may remain under Article 73 even where its customer reports through a sectoral regime. And a discriminatory credit model can harm many applicants without ever registering as a major ICT-related incident.
Medical device updates. A software update to an AI medical device can face two reassessment tests, the MDR's and the AI Act's own concept of substantial modification, and the two may give different answers.
Requirements with no financial-sector relief. Human oversight, data governance, accuracy, robustness and cybersecurity, transparency to deployers and AI literacy must each be met on the AI Act's own terms. A bank can satisfy prudential expectations on human judgement in models and still fall short of an oversight requirement aimed at risks to health, safety and fundamental rights.
In a cross-border lending group, the entity that builds the model may carry the heaviest AI Act burden with the least EU relief. An insurer whose motor and life models share code runs two governance tracks for one set of executives. And a German grid operator and its vendor report one model failure separately, while the people affected have no AI Act right to an explanation, because Article 86 excludes Annex III point 2 systems.
At EU level, the regimes that reach executives personally concern resilience and security. DORA places ultimate responsibility for ICT risk on the management body, and under NIS2 management bodies can be held liable for infringements of its risk-management article. The AI Act penalises operators, with fines of up to €15 million or 3% of worldwide annual turnover for most operator obligations, but creates no general regime of director or senior-manager liability.
National regimes go further in some places. The UK's Senior Managers and Certification Regime, with the Consumer Duty, and Ireland's Senior Executive Accountability Regime can attach accountability for conduct outcomes to senior individuals. Neither is EU law, and neither reaches a firm outside its own scope.
The author's argument, an inference rather than a finding of law, is that where no national regime attaches conduct accountability to individuals, firms may build AI governance around the resilience regimes that reach their executives and add AI Act obligations as documentation. That would leave fairness with the weakest owner. Personal accountability is one plausible reason among several, alongside supervisory intensity, licensing consequences, litigation risk and group control design.
The first step is a register exercise. Map each obligation once, recording which regime each control satisfies and on what legal basis, and confirm which group entity is the provider.
Settle incident duties with vendors, and choose defaults for shared models on purpose where UK and EU rules diverge. Then give a senior individual responsibility for unfair outcomes from each high-risk system, whether or not a statute yet requires it.
The full paper, Who Owns the Harm?, sets out the five fault lines, the three cases, the law on personal accountability, the author's argument about it and the staged steps.