云端 AI 治理：架构师实操指南

你正在面对的问题 如果你在云端运行业务，那么你的团队其实已经在使用 AI 了：ChatGPT 插件、集成开发环境（IDE）中的 Copilot、悄无声息嵌入客户流程的 LangChain " 概念验证，或是一款本应临时使用、却留存至今的周末辅助工具。 问题不在于 AI 是否存在于你的 IT 资产中，而在于有多少相关实例是你不知情的。 微软针对英国企业机构开展的研究 "显示，71% 的员工会在工作中使用未获审批的 AI 工具，其中 51% 的人每周都会使用，该研究将这类行为明确定义为“影子 AI”，并着重指出其潜藏的安全隐患。Ivanti 等机构的调研同样表明，大量员工私自使用未授权 AI 工具，且大多通过个人账号登录使用。 近期发生的事件也印证了这一点。2025 年 8 月，针对 Nx npm 包的 s1ngularity " 供应链攻击利用恶意的安装后脚本从开发设备与持续集成/持续交付（CI/CD）运行环境中窃取 GitHub 令牌、云凭证及其他机密信息，让攻击者得以入侵下游各类环境。 2024 至 2025 年期间，多项调查，大量暴露在公网中的 Jupyter " 服务、大语言模型（LLM）服务器以及 AI 接口几乎未设置身份验证，部分设备还被用于加密货币挖矿、DDoS 攻击和数据窃取等恶意行为。 传统安全机制默认你清楚自身正在运行的业务与程序，而 AI 彻底打破了这一假设。有开发者为快速搭建原型接入 OpenAI API，尝试使用了真实客户数据，事后却忘了告知任何人。三个月后，该接口开始处理生产流量，没人敢贸然将其关停。 本指南后续内容将介绍如何以团队可接受的方式重新掌控局面。我们先从排查工作入手，讲解如何借助监控/可观测性工具检测基础设施中运行的各类 AI 服务。接着介绍数据写入时的分类规则，以及如何通过身份与访问控制落实控制，杜绝未授权数据流向大模型。 最后，我们将介绍策略即代码、模型注册表以及基于风险的审批机制，把治理工作融入常规交付流程，而非仅做事后审计。落实以上内容，就能显著提升 AI 模型的安全水平。 发现：找到你不知道的 第一步是梳理真实的 AI 接入节点清单。这件事看似简单，实际操作却并不容易。各类 AI 服务常常部署在现有工具无法监测的地方，下文我们会详细介绍可用于保护企业与数据的工具。 云访问安全代理扫描 云访问安全代理（CASB）部署在用户与云应用之间，可监控对各类主流 AI 服务商的接口调用。 Microsoft Defender for Cloud Apps "、 Netskope "、 Prisma Access " 等产品能够在用户访问 OpenAI "、 Anthropic "、 Hugging Face " 或 Azure OpenAI " 时及时发出告警。 大多数 CASB 产品都预设了 AI 应用分类。在 Defender for Cloud Apps 中，打开云应用目录，按“生成式 AI”筛选可将各个应用标记为已批准、未批准或监控状态。对于 Netskope，可使用“生成式 AI”应用分类创建实时防护策略。建议先将策略设为告警模式，持续运行三十天完成数据基线采集，之后再酌情启用拦截规则。 请至少为你的 CASB 告警筛选以下域名：api.openai.com、claude.ai、api.anthropic.com、huggingface.co，以及企业内部使用的所有 Azure OpenAI 接入端点。三十天后，你就能掌握各团队的使用情况、访问频次以及对应的终端设备信息。 部署后首日即可产生防护效果，且无需修改任何应用程序，但该方案的局限在深度方面：仅能查询到“昨日发起五百次 OpenAI 调用”这类统计数据，无法查看传输数据内容与发起调用的服务来源，CASB 也会遗漏自托管模型。 可将 CASB 作为发现和可见性工具，但不要把它当作拦截器。相关控制后续通过 IAM、虚拟私有云（VPC）权限控制或准入校验来实现。 服务网格遥测 采用服务网格部署自托管 AI 效果较为理想。若你正在使用 Istio "、 Linkerd " 或 AWS App Mesh "，相关运行数据已完成采集，只需执行查询操作即可查看。 针对运行 AI 工作负载的 Kubernetes 集群，先梳理出 AI 框架的实际部署分布情况。 第一步需要扫描所有命名空间中的 Pod，识别出运行主流 AI 框架的容器。该脚本利用 kubectl 的 JSON 输出结合 jq 过滤来搜索镜像名称，专门查找镜像中包含 TensorFlow "、 PyTorch "、 Hugging Face "、 MLflow " 或 Triton Inference Server " 引用的容器，这些框架代表了生产环境中最常部署的 ML 基础设施。 # 查找运行主流 AI 框架的 Pod kubectl get pods --all-namespaces -o json | jq -r ' .items[] | select((.spec.containers // []) | any(.image?; test("tensorflow|pytorch|huggingface|mlflow|triton"; "i"))) | {namespace: .metadata.namespace, pod: .metadata.name, images: ((.spec.containers // []) | map(.image) | unique)} ' | jq -s 'unique_by(.namespace + "-" + .pod)' 脚本会解析 JSON 输出，提取所有匹配 Pod 对应的命名空间、Pod 名称与唯一容器镜像。脚本采用大小写不敏感的正则匹配规则，可识别 TensorFlow、tensorflow 以及内置该框架名称的自定义镜像等各类变体。最后的去重过滤逻辑能够避免单个 Pod 内多个带有 AI 框架的容器生成重复记录。 识别出 AI 工作负载后，下一步关键操作是检查网络策略，明确网络访问权限。ML 模型通常需要对外建立连接，用于下载模型、上报遥测数据或是调用云服务。网络策略审计会重点排查两类规则：未配置出站规则（默认放行全部出站流量）、通过 IP 段放开外部访问权限的策略。 # 核查允许对外出站访问的网络策略 kubectl get networkpolicies --all-namespaces -o json | jq -r ' .items[] | select( .spec.egress == null or (.spec.egress[]? | ((.to[]?.podSelector == null) or (.to[]?.ipBlock != null))) ) | {namespace: .metadata.namespace, policy: .metadata.name, allows_external: true}'该脚本很有用，但也只是临时快照。想要持续监测新增服务，就需要长期采集运行数据，而这正是 API 网关日志发挥作用的地方。 API 网关审计 如果业