By Micky Irons, founder and CEO of Mickai.
By the middle of 2026, the tension is no longer theoretical. Hospitals, banks, defence primes and government departments all hold data they are not permitted to move. Patient records, transaction ledgers, classified assessments and citizen files sit behind legal walls built deliberately, and those walls will not come down. Yet the same organisations are under pressure to derive shared intelligence from that data: to spot fraud across institutions, to detect threats across sites, to learn from populations rather than one office in isolation. The obvious answer, pooling everything into a central lake, is the one most of them cannot lawfully choose.
The regulatory calendar has sharpened the point. The EU AI Act's Annex III high-risk obligations, once due on 2 August 2026, now apply from 2 December 2027 after the Digital Omnibus deferral, and that list reaches into medical, biometric, employment and critical-infrastructure use. The move buys time, but it changes nothing about the proof: the requirements survive the deferral intact, so the sensible response is to build now rather than wait. DORA has been in force across financial entities since January 2025, NIS2 has widened the definition of essential and important entities, and ISO/IEC 42001 now gives buyers a management-system standard to demand. The question a serious operator asks is not how to gather more data in one place, but how to gain shared capability while the underlying records never leave the ground where they were collected.
The default that most architectures got backwards
For two decades the reflex has been to centralise first and secure later: move the data to the compute, aggregate it, then wrap governance around the aggregate. That order made sense when compute was scarce, but it produced the concentrated data estates that are now the largest single point of failure in most organisations.
Federation inverts the reflex. The data stays on each site, on hardware the operator owns, and the model travels to the data instead. What crosses a boundary is never the raw record but a permitted signal: a gradient, a summary, an aggregate statistic, an alert, a verified answer. The primary copy of the sensitive material never departs the perimeter that already governs it.
Mickai is a Sovereign Intelligence Operating System, a SIOS, that runs offline on operator-owned hardware. Federated operation is native to how it is built, a starting posture rather than a mode bolted onto a design that assumed central pooling.
What actually crosses the boundary, and what never does
The credibility of any federated design rests on a single unglamorous question: what leaves each site. If the honest answer is the record itself, in any recoverable form, the design has failed, so the discipline is to make egress the exception and every permitted signal explicit.
In practice the site owner defines, in advance, the shape of what may leave: a model update that carries learning but not examples, a count that reveals a trend but not an individual, or an answer a local model has already composed from local data. Everything else is denied by construction. The boundary is not a filter over a stream of records hoping to catch the sensitive ones; it is a wall through which only named, permitted signals may pass.
Shared intelligence is legitimate only when the underlying records never move and every signal that crosses a boundary can be named, permitted and later proven.
Zero egress as an inbound perimeter
Most security thinking still frames the perimeter as a gate that inspects what comes in. For a system that holds data it may never leak, the more important question is what can get out. The perimeter is designed as a zero-egress boundary: the system does not call home, does not phone external services, and does not reach any host the operator has not explicitly authorised.
This matters for federated intelligence, because the risk in any collaboration is not only what a partner receives on purpose. It is what leaks by accident, through telemetry, an update channel, or a diagnostic that quietly ships context elsewhere. When nothing leaves unless the operator has named it, that accidental channel is closed before it can be exploited.
Proving the record never moved
A promise that data stayed put is worth very little to a regulator or an auditor. Proof is worth a great deal, which is where verifiability has to do real work. Every action a site takes, every signal it emits, every model update it contributes, is recorded in an audit chain that is signed and tamper evident.
These records are signed with post-quantum signatures, so the chain of evidence holds even as the cryptographic ground shifts over the coming years. It can be verified offline, by the operator, without trusting the system that produced it and without a network round trip to any external party. Identity is anchored to the hardware itself, so an auditor can establish not just that an action happened but which attested machine performed it, and a site can then demonstrate, after the fact, that it shared only what it agreed to and that the raw records stayed put.
Why answers get harder to corrupt when models disagree
Federation raises a second-order worry. If sites learn from one another, a poisoned contribution from one site could degrade the intelligence of all. This is the collaborative version of the data-poisoning and model-manipulation risks the OWASP work on AI systems has catalogued, and it deserves a structural answer.
The answer is not to trust a single model with the final word. Consequential outputs are produced by more than one sovereign model reasoning independently, and an answer earns confidence through consensus rather than the authority of any one component. A contribution that pulls one model in a strange direction has to move several before it changes the outcome, and the disagreement itself flags that something warrants review.
The jurisdiction question the architecture answers
Underneath the technical discussion sits a hard legal fact many buyers have learned to name. Data held by a provider subject to the US CLOUD Act can be reachable by that jurisdiction regardless of where the servers physically sit. For a European hospital, a British department or a defence supplier, that is a reason a lawful federation cannot depend on a central store held by any single foreign-reachable operator.
A federated-by-default design sidesteps the problem rather than arguing about it. If the records never leave the site, there is no central store to compel, and each participant remains governed by its own law on its own ground. This is a matter of architecture, not an accusation against any company: where data lives, and who can be compelled to hand it over, are decisions settled when the system is built, not when the subpoena arrives.
What federated by default asks of the next few years
As these regimes move from statute into procurement, buyers will stop asking whether a system is secure in general and start asking a sharper pair of questions. Where does the data physically reside, and can they prove what left the building. Federation answers both, because it gives the first question only one answer: here, on site.
The work is protected by 104 filed UK patent applications carrying approximately 2,340 claims, owned by Mickai LTD and patent pending, spanning offline verifiability, hardware-attested identity, sealed audit and the federated mechanisms described here. Organisations should reach their own conclusion from the design rather than take a claim on trust.
Intelligence without moving the data is not a compromise on capability. It is a recognition that the most valuable data is the data that must stay put, and that the systems worth trusting with it are built, from the first line, never to need it anywhere else.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/federated-by-default-intelligence-without-moving-the-data. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)