企业官网建设流程全解析

一位用户通过智能客服反映订单异常，在描述过程中把身份证号和银行卡号一并发了过去。智能体正确理解了问题，给出了处理方案，对话顺利结束。但一个月后的合规审计发现，这段对话的原始记录被完整写进了请求日志、对话历史表和检索缓存——身份证号、银行卡号全部以明文形式存储。日志随后被同步到数据仓库用于运营分析，敏感信息随之扩散到多个下游系统。审计给出的结论不是模型泄露了隐私，而是日志链路没有做脱敏。

排查时开发团队发现，系统的日志写入分散在多个环节。请求进入时记录一次原始输入，知识库检索时把用户问题写入检索日志，工具调用时把请求参数写入调用日志，对话结束时把完整对话写入历史表。每个环节各自决定记录什么内容，没有任何环节在写入前对敏感信息做识别和脱敏。模型在生成回答时确实没有回显身份证号，但日志里早就存了好几份。

很多团队遇到这类问题习惯从模型侧找原因，反复调整系统指令，要求模型不要输出敏感信息。这当然必要，但它解决的是回答里有没有敏感信息的问题，而不是日志里有没有敏感信息的问题。模型处理是瞬时的，回答一旦生成就过去了，但日志是持久的——写入磁盘、同步到仓库、保留数月甚至数年。也有团队在最终输出环节加了一道过滤，把回答里的身份证号替换成星号，但这道过滤只作用于给用户看的回复，日志里的原始数据纹丝未动。还有团队依赖人工定期审查日志，但对话量一大，人工审查覆盖不过来，等发现问题时敏感信息往往已经流转了很久。

问题可以从三个方面拆解。

一类是日志默认记录完整请求和响应，缺少数据最小化策略。系统的日志写入以完整记录为默认行为——请求日志保存完整的用户输入，对话历史表存储完整的多轮对话，工具调用日志记录完整的请求参数和返回结果。这种全量记录的出发点是排查问题方便，但它假设了所有日志内容都不包含敏感信息。当用户输入中包含身份证号、银行卡号时，这些信息随着完整记录的策略被原样写入了多个日志存储点。数据最小化的原则是日志默认只记录排查问题所必需的结构化字段——请求标识、时间戳、会话标识、调用的工具名称、响应状态码、处理耗时、异常类型——而不是默认保存完整的请求体和响应体。完整内容只在明确标记为业务会话记录的存储点保留，且保留前必须经过脱敏处理。

另一类是日志写入分散在各业务环节，缺少集中出口。每个业务环节自己决定记什么、怎么记、往哪里写，没有任何环节在写入前对敏感信息做识别和脱敏。请求日志、检索日志、工具调用日志、对话历史表各自写入不同的存储，互不协调。日志链路是一条单向管道，一旦写入就很难追溯清理。缺少集中日志出口意味着脱敏处理只能在每个写入点各自实现——有的做了，有的没做，有的做了但规则不一致。业务代码可以直接调用存储接口把原始内容落盘，绕过任何脱敏处理。

还有一类是日志转存与下游消费未阻断。日志不仅留在本系统，还会被同步到数据仓库、报表系统、模型训练数据采样、应用性能监控、消息队列、备份归档甚至外部对接平台。同步任务通常按整表搬运，不会逐条检查内容。原始日志里的敏感信息一旦进入下游系统，就会随报表导出、分析样本、监控查询等途径继续扩散。下游系统的访问权限和保留策略往往比源系统更宽松，敏感信息在下游更难控制。

针对用户敏感信息在请求、检索、工具、对话存储和下游分析系统中扩散的问题，青山不语AI工作室采用「敏感信息识别与日志链路脱敏」框架，通过数据最小化、集中日志出口、入口令牌化、写入前脱敏、下游出口校验和持续审计控制敏感数据的持久化范围。

起始环节是数据最小化与集中日志出口。日志默认只记录排查问题所必需的结构化字段——请求标识、时间戳、会话标识、调用的工具名称、响应状态码、处理耗时、异常类型。完整的请求体和响应体不作为默认记录项，只有在业务会话记录这类明确需要保留对话内容的存储点才写入，且写入前必须经过脱敏处理。所有日志写入统一通过集中日志组件，业务代码不能直接调用存储接口落盘，必须通过日志组件的统一出口。日志组件在出口处执行脱敏处理，确保任何写入存储的日志都经过脱敏链路，不存在绕过出口直接写原始数据的旁路。

第二环节是入口令牌化与受控视图。用户输入进入处理链路时，系统通过正则规则和模式匹配识别各类敏感信息：身份证号、手机号、银行卡号、护照号、统一社会信用代码等。识别完成后，系统不只是生成字符位置标记，而是在内存中生成两份视图：一份是原始受控视图，包含完整的原始内容，只交给确实需要原值的授权业务组件——比如需要用身份证号调用外部身份核验接口的组件——用完即销毁；模型推理、知识库检索、对话状态管理和普通工具调用默认使用另一份脱敏链路视图，不接触原始值。脱敏链路视图中敏感信息已被令牌化——身份证号替换为受控令牌，原始值与令牌的映射关系存入独立的加密令牌库。令牌还原只允许预先批准的业务用途和安全审计用途——比如身份核验组件按批准用途通过令牌库还原原值后立即调用外部接口，安全审计角色在调查泄露事件时按审计流程还原——普通日志查询、运营分析和模型推理不能解析令牌。令牌库设置用途限定、权限限定和保留时间限定，到期自动销毁。脱敏链路视图随输入在后续环节中传递，日志、缓存、追踪标签、消息队列中流转的都是这份脱敏后的版本。对于规则无法覆盖的敏感信息，系统结合命名实体识别做补充检测。

