Regions or Countries: The Five Words That Cap AI Supply-Chain Disclosure

Nineteen Names and the Category That Is Missing

On November 18, 2025, the three European Supervisory Authorities published the first list of critical ICT third-party providers designated under the Digital Operational Resilience Act. Nineteen firms made it. The assessment, the ESAs explained, followed “the multifaceted criteria set out in DORA, which required a complete evaluation of a provider’s systemic importance, its role in supporting critical or important functions for financial entities, and the level of substitutability of its services.”¹

Two of the nineteen are colocation operators: Equinix (EMEA) B.V. and InterXion HeadQuarters B.V.² Europe’s financial regulators looked at the infrastructure supporting the continent’s banks, insurers, and trading venues, and concluded that the buildings themselves are systemically important enough to warrant direct supervision.

No frontier AI provider is on the list. Not OpenAI, not Anthropic, not Mistral, not xAI, not Cohere.

The United Kingdom reached a similar shape from a different direction. Its critical third parties regime took effect January 1, 2025, and the first designations were announced on July 10, 2026, effective three days later.³ Four entities, all hyperscale cloud. Again, no AI provider.

Neither omission is an error. Both regimes designate on the basis of documented systemic dependency, and the AI layer is young enough that the supervisory evidence has not accumulated. But the consequence is concrete: the layer growing fastest inside enterprise workflows is the layer with the least supervisory visibility, and the layer regulators have designated is the one underneath it.

Since then, the ESAs have spoken directly on the subject. A Joint Committee statement issued July 31, 2026 addresses ICT risks from frontier AI models, warning that AI-enabled cyber tools “could generate systemic risks due to their ability to: i) rapidly discover and exploit vulnerabilities; ii) target vulnerabilities in shared infrastructure; and iii) leverage single points of failure across entities.”⁴ It is a supervisory expectations statement rather than a rule, and its recommended action is that financial entities “assess, monitor, and enforce cybersecurity standards across the whole supply chain.” One reading of it, offered by counsel advising providers in the days after publication, is that it imposes no new legal obligation on AI providers directly and instead shapes what their regulated customers will demand contractually.⁵

Which raises the question this piece exists to answer: what, exactly, is an enterprise entitled to demand?

The signal Regulators have identified the physical infrastructure layer as critical and the AI layer as something their supervised entities should ask better questions about. The gap between those two postures is now the enterprise’s to manage alone.

Five Words in Article 30

DORA contains the most demanding third-party transparency provision in force anywhere, and it is worth reading closely because it establishes the ceiling. Article 30(2)(b) requires that contracts specify:

“the locations, namely the regions or countries, where the contracted or subcontracted functions and ICT services are to be provided and where data is to be processed, including the storage location, and the requirement for the ICT third-party service provider to notify the financial entity in advance if it envisages changing such locations”

— Regulation (EU) 2022/2554, Article 30(2)(b)

Namely the regions or countries. The legislature considered the location question and answered it at national granularity.

The supervisory reporting layer confirms the reading rather than extending it. DORA’s Register of Information, whose templates were set by Implementing Regulation (EU) 2024/2956, carries dedicated location fields for the country of service provision, the location of data at rest, and the location of data processing. Each is populated with an ISO 3166-1 alpha-2 country code.⁶

So a European bank has a legal right to know that its inference runs in Sweden. It has no legal right to know whose building it runs in, whether that building is owned by the model provider or leased from a neocloud, or whether the same hall also serves the provider the bank has designated as its failover.

One provision cuts the other way and deserves emphasis because it is the sharpest lever currently available. The register requires a rank field for each entity in the ICT supply chain, with rank one as the direct provider and subsequent ranks as the subcontractors beneath it. The chain must be enumerable even where the facility need not be named. Article 29 reinforces this by requiring a concentration-risk assessment before contracting for a critical function, explicitly covering “whether and how potentially long or complex chains of subcontracting may impact their ability to fully monitor the contracted functions.”⁷ And the subcontracting technical standard adopted in March 2025 requires that a provider be able to identify all subcontractors, notify the entity of them, and give notice well in advance of material changes.⁸

A second lever exists, and it is more blunt. Article 30(3)(e) requires contracts covering critical or important functions to grant “unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority, and the right to take copies of relevant documentation on-site,” alongside an obligation on the provider to “fully cooperate during the onsite inspections and audits.”⁷ An on-site inspection right is awkward to exercise without knowing which site. Nothing in the provision compels a provider to volunteer an address, but the right presupposes the address is obtainable, and that presupposition is the closest thing in force to a facility-level entitlement.

An enterprise willing to use these provisions can compel a list of the operators in its chain, and a regulated one can, in principle, walk into their buildings. Neither can compel the mapping: which operator serves which workload, on which day. That is the piece a failover architecture actually turns on, and it is the piece no instrument reaches.

