DORA Is in Its Audit Phase: What Banks Must Now Prove About Their AI Vendors

The Digital Operational Resilience Act has been binding on European financial entities since January 2025, and the calendar has now turned a corner. The first year was about drafting policies, mapping providers and standing up governance. The current phase is different. Supervisors are examining what banks filed, testing whether the Register of Information matches operational reality, and asking firms to prove, not assert, that their critical functions can withstand the failure or compromise of an outside supplier. For AI, that shift arrives at an awkward moment, because most institutions adopted the capability faster than they documented it.

The pressure is compounding. The EU AI Act high-risk obligations under Annex III, once due on 2 August 2026, now apply from 2 December 2027 after the Digital Omnibus deferral, and that list reaches directly into credit scoring and other financial decisions, while NIS2 has widened the cyber duties that sit alongside DORA. The deadline has moved but the proof requirements have not, so the sensible response is to build now rather than wait. A bank still has to reconcile a resilience regime, a product safety regime and a cyber regime against the same AI supply chain. The common question underneath all three is simple and hard to answer: who else is inside your decision loop, and what happens when you cannot see what they are doing.

What the audit phase asks a bank to prove

DORA does not merely require a list of suppliers. The Register of Information is a structured record of every ICT third-party arrangement, the functions each one supports, the criticality of those functions and the substitutability of the provider. In the audit phase, supervisors read that register as a claim and look for evidence behind it. An AI vendor that touches a material function is not a line item to be waved through. It is a dependency the bank must explain, monitor and, if the regime demands, exit.

Three duties become concrete. The bank must monitor the provider on an ongoing basis, not just at onboarding. It must hold an exit strategy that does not collapse the function the provider supports. And it must show that concentration risk, the quiet accumulation of many services behind a single infrastructure, has been assessed rather than assumed away. Each is easy to write down and hard to satisfy when the AI capability lives on someone else's servers, under someone else's update schedule, behind an interface the bank cannot inspect.

The critical third-party regime changes the maths

DORA introduces a category above the individual bank: the Critical ICT Third-Party Provider, designated by the European Supervisory Authorities and brought under direct oversight. The logic is systemic. When a large share of the financial sector depends on the same handful of infrastructure providers, the failure of one becomes everyone's failure at once. For a bank leaning on hosted AI, this reframes the vendor question. It is no longer only about the supplier's reliability, but about the layers beneath it: the cloud region, the identity fabric, the network path and the jurisdiction that governs all three. Each shared layer is a correlated exposure the register is meant to surface, and a dependency you cannot remove is one you must document, monitor and defend at your own cost, indefinitely.

The jurisdiction problem sits underneath the technical one

Resilience is not only about uptime. It is about who can reach the data and under what authority. Where an AI service runs on foreign-controlled infrastructure, the governing law of that infrastructure travels with it. The US CLOUD Act, for instance, can compel a provider to produce data held under its control regardless of where the servers physically sit. This is a design property of the arrangement, not a failing of any one firm.

For a European bank subject to DORA and adjacent to the AI Act, this creates a documentation burden with no clean answer. The register asks where a function's data lives and who governs it, and honest completion of that field, for a hosted foreign AI service, records a residual exposure that supervisory scrutiny is designed to notice. The cleanest answer to the jurisdiction question is to arrange matters so it does not arise.

How an on-premise sovereign system removes the dependency

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware inside the bank's own perimeter. There is no inference call leaving the building, no external endpoint in the decision path and no third-party service to enter as a critical dependency in the Register of Information. The distinction matters for DORA because the register measures dependencies, and a capability that runs entirely on infrastructure the bank owns and controls is not a third-party arrangement to be monitored and exited. It is an internal system.

This is architecture, not assertion. A zero-egress inbound perimeter means data and models stay put by construction rather than by policy, and because models run locally, the update schedule, the version history and the behaviour under load are all the operator's to inspect. The concentration risk DORA asks banks to assess against shared external infrastructure does not accumulate, because there is no shared external infrastructure in the loop.

“An AI capability that never leaves the bank's own hardware is not a third-party dependency to be documented, monitored and exited. It is an internal system the bank already controls.”

What auditable means at the single-decision level

Removing the external dependency solves half the problem. The other half is proof. Supervisors want to see that a firm can reconstruct what its systems did and show that the record has not been altered. Sovereign design makes this a property of the system, not an after-the-fact reporting exercise. Every action inside the SIOS is cryptographically sealed. Identity is hardware-attested, so an action is bound to the specific machine and operator that produced it rather than to a claimed credential. The audit chain is signed with post-quantum schemes, keeping the integrity of today's records defensible against tomorrow's computation. And for decisions that carry weight, cross-model consensus requires several independent sovereign models to agree before an output is trusted, addressing the model-integrity and hallucination risks that frameworks such as the OWASP AI catalogue and ISO/IEC 42001 now ask institutions to manage.

The result is an evidence base a bank can hand to an auditor directly: not a vendor's attestation about its own controls, but a tamper-evident, locally held record the operator can verify without trusting anyone else. The engineering behind this verifiability sits within an estate of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented.

Where this leaves banks preparing for the next inspection

DORA, the AI Act and NIS2 look like three compliance projects, and most banks are resourcing them as three. Read together, they converge on a single instruction: know exactly what your AI systems do, prove they did not change without record, and account for everyone who can reach inside the loop. For the material functions DORA classes as critical or important, the cost of proving control over an external dependency, year after year, can exceed the cost of not creating it. The register is where that choice becomes visible.

The audit phase rewards firms that can show control rather than describe intent. For AI, the sharpest way to show control is to hold the capability inside a boundary the bank already governs, where the data never leaves, the models are the operator's own and every decision carries a sealed, verifiable record. Mickai was built as that boundary. The institutions best placed for the next inspection are the ones whose most sensitive intelligence never became someone else's dependency to begin with.