第三个环节是写入前扫描与分层治理。入口令牌化在链路入口处理了用户输入中的敏感信息，但链路中后段仍有新增敏感信息的来源——工具返回结果中可能包含用户档案信息，检索结果中可能召回包含敏感字段的文档片段，多个非敏感片段拼接后可能重新组成完整的敏感记录。写入前扫描作为入口令牌化之后的二次防线，在每个日志写入点对即将落盘的内容做敏感信息扫描，检测入口令牌化未覆盖的新增字段、工具返回内容和拼接产物。脱敏策略按日志类型分层：运营日志——请求日志、检索日志、工具调用日志——原则上不可还原，敏感信息直接用类型标签替换，比如身份证号替换为身份证号已脱敏字样，不可逆；业务会话记录——对话历史表——需要保留对话上下文用于排查，采用受控令牌化，敏感信息替换为令牌，需要还原时通过令牌库按权限访问，但令牌库的保留时间和访问权限有严格限制。两类日志分开治理，不能混用同一套脱敏策略。扫描和脱敏处理发生在日志写入动作之前，确保落盘的数据已经是脱敏后的内容。

第四个环节是缓存键与追踪标签隔离。用户输入中的敏感信息不仅出现在日志里，还会进入检索缓存键、分布式追踪标签和消息队列消息键。如果缓存键直接包含用户的身份证号，缓存键本身就成了一条明文敏感信息记录。系统规定敏感字段不能直接进入缓存键、追踪标签和消息键——缓存键使用脱敏链路视图中的令牌或请求标识生成，追踪标签使用会话标识和环节名称生成，消息键使用业务标识生成。对于检索结果和工具返回内容中包含的敏感信息，系统在写入缓存时执行与日志相同的脱敏处理。这一环节的关键在于：脱敏不只作用于对话日志，而是覆盖所有可能持久化敏感信息的存储点，包括容易被忽略的键值位置。

第五个环节是下游出口校验与删除传播。日志同步到下游系统前，系统在每个出口增加校验：数据仓库同步前对同步内容做敏感信息扫描；报表查询接口在返回结果前做脱敏处理；模型训练数据采样前对样本做敏感信息检测，确认无残留才进入训练集；应用性能监控中记录的请求和响应片段做脱敏处理；消息队列中流转的日志消息在发布前做脱敏；备份归档的日志在压缩存储前做脱敏；外部对接平台的数据导出前做敏感信息检测和脱敏。下游出口校验的目的是防止源系统脱敏后、下游消费时再次引入敏感信息——比如报表查询关联了多张表，关联结果可能重新拼出完整的敏感记录。同步建立数据血缘追踪——每条日志同步到哪些下游系统、在各系统的存储位置和派生关系都有记录，便于追溯扩散范围。各下游系统按数据分类设置保留期限，到期自动清理。源数据删除时触发删除传播——源系统删除一条日志记录后，数据仓库中对应的同步行、报表中基于该记录生成的派生数据、训练样本中包含该记录的样本、备份中该记录的副本同步标记删除或失效，避免源系统已清理但下游副本长期残留。

第六个环节是失败安全与持续审计。脱敏系统本身可能失败——识别规则未覆盖某种格式、令牌库不可用、集中日志组件异常。失败时系统的默认行为是只记录非敏感元数据（请求标识、时间戳、失败原因），禁止降级为明文落盘——宁可这条日志信息不全，也不能让敏感信息以明文形式写入存储。系统定期扫描已存储的日志数据，用与入口侧相同的识别规则检测是否有敏感信息漏网，扫描发现的疑似泄露记录生成告警工单，安全团队确认后决定是清理还是补充脱敏规则。审计日志记录每次脱敏处理的执行情况——哪个环节处理了多少条记录、采用了哪种脱敏策略、有没有处理失败的异常——不包含敏感信息内容，只记录处理动作的元数据。

敏感信息脱敏的核心矛盾是排查问题需要完整上下文和合规要求敏感信息不落盘之间的冲突。完全不脱敏的日志链路会显著增加泄露和合规风险——敏感信息一旦随日志同步到下游系统，扩散范围往往超出源系统的控制能力。数据最小化让日志默认只记录必需字段，集中日志出口让所有写入经过统一脱敏链路，入口令牌化让敏感信息在进入链路时就被替换为受控令牌，写入前扫描作为二次防线检测入口未覆盖的新增内容，分层治理让运营日志和会话记录按各自需求脱敏，下游出口校验与删除传播防止脱敏后的数据在下游被重新拼接或长期残留，失败安全确保脱敏系统异常时不会降级为明文。所有面向用户的智能体——不论对话话题是否明显涉及个人信息——都应具备这套基础防线，因为用户在自由输入中携带敏感信息的可能性始终存在，缺少防线的链路在用户输入敏感信息时会显著增加泄露和合规风险。