What Sovereign-AI Buyers Should Prepare Before the EU AI Act's December 2027 High-Risk Deadline

Sovereign-AI buyers should prepare for 2 December 2027, the corrected date for the EU AI Act's high-risk Annex III obligations after the Digital Omnibus moved them from 2 August 2026. Before that date, prepare four things: a complete technical file for every high-risk use, continuous event logging an auditor can replay, defined human oversight with named accountable roles, and infrastructure that keeps regulated data inside your own control. The reason this matters is simple: high-risk obligations are met with records you can produce on demand, not with assurances, so the system must generate that evidence from the first day it runs.

The 2026 market has the date wrong. The deferral was reported as relief, and some buyers paused their compliance work. We read it differently. The obligations did not shrink, and the systems that satisfy them take longer to assemble than the time that remains. A buyer who treats the extra months as a build window, rather than a pause, will hold working evidence when the date arrives.

What is the real deadline after the Digital Omnibus?

The Digital Omnibus repackaged the AI Act timeline. The high-risk obligations in Annex III, which cover uses such as critical infrastructure, employment, essential services, law enforcement and migration, now apply from 2 December 2027. High-risk systems embedded in products already regulated under Annex I, such as machinery and medical devices, follow from 2 August 2028. The transparency duties in Article 50, which require people to be told when they are dealing with an AI system or with synthetic content, are largely unchanged. The date to plan against for most sovereign buyers is 2 December 2027. The earlier figure of 2 August 2026 is no longer the live high-risk deadline and should be removed from internal plans.

Why is 2 December 2027 a build window and not a reprieve?

Nothing in the deferral reduced what a high-risk system must do. It only moved when the proof is checked. The work that produces that proof, being logging, documentation, oversight and a defensible data boundary, cannot be retrofitted in the final weeks. Audit evidence has to accumulate while the system operates, because an auditor asks what happened on a given day, not what the policy says should happen.

“The deadline moved, the burden of proof did not, and proof is built, not promised.”

What must a high-risk system be able to show an auditor?

The AI Act sets out obligations that read, in practice, as a list of things you must be able to hand over. A buyer should be able to produce each of the following on request:

• A technical file describing the system, its purpose, its data and its known limits.
• Automatic event logs that record each decision and let an assessor reconstruct it.
• Evidence of human oversight, including who can intervene and how.
• Data governance records showing where training and input data came from.
• Measures for accuracy, robustness and cybersecurity, with the tests that support them.

The plain test is replay: can you take any single output and show, from the record, the inputs, the model state and the person accountable? If the answer needs a meeting rather than a query, the system is not ready.

Which other rules make preparation urgent now?

The AI Act does not arrive alone, and several rules already bind. DORA has applied to financial entities since January 2025 and demands operational resilience and traceable digital records. NIS2 extends security and reporting duties across essential and important entities. GDPR still governs any personal data the system touches. ISO/IEC 42001 gives a certifiable management-system standard for AI that auditors increasingly expect. And the US CLOUD Act reaches data held by US-linked providers wherever it sits, which is why routing regulated data through public cloud AI services such as ChatGPT, Claude or Gemini creates serious compliance risk for regulated buyers. The jurisdiction of the infrastructure becomes part of the compliance question.

How does a sovereign architecture meet these obligations?

Mickai is a Sovereign Intelligence Operating System, a SIOS. It runs offline on operator-owned hardware, and every action is cryptographically sealed as it happens. That design answers the AI Act's evidence problem directly, through a small number of concrete mechanisms:

• Offline verifiability: the record lives on your hardware and can be inspected without a network round trip to any vendor.
• A zero-egress inbound perimeter: data can enter for processing, but nothing leaves the boundary, so foreign-jurisdiction reach and accidental disclosure are structurally removed.
• Hardware-attested identity bound to the audit chain: every action is tied to an attested device and role, so the log names who and what, not merely when.
• A post-quantum signed audit ledger: each entry is sealed with FIPS 204 (ML-DSA) as the primary signature standard, with FIPS 205 (SLH-DSA) available, so the ledger stays verifiable even against future quantum attack.
• Cross-model consensus: sovereign models check one another before an output is committed, which raises accuracy and leaves a record of the agreement.

The underlying design is protected by 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all patent pending.

What should a buyer prepare before December 2027?

A practical sequence for the time that remains:

• Map every AI use to its Annex III category and mark which are high-risk.
• Choose infrastructure whose jurisdiction you can defend, and keep regulated data off public cloud AI services.
• Turn on continuous, tamper-evident logging now, so evidence exists before the audit does.
• Assign named human oversight for each high-risk use, with a documented route to intervene.
• Assemble the technical file per use case, and keep it current rather than writing it at the end.
• Confirm your audit record is sealed with a signature standard that will outlast the hardware, meaning FIPS 204 and FIPS 205.

Each step produces evidence. That is the point. The buyer who finishes this sequence early is not waiting for December 2027, but demonstrating readiness through records that already exist.

Frequently asked questions

When are the EU AI Act high-risk rules actually due?

The high-risk obligations under Annex III now apply from 2 December 2027, after the Digital Omnibus moved them from 2 August 2026. High-risk systems embedded in products regulated under Annex I follow from 2 August 2028. The Article 50 transparency rules were largely unchanged.

Did the Digital Omnibus cancel the high-risk obligations?

No. It deferred the date they take effect, not the obligations themselves. A high-risk system will still need technical documentation, event logging, human oversight and cybersecurity measures. We read the deferral as a build window, because the evidence these rules demand takes time to accumulate.

Can we use ChatGPT or Claude for a high-risk regulated use?

For regulated data the answer is usually no. Public cloud AI services sit under foreign jurisdiction, and the US CLOUD Act can reach data held by US-linked providers wherever it is stored. Regulated buyers generally need infrastructure whose jurisdiction and data boundary they control, which is why sovereign, offline deployment exists.

What does offline verifiability mean for an audit?

It means the audit record is generated and stored on your own hardware and can be inspected without contacting any vendor. An assessor can replay a decision from the local log rather than requesting an export from a third party. This keeps the evidence available, self-contained and under your control.

Which post-quantum standard signs the audit ledger?

FIPS 204, the ML-DSA standard, is the primary signature standard that seals and verifies each ledger entry, with FIPS 205 (SLH-DSA) available as an alternative. FIPS 203 (ML-KEM) is a key-encapsulation standard and does not sign anything. Signing the ledger with a post-quantum standard keeps its records verifiable against future quantum attack.