ISO/IEC 42001 and the Sovereign Runtime: What an AI Management System Actually Asks For

In 2026 the conversation about artificial intelligence governance stopped being theoretical. ISO/IEC 42001, the first management system standard written specifically for AI, moved from a document specialists discussed to a line item procurement teams enforce. Over the year several of the largest providers of AI infrastructure secured certification against it, and once the biggest sellers hold a badge, the badge becomes the floor that buyers in regulated sectors ask for before a serious conversation begins.

The timing is not accidental. The EU AI Act reaches its next major milestone on 2 August 2026, when a broad set of obligations for general-purpose and high-risk systems come into full application. The UK Sovereign AI programme has pushed public bodies to think harder about where models run and who can see the data. Inside the NHS, unease about sending clinical information to systems the operator cannot inspect has become a governance concern rather than a footnote. ISO/IEC 42001 arrives into that pressure as the common language everyone can point to, which is why the detail of what it asks for matters.

What the standard is, and what it is not

ISO/IEC 42001 is a management system standard, in the same family as the established standards for information security and quality management. It does not certify a model as safe, accurate or fair. It certifies that an organisation has an AI management system: a documented, repeatable way of identifying AI risks, assigning ownership, setting controls, monitoring outcomes and improving over time. The object of certification is the discipline, not the algorithm.

This distinction is the one buyers most often miss. A certificate tells you a provider can describe how it governs AI and show an auditor the evidence. It does not tell you that any given output is correct. The standard leans on a familiar structure: context and scope, leadership commitment, risk and impact assessment, operational controls, performance evaluation and continual improvement, with Annex A setting out control areas from data governance and transparency to accountability across the system lifecycle. The practical question, then, is not whether an organisation says it does these things, but whether the underlying architecture lets it prove them without asking anyone to take its word.

Where the controls meet the runtime

Most of ISO/IEC 42001 can be satisfied on paper by a diligent team: policies written, roles assigned, risk registers maintained. The friction appears at the controls that demand evidence of what a system actually did: data provenance, logging, access control, incident traceability and the ability to show, after the fact, exactly which inputs produced which outputs and who authorised them.

Those are runtime properties, decided by where computation happens and how it is recorded, not by the quality of the surrounding documentation. When inference runs on infrastructure the operator does not control, that operator inherits a governance system it can describe but cannot independently verify. The logs belong to someone else, the data path crosses a boundary the auditor cannot walk, and the provider's certificate becomes a proxy for trust the buyer cannot reconstruct on its own.

“A management system is only as credible as the evidence it can produce without asking anyone to trust it.”

Why sovereignty changes the evidence

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, and every action it takes is cryptographically sealed. That single architectural choice reframes much of the ISO/IEC 42001 evidence problem, moving the controls from things an organisation asserts to things the system enforces.

Consider data governance and residency, which sit at the centre of both the standard and the NHS concern. When a SIOS executes inside the operator's own perimeter with a zero-egress inbound design, information does not leave to be processed elsewhere. With no outbound data path to a third-party endpoint, residency is not a policy commitment that a misconfiguration could breach but a property of the deployment, and the evidence for the control is the absence of the egress, a stronger position than a contractual promise not to retain data.

Traceability follows the same logic. Every action a SIOS performs is recorded to an audit chain sealed with post-quantum signatures, so the record cannot be altered after the fact without breaking the seal. Identity is hardware-attested, so the actor behind each action is bound to a specific machine rather than a reusable credential. For the accountability and logging controls in Annex A, this produces what an auditor wants: a tamper-evident sequence showing which input produced which output, on which hardware, under whose authority.

Verifiability that survives disconnection

A quietly important consequence of running offline is that verification does not depend on the network being up or on a vendor remaining in business. Governance evidence that can only be produced by calling a remote service is fragile: it fails during an outage, and it disappears if the supplier does. Offline verifiability means the operator can inspect the audit chain, confirm the signatures and reconstruct the decision trail using only what sits on their own hardware. This matters for the continual improvement and performance evaluation clauses, which assume the organisation can look back at real operational data and act on it. It matters more for public bodies that must retain records for years and cannot accept a compliance posture held hostage to a third party's uptime.

Where model behaviour meets governance

ISO/IEC 42001 asks organisations to manage risks arising from AI outputs, including reliability and the impact of errors. This is where architecture and governance stop being separable: a single model is a single point of failure, and its confident mistakes are the hardest kind to catch.

Running several sovereign models and requiring them to agree, a cross-model consensus approach, gives the management system a mechanism rather than a hope. Disagreement between models flags an output for review instead of passing it through. That is a concrete control the standard's risk clauses can point to, and it produces its own logged evidence: the record shows not only the answer but the degree of agreement behind it. Agentic-audit governance, where the system's own processes are checked continuously rather than sampled once a year, fits the same frame.

The architecture behind these mechanisms is the subject of 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD. We describe them here as filed and patent pending, and mention them only because the question of how a runtime produces verifiable governance evidence is precisely what they concern.

What a serious buyer should ask next

A certificate against ISO/IEC 42001 is worth having and worth asking for; it is a reasonable signal that a provider takes AI governance seriously. It is not, on its own, an answer to the question a CISO, a regulator or a public-sector buyer actually needs to settle: can we independently prove what this system did with our data, without depending on the party we are auditing.

The better line of questioning goes past the badge. Where does inference physically run. Can the operator inspect the full audit trail without a network round-trip. Is the log tamper-evident, and by what cryptographic means. Is data residency a property of the deployment or a clause in a contract. When these questions have architectural answers rather than procedural ones, the management system rests on foundations an auditor can walk end to end. As the EU AI Act obligations land and sovereign-AI expectations harden through 2026, the difference between governance you assert and governance you can prove will decide which systems survive real scrutiny.