AI API 接入前怎么处理敏感字段？

AI API 接入业务系统前，很多团队先关注模型效果和成本，却忘了输入里可能混着手机号、合同编号、客户姓名、内部账号和工单原文。等到日志、重试队列、调试样本都留下完整内容，再补脱敏规则会非常被动。

适用场景：要调用模型，但不想把原始数据到处留

这篇适合准备把客服、CRM、表单、知识库、合同摘要或 AI 自动化办公流程接入模型的团队。你可能只是想让模型做分类、摘要、改写或字段抽取，却在请求体里带上了完整联系人、地址、订单号和备注。若还没有整理知识来源和权限边界，可以先看 AI API 接入前企业知识库要先整理什么；多人共用接口时，也建议参考 团队多人用 AI 模型接口怎么管权限和日志。

操作步骤：先减少，再替换，最后控制留存

1. 列出字段清单和用途

不要一上来就写正则。先列出模型完成任务真正需要的字段：分类任务可能只需要问题标题和标签，摘要任务需要正文但不一定需要手机号，合同条款比较需要条款文本但不需要签署人身份证。把字段分成必需、可选、禁止三类，写进调用说明。这个动作能让 AI 模型接口的输入变小，也能降低后续日志暴露风险。

2. 在进入模型前做脱敏

脱敏应发生在调用 AI API 之前，而不是写完日志以后。常见做法是把手机号替换成 [PHONE_1]，姓名替换成 [NAME_1]，订单号替换成 [ORDER_1]，同时在本地受控存储里保留映射，只有业务回填时才使用。对开发者 AI 调用来说，脱敏后的文本也更容易复现和分享给测试人员。

$text = $text -replace '\d{11}', '[PHONE]'
$text = $text -replace '订单号[:：]?\s*[A-Za-z0-9-]+', '订单号：[ORDER]'
# 只把脱敏后的 text 发给模型

3. 日志只留排查所需信息

日志里建议记录 request_id、用户、功能、模型、输入长度、输出长度、状态码、错误类型和脱敏版本哈希，不默认保存完整原文。若业务需要抽样复盘，应建立单独样本库，标注授权来源、保留期限和访问人。结构化输出可结合 开发者调用 AI 模型时的 JSON 输出契约，让模型返回字段状态，而不是把敏感信息原样带回。

常见问题/避坑：脱敏不是把所有文本打码

第一个坑是过度脱敏，模型失去判断上下文。例如售后工单里“北京仓”和“上海仓”可能是分流依据，不能全部替换成地点。第二个坑是只脱敏前端展示，后端请求和日志仍然保存原文。第三个坑是把脱敏映射写进普通日志，等于换了个地方泄露。第四个坑是测试环境随手复制生产样本，后来谁都说不清样本来源。

还有团队会把脱敏和权限混为一谈。脱敏减少内容暴露，权限决定谁能调用、谁能查看日志、谁能恢复映射，两者都要做。若接口已经上线，建议配合 AI API 用量观测和日志标签，排查哪些功能还在发送完整原文。

检查清单：上线前至少跑三类样本

• 含手机号、姓名、地址的样本，确认请求体、失败日志和重试队列都只出现占位符。
• 含业务编号和合同编号的样本，确认模型仍能完成分类或摘要。
• 含长文本的样本，确认只记录长度、哈希、状态和必要错误类型。
• 权限检查：普通开发者不能下载完整原文和脱敏映射。
• 保留期限检查：调试样本和异常样本有明确清理时间。

FAQ：已经有 HTTPS，还需要脱敏吗

需要。HTTPS 解决传输过程中的安全问题，不代表业务系统、日志平台、队列、备份、工单截图都不会保存内容。AI API 接入要按“最小必要数据”设计，能不发就不发，能替换就替换，能短期留存就不要长期留存。你可以在 AI API 接入专题 里继续整理调用、权限和模型调用管理规则，让接口从第一天就更容易审计。

验收标准：从请求到日志都看不到原始敏感值

上线前不要只检查正常成功路径。建议准备三条样本：一条包含手机号和姓名，一条包含订单号和地址，一条包含较长的客户备注。分别触发成功、超时和参数校验失败，检查请求日志、错误日志、重试队列、人工复盘样本和用量看板。只要其中一个位置还能看到原始手机号或完整订单号，就说明脱敏链路没有闭合。

对开发者 AI 调用来说，还要确认脱敏后的文本不会破坏任务目标。比如合同摘要里可以替换证件号，但付款金额、期限和条款编号必须保留；客服分流里可以替换联系人，但产品型号和问题类型要保留。这个取舍要写进接口说明，不能只靠模型临场理解。永沃云枢的内部清单也建议把字段用途、脱敏策略、日志保留期限和负责人放在同一页，方便后续审计。