What Each Regime Reaches and Where It Stops

Four bodies of law touch this question, along with a set of voluntary standards that enterprises routinely mistake for a fifth, and each stops a layer above the hardware for a different reason.

The AI Act case is the most striking, because it is the instrument written specifically for this technology. Annex XI requires a general-purpose model provider to document “the computational resources used to train the model (e.g. number of floating point operations), training time, and other relevant details related to the training,” along with known or estimated energy consumption. Annex XII, which governs what a provider must tell downstream integrators, covers architecture, parameter count, modality, licensing, and the technical means needed for integration.⁹ While the Act asks how many floating-point operations went into a model, it never asks where those operations occurred, or where the operations serving a live request happen now.

Furthermore, no relief is arriving soon. The Digital Omnibus on AI, which entered into force July 27, 2026, deferred the Annex III high-risk obligations from August 2026 to December 2027, and the Annex I embedded high-risk obligations from August 2027 to August 2028.¹⁰ The portion of the Act most likely to force enterprises to document their AI supply chains in earnest now lands more than a year later than originally legislated.

Data protection law gets further than most people expect on one axis and nowhere on the other. The European Data Protection Board’s October 2024 opinion on reliance on processors and sub-processors reads Article 28 to require that a controller have readily available, at all times, the identity of every processor and sub-processor in the chain, expressed as name, address, and contact person, and that this holds regardless of the risk profile of the processing.¹¹ That is a real entitlement to the corporate map. A registered address, however, is a company’s address, not the address where a GPU is racked.

One genuinely open question is worth flagging rather than resolving. The EU Data Act, applicable since September 12, 2025, requires providers of data processing services to publish the jurisdiction to which the ICT infrastructure deployed for their services is subject.¹² Whether an inference API constitutes a data processing service within that definition does not appear to have been settled by any regulator or court. The definition is broad enough to plausibly capture it. If it does, model providers acquire a public jurisdiction-disclosure duty they mostly are not discharging today; if it does not, the last remaining candidate for a public infrastructure disclosure obligation falls away.

Standards close none of this. ISO/IEC 42001 requires an organization to identify and document the resources each AI system depends on, including its computing resources and, at a coarse level, where they sit.¹³ That is an inventory the provider keeps, not a disclosure the customer receives. There is a certain irony in it: the standard obliges a model provider to document the compute its systems depend on, and obliges it to tell no one who runs workloads on that compute.

Disclosure in Practice: Google’s Register, OpenAI’s Set

Regulation sets a floor, and the floor reaches further than most buyers make it reach. Where an infrastructure operator handles personal data it is a sub-processor, and the entitlement to sub-processor identity described above already extends to it. What varies is how legibly providers discharge that duty, and the variation is the most useful evidence available because it demonstrates what is commercially survivable.

At the top of the ladder sits Google Cloud’s sub-processor list, which is not a list so much as a register. Nine columns per entry: the entity, the services it touches, the applicable cloud regions, the activity performed, the country of processing, the registered address, the country of registration, the company number, and the ultimate parent. It names third-party facility operators outright, including Green Box Computing B.V. performing data centre operations in the Netherlands and Eviden and Bull entities managing hosting environments.¹⁴ Whatever else is true, facility-operator disclosure cannot be impossible because one of the largest infrastructure providers in the world publishes it and updates it regularly.

AWS names its own subsidiary entities mapped to regions, and no colocation operators. OpenAI, the most transparent of the AI-native providers, publishes a sub-processor list updated July 9, 2026 that names six compute suppliers and the countries each operates in.¹⁵ That is more than most peers offer and it still answers the wrong question. It tells a customer which suppliers might touch its workloads somewhere across the estate. It does not tell that customer which supplier served a given request, and no mapping from workload to supplier is published or contractually available.

Anthropic illustrates this point perfectly. Its incident retrospective for the March 2026 outage attributes the failure to a networking performance degradation “within our infrastructure” that disrupted communication between components of its serving stack.¹⁶ The company is publicly known to run across at least two hyperscale platforms and a leased GPU campus. Our infrastructure, in that sentence, is doing an enormous amount of work. A customer reading it cannot determine which platform failed, and therefore cannot determine whether its own contingency plan was ever exposed.

Uptime Is Measured, Not Promised

Disclosure of infrastructure is one half of the gap. The other half is what happens when that infrastructure fails, and here the contractual position is weaker than the operational reality, which is an unusual inversion.

