DORA and the ICT Third-Party Test: How Sovereign AI Removes the Concentration Risk Regulators Fear

The regulation that made your AI vendor a board problem

The Digital Operational Resilience Act (DORA) applies across the EU financial sector and reframes something most firms treated as procurement into something the board now owns. Under DORA, information and communication technology (ICT) risk is not a line item in an IT budget. It is a resilience obligation that reaches every third party your critical and important functions depend on, including the AI services quietly threaded through fraud detection, underwriting, client servicing, and reporting.

Read plainly, DORA asks three things of a financial entity. Can you name every ICT third party that supports an important function. Can you exit or substitute that third party without breaking the function. And are you avoiding a concentration of dependency on providers so large that their failure becomes your failure. Public-cloud AI is difficult to satisfy on all three counts. Sovereign AI, meaning AI you own and run inside your own walls, answers each one directly.

I am Micky Irons, founder and CEO of Mickai. What follows is a plain reading of the ICT third-party and concentration-risk rules, and why owned, on-premise AI is the honest answer.

The ICT third-party register, and why cloud AI resists it

DORA requires a register of information covering ICT third-party arrangements, with particular scrutiny where those arrangements support critical or important functions. The register is not a formality. It is meant to make substitutability and concentration visible to your regulator and to your own risk committee.

Public-cloud AI resists clean entry in that register. The model may be retrained without notice. The inference endpoint may sit in a jurisdiction touched by the CLOUD Act. The subprocessor chain runs several layers deep, and the terms of service reserve the right to change the service you depend on. You are asked to document a dependency whose behaviour you neither control nor can fully see.

Mickai changes what goes in the register. The AI is deployed on infrastructure you own, on-premise and air-gapped. There is no external inference call, no shifting subprocessor tree, no cross-border data path to reconcile against your data residency obligations. The register entry becomes short, stable, and truthful, which is exactly what an examiner wants to read.

Concentration risk is the fear, and ownership is the answer

Concentration risk sits at the centre of DORA and of the wider operational resilience agenda that supervisors already pursue under PRA and FCA rules. Regulators watched the sector consolidate its most sensitive workloads onto a very small number of hyperscale providers, and they concluded that a single outage, policy change, or geopolitical event at one provider could ripple through many regulated firms at once. That is systemic risk wearing a procurement badge.

You cannot fully diversify your way out of it when a handful of vendors dominate the market. You can, however, remove the dependency altogether for the workloads that matter most. When the AI runs on hardware you own, inside your perimeter, the failure of any external provider does not touch it. There is no shared control plane to go down, no shared region to lose, no shared vendor whose incident becomes your incident report. Ownership is not a partial mitigation of concentration risk. For the owned workload, it retires the risk.

This is the point where the market is moving toward this architecture rather than away from it. Regulated buyers are actively looking for an answer to exactly this question, and the sovereign AI category is projected to grow from roughly USD 40 billion in 2025 to USD 148 billion by 2032. DORA is one of the reasons.

What the CRO and the Head of Internal Audit actually need

DORA is enforced through people with named accountability. The Chief Risk Officer has to certify that ICT risk is managed. The Head of Internal Audit has to test that the controls work. Neither can sign against a black box.

Mickai is built for their evidence burden. Every action the system takes is written to an Operational Audit Record (OAR): a tamper-evident log, signed with ML-DSA-65 post-quantum cryptography, bound to a hardware-rooted identity so that a record cannot be forged or repudiated later. The OAR is not a marketing feature. It is the artefact an auditor pulls to prove, after the fact, that a decision happened the way the firm says it did, in the order it says it did, on the infrastructure it says it did.

Underneath, fifty specialised brains operate under a single deterministic arbiter, so the system does not improvise a path through a regulated process. Where a step needs to be reversed, compensating rollback unwinds it cleanly rather than leaving a half-finished action in a critical function. For a Head of Internal Audit, this converts AI from something you take on faith into something you can test.

Resilience testing and exit, without a third party in the loop

DORA expects firms to run resilience testing and, for the most significant, threat-led penetration testing, then to hold a credible exit strategy for critical ICT dependencies. Exit is where cloud AI quietly fails the test. Migrating a live fraud or underwriting model off a hyperscaler, under time pressure, with data residency intact, is a plan most firms cannot actually execute.

An owned deployment removes the exit problem by removing the third party from the critical path. There is no provider to exit. Testing happens against your own infrastructure, on your schedule, without carve-outs negotiated into a vendor contract. Mickai runs its retrieval-augmented generation against an air-gapped knowledge base, so even the model's grounding data never leaves the building, which is what lets your DORA testing evidence and your GDPR data-residency position tell the same story.

Mickai as the ally, not the next dependency

The instinct to be careful here is correct. Swapping one opaque dependency for another would defeat the purpose. That is why Mickai is delivered as something you own and operate, with 104 filed UK patent applications spanning roughly 2,340 claims underwriting the architecture, and manufacturing secured in Birmingham to keep the supply chain accountable. We are an ally to your compliance function, not a hyperscaler asking you to trust a distant control plane. The dual-buyer thesis is simple: the regulated firm buys resilience it can prove, and the wider AI ecosystem gains a compliant on-ramp into markets that were legally closed to public cloud.

As a third-party momentum signal, Micky Irons was ranked number four on Crunchbase in June 2026, with Mickai among the top one to two percent of companies globally, which reflects how actively regulated buyers are now searching for an owned answer to the DORA question.

Mickai is built and LIVE, and we are building to scale with a small number of selected financial partners ahead of the wider rollout. If DORA has made your AI supply chain a board conversation, and it should have, I would welcome a direct one. Reach me at micky@mickai.co.uk.

FAQ

See the questions below for the short version.

Frequently asked questions

What does DORA require for AI third parties?

DORA treats any AI service supporting a critical or important function as an ICT third-party dependency. You must record it in your register of information, prove you can substitute or exit it, and avoid concentrating dependency on a small number of providers. Owned, on-premise AI answers all three because there is no external provider in the critical path.

How does owned AI reduce concentration risk?

Concentration risk arises when many regulated firms rely on the same few hyperscale providers, so one outage or policy change becomes a shared event. When the AI runs on hardware you own inside your perimeter, no external provider failure touches it. For that workload, ownership retires the concentration risk rather than partially mitigating it.

What evidence does Mickai give a CRO or Head of Internal Audit?

Every action is written to an Operational Audit Record: a tamper-evident log signed with ML-DSA-65 post-quantum cryptography and bound to a hardware-rooted identity, so records cannot be forged or repudiated. Fifty brains run under a deterministic arbiter with compensating rollback, so a regulated process is testable rather than improvised.

How does owned AI satisfy the DORA exit-strategy requirement?

By removing the third party from the critical path. There is no provider to migrate away from under time pressure. Resilience and threat-led testing run against your own infrastructure on your own schedule, and air-gapped retrieval keeps grounding data inside the building, so your DORA testing evidence and your GDPR data-residency position stay consistent.

Is Mickai a replacement for a hyperscaler?

No. Mickai is an ally to the compliance function and a compliant on-ramp for AI into markets legally closed to public cloud. The dual-buyer thesis is that regulated firms buy resilience they can prove, while the wider AI ecosystem gains access to those markets. Mickai is built and LIVE, and building to scale.