AI Post-Quantum / Cryptographic Agility / Long-Lived Evidence Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_POST_QUANTUM_CRYPTOGRAPHIC_AGILITY_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

重要说明: 本文用于 AI 系统加密敏捷性与长期证据架构分析，不构成密码学实施建议、法律意见、监管意见、信息安全认证意见、供应商采购意见或生产迁移方案。正式项目必须由 Security Architecture、Cryptography Engineering、CISO、Enterprise Architecture、Platform Engineering、Legal、Privacy、Records、Model Risk、Third-Party Risk、Compliance、Procurement、Internal Audit 和业务 owner 共同确认。适用性取决于业务场景、数据寿命、监管留存要求、协议栈、供应商产品、硬件生命周期、证书体系、密钥管理、合规要求和机构政策。

---

Source Anchors

核心导读

Post-quantum AI architecture 的核心不是预测量子计算何时可用，而是让 AI 系统中的加密依赖、长期证据、签名、密钥、证书、供应商、协议和归档对象可以被发现、分级、替换、验证和审计。金融零售 AI 的证据和客户数据往往需要多年保密和可验证，PQC 准备不足会同时影响 confidentiality、integrity、non-repudiation、records 和监管防御能力。

AI 系统的加密面比普通应用更分散：model gateway TLS、API token、JWT、agent tool signing、RAG 语料加密、vector store、prompt/output archive、model artifact signing、content provenance、customer communication evidence、vendor API、mobile SDK、workflow approval signature。任何一个长期依赖都可能成为 future decryption、signature obsolescence 或 evidence replay failure 的薄弱点。

成熟策略不是一次性“换算法”，而是建立 cryptographic agility：有 inventory、有算法元数据、有集中 crypto services、有 risk tier、有 migration roadmap、有互操作测试、有 vendor readiness、有 re-sign / re-encrypt 方案、有持续治理。

问题定义

AI 让加密风险从底层安全工程扩展到产品和证据架构。需要特别关注三类问题：

1. Harvest now, decrypt later：今天被拦截的长期敏感数据，未来可能因量子能力或算法淘汰而失去保密性。金融零售中的客户资料、贷款记录、投资沟通、欺诈调查、模型证据和员工记录都有长期价值。

2. Long-lived evidence verification：AI 决策、客户沟通、审批、模型版本、检索来源和审计包需要多年后仍可验证。如果签名算法过时、证书链不可验证或 key lifecycle 不完整，证据防御力会下降。

3. Embedded cryptography sprawl：AI 平台、供应商 SDK、开源库、代理框架、向量数据库、MLOps、DLP、KMS、API gateway、workflow tools 可能各自内置算法选择。没有 inventory 就没有迁移计划。

关键架构问题：

• 哪些 AI 数据和证据需要 3、7、10 年甚至更久的保密或可验证性？
• 哪些 TLS、签名、加密、token、certificate、key exchange、artifact verification 使用 quantum-vulnerable algorithms？
• 哪些组件支持算法替换、hybrid mode、metadata tagging 和 re-issuance？
• 哪些 vendor 需要 readiness attestation、roadmap、测试环境和合同义务？
• 如何在不中断业务、不过度误伤互操作性的情况下逐步迁移？

核心原理/方法

Crypto inventory before migration

迁移的第一步不是选算法，而是发现加密使用点。Inventory 应覆盖 protocol、library、algorithm、key length、certificate、KMS/HSM、data store、archive、signature、token、vendor dependency、owner、business process、data/evidence lifetime、替换能力和测试状态。

Data and evidence lifetime tiering

并非所有对象同等紧急。应按保密寿命、可验证寿命、客户影响、监管保留、攻击价值、外部暴露和替换难度分级。短期 ephemeral session 与长期客户记录、SAR/AML 证据、模型审批包、合同、审计记录的风险不同。

Algorithm metadata everywhere

加密对象需要携带 algorithm、mode、key id、certificate chain、signature timestamp、crypto provider、version、expiry、migration status。没有元数据，未来无法判断哪些对象需要 re-encrypt、re-sign、re-issue 或 quarantine。

Central crypto services over embedded choices

AI 应用不应在业务代码或 prompt workflow 中硬编码 crypto choices。尽量通过 KMS/HSM、certificate service、signing service、token service、secrets platform 和 policy-as-code 管理算法和密钥。

Hybrid and phased migration

PQC 迁移通常涉及互操作、性能、包大小、证书链、供应商支持和合规验证。混合方案和灰度迁移可以降低切换风险，但会增加运维复杂度和测试矩阵。目标是可回滚、可监控、可验证，而不是一次性替换。

Evidence renewal strategy

长期证据不只是加密保存，还需要验证能力续期。架构应考虑 timestamping、archive signing、periodic re-signing、hash chain、certificate renewal、key escrow/retirement、legal hold 和 migration proof。

系统/架构模型

推荐把 PQC 和 crypto agility 纳入 AI platform governance，而不是只作为网络层项目。

cryptographic discovery
  -> AI crypto inventory
  -> data / evidence lifetime classification
  -> quantum-vulnerable dependency map
  -> target crypto patterns and policy
  -> vendor readiness and contract review
  -> interoperability / performance testing
  -> phased migration and evidence renewal
  -> continuous crypto governance

关键组件：

AI 平台中的加密控制应与 software supply chain、model governance、records management 和 third-party risk 连接。模型文件签名、prompt/output archive、RAG corpus encryption、agent approval token 都不是安全团队孤立资产。

关键机制与取舍

迁移优先级 vs 业务连续性