Anthropic’s published Commercial Terms, effective June 17, 2025, contain no uptime commitment and no service credit. They state that the services are provided “AS IS” and “AS AVAILABLE” without warranty of any kind, and that Anthropic “DOES NOT WARRANT, AND DISCLAIMS THAT, THE SERVICES OR OUTPUTS ARE ACCURATE, COMPLETE OR ERROR-FREE OR THAT THEIR USE WILL BE UNINTERRUPTED.”¹⁷ The same company publishes measured ninety-day uptime by component on its status page, where the API stood at roughly 99.5% and claude.ai at roughly 99.4% when this was written in early September 2026.¹⁸ A provider disclaiming availability entirely while publishing its actual availability is a strange posture and, on balance, a creditable one: the measured number is the more useful artifact.

Where commitments do exist, they are lower than enterprise buyers tend to assume. Gemini online inference on Vertex carries a committed monthly uptime of 99.5%, dropping to 95% for models designated for shorter availability, with credits of 10%, 25%, or 50% and total credits capped at half the monthly bill for the affected service.¹⁹ Amazon Bedrock commits to 99.9% on commercially reasonable efforts, with credits applied only against future Bedrock charges, and excludes underlying model crashes from credit eligibility. That SLA was last revised on October 4, 2023, before most of the models it now serves existed.²⁰

For context on what 99.5% means: it permits roughly three and a half hours of downtime per month, against the forty-three minutes implied by the 99.9% that has been table stakes for conventional cloud services for a decade.

Independent measurement fills in the historical picture. A peer-reviewed characterization of outages across public LLM services, covering February 2021 through August 2024, found mean availability of 99.82% for the OpenAI API and 99.92% for the Anthropic API, with mean time between incidents measured in single-digit days and mean time to recovery between two and four hours.²¹ Those are respectable numbers for a young category. They are not the numbers a bank uses when sizing an operational risk capital charge, and they sit well below the reliability the surrounding contract language declines to promise at all.

The Case Against Telling You

The argument for infrastructure opacity deserves a fair hearing, and it comes in two versions of very unequal quality.

The weak version is security through obscurity. It has been made for a long time. In July 2010, a Google product marketing manager defended the company’s refusal to disclose data centre locations on the grounds that “we think it’s a security risk.” The analyst Andreas Antonopoulos rejected it in the same article, observing that security by obscurity “doesn’t work. There’s always someone who knows.”²² Sixteen years later, the argument has aged poorly, not least because Google itself now publishes named facility operators with company numbers and registered addresses, and the sky has not fallen.

The strong version is architectural, and it is correct. Facility-level provenance may be genuinely unknowable at request granularity because the routing layer that makes capacity economical is the same layer that erases the mapping. Amazon’s global cross-region inference explicitly routes requests across supported commercial regions worldwide rather than within a single geography, and documents that input prompts and output results may move outside the source region during cross-region inference.²³ Anthropic exposes an inference geography parameter whose default value is global.²⁴ Under those architectures, a demand to know which building served a particular request is not so much refused as put to a system that does not retain the answer at that resolution. On the other hand, it is worth noticing how much the system does retain. Anthropic’s API returns an inference geography field in the response body, so per-request provenance exists at the granularity the routing layer tracks.²⁴ The boundary here is not secrecy. It is resolution, and resolution is negotiable in a way secrecy is not.

That objection defeats one version of the ask and leaves the more useful version intact. An enterprise designing for correlated failure does not need per-request provenance. It needs to know the eligible set: which operators and facilities could serve its workloads, and whether the set behind its primary provider intersects the set behind its designated failover. That question is answerable. DORA’s rank-ordered chain already presumes it is answerable. Google’s sub-processor register demonstrates that publishing something close to it is compatible with running a large commercial infrastructure business.

Ask the Question the Architecture Can Answer

The practical move is to stop asking a question the architecture cannot answer and start asking four that it can.

Ask for the chain, ranked. Request the enumerated list of entities in the ICT supply chain supporting your workloads, in the rank-ordered form DORA already contemplates, whether or not you are an in-scope financial entity. Regulated buyers have established the template and generally under-use it, since their contracts for critical functions must already carry unrestricted on-site inspection rights that are hard to exercise without an address. For everyone else, the question at renewal is not whether a provider will grant the chain, but why it would decline what its regulated customers already receive.

Negotiate for set disjointness rather than facility identity. The achievable commitment is narrow: that capacity serving your primary workloads and capacity serving your designated fallback do not share a facility or a power feed, or, failing that, an explicit statement that this cannot be committed. A refusal is itself information, and it is information most architectures currently proceed without.

Material-change notification needs a real notice period. DORA’s subcontracting standard requires notice well in advance of material subcontracting changes; the thirty-day sub-processor objection window familiar from vendor data processing agreements is a contractual convention rather than a statutory entitlement, and its only remedy is termination. Neither suffices alone. The combination is a reasonable floor to write into a commercial agreement: advance notice, a defined window, and a remedy short of walking away.

