Ten questions to test whether your AI is quantum-ready
A ten-point pass or fail test for quantum-readiness, with a liftable scorecard and how a sovereign, offline SIOS satisfies every check.
Apply a ten-point pass or fail test; fail one check and your AI is not quantum-ready, because a single weak link exposes long-lived data.
This matters now because the migration has a deadline you do not control. Adversaries can harvest encrypted traffic today and decrypt it once a cryptographically relevant quantum computer arrives, so any record with a long confidentiality life is already exposed. NIST finalised the core post-quantum standards in 2024, regulators including DORA, in force since January 2025, and NIS2 now expect demonstrable operational resilience, and boards are asking a simple question: can our AI prove its records will still stand. Mickai is a Sovereign Intelligence Operating System, a SIOS, built and live, running offline on operator-owned hardware with every action cryptographically sealed, so these checks are answered by design rather than retrofitted.
What does quantum-ready actually mean for AI?
Quantum-ready means every record your AI produces can still be verified and its secrets kept once a large quantum computer exists, using standardised post-quantum cryptography.
Quantum-readiness is not about running on quantum hardware. It is about surviving quantum hardware. The threat is arithmetic: Shor's algorithm breaks the RSA and elliptic-curve mathematics that protects most signatures and key exchange today. A quantum-ready AI therefore signs its records with post-quantum algorithms, keeps long-lived secrets under schemes a quantum computer cannot unwind, and can prove both without trusting a vendor. Anything less is a system that works until the day the mathematics changes.
Which post-quantum standards should sign the record?
FIPS 204 and FIPS 205 sign the audit ledger; FIPS 203 only encapsulates keys and never signs, so any system claiming 203 signatures fails immediately.
Signing and encryption are different jobs, and conflating them is the commonest error we see. FIPS 204, ML-DSA, and FIPS 205, SLH-DSA, are digital signature standards: they are what seals an audit ledger so a record cannot be altered undetectably. FIPS 203, ML-KEM, is a key-encapsulation mechanism: it protects a key in transit and never produces a signature. A quantum-ready audit trail is signed by 204 or 205. If a vendor tells you 203 signs the ledger, they have misread the standards, and that alone is a fail.
What are the ten checks, and how do we score them?
Each check is binary: a clear pass condition and a fail signal. Score all ten; a single fail means not quantum-ready, regardless of marketing language.
The ten checks below are deliberately binary. There is no partial credit, because an attacker only needs one unguarded record. Score your own system against every row: a pass condition you can demonstrate, or a fail signal you can see. The final column shows how the Mickai substrate satisfies each check.
| Check | Pass condition | Fail signal | How Mickai satisfies it |
|---|---|---|---|
| Cryptographic inventory | You can list every algorithm, key and certificate in use. | No one can name what protects each record. | Every seal records its scheme, so the ledger is a live inventory. |
| Post-quantum signatures on new records | New records are signed with FIPS 204 or 205. | New records still rely only on RSA or ECDSA. | The audit ledger is signed with ML-DSA, FIPS 204. |
| Hybrid during transition | Classical and post-quantum run together while migrating. | A single scheme with no fallback. | We pair classical and post-quantum signatures through transition. |
| Crypto-agility | Algorithms can be swapped without rewriting the system. | The scheme is hard-wired into the format. | Schemes are configurable and named per record. |
| Protection of long-lived records | Data kept beyond ten years is already quantum-safe. | Archives sit in harvestable classical encryption. | Long-lived records carry post-quantum seals from creation. |
| Key custody | You hold and rotate your own keys. | A vendor holds keys you cannot see. | Keys stay in operator custody on owned hardware. |
| Offline verifiability | Signatures verify with no call to the vendor. | Verification needs the vendor's servers. | Any record verifies offline against the sealed chain. |
| Freedom from vendor lock-in | Records verify with open, standard algorithms. | A proprietary format traps your history. | Seals use NIST standards, not a private scheme. |
| Algorithm identifiers in the record | Each record states which algorithm signed it. | Records omit the scheme used. | Every sealed entry names its algorithm and version. |
| A re-signing plan | A documented process re-signs records when schemes age. | No plan to migrate old signatures. | Re-signing runs against the existing chain without loss. |
Why does offline verifiability decide the outcome?
Offline verifiability means anyone can check a signed record without calling the vendor; if verification needs their servers, you cannot prove integrity during an outage.
A quantum-ready record must be checkable by someone who does not trust, and cannot reach, the vendor who made it. Our seals verify against the sealed chain locally, behind a zero-egress inbound perimeter, so an auditor can confirm integrity during an outage, a dispute or a regulator's inspection. The same offline property is what lets sensitive workloads run without sending data to a public cloud, where the US CLOUD Act can compel a US-based provider regardless of where its servers physically sit.
How does Mickai stay crypto-agile without vendor lock-in?
We treat every algorithm as swappable: each record names its scheme, keys stay in operator custody, and a re-signing plan rotates schemes without rewriting history.
Crypto-agility is where most systems quietly fail: the signing scheme is baked into the file format, so replacing it means rewriting years of history. We designed the substrate the other way. Each sealed record names its own algorithm and version, keys remain in operator custody, and a documented re-signing plan lets us rotate to a new standard without breaking the existing chain. The underlying architecture, including the post-quantum signed audit ledger and hardware-attested identity bound to that chain, sits within 104 filed UK patent applications and 2,340 claims owned by Mickai LTD, Companies House 17166618, filed and patent pending. Freedom from lock-in follows naturally, because verification depends on NIST standards, not a private format only we can read.
Does quantum-readiness rule out ChatGPT, Copilot or Gemini?
No: ChatGPT, Copilot and Gemini excel at open, non-sensitive work; they simply cannot be the system of record for data that must outlive quantum computers.
Public AI services are the right pick for a great deal of work. ChatGPT drafts and researches at pace, Copilot lifts developer throughput, and Gemini is strong across everyday productivity, and for open, non-sensitive tasks that is exactly what most teams should reach for. The distinction is architectural, not competitive: these services keep keys and verification on the provider's infrastructure, so they cannot be the sovereign system of record for data that must remain provable for decades. That role needs offline verifiability and operator-held keys, which is the gap a SIOS is built to fill.
“Quantum-readiness is not a feature bought later; it is a property of how every record was signed and kept from the day it was created.”
Frequently asked questions
How do I know if my current AI is quantum-ready?
Run the ten checks above. Each is binary, and if any single check fails, the system is not quantum-ready, however capable it is elsewhere. The fastest tell is whether new records carry a post-quantum signature and name the algorithm that produced it.
Which FIPS standard actually signs the audit trail?
FIPS 204, ML-DSA, and FIPS 205, SLH-DSA, sign. FIPS 203, ML-KEM, only performs key encapsulation and never signs. Any vendor claiming that 203 signs the ledger has the standards wrong, and that is an immediate fail.
Why does offline verification matter if my vendor is reputable?
Reputations do not help during an outage, a contract dispute or a subpoena. If verifying a record needs the vendor's servers, you cannot independently prove integrity. Note that the US CLOUD Act can compel a US-based provider regardless of where its servers sit.
Does the EU AI Act require quantum-readiness by 2026?
Not directly. The high-risk Annex III obligations once due 2 August 2026 were deferred by the Digital Omnibus to 2 December 2027, with product-embedded high-risk obligations deferred to 2 August 2028 and Article 50 transparency largely unchanged. Quantum-readiness is driven by data lifetime and by DORA and NIS2 resilience duties, not a single AI Act date.
What is harvest now, decrypt later?
It is the practice of capturing encrypted traffic today to decrypt once a quantum computer exists. Any record with a long confidentiality life is therefore exposed already, which is why post-quantum sealing has to be present from the day a record is created, not bolted on later.