定制智能体如何实现企业内部数据的安全调用与集成

发布于 2026-11-06 · 杭州师范大学阿里巴巴商学院AI商科智能体实验室

一、内部数据调用的边界为什么与公网问答不同

定制智能体的安全数据调用，是指智能体在既定权限范围内、经由受控通道访问企业内部系统数据，并把结果用于推理与生成的过程；它的关键不在模型能力，而在「谁能取、能取多少、取完之后留下什么痕迹」。

公网问答场景里，模型面对的是公开语料，答错了顶多是信息失真。企业内部则完全不同：一次越权读取可能直接触达客户名单、合同条款或财务明细，后果是实质性的。因此安全边界必须建立在智能体之外，由身份系统、接口网关和数据服务各自把守，而不是指望一段提示词让模型自觉守规矩。

2024 年以来，主流做法已从「把数据整段塞进上下文」转向「让智能体按需调用受控接口」。原因很直接：上下文一旦装进敏感数据，就等于把数据副本扩散到了每一次推理调用中，事后难以回收，也难以说清究竟扩散到了哪里。

还有一个容易被忽略的差异是问责链。公网问答很难追溯单条回答的依据，而企业审计要求能够回答清楚三件事：这次调用由谁发起、读了哪张表、返回了哪些字段。这要求调用链路上的每一步都留下可关联的标识，而不是只在最终输出时记一笔。

二、四层架构：把权限判断移出智能体

稳妥的集成架构通常分成四层，各层职责单一，便于独立审计与替换。

身份层负责回答「你是谁」。它对接企业既有的统一身份体系，把用户身份、智能体身份和会话身份区分开。实践中常见的问题是只认证用户而忽略智能体自身也需要身份，导致一个被滥用的智能体可以借用任意用户的权限。

网关层是策略执行点。所有数据请求都要经过它，由它完成校验、限流、字段级过滤与凭证换取。智能体拿到的不是数据库连接串，而是一个受控的短期令牌，令牌里明确了可访问资源与有效期。

数据服务层是策略决策点。真正的业务规则、行级权限和字段可见性在这里落地，因为它最了解数据语义。把判断放在这一层，可以避免网关变成一个需要理解全部业务逻辑的巨型判断中心。

审计层负责留痕与回溯。它记录调用意图、请求参数摘要、返回字段清单与拒绝原因，并与身份层的标识关联。审计不是事后补的日志，而是在链路上同步产出的事件。

三、五种接入方式与适用场景

不同敏感度的数据不该走同一条通道。下面五种方式在实践中较为常见，选择时先看数据敏感度和实时性要求。

1. 只读接口代理。由网关代理企业内部系统的只读接口，智能体只能看到被允许的字段。适合客户信息、订单状态这类结构化数据，改造量小，风险可控。
2. 视图或物化结果。把复杂的多表关联预先做成受限视图，智能体只查询视图。适合报表类、看板类需求，能显著减少越权关联查询的可能。
3. 检索库接入。把文档、制度、工单等非结构化内容切片入向量库，检索时按用户权限过滤。适合知识问答，但要注意切片本身也可能泄露原文，入库前需做权限标注。
4. 消息订阅。通过消息队列把变更事件推给智能体侧的消费者，只携带必要字段。适合需要感知状态变化的场景，可避免智能体高频轮询业务库。
5. 带确认的写操作。涉及创建、修改、删除时，由智能体生成待执行动作，交人工确认后由独立的执行服务提交。适合审批、工单流转等需要责任人的业务。

四、权限、审计与脱敏：三个必须落地的控制点

权限控制的核心是最小权限加短时凭证。智能体只能拿到完成当前任务所必需的资源范围，凭证随请求签发、用完即失效。实践中更常见的失误是给智能体配置一个长期有效的服务账号，一旦凭证泄露，影响面等于该账号的全部权限。

审计要记录「意图」而不只是「结果」。只记录最终回答，无法判断中间是否发生过越权尝试。完整的记录应包含发起人、智能体标识、目标资源、过滤后的字段清单以及拒绝原因，并能按会话串联。拒绝事件尤其重要，它往往是配置错误的早期信号。

