---
title: 关于权限，该向 AI 厂商问些什么
canonical: https://getcyril.com/zh/博客/人工智能权限该问什么/
published: 2026-08-31
author: Cyril team
language: zh-CN
---
# 关于权限，该向 AI 厂商问些什么

大多数 AI 评估都把时间花在了错误的风险上。演示被反复审视，回答被逐一打分，有人问到幻觉率——而真正决定这款软件能否为四百人而不只是四个人开启的那件事，却从来没人提起。

那件事就是权限模型。它也是最没意思的一个问题，正因如此，才值得在通话之前先写下来。

以下内容与具体产品无关。它既适用于外挂在您现有工具上的助手，也适用于宣称全面内建 AI 的平台，以及介于两者之间的任何东西。

## 为什么这个问题决定了能否全面推广

一项能看到比其用户更多内容的 AI 功能，不是一项附带安全说明的功能，而是一次披着聊天界面外衣的数据访问变更。

这种模式一再重演：试点很顺利，因为试点小组是同一个部门的十个人，他们本来就能看到彼此的数据。然后推广到了财务、人力资源或某个受监管的团队，有人问起助手能读取什么。如果答案是“索引里的一切”，项目就到此为止——而预算、集成和变革管理的投入早已花了出去。

在第一次演示时就问这八个问题，只需二十分钟，就能知道这堵墙是否存在。

## 1. AI 用的是谁的权限？

**问：** 助手读取一条记录时，用的是谁的访问权限——我的，还是它自己的？

**您希望听到的回答：** 您的。AI 以调用者的身份运行，遵循同样的角色和记录级规则，检索不到任何您自己打不开的东西。

**您常常会听到的回答：** 一个拥有广泛读取权限的专用服务账号，外加一句“系统提示词会约束它”的保证。那不是访问控制。它把权限问题从角色模型中挪了出去——角色模型会被审查、审计，会随人员离职而回收——挪进了一段提示词，而在那里这些都不会发生。

## 2. 被要求做超出范围的事时会怎样？

**问：** 当我向助手询问一条我无权查看的记录时，它会怎么做？

**您希望听到的回答：** 与应用本身的做法一样——被拒绝，走的是同一条代码路径，而且拒绝的表现与这条记录不存在毫无二致。

**要留意的说法：** “它会告诉您它帮不上这个忙。”模型婉拒是一种行为，系统拒绝才是一种管控。如果管控依赖的是模型的判断，而不是查询本身，那么换一种问法就能绕过去。

## 3. 检索的权限从哪里来？

这是最容易被忽略的一个问题，也是引发最多无声事故的一个问题。

**问：** AI 在我们的内容中搜索时，索引是用我的权限建的，还是用更高的权限建的？当某份文档的权限发生变化时，索引什么时候才会知道？

**您希望听到的回答：** 检索在查询时按提问者的权限过滤，权限变更会及时同步。

**为什么重要：** 一个由高权限爬虫一次性建好的索引，就是一份永久的、可搜索的全量副本，摆在一个非常擅长总结的自然语言界面后面。您上个月收回权限的那份文档，依然可以被准确地、用一段话描述给一个从未被允许打开它的人——而该文件本身的访问日志里不会留下任何记录。

## 4. AI 能扩大自己的访问权限吗？

**问：** 助手能否执行改变权限的操作——把某人加入用户组、共享一份文档、更改一个角色？

**您希望听到的回答：** 要么不能，要么这类操作属于单独管控的一类，需要明确的审批。

**原因：** 一个既能代表您行事、又能授予访问权限的智能体，实际上只隔一步就拥有了无限的访问权限。即使答案显然是否定的，也值得一问，因为回答会告诉您，是否有人认真考虑过操作的分类。

## 5. 日志里记录了它做了什么？

**问：** 请在助手执行完某个操作后，立刻给我看审计记录。

