网关侧脱敏比应用里补丁更稳：AI调用前后该过滤哪些字段

Written by

AI安全里有一类问题特别常见：团队知道要脱敏，但脱敏逻辑散落在各个应用里。一个服务过滤手机号，另一个服务忘了过滤身份证；一个接口过滤输入，另一个接口把工具返回原样塞进提示词。

这就是为什么脱敏更适合放在网关侧。不是说业务应用不用管，而是AI中转站应该提供一层统一兜底。

输入里先过滤直接标识符

进入模型前，最先要处理的是直接标识符，例如：

这些字段如果不是任务必需，就不应该进入模型上下文。即使任务需要，也应该尽量替换为占位符，让模型处理结构而不是处理真实敏感值。

很多团队只过滤用户输入，却忘了检索增强和工具返回。RAG片段、CRM查询结果、日志摘要、数据库返回，都可能携带敏感字段。

因此脱敏点应该覆盖：

只在入口过滤一次是不够的，因为敏感信息可能在链路中途被工具带回来。

模型输出不是天然安全的。它可能复述输入中的敏感信息，也可能把工具返回里的字段带出来。

对于面向外部用户的场景，网关可以在输出前再做一轮轻量检查：是否包含密钥形态、身份证形态、手机号形态，是否出现内部域名、内部错误栈、调试字段等。

这不是为了替代业务规则，而是防止明显泄露穿透到用户侧。

脱敏的目标是降低风险，同时保留任务可用性。如果所有字段都替换成星号，模型可能无法完成任务。

更好的方式是按字段类型处理：

这样既减少暴露，也保留足够上下文。

日志保存时间通常比一次请求长得多，也更容易被更多内部人员访问。因此日志脱敏应该比实时请求更严格。

建议普通日志只保存摘要、哈希、字段类型和调用结果。原始内容如果必须保存，应放在更高权限区域，并设置过期时间。

脱敏逻辑如果散在每个应用里，很难保证一致。统一AI中转站可以把敏感字段识别、替换、日志策略和审计放在同一层，让所有模型调用走相同底线。

像 https://top-api.cc 这样的统一入口，适合把脱敏作为默认能力接入：应用仍然可以做业务级过滤，但网关层负责最后一道通用防线。

AI脱敏不是上线前随手加几个正则，而是贯穿输入、上下文、工具结果、输出和日志的链路治理。越早把脱敏放到网关侧，后续接入的应用和工具越不容易各自为战。