Register of Information Season: Every Line You Do Not Have To Explain
The 2026 Register of Information cycle is live. For the AI workload, ownership does not defend the row. It removes it.
The register row you never have to defend
Register of Information season is live. The 2026 cycle runs against a reference date of 31 December 2025, and if you sit inside a DORA-scoped financial entity you already know the shape of the next few weeks. You are reconciling contractual arrangements against RT.01 through RT.99. You are chasing LEIs that vendors still have not filed. You are trying to explain, in a machine-readable template, exactly which of your ICT third-party providers touch a critical or important function, and what happens to that function on the day one of them goes dark.
We built Mickai for the entities on the receiving end of that work. Here is the practical claim, and we will defend it line by line: an owned, air-gapped Sovereign Intelligence Operating System with no external ICT dependency for the AI workload is a register entry you do not have to map, monitor, or defend. It collapses a row.
That is a smaller promise than "compliance in a box," and it is a truer one. Let me show you the delta.
Why the register is where the pain landed
The first enforcement cycle taught the market something the guidance did not. Incomplete or inaccurate registers were among the most common triggers for supervisory follow-up letters. Not incident-reporting failures. Not resilience-testing gaps. The register. The plain administrative artefact that most firms treated as a data-entry exercise turned out to be the document supervisors read first, because it is the map of everything else.
The reason is structural. Your Register of Information is a self-declaration of your entire ICT dependency surface. Every provider you list becomes a thread the supervisor can pull: contractual terms, exit plans, sub-outsourcing chains, concentration risk, the substitutability assessment, whether the arrangement supports a critical or important function. A cloud-hosted AI service is one of the densest threads you can add, because it rarely stops at one row.
What a cloud-AI register row actually costs you
Put a third-party AI platform into a critical or important function and look honestly at what you have just committed to carry.
You carry an ICT third-party service provider entry with its own LEI, country of establishment, and the function it supports. You carry the sub-outsourcing chain behind it, because the model provider sits on a hyperscaler, and that hyperscaler sits on regions you do not choose. You carry a substitutability and exit assessment for a model whose weights, safety layer, and API you do not control and cannot port. You carry data-location evidence for every place your prompts, embeddings, and outputs come to rest. You carry an incident-notification dependency, because when the provider has an event, your clock starts on their disclosure. You carry concentration risk, because half your peer group lists the same three names.
None of this is a criticism of cloud. We want to be exact here, because the market is full of people who over-claim. DORA does not bar you from cloud. Neither does the FCA, the PRA, the EBA, GDPR, or the NHS DSP Toolkit. Cloud is legally permitted with controls, and the overwhelming majority of the market runs that way today. The genuine no-cloud bar is workload-level and narrow: classified material, ITAR-controlled data, isolated OT and SCADA environments, and cases where a data protection impact assessment comes back negative.
So the honest question is not "are you allowed." It is "what do you want to spend your register budget defending." Every cloud-AI row is a set of ongoing obligations you keep alive for the life of the arrangement. That is the cost, and for many teams it is a rational cost. It is simply not the only option.
What an owned SIOS removes from the row
Now run the same function on an owned deployment. Mickai is a Sovereign Intelligence Operating System. You own it and you run it inside your own walls, air-gapped, on your own hardware. There is no external API call for inference, no model provider in the loop, no hyperscaler under the model. The AI workload has no external ICT dependency, because the workload is yours.
Trace that back through the template and watch the entries fall away. There is no third-party provider LEI to file for the AI function, because there is no third party in it. There is no sub-outsourcing chain, because there is nothing sub-contracted beneath your own infrastructure. The substitutability and exit assessment simplifies to your own change management, since the software and its weights live on your estate and port with your estate. Data location is your own data centre, evidenced by your own controls. There is no external incident-notification dependency for the AI layer, because there is no external party whose disclosure your clock waits on.
What you gain instead is a positive artefact rather than a defensive one. Every action Mickai takes writes a cryptographically-signed audit record. When a supervisor asks what the AI did, when, and on whose authority, you do not reconstruct it from provider logs you have to request. You hold a tamper-evident record on your own estate. That is the inversion. The cloud row is a liability you monitor. The owned row is evidence you already have.
The delta, in one line
A cloud-AI register entry is a live obligation: a provider to map, a chain to trace, an exit to plan, an incident clock you do not control. An owned, air-gapped Mickai entry for the same function is your own asset on your own estate, with a signed audit record on every action. One is a thread the supervisor pulls. The other is a thread that ends at your own front door.
We are not telling you to rip out cloud. We are telling you that for the workloads where sovereignty is the sensible preference, and there are more of them than most registers admit, ownership removes the row rather than defending it. That is worth pricing into this cycle rather than the next one.
There is one more piece to the posture. The capability that lets a regulator or auditor independently validate those signed records, without us on your premises, is an on-chain attestation rail. It is a validation utility, a way to check a record, and nothing more. It exists so that "trust our audit log" becomes "verify our audit log yourself." That is the sovereign posture end to end: your infrastructure, your model, your record, independently checkable.
Frequently asked questions
Does an owned AI deployment mean I file nothing in my Register of Information?
No, and we would not claim that. You still run the ICT asset itself: your hardware, your operating environment, your internal function ownership. What you remove is the external third-party provider row for the AI workload and everything that hangs off it, because there is no external provider in an air-gapped owned deployment. You are documenting an internal asset, not a third-party dependency. That is a categorically simpler entry to complete and defend.
Is Mickai claiming DORA bars us from using cloud AI?
No. We are explicit that DORA, the FCA, the PRA, the EBA, and GDPR all permit cloud with appropriate controls, and most institutions run that way. The genuine no-cloud bar is workload-level and narrow. Our argument rests on sovereignty as a preference for control, cost, and data-exfiltration risk, not on a legal prohibition that does not exist. If someone tells you regulation flatly bars your cloud, be sceptical.
How does the signed audit record help in a supervisory review?
Because it moves you from requesting evidence to holding it. Every action the system takes is recorded with a cryptographic signature on your own estate, so questions about what the AI did, when, and under whose authority are answered from a tamper-evident record you already control rather than from third-party logs you have to obtain. This connects directly to our work on the sovereign audit record and to Mickai as a layer-2 operating boundary that sits alongside your existing systems.
Is this built, or is it a roadmap?
It is built and it runs. Mickai is a live Sovereign Intelligence Operating System that regulated organisations own and operate air-gapped inside their own walls. Our patent position is a portfolio of 104 filed UK applications covering roughly 2,340 claims across 13 families, naming inventor Mickarle Wagstaff-Irons, building toward examination. Filed, not granted, and we say so plainly. For the wider picture, see our writing on the register-backed sovereign market and on owning your AI layer rather than renting it.