最先处理的不是最容易改的系统，而是长期高敏数据、外部暴露面、证据防御力和替换窗口最紧的依赖。低风险短期流量可排后，高价值长期归档和外部 API 应优先进入评估和试点。

Hybrid mode vs 简化运维

Hybrid classical + PQC 可降低单算法不确定性和互操作风险，但带来更大的证书、握手、性能、日志和故障排查复杂度。需要明确哪些场景使用 hybrid、何时退出 hybrid、如何监控失败和降级。

集中 crypto service vs 应用自治

集中服务提升一致性和升级能力，但可能形成平台瓶颈和单点依赖。应用自治速度快，但长期会形成算法碎片。金融零售 AI 更适合中心策略与受控例外：标准路径集中，特殊场景经过风险接受和到期复核。

Re-encrypt vs re-sign vs preserve

数据保密性风险需要 re-encrypt 或重新包封密钥；证据可验证性风险可能需要 re-sign、timestamp renewal 或 hash chain extension；某些历史证据必须 preserve original plus migration proof。不能用同一种动作处理所有对象。

Vendor readiness vs vendor lock-in

大型 AI、云、identity、KMS、RAG、MLOps vendor 的 PQC 支持节奏不同。依赖 vendor roadmap 可以降低内部成本，但会增加锁定风险。合同应要求 roadmap transparency、notice、test access、algorithm metadata、exit-friendly evidence export。

Performance vs assurance

PQC 相关算法可能影响 handshake、token size、签名体积、移动端性能、存储和带宽。架构要做真实负载测试，尤其是 mobile banking、high-frequency API、agent tool call、batch signing 和 archive verification。

证据与控制

Crypto agility 的证据不是“安全团队说已经准备”，而是 inventory、分类、测试、迁移和例外都可审计。

关键指标：

• AI crypto inventory 覆盖率和未知算法数量。
• 长期证据对象中带 algorithm metadata 的比例。
• Quantum-vulnerable external connections、signatures、archives 的风险分布。
• Vendor PQC readiness 已确认/未确认/不可用比例。
• PQC/hybrid 测试的性能、失败率、兼容性缺陷。
• 例外到期未复核数量。
• 已完成 re-encrypt / re-sign / certificate re-issue 的对象比例。
• 新项目通过 crypto architecture gate 的比例。

金融零售/AI产品场景

Model gateway and API TLS

AI gateway 连接内部应用、云模型、供应商 API、客户渠道和 agent tools。需要盘点 TLS、mTLS、certificate chain、key exchange、API gateway policy、fallback path。迁移时要考虑移动端、浏览器、合作方和 legacy system 兼容性。

RAG corpus and vector store

RAG 语料包含政策、合同、客户记录、投诉、研究资料和内部知识。需要区分静态文档加密、embedding store、metadata、access token、backup、export、cross-region replication。长期敏感语料应优先进入 inventory 和 lifetime classification。

Agent tool invocation

AI agent 调用支付、账户、case、CRM、workflow、email、document generation 等工具时依赖 token、JWT、签名、approval record 和 audit log。Agent 越有执行权，越需要签名元数据、短期凭证、tool policy、non-repudiation 和 evidence renewal。

AI evidence archive

模型审批、prompt、retrieval、output、human review、customer communication、incident record、SAR/fraud evidence 可能需要长期保留。归档系统要支持原始证据保存、hash、timestamp、signature、re-sign、key retirement 和 replay verification。

Content provenance

AI 生成的营销、客户教育、图像、语音、合同摘要或顾问内容可能需要 provenance signature。PQC 准备不仅关系传输安全，也关系多年后能否验证内容源和修改链。

Mobile banking and customer channels

移动端 SDK、证书 pinning、push notification、secure messaging、document upload、biometric binding、device attestation 都有加密依赖。迁移要避免只看 server-side API，而忽略客户设备和版本分布。

Third-party AI vendors

云模型、身份验证、fraud analytics、HR AI、marketing automation、call center analytics、document AI vendor 都可能持有或处理长期敏感数据。Vendor readiness 应进入采购、续约、exit plan 和 incident response。

反模式

• 把 PQC 当作网络团队的 TLS 项目，忽略 AI 证据、RAG、agent、archive 和供应商。
• 没有 crypto inventory 就讨论算法替换。
• 只记录系统名称，不记录 algorithm、key、certificate、protocol、owner、lifetime 和替换能力。
• 新 AI 项目继续硬编码 crypto library 和 token 方案。
• 长期证据归档没有签名续期、时间戳续期或迁移证明。
• Vendor 只说“未来支持 PQC”，合同中没有测试、通知、元数据和出口要求。
• 迁移只在实验室跑通，未覆盖 mobile、partner、legacy、batch、high-volume agent calls。
• 把 re-encryption、re-signing、certificate rotation 混为一谈。
• 例外永久化，没有到期复核和风险接受记录。

最终心智模型

Post-quantum readiness 对 AI 系统而言，本质是长期信任维护。金融零售需要保护的不只是实时 API 流量，还有客户数据、模型证据、审批记录、内容来源、agent 操作和监管防御材料在多年后的保密性和可验证性。

可以用这条链检查成熟度：

crypto discovery -> inventory -> lifetime tiering
  -> algorithm metadata -> target pattern
  -> vendor readiness -> interoperability testing
  -> migration / renewal -> continuous governance

如果一个 AI 证据对象多年后无法说明它用什么算法保护、谁签名、密钥如何管理、何时迁移、迁移后如何验证，那它的证据价值会随时间衰减。成熟架构的目标不是押注某个算法永远安全，而是让算法变化成为可治理、可测试、可审计的常规能力。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。