微软把AI变成执行层？信任边界才是命门

你有没有想过，为什么同一个Copilot，在不同同事手里表现完全不同？有人能让它直接改文档，有人连看权限都没有。这不是bug，是微软故意设计的。

最近看到Aakash Rahsi提出的RAHSI框架，把这件事说透了——Copilot正在从"聊天工具"变成企业的"执行层"。但执行的不是AI，是AI背后那套复杂的信任边界。

一张图看懂：执行层到底在哪

RAHSI框架的核心，是把Copilot的定位从"生产力助手"往下挖了一层。

传统认知里，企业工具帮你找信息。搜索、分类、归档，都是信息层的事。但Copilot现在能干的事变了：总结、推理、转换、推荐、触发、支持运营动作——这些全属于执行层。

执行层和信息层的区别在哪？

信息层问的是"这东西在哪"。执行层问的是"这东西我能动吗"。

Rahsi画了条清晰的线：执行不是AI能生成什么，而是AI被允许看见什么、推理什么、转换什么、在什么上下文里行动。这条线就是信任边界。

信任边界由什么构成？原文列了七层：

提示词（Prompts）、权限（Permissions）、工作流（Workflows）、敏感度标签（Sensitivity Labels）、Microsoft Purview、Microsoft Entra ID、执行上下文（Execution Context）。

这七层不是并列关系，是层层嵌套的过滤网。用户说一句"把Q3报告发给市场部"，Copilot要过七关：你是谁（Entra ID身份）、你能看哪些文件（权限）、这文件有没有机密标签（Purview敏感度标签）、市场部的人在哪个工作流里、当前会话上下文允不允许这个动作……

任何一层卡住，执行就中断。表现给用户的就是"Copilot有时候好用有时候不好用"。

为什么"表现不一致"是设计，不是缺陷

很多企业IT抱怨Copilot"不稳定"。同一个指令，A同事能执行，B同事被拒绝。Rahsi的观点很直接：这不是噪音，是设计好的行为。

系统在实时响应身份、权限、策略、标签、上下文。不同用户看到的Copilot，本质上是不同的执行实例。

举个例子：两份内容相同的文档，一份贴了"机密-高管可见"标签，一份没标签。Copilot对前者的总结能力、引用能力、转发能力都会被压缩。这不是AI变笨了，是Purview的标签策略在起作用。

再比如跨租户场景。总部Copilot能调用的数据，子公司实例完全看不到。Entra ID的边界把执行能力物理隔开了。

这种设计的好处和麻烦都很明显。好处是安全合规内嵌，不用额外套壳。麻烦是用户学习成本极高——他们得理解自己"被允许"的边界在哪，而不是抱怨AI"不听话"。

信任边界的六个控制点

Rahsi把信任边界拆解成六个可操作维度，每个维度都直接决定Copilot能干什么：

第一，能看见什么（Access）。这是最基础的。没有读取权限的数据，Copilot连存在都不知道。不是"假装看不见"，是索引层就被过滤掉。

第二，能总结什么（Summarize）。有读取权不代表能自由总结。敏感度标签可以限制"允许AI生成摘要"的范围。某些高密级内容，人工可以看，但Copilot不能提炼。

第三，能推理什么（Reason）。推理需要跨文档关联。如果关联文档分散在不同权限区，Copilot的推理链条会被切断。表现出来的就是"答非所问"或"遗漏关键信息"。

第四，能转换什么（Transform）。格式转换、语言翻译、代码改写，这些动作需要写权限或衍生权限。标签策略可以禁止AI对特定内容做任何转换，即使人工有编辑权。

第五，能推荐什么（Recommend）。推荐基于模式识别，需要访问足够大的行为数据集。如果用户的历史操作被Purview标记为敏感，Copilot的推荐质量会断崖下跌。

第六，能支持什么运营动作（Operational Support）。这是执行层的顶端。触发工作流、自动填表、跨系统同步，每一步都要过工作流引擎的权限校验。Copilot在这里只是个自然语言入口，真正的闸门在Power Automate和Azure Logic Apps里。

六个维度层层递进，构成完整的信任边界模型。企业AI架构的核心问题，不是"Copilot能做什么"，而是"在这个具体边界内，Copilot被允许推进到哪一层"。

从"纠正微软"到"理解微软"

原文有个很关键的立场声明："This is not about correcting Microsoft. This is about understanding Microsoft's design philosophy."

这不是客套。很多企业的AI治理思路是反的：先让Copilot跑起来，发现越权了再打补丁。Rahsi认为这条路走不通。

微软的设计哲学是前置治理。权限、标签、策略在数据产生时就贴上，AI的执行能力自然被约束。不是"先开放再收紧"，是"默认收紧，按需开放"。

这解释了为什么Copilot的部署比预期慢。不是技术问题，是治理基础设施没跟上。没有Purview的标签体系，没有Entra ID的精细权限，没有工作流的编排能力，Copilot就是个被封印的聊天机器人。

Rahsi的RAHSI框架本质上是个诊断工具。企业可以对照六个控制点，逐层检查自己的治理成熟度。缺哪层，执行能力就卡在哪层。

执行层的真正战场：人机意图的翻译

信任边界最微妙的地方，在于它处理的是"人类意图"到"机器动作"的转换。

用户说"帮我准备下周的董事会材料"，这是个模糊意图。Copilot要拆解成：调取哪些文件（Access）、生成什么格式的摘要（Summarize）、要不要做财务预测（Reason）、图表需不需要重新设计（Transform）、有没有历史模板可参考（Recommend）、最终输出到哪里（Operational Support）。

每一步都涉及信任边界的校验。不是AI理解不了意图，是意图的每个分解动作都要过权限闸。

这就产生了一个反直觉现象：Copilot在治理成熟的企业里表现更好，不是因为AI更强，是因为边界清晰，AI知道什么能碰、什么不能碰。治理混乱的企业，AI反而束手束脚，到处触发未知限制。

Rahsi把这种现象称为"执行上下文的质量决定AI输出质量"。上下文不是技术参数，是组织治理状态的镜像。

给企业IT的实操建议

基于RAHSI框架，原文隐含了三条行动线，但没有明说。我根据框架结构整理出来：

第一，把敏感度标签当成执行开关，不是装饰。Purview的标签直接决定Copilot能处理到哪一层。标签策略越细，AI的执行粒度越可控。

第二，把Entra ID的权限设计从"人能看什么"升级到"AI能推什么"。身份治理要覆盖服务主体、托管标识、AI代理的执行上下文。

第三，把工作流编排纳入AI治理。Power Automate的流程不是自动化的终点，是Copilot执行能力的边界定义。流程卡在哪，AI就停在哪。

这三条线没有捷径，都是基础设施工程。Rahsi的13年IT自动化经验也体现在这里——他清楚知道企业级部署的阻力在哪。

冷幽默

所以下次你的Copilot又"听不懂"了，别急着骂它。它可能正在七层信任边界里疯狂试探，然后发现你根本没给它开那扇门的钥匙。

最讽刺的是：你以为是AI变聪明了，其实是你的IT部门终于把权限理清楚了。Copilot还是那个Copilot，只是它终于知道，哪些话可以说，哪些话必须假装没听见。