很多团队上 Agent 的顺序是这样的：先选一个业务场景，把数据接进去，跑通、看到效果，然后才开始想「这样合不合规」。问题是第一批被接进来的数据，往往就是个人信息。
客服 Agent 要读工单，工单里有手机号和地址；HR Agent 要处理简历和入职材料，那里面有身份证号；财务 Agent 要核报销，那里面有银行卡号和消费明细。这些都不是「稍微敏感」，是法律意义上的个人信息，处理不当要担责任的那种。
这篇不讲概念，只讲一件具体的事：怎么给 Agent 自己划数据边界。先说清楚和站内旧文的区别——数据脱敏检查 和 敏感数据分层脱敏 讲的是「把 Agent 当成脱敏工具来用」，本篇是反过来：Agent 自己就是那个要管住的对象。
一、先看三个最容易出事的动作
不用背法规，先自查这三个动作有没有发生在你的系统里：
- 把原始记录整段塞进提示词。最典型的写法是「把这条工单内容给模型看看它该怎么回」。于是身份证号、手机号、家庭住址、客户情绪化投诉原话，全部进了模型的上下文。
- 交互日志明文落盘。提示词和回答默认会被记录，方便排查。这一记录，就等于把上面的内容又抄了一份到日志系统里——而且日志往往权限更松、留存更久、备份更多。
- 一个 Agent 同时握着「读全量」和「往外发」。能读客户表、又能发邮件、又能调外部接口。这三个凑在一起，一次提示词注入就足够把数据带出去。
这三个动作的共同点是：你并没有想作恶，你只是想让功能跑起来。风险就是这么攒出来的。
二、第一道闸：数据分级，先定「哪些字段可以进模型」
这一道闸的作用是把决策提前——不要在写提示词的时候临时判断「这个字段能不能给」，而是提前把清单定死。
粗分四级就够用：
- 公开级：产品说明、公开文档、帮助中心内容。可以自由进上下文。
- 内部级：内部制度、流程说明、非敏感的业务数据。可以用，但要限定在内部模型服务里。
- 个人信息级：姓名、手机号、邮箱、住址、设备号、订单明细等能直接或间接识别到人的信息。默认不进上下文，需要用就用脱敏后的替代值。
- 敏感个人信息级：身份证号、银行卡号、生物特征、健康与医疗记录、精确位置、未成年人信息。默认不进上下文，要进必须单独审批并记录理由。
分完级，产出的东西不是一份报告，而是一张字段白名单表：哪张表的哪个字段，属于哪一级，允许以什么形态进入模型。没有在这张表上的字段，就是不能进。这比任何提示词里的「请注意不要泄露」都管用。
举一个客服场景的例子。工单原文里有十几个字段，真正需要模型看的可能只有「问题类型 + 产品型号 + 发生时间 + 客户描述（去标识后）」。手机号、订单号这些拿来定位记录用的字段，压根不需要给模型看——它在数据库里查就行。
三、第二道闸：脱敏要做在取数层，不做在输出层
这是最容易被做错的一道。很多人把脱敏放在 Agent 回复之后：模型答完了，再拿规则把答案里的敏感信息抹掉。
这个顺序是错的。因为数据在进模型的那一刻就已经出去了——出去了就不归你管了。正确的做法是在数据离开数据库、进入上下文之前就处理掉。
两种做法按场景选：
- 掩码：手机号显示成 138****5678，身份证号留头尾。格式还在，人能看懂，模型也能理解上下文。适合「模型只需要知道这里有个手机号」的场景。
- 令牌化：把真值换成一个随机代号（如
CUST_7F3A），真值留在一张本地映射表里。模型全程只看代号，只有在你需要执行真实操作（比如发短信）时，再由程序在可信侧把代号换回真值。适合客服、工单这类「模型必须区分不同人、但不该知道他是谁」的场景。
选哪种，判断标准是一句话：模型需不需要知道真实值才能完成任务？不需要，就令牌化；只需要识别格式，就掩码。
还有一条纪律：脱敏规则要跟着字段白名单一起版本化。新增一个字段就要问一次「它属于哪一级、要不要脱敏」。最怕的是系统跑得好好的，某天业务加了个「客户备注」字段，谁也没注意，明文就这么一直流进了上下文和日志。
四、第三道闸：最小权限，敏感动作回人
前两道闸管的是「数据能不能看」，这一道管的是「能不能动」。站内 权限最小化怎么做 已经把原则讲透了，这里只说在个人信息场景下最容易忽略的三点：
- 读写分离。只做问答的 Agent 不该有写权限。很多事故不是「泄露」而是「误改」——Agent 顺手把工单状态改了、把备注覆盖了，追溯时才发现它从来没有被授权做过这件事。
- 按任务发临时凭证，不发长期密钥。做法参考 凭证轮换怎么设：每个任务开始时拿一个短时效、窄权限的凭证，任务结束即失效。这样即使凭证被带出去，窗口期也极短。
- 涉及个人的高风险动作必须人工确认。批量导出、对外发送、删除记录、修改客户资料——这几类动作属于「做错了很难收回」，一律留人工最后一道确认。具体怎么设计确认队列，站内 客户可见动作怎么管 讲得很细。
五、第四道闸：留痕，而且日志本身也要脱敏
留痕这件事有个悖论：你和审计需要的日志，恰好是风险最高的数据集中地。提示词里有原文、回答里有细节、截图里有界面，全都在日志里躺着。
要做两件事：
- 留什么要设计过。别只留「模型答了什么」，要留下判断链上的关键字段：是谁发起的、什么任务、读了哪几条记录、调了哪些工具、结果给了谁。字段怎么设计参考 审计查询字段怎么设计——目标是半年后有人问「这条数据流向哪了」，你能立刻答出来，而不是翻一堆原始日志。
- 记下来的东西本身要脱敏。日志里的手机号该掩码就掩码，原文该存摘要就存摘要。需要完整原文做取证的场景，把它单独隔离到一个更严格的环境里，别混在日常可查的日志里。这个「分层留证」的思路和 证据包怎么留 是同一套东西。
顺便提一句：回放和截图是最常被漏掉的两个角落。为了排查问题录下来的操作回放里，往往带着最完整的明文界面。做 回放对照 的时候，要顺手确认回放文件的权限和留存周期。
六、落地三步
- 盘数据资产，出字段白名单。把你准备接进 Agent 的那几个业务表过一遍，逐个字段定级、定形态。这一步做完，最大的风险其实已经被消掉了。
- 挑一个风险最高的场景先跑通。通常就是客服或工单。把分级、脱敏、权限、留痕这四道闸在这个场景里完整走一遍，跑顺了再复制到其他场景。
- 把检查做成例行的。规则定完不会自动保持正确。设一个周期性任务，定期核查「有没有新字段绕过白名单进了上下文」「有没有不该出现的明文落在日志里」。周期性巡检的写法可以参考 陈旧内容巡检 的思路，只是检查对象从知识库换成了数据流。数据质量门禁 那套「在入口处拦」的思路也直接适用。
七、四个最常见的坑
- 把脱敏放在输出侧。前面讲过：数据进过模型就已经出去了，事后抹掉只是让报告好看。
- 只靠提示词约定。「请不要泄露用户隐私」这句话，在正常对话里可能有用，在提示词注入面前基本等于没写。防线要在数据层和权限层，不在自然语言层。
- 日志、回放、截图里躺满明文。四道闸只盯着主链路，忘了这些副本。事后追责时你会发现，最脏的地方是审计工具本身。
- 以为「不用公网模型就没事」。这里要分两种情况看：调用境外模型 API，等于把数据发送到境外，属于需要单独评估的合规事项；即使模型服务部署在境内，也要确认服务商是否会用你的数据做训练，以及数据存不存在你控制不了的地方。自建一套私有服务能解决一部分问题，做法见站内 本地模型怎么接。
更完整的防线思路，可以对照站内 生产级 Agent 的七道安全防线 一起看——那篇讲的是整体框架，本篇补的是「个人信息」这一块的具体做法。
优缺点和适合人群
优点：四道闸全都在工程层实现，不依赖模型自觉；字段白名单一旦成型，新增场景的合规判断成本会大幅下降；留痕做得好，复盘和责任界定都轻松；这套做法同时能覆盖「数据质量」和「安全审计」两类需求。
缺点：前期盘数据、定字段是要花时间的活，没有捷径；脱敏会损失一部分信息，个别需要看原文的场景（比如纠纷取证）体验会变差；规则需要人维护，字段一变就得跟着更新，长期看是个持续成本；令牌化方案需要改造取数层，对小团队来说是不小的工程量。
适合：准备把 Agent 接进真实业务、且业务数据里含个人信息的团队——尤其是客服、HR、财务、医疗、金融这几类。如果你的 Agent 目前只处理公开文档和内部非敏感资料，可以先把分级做起来，其余三道闸等接了真数据再上。
总结
- 先自查三个动作：整段塞原文、日志明文落盘、读全量又能外发。中一条就得动手。
- 数据分级出白名单：没有在清单上的字段，就是不能进上下文。
- 脱敏放到取数层：模型不需要知道真值就用令牌化，只需要识别格式就用掩码。
- 最小权限加重确认：按任务发短时效凭证，高风险动作留人工一票。
- 留痕要设计，日志也要脱敏：别让审计工具变成最脏的地方。
最后一句：合规不是加在 Agent 外面的一个壳，而是数据流进来之前就要定好的规矩。等到出事再补，你补的就不是流程，是责任了。
