Quantum-Safe Planning for AI Infrastructure: Start With the Inventory
Harvest-now-decrypt-later makes long-lived AI assets — model weights, embeddings, training corpora — an attractive target today. The migration is a five-year programme, and the first year is discovery.
Post-quantum migration has an unhelpful reputation as a problem for later. For AI infrastructure specifically, that framing is wrong, because the assets involved have unusually long confidentiality lifetimes: a training corpus, a set of proprietary weights, and a customer's embedded documents are all still sensitive in fifteen years.
Why AI assets rank high on the harvest list
- Model weights represent concentrated, expensive intellectual property that does not expire.
- Embeddings are a reversible-enough representation of your entire document estate.
- Training corpora frequently contain regulated personal data with statutory retention far beyond the useful life of today's key sizes.
- Inference traffic carries customer content in real time, often over TLS terminated at a third party.
Year one is discovery, not migration
The organisations making progress are not swapping algorithms yet. They are building a cryptographic bill of materials: every place a key is used, what algorithm, what key length, who owns it, and what the confidentiality horizon of the protected data is. For AI platforms this means model registries, artifact stores, vector databases, feature stores, inference gateways and the service mesh between them.
The sequencing that works
1. Classify by confidentiality horizon
Anything that must stay secret past 2035 goes in the first migration wave. Most operational telemetry does not; most model artefacts and customer corpora do.
2. Fix the long-lived roots first
Code signing, artifact signing and model-provenance signatures have the longest tail. A signature you cannot trust in 2033 undermines every supply-chain control you built on top of it.
3. Hybrid key exchange in transit now
Hybrid post-quantum TLS is broadly available across major providers and libraries. Turning it on for inference and internal service traffic is a configuration change, not a rewrite, and it directly addresses harvest-now-decrypt-later.
4. Design for crypto-agility
Wrap cryptographic operations behind an internal interface so the next algorithm change is a library upgrade rather than an archaeology project. This is the deliverable that pays off regardless of the timeline.
What to tell the board
Not "quantum computers will break our encryption". Instead: "data we transmit today can be stored and decrypted later, several of our most valuable assets stay sensitive for a decade or more, and the migration takes years. We are starting with an inventory this year."
The risk is not a sudden cryptographic collapse. It is discovering in 2031 that nobody knows where the keys are.
