AI Infrastructure and Post-Quantum Cryptography: What Security Teams Must Prepare For

Model weights trained on proprietary data are worth more than most organisations' entire IT infrastructure. GPT-4 class models carried published academic estimates of $50-100M in training compute alone, derived from Chinchilla scaling law analysis of reported hardware budgets. Enterprise fine-tuned models add IP value from proprietary training datasets and annotation investment that does not appear on any hardware bill. Yet the security posture applied to those artefacts is, in most deployments, identical to what is applied to any other enterprise application: standard TLS certificate management and cloud KMS key rotation policies designed for transient data.

The quantum exposure of AI infrastructure is specific, not generic. Model weights at rest are encrypted with AES-256, which Grover's algorithm reduces to approximately 128 bits of effective security. That is still practically unbreakable. The vulnerability sits one layer up, at the Key Management Service infrastructure that wraps the AES data keys. AWS KMS, Azure Key Vault, and Google Cloud KMS all use RSA or ECDSA for root key material in standard configurations. RSA and ECDSA are broken by Shor's algorithm on a cryptographically relevant quantum computer. The KMS key hierarchy is the cryptographic equivalent of a safe inside a safe: the inner safe is quantum-resistant; the outer safe is not. The question is when someone acquires the key to the outer one.

Separately, EU AI Act Article 15's requirement for "an appropriate level of accuracy, robustness, and cybersecurity" creates a compliance hook for AI security programmes that is dynamic by design. It will incorporate ENISA guidance as that guidance matures. Starting PQC migration of AI infrastructure now builds a defensible compliance position for the Article 15 obligation before the standard's practical content is fully defined.

AI infrastructure as a security target: what is actually at risk

Model weights as long-lived, high-value artefacts

Large language model weights, fine-tuned models, and domain-specific models trained on proprietary datasets represent a category of IT asset that most security frameworks have not explicitly classified for data sensitivity or retention priority. Model weights are stored in shared file systems (NFS, GPFS, Ceph), object storage (S3-compatible endpoints), and model registries such as MLflow and private Hugging Face hubs. These storage systems use AES-256 encryption at rest. The AES layer is quantum-resistant.

The exposure is at the KMS level. The AES data key that encrypts the model weights is itself wrapped by an RSA or ECDSA root key in the KMS hierarchy. That root key is the Shor's algorithm target. An adversary who intercepts and stores the KMS key exchange operations today, when quantum decryption of RSA is not yet feasible, will be able to unwrap the data key and decrypt the model weights once CRQC capability arrives. This is not a theoretical HNDL attack; it is a direct application of the HNDL mechanism to the specific KMS architecture that all three major cloud providers use as their default configuration.

The commercial sensitivity lifetime of model weights is not well-defined in most organisations, because most organisations have not explicitly addressed it. A model fine-tuned on five years of proprietary clinical trial data, medical literature, and internal annotation has sensitivity that extends well beyond a standard 90-day or annual key rotation cycle. The KMS keys that wrap those weights are being rotated on IT infrastructure timelines. The retention horizon for the artefacts they protect is measured in years or decades.

Training data as HNDL exposure

The training data pipeline, the movement of datasets from data lakes to preprocessing environments to GPU clusters, uses TLS-encrypted connections with RSA or ECDSA key exchange. This is standard enterprise TLS, and it carries the same HNDL exposure as any other enterprise TLS traffic. For AI training specifically, the data involved may include healthcare records, legal communications, financial data, or government information that carries statutory retention and sensitivity requirements extending 20 years or longer.

A healthcare AI model trained on ten years of patient records has de-identified but sensitivity-bearing training data. The transfers that moved that data to GPU cluster storage used TLS sessions that, if intercepted, can be retroactively decrypted. The data was de-identified; it was not made cryptographically permanent. For a structured approach to assessing HNDL exposure for long-lived datasets, apply the methodology in the HNDL risk assessment framework.

GPU cluster TLS and IPsec: the configuration exposure

Inter-node communication

Distributed training on GPU clusters, whether NVIDIA DGX A100/H100, AMD Instinct MI300X, or cloud-managed GPU infrastructure, uses high-bandwidth interconnect fabrics and cluster management APIs that carry standard enterprise cryptographic vulnerabilities. InfiniBand deployments with IPsec-RDMA extensions use IKEv2 for security association negotiation; IKEv2 (RFC 7296) uses RSA or ECDH key exchange by default. RoCEv2 configurations with IP-layer security carry the same IKEv2 exposure. Cluster management APIs, including REST and gRPC interfaces for cluster orchestration, operate over TLS 1.3 with RSA or ECDSA certificates in standard deployment configurations.

These are not exotic protocol choices. They are the same cryptographic infrastructure that every enterprise uses for authenticated communications. The difference for AI clusters is the value of what the encrypted traffic contains: model weights during checkpoint transfers, training data batches, and gradient updates during distributed training. The asset value that the cryptography is protecting is substantially higher than on a typical enterprise application server.

Model serving infrastructure

