高敏感业务上AI，别只装模型：还要有一张“业务隔离卡”

一份合同、一段客户邮件、一次合规检索，表面上都是“让 AI 帮忙读一读”的小事；可一旦智能体能跨文件库找材料、调用专业系统、生成可交付的工作成果，真正决定它能否进生产环境的，就不再只是模型回答得是否漂亮。它能看到哪一个事项？引用了哪一版制度？这次判断能否被同事复核？答案若说不清，效率越高，风险反而越快被放大。

8月25日，Google Cloud 发布 Gemini Enterprise for Legal 预览版。这个面向法律服务与企业法务的产品，把领域技能、可信业务系统连接、可执行的智能体和开放生态放在同一套受治理的环境中。值得关注的并非“AI 进入法律行业”这句口号，而是它把高敏感工作流里原本容易被忽略的三件事放到了台面上：专业规则、既有权限和可验证依据，必须随着任务一起运行。

高敏感场景的关键，不是让智能体“懂得更多”，而是让每一份输出都能回答：基于什么资料、在什么权限内、由谁承担最终判断。

从“万能助手”到受约束的专业工作流

法律、财务、医疗、研发等场景有一个共同点：资料不是普通上下文，而是带着业务归属、保密等级、有效期限和责任边界的工作证据。用一个通用对话框把资料全塞进去，或让服务账号以高权限连接全部系统，短期看部署很快，长期却会制造新的“信息黑箱”。当同一智能体服务不同客户、项目或部门时，原本由人员、事项和系统共同维持的边界，很容易在一次跨系统调用中被抹平。

Google Cloud 在此次发布中强调，连接文档管理、案件资料、研究服务和行业应用的 MCP 连接器，应继承底层系统已有的用户权限与访问控制；其受治理控制面则用于实施安全策略、私有数据隔离，以及带可追溯引用的内容依据。换句话说，智能体不是再造一套“谁都能看”的知识库，而是在已有业务边界内完成检索、归纳和执行。

真正要沉淀的，是“业务隔离卡”

我认为，企业不必等到部署一套完整行业平台后才开始治理。更实际的起点，是为每一类高敏感智能体建立一张业务隔离卡：它不是一份笼统的安全制度，而是一组能被工作流读取、检查和复盘的业务事实。

第一栏写清任务边界：它服务哪个事项、客户、产品线或项目；允许处理哪些文件类型；哪些动作只能生成草稿，哪些动作必须由具备资格的人确认。第二栏写清资料边界：权威来源在哪里、文档版本如何识别、过期材料如何处理、跨项目检索是否默认禁止。第三栏写清权限接力：发起人是谁，智能体代谁访问，连接器在哪一层再次校验，拒绝访问后是提醒申请、转人工，还是直接终止任务。

最后一栏是证据与处置：输出中哪些结论必须附来源，哪些修改需要保留差异，人工采纳、驳回或纠正后如何回写。这样做的价值不在于多一张表，而在于让“边界”从口头要求变成可执行的输入。日后发生争议时，团队能回到具体的事项范围、权限记录、引用材料和人工决定，而不是在聊天记录里猜测模型为什么这样说。

三个先问的问题，决定能否从试用走向生产

准备上线高敏感智能体时，我建议业务负责人先不问“它能不能做得更快”，而是连续问三个问题。第一，它在替谁工作？如果回答只是“替法务部”或“替销售团队”，粒度还不够；应落实到事项、角色和当次委托。第二，它凭什么得出结论？关键输出应能回指到受许可的来源、版本和必要的引用，而不是只给一段流畅的摘要。第三，它越界时谁接手？对权限不足、资料冲突、高风险条款或事实不充分的情况，要预先定义暂停、升级和人工批准路径。

这三个问题同样适用于合同审阅、客户方案、产品安全评估和财务分析。模型可以替企业压缩检索与整理的时间，却不能替企业消除责任。越是专业、越是敏感的流程，越需要把“人、资料、权限、证据”四件事绑定在一次任务里，而不是在结果出现后再补救。

STARBOX视角：把隔离边界变成可复用的工作资产

在 STARBOX 看来，企业搭建专属 AI 工作站，不应只配置提示词和知识库。组织层需要明确业务委托、风险等级、审批责任和留存规则；BOX 层沉淀事项字典、权威资料、角色范围、连接器边界与引用模板；智能体层则只在本次卡片允许的资料和动作范围内执行。再将权限拒绝、人工改写、来源缺失和异常升级等反馈回流，隔离卡才会从静态清单成长为持续改进的工作资产。

高敏感业务不会因为接入 AI 而变得简单，但可以变得更清楚：哪些工作值得自动化，哪些边界不能被效率穿透，哪些结论必须留给人作最后确认。企业真正要建设的，也许不是一位无所不能的 AI 助手，而是一支始终知道自己该看什么、不能看什么、依据什么工作的智能体队伍。