Finally, use measured availability in preference to promised availability. Where a provider publishes historical uptime, that figure belongs in the operational risk assessment ahead of any contractual number because the contractual number describes a remedy rather than a behavior. Where none is published, independent measurement exists, with attention to what it probes: edge reachability and successful inference are different properties, and a monitor showing an endpoint answering will not show a model returning degraded output behind it.

Finally, one organizational note exists beneath all four. These asks belong in third-party risk management alongside the cloud and payment-processor reviews already running, not in an AI governance workstream sitting parallel to them. AI governance committees have largely been constituted around model behavior, bias, and acceptable use, and the questions in this article are none of those. They are supply-chain questions, and there is a mature function that already knows how to ask them.

The Field That Does Not Exist

Somewhere in a European bank’s register of information there is a row describing an AI service, with a two-letter country code in the location field and a rank-ordered list of the entities in the chain. It is a genuinely useful record, and it is the most any enterprise anywhere is currently entitled to compel. The field that would say which hall, whose racks, and on whose power does not exist in the template because no one drafting it in 2022 expected the model layer and the building layer to collapse into the same risk. They have. The regulation will catch up eventually—on the timeline regulation moves. Until then, the only instrument that closes the distance is the contract in front of you, and the only cost of asking is the awkwardness of being the first customer to try.

References

1. “European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act,” European Banking Authority, November 18, 2025.
2. “List of designated CTPPs,” EIOPA, November 18, 2025 (nineteen entities designated).
3. “UK financial regulators to begin overseeing Critical Third Parties,” Bank of England, July 10, 2026, effective July 13, 2026; regime rules at FCA PS24/16 and PRA PS16/24, November 2024, in force January 1, 2025.
4. European Supervisory Authorities Joint Committee, “Toward a consistent and risk-based approach for ICT risks from frontier AI models,” JC 2026 25, July 31, 2026.
5. “Frontier AI and DORA: AI Service Providers to European Financial Entities Take Note,” Goodwin, August 6, 2026.
6. Commission Implementing Regulation (EU) 2024/2956, register of information templates, fields B_02.02.0130, B_02.02.0150, and B_02.02.0160, each populated with ISO 3166-1 alpha-2 codes; supply-chain rank field at template B_05.02.
7. Regulation (EU) 2022/2554 (DORA), Articles 28(3), 29, 30(2)(b), and 30(3)(e). Applicable from January 17, 2025.
8. Commission Delegated Regulation (EU) 2025/532 of March 24, 2025, regulatory technical standards on subcontracting of ICT services supporting critical or important functions; applicable from July 22, 2025.
9. Regulation (EU) 2024/1689 (AI Act), Annex XI and Annex XII.
10. Regulation (EU) 2026/1744 (Digital Omnibus), in force July 27, 2026; deferral of Annex III obligations to December 2, 2027 and Annex I obligations to August 2, 2028.
11. European Data Protection Board, Opinion 22/2024 on certain obligations following from the reliance on processor(s) and sub-processor(s), adopted October 9, 2024. The characterization here follows published legal analyses of the opinion; readers relying on the precise wording should consult the EDPB text directly.
12. Regulation (EU) 2023/2854 (Data Act), Article 28, applicable from September 12, 2025. Whether an inference API falls within the definition of a data processing service appears to be unsettled.
13. ISO/IEC 42001:2023, Annex A control A.4 (resources for AI systems), and in particular A.4.5 on system and computing resources. The standard is not publicly available; this description follows published implementation guidance rather than the standard text.
14. “Google Cloud sub-processors,” Google Cloud, last modified August 20, 2026.
15. “Sub-processor list,” OpenAI, updated July 9, 2026.
16. Anthropic incident retrospective for the March 26–27, 2026 outage, Claude Status, 2026.
17. “Commercial Terms of Service,” Anthropic, effective June 17, 2025.
18. Claude Status, ninety-day uptime by component, retrieved September 4, 2026. The window rolls daily and the figures move with it.
19. “Gemini Online Inference API on Gemini Enterprise Agent Platform Service Level Agreement (SLA),” Google Cloud, last modified June 30, 2026.
20. “Amazon Bedrock Service Level Agreement,” Amazon Web Services, last updated October 4, 2023.
21. Chu, Talluri, Lu, and Iosup, “An Empirical Characterization of Outages and Incidents in Public Services for Large Language Models,” Proceedings of the 16th ACM/SPEC International Conference on Performance Engineering (ICPE ‘25), doi:10.1145/3676151.3719372; preprint at arXiv:2501.12469. Covers February 11, 2021 to August 31, 2024.
22. Ellen Messmer, “Secrecy of cloud computing providers raises IT security risks,” Network World, July 6, 2010.
23. “Geographic and global cross-Region inference,” AWS Bedrock documentation, 2026.
24. “Data residency,” Anthropic platform documentation, 2026. The inference_geo parameter defaults to global.