警惕AI中转站数据安全风险

很多人挑中转站只看价格和速度，等把客户资料、内部代码、合同文本喂进去之后才想起来问一句：这些内容会经过谁的手、留存多久、能不能删。这篇不吓唬人，只把风险拆成看得见的几层，再给一套选站和用站时能照着做的动作；合规要求高的场景该不该走中转，文中也说了什么情况下不适用。

挑中转站的时候，价格和速度最显眼，数据去哪了反而没人问。等客户资料、内部代码、合同文本已经喂进去好几轮，才想起来这一层，通常就晚了。这篇不渲染恐慌，只把风险拆成看得见的几段路、几档数据、几个开关，让你在选站和日常调用时能照着做。

要说明的是，中转站本身不是原罪。它解决的是接入成本、多模型切换和网络可用性问题，这些价值是真实的。问题出在很多人把它当黑盒用，既不问留存也不做脱敏，把高敏感内容当成普通问答发出去。下面按「链路—分级—选站—日常—不适用」的顺序讲。

先搞清楚你的数据到底走了哪几段路

一次调用看起来只是本地发个请求、拿到一段回复，实际链路比这长。从你的程序到中转站是一段，中转站到上游官方接口是第二段，中间还可能经过日志、缓存、重试队列三个留存点。任何一处配置不当，请求原文都能被完整记下来，而且往往留存时间比你想象的长。

• 日志留存：请求体、响应体、错误栈都可能落盘，排查问题时最容易被翻出来
• 缓存与重试：为省成本或提高成功率做的缓存和失败重试，会把同一段内容在多个节点复制一遍
• 账号标识：请求里带不带你的用户 ID、项目标识，决定别人能不能把调用记录对应回具体的人
• 多人共用一把 Key 时，谁调了什么、调了多少，在中转站侧通常是一张能看全的表

按数据类型分三档，别一刀切

很多团队出问题是因为把「敏感」当成一个开关，要么全禁要么全放。更实用的做法是按数据类型分档，不同档位配不同动作。分档的标准不是内容看起来重不重要，而是泄露之后对客户、对公司有没有实际损失。

分档之后还要落到人。给团队列一张「哪些内容不许贴进对话框」的清单，写进新人上手文档，比事后追责有用得多。清单不必长，把你们业务里最容易顺手粘贴的那几类写进去就够了。

选站阶段能查的几件事

1. 先看有没有公开说明站点有没有隐私条款、数据留存说明、运营主体信息。一条都没有的直接排除，不用再谈价格和速度。
2. 做一次可控的定向测试用一小段你构造的、能识别的测试文本发过去，观察回显里有没有出现不该出现的上下文。具体探针方法和判读方式，到 /tools/verify 与 /tools/verify#probes 看当时的说明。
3. 对照站内收录与可信度信息把站内的收录信息和可信度相关榜单当初筛，不当背书；价格与状态这类会变动的数字，到 /sites 和 /rankings 核对当时的数据。
4. 问清上游是谁你的内容最终落到哪家官方接口，这决定了真正的数据政策。上游不清楚的站，前面几步做得再好也只能算低风险，不能算没风险。

要讲清一个不适用的情形：条款写得再全，也挡不住上游供应商本身的数据政策。最终风险取决于整条链路里最松的那一环，而这一环往往不在中转站手里。

日常调用要落地的几个开关

选站只是开始，真正天天发生的是调用。下面几个动作成本都不高，但能把大部分意外挡在外面。核心思路是把「信任」换成「不依赖信任的设计」。

• 中转用的 Key 独立申请、独立用途、可随时吊销，不要和官方账号的主 Key 混用
• 在调用前做一层前置脱敏：手机号、邮箱、证件号、内部域名用正则替换成占位符
• 日志只保留元数据，时间、模型、token 数这类可以留，请求和响应原文不落盘
• 把「谁能发什么内容」写进流程，新成员入职就讲一遍
• 定期复查还在用的中转 Key 和授权范围，离职、换项目时同步清理

脱敏这一步值得单独强调。它不依赖任何一方的承诺，只依赖你自己的代码，是整条链路上最可控的一环。质量监控和自查工具可以到 /tools/quality-monitor 与 /tools/quality-check 看你需要的功能当时是否可用。

哪些情况下不该用中转

前面讲的是怎么用得更安全，这一节讲的是有些场景压根不该用。判断依据不是技术能不能跑通，而是合规和审计上能不能交代过去。

已签数据处理协议的项目

客户条款明确要求数据不得经第三方转手时，中转链路本身就是违约点

需要审计留痕的场景

行业监管要求你能拿出可追溯的上游调用凭证，中转站通常给不了

对上游身份有硬要求时

官方通道与云厂商托管通道的处理口径更清楚，差异到 /official-api 与 /providers 对照

还有一种折中做法：敏感任务走官方或自建通道，普通任务继续用中转，按任务分流而不是整站搬走。这样既不放弃中转带来的成本和便利，也不把高风险内容放上不可控的链路。