两个问题分开看
数据放哪里由合规与延迟决定，模型用哪家由能力与成本决定。混在一起讨论，容易出现为了用某家模型而整体改架构的情况；分开评估后，往往能在不改架构的前提下解决大部分需求，投入也更可控。
常见组合模式
本地部署通用模型处理敏感任务，云上调用能力更强的模型处理复杂请求，用网关按数据级别与任务类型路由。组合的复杂度集中在路由与评测，而不是调用本身；把这两件事做好，日常运维负担可以接受。
网关是必要投入
统一网关承担鉴权、限流、日志、路由与降级，使模型与部署位置可替换。没有网关，每次调整都牵动业务代码，测试范围也随之扩大；网关本身要有人维护，规则变更要走评审并留痕，避免上线后无人跟进。
治理与审计
跨侧调用要能回答谁在何时把什么数据发到了哪里。日志要覆盖请求摘要、模型版本与响应状态，并纳入现有审计体系；敏感字段要脱敏，日志保留期限也要与合规要求对齐，不能只靠口头约定，日志本身也要控权限。
别为形态而形态
如果业务全部可在云上合规运行，混合云只增加复杂度。形态应服务于数据边界与业务连续性需求，而不是作为技术先进性的证明；评审时要能说清每一项跨侧设计的必要性，否则不如直接简化。
适用与不适用
适合谁
- 在混合云与直接调用接口之间犹豫的团队
- 需要同时满足合规与能力上限的企业
- 多业务线共用模型能力、需要统一入口的架构师
不适合谁
- 数据可全部上云、无跨侧需求的项目
- 尚无明确业务场景、先建架构的团队
典型场景
某保险公司本地保留理赔影像与客户信息，云上调用大模型做条款解释。团队用网关按数据敏感度分流：含个人信息的请求只走本地模型，公开条款解释走云上模型。日志记录请求类别与模型版本，审计时可还原每次调用路径。
可执行步骤
- 分开梳理数据边界与能力需求，避免混在同一张表里讨论，形成两页说明
- 列出必须本地处理的任务清单，请安全部门确认并说明依据，形成书面结论
- 用网关实现按级别路由与限流，规则集中在网关而非业务代码，便于统一调整
- 日志覆盖请求类别、模型版本与响应状态，满足审计与追溯要求，字段要脱敏
- 按季度复核路由比例、质量与成本，必要时调整分流比例，形成复核记录，并留档
常见坑
- 把架构形态当目标，忽略业务是否真的需要跨侧，投入与收益并不匹配，评审时也难以自圆其说，后续调整空间很小。
- 路由规则写死在业务代码里，调整一次要改多处，测试范围失控，回归成本大幅上升，故障时难以快速定位。
- 跨侧调用日志缺失，无法回答数据去了哪里，检查时难以自证，问题定位也变慢，追责更无从谈起，整改也无从下手。
- 只为能力上限选模型，忽略本地合规限制，方案在评审阶段被否，前期投入沉没，进度也被拖慢，预算也被浪费。
- 网关上线后无人维护，规则逐渐过时，降级预案形同虚设，真故障时无从下手，恢复时间不可控，业务连续性受影响。
自检与验收清单
- 数据边界与能力需求是否分开梳理，是否分别成文
- 本地必处理任务是否有清单，是否经安全确认，是否有签字
- 路由是否集中在网关而非业务代码，是否有评审流程
- 跨侧调用日志是否可用于审计，是否覆盖敏感字段
- 是否定期复核路由比例与成本，是否形成记录，是否有台账
常见问题
混合云加接口会不会太复杂？
复杂度主要来自路由、评测与审计三件事。用统一网关与一套评测集，复杂度可控；如果每个业务各自对接，才会迅速失控，也很难在故障时快速定位问题，缺少网关时排查会非常被动。
能不能只用接口满足合规？
取决于数据分级与监管要求。部分场景可通过脱敏、专属实例或区域化部署满足，但需要安全与法务确认，不能由技术方案单方认定，也不能用口头承诺替代书面条款，条款要写进合同。
路由规则应该多久调整一次？
建议按季度复核，业务或合规变化时随时调整。调整要有评测与灰度，避免一次性改变大量请求路径导致质量波动，也要保留回切方案，调整后要有对比数据并留存记录，不要一次性全量切换。