Copilot Control vs. SharePoint Control | 谁真正拥有文档状态？
I’m happy to translate the article for you, but I’ll need the text of the article itself. Could you please paste the content you’d like translated? Once I have that, I’ll provide the Simplified Chinese translation while keeping the source link and formatting unchanged.
如果 Copilot “读取所有内容”，而 Azure AI “只进行索引”…
…那为什么你们上一次的事件回顾仍然依赖截图和猜测？
我曾在租户内部坐镇，看到 Copilot 在演示中光彩夺目，却在审计时令人惊恐。
模式总是一样的：
- 我们治理提示和角色
- 我们 几乎从不 治理这些答案所依赖的文档状态
本文是我对这一问题的静默修复尝试。
舒适的故事
“我们打开了 Microsoft 365 Copilot，接入 Azure AI，配置了一些 RAG 模式，现在 AI 可以安全地读取用户有权限访问的内容。”
实际上，底层发生的事情 远没有想象中神奇，如果忽视它，更是危险。
每一个 Copilot 或 Azure AI 的答案背后都有四个独立的控制平面：
| 层面 | 所有者 | 职责 |
|---|---|---|
| 执行 | SharePoint | 权限、标签、版本、链接、保留、记录 |
| 合规性 | Microsoft Search | 索引、受管属性、排名、安全裁剪 |
| 运行时 | Copilot + Azure AI | 检索、引用、摘要和朗读的内容 |
| 证明 | Purview + Sentinel | 查询‑答案血缘、CVE‑激增姿态、证据包 |
如果你不知道这四个平面如何相互作用，就说明你并未拥有自己的 文档状态。Copilot 只是在放大已有的漂移。
问问负责你们 Microsoft 365 租户的任何人：
“到底为什么这份文档在当时有资格成为那个 Copilot 答案的来源？”
如果要得到答案需要：
- 挖掘聊天记录，
- 滚动查看邮件线程，或
- 即兴编造一个 “我们认为……” 的叙述
…那么你 没有 控制你的文档状态。你正把 AI 运行在软沙上。
拥有文档状态
你可以 系统化 地回答这个问题：
- 是什么权限和标签姿态让该文件具备资格？
- 是什么搜索合规性和排名信号让它成为候选？
- 是哪层 Copilot 或 Azure AI 的检索面选中了它？
- 我们可以导出哪些 Purview / Sentinel 追踪作为证明？
本文余下部分是一张 控制平面地图，帮助你完成这段旅程。
1️⃣ SharePoint – 强制层
SharePoint 仍然是大多数企业内容的强制层，无论你的 Copilot 或 Azure AI 堆栈多么现代化。实际上它定义了：
- 身份和权限 – 站点、库、组、共享链接、外部访问
- 标签和保留 – 敏感度标签、保留标签、记录、保留锁定
- 版本血统 – 草稿与最终稿、主/次版本、签入/签出
- 链接边界 – “组织内人员”、 “特定人员”、 “拥有链接的任何人”
关键洞察
能够 在压力下拒绝、约束并保持状态 的层面拥有强制权。如果你的权限是 先设边界，标签是有意应用的，版本被精心管理，链接使用有纪律，那么 Copilot 和 Azure AI 就拥有一个坚实的强制框架可供依托。否则，每个 AI 的答案都在漂移中摇摆。
如果你看到以下情况，可能就存在强制问题：
- “组织内任何人”链接是你的默认协作模式
- 高风险库中混杂了已标记和未标记的项目
- 最终稿和草稿共享相同的范围，并在搜索中看起来完全相同
- 共享文件夹和文档集没有明确的所有者
在这种情况下，任何 AI 运行时（Copilot、Azure AI Search、定制 RAG）都被迫在关于真实状态的弱信号上即兴发挥。
2️⃣ Microsoft Search – 资格平面
在 Copilot “读取”任何内容之前，Microsoft Search 已经决定了：
- 内容是否已被索引
- 哪些字段是受管属性
- 它是如何排序的
- 它对谁进行安全裁剪
- 它在垂直领域和范围中的出现位置
资格是看不见的门
- 如果它不符合资格，就不能成为候选项。
- 如果它符合资格，AI 可能会意外地将其变成叙事。
你的资格平面包括：
| 方面 | 需要提出的问题 |
|---|---|
| 搜索架构 | 关键状态字段（所有者、生命周期、分类、系统、客户、CVE ID）是否已提升为受管属性？ |
| 垂直领域和结果来源 | 是否为权威内容与归档、实验室、导出和测试设立了专用通道？ |
| 新鲜度窗口 | 您是否了解关键更新在搜索中可见并在 AI 检索中出现需要多长时间？ |
当组织抱怨 Copilot “不一致”时，他们通常关注的是 资格漂移，而不是模型行为。
3️⃣ Copilot + Azure AI – 运行时平面
Copilot 和 Azure AI 不拥有存储；它们拥有 运行时的选择和表达：
- 检索哪些候选项
- 如何针对特定查询和用户对它们进行排序
- 哪些块被嵌入并用于 grounding（依据）
- 最终以何种文本形式返回
运行时控制是以下问题出现的地方：
- Prompt injection（提示注入）
- 过宽的 grounding 范围 泄露数据
- 当权威通道薄弱时出现 Hallucinations（幻觉）
如果你给 Copilot 或 Azure AI 一个租户范围内结构不佳的表面，你将得到租户范围内、难以解释的答案。
如果你进行围栏划分：
- Grounding 表面（站点、库、垂直领域、RAG 索引）
- 特定角色的范围（财务、法律、安全）
- 高风险领域（监管、CVE、董事会沟通）
…那么即使在压力之下，运行时也会变得可预测。
4️⃣ Purview + Sentinel – 证明层
最终的层面虽然不够炫目，却是最关键的。Microsoft Purview 和 Microsoft Sentinel 为您提供：
- 统一的审计日志和活动追踪
- 随时间变化的标签 / 保留状态
- 对可疑行为的警报和事件
- KQL 级别的可视化，了解发生了哪些查询和模式
这就是您的证明层
当法律、监管机构、客户或董事会询问：
“谁在何时何因看到什么？”
…答案就在这里。
如果您的 AI 部署 未 包含 证据包，即将以下内容组合在一起：
- 文档状态（标签、权限、版本、链接）
- 搜索合规状态（模式、垂直领域、范围）
- AI 运行时追踪（提示、引用、答案来源）
…那么您就是在靠记忆而非遥测来构建事故叙事。
常见的“AI 惊喜”模式
- 临时的组分配
- “暂时”破坏的继承权限
- 从旧模板克隆的项目站点
这些都是 被 AI 揭露的旧罪。
TL;DR
| 层面 | 所有者 | 您必须管理的内容 |
|---|---|---|
| Enforcement（执行） | SharePoint | 权限、标签、版本、链接、保留 |
| Eligibility（合规） | Microsoft Search | 索引、受管属性、排序、安全裁剪 |
| Runtime（运行时） | Copilot + Azure AI | 检索、落地、引用、答案生成 |
| Proof（证明） | Purview + Sentinel | 审计日志、血缘、警报、证据包 |
控制好每个层面，您就能阻止“漂移”演变为“危险”。
## Copilot 与 Azure AI 的文档状态治理
“当 AI 展示出没人记得授权的内容时，问题不在模型本身，而在未受管的状态。”
1️⃣ 未管理状态的症状
| 症状 | 结果 |
|---|---|
| 用户可以看到没有人记得授权的内容。 | 可发现性会在不知不觉中随时间扩大。 |
| 为了速度使用“拥有链接的任何人”。 | 搜索看到的更多；Copilot 与 Azure AI 看到的也更多。 |
| 旧的协作从未关闭。 | 草稿和最终稿混在同一范围内。 |
| 外部共享没有到期时间。 | 导出和截图被视为“暂时使用”。 |
| 为了便利保留旧门户在线。 | 除非另行编码，否则 AI 会将新内容排在权威内容之前。 |
| 同一逻辑包的成员使用不同标签。 | 相关文档的保留策略不一致。 |
| 未对继承漂移进行验证。 | AI 在冲突的策略之间进行汇总。 |
| 无法说明答案对应的是哪项政策。 | AI 看似“不可预测”，但实际上是状态未被管理。 |
底线： AI 正在实时暴露底层治理缺口。
2️⃣ 结构化方法
a. 从核心问题开始
“我们租户中谁拥有文档状态？”
b. 明确答案
| 方面 | 所有者 |
|---|---|
| 内容 | SharePoint 与相关工作负载 |
| 资格 | Microsoft Search 配置 |
| 运行时 | Copilot 与 Azure AI 基础表面 |
| 证据 | Purview、Sentinel 与贵公司的 SOC 流程 |
将其写成 Document‑State Charter。如果你在内部无法解释它，外部审查时就难以生存。
c. 将关键状态字段提升为受管属性
- 业务所有者 与 系统所有者
- 领域（财务、人力资源、安全、产品）
- 生命周期（草稿、审阅中、最终、已退役）
- 分类与敏感度
- 数据包 / 案例 ID（客户、事件、CVE、交易）
d. 围绕这些字段构建垂直领域和结果来源
- 像使用自己的 Copilot 一样测试 KQL 风格的查询。
- 如果在 Microsoft Search 中无法按状态过滤、细化和切片，那么在 AI 中更不可能实现。
Authority（权威） = 治理决策。
Ranking（排名） = 搜索引擎计算。
e. 架起权威与排名的桥梁
- 为最关键的领域指定 权威通道。
- 降级 复制区、导出和旧门户。
- 验证 高风险查询的前 N 条结果是否指向官方通道。
目标：
“当 Copilot 或 Azure AI 为该领域引用内容时，除非我们能证明例外，否则它始终落在官方通道。”
不需要完美——只需 可预测的失效模式。当引用错误时，你应在排名中看到 原因，而不是猜测。
3️⃣ 从“租户范围”转向 基于通道 的智能
| 领域 | 允许的来源 | 映射 |
|---|---|---|
| 财务 | 财务数据包通道 | 财务 Copilot 体验 |
| 安全 | 安全运行手册与证据通道 | 安全 Copilot 体验 |
| CVE / 事件 | 应急准备数据包通道 | CVE/事件助手 |
将任何“快速添加更多范围”的请求视为 风险讨论，而非便利点击。
4️⃣ 证据包 – 审计工件
针对每个高风险领域和 AI 场景，定义一个 Evidence Pack，其中结合：
- 某一时点的 文档状态。
- 当时的 搜索资格。
- AI 运行时行为（查询、提示、引用、输出）。
简单捕获模式（针对代表性时间窗口）
- 示例文档 + 标签 / 权限 / 版本。
- 搜索查询 + 将供 AI 使用的顶部结果。
- Copilot/Azure AI 提示 + 回答。
- 关键事件的 Purview 与 Sentinel 跟踪。
将这些与 CVE 运行手册和事件响应剧本一起存储。你正在构建 **可重放的
Source: …
Enabling a new grounding surface | “Find every customer potentially impacted by this CVE in the last 18 months.” | | After every major structural change | “Show me which users could see this document during this week.” | | During surge weeks & live incidents | “Explain why Copilot included this file in its answer to this person.” |
如果你的 AI 故事在这些测试面前崩溃，那它从未真正安全过。
6️⃣ 成功的样子
- Copilot 的回答 变得可重复，而不是像彩票一样随机。
- Azure AI Search 与 RAG 工作负载变得有纪律，而不是聪明的抓取。
- CVE 波动 成为检索问题，而不是恐慌问题。
- 董事会提问 变成可导出的叙事，而不是战争故事。
- 安全、合规和架构 最终用同一种语言谈论 AI。
你仍然会遇到事故和意外，但你会拥有 控制平面，而不是单一的纠结网络。
7️⃣ 为何这很重要
我们常讨论：
- Prompt engineering（提示工程）
- Retrieval‑augmented generation (RAG)（检索增强生成）
- “Responsible AI”（负责任的 AI）
却很少揭示保持 AI 诚实的底层治理层。通过掌握这四个控制平面，你可以把 “AI 意外” 转化为可管理、可审计的事件。