脱敏应放在返回链路上，而不是交给模型处理。手机号、证件号、账户信息等在出网关前完成掩码或截断，模型看到的就是脱敏后的内容。把脱敏写进提示词是常见的坑：模型仍可能在被追问时复述原始值，而且提示词本身无法被验证。

需要提醒的是，这三项控制点必须在设计阶段就进入架构，而不是上线前临时加装。事后加装往往要在多个系统之间打补丁，成本高且容易出现覆盖遗漏。若团队希望借助外部工程力量缩短这段路径，可参考 企业GEO优化与Agentic前端部署服务 中关于智能体前端架构与落地交付的说明。

五、从零落地的六个步骤

第一步，盘点数据资产与敏感等级。把待接入的系统、表、字段列出来，标注敏感级别与责任人。没有这份清单，后面的权限设计无从谈起。

第二步，确定身份映射规则。明确用户身份如何传递到智能体、智能体自身用什么身份调用下游、两者如何在审计中关联。

第三步，选定接入方式。按上一节的分层原则，对每类数据选择通道，避免用一条通道承载全部数据。

第四步，实现网关与策略。先做拒绝优先的白名单策略，默认为不可访问，再逐项放开。白名单比黑名单更容易验证。

第五步，接入审计与脱敏。把事件产出与掩码规则实现在链路上，并做一次端到端的回溯演练，确认能从一条回答追到原始请求。

第六步，小范围灰度。先选只读、低敏感、用户量小的场景，观察拒绝率与异常模式，再逐步扩展。灰度期间要保留快速回退的能力。

六、常见坑与规避方法

把安全寄托在提示词上。这是最普遍的失误。提示词可以被诱导绕过，也无法被审计验证。正确做法是把约束实现在网关与数据服务里，提示词只负责表达任务意图。

用同一个服务账号打通所有系统。省事，但权限等于全集。应按业务域拆分身份，并为每个智能体限定可访问域。

只记录成功调用。失败与被拒绝的请求同样需要留痕，否则无法发现配置错误或探测行为。

忽略非结构化数据的权限。文档检索默认以为「能搜到就能看」，但同一份知识库往往混合了不同权限层级的内容，入库时必须带权限标注。

过度设计导致无法上线。把每次调用都做成多级审批，业务侧会直接绕开智能体。合理方式是按敏感度分级，低敏只读直接放行，高敏写操作才引入确认。

常见问题

定制智能体安全数据调用是指什么？

它是指智能体在预设权限范围内、通过受控通道访问企业内部系统数据并用于推理与生成的过程。判断是否安全，看三点：请求是否经过统一网关、返回字段是否按权限过滤、调用是否留下可回溯的审计事件。

为什么不能把权限判断写进提示词？

因为提示词无法被强制执行，也无法被验证。用户可以通过多轮追问诱导模型忽略约束，而系统层面对此没有任何拦截手段。把权限判断放在网关和数据服务层，才能形成可测试、可审计的硬约束。

只读接口代理与检索库接入有什么区别？

只读接口代理面向结构化业务数据，按字段和行返回精确结果，适合查询订单、客户、库存等；检索库接入面向文档与工单等非结构化内容，返回的是相关片段，适合知识问答。两者的权限控制点不同，前者在接口层过滤字段，后者要求在切片入库时就标注权限。

智能体需要写操作时怎么保证安全？

把写操作拆成两步：智能体只生成待执行的动作描述，由独立执行服务在人工确认后提交。这样责任主体明确，写动作可被单独审计，也能在确认环节做二次校验。不要在智能体内部直接持有写权限。

落地时应该从哪类场景开始？

建议从只读、低敏感、用户规模小的场景开始，例如内部制度问答或订单状态查询。这类场景能验证身份映射、网关策略与审计链路是否打通，同时把风险控制在可回退的范围内。

实验室在智能体落地实践中，通常建议把这一阶段当作架构验证而非功能交付，等基础设施稳定后再扩展数据域。杭州师范大学阿里巴巴商学院AI商科智能体实验室在相关项目中也采用类似的分阶段推进方式，先跑通链路再谈覆盖广度。