平台工程团队在过去十年中已经标准化了 Kubernetes 集群、流水线、内部开发平台（IDP）和用于 Web 和微服务工作负载的流程。如今，随着组织将大型语言模型（LLM）和 AI 代理集成到生产工作流程中，平台工程 1.0 正在转变为平台工程 2.0。这一转变对安全性有明确影响，尤其是在这个新的代理世界中对隔离和合规的要求。但对于那些显然担心支出的人员而言，一个有效的平台工程 2.0 策略应代表一种演变，而不是重置。这些在基础平台工程 1.0 基础层中的变化在博通最近推出的平台工程 2.0 蓝图中可以找到。对于治理和合规，仅限于文档和应用代码是不够的。相反，结构化框架必须通过实施一致的保护机制、政策和程序来有效防范 AI 风险，确保真实的技术控制。安全责任必须转移到平台本身，由平台层级强制执行，而不是在部署后附加。AI 加剧了安全担忧。在 IT 中一直存在一个真理：人类不可避免地会（无论知情与否）将坏代码引入基础架构。有了 AI 代理的参与，如果允许 AI 将坏代码引入基础设施，这一公理将被放大，结果可能从小错误到重大故障，尤其是在高度分布式环境中。因此，强隔离机制至关重要。第二个关切是遵守旨在应对 AI 生成代码和大型语言模型（LLMs）爆炸性增长的新监管法规。由于对数据居留的新监管要求，持续合规成为必要。为了解决这个问题，平台工程 2.0 将政策即代码的执行自动化，作为核心能力。这为安全和合规团队提供了一个本地平台层，以规定保护机制，而不是强迫他们在部署后审计脆弱、定制的应用架构。平台工程 2.0 如何处理 AI 安全性将 AI 安全性视为一种一流的工作负载类型，而不是特殊案例，具备用于治理和隔离的本地构造。虽然平台工程 1.0 提供了“默认安全”的 Kubernetes 集群和 GitOps 流水线，但 2.0 增加了“默认治理”的模型访问和“默认隔离”的 AI 工作负载通道。将安全性下移到平台和运行时层旨在补充传统的“左移”流水线检查。它扮演着一个持续的运行时安全网，捕捉静态代码分析和流水线模板完全遗漏的主动的、不可预测的威胁。这种基础平台架构是必需的，因为前沿模型正以前所未有的速度扩大安全差距，而传统的附加应用控制无法快速响应。平台基础层必须原生预防模型中毒和推理数据泄露——这两个关键攻击向量是平台工程 1.0 架构从未预见到的风险。甚至像提示注入这样常见的风险最终也属于这种更广泛的隔离之伞之下，而行业目前缺乏能够无缝处理这些问题的本地平台架构。在高层次上，2.0 迭代围绕两个基础安全支柱展开：首先，严格的平台级 AI 模型治理使用一个控制层，强制执行政策、数据处理规则和记录日志，适用于所有模型和提供者，无论它们运行在哪里。其次， robust 工作负载隔离被融入平台架构中，并通过结构性强制措施确保一个 AI 工作负载不能渗透另一个的数据信息、机密或性能范围。这两者必须作为平台能力而非定制模式公开，以便开发人员可以通过 API 和模板将其作为自服务基础设施使用，而无需根据应用重新实现。支柱 1：模型治理 模型治理作为集中控制层运作。由于模型特定治理在大规模下会出现问题，模型层之上的控制层可以强制执行政策、记录决策并监控所有模型的行为。平台工程 2.0 通过四个核心元素实现这一目标。首先，一个中央模型注册表通过一致的 API 追踪已批准的能力和位置。第二，统一的政策执行在普遍范围内锁定数据处理和安全规则。第三，集中审计提供单一的视图，便于追踪事件和记录请求。最后，标准化的访问工作流自动将开发人员请求映射到风险级别，取代人工安全例外。这种“基础设施即 AI”充当了裁判，允许企业平台团队选择他们想要的模型，从而开发人员可以挑选自己所需的模型而无需