**您希望听到的回答：** AI 的操作与人工操作记在同一份日志中，同时标明 AI 及其所代表的人，并附有操作前后的状态。

**破绽：** 一个单独的“AI 活动”页面。两份日志意味着，要还原一条记录发生了什么，就得按时间戳把它们对照起来——而这正是您在最关键的那一天、在压力之下不得不做的还原工作。

## 6. 谁能开启它，为谁开启？

**问：** 由谁控制是否启用，控制粒度有多细？能否只为某个团队关闭，而不必为所有人关闭？

**您希望听到的回答：** 由管理员按角色或按用户组控制，关闭和开启一样容易。

正是这个问题，决定了法务、医疗或薪资团队能否被单独排除在外——也决定了发生事故时，您能否不提工单就直接关掉它。

## 7. 什么会离开公司？

**问：** 哪些服务商会处理我们的内容？内容是否会被用于训练？在哪里处理？

**您希望听到的回答：** 一份具名的次级处理方列表，可以直接交给您自己的合规人员；在合同中明确不用于训练；以及关于处理区域的直接回答。

“我们使用的是一家领先的 AI 服务商”不算回答。如果厂商说不出它的名字，也就无法告诉您它何时更换。

## 8. 有人离职时会怎样？

**问：** 当我为某个用户办理离职时，助手代表他所掌握的东西——保存的对话、生成的摘要、任何缓存——会怎样？

**您希望听到的回答：** 与他的其他数据走相同的生命周期，遵循相同的保留策略，由相同的流程删除。

**为什么放在最后问：** 这是最可能让对方停顿一下的问题，而这一停顿本身就是信息。离职交接，正是外挂功能暴露出它有一个没人梳理过的独立存储的地方。

## 简短版本

如果您只想在招标文件里写一段话：

> 请说明 AI 功能的访问权限如何从请求用户的权限中派生，包括检索和搜索。请说明是否有任何组件以高权限或服务账号权限运行；如有，请说明以何种方式加以约束。请确认 AI 的操作与用户操作记录在同一份审计记录中。请列出所有接收客户内容的次级处理方，并确认客户内容不会被用于模型训练。

四句话。能以书面形式回答的厂商，是认真考虑过这个问题的；回答不了的厂商，就是没有考虑过，而您会在试点时发现这一点。

## 好的回答，整体听起来是什么样

在这八个问题中，您要听的都是同一个特性：**AI 是一个调用方，而不是一个例外。** 它使用[同一套权限模型](/trust/)，写入同一份日志，受同样的管理员控制约束，并与人一样遵循同样的保留规则。

每一个薄弱的回答，都是同一件事的变体——另一条路径，有自己的账号、自己的存储、自己的日志或自己的规则。另一条路径并不一定是错的，但每一条都需要审查、需要在离职时回收，也都会被遗忘。数一数有几条，就能大致判断日后维护它要花多少功夫。

## 常见问题

### 这只与受监管行业有关吗？

不是。受监管行业的买家最早问这些问题，但失败的方式——助手总结了一份提问者打不开的文档——在一家 40 人的公司里同样尴尬，而在那里，那份文档更可能是某人的薪资，而不是病历。

### 厂商说模型不会保留我们的数据，这够了吗？

它回答了八个问题中的一个，而且不是决定能否推广的那一个。保留关心的是数据发送之后会怎样，权限关心的是一开始会发送什么。

### 如果 AI 目前是只读的呢？

还是要问，并且问问路线图上怎么写。只读是大多数 AI 功能的暂时属性，而权限架构早在写入路径加进来之前就已经定型了——通常是由当时赶时间的那个人决定的。

### 如果只能问一个问题，该问哪个？

第三个。检索权限是最常出错、最少被问到、也最难事后补救的，因为修正它意味着重建索引，而不只是改一项设置。

---

如果您想成为首批使用 Cyril 的人，欢迎[加入等候名单](/waitlist/)。