Model serving endpoints using NVIDIA Triton Inference Server, KServe, or vLLM expose REST and gRPC APIs over TLS. Production deployments use RSA-2048 or ECDSA-256 certificates from enterprise CAs or cloud-managed certificate services. Inference endpoints are the highest-exposure surface for a specific class of attack: an adversary who intercepts and decrypts inference traffic at scale can recover input data, output logits, and indirectly reconstruct model behaviour. The PKI migration requirements that underpin this certificate lifecycle are detailed in the PQC in PKI migration planning guide.

This is not the same as a classical model extraction attack. It is worth being precise about the distinction because conflating them leads to incorrect remediation decisions.

Model-stealing attack vectors and quantum acceleration

Model extraction: the standard threat

Classical model extraction, as documented by Tramèr et al. in their 2016 USENIX Security paper "Stealing Machine Learning Models via Prediction APIs", works by making repeated queries to a model's public API and using the output distributions to reconstruct the model's decision boundary. For some architectures, this can approximate the model's weights with sufficient query volume. This attack operates via public API access. It does not require decrypting network traffic, and it does not rely on any cryptographic vulnerability.

Quantum computing does not accelerate classical model extraction in any meaningful way. Grover's algorithm, which provides a quadratic speedup for unstructured search problems, does not apply to the input-output sampling process that model extraction exploits. A CRQC does not make model extraction faster or more effective.

Quantum-assisted model extraction: the distinction

The quantum risk to AI inference infrastructure is specifically at the transport layer, not the model API level. A CRQC breaks the RSA or ECDSA key exchange on the TLS connection carrying inference requests and responses. With the session key recovered, an adversary who has been collecting inference traffic can decrypt every request and response in that archive: the input prompts, output tokens, and logit distributions that reveal model behaviour at scale. This is an HNDL attack on the inference stream. The remediation is PQC migration of TLS on inference endpoints, not model architecture changes.

Keeping these two threat categories separate prevents a common framing error in AI security discussions: the assumption that model hardening techniques (output filtering, query rate limits, differential privacy) address the quantum risk to AI infrastructure. They do not. The quantum risk is at the infrastructure layer that those techniques do not touch.

KMS rotation cadence and AI workloads

Why model artefacts require deliberate KMS policy

Standard KMS key rotation policies, whether the 90-day cycles common in financial services or the annual rotation typical in enterprise settings, are designed for transient or short-lived data encryption. Model artefacts occupy a different retention category. Training checkpoints, fine-tuned weights, evaluation datasets, and benchmark results are stored for multi-year periods. They may be subject to litigation holds, regulatory data retention requirements, or IP protection obligations that prevent deletion.

A KMS key that wrapped model training data in 2024, rotated in 2025 with the previous key version retained for decryption, is a long-lived cryptographic artefact. The root key wrapping mechanism for that retained key version is RSA or ECDSA in standard AWS KMS, Azure Key Vault, and GCP Cloud KMS configurations. That root key material is the HNDL target. Key rotation of the data-encrypting key does not help if the root key wrapping it is retained in a vulnerable state. The sensitivity lifetime question is best addressed through the Mosca inequality calculator walkthrough, which makes the data lifetime input concrete for AI artefact categories.

AWS KMS, as of August 2025, supports RSA-2048, RSA-3072, RSA-4096, ECC P-256, and ECC P-384 key material types. ML-KEM key material type support was not available at that date. Verify the current state of KMS ML-KEM support at the AWS KMS developer documentation before treating this as a current configuration option, as cloud provider PQC roadmaps are advancing rapidly. For a comparative assessment of PQC readiness across cloud KMS providers, see PQC readiness: AWS KMS, Azure Key Vault, and GCP Cloud KMS.

The migration path for KMS

The recommended approach for AI workloads during the migration period is a hybrid key hierarchy. The envelope key protecting the AES data key is wrapped using both a classical key (RSA-4096 or ECDSA) and a post-quantum key (ML-KEM-1024, the highest security level in FIPS 203) in parallel. An adversary must break both to recover the data key. This provides classical security until PQC implementation is fully verified and audited, while adding quantum resistance as the outer layer.

ML-KEM-1024 is appropriate for model artefacts of high commercial value and long sensitivity lifetime. The larger key sizes (1,568-byte public key, 1,568-byte ciphertext) are not a constraint at the KMS level, where key wrapping operations are infrequent. The computational cost difference between ML-KEM-768 and ML-KEM-1024 is negligible for this use case.

EU AI Act Article 15: cybersecurity requirements for high-risk AI

Article 15 scope

EU AI Act (Regulation (EU) 2024/1689), Article 15(1) mandates that high-risk AI systems achieve "an appropriate level of accuracy, robustness, and cybersecurity." Article 15(5) specifically requires that high-risk AI systems be "resilient against attempts by unauthorised third parties to alter their use, outputs or performance," which in the context of model infrastructure means protection of model artefacts and training data from exfiltration, not simply protection of the inference API from adversarial inputs.

