AI and Post-Quantum Security: The Order That Survives

Most organizations I talk to treat AI adoption and post-quantum migration as two separate programs on two separate timelines, owned by two separate teams. They are not two problems. They are the same problem arriving from two directions, and they are already colliding. AI is generating enormous volumes of sensitive data on top of cryptographic foundations that will not survive a quantum computer, while adversaries harvest that data today to decrypt it later. If you get the order of operations wrong, you cannot engineer your way back. So here is the order I argue for: protect the data first, fix your cryptographic foundations second, scale your AI workloads third. In that sequence, and not another.

‍

I made this case recently with Ashar Samdani on the TechUnhinged podcast, in an episode we called "Why Your Data Is Never Safe." The full conversation is below. What follows is the structured version of the argument.

‍

‍

Why the collision is happening now, not in 2030

Two clocks are running at the same time, and neither one waits for your roadmap.

The first is the harvest-now-decrypt-later clock. Harvest now, decrypt later is the practice of intercepting and storing encrypted data today, on the bet that a future quantum computer will decrypt it before the data stops being sensitive. Nation-state actors are doing this now. This is not theoretical capture. It is operational: backbone tapping, exfiltration from compromised systems, supply chain intercepts. Storage is cheap and patience is free, so anything you send today with a ten or twenty year confidentiality requirement is already inside the threat window.

‍

The honest way to size this is Mosca's inequality, from Dr. Michele Mosca at the University of Waterloo. Let X be the years until a quantum computer can break your current cryptography, Y be the years your data must stay confidential, and Z be the years it takes you to migrate. If X is less than Y plus Z, you have a problem today. I am not going to hand you an exact Q-Day date, because nobody credible can. What is not in dispute is the direction: NIST plans its migration against a cryptographically relevant quantum computer arriving in the 2030 to 2035 window, the NSA's CNSA 2.0 already requires new national security systems to support quantum-resistant cryptography from 2027, and recent research from Google Quantum AI cut the estimated qubit count to break RSA-2048 from tens of millions to under one million under certain assumptions. The horizon is compressing, not receding.

‍

The second clock is AI. Every model, every agent, every retrieval index is generating and consuming sensitive data at a rate no prior system did. Corporate data, training data, embedded stores, and the agent memory itself, which is data that gets created, indexed, and stored in systems that were never architected for cryptographic agility. So you have more sensitive data than ever, produced faster than ever, sitting on foundations with an expiration date. That is why the two clocks are the same clock.

‍

AI is both the vulnerability and the weapon

The reason to protect the data before you scale AI is that AI widens the exposure from both sides at once.

‍

As a vulnerability, AI is where data goes to leak. People bleed sensitive information into public models, and factions inside organizations wire source code, chat windows, and agentic systems into endpoints they were never authorized to touch. Once your data lands inside someone's model, you cannot pull it back. You cannot unlearn it. And the failure mode is not always a human mistake. An AI coding agent that deleted a production database last year did exactly what it was told: learn and optimize. It decided it did not need that database. Autonomy without data-layer enforcement means the agent operates with whatever reach its session happens to have.

‍

As a weapon, the same capability lets adversaries generate attack code at scale and probe for the vulnerabilities that AI adoption just introduced. Defenders answer with AI too. The net effect is fewer easy attack-surface vulnerabilities over time, because everything learns and tightens, and more targeted, deep, far-reaching attacks aimed at the data itself. Data is the only prize that matters to an attacker. Everything else is a route to it.

‍

The sequence

1. Protect the data at the data layer. This is the load-bearing step. Bind identity, policy, and encryption to the data object itself, at the file level and the cell level, so that authorization and attribute control are enforced by the data rather than by the perimeter around it. Done properly, a leak stops being a breach. The attacker holds ciphertext they cannot use, tied to keys they cannot reach, governed by a policy that never granted them access. In many cases harvested data gets discarded before it is ever used, because it is not worth the effort. This is what "the unit of protection has changed" means in practice: the control plane is the data, not the network. (Read my last blog post on this here.)
2. Fix the cryptographic foundations. Crypto agility is the architectural ability to swap cryptographic algorithms and modules without re-engineering every system that depends on them. It is a property you design in, or you do not have it. That means an accurate inventory of every system and the cryptography it uses, a chosen standard (NIST finalized FIPS 203 for key encapsulation and FIPS 204 and FIPS 205 for signatures in August 2024), and the ability to swap cryptographic modules without re-touching every petabyte of historical data by hand. Most organizations cannot do this today because their systems were not built for the size or the computing cost of a post-quantum key. The work is to make agility consumable, to get rid of the undifferentiated heavy lifting of migration so you get speed, security, and the ability to change in one move. Quantum-safe and crypto-agile.
3. Then scale AI. Once the data is protected and the foundation is agile, you scale AI workloads on top of that base. Now the sensitive path is governed in the DNA of the data protection itself, not by a human policy document that an agent will ignore. When someone, or something, needs sensitive data, access runs through the keys and the policy, not through good intentions.

‍

Why the order is not negotiable

Do this out of sequence and you are building a skyscraper on sand. Everyone can see it is going to fail. Racing to deploy AI on cryptography that is already deprecating, and calling a passed audit "secure," is the exact mistake I want buyers to avoid. Compliance is not security. Compliance means you followed the directions and documented it. Security is actively preventing bad actors from doing what they should not. A framework is a floor. The architecture that satisfies several frameworks at once, because the data itself is bound to identity and policy, is the ceiling.

‍

The mismatch between how fast you are generating sensitive data and how slowly you are protecting it is not a gap you close later with more engineering. You close it now, at the data layer, or you inherit it retroactively when someone else's quantum computer opens the archive.

‍

For the unscripted version of this argument, including the parts on compliance, defense acquisition, and where the cloud industry stopped building, watch the full conversation on the TechUnhinged podcast: "Why Your Data Is Never Safe."

‍

‍

‍

About the author

Paul Bockelman is CTO of Qanapi. He spent nearly 25 years building cloud platforms for defense, federal, and intelligence customers, including nine years at AWS and three at Google Public Sector, before joining Qanapi.

‍