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