High-risk AI systems are defined in Annex III and include AI used in critical infrastructure, employment decisions, education, financial services, law enforcement, and border control contexts. Organisations deploying AI in any of these categories are directly in scope for Article 15's cybersecurity obligation. For the detailed analysis of how Article 15 intersects with quantum security requirements, see EU AI Act cybersecurity requirements and quantum risk.

Article 15 and quantum risk

The EU AI Act does not mention post-quantum cryptography or quantum computing. Article 15's cybersecurity requirement is a dynamic concept under EU law: its practical content evolves with published guidance from ENISA and the European Commission. ENISA has not yet finalised AI Act Article 15 implementation guidance; inclusion of PQC readiness as a component of Article 15 compliance is a reasonable forward-looking expectation, not a current regulatory requirement. ENISA's existing NIS 2 guidance characterises PQC migration as part of good cryptographic hygiene for long-lived systems, and that framing is likely to carry through into AI Act guidance as it matures. The practical content of Article 15 will in time include PQC readiness for AI systems handling sensitive long-lived data, but that point has not yet been reached.

For compliance programmes: treating ML-KEM migration of model artefact KMS infrastructure as an Article 15 deliverable is a defensible and forward-looking framing, given that FIPS 203 is the NIST-published standard referenced by ETSI and ENISA as the authoritative PQC baseline. Building a documented PQC migration programme now creates an evidence trail for Article 15 compliance before ENISA's AI Act cybersecurity guidance finalises the specific requirements. For organisations also in NIS 2 scope, the NIS 2 implementation pillars for cyber resilience officers shows how Article 15 AI obligations sit within the broader NIS 2 cryptography requirement.

NIST AI RMF alignment

Where PQC migration fits in the AI RMF

NIST AI Risk Management Framework 1.0 (January 2023) organises AI risk management across four functions: Govern, Map, Measure, and Manage. PQC migration of AI infrastructure maps directly across three of the four. Under Govern: establishing cryptographic security policy for AI artefacts, including KMS key material types and rotation schedules appropriate to artefact sensitivity lifetimes, is a governance decision that should be documented at the level of AI risk governance policy. Under Map: identifying cryptographic dependencies in AI infrastructure is the CBOM for AI systems, directly analogous to the cryptographic inventory work required for any enterprise PQC programme. Under Manage: implementing ML-KEM migration for KMS and TLS configurations is the operational migration work.

AI as quantum resistance tool: a distinction to maintain

This article covers one direction of the relationship between AI and quantum computing: the security of AI infrastructure against quantum threats. It does not cover the separate and largely speculative research area of quantum-accelerated AI capabilities, or the use of AI tools for automated cryptographic inventory and vulnerability scanning.

Conflating these creates a comfort that is not warranted. The claim that "AI will help solve the quantum security problem" is a different proposition from anything in this article. AI-assisted PQC migration tooling is a legitimate adjacent topic. It is not a substitute for migrating the cryptographic infrastructure that protects AI artefacts. Those are two separate activities, and treating them as linked risks deferring the migration programme while the tooling matures.

Practical security team actions

Immediate term (now to 2027)

Four actions establish the baseline for AI infrastructure PQC migration. First, inventory KMS key material types for all AI workloads: identify RSA versus ECDSA root key wrapping for every model registry, training data store, and model checkpoint archive. This is a one-time discovery task that takes hours, not months. Second, classify model artefacts by sensitivity lifetime and commercial value. Not all models warrant immediate priority; a production recommendation model trained on 90 days of transactional data has a different risk profile from a clinical AI model trained on a decade of proprietary clinical data. Third, audit TLS certificate configurations on model serving endpoints and cluster management APIs, identifying RSA-2048 deployments as the first migration tier. Fourth, enable TLS 1.3 with hybrid key exchange on serving endpoints where the TLS library supports it. OpenSSL 3.5 supports X25519+ML-KEM-768 hybrid groups; enabling them at the gateway level does not require application changes.

For assessing HNDL exposure across the inference stream specifically, see how HNDL applies to data in motion across enterprise infrastructure.

Medium term (2027-2031)

Three medium-term actions complete the migration programme for most AI infrastructure configurations. Migrate KMS root key material to ML-KEM-1024 (FIPS 203) as cloud provider support becomes available. The hybrid wrapping approach described in the KMS section above is the bridge configuration for the period before native ML-KEM KMS support is available from all three hyperscalers. Update IKEv2 configurations on GPU cluster IPsec deployments to RFC 9370 (Multiple Key Exchanges in IKEv2), which adds hybrid post-quantum key exchange to the IKEv2 negotiation without replacing the underlying IPsec infrastructure. Apply Article 15 cybersecurity documentation: treat PQC migration progress as evidence of appropriate cybersecurity under Article 15(1), with dated records of each migration phase as the audit trail.

QSECDEF's PQC migration strategy and roadmap for cybersecurity leaders provides a structured programme framework that AI security teams can adapt for the specific sequencing requirements of GPU cluster, KMS, and model serving infrastructure.