Sovereign AI for Central Banks: Monetary Data That Cannot Touch a Public Cloud

A central bank sits on the most consequential data in any economy. Interest-rate deliberations before they are announced, foreign-exchange intervention plans, supervisory files on systemically important lenders, and the granular payment flows that pass through a real-time gross settlement system. A single premature disclosure of any of it can move currency markets, reprice sovereign debt and hand an information advantage to whoever receives it first. This is data whose value is measured not in gigabytes but in the stability of a currency.

The pressure to apply artificial intelligence to that data is real and growing through 2026. Nowcasting inflation, screening transactions for financial-crime signals, drafting supervisory assessments and interrogating decades of policy archives are all tasks where a capable model earns its keep. The difficulty is not the ambition. It is that the dominant way to consume advanced AI, sending a prompt to a model hosted on someone else's infrastructure, asks a monetary authority to place its most sensitive material on systems it does not own, cannot inspect and cannot fully wall off from foreign legal reach.

The data a central bank simply cannot export

Consider what a monetary-policy prompt actually contains. To be useful, it carries the very numbers and reasoning that markets are not permitted to see until publication. A model that summarises a rate-setting committee's draft minutes has, by definition, ingested those minutes. If that inference happens off-premise, the institution has exported its embargo to a third party and taken on faith that the embargo holds.

The same logic applies to supervisory data on individual banks, to settlement records that reveal the liquidity position of named counterparties, and to reserve-management strategy. None of it is ordinary corporate information. It is category-defining sensitive, and the correct default for it is not a stronger contractual promise about a public cloud. The correct default is that it never leaves the building.

Why a contract is not a control

Public-cloud AI security rests on a stack of assurances: encryption in transit and at rest, access controls, regional data-residency commitments, and audited compliance certifications. These are real engineering achievements and they matter. They are also, in the end, promises made by an operator about infrastructure the customer cannot see inside.

Two structural facts complicate those promises for a central bank. First, extraterritorial legislation such as the US CLOUD Act can compel a provider subject to its jurisdiction to produce data it holds, wherever in the world that data physically sits. A data-residency clause governs geography. It does not always govern legal reach. Second, a hosted model is a shared, remotely managed system: the customer depends on the operator's people, patch cycles and internal controls, and cannot independently verify at any given moment what touched the data. For most enterprises that trade-off is entirely rational. For the institution that anchors a currency, the residual risk lands differently.

The 2026 regulatory floor is rising

The compliance environment now reinforces the architectural argument rather than merely coexisting with it. The EU AI Act places systems used in essential public and financial functions in the high-risk tier under its Annex III, with duties on logging, human oversight, robustness and traceability. Those obligations were once due on 2 August 2026, but the Digital Omnibus has deferred them, so they now apply from 2 December 2027. The proof requirements survive the move unchanged, so we read the delay as a build window rather than a reprieve, and the sensible response is to build now. The Digital Operational Resilience Act has bound EU financial entities since January 2025 to hard standards on operational resilience and third-party risk, and a hosted AI dependency is precisely the kind of critical third party DORA scrutinises. NIS2 raises the baseline for essential-entity cybersecurity, and ISO/IEC 42001 gives institutions a certifiable management system for AI governance.

Read together, these instruments push in one direction: demonstrable control, complete audit trails and the ability to prove after the fact exactly what a system did. Those obligations are far easier to discharge when inference happens on infrastructure the institution owns and can examine, and considerably harder when it happens inside a remote service whose internals are opaque by design. The published lists of AI-specific failure modes, including prompt injection and training-data exposure, only sharpen the case for keeping the model and the data under one roof.

What on-premise inference actually looks like

Sovereign AI is not a slogan. It is a specific architecture in which the model weights, the data they process and the record of every action all remain inside the operator's own perimeter. Mickai is a Sovereign Intelligence Operating System, a SIOS, built to that specification. It runs offline on operator-owned hardware, with no dependency on an external endpoint for the reasoning itself.

Several mechanisms make that architecture verifiable rather than merely asserted. Hardware-attested identity binds the running system to the physical machine it is authorised to run on, so a workload cannot be silently relocated. A zero-egress inbound perimeter inverts the usual assumption: data and queries come in, and nothing is permitted to phone home. Every action is written to a post-quantum signed audit chain, a tamper-evident ledger whose signatures are designed to withstand future cryptographic attack, so that the trail an auditor or regulator inspects is one no operator can quietly rewrite. Cross-model consensus, in which more than one sovereign model must agree before a high-stakes output is surfaced, reduces the chance that a single model's error or manipulation passes unchallenged. The sovereign models themselves are run in the abstract, decoupled from any external vendor's operational control.

“Data that can move a currency should never depend on a promise made by infrastructure the central bank does not own.”

Verifiability as the deciding property

The distinction that matters most is between trusting a control and being able to prove it. A hosted service can tell an institution that its data was isolated and its logs are complete. An on-premise system lets the institution's own auditors, and its supervisors, examine the sealed record directly and confirm it.

That shift changes the character of an inspection. Instead of reviewing a provider's attestation about a system it operates, an examiner reviews a cryptographically sealed history the institution holds itself. Offline verifiability means the evidence does not depend on the continued cooperation, or even the continued existence, of an outside vendor. For a body whose legitimacy rests on public trust and demonstrable independence, the ability to answer a hard question with its own tamper-evident record, rather than a third party's assurance, is not a technical nicety. It is central to the mandate.

Sovereignty is not isolation

A common objection is that keeping AI on-premise sacrifices the pace of frontier capability. In practice the trade-off is narrower than it appears. Capable sovereign models can be deployed, updated and improved within a controlled environment, with new weights brought in through governed, inspected channels rather than by exposing live monetary data to an external service. The institution keeps its data inside and still moves its capability forward.

Nor does sovereignty mean going it alone technically. The engineering behind this architecture is documented and defensible. The underlying methods sit within a body of intellectual property comprising 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD; never granted or patented. That is offered here as evidence that the mechanisms are concrete and specified, not as the argument itself. The argument rests on where the data lives and who can prove what was done to it.

The direction of travel

Through the rest of 2026 and beyond, two forces are converging. Regulation is demanding provable control over automated decisions in essential functions, and geopolitics is making dependence on foreign-controlled infrastructure a board-level and sovereignty-level concern. Central banks feel both pressures more acutely than almost any other institution, because their data is uniquely market-moving and their independence is a public good.

The reasonable conclusion is not that central banks should avoid AI. It is that they should adopt it on their own terms: models they run, data that never crosses their perimeter, and an audit trail sealed against tampering and legible to their supervisors. A serious reader can weigh that against the convenience of the hosted alternative and reach their own view. The responsible position for monetary data is that ownership of the whole stack is not the cautious option. Given what is at stake, it is the responsible one.