没有读正文，AI 为什么也可能泄露文件信息
某员工问 AI“公司最近有哪些收购项目”，系统没有返回任何文档正文，却列出了一个受限文件夹的名称和三份文件标题。如果标题已经包含交易对象与谈判阶段，信息边界仍然被突破了。检查 AI 文档权限时，只验证正文是否可读，会遗漏标题、路径、作者和更新记录等元数据。
哪些元数据本身有业务价值
文件名可能包含客户、人员与项目代号；目录层级可能透露组织结构；创建和修改时间可能暗示业务进展；结果数量也可能暴露某类资料是否存在。这些信息不一定都需要同样严格的控制，但应由资料所有者判断敏感程度，不能因为它们不是正文就自动视为公开信息。
OWASP 授权指南强调对资源访问逐次校验，日志指南也提醒文件路径与标识可能需要特殊处理。这两条原则放到 AI 界面，意味着搜索建议、引用卡片、错误提示和后台日志都应进入权限检查范围。系统不能先把全部标题交给模型，再希望模型自觉隐藏员工不应知道的部分。
| 界面位置 | 容易遗漏的信息 | 建议测试 |
|---|---|---|
| 搜索候选 | 文件标题与数量 | 无权用户是否能看到候选 |
| 引用卡片 | 目录、作者与摘要 | 删除权限后卡片是否仍暴露内容 |
| 拒绝提示 | 受限项目是否存在 | 提示是否给出过多业务线索 |
| 管理日志 | 敏感文件名与路径 | 运维人员是否超出必要可见范围 |
用虚构标记检查整条展示链
可以创建两份测试文件：正文是普通示例文字，但一份标题含独特的虚构项目名，另一份目录含虚构客户名。只给测试账号访问第一份，然后从搜索、聊天、引用、历史会话和导出入口观察第二份的信息是否出现。这样能够区分正文控制与元数据控制，测试过程中也不需要使用真实秘密。
如果发现泄露，应回到产生信息的位置修复。例如，候选列表在权限过滤前已经返回浏览器，就应调整候选服务；日志把完整路径写入公共看板，就应缩小日志字段及查看权限。仅在最终回答中删除某个词，通常无法覆盖其他入口，也不利于长期维护。
元数据可见性也要分层
有些企业允许员工知道某个公共制度存在，只是附件需要申请；另一些项目连存在性都需要限制。两种场景可以采用不同提示，但必须有明确规则。不要把所有拒绝都写成“文件不存在”，也不要把所有受限标题直接展示出来。应依据资源类别，确定是否允许披露存在性以及怎样申请访问。
验收表中可以增加“正文、元数据、历史结果、错误提示”四列，为每类用户逐项填写结果。对于无法验证的路径标为待测。这样团队讨论的就不再是笼统的“AI 有权限控制”，而是哪些信息在什么位置受到怎样的约束。本文方法用于设计检查，不代表任一产品已经具备全部控制能力。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。