- 发布于
- 阅读时长
- 8 分钟
关于权限,该向 AI 厂商问些什么
风险不在 AI 演示本身,而在演示之下的权限模型,它决定了这项功能能否走出试点小组。八个与具体产品无关的问题,每个都附上您希望听到的回答。
本页内容
大多数 AI 评估都把时间花在了错误的风险上。演示被反复审视,回答被逐一打分,有人问到幻觉率——而真正决定这款软件能否为四百人而不只是四个人开启的那件事,却从来没人提起。
那件事就是权限模型。它也是最没意思的一个问题,正因如此,才值得在通话之前先写下来。
以下内容与具体产品无关。它既适用于外挂在您现有工具上的助手,也适用于宣称全面内建 AI 的平台,以及介于两者之间的任何东西。
为什么这个问题决定了能否全面推广
一项能看到比其用户更多内容的 AI 功能,不是一项附带安全说明的功能,而是一次披着聊天界面外衣的数据访问变更。
这种模式一再重演:试点很顺利,因为试点小组是同一个部门的十个人,他们本来就能看到彼此的数据。然后推广到了财务、人力资源或某个受监管的团队,有人问起助手能读取什么。如果答案是“索引里的一切”,项目就到此为止——而预算、集成和变革管理的投入早已花了出去。
在第一次演示时就问这八个问题,只需二十分钟,就能知道这堵墙是否存在。
1. AI 用的是谁的权限?
问: 助手读取一条记录时,用的是谁的访问权限——我的,还是它自己的?
您希望听到的回答: 您的。AI 以调用者的身份运行,遵循同样的角色和记录级规则,检索不到任何您自己打不开的东西。
您常常会听到的回答: 一个拥有广泛读取权限的专用服务账号,外加一句“系统提示词会约束它”的保证。那不是访问控制。它把权限问题从角色模型中挪了出去——角色模型会被审查、审计,会随人员离职而回收——挪进了一段提示词,而在那里这些都不会发生。
2. 被要求做超出范围的事时会怎样?
问: 当我向助手询问一条我无权查看的记录时,它会怎么做?
您希望听到的回答: 与应用本身的做法一样——被拒绝,走的是同一条代码路径,而且拒绝的表现与这条记录不存在毫无二致。
要留意的说法: “它会告诉您它帮不上这个忙。”模型婉拒是一种行为,系统拒绝才是一种管控。如果管控依赖的是模型的判断,而不是查询本身,那么换一种问法就能绕过去。
3. 检索的权限从哪里来?
这是最容易被忽略的一个问题,也是引发最多无声事故的一个问题。
问: AI 在我们的内容中搜索时,索引是用我的权限建的,还是用更高的权限建的?当某份文档的权限发生变化时,索引什么时候才会知道?
您希望听到的回答: 检索在查询时按提问者的权限过滤,权限变更会及时同步。
为什么重要: 一个由高权限爬虫一次性建好的索引,就是一份永久的、可搜索的全量副本,摆在一个非常擅长总结的自然语言界面后面。您上个月收回权限的那份文档,依然可以被准确地、用一段话描述给一个从未被允许打开它的人——而该文件本身的访问日志里不会留下任何记录。
4. AI 能扩大自己的访问权限吗?
问: 助手能否执行改变权限的操作——把某人加入用户组、共享一份文档、更改一个角色?
您希望听到的回答: 要么不能,要么这类操作属于单独管控的一类,需要明确的审批。
原因: 一个既能代表您行事、又能授予访问权限的智能体,实际上只隔一步就拥有了无限的访问权限。即使答案显然是否定的,也值得一问,因为回答会告诉您,是否有人认真考虑过操作的分类。
5. 日志里记录了它做了什么?
问: 请在助手执行完某个操作后,立刻给我看审计记录。
您希望听到的回答: AI 的操作与人工操作记在同一份日志中,同时标明 AI 及其所代表的人,并附有操作前后的状态。
破绽: 一个单独的“AI 活动”页面。两份日志意味着,要还原一条记录发生了什么,就得按时间戳把它们对照起来——而这正是您在最关键的那一天、在压力之下不得不做的还原工作。
6. 谁能开启它,为谁开启?
问: 由谁控制是否启用,控制粒度有多细?能否只为某个团队关闭,而不必为所有人关闭?
您希望听到的回答: 由管理员按角色或按用户组控制,关闭和开启一样容易。
正是这个问题,决定了法务、医疗或薪资团队能否被单独排除在外——也决定了发生事故时,您能否不提工单就直接关掉它。
7. 什么会离开公司?
问: 哪些服务商会处理我们的内容?内容是否会被用于训练?在哪里处理?
您希望听到的回答: 一份具名的次级处理方列表,可以直接交给您自己的合规人员;在合同中明确不用于训练;以及关于处理区域的直接回答。
“我们使用的是一家领先的 AI 服务商”不算回答。如果厂商说不出它的名字,也就无法告诉您它何时更换。
8. 有人离职时会怎样?
问: 当我为某个用户办理离职时,助手代表他所掌握的东西——保存的对话、生成的摘要、任何缓存——会怎样?
您希望听到的回答: 与他的其他数据走相同的生命周期,遵循相同的保留策略,由相同的流程删除。
为什么放在最后问: 这是最可能让对方停顿一下的问题,而这一停顿本身就是信息。离职交接,正是外挂功能暴露出它有一个没人梳理过的独立存储的地方。
简短版本
如果您只想在招标文件里写一段话:
请说明 AI 功能的访问权限如何从请求用户的权限中派生,包括检索和搜索。请说明是否有任何组件以高权限或服务账号权限运行;如有,请说明以何种方式加以约束。请确认 AI 的操作与用户操作记录在同一份审计记录中。请列出所有接收客户内容的次级处理方,并确认客户内容不会被用于模型训练。
四句话。能以书面形式回答的厂商,是认真考虑过这个问题的;回答不了的厂商,就是没有考虑过,而您会在试点时发现这一点。
好的回答,整体听起来是什么样
在这八个问题中,您要听的都是同一个特性:AI 是一个调用方,而不是一个例外。 它使用同一套权限模型,写入同一份日志,受同样的管理员控制约束,并与人一样遵循同样的保留规则。
每一个薄弱的回答,都是同一件事的变体——另一条路径,有自己的账号、自己的存储、自己的日志或自己的规则。另一条路径并不一定是错的,但每一条都需要审查、需要在离职时回收,也都会被遗忘。数一数有几条,就能大致判断日后维护它要花多少功夫。
常见问题
这只与受监管行业有关吗?
不是。受监管行业的买家最早问这些问题,但失败的方式——助手总结了一份提问者打不开的文档——在一家 40 人的公司里同样尴尬,而在那里,那份文档更可能是某人的薪资,而不是病历。
厂商说模型不会保留我们的数据,这够了吗?
它回答了八个问题中的一个,而且不是决定能否推广的那一个。保留关心的是数据发送之后会怎样,权限关心的是一开始会发送什么。
如果 AI 目前是只读的呢?
还是要问,并且问问路线图上怎么写。只读是大多数 AI 功能的暂时属性,而权限架构早在写入路径加进来之前就已经定型了——通常是由当时赶时间的那个人决定的。
如果只能问一个问题,该问哪个?
第三个。检索权限是最常出错、最少被问到、也最难事后补救的,因为修正它意味着重建索引,而不只是改一项设置。
