你正准备把一个项目的模型调用切到国内中转站，或者已经切了但心里没底：请求里带着业务数据，Key 也在别人手里过一道，万一泄漏算谁的？这篇不给「绝对安全」的结论，只给可执行的东西——一条判断链路、几个能自己验的动作、一份出事后的排查与留证顺序。看完你能对着一项项打勾，而不是听平台口头保证。
你正准备把一个项目的模型调用切到国内中转站，或者已经切了但心里没底：请求里带着业务数据，Key 也在别人手里过一道，万一泄漏算谁的。先说清楚，这篇不给「绝对安全」或者「绝对不安全」的结论，谁给你这种结论都别信。
这里只给能落地的东西：一条判断链路、几个能自己动手验的动作、一份出事后的排查与留证顺序。看完你能对着一项项打勾，而不是听平台口头保证。对价格和模型覆盖这类数字，一律到站内页面核对当时的实际情况，别拿本文当依据。
先分清：什么才算真的泄漏
很多人把「请求经过了第三方服务器」直接等同于泄漏，这会导致两种错误：一是过度恐慌，把能用的方案全否掉；二是过度放心，只盯着平台的口头承诺，忽略自己这边的 Key 管理。先把泄漏拆成三层，每层的危害和应对完全不一样。
- Key 被拿走
- 别人能用你的额度发请求，直接后果是账单失控，通常不涉及业务数据外流
- 请求内容被留存或转卖
- 你发出去的正文、上下文、附带的数据被落库，可能被长期保留或二次使用，这是真正的数据风险
- 响应被二次分发
- 返回给你的内容同时被别人拿到，少见但危害最高，通常说明链路里有人在中间抓包或做代理池
判断落在哪一层，关键看中转站是纯转发还是落库。落库又分三档：只存元数据（时间、模型、token 量）、存请求正文、存正文且长期保留。第一档基本可以接受，第三档需要你确认这批数据里有没有用户隐私。不适用的情况也写清楚：如果你调用的只是公开信息、请求里不含任何用户数据，数据泄漏的危害等级可以下调，但 Key 侧的账单风险一点没变小。
按风险从高到低排一遍你的调用链
别笼统问「这家安全吗」，把调用链拆成四段，逐个打分。多数事故不是出在中转站本身，而是出在前两段——也就是你自己完全能控制的地方。
- 你本地和 CI 里的 Key 存储：有没有硬编码进仓库、有没有在共享环境里明文放、离职或协作变更后有没有轮换
- 传输通道：是不是全程加密，有没有在不安全的网络或公共代理下明文发过
- 中转站自身的日志策略：条款里是否写清保留时长、是否用于训练、有没有可控的关闭选项
- 上游厂商看到的请求：这一层你基本无感，但决定了最坏情况下数据能追溯到哪
把上面四段按「高风险信号 / 中风险信号」对照着过一遍，比看平台的宣传页有用得多。下面这张表可以直接拿去逐项勾选。
| 观察点 | 高风险信号 | 相对可控的信号 |
|---|---|---|
| Key 形态 | 全站一个共享 Key，或者控制台能看到别人的调用记录 | 支持你自助创建、命名、随时吊销独立 Key |
| 条款公示 | 对日志保留、是否用于训练只字不提 | 明确写了保留时长和数据用途 |
| 异常响应 | 出问题只让你「等等」，没有公开联系与申诉渠道 | 有工单或公示的处理流程 |
| 域名稳定性 | 域名频繁更换，文档和入口对不上 | 入口稳定，变更会公告 |
能自己动手验的几件事
平台的保证没法验证，但下面这几件事你自己就能做，而且做完成本很低。建议在正式切流量之前先跑一轮，别等出事了才回头补。
- 发一条带唯一标记的无害请求用临时或小号 Key，在请求里塞一个只属于你的随机标记，内容本身不要含真实业务数据；然后观察这个标记会不会出现在对外可见的用量统计、示例响应或其他人的结果里。出现了就是明确信号。
- 确认传输层检查你的调用代码和代理配置，确认走的是加密通道，别在不安全网络或来路不明的代理下明文发。这一步是自查，不依赖任何平台。
- 翻条款和公示页重点找三个问题的答案：日志保留多久、是否用于训练、能不能关闭。找不到答案就按「会留」做预案，而不是按「不会留」赌一把。
- 本地留一份请求摘要每次调用记录时间、目标、请求体摘要和你用的 Key 标识，存在自己这边。出事的时候，这是你唯一能自己掌控的证据。
还有一件常被忽略的事：把测试流量和正式流量分开。用测试 Key 做验证、用正式 Key 跑业务，一旦要止损，吊销一个不会把线上打断。这属于操作习惯，跟平台好坏无关。
怀疑已经泄漏：排查与止损顺序
顺序错了会丢证据，也会扩大损失。最常见的问题是先跑去跟平台理论，等到想起来吊销 Key 的时候，异常调用已经刷了一轮。按下面这个顺序走。
- 第一步停用可疑 Key 并轮换，止损优先于定责，别先争论
- 第二步拉账单和调用记录，找异常时间窗、异常模型、异常调用量
- 第三步做影响面判断：这批请求里有没有个人数据、密钥、内部资料，决定要不要走内部上报
- 第四步留证：带时间的截图、控制台记录、你本地的请求日志，别只存聊天记录
- 第五步再去找平台，带着前三步的材料去谈，比空口质问有效得多
留证这块有具体格式要求，比如截图要不要带时间、控制台记录怎么导出、跟平台沟通时哪些信息该留哪些不该发，照着去 Key 泄漏应对手册（/guides/key-leak-response-runbook） 和 纠纷取证与留证（/guides/dispute-evidence-keep） 做就行，本文不重复展开。如果你还没选定平台，先把候选站点的可信度过一遍，到 中转站列表（/sites） 和 可信度排行（/rankings） 看当时的检测结果，数字会变，别记死。
这些判断在什么情况下不成立
上面这套是给普通开发者的通用筛查，不是万能的。三类场景要特别说明，硬套会出事。
- 只跑公开数据、不含任何用户信息的小工具，可以容忍更高的不确定性，但账单被刷的风险一点不减，Key 轮换和额度上限还是要设
- 企业对企业、涉及合同或合规义务的场景，不能只用本文自查，得走内部的合规与数据出境流程
- 一旦涉及敏感个人信息或受监管行业的数据，本文只能当筛查清单，真正的结论要由法务和安全团队出，别拿自查结果当合规依据
你控制不了平台怎么存你的数据，但你能控制发出去什么、用哪把 Key、以及出事时手里有什么。下一步与其纠结某一家安不安全，不如先把你现在在用的站点过一遍检测记录，再挑两三个备选做对照。去站内可信度检测与价格追踪页面看当时的数字和变更记录，比看宣传页靠谱。→
常见问题
中转站会不会偷偷把我发的内容存下来？
没有任何外部方法能百分百证明它没存。你能做的是：只用可替换的 Key、请求里尽量不带不可撤回的敏感原文、在本地留请求摘要。如果条款对日志保留时长和用途没有明确写法，就按「会被留存」来设计你的数据边界，而不是赌它守信。
怎么判断一个中转站是不是纯转发、不落库？
看它公开的说明、看它是否提供按 Key 区分的调用记录、看它的用量统计粒度是否只到次数和 Token。这些都是间接证据，不能当定论。最稳的做法是用低敏感请求先跑一段时间，同时用一个独有的标记内容观察是否外泄，再决定要不要接入真实业务数据。
数据出了事，找平台还是自己报？
先止损：停 Key、轮换、确认影响面。如果涉及个人数据或受监管数据，要不要报、报给谁，取决于你所在行业和数据的性质，这一步别自己拍板。平台侧的沟通记录、你的账单和请求日志都要留，顺序和清单可以参照站内关于泄露应急与举证留证的文章。
