一个行之有效的 Microsoft Azure AI 治理框架
审计人员会问一个问题：“请向我展示这项策略在运行时是如何执行的。”
大多数公司都无法通过这项测试。他们递交的是长达 40 页的文件和风险登记册。文件描述的是意图。它们无法阻止开发人员使用未经批准的模型，也无法阻止智能体（agent）生成子智能体。
你的政策手册与运行系统之间的鸿沟，正是违规行为发生的地方。
要解决这个问题，你需要一个强制性的 AI 网关。这是你的通用控制平面。每一次模型调用和每一次智能体操作都必须通过它。
在 Microsoft Azure 上，你必须连接三个平面：
• 身份 (Microsoft Entra)：网关在调用者接触模型之前对其进行身份验证。 • 数据 (Microsoft Purview)：网关执行 PII（个人身份信息）脱敏，并记录 Purview 可能遗漏的事件。 • 模型 (Azure AI Foundry)：网关强制执行模型白名单和 Token 限制。
强制性网关可以完成文件无法完成的三项任务：
- 它能终结影子模型（shadow models）：如果你只允许通过网关访问模型，未经批准的模型将无法连接。
- 它能遏制智能体蔓延（agent sprawl）：每一次智能体操作都必须路由到中心点进行授权。
- 它能产生持续的证据：每一次调用都会变成一个审计事件。你不再需要为审查临时制作证据，而是持续不断地收集证据。
不要将治理视为一种“速度税”。要将其视为架构的一部分。
不要再把影子模型视为一个检测问题。它是一个路由决策问题。如果你的网络只允许通过网关进行出口流量（egress），问题就会消失。
不要再仅仅将提示词注入（prompt injection）视为安全问题。它是一个问责问题。将高风险操作保留在 LLM 循环之外。使用一个独立的、受限的路径来授权重要操作。
分三个阶段构建你的治理体系：
- 发现阶段：使用审计模式策略。在不阻断任何操作的情况下，找出你的影子模型和血缘断裂点。
- 强制关卡：开启拒绝策略。将评估关卡接入你的 CI/CD 流水线，使不合规的模型在开发阶段就无法通过。
- 持续证据：使用不可变日志。用实时数据取代特定时间点的审批。
治理存在于你的代码中，而不是你的文件夹里。
Source: https://dev.to/az365ai/an-ai-governance-framework-on-microsoft-azure-that-actually-works-3773
Optional learning community: https://t.me/GyaanSetuAi