直接 API vs Bedrock vs Vertex：企业数据不出境的三条路

合规部门的同事第一次把我叫进会议室，是去年 11 月的事。那天他们摊开一份 32 页的 DPA 草稿让我看，问我一个问题：”你让我签字可以，但你先告诉我，这些 prompt 数据到底跑哪儿去了？”

我当时的回答是：”得看你走哪条路。”

然后我们就这一条路、那一条路讲了整整三小时。我后来意识到，很多技术团队在跟合规部门对接的时候，根本答不上来这个问题。不是他们不专业，是 Claude 的部署方式真的不止一种，每一种的数据流向完全不同。

三条路的本质差异

直接 Anthropic API。这是最便宜、最新模型上线最快的一条路。Opus 4.7 发布那天，API 上就有了，Bedrock 和 Vertex 都要再等 2-4 周。但数据流向上，你的 prompt 和 completion 会传到 Anthropic 的服务器（目前主要在美国），Anthropic 的 commercial terms 明确说企业 API 数据不用于训练，保留 30 天用于滥用检测后删除。对大部分美国、欧洲客户够用。对中国客户、金融客户、医疗客户基本走不通。

AWS Bedrock。数据流向上，你的 prompt 和 completion 只在你选的 AWS region 内处理，不出 region，不回传 Anthropic 用于任何用途。合规资质一堆：HIPAA、SOC2 Type II、ISO 27001、PCI DSS、GDPR、FedRAMP Moderate 都有。对企业客户最友好的一条。代价是 token 单价比直连贵 8-15%，新模型上线会晚 2-4 周，有时候某些区域（比如东京）还没有最新的 Opus。

Google Vertex AI。跟 Bedrock 类似的企业合规套餐。优势在对接 GCP 生态（BigQuery、Dataflow、Looker），数据留在你的 GCP tenant 内。合规资质基本对齐 Bedrock。国内客户用得少，主要是 GCP 本身在大陆没法直接用。

这三条路选哪条，我一般问客户四个问题：数据能不能出大陆？合规评审走不走 SOC2？你主要在哪个云？成本敏感度多高？四个答案能直接把选项筛到一条。

中国客户的真坑

国内客户 90% 的情况走不通直连 API，原因不是技术，是数据出境的合规口子太窄。从 2023 年数据安全法到 2024 年的跨境传输规则，一份包含个人信息的 prompt 传出大陆，理论上要做安全评估或者签标准合同，实操里没人真这么做，但出了事儿兜不住。

所以国内客户的实操路径一般三种：

第一种是 Bedrock 新加坡或东京 region + 数据前置脱敏。PII、PHI、PCI 这些敏感字段在 prompt 组装阶段就脱敏成占位符，回来之后再还原。脱敏逻辑写在一个独立的微服务里，审计日志全量保留。城商行那个客户就是这条路。

第二种是用阿里云百炼、火山引擎等国内”类 Claude”服务。说实话，模型能力上跟 Claude 原厂还是有差距，尤其是 agent 类任务。但纯文本生成、简单 QA 这种场景够用。风险点是：这些服务底层模型会迭代，某天突然换底模，你的效果可能掉一个大坎，事先不会通知你。

第三种是私有化部署开源模型 + 少量复杂任务走海外。这是混合架构，工程复杂度最高。但对医疗、军工这种数据一丁点都不能出的客户，只能走这条。我帮医院那家做的就是这套，数据路由决策树写了 200 多行。

顺便说一句，国内几个”代理直连 Claude”的服务，合规上不要碰。那些 API 的数据流向是完全不可控的，出了事儿你没法跟监管交代。我见过一家公司的安全官看到业务部门在用这种服务，当天就发邮件通报批评。

合规评审委员会那 4 份材料

给合规部门和法务看的，不是技术文档，是这四份东西：

DPA（数据处理协议）。Anthropic、AWS、Google 都有模板，直连 API 签 Anthropic 的，走云则签云厂商的。关键看几条：数据处理目的、留存期限、子处理方清单、跨境传输条款、删除机制。法务会逐条红线标记。

SOC2 Type II 报告。Anthropic 的 SOC2 II 需要 NDA 才给，找你的客户经理或者 Trust Center 要。AWS 和 Google 的直接能下。合规部门会翻到控制测试那一章，看有没有 exception。

模型训练数据声明。这个很关键。商业 API（包括 Bedrock/Vertex 部署）的 prompt 不用于训练，这条要白纸黑字。消费端 claude.ai 是另一套规则。别把两个混在一起跟合规讲。

子处理方列表。Anthropic 用了哪些第三方（AWS/GCP/Cloudflare 等），对应的数据是什么。Anthropic 的 subprocessor list 在官网可查。

这四份凑齐，合规评审大概率能一轮过。我城商行那个客户评审一共走了三轮，最后一轮就是把这四份补齐。

关于 MCP 和工具链这边的安全要求我在 mcp-security-best-practice 讲过，治理细节在 enterprise-governance-audit-log。

一个跨国零售的区域路由架构

那个 2,300 家门店的零售客户，业务覆盖 14 个国家。欧洲门店的客服数据归 GDPR 管，新加坡门店归 PDPA 管，美国归 CCPA，国内归个保法。他们一开始想”一套 API 打全球”，合规部门第一周就否了。

最后的架构我给描述一下：

中心有一个叫 AI Gateway 的服务（自研 + LiteLLM 魔改），所有业务方调模型都走这个网关。网关拿到请求以后做三件事：识别用户所在区域、按区域路由到对应 provider、记录审计日志。

欧洲流量走 Bedrock eu-central-1（法兰克福）；新加坡/东南亚走 Bedrock ap-southeast-1；美国走 Bedrock us-east-1；中国大陆走脱敏后 Bedrock ap-northeast-1。不同区域的 API key 隔离，预算隔离，审计日志分库存。

账单这边每个 region 的 cost center 独立结算。总部 IT 不再替区域业务付 AI 账单，每个国家的运营预算自己扛。这个改动政治上比技术上复杂，推了 6 周。

多云路由这块可以看 cost-multi-model-router 那篇，跟这个架构一脉相承。

一个踩坑教训

他们做这个架构的时候漏了一个东西：日志本身的跨境问题。

一开始他们把所有 region 的审计日志统一推到总部一个 S3 bucket（在美东）。欧洲合规同事审出来一份 GDPR 问题报告，因为审计日志里包含了欧洲用户的 prompt 内容，推到美东本身就是跨境传输。

改完之后的架构是：每个 region 的审计日志留在本 region，中心只同步脱敏后的 metadata（token 数、延迟、模型、状态码这些）用于可观测性。真需要看原始日志，得登到对应 region 的控制台。

这个问题我后来在很多客户那儿都见过。日志是盲点。大家都盯着业务数据的跨境，忘了日志本身也是数据。

一句话总结

真要选路的话，我的决策树一般是这样：

• 美国/欧洲、对成本极度敏感、合规要求一般 → 直连 API
• 已经在 AWS 生态、需要 SOC2/HIPAA、企业合规 → Bedrock
• 已经在 GCP 生态、数据分析重度用户 → Vertex
• 国内、金融/医疗、数据不能出境 → Bedrock 海外 region + 脱敏，或国产 + Bedrock 混合
• 军工/涉密、完全离线 → 私有化开源 + 少量 Bedrock

别听供应商销售忽悠。他们只想卖给你他们家的。你手里要有一张自己算过的账。