先分级再选路
把请求按数据密级与任务类型分成必须本地、可脱敏外发、可直接外发三类，再为每类指定处理位置。为什么先分级：不分级就只能整体选边，要么牺牲能力，要么放弃合规。边界是分级结论由合规与业务共同确认，技术人员不能自行放宽。
比较五个维度
能力差距、延迟与并发、数据约束、三年总成本、运维负担。怎么做：用同一套评测样本分别跑本地与云 API，把差距量化成通过率而非主观评价；成本按实际调用量折算，不要拿标价直接对比，忽略闲置与人力会得出反向结论。
网关统一入口
在应用与模型之间放一层网关，统一做鉴权、脱敏、路由、限流与审计。为什么值得：切换供应商时只改策略不改业务代码，出问题时能按 trace 定位。边界是网关自身也要纳入高可用与容量评估，否则它成为新的单点。
双轨的运维代价
两套环境意味着两套监控、两套发布与两拨值班，人力往往被低估。怎么做：尽量统一推理协议与日志格式，把差异收敛到配置层；边界是合规要求不同的环境不能为了省事共用密钥与账号，权限要按环境隔离。
回退预案
云侧限流、涨价或合规口径变化时，要能在约定时间内把流量切回本地。怎么做：定期做切换演练，验证容量与配置；边界是回退只能让业务保持可运行，能力差距要提前向业务说明，不能承诺无缝切换。
适用与不适用
适合谁
- 业务同时包含敏感信息与公开咨询的行业客户
- 希望保留云 API 能力又必须满足数据要求的企业
- 正在设计模型接入层与供应商策略的架构团队
不适合谁
- 全部请求都涉及强敏感数据、没有可外发部分的业务
- 没有运维能力、也不接受双轨管理复杂度的团队
典型场景
某制造企业的售后问答既有设备参数也有客户信息。团队把含客户标识的请求留在本地中等规模模型，纯参数查询走云 API，网关按字段识别自动分流。上线前做了两次切换演练，确认云侧不可用时本地能承接主要流量，切换脚本与责任人写进了运维手册。
可执行步骤
- 按字段梳理每个请求的数据构成，逐一标出敏感项、可脱敏项与可直接外发项
- 与合规部门确认三类分级与对应的处理位置，形成书面结论并签字留档
- 用同一套评测集比较本地与云 API 的通过率、延迟分位与成本口径
- 在网关配置分流策略、脱敏规则、限流阈值与审计字段，变更走灰度
- 做一次双向切换演练，记录切换耗时、实际容量、失败点与责任人并复盘
常见坑
- 只按业务系统划分而不看请求内容，同一接口里既有敏感也有非敏感字段，分流规则实际失效却无人察觉。
- 比较时只看单次调用价格，忽略闲置容量与运维人力，结论偏向自建，运行半年后发现总支出更高。
- 网关只做转发不做审计，出了问题查不到请求去了哪里、用了哪个模型，责任界定非常困难。
- 没有回退演练，云侧限流时才发现本地容量不足，业务被迫长时间降级且无法向客户解释。
自检与验收清单
- 请求级的数据构成是否逐字段梳理并形成清单
- 分级结论是否有合规签字、日期与适用范围的说明
- 评测是否用同一套样本、同一口径对比本地与云 API
- 网关是否记录路由结果、脱敏动作与耗时字段
- 双向切换是否演练过并记录耗时、失败点与责任人
常见问题
双轨会不会增加泄露风险？
会增加管理面，但不必然增加泄露风险。关键是分流规则由谁维护、脱敏在哪一层执行、审计能否还原每次请求的去向。规则集中管理并定期复核，风险是可控制的，散落在各业务代码里才危险。
云 API 能不能签数据不落地条款？
可以谈，但条款效力取决于对方能否提供审计与证明，以及违约后的救济方式。签约前应确认日志留存、子处理者与删除机制，并把关键承诺写成可检查的义务，而不是一句声明。
什么情况下应当全本地？
数据类型单一且高度敏感、并发稳定、已有运维能力时，全本地更容易把边界做实。反之业务波动大、能力要求高，双轨通常更现实，但要把网关与值班成本一起算进去。