向人工智能厂商询问权限的八个问题

大多数人工智能评估都把时间花在了错误的风险上。演示被反复推敲，回答被逐条打分，有人会问起幻觉率——而真正决定这套软件能不能面向四百人（而不是四个人）开启的那件事，却始终没人提起。

那件事就是权限模型。它同时也是最扫兴的一个话题，正因如此，才值得在通话之前先把它写下来。

下面的内容与具体产品无关。无论是挂在你已有工具上的一个助手，还是一个声称处处都有人工智能的平台，或是介于两者之间的任何东西，它都同样适用。

为什么这才是决定能否全面推广的问题

一个能看到比使用者更多内容的人工智能功能，不是一项带着安全备注的功能。它是一次披着聊天界面外衣的数据访问权限变更。

这个模式反复出现：试点很顺利，因为试点小组是同一个部门里的十个人，他们本来就能看到彼此的数据。等推广铺到财务、人力，或者某个受监管的团队，就会有人问：这个助手到底能读到什么？如果答案是「索引里的一切」，项目就到此为止——而此时预算、集成和变革管理的投入都已经花掉了。

在第一次演示里问完这八个问题只需要二十分钟，却能告诉你那堵墙存不存在。

1. 人工智能用的是谁的权限？

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

你想听到的回答： 你的。人工智能以调用者本人的身份运行，受同一套角色与记录级权限约束，取不到任何你自己打不开的内容。

你常会得到的回答： 一个拥有宽泛读取权限的专用服务账号，外加一句「系统提示词会约束它」。那不是访问控制。它把授权这件事从角色模型里搬了出去——角色模型会被复核、被审计、在员工离职时被回收——搬进了提示词，而这些事在提示词里一件都不会发生。

2. 当它被问到权限范围之外的东西时会怎样？

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

你想听到的回答： 和应用本身的做法完全一致——请求被拒绝，走的是同一条代码路径，而且这个拒绝与「该记录不存在」无法区分。

注意听： 「它会告诉你它帮不了这个忙。」模型婉拒是一种行为，系统拒绝才是一道控制措施。如果强制约束落在模型的判断上而不是落在查询里，那么换个说法提问就是一次绕过。

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

这是最容易被漏掉的一个问题，也是引发过最多「无声事故」的一个。

该问： 当人工智能在我们的内容中做检索时，这个索引是按我的权限建的，还是按高权限建的——以及，某份文档的权限发生变更后，索引什么时候才会知道？

你想听到的回答： 检索在查询时按提问者本人的权限过滤，权限变更会及时同步。

为什么重要： 一个由高权限爬虫一次性建好的索引，就是一份永久的、可被搜索的全量副本，而它背后还接着一个极其擅长归纳总结的自然语言界面。你上个月刚刚收回访问权限的那份文档，依然可以被准确地、用一整段话描述给一个本来无权打开它的人——而文件本身不会留下任何访问日志记录。

4. 人工智能能否扩大自己的权限？

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

你想听到的回答： 要么它做不到，要么这类操作属于单独治理的一类动作，必须经过明确审批。

为什么： 一个既能代表你行事、又能授予权限的智能体，实际上拥有的是「多绕一步」的无边界权限。即使答案显然是「不能」，这个问题也值得问，因为对方的回答会告诉你：他们究竟有没有对动作分级这件事想过哪怕一次。

5. 日志里写了它做过什么？

该问： 在助手做完某个动作之后，立刻把审计轨迹拿给我看。

你想听到的回答： 人工智能的动作与人类动作出现在同一份日志中，同时标识出人工智能本身和它所代表的那个人，并带有变更前后的对比。

破绽： 一个单独的「人工智能活动」页面。两份日志意味着，要还原一条记录到底经历了什么，就必须靠时间戳把它们对齐——而这恰恰是你将来要在压力之下、在最紧要的那一天去做的还原工作。

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

该问： 谁来决定是否启用它，可以精细到什么粒度，以及能否只对某一个团队关闭而不必对所有人关闭？

你想听到的回答： 由管理员控制，可按角色或按用户组设置，而且关闭开关和开启开关一样容易。

这个问题决定了法务、临床或薪酬团队能否被单独划出来——也决定了出事的时候你能不能自己关掉它，而不用先提一张工单。

7. 有什么东西离开了公司？

该问： 有哪些供应商会处理我们的内容，这些内容是否用于训练，以及处理发生在哪个地区？

你想听到的回答： 一份可以直接摆到你们合规同事面前的具名次级处理方清单、一条写进合同的「不用于训练」承诺，以及一个关于处理地区的明确答复。

「我们用的是一家领先的人工智能供应商」不是回答。如果厂商说不出它的名字，那么等它换掉供应商时，厂商同样不会告诉你。

8. 有人离职时会发生什么？

该问： 当我注销一个用户时，助手曾代表他掌握的东西会怎么处理——保存的会话、生成的摘要、以及任何缓存下来的内容？

你想听到的回答： 与他的其他数据遵循同一套生命周期、同一套留存策略，由同一套流程删除。

为什么把它放在最后问： 这是最可能换来一阵停顿的问题，而那阵停顿本身就是答案。离职注销正是一个外挂式功能露馅的地方——它有自己的一套存储，而没有人把它梳理进图。

一段话版本

如果你只想在招标文件里放一段话：

请说明人工智能功能的访问权限如何由发起请求的用户权限推导得出，包括检索与搜索场景。请说明是否存在以高权限或服务账号身份运行的组件，若有，其约束条件是什么。请确认人工智能的动作与用户动作记录在同一份审计轨迹中。请列出所有会接触到客户内容的次级处理方，并确认这些内容不会用于模型训练。

四句话。能把这四句写成书面答复的厂商，说明他们认真想过；写不出来的厂商说明没有——而试点期就是你发现这一点的地方。

有力的回答整体上是什么样

这八个问题，你要听的其实是同一个属性：人工智能是一个调用者，不是一个例外。 它使用同一套权限模型，写入同一份日志，受同一套管理控制约束，并适用与人相同的留存规则。

每一个无力的回答，都是同一件事的不同变体——第二条路径，带着自己的账号、自己的存储、自己的日志或自己的规则。第二条路径未必天生就是错的，但每多一条，就多一样要复核的东西、多一样要在离职时清理的东西，也多一样终将被遗忘的东西。数一数有几条，是判断这套系统日后要花多少力气维护的一个不错的近似指标。

常见问题

这只和受监管行业有关吗？

不是。受监管行业的采购方最早问出这些问题，但那个失败模式——助手为提问者总结了一份他打不开的文档——在一家四十人的公司里同样尴尬，只不过那份文档更可能是某人的工资单，而不是一份病历。

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

它回答了八个问题中的一个，而且不是决定能否全面推广的那一个。留存说的是数据被发送出去之后会怎样，权限说的是一开始有哪些数据会被发送出去。

如果这个人工智能目前是只读的呢？

照样要问，并且要问路线图怎么写。对大多数人工智能功能来说，只读都是暂时属性，而权限架构远在写入路径加上去之前就已经定了——通常是由某个赶时间的人定的。

如果只能问一个问题，你会问哪个？

第 3 个。检索权限出错的概率最高，被问到的概率最低，事后补救的难度也最大——因为修好它意味着重建索引，而不是改一个设置项。

---

如果你希望成为最早使用 Cyril 的用户，加入等候名单。