Your cryptographic assumptions are about to break. Not in theory, not eventually, but within the planning horizon of systems you're validating today.
Model risk and assurance teams often assume the encryption protecting training data, model parameters, and inference APIs will hold. Quantum computing threatens that foundation. Yet most teams treat quantum risk as a distant concern, making predictable mistakes that will leave their AI systems exposed when quantum capabilities mature.
Here's why these errors persist and how to fix them before your cryptographic controls become obsolete.
Why These Mistakes Keep Happening
Quantum computing feels abstract. You can't test against it yet. NIST is still finalizing post-quantum cryptographic standards. Your immediate risks, like model drift, data quality, and adversarial attacks, demand attention now.
This creates a dangerous pattern: teams acknowledge quantum risk in principle but defer concrete action. The result? Cryptographic dependencies are baked into AI systems without quantum-resistant alternatives, governance frameworks assume current encryption holds indefinitely, and vendor contracts don't address cryptographic transition obligations.
The gap between awareness and action widens every sprint cycle.
Mistake 1: Treating Quantum Risk as a Pure IT Security Problem
Why it happens: Your information security team owns encryption standards, so you assume they own quantum risk too. Model risk teams focus on statistical validation, performance monitoring, and bias testing. Cryptography feels like someone else's domain.
Real consequence: Your model inventory doesn't track cryptographic dependencies. You can't answer: Which models rely on RSA-encrypted training data? Which APIs use elliptic curve cryptography? Which vendor models were trained on data protected by quantum-vulnerable encryption? When NIST finalizes post-quantum standards and your CISO mandates migration, you discover you lack the documentation to execute.
The fix: Add cryptographic dependency fields to your model inventory. For each model, document:
- Encryption algorithms protecting training data at rest
- Key exchange protocols for model API calls
- Cryptographic methods used by Foundation Model Providers in your supply chain
- Data retention periods (longer retention = higher quantum harvest risk)
Integrate this into your SR 11-7 documentation requirements. Model validation evidence should include cryptographic architecture diagrams, not just statistical performance metrics.
Mistake 2: Ignoring Harvest-Now-Decrypt-Later Threats in Model Training Data
Why it happens: You focus on protecting models in production. Training data feels historical, already encrypted, safely stored. The threat model assumes adversaries need real-time access to exploit vulnerabilities.
Real consequence: Adversaries are already harvesting encrypted datasets today, planning to decrypt them once quantum computers mature. If your training data includes personally identifiable information, protected health information, or proprietary business logic, that data remains valuable for years. A quantum-enabled adversary could decrypt your 2024 training corpus in 2029 and extract competitive intelligence, personal data, or model architecture details you thought were protected.
The fix: Conduct a Data Protection Impact Assessment specifically for quantum harvest scenarios. Prioritize:
- Training datasets with long-term sensitivity (customer behavior, medical records, financial transactions)
- Models trained on data encrypted with RSA-2048 or smaller key sizes
- Outsourced models where you lack visibility into the Foundation Model Provider's data retention and encryption practices
For high-sensitivity datasets, implement defense in depth now: combine current encryption with quantum-resistant algorithms in hybrid mode, reduce retention periods where feasible, and add Differential Privacy techniques to limit what adversaries could extract even after decryption.
Mistake 3: Waiting for Final Standards Before Planning Migration
Why it happens: NIST's post-quantum cryptography standardization process is ongoing. You don't want to invest in algorithms that might not be selected or could have vulnerabilities discovered during review. Waiting feels prudent.
Real consequence: Migration takes years, not months. You need to inventory systems, test compatibility, update vendor contracts, retrain operations teams, and validate that new cryptographic implementations don't break model performance or introduce new risks. If you wait until standards are finalized to start planning, you'll be 18-24 months behind organizations that began transition planning early.
The fix: Start your readiness assessment now:
Create a quantum transition roadmap that maps to your AI Lifecycle Processes (ISO/IEC 5338):
- Development phase: Require cryptographic flexibility in new model architectures; avoid hard-coding algorithm choices
- Validation phase: Add "cryptographic migration feasibility" as a validation criterion; flag models that would be expensive to re-encrypt or re-train
- Deployment phase: Implement cryptographic agility in APIs; design for algorithm swaps without service interruption
- Monitoring phase: Track cryptographic library versions and maintain update readiness
Run a tabletop exercise: simulate NIST releasing final standards tomorrow and your CISO mandating a 12-month migration. Identify your longest-pole dependencies now.
Mistake 4: Overlooking Quantum Risk in Vendor Due Diligence
Why it happens: Your Vendor Due Diligence questionnaires ask about current security practices, compliance certifications, and incident response. Quantum computing doesn't appear in standard third-party risk assessments yet, so it doesn't make your vendor intake forms.
Real consequence: You're inheriting quantum risk through your AI supply chain. Foundation Model Providers train on massive datasets, often retained for years for model updates and research. If their encryption is quantum-vulnerable and you lack contractual rights to demand cryptographic updates, you can't control your exposure. When quantum capabilities mature, you discover you're contractually bound to vendors who won't or can't migrate in your required timeframe.
The fix: Update your vendor risk assessment template to include quantum-specific questions:
- What encryption algorithms protect training data used for our models?
- What is your cryptographic transition roadmap and timeline?
- Will you provide cryptographic migration support as part of our contract, or is it a paid service?
- For Federated Learning or Secure Multi-Party Computation implementations, which cryptographic primitives are used and what's your post-quantum migration plan?
- What data retention policies apply to our training data, and can we request early deletion to reduce harvest risk?
Add quantum transition obligations to new vendor contracts: require notification when cryptographic standards change, mandate migration support, and establish clear data deletion rights.
Mistake 5: Assuming Model Retraining Solves the Problem
Why it happens: You reason that once post-quantum encryption is available, you'll simply retrain models on freshly encrypted data. The model itself doesn't "remember" the old encryption, so retraining feels like a clean break.
Real consequence: Retraining is expensive, time-consuming, and sometimes impossible. If your original training data was harvested and decrypted by adversaries, retraining doesn't undo that exposure. If your Foundation Model Provider no longer offers the base model you fine-tuned, you can't reproduce your current system. If regulatory approvals or Model Recalibration evidence were tied to specific training runs, retraining triggers new validation cycles and compliance reviews.
The fix: Separate data protection from model protection in your risk assessment. Even if you plan to retrain models, you need quantum-resistant encryption for training data now to prevent harvest attacks.
Document Model Limitations and Use Restrictions that account for cryptographic assumptions. If a model was trained on data encrypted with quantum-vulnerable methods, that's a material limitation. Your Instructions for Use should reflect the risk window.
For high-stakes models (credit decisioning, clinical support, fraud detection), maintain cryptographic provenance: document which encryption protected training data, when it was applied, and what quantum resistance it offers. This becomes part of your Validation Evidence and supports Root Cause Analysis if a breach occurs.
Prevention Checklist
Use this checklist during model intake, vendor onboarding, and annual governance reviews:
Inventory and Documentation
- Model inventory includes cryptographic dependency fields
- Training data encryption methods documented for each model
- Data retention periods recorded and reviewed for quantum harvest risk
- Vendor cryptographic practices documented in due diligence records
Risk Assessment
- Data Protection Impact Assessment includes quantum harvest scenarios
- High-sensitivity training data identified and prioritized for protection
- Vendor Model Risk assessment covers quantum transition capability
- Cryptographic migration feasibility included in model validation criteria
Planning and Governance
- Quantum transition roadmap created and integrated with AI lifecycle processes
- Tabletop exercise completed to identify migration dependencies
- Vendor contracts include quantum transition obligations and notification requirements
- Cryptographic provenance documented as part of Validation Evidence
Technical Controls
- Cryptographic agility designed into new model APIs and deployment infrastructure
- Hybrid encryption (current + post-quantum) implemented for high-sensitivity data where feasible
- Differential Privacy or other privacy-preserving techniques layered with encryption
- Model Limitations documentation reflects cryptographic assumptions and risk windows
The teams that start now won't just survive the quantum transition. They'll use it as a forcing function to build more resilient, better-documented, cryptographically agile AI systems. The ones that wait will spend 2029 in crisis mode, racing to patch systems they should have understood years earlier.
