But DORA, GDPR and your supervisor will still make you justify where every workload runs. A detailed evaluation of the EU AI Act and the Digital Omnibus amendments for banks, insurers and asset managers: what they actually mean for the sovereign AI, on-prem and off-prem decision. The Act regulates roles, risk tiers and evidence, not geography. The obligations that bear on location sit elsewhere, and they are already in force. Conflating the two produces both wasted capital and unmanaged risk.
Seven propositions underpin our analysis. Each is evidenced in the sections that follow. If you read nothing else, read these, then check the ones you disagree with.
| # | Proposition | Why it matters and where the evidence sits |
|---|---|---|
| 1 | The AI Act contains no data-localisation requirement. | It is a product-safety-style regime built on roles (provider / deployer), risk tiers and documentary evidence. Nothing in Arts. 8–27, 43, 49 or 72–73 specifies where compute, data or models must sit. Any vendor pitching "sovereign AI for AI Act compliance" is selling you a different regulation's problem. §06 |
| 2 | But it raises the evidentiary bar sharply, and evidence depends on control. | Art. 11 technical documentation, Art. 12 logging, Art. 14 human oversight, Art. 15 robustness and Art. 74 authority access to source code and training data all require that you can produce things. Architectures where the bank cannot see inside the stack fail on producibility, not on geography. §06 |
| 3 | Article 25 is the single largest under-priced exposure. | Fine-tune, re-badge or re-purpose a bought model and you stop being a deployer and become the provider, inheriting conformity assessment, CE marking, EU database registration and a 10-year documentation duty. Annual recalibration of a vendor scorecard is very likely enough. §05 |
| 4 | The residency pressure is real, but it comes from elsewhere. | DORA Arts. 28–30 and the subcontracting RTS, the EBA outsourcing guidelines' third-country test, GDPR Chapter V and Art. 48 against the US CLOUD Act, Data Act Art. 32, the ECB's July 2025 cloud guide, and national schemes such as SecNumCloud. These are the instruments that actually shape hosting. §07 |
| 5 | The Omnibus delay is a planning window, not relief. | Annex III moved to 2 December 2027. DORA has applied since January 2025, GPAI obligations since August 2025, and Art. 50 transparency went live ten days ago. BaFin assumed financial-sector market surveillance on 29 July 2026. Infrastructure decisions have 18–36 month lead times in Europe; the window is roughly one procurement cycle. §03 |
| 6 | Sovereignty is a spectrum of specific controls, not a product you buy. | A US hyperscaler's "sovereign" region reduces regulatory friction and satisfies residency questions. It does not resolve CLOUD Act exposure, Microsoft France told the French Senate under oath in June 2025 that it could not guarantee refusal. Bank-held keys and selective on-prem placement do more real work than the label. §10 |
| 7 | Availability is a separate risk from confidentiality, and it has already materialised. | On 12 June 2026 a US export control order removed Claude Fable 5 and Mythos 5 from every customer worldwide for eighteen days. Sovereign regions, bank-held keys and confidential computing would have made no difference: the restriction attached to the model, not the data. Every control in this briefing addresses who can see your data. None addresses whether you can still run the system. §10 |
Frameworks are easy and answers are falsifiable, so here is the answer first. This is the layered architecture we would recommend to a European bank or insurer today, before any of the reasoning that supports it. Sections 03 to 12 are the evidence; disagree with them and the architecture should change.
The single most important structural point: this is a per-workload decision, not an estate-wide policy. Almost every expensive mistake in this area comes from applying one sovereignty posture uniformly: either paying a premium and a capability penalty across workloads that carry no sensitive data, or leaving genuinely sensitive processing on infrastructure that cannot be defended because that is where everything else already runs.
| Layer | Where we would put it | The specific control, and why |
|---|---|---|
| Frontier model serving and inference | EU-region public cloud, standard tenancy | Capability and cadence live here and there is no realistic substitute. Make it defensible rather than moving it: negotiated DORA Art. 30(2) terms actually signed, EU processing explicitly configured rather than assumed, encryption with bank-held keys via external key management, documented concentration risk, and a second provider qualified on paper. Paying a sovereign premium at this layer buys residency you already have and costs you model access. |
| Sensitive training and fine-tuning data | On-premises, or an ownership-capped EU operator | This is the layer where the compulsion question actually bites, because the corpus is concentrated, re-usable and often special-category. It is also small relative to inference, so moving it is cheap. If one thing in your estate sits outside a US-parented provider's reach, make it this. |
| Art. 12 inference logs | On-premises or EU-native, encrypted at rest | A durable, un-deletable-by-design evidence store containing input signals and inference patterns, dual-compellable if it sits on US-parented infrastructure. Log hashes of inputs rather than raw personal data, keep the log store structurally separate from the source data store, and resolve retention explicitly against the six-month AI Act floor, financial services record-keeping and GDPR storage limitation. |
| Art. 11 / Annex IV technical documentation | Institution-controlled, EU jurisdiction | Ten-year retention under Art. 18, and the artefact a market surveillance authority will actually ask for. Producibility is the binding constraint: if you cannot see into the stack, you cannot write this document. Secure contractual documentation rights from every model and platform vendor now, or accept self-hosted fine-tuning for anything where you are the provider. |
| High-volume, stable workloads | Owned GPU capacity, where utilisation justifies it | Financial crime alert triage, onboarding document processing, internal code assistance. These have stabilised at volume, are predictable, and carry sensitive data. This is where on-premises economics are genuinely favourable rather than aspirational. Build the case per workload on measured utilisation. |
| High-risk inference where continuity is critical | Open weights you can pin, on hardware you control | Not a cost or sovereignty argument, a continuity one. A hosted model can be withdrawn by its vendor's government with immediate effect and no notice, as June 2026 demonstrated, and it can be deprecated on the vendor's schedule rather than yours. Either event leaves your Art. 11 conformity baseline pointing at a system you cannot reach. Holding the weights is the only arrangement no export order penetrates. |
| National-scheme workloads | SecNumCloud-qualified or national equivalent | French sensitive workloads in particular. S3NS demonstrates the ownership-capped model works with foreign technology; treat qualification as the marker your local supervisor will recognise. |
Roughly 60–70% sustained GPU utilisation is the line between on-premises and cloud inference economics. Above it, ownership wins decisively: Lenovo's 2026 total-cost study puts breakeven against hyperscale cloud at as little as six months for sustained high-throughput inference, with up to a 17x advantage per million tokens over a five-year hardware life. Below it, you are carrying idle capacity and cloud elasticity wins.
Set against that, the costs vendor studies underweight: approximately $200k–$400k per eight-GPU node and $4–20m for an enterprise-scale cluster before facilities; 18–36 months to commission a data centre in congested European markets; a two-to-three-year silicon refresh cycle that runs whether the estate is busy or not; and a specialist MLOps, GPU-operations and AI-security team of 10–30 people that most institutions do not currently employ.
Most European banks' AI workloads in 2026 are growing fast, spiky and still changing shape, none of which favours ownership. That is why the recommendation above puts only stabilised high-volume workloads on owned hardware, and why an estate-wide on-premises strategy is usually the wrong answer sold as prudence.
A mid-sized EU universal bank, ECB-supervised, with a French subsidiary. It runs a bought credit-scoring engine that it recalibrates annually on its own book, a generative assistant for internal document work, a financial crime alert-triage model processing high daily volume, and a customer-facing chatbot.
Note what this produces: four different hosting answers inside one institution, and only one of them driven by the AI Act. That is the shape of a correct answer here.
The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It is a timing and simplification instrument. It defers, clarifies and trims. It does not soften the substantive obligations that will land on banks.
Sixteen extra months on Annex III is easy to read as breathing room. It is not, for four reasons. First, nothing else moved: DORA, GDPR, the EBA guidelines, MiFID II, the CCD and MCD, and SS1/23 model risk management in the UK all apply now. Second, Art. 50 and the Art. 49(2) registration duty are live as of ten days ago, and carry the 3% tier. Third, supervisors have already started: BaFin formally assumed market surveillance over AI in regulated financial activity on 29 July 2026, naming customer chatbots, creditworthiness checks, credit scoring and life/health pricing as its surveillance targets. Fourth, and most practically, European data-centre commissioning runs 18–36 months in congested markets and GPU procurement is not instant. If your compliance answer depends on infrastructure you do not yet have, December 2027 is roughly one procurement cycle away.
As of August 2026 no fines have been issued under Art. 99 or Art. 101. National designation is patchy: on the most recent trackers roughly nine Member States have fully designated both market surveillance and notifying authorities (Cyprus, Denmark, Finland, Hungary, Ireland, Italy, Lithuania, Malta, Slovenia), around twelve are partial, including Germany, France, Spain and the Netherlands, and the remainder have designated nothing. All 27 have designated fundamental-rights authorities under Art. 77. Treat these counts as a fast-moving snapshot rather than a stable fact: designations are being made continuously and the split will have shifted by the time you read this. Check the current position for the specific Member States you operate in rather than relying on the aggregate.
For a cross-border group this asymmetry is a planning problem rather than a reprieve. The obligations apply regardless of whether a Member State has organised itself, and the first movers set the interpretive tone. Germany's route is instructive: under the national KI-Marktüberwachungsgesetz, BaFin supervises AI used in regulated financial activities while the Bundesnetzagentur takes everything else, including HR systems inside the same bank. AI supervision is arriving through existing supervisors, not new ones. Your JST and your AI Act market surveillance authority will increasingly be the same building.
EN 18286:2026 on AI quality management systems was published in July 2026, the first harmonised standard under the Act, giving a presumption of conformity for Art. 17. The substantive ones are still in enquiry: prEN 18228 (risk management), prEN 18282 (cybersecurity) and prEN 18229-1 (logging), with publication expected late 2026 to early 2027. The standards delay was itself part of the rationale for deferring Annex III. Practical consequence: firms designing high-risk AI controls in 2026 are building against draft standards, and should assume a reconciliation exercise in 2027.
Two Annex III entries do most of the work in financial services, plus one that catches every employer. The boundaries are sharper than most inventories assume in some places, and much blurrier in others.
Annex III point 5(b): AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud.
Annex III point 5(c): AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.
Annex III point 4: employment, worker management and access to self-employment, recruitment, screening, evaluation, promotion, termination, task allocation and performance monitoring.
Several of the in/out determinations that follow rest on the Commission's draft guidelines on the classification of high-risk AI systems under Art. 6, published for consultation on 19 May 2026. The consultation ran until 23 July 2026, having been extended from 23 June, and final guidelines are expected to be adopted by the end of 2026. They are therefore persuasive but not settled, and the boundary calls in the contested rows below may move on adoption. Two general principles from the draft are worth carrying into any classification exercise: classification turns on the intended purpose alone, and adding human involvement does not remove high-risk status, a provider cannot downgrade a system simply by requiring a human in the loop. Human oversight is a compliance requirement under Art. 14, not a classification escape.
| Use case | Status | Reasoning and residual risk |
|---|---|---|
| Consumer credit scoring / creditworthiness | In | The paradigm case under 5(b). Covers consumer lending and mortgage origination, whether the model is built in-house or bought. A human loan officer in the loop does not remove it if the model materially shapes the outcome. |
| Mortgage affordability assessment | In | Creditworthiness evaluation of a natural person. In scope. |
| Credit limit setting and repricing | In | Establishment or modification of terms for a natural person forms part of creditworthiness evaluation. |
| Life and health insurance underwriting and pricing | In | Express under 5(c): eligibility, risk banding, premium setting, mid-term repricing. EIOPA's August 2025 Opinion deliberately excluded high-risk AI from its own scope and deferred to the Act. |
| HR: CV screening, interview scoring, performance monitoring | In | Annex III point 4, by virtue of the employment relationship, not the sector. Frequently missing from bank AI inventories because it is owned by HR, not the CRO. In Germany the supervisor is the Bundesnetzagentur, not BaFin. |
| Fraud detection | Out | The one express carve-out in 5(b). But the Commission's May 2026 draft guidelines require fraud detection to be the primary intended purpose "preceding all other purposes", a dual-purpose exposure-and-fraud model is not carved out. This is a documentation discipline, not a free pass. |
| AML, KYC and transaction monitoring | Out | No Annex III point captures them. Governed by AMLR (EU) 2024/1624 and EBA ML/TF guidance. Falls back in only if functionally fused with creditworthiness assessment. |
| General insurance (motor, property, travel, commercial) | Out | Point 5(c) is confined to life and health. Multi-line insurers must classify line by line; EIOPA's IDD/Solvency II governance framework applies instead. |
| Algorithmic trading and execution | Out | Not in Annex III, these systems act on instruments, not natural persons. MiFID II Arts. 17 and 19 remain the framework. Academic argument for a "MiFID III" exists; no legislative traction. |
| Robo-advice and suitability assessment | Out | Not high-risk. MiFID II suitability applies independently; Art. 50 chatbot disclosure applies if conversational. |
| Corporate / SME credit scoring (legal entity only) | Out | The adopted text is confined to natural persons. The Commission's original proposal covered legal persons; that did not survive. Commentary that says otherwise is reading the proposal, not the Regulation. |
| SME lending that scores the proprietor or guarantor | Contested | Where the model profiles a natural person's personal financial position to support a commercial facility, 5(b) is engaged on the text. Trending toward "in". Treat as in scope absent contrary guidance. |
| Collections and forbearance decisioning | Contested | Not addressed in the May 2026 guidelines. Assessing whether a person in arrears can service a restructured facility looks like creditworthiness evaluation. Conservative practice treats material collections models as high-risk. |
| Insurance claims handling | Contested | The draft guidelines exclude claims management and product design from 5(c), but they are draft. But where claims AI feeds back into pricing, no-claims recalculation, mid-term repricing; it re-enters as pricing AI. |
| Onboarding with an embedded eligibility gate | Contested | Identity verification alone is out. Once onboarding decides whether the applicant can access a credit product, it starts functioning as creditworthiness assessment, and a broad intended purpose that includes one high-risk function classifies the whole system as high-risk. |
| Logistic regression scorecards | Contested | Whether classical statistical models meet the Art. 3(1) definition of an AI system is unresolved. The ECB flagged this as a live uncertainty in November 2025. Given that these models sit at the heart of most credit decisioning, this is the single highest-leverage open definitional question in the sector. |
Article 6(3) lets a provider disapply high-risk status where a system poses no significant risk and meets one of four conditions: it performs a narrow procedural task; it improves the result of a completed human activity; it detects decision patterns without replacing or influencing human assessment; or it performs a preparatory task. Attractive on its face.
The final sentence closes it. An Annex III system is always high-risk where it performs profiling of natural persons. Credit scoring profiles natural persons by definition. So does life and health underwriting. The derogation therefore has real application only to peripheral tooling, a completeness checker that validates whether an application form is filled in before any human looks at it, a pure data-aggregation utility. Anything that produces a score, rating, ranking or recommendation feeding a lending or underwriting decision cannot use it.
The Commission proposed removing the EU database registration requirement for systems self-assessed as not high-risk. That proposal did not survive the Omnibus. A provider who concludes an Annex III system is not high-risk must document the assessment and register the system under Art. 49(2). The Omnibus trimmed the required fields (deleting Annex VIII Section B points 7 and 9) but kept the obligation. Crucially, this duty was carved out of the December 2027 deferral: it applies from 2 August 2026. Any firm planning to lean on self-assessment is publishing that assessment into a database from now, not in eighteen months. On numbering, verified against the consolidated text: the derogation and its four conditions sit at Art. 6(3), the duty to document the assessment and register under Art. 49(2) sits at Art. 6(4), and Art. 6(5) is the Commission's own obligation to issue classification guidelines.
For Annex III point 5 systems, everything in the credit and insurance space, the conformity assessment route under Art. 43 is internal control under Annex VI. Self-assessment. No notified body. Only Annex III point 1 biometrics require third-party involvement, and then only where harmonised standards have not been fully applied. This materially reduces the cost and the calendar risk of the December 2027 date, and it is frequently misunderstood in board papers that assume a CE-marking certification process with an external assessor. The burden is documentary and organisational, not certification queueing.
Article 25 decides which set of obligations you carry, and the two are not comparable in size. The deployer duties in Art. 26 are operational: use the system as documented, resource the human oversight, keep the logs. The provider duties in Art. 16 run to conformity assessment, EU database registration and ten years of technical documentation. What moves you from one to the other is not an exotic act of engineering. It is fine-tuning a bought model on your own book.
| Provider, the heavy stack (Art. 16) | Deployer, the operational stack (Art. 26) |
|---|---|
| Risk management system across the lifecycle (Art. 9) · data and data governance (Art. 10) · technical documentation to Annex IV (Art. 11) · logging capability by design (Art. 12) · instructions for use and performance disclosure (Art. 13) · human oversight designed in (Art. 14) · accuracy, robustness, cybersecurity (Art. 15) · quality management system (Art. 17) · 10-year documentation retention (Art. 18) · conformity assessment (Art. 43) · EU declaration of conformity and CE marking (Arts. 47–48) · EU database registration (Art. 49) · post-market monitoring (Art. 72) · serious incident reporting (Art. 73) · corrective action and recall (Arts. 19–20). | Use strictly within the documented intended purpose · assign human oversight to competent, resourced, empowered people · ensure input data is relevant and representative · monitor operation and suspend on identified risk · retain logs (minimum six months) · inform workers' representatives before workplace deployment · feed Art. 13 information into the GDPR DPIA · inform affected persons that a decision involved a high-risk system · report serious incidents to the provider · conduct the Art. 27 FRIA · answer Art. 86 explanation requests. |
This is the genuinely unsettled question, and there is no Commission guidance addressing it for non-GPAI high-risk systems. The practitioner position that has consolidated through 2025–26:
| Build pattern | Assessment | Analysis |
|---|---|---|
| Fine-tuning a bought credit model on your own book | Very likely provider | The dominant practitioner view. The vendor model is trained on a market; yours must reflect your portfolio, so this is the most natural thing a bank does, and it is the thing most likely to flip the role. Annual recalibration that updates model weights is very likely sufficient. This is described in the specialist literature as the most expensive available mistake under the Act. |
| Building a purpose-made credit decisioning agent on a foundation model | Provider | Assembling a foundation model with proprietary tools and credit-specific logic into a decisioning system creates a new high-risk system put into service by you. The identity of the underlying model is irrelevant to your role. |
| RAG over internal documents | Depends | No weight changes, but outputs change. Turns on whether it affects compliance with the Section 2 requirements or alters the intended purpose. Adding credit-assessment capability to a general assistant clearly engages Art. 25. Improving information retrieval within the original purpose is a weaker case, unresolved. |
| System-prompt and guardrail configuration | Generally not | Configuration within the provider's documented intended purpose, without weight changes, is not generally treated as substantial modification. Keep the vendor's intended-purpose documentation and prove you stayed inside it. |
| LoRA / parameter-efficient tuning of a GPAI model | Threshold logic | For GPAI models the Commission has indicated a downstream modifier becomes the provider of the modified model where fine-tuning compute exceeds roughly one third of the original training run. LoRA is nowhere near that. But this threshold governs Chapter V GPAI status, its application by analogy to Title III high-risk systems is influential in practice and not authoritative in law. |
Being the provider means producing Annex IV technical documentation: the training data and its governance, the development process including third-party tools, testing procedures and results, the logging schema, the post-market monitoring plan. You cannot write that document about a system whose internals you cannot see. If the model, the fine-tuning pipeline and the evaluation harness sit inside a managed service that will not expose training logs, evaluation artefacts or architecture detail, you have a producibility problem that no amount of contractual assurance fully fixes. This, not data residency, is the AI Act's genuine, and largely indirect, push toward controlled infrastructure. It is satisfied equally well by on-prem fine-tuning or by hard contractual documentation rights from the vendor. It is not satisfied by hope.
The FRIA (Art. 27) is not optional for banks. The obligation reaches deployers that are bodies governed by public law, private entities providing public services, and, expressly, deployers of Annex III point 5(b) and 5(c) systems. A bank deploying credit-scoring AI and an insurer deploying life or health pricing AI are caught directly by the use-case limb; the debate about whether a commercial bank is a "private entity providing a public service" does not need to be resolved to reach the answer. The FRIA must be completed before deployment and must cover the processes involved, the period and frequency of use, the categories of affected persons, the specific risks of harm, the human oversight arrangements, and the governance and complaints measures. It may be integrated into a GDPR Art. 35 DPIA, which is the efficient path, but a DPIA is a data-protection instrument and a FRIA is a fundamental-rights instrument, so the content must be genuinely extended, not relabelled. It is the deployer's duty and is not discharged by the provider's conformity assessment.
Article 86 makes "the computer says no" untenable. Any person subject to a decision taken on the basis of a high-risk Annex III system that produces legal or similarly significant effects has a right to obtain from the deployer clear and meaningful explanations of the role of the AI in the decision procedure and the main elements of the decision taken. Note the two differences from GDPR Art. 22: it sits with the bank rather than the model vendor, and it applies even where a human was formally involved. A generic description of how the model works does not satisfy it; you must be able to explain what drove this adverse output. A black-box gradient-boosted scorecard with no output-level attribution capability will not meet Art. 86. Layer on the Schufa judgment (CJEU C-634/21), which held that a score routinely used as a determinative factor is itself automated decision-making under Art. 22 even where the lender formally decides, and the explainability requirement becomes structural rather than cosmetic.
The claim that the Act is infrastructure-agnostic is correct as a matter of law and needs five qualifications as a matter of practice. None of them is a localisation rule. All of them are producibility and control requirements that a badly chosen architecture can fail.
| Provision | What it actually requires | Infrastructure consequence |
|---|---|---|
| Art. 11 + Annex IV Technical documentation | Where you are the provider: full description of training data and governance, development process including third-party tools, testing procedures and results, logging schema, post-market monitoring plan. Kept current, retained ten years (Art. 18). | The strongest de facto pressure in the Act. Requires visibility into the stack. Opaque managed AI platforms may make compliance impossible. Resolved by either self-hosted fine-tuning or enforceable documentation rights in the vendor contract. |
| Art. 12 Logging | Automatic recording of events over the system lifetime, sufficient to identify risk situations, support post-market monitoring and support deployer monitoring. Deployers retain logs a minimum of six months (Art. 26(6)). | Creates a durable evidence store containing inference patterns, input signals and potentially personal data. Where that store sits on US-headquartered infrastructure it is simultaneously accessible to EU market surveillance authorities and compellable under the CLOUD Act. Log hashing, separation from the personal data store and EU-native placement are the standard mitigations. |
| Art. 15 Robustness & cybersecurity | Appropriate accuracy, robustness and cybersecurity across the lifecycle; resilience to adversarial inputs, data poisoning and model poisoning. Declared metrics in the instructions for use. | No infrastructure mandate; a standard of care that shapes supplier selection and architecture. Where the Cyber Resilience Act applies and its Art. 12(1) conditions are met, conformity there is deemed to satisfy Art. 15 (Art. 42(3)). Intersects with DORA Art. 9 and NIS2 Art. 21, layered, not contradictory. |
| Arts. 21, 26(8) Cooperation duties | Providers and deployers must make documentation available to competent authorities on request and ensure technical accessibility. | Producibility again. Militates against arrangements where access is jurisdictionally uncertain or mediated entirely through a third party's discretion. |
| Art. 74 Market surveillance access | Applies Reg. (EU) 2019/1020. Authorities may obtain access to source code on reasoned request where necessary, and to training data. For systemic-risk GPAI, the AI Office may require full documentation and evaluation results. | If training data or code sits exclusively in a third-country environment subject to conflicting disclosure restrictions, the provider may be practically unable to comply. A risk-management issue rather than a localisation obligation, but a real one for global groups with fragmented data estates. |
The Act was drafted with regulated financial institutions in view, and three carve-outs materially reduce duplication. They are partial, and the exclusions matter more than the reliefs.
The AI Act's deployer minimum is six months (Art. 26(6)). The ten-year figure that appears in some banking guides is not a standalone AI Act provision; it is derived from the interaction with financial services record-keeping (MiFID II, CRD/CRR), DORA incident records, and the ten-year documentation retention that Art. 18 imposes on providers. The practical answer for most institutions will be well above six months and driven by the credit relationship plus limitation periods. Resolve it explicitly in the records policy with stated reasoning rather than defaulting to either number, and note that a long retention period for inference logs containing personal data creates a GDPR Art. 5(1)(e) storage-limitation tension that needs its own documented resolution.
Art. 74(6) allows Member States to designate the sector's national competent authority as the market surveillance authority for AI in that sector, which is precisely what Germany did with BaFin, and what Ireland has signalled with the Central Bank. For significant institutions under ECB direct supervision this produces a two-authority structure: the national authority as AI Act market surveillance authority, and the ECB as prudential supervisor conducting thematic reviews and on-site inspections of AI and digital transformation. The ECB does not hold AI Act market surveillance powers, but its 2026–28 supervisory priorities include a more focused approach to generative AI under the operational resilience priority, and it has said it is actively following national market surveillance and EBA developments. Both will ask. The answers must reconcile.
Five regimes plus a supervisory overlay. None of them mandates data localisation either, a point worth stating plainly, because the sovereignty conversation is frequently conducted as though one of them does. What they collectively require is documented jurisdictional risk assessment, enforceable access and exit, and a defensible answer to the CLOUD Act conflict.
Applying since 17 January 2025, DORA does more to constrain AI hosting than the AI Act does, and it does so without ever mentioning geography as a requirement. Art. 29(3) requires that where subcontracting may involve a provider established in a third country, the financial entity must weigh the benefits and risks. That is a documented assessment duty, not a prohibition. The Commission's rejection and revision of the ESAs' original 2023 draft subcontracting RTS is significant history here: the final text (Delegated Regulation (EU) 2024/1773) settled on chain transparency and risk management, and the Commission deliberately declined to introduce localisation through that route.
What bites instead is the combination of criticality, substitutability and exit. AI workloads embedded in credit origination, fraud and financial crime, or risk management will in most large banks support a critical or important function under Art. 3(22), which pulls the full Chapter V apparatus over them. And the ESAs' own landscape work found that around half of financial entities using critical ICT services from the top providers assessed those services as non-substitutable, rising to roughly three-quarters for the most-used providers. An AI platform that cannot be exited is a DORA problem irrespective of where its data centres are.
On 18 November 2025 the ESAs published the first list of Critical ICT Third-Party Providers under DORA Art. 31, around nineteen entities, with AWS, Microsoft Azure and Google Cloud among them under EBA lead oversight, alongside IBM, Oracle, SAP, Salesforce and providers in payments, post-trade and messaging. (Treat the full roster with care: the hyperscaler designations are well evidenced, the complete list less consistently reported.) Designation means your cloud provider is itself subject to ESA oversight, joint examination teams, information requests, inspections, binding recommendations, periodic penalty payments for non-cooperation. That is genuine assurance. It does not transfer any of your own obligations, and it does not make concentration risk go away; the point of the regime is precisely that concentration was judged systemic.
The EU–US Data Privacy Framework survived its first serious challenge: the General Court dismissed Latombe v Commission (T-553/23) in full on 3 September 2025, upholding the Data Protection Review Court as adequate redress. So adequacy stands, and transfers to DPF-certified US recipients have a clean Art. 45 basis as of today.
The fragility is structural rather than doctrinal. The DPF rests on Executive Order 14086 and on the continuing political relationship between the two blocs; further challenge from NOYB and others is signalled; and the Schrems I and II precedents establish that invalidation is a live tail risk rather than a theoretical one. A bank building a ten-year AI platform strategy on the assumption of permanent adequacy is taking an unpriced bet. The rational response is not to avoid US providers; it is to ensure that the architecture degrades gracefully if adequacy falls: bank-held keys, EU-resident processing configured by default, and a genuine exit path.
Underneath adequacy sits the harder conflict. GDPR Art. 48 provides that a third-country authority's order to disclose personal data is recognisable in the EU only if grounded in an international agreement such as an MLAT. The US CLOUD Act is not such an agreement, and no EU–US bilateral executive agreement under it has been concluded. Data Act Art. 32 builds the parallel shield for non-personal data, requiring providers to take technical, legal and organisational measures against conflicting international governmental access. Both provisions are real, and both depend on the provider's willingness and legal capacity to resist an order it is jurisdictionally bound to obey. That is the unresolved centre of the entire sovereignty debate.
It establishes that sovereignty certification does not require European technology. It requires European control over data access and operations, European ownership structure, European-cleared operating personnel, European key custody, tightly scoped and audited remote intervention by the technology partner. This is the template the EU-level framework is now codifying, and it is the most useful mental model for evaluating any "sovereign" offer put in front of you: ignore the branding, and ask who can technically reach the data, under whose employment contract, subject to which country's compulsion.
DORA prescribes roughly 47 terms for ICT arrangements supporting critical functions. None of them contemplates a government order withdrawing one specific model while the service otherwise performs normally. A fully DORA-compliant contract therefore leaves this exposure open, and standard vendor terms close it in the provider's favour.
The Cloud Legal Project at Queen Mary University of London surveyed 20 standard contracts for chat-based generative AI services from 13 providers, including Anthropic, Google, Microsoft, OpenAI, Alibaba, DeepSeek and Mistral. The pattern across them is consistent: export control clauses are non-specific and put the compliance warranty on the customer, which understates the provider's role in enabling compliance; supported regions are listed and may be changed unilaterally during the term; termination for convenience and suspension where required by law are reserved to the provider; and government orders are commonly treated as force majeure, relieving the provider of performance while the customer's payment obligation continues.
Where a deal is large or strategic enough to negotiate, three asks materially change the risk allocation:
Independently of drafting, any critical implementation needs a business continuity plan for the case where access disappears overnight. That is no longer a hypothetical scenario to satisfy a policy document.
There is no UK AI Act, and none is imminent. UK banks operate under principles-based supervision with SS1/23 model risk management as the closest functional analogue to the Act's high-risk obligations, SS2/21 for outsourcing and third-party risk (updated March 2026, effective 18 March 2027 under PS7/26), and the critical third parties regime under FSMA 2023 and PS16/24 now in force. The Data (Use and Access) Act 2025 adds an automated decision-making basis and a complaint right from 19 June 2026.
Three practical consequences for a UK-headquartered group with EU subsidiaries. First, the AI Act reaches you anyway: it applies to providers and deployers placing AI on the EU market and where system outputs are used in the EU, so the lighter domestic regime offers no exemption. Second, SS1/23 validation discipline is directionally aligned with Arts. 9–11 but does not satisfy them, different artefacts, different addressees. Third, on infrastructure, DORA is the more demanding standard, so the efficient answer is almost always a single DORA-grade contractual and architectural baseline applied group-wide, rather than parallel estates. Building to DORA generally subsumes SS2/21 and the UK CTP expectations; building to UK standards and retrofitting for DORA does not work.
"On-prem", "off-prem" and "sovereign" are used loosely enough to be useless in a control document. Six tiers, with the distinctions that carry regulatory weight.
"On-prem" now includes provider-managed hardware inside your own data centre. Azure Local, AWS Outposts, Google Distributed Cloud, and arrangements where a provider's cloud is hosted within the bank's facilities. BNP Paribas has run IBM Cloud inside its own data centres since 2019 and renewed for ten years in April 2025 with GPU capacity and a dedicated area planned for 2028. That is a materially different risk profile from either classic outsourcing or classic self-build, and it is under-represented in most banks' option analysis.
The observable pattern across tier-one European institutions is diversification, not repatriation. EU-region hyperscaler cloud for core workloads, hosted frontier models for capability, and selective sovereign or on-premises placement for the most sensitive or highest-volume workloads. One clear exception proves instructive.
| Institution | Pattern | Detail |
|---|---|---|
| La Banque Postale | Sovereign on-prem | May 2026: three-year partnership with Mistral AI deploying models on the bank's own servers and in its own data centre, with a Mistral team embedded in the bank's IT function. 5,000 employees initially; customer relations, AML and fraud, and coding. Sovereignty was the stated rationale, within the Caisse des Dépôts digital plan. The clearest sovereignty-driven infrastructure decision in the European public record. |
| BNP Paribas | Provider-in-our-DC | Nearly 1,000 AI use cases; central AI factory with an LLM-as-a-service platform and federated business-unit governance. IBM Cloud hosted inside BNP data centres since 2019, renewed for ten years April 2025 with GPU access and Red Hat OpenShift. Deliberately multi-tool on coding assistants to avoid lock-in. CTO framing: don't underestimate the risk of spreading everything outside. |
| Unicaja Banco | Explicit hybrid | April 2026: own on-premises AI factory combined with Google Cloud and NVIDIA AI Enterprise, running open models via NIM microservices alongside commercial models. Stated aim of retaining sovereignty and full control within a hybrid architecture. The clearest published hybrid reference architecture from a mid-sized European bank. |
| Intesa Sanpaolo | EU-region cloud | July 2026: completed migration of core banking to Google Cloud's Milan and Turin regions in TIM data centres , 800+ applications migrated, 800+ decommissioned. Residency satisfied by in-country regions rather than a sovereign SKU. |
| UniCredit | Single-partner cloud | Ten-year MoU with Google Cloud (May 2025) across 13 core European markets, AI workloads on Vertex. No sovereign or on-premises component announced, the clearest counter-example to the sovereignty thesis. |
| ING | Centralised, EU-resident | Standardised on cloud-hosted models with EU-based servers; 90% pilot-to-production rate against a ~30% industry average; 75% of customer queries handled by generative chatbots; agentic AI in mortgage processing. Publicly acknowledges residual continuity dependencies even with EU servers. |
| Santander | Multi-model at scale | AI access extended to all 185,000 employees (June 2026); 280+ automation agents in production; ~40% of code AI-generated; €35m value in Q1 2026 against a €1bn+ 2026–28 target. Multi-provider across Microsoft, OpenAI, Anthropic and Google, with an explicit policy against sharing customer data to train third-party models. |
| HSBC | Deep partnership | June 2026 multi-year partnership with Google Cloud and DeepMind; 600+ applications already on Google Cloud; 200+ AI use cases planned over two years, with financial crime detection across roughly a billion transactions monthly. |
| Barclays | Productivity-first | Microsoft 365 Copilot to 100,000 employees from June 2025 following a 15,000-user trial. No published sovereignty constraint. |
The sector-level read matches the individual cases. Morningstar DBRS commentary in March 2026 described European banks shifting some workloads toward domestic providers. OVHcloud, IONOS, Scaleway, while retaining hyperscaler access for AI and advanced services, keeping the most critical systems in-house, and strengthening European provider relationships to meet data-governance expectations and reduce exposure to external political pressure. Gartner-sourced figures circulating in 2026 put roughly 61% of European CIOs planning to shift more workloads to local providers and 44% having begun. "Begun" almost universally means adding at the margin. No major European bank has publicly executed a full cloud repatriation.
The on-premises option is materially better than it was three years ago. Open-weight models suitable for regulated deployment now include the Llama and Mistral families, Qwen, NVIDIA's Nemotron line and others, served through NVIDIA AI Enterprise and NIM, Red Hat OpenShift AI, IBM watsonx on OpenShift or Z/LinuxONE, Dell AI Factory, HPE Private Cloud AI or Lenovo reference architectures. For structured, well-scoped tasks, document classification, internal-corpus question answering, code generation, summarisation, a well-run 70B-class model delivers most of the value of a frontier model. The gap persists on open-ended reasoning, complex multi-step agentic work and tasks needing current world knowledge, which is precisely where research synthesis and broad customer-facing assistants live. Chinese-origin weights, however permissively licensed, face internal review friction in most European institutions regardless of the fact that self-hosting eliminates the data-exfiltration concern.
On economics, the vendor-published analyses are directionally right and conditionally true. Lenovo's 2026 total-cost study puts breakeven against hyperscale cloud at as little as six months for sustained high-throughput inference, with up to a 17x advantage per million tokens over a five-year hardware life. That holds above roughly 60–70% sustained GPU utilisation and collapses below it. Against it, count what the vendor studies underweight: capital outlay of roughly $200k–$400k per eight-GPU node and $4–20m for an enterprise-scale cluster before facilities; European power and grid constraints pushing data-centre commissioning to 18–36 months in dense markets; a two-to-three-year silicon refresh cycle running whether or not the estate is busy; and a specialist MLOps, GPU-operations and AI-security team of ten to thirty people that most banks do not currently employ and will compete hard to hire.
On-premises AI economics are a bet that your workload is high-volume, predictable and durable. Most European banks' AI workloads in 2026 are none of those things; they are growing fast, spiky and still changing shape. That argues for cloud elasticity now and targeted on-premises capacity for the specific workloads that have already stabilised at volume: document processing in onboarding, financial-crime alert triage, internal code assistance. Build the on-prem case per workload with measured utilisation, not as an estate-wide strategy.
This section exists because the gap between what sovereign cloud is sold as and what it demonstrably delivers is the largest single source of misallocated spend in this area.
On 10 June 2025, Microsoft France's director of public and legal affairs was asked under oath before the French Senate's commission of inquiry into public procurement and digital sovereignty whether he could guarantee that French citizens' data would never be transmitted to US authorities without French authorisation. His answer: no, he could not guarantee it. He confirmed Microsoft resists ill-founded requests, that the situation had not arisen, and that under the CLOUD Act a US company can be compelled regardless of where data is stored.
That testimony is the most useful artefact in the entire sovereignty discussion, because it settles a question that marketing material otherwise leaves ambiguous. EU data residency commitments from US-parented providers, including sovereign-branded offerings, reduce practical exposure and do not eliminate the legal conflict. Against roughly 70% of the European cloud market held by three non-EU hyperscalers, and EU providers' share having fallen from 29% in 2017 to about 15% in 2022, that is a structural condition, not a vendor-selection error.
| Genuine risk reduction | Theatre, or at least materially oversold |
|---|---|
|
Bank-held encryption keys. External key management with the bank's own HSMs means an order served on the provider returns ciphertext. The single highest-value control available. Keeping the most sensitive data out of the AI path entirely. If customer PII, positions or MNPI never reach the hosted model, the compulsion question is moot for that workload. EU-region configuration. Genuinely answers the residency question a DPO audit or JST review will ask, and satisfies the ECB's approved-jurisdiction expectation. Provider diversification. Directly addresses the DORA concentration and substitutability findings, which are enforceable today. Negotiated DORA addenda with real audit and documentation rights. Boring, unglamorous, and the thing an examination will actually test. Ownership-capped operators for the most sensitive workloads. The only structural answer to the compulsion problem. |
Believing a sovereign SKU resolves CLOUD Act exposure on unencrypted data. The Senate testimony settles this. Assuming an EU data boundary covers everything. It does not, support engineering, threat intelligence and parts of the AI service surface sit outside, and EU processing for AI services generally has to be explicitly configured. A 2025 survey found 43% of EU enterprises believed otherwise. Treating a locally-operated partner cloud as fully immune. Where the technology stack and its intellectual property remain with a US parent, residual dependency remains even when data and operations are local. Treating a sovereign region as protection against unavailability. It protects confidentiality, not continuity. In June 2026 an export order removed two frontier models from every customer worldwide; no sovereign SKU, key arrangement or enclave would have kept them running. Conflating residency with operational sovereignty. Residency is where bytes sit. Operational sovereignty is whether the European entity can keep running if the parent is compelled, sanctioned or ordered to withdraw. Different questions, different evidence. Buying sovereignty for workloads with no sensitive data. Paying a premium and a capability penalty to protect a document-summarisation tool that touches nothing confidential. |
Everything above concerns confidentiality: who can reach your data, under whose compulsion. In June 2026 the sector was handed a worked example of a different failure mode entirely.
Eighteen days of total unavailability, with no notice, imposed on a vendor that objected. Four things follow for anyone making a hosting decision.
First, no sovereignty control in this briefing would have helped. The restriction attached to the model, not to the data. An EU sovereign region, bank-held keys, confidential computing, an ownership-capped operator: none of them keeps a withdrawn model running. The §08 spectrum grades residency and compulsion exposure; until now it graded availability nowhere.
Second, an order narrow in intent produced total unavailability, because compliance at the intended granularity was infeasible. The directive targeted nationality, not geography. Because nationality cannot be verified per request in real time, the only available compliance path was switching the model off for everybody. Do not assume a restriction aimed at someone else leaves you unaffected; assume instead that the blast radius is set by what the vendor can technically enforce, not by what the order intended.
Third, routing through your existing cloud provider made recovery slower, not faster. Direct platform access returned on 1 July; the hyperscaler channels followed. An institution consuming frontier models through Bedrock or Foundry had a longer outage than one on the direct API, which inverts a common assumption about the resilience benefit of buying through an incumbent.
Fourth, it settles the question of what vendor resistance commitments are worth. Microsoft pledges to contest government orders promptly and vigorously; Anthropic publicly disputed this one. Both are sincere and both are beside the point against an immediate directive. Two independent episodes now say the same thing, and neither involved a vendor behaving badly.
For a bank the consequences are concrete rather than atmospheric. A high-risk system certified against a specific hosted model would have been unavailable, with its Art. 11 conformity baseline pointing at something it could not reach, and its DORA exit plan tested for real rather than on paper. Art. 28(8) substitutability, Art. 29 concentration risk and business continuity all now have a dated worked example, and the standard vendor contract allocates the loss to the customer.
The unit of decision is the workload, not the estate. Four questions determine placement, in this order, and the first two are AI Act questions while the second two are everything else.
| Workload | AI Act position | DORA | Indicated placement |
|---|---|---|---|
| Credit scoring / affordability, recalibrated in-house | High-risk, provider | CIF | Controlled infrastructure: on-prem or sovereign operator, bank-held keys, full pipeline visibility for Annex IV. This is the workload with the strongest case, and it is the strongest case on producibility and compulsion, not on the AI Act's text. |
| Vendor credit engine used strictly as supplied | High-risk, deployer | CIF | Vendor's choice of hosting, subject to DORA Art. 30(2) terms, audit rights, exit plan and residency configuration. Guard the deployer status contractually, no silent recalibration. |
| Life / health underwriting and pricing | High-risk | CIF | As credit scoring. FRIA required before deployment. |
| Financial crime: AML, transaction monitoring, fraud | Outside Annex III | CIF | DORA-driven, not AI Act-driven. High volume and predictable, often the best genuine on-prem economics in the bank. Keep fraud detection documented as the primary purpose. |
| Customer-facing chatbot / voicebot | Art. 50 live now | Often CIF | EU-region hosted frontier model is normally right. Disclosure must be in the interaction design, not the terms and conditions. Do not rely on the "obviously obvious" exception for a retail banking bot. |
| HR screening and performance evaluation | High-risk (point 4) | Rarely CIF | Usually vendor-hosted SaaS. The gap is inventory and ownership, not infrastructure. Different supervisor in some Member States. |
| Internal code assistance and document summarisation | Out of scope | Not CIF | Public or EU-region cloud. Sovereignty spend here is misallocated. On-prem justified only on utilisation economics at scale. |
| Research synthesis and market commentary | Art. 50(4) | Not CIF | Hosted frontier models. Where AI-generated text informs the public on matters of public interest, either disclose or maintain genuine human editorial responsibility with a named accountable person. |
These are the points where confident advice should make you suspicious. Each needs a documented institutional position, revisited as guidance lands.
| Question | State of play | Suggested holding position |
|---|---|---|
| Do classical statistical models count as AI systems? | Unresolved under Art. 3(1). The ECB flagged logistic regression explicitly as a live uncertainty in November 2025. | The highest-leverage question in the sector, because these models sit at the heart of credit decisioning. Assume in scope for governance purposes; document the reasoning; do not build a compliance strategy that collapses if the answer goes the other way. |
| What level of modification triggers Art. 25? | No Commission guidance for non-GPAI high-risk systems. The one-third-of-training-compute threshold is a GPAI concept applied by analogy. | Treat weight-updating recalibration as a trigger. Document configuration-only changes carefully to defend the deployer position. Revisit when interplay guidelines arrive by August 2027. |
| Collections and forbearance AI | Not addressed in the May 2026 draft guidelines. Textually arguable both ways. | Treat material collections decisioning as high-risk. The cost of over-inclusion is documentation; the cost of under-inclusion is a misclassified system in a supervised portfolio. |
| Dual-purpose fraud and credit models | The carve-out requires fraud detection to be the primary purpose "preceding all other purposes". Not case-tested. | Separate the systems where you can. Where you cannot, make the intended-purpose documentation unambiguous at design time; this is won or lost in the specification, not in the argument afterwards. |
| What a sufficient FRIA looks like | No authoritative content guidance for credit or insurance. AI Office template pending. | Build to the Art. 27 list, integrate with the DPIA, and keep it updatable. Expect to redo the first cohort once the template lands. |
| Will EU sovereignty grading become binding? | EUCS unadopted; the Cloud and AI Development Act (COM(2026) 502, June 2026) is at proposal stage and would drive Member State sovereignty risk assessments per use case. | Do not procure today against a framework that does not exist. Do ensure contracts contain termination rights triggered by a provider's inability to meet changed EU data-location law, the ECB guide already signals this as good practice. |
| Does DPF adequacy hold? | Upheld in Latombe (T-553/23, Sept 2025). Further challenge signalled; dependent on US executive arrangements. | Do not treat as permanent. Architect so that losing adequacy is a contractual and configuration event, not a re-platforming event. |
| Will export controls on frontier models prove durable? | The 1990s Crypto Wars are the closest precedent, and there export controls failed once strong cryptography commoditised. Two defences currently distinguish AI: frontier models are served over an API rather than distributed, and they need data-centre-scale hardware. Both are eroding as open-weight models climb benchmarks at lower hardware cost. | Hold both possibilities open, because they point different ways. If controls persist, continuity risk on hosted frontier models is permanent and self-hosted open weights are the hedge. If controls prove unsustainable, heavy capital investment in sovereign infrastructure to guard against them is over-investment. Open-weight optionality is the position that pays under both outcomes; an owned data centre is the position that only pays under one. |
| Can a European subsidiary lawfully refuse a CLOUD Act order? | Untested. The AWS European Sovereign Cloud structure is the strongest attempt; ownership-capped models such as S3NS avoid the question rather than answering it. | Assume it cannot, and let bank-held keys and data minimisation carry the risk rather than the corporate structure. |
The EU AI Act, as deferred by the Digital Omnibus to 2 December 2027 for credit scoring, life and health insurance pricing and HR systems, imposes no obligation about where AI runs, but it does require that we can evidence, for ten years and on demand, exactly what our models did and why; the pressure to move workloads onto sovereign or on-premises infrastructure comes from DORA, GDPR transfers and the unresolved CLOUD Act conflict, not from the AI Act; and the two decisions that matter most in the next twelve months are whether our own model modifications have quietly made us the provider of high-risk systems, and whether we hold our own encryption keys. To which June 2026 added a third: whether we could still operate at all if a hosted model were withdrawn overnight by a government that is not ours.