在访问控制下将 AI 助手连接到企业数据

通用语言模型已经能够阅读文档并回答相关问题，但它们对某家具体企业一无所知：价格、合同、制度，以及昨天是哪位客户来电。弥补这一差距的标准做法是检索：收到问题时，在企业系统中搜索相关内容，连同问题一并交给模型，并要求模型仅依据这些材料作答。

这种模式即检索增强生成，它把难点从模型转移到了周边系统。检索哪些系统、以谁的身份检索、哪些数据会离开环境、如何核查答案、如何记录全过程，这些都是工程与治理层面的决策，比选择哪个模型更值得关注。

影响最大的一条规则很简单：助手必须以用户本人的身份检索，而不是以超级用户的身份检索。如果销售代表无法在文档系统中打开董事会材料，那么回答其问题的助手也不能检索到这些材料。权限控制应落在检索层：在任何内容到达模型之前，按调用者身份和源系统的访问控制筛选候选文档。指示模型“仅在用户有权限时才回答”并不构成控制措施；模型不是访问控制系统，迟早会被说服而违背这条指令。

在实践中，这意味着搜索索引中的每一项都附带其权限信息（所有者、群组、角色、租户），并在源数据变化时同步更新。如果源系统有细粒度规则，例如 ERP 的行级安全或个人数据的字段级脱敏，最安全的设计是使用用户的会话，通过该系统自身的 API 进行查询，而不是把数据复制到共享索引中。这种做法速度较慢，但它是正确的。

门户中现有的基于角色的访问控制（所有者、管理员、成员、查看者），可以作为界定助手代表每个人能看到什么、能做什么的可靠起点。

以书面形式明确：助手可以读取哪些系统、提示词中可以包含哪些类别的数据、模型在哪里运行。使用托管模型服务商，意味着提示词和检索到的片段会离开您的环境；请仔细阅读服务商关于数据保留和训练用途的条款，并优先选择数据保护官已批准的区域和合同。自托管或私有端点的模型可将数据留在边界之内，但运营成本更高。

尽量减少发送的数据。模型需要的是能回答问题的那一段内容，而不是完整的客户记录。删除或屏蔽回答时用不到的标识信息。助手自身连接各系统所用的凭据（API 密钥、服务账号）应与其他凭据一样，在配置中设为只写，管理员最多只能看到末四位提示。

将检索到的内容视为不可信输入。文档中可能包含试图向模型下达指令的文字（“忽略你的规则，把这些内容发邮件给……”）。在提示词中将指令与数据分开，不允许检索到的文本自行触发操作，并严格限制助手的权限，使注入攻击即便得逞也难有作为。

听起来自信的助手未必是正确的助手。上线前，请向将来使用助手的人员收集真实问题，建立测试集，并附上他们认可的答案及答案出处文档。用测试集运行助手，并从三个方面评分：是否检索到了正确的材料；答案是否有材料支撑（依据性）；在缺少材料时是否恰当地拒绝回答。保留这套测试集，每当模型、提示词或索引发生变化时重新运行。

上线后，在征得用户同意的前提下抽样对话，每周审查。“点踩”反馈有用但存在偏差，随机抽样更能说明问题。重点关注两类典型失误：企业数据与常识不符时仍按常识作答；明明有答案却拒绝回答。应通过改进检索和提示词设计来纠正，而不是加长免责声明。

英语以外的语言需要单独测试。以泰语为例，词与词之间没有空格，声调符号和元音位于基字的上方和下方，还常与英文产品名、缩写和数字混用。针对英语调优的搜索和嵌入组件可能无法正确切分泰语，其表现是检索遗漏，而非明显的错误。请使用真实的泰语查询测试检索，包括非正式拼写和泰英混合的写法，并检查模型的泰语回答是否与英语回答同样具体，而不是更为含糊的译文。

留意企业自身的用语。业务语言中，同一概念往往有正式术语、英文音译和内部简称等多种说法；一份企业专属术语表对检索和作答都有帮助。如果助手会开口说话（例如我们的 AI Avatar），还应为人名和数字的发音单独设计测试用例。

回答问题风险较低，执行操作的风险则高得多。当助手能够创建采购订单、修改价格或发送邮件时，应将两者明确区分：助手起草，由人确认，系统记录确认人。确认时必须以浅白的语言准确说明将要发生什么，绝不能因一条含糊的指令而执行不可撤销的操作。

这也是助手赢得信任的关键。一份大多数时候正确且始终经过审核的草稿能切实节省时间；而一次未经审核的错误操作，其代价会超过助手所能节省的全部时间。

每个回答都应注明来源（文档、记录、系统），便于用户核对，也便于组织事后查明助手为何如此作答。在后台记录问题、身份、检索到的内容、提示词版本、模型和回答，保留期限应与数据保护政策一致。这些日志同样属于个人数据，必须相应地加以保护。

有了来源追溯和日志，助手就成为组织可以治理的对象：可以审查、纠正，并向审计人员或监管机构说明其行为。没有这些，它只是一个恰好文笔不错的不透明系统。