Your AI Vendor Is Now a Critical Third Party: DORA, Concentration Risk and Owning the Model

Under the Digital Operational Resilience Act, the European Supervisory Authorities can designate a Critical ICT Third-Party Provider and bring it under direct oversight. DORA has been fully applicable since 17 January 2025, and 2026 is the year its supervisory posture turns from paper to practice, with the first comprehensive examinations and binding recommendations expected against designated providers. The regime is now an operating reality for every regulated financial entity in the European Union.

The uncomfortable question that follows is simple. If a large artificial intelligence provider supplies inference to a bank, an insurer or a market operator, and enough of the sector depends on it, that provider can be designated a critical ICT third party. The firms that rely on it must then hold contractual audit rights, document and annually test an exit strategy, and carry the concentration risk on their own books. The model you rent has become a supervised dependency, and it is worth setting out what that means and what the alternative looks like.

What DORA actually asks of a critical dependency

DORA does not ban reliance on large providers. It makes that reliance legible and testable. Contracts with critical ICT third-party providers must carry rights of access, inspection and audit for both the financial entity and its competent authority, specify termination conditions and a minimum notice period, and be backed by exit plans documented and tested at least annually. Some providers argue that direct supervisory oversight already covers the ground, so customer audit rights are redundant. DORA treats those obligations as independent: the duty sits with the regulated firm, not the vendor.

The harder obligation is the exit strategy itself. An exit plan is only credible if there is somewhere to exit to. For commodity compute this is manageable. For a specific model, fine-tuned to a specific workflow and embedded in downstream decisions, portability is largely fictional. You cannot lift the weights, guardrails and observed behaviour of a hosted model and set them down elsewhere. The exit plan becomes a document describing a migration nobody can perform within the notice period.

Concentration risk is a property of the market, not your contract

Concentration risk is the part firms cannot negotiate away. A well-drafted contract protects one relationship, but does nothing about the fact that a handful of providers now sit beneath a large share of the sector. When many regulated entities depend on the same inference substrate, a single outage, policy change or model deprecation becomes a systemic event. This is precisely the failure mode DORA was written to surface.

The cross-border layer beneath the contract

There is a second dependency that contracts describe poorly. Where a provider or its parent company is subject to a foreign legal regime, the data and the workload can fall within reach of that regime regardless of where the servers physically sit. The United States CLOUD Act is the clearest example, giving lawful process reach over data held by providers under its jurisdiction. NIS2 raises the baseline for network and information security across essential and important entities, and the EU AI Act layers obligations for high-risk uses, including the Annex III use cases, on top. Those high-risk obligations were once due to apply from 2 August 2026, but the Digital Omnibus deferred them, so stand-alone Annex III obligations now apply from 2 December 2027. The proof requirements survive the move unchanged, so we read the deferral as a build window rather than a reprieve, and the sensible response is to build now. Auditing a supplier tells you what it did last quarter; it does not move the boundary of who can compel it.

Owning the model removes the party you would exit from

This is where the architecture, rather than the paperwork, changes the answer. If the model runs on hardware the operator owns, in an environment the operator controls, there is no external provider to designate, to audit through a contract, or to exit from. The exit strategy DORA asks for becomes trivial: there is no third party in the critical path to leave.

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, with sovereign models held and served locally rather than called across a network to a vendor. Concentration risk does not disappear from the world, but it stops being your concentration risk, because your intelligence layer is not shared with anyone else and no aggregation of your peers sits beneath it.

“The most resilient exit strategy is the one you never have to execute, because there was never a vendor in the critical path to leave.”

Verifiability is what makes ownership auditable

Ownership without evidence is just a different kind of assertion. What makes an operator-owned model answerable to a regulator is that every action can be proven after the fact. Mickai seals each action into a signed audit chain, using post-quantum signatures so the record survives the arrival of quantum computing. Identity is attested by the hardware itself, so an action is bound to a specific machine, not merely to a claimed credential. The perimeter is inbound and zero-egress by design, so data does not leave the environment for a remote model to process.

These are mechanisms an examiner can test. A rented model offers a contractual right to audit a supplier controls; an owned and sealed model offers a cryptographic record of what happened on hardware you can point to. Where consensus matters, cross-model agreement can be run locally, so a decision is checked by more than one model without any of them leaving the environment. The claim is not that on-premise intelligence is automatically safe. It is that it can be made verifiable in a way a shared external service structurally cannot.

How this maps to the standards a buyer already runs

None of this asks a firm to abandon the frameworks it has. ISO/IEC 42001 gives a management-system spine for governing artificial intelligence, and an owned, sealed model produces exactly the traceable records such a system expects. The OWASP work on risks in large-language-model applications catalogues failure modes, from prompt injection to training-data exposure, that are far easier to contain when the model and its data never leave a controlled perimeter. DORA resilience testing, incident reporting and third-party register all become simpler to satisfy when the intelligence layer sits inside the boundary you already govern.

We hold 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD. They cover the sealing, attestation and consensus mechanisms described above, and are filed rather than granted. We note them here only because the architecture they protect is the same architecture that turns a rented dependency into an owned and auditable one.

Where this leaves a regulated buyer in 2026

The designation of critical ICT third-party providers is a live supervisory fact, and 2026 is the year firms will be asked to show their exit plans work. For most rented models, that is the hardest question in the file, because portability was never real, and the honest answer for many will be that the exit plan is aspirational.

There is a different path, and it is architectural rather than contractual. When the model runs on hardware you own, sealed into a provable record and bounded by a perimeter that does not leak, the concentration risk, the audit right and the exit strategy stop being clauses you negotiate and become properties of the system you operate. A serious buyer does not have to take our word for it. The point of building it this way is that they should never have to.