AI 治理框架是非常好的读物。它们分配角色、列出原则并规划审查委员会。但一旦员工将客户反馈粘贴到公共聊天机器人中，或者当后端 API 在不经意间将个人身份信息转发给外部模型时，框架就失去了作用。治理的真正工作并不发生在委员会会议室里，而是发生在“访问路径”上。这正是人员、应用程序或 API 端点首次触及 AI 模型的那一点。如果你无法在那里执行规则，你就没有治理，你只有一份愿望清单。
框架与现实之间的差距
大多数组织在过去两年里都在建立 AI 委员会、起草可接受使用政策并开展员工培训。这些努力很重要，它们设定了预期。然而，它们无法预见在周二下午的代码编写环节中会发生什么——例如，为了节省时间，开发人员通过一个未经审查的浏览器扩展发送了专有源代码。框架存在于文档中，而工作存在于终端、浏览器和 API 调用中。
其结果是一个可以预见的盲点。领导层认为 AI 的使用是受控的，因为政策是这么规定的；而运营层面呈现出的却是另一番景象。这种脱节代价高昂。一个包含未脱敏健康记录或未发布财务数据的提示词（prompt）就可能引发合规违规、监管调查，或引发任何道歉巡演都无法挽回的公开事件。等待审计来发现滥用行为已经太晚了。真正的治理需要对交互过程本身具备可见性，而不仅仅是围绕它的文书工作。
“访问路径”究竟意味着什么
访问路径并非一个抽象概念。它是请求离开你的环境并前往 AI 模型的精确瞬间。该请求可能来自使用经批准的 Web 界面的营销经理，可能来自回答员工问题的 Slack 机器人，也可能来自调用 API 来总结支持工单的微服务。每条路径都带有其自身的风险，且每条路径都需要自己的防护机制。
如果在这个边缘没有控制点，你的组织就无法区分员工是在要求模型重写一封内部邮件，还是在上传一个填满了账号信息的电子表格。两者看起来都是流量。但只有其中一种应该被允许通过。在你掌控这一边界之前，每一个处于你直接控制之外的 AI 模型本质上都是一条黑暗的走廊，数据可以在其中悄无声息地流出。
架构必须回答的九个问题
在任何提示词到达模型之前，你的系统必须能够回答九个特定的问题。首先从身份和意图开始。谁发送了请求？业务用例是什么？哪个部门或系统拥有它？这三个问题确定了交互是否合法且可追溯。
接下来是数据和模型安全。哪些数据进入了提示词？哪个 AI 模型将对其进行处理？该特定模型是否已获准执行此特定任务？在数据离开你的环境之前，是否需要对敏感数据进行脱敏或拦截？
最后是运营问责制。你是否记录了访问