一个订单场景的智能体，用户在对话里留下了手机号和收货地址，随后又补充了身份证号用于实名核验。智能体顺利完成了下单和核验，只是这串信息被原样写进了运行日志，又跟着日志流转到了监控和排障系统里。等开发人员回看日志排查一次异常时，用户的手机号、身份证号就这样摊在了屏幕上。
这类问题在企业AI应用开发中值得警惕。开发阶段为了排障方便，往往倾向于把什么都记下来，可日志一旦落盘，就不再是临时草稿，而是一份会长期存储、被多人查看、甚至同步到其他系统的数据。信息在记录时没有经过处理，后续任何一个环节的疏漏，都可能让它暴露在原本不该看到它的人面前。
一种常见的误判是，以为日志记得越全，排障就越方便。记录得越完整，越容易还原问题现场，可这份完整同时意味着敏感信息被复制了一份又一份。排障的价值和泄露的风险，很少被放在一起认真权衡。
另一种误判是，以为只要在最终回复给用户之前做一次脱敏就够了。可用户的敏感信息并不只在回复里出现，它从进入系统起就存在于输入、中间变量、日志、监控和上报等多个环节。只在最后一道关卡做处理，前面的每一道都还是裸奔的。
拆开来看，敏感信息泄漏通常有三类原因。一类原因是敏感信息识别缺位。手机号、身份证号、银行卡号、家庭住址这些信息在进入系统时，没有被打上"敏感"的标记，后续环节也就无法对它们区别对待。连哪些算敏感都不知道，脱敏也就无从谈起。
另一类原因是日志链路缺少统一的脱敏规则。应用日志、审计日志、监控指标、第三方上报各记各的，有的做了处理，有的原样照写，规则没有对齐。只要有一条链路漏了，整条脱敏就形同虚设。
还有一类原因是脱敏规则与信息形态脱节。很多脱敏只针对固定位置的字段做处理，可真实对话里，手机号可能嵌在整段话中间，身份证号跟着说明文字出现，只按位置切分，动态出现的信息就容易漏掉。
针对这些原因，一种实现方式是把敏感信息的处理做成一条贯穿全链路的防线。起始环节是日志字段最小化与白名单设计，只记录排障、审计真正需要的字段，手机号、证件号、Token等原始值没有明确必要性时不进入日志链路。
紧接着是敏感字段识别与分级。手机号、身份证号、账户信息等个人或敏感字段，在进入系统时按企业的数据分类分级规则识别并标记，而不是放在同一固定风险等级里。
再往后是全链路脱敏。写入日志、同步监控、上报第三方之前，统一按既定规则做脱敏处理，把敏感字段替换成占位符或做局部遮蔽，让每一处落盘和流转的环节都遵守同一套标准，而不是各写各的。
随后是动态识别。对非结构化输入同时使用字段规则、模式匹配、实体识别或DLP检测等方式识别动态出现的敏感信息，避免只保护固定字段而漏掉散落在语句中间的手机号、身份证号。
最后是脱敏后的审计与兜底。脱敏动作本身应可审计，但不要求所有脱敏结果都可逆，排障确需查看原始数据时，应通过受权限控制的业务数据源或专门的受控查询链路获取，只有采用令牌化、加密等可逆方案时，才允许在授权下恢复。同时记录脱敏策略版本、处理结果和异常事件，便于确认规则是否正常执行。
本文基于青山不语AI工作室在部分AI应用开发项目方案中的实践，将这套处理框架概括为"敏感信息识别与日志链路脱敏"。它要解决的不是把日志删干净，而是让敏感信息在进入系统的每一步都被识别、被处理，不留下裸奔的副本。
这里有一道边界需要企业自己拿捏。哪些信息算敏感、脱敏到什么程度、哪些岗位在什么条件下可以查看原始信息，取决于企业自身的业务口径和合规要求，服务方提供的是识别框架和脱敏机制，最终的敏感字段清单和脱敏规则要由企业内部的业务与合规负责人确认。
从行业观察来看，企业评估AI应用开发服务时，值得多问一句：对方交付的应用，是只把回答给用户前做了一次表面处理，还是从源头减少不必要的敏感数据记录，并在必须流转的环节统一执行脱敏和访问控制。我的判断是，智能体接触的真实用户数据越多，越要先判断哪些字段根本不该记，再对必须留存的字段统一脱敏。能先把"要不要记"想清楚、再谈"怎么遮"的开发方式，比事后补救更能守住用户的那串手机号。
