平台工程 2.0：面向 AI 负载的安全与隔离架构

随着大语言模型（LLM）与 AI 智能体逐步进入生产环境，传统的平台工程范式——以 Kubernetes 集群、CI/CD 流水线与内部开发者平台（IDP）为核心——正面临新的安全与合规压力。业界开始提出「平台工程 2.0」的概念，主张把 AI 当作一类一等公民的工作负载来对待，而非在既有 Web 与微服务架构上临时叠加补丁。

为什么 AI 放大了安全风险

长期以来，IT 领域有一条不成文的定律：人或早或晚会把坏代码引入基础设施。当 AI 智能体被赋予修改基础设施的能力后，这条定律被进一步放大，潜在的故障可能从轻微 Bug 演变为大规模宕机，尤其是在高度分布式的环境中。

与此同时，围绕 AI 生成代码与大模型的监管正在快速收紧。出于数据驻留与持续合规的需要，传统的「事后审计」模式已经不够用，企业必须在平台层就内嵌合规与治理能力，而非在部署完成后再去修补。

两根支柱：模型治理与负载隔离

平台工程 2.0 把 AI 安全拆解为两个相互独立又彼此配合的基础支柱。

支柱一：模型治理

目标是构建一个统一的控制平面，覆盖所有模型与提供商，无论它们部署在何处。具体落地通常包含四个要素：

• 集中的模型注册表（Model Registry）：通过一致 API 跟踪已批准的模型能力与部署位置。
• 统一的策略执行：把数据处理与安全规则以策略即代码（Policy-as-Code）方式落到所有模型上。
• 集中的审计与日志：提供单一视图用于事件追溯与提示词记录。
• 标准化的访问工作流：自动把开发者的请求映射到风险等级，取代手工的安全豁免流程。

这种「Infrastructure as AI」的思路让平台团队可以预先挑选与审批模型，而开发者则通过自助式 API 与模板按需取用，无需每次都提工单或手写 YAML。

支柱二：负载隔离

AI 改变了传统多租户模型的边界，平台必须从结构上保证一个 AI 负载无法污染另一个负载的数据、密钥或性能表现。关键做法包括：

• 为实验沙箱、内部负载与受监管数据分层设立独立域。
• 通过打标资源池与负载组，隔离共享 GPU、向量存储等后端硬件，防止高负载推理任务影响延迟敏感的交互应用。
• 引入零信任身份控制，把模型与工具绑定到最小权限的服务身份，抑制提示词注入成功后的横向移动。
• 在集群、节点与 Pod 各层对齐网络、存储与运行时策略，并借助机密计算（confidential computing）强化保护。

从「默认安全」到「默认治理」

平台工程 1.0 已经能做到 Kubernetes 集群与 GitOps 流水线的「默认安全」。进入 2.0 阶段后，平台进一步提供「默认治理」的模型访问能力，以及「默认隔离」的 AI 工作负载通道。这些能力与传统的「左移」流水线检查形成互补——左移检查擅长发现静态问题，而平台层则充当持续运行的运行时安全网，捕捉静态分析与流水线模板无法覆盖的实时威胁。

需要承认的是，前沿模型带来的安全缺口扩张速度，远快于外挂式应用控制手段的响应速度。模型中毒、推理数据泄露等新型攻击向量，原有平台架构从未预设针对；而提示词注入这类常见风险，目前也缺乏原生平台机制去无缝应对。把安全职责下沉到平台与运行时层，让治理成为平台一等公民，正是在这一背景下被反复强调的方向。