“调用国外大模型 API产品还要不要管 EU AI Act”这个问题是最近在一次产品规划会上被点名的。当时法务同事很平静地问了一句“我们接的那个大模型 API受不受 EU AI Act 管”会议室安静了两秒然后有人小声说了一句“用户都在国内跟欧盟有什么关系”如果你正处在类似的产品团队里这句话大概率也是你脑子里潜在的第一反应。但我后来花了三周时间把整条链路从法规条文、模型供应链到产品使用场景逐层拆了一遍才意识到这个问题的正确问法不是“yes or no”而是“这个产品在整个法案覆盖的图里落在哪个格子”。所以这篇内容我想讲清楚三件事EU AI Act 到底管谁在“调用海外大模型 API”这个具体姿势下责任会落在谁身上以及如果确实需要管最小可执行的合规动作是什么。适合产品经理、技术负责人、法务与 GR 相关同学参考。1. 一张“地域图”把问题摊开EU AI Act 管谁、管什么、什么时候生效1.1 三条适用路径先对号入座很多人听到“欧盟法案”就先入为主地以为只有“在欧盟注册的公司”才需要遵守。实际上 EU AI Act 的适用范围写得比想象中宽它更像一张带触角的地图而不是一张只有边界的静态图纸。它的核心规则写在第 2 条里可以简化成三条适用路径。路径适用对象关键触发条件为什么值得注意提供者路径AI 系统的提供者在欧盟市场投放系统或投入使用谁开发、谁投放谁就是主要责任人部署者路径AI 系统的部署者部署者位于欧盟境内使用者也要承担一部分义务域外路径欧盟境外的提供者或部署者系统的输出在欧盟境内被使用不看你注册地看你输出的“脚”落在哪第三条路径往往是被忽略的。它的逻辑是即便你公司不在欧盟、服务器也可能不在欧盟但只要你的 AI 系统输出结果实际被用到欧盟用户身上法案就认为你与欧盟场景产生了实质联系。这正是“调用国外大模型 API”这个问题里最微妙的部分。打个不严谨但好理解的比方法案不是只看“人住在哪”而是看“手伸到了哪”。你人在境外但只要系统输出在欧盟境内产生了业务效果就进入了法案的观察范围。很多纯做国内业务的产品团队之所以说“不用管”本质上是在赌第三条路径没有被触发但这需要严谨的证据链而不是一句“我们用户都在中国”就完事。1.2 三套义务三种“火力”确认自己在不在范围内之后第二步是判断自己处于哪种义务层级。EU AI Act 不是一个“一刀切”的法规它把义务按风险分成几个梯度越往高风险走动作越重。义务层级适用对象典型动作罚款上限取两者较高者禁止实践所有人不得使用操纵性、剥削性技术不得做社交评分特定实时远程生物识别被禁止3500 万欧元或全球年营业额 7%高风险系统高风险场景的提供者与部署者风险管理、数据治理、技术文档、日志记录、人工监督、事件报告3500 万欧元或全球年营业额 7%GPAI 基础模型基础模型提供者通常是 API 上游模型卡、版权政策、训练数据摘要、安全评估、系统性风险应对1500 万欧元或全球年营业额 3%透明度义务交互式 AI、深度合成、情感识别系统告知用户正在与 AI 交互、对合成内容做标记视具体违规情形而定这里我们需要先把两个角色名词理清楚。所谓“提供者”是把 AI 系统推向市场的那个人一般情况下是模型开发者所谓“部署者”是在真实业务场景里使用这套 AI 系统的人。在 API 调用场景里模型供应商是上游提供者而你把自己的业务数据喂进去、把结果用在自己的产品流程里你就处在“部署者”的位置上。这两类角色不是互斥的一个团队完全可能同时既是上游模型的部署者又是自己包装后 AI 功能的提供者。很多技术团队只关注“模型能力怎么接入”但法案更关心“这个能力被用来做什么”。同样是调用同一个海外大模型 API你把它拿来做客服问答和把它拿来做招聘简历排序责任等级完全不同。场景分类是决定你是否需要大动干戈的核心变量。1.3 生效时间线比大多数团队想象的更近还有一个容易被低估的因素是时间。EU AI Act 不是等到某个“未来时刻”才一次生效它分了几波。如果不把时间线标出来很容易出现“现在不需要做、下季度突然要上线”的慌乱局面。以公开的时间表为参考时间节点关键变化2024 年 8 月法规正式生效2025 年 2 月禁止实践条款开始适用2025 年 8 月GPAI 基础模型义务开始适用2026 年 8 月部分高风险系统分类规则开始适用2027 年 8 月遗留高风险系统规则全面过渡完毕把时间线摊开之后你会发现很多团队现在还在做技术选型和联调觉得“合规是后话”但禁止实践条款的适用时间已经过去GPAI 义务也已经进入执行阶段。模型供应商那边已经开始出一系列文档和承诺连带下游产品的责任边界也会被重新梳理。所以早期产品设计里给合规留一个小口子比后面推倒重来要便宜得多。2. “调用国外大模型 API”到底算谁的义务2.1 位置一纯上游提供者义务基本落在模型方为了讲清楚这个场景我虚拟一个案例某团队 A 开发了一款面向国内中小企业的知识库问答应用通过 API 接入了海外某模型供应商的基础模型产品只面向国内客户不开设海外版本官网只有中文销售合同全部由国内主体签署部署也都在国内。在这种“纯国内链路”里EU AI Act 主要的目光会落在上游模型供应商身上。作为模型提供者他们要承担 GPAI 基础模型的义务包括编写模型卡与技术文档、制定版权相关政策、按监管模板提交训练数据摘要、开展安全评估、对系统性风险做缓解措施等等。这些义务从条文上看确实不以某个具体下游客户为转移而是伴随基础模型本身存在的。也就是说如果你的产品没有进入欧盟市场没有欧盟部署者输出也没有被欧盟用户使用那么“要不要管”这个问题的答案在当前的客观事实下更多是“暂不触发”。但注意这是一个动态判断不是一劳永逸的豁免证明。2.2 位置二用API做产品的集成方其实就是“部署者”很多团队没有意识到“部署者”这三个字的分量。你不需要自己训练模型才叫提供者拿起别人的模型塞进自己的业务流程里在法案视角下你就是部署者。部署者不是完全无责的旁观者第 26 条明确要求部署者按提供者给定的使用说明来使用系统对系统输出进行监测在发生事件时及时报告在高风险场景下还要做一系列配套动作。继续用刚才那个案例做变体团队 A 把同一个知识库产品上了某个面向欧盟客户的云市场并且把模型能力用于客户服务场景。这时“输出在欧盟被使用”这个条件就被点亮了产品开始进入 EU AI Act 的实体适用范围。而如果这个产品还被客户自行用于招聘简历初筛、信贷资料预审这类敏感场景那“高风险系统”这顶帽子也会随之扣下来。这就是标题问题的核心答案雏形问题不在于“你是否调用国外大模型 API”而在于“你的产品实际服务谁、输出去哪里、用于什么场景”。单纯调用 API 本身不构成原罪让输出在欧盟场景落地才是触发的开关。2.3 位置三中间平台/聚合服务责任最容易被忽略还有一种容易被忽视的角色聚合平台。有些团队不直接面向最终用户而是做一个网关或聚合服务把多个模型 API 统一封装后提供给第三方开发者。这种位置的人经常觉得“我只是转发请求模型是上游的业务是下游的跟我有什么关系”。但法案的归责逻辑不是看“你是否拥有算法”而是看“谁在多大程度上决定了系统的使用方式”。如果你在封装层做了模型选择、提示词模板、输出格式控制、数据转发策略那你就已经深度介入系统设计。欧盟监管机构完全可能把这一层解释为“提供者”或“再提供者”而不是无辜的管道。对聚合平台来说最稳妥的做法是把自己默认当成责任链条上的一环向上下游明确权利与义务边界而不是寄希望于“技术中立”免死金牌。2.4 回答标题的问题三层判断足够用绕了这么一大圈该给一个可以直接照做的判断路径了。我把它收敛成三层判断遇到类似问题先过一遍基本能定位个大概。第一层系统是否在欧盟市场上投放或投入使用——自己开发的模型或功能有没有上欧盟应用市场、云市场有没有欧盟本地化版本第二层部署者是否位于欧盟——你的直接客户、渠道伙伴、经销商是不是欧盟实体第三层系统输出是否会在欧盟境内被使用——哪怕只是偶然被访问也要评估接触面。只要这三层里任意一层命中就需要往下一步判断你从事的具体场景是禁止实践、高风险系统、GPAI 基础模型还是只需要满足透明度义务。如果三层全部不命中把评估结论和依据记录下来标注日期存档。这一步很重要它既是给管理层看的“合规判断留痕”也是未来业务扩张时用来重新评估的基线。3. 实操要点用四类问题给自己做一次“电子体检”3.1 客户是谁欧盟用户有没有可能触达“客户是谁”这个问题看起来蠢但实际操作中特别容易想当然。很多产品团队说“我们没有海外业务”但细问之下全是缺口官网其实有多语言版本销售通过经销商卖过一次单合同签约方是经销商的欧盟主体产品上了某个国际云市场的公开目录。这些事情单看都不大合起来就是域外适用路径的实锤。我自己用过的检查方法是一张简短清单官网有没有欧盟地区可访问的落地页、定价页、下载入口产品有没有在面向欧盟的应用市场或云市场上架销售合同模板里有没有可能出现欧盟实体的签约路径市场活动有没有通过欧盟当地的代理商、分销商触达终端用户客服系统中是否可能收到来自欧盟 IP 或欧盟邮箱的咨询如果这些问题全是“否”触发概率确实低但只要有一个“是”就不能用“我们没有海外业务”来自我安慰。这是实务里最容易被忽视的第一步。3.2 场景是什么你做的事算不算高风险EU AI Act 对高风险系统的定义不在技术路线而在应用领域。它列出了一整套场景清单比如就业与员工管理、信贷评估、医疗分诊、教育招生、司法分析、关键基础设施等。只要你用模型能力辅助这些领域的决策无论你调用的是开源模型还是海外商业 API都会被拉进高风险框架。我特别想提醒一点很多产品并不直接宣称自己是“招聘工具”或“信贷工具”但它们做出来的功能客观上在支持这些决策。比如一个简历解析插件虽然只负责“提取候选人经历并生成摘要”但客户拿它直接辅助筛选那就可能被解释为招聘场景的系统组件。所以判断场景时不能只按产品定位的文档走还要看客户实际怎么用。一条实用的经验在产品条款里明确“预期用途”把不支持的场景写清楚至少能缩小责任的外沿。3.3 数据是什么GDPR和AI Act是两条线还是同一条EU AI Act 与 GDPR 不是替代关系而是并行关系。GDPR 管个人数据的使用和流动AI Act 管 AI 系统的风险与治理。两者在某些高风险场景下会交叉叠加。比如你在欧洲医疗场景用海外大模型 API 做辅助诊断既涉及健康数据的 GDPR 合规又可能触发 AI Act 高风险系统的全套装具DPIA数据保护影响评估这类动作大概率跑不掉。如果你的产品完全不碰个人数据AI Act 带来的负担会明显轻一些。但也别高兴太早只要系统被用于欧盟场景一些底线的透明度和监控义务依然存在。实操上我建议先做一张简单的数据流图输入了什么输出被谁看到是否在服务器上留存是否能被人工读取删除路径是什么。这张图既是 GDPR 合规的基础也是 AI Act 技术文档的骨架可以一份材料支持两套法规的要求。3.4 宣示知悉合同、条款、模板里的“担保条款”合规义务能不能在合同层面提前划清边界完全可以。而且这是成本最低的杠杆。我现在做产品方案时会把合规预期写成可被合同引用的条款而不是只停留在口头讨论。分享一个简化版模板它能直接改着用“甲方仅按照文档约定提供通用模型接口能力不对特定行业决策结果作任何正确性担保甲方不将本服务用于欧盟法规项下的高风险决策场景包括但不限于招聘、信贷、医疗诊断若使用者自行将服务用于上述场景使用者作为部署者应自行承担相应合规义务与责任。”不要小看这几句话。上游模型供应商的 API 使用条款里往往也会写“不得用于高风险或特殊决策场景”我们把它传导到自己的下游客户合同里其实是在多重义务之间建立了一道缓冲带。每次产品发布前我都会把“预期用途声明”当作产品文档的一部分去维护而不是让法务追着我要材料。4. 我踩过的几个“合规陷阱”和排查实录4.1 常见误区一模型方合规等于我合规这是我在实际项目里见过最多、也最麻烦的误区。某次项目里产品打算做一个面向 HR 的初筛辅助模块团队觉得“我们调用的是海外头部大模型 API人家肯定把所有欧盟手续办完了我们跟着用就行”。但这是把“模型提供者”的合规和“场景部署者”的合规混为一谈了。上游模型供应商做好 GPAI 义务只能证明“这个模型本身符合基础模型层级的监管要求”。但把它放在招聘初筛这个场景里使用时部署者需要额外承担人工监督、结果说明、事件响应等义务。当候选人对 AI 判断提出异议时产品需要提供可解释的信息和人机协作通道。我们后来补了一整套功能给 HR 的界面增加“AI 初筛仅供参考”的提示给候选人提供人工申诉邮箱在系统里保留每个评分节点的人工复核记录。这些动作不大但在责任链条上堵住了关键缺口。说到底模型合规只是你的“上游证照”你自己的场景责任还得自己背。这个误区的破解之道很简单把“调用 API”和“在业务里使用”看成两件事分别问一次“谁担责”。4.2 常见误区二只有“有欧盟分公司”才被管另一个高频误解是“我们在欧盟没有实体、没有分公司所以管不到我们”。这个说法在绝大多数国家的地域管辖逻辑下都站得住脚但 EU AI Act 的域外适用条款专门设计了一个“输出使用地”的锚点就是为了防止有人通过“在欧盟境外注册主体”来绕开约束。举个实际例子某公司没有欧盟实体但它的产品通过一家欧盟经销商提供给当地企业客户。经销商买走产品之后把它直接用于员工绩效评估。从法案的条文逻辑看这家公司可能被认定为向欧盟市场投放系统的实体同时其输出在欧盟境内被使用域外路径完全被点亮。看似“没有欧盟分公司”的公司也可能因为经销渠道的存在而进入监管视野。所以在内部合规评审里我建议把“是否在欧盟注册”这个问题换成“我的客户、渠道、输出结果是否在欧盟”。前者是静态身份后者才是动态风险。问对问题答案往往比想象中复杂。4.3 常见误区三日志保留、人工监督不知道怎么写当团队真要准备 AI Act 相关文档时最容易卡住的是“日志保留”和“人工监督”这两个要求。它们不像是写一行代码那么具体写起来很容易变成空话。我提供一个相对落地的组合它是我们在一次合规版本迭代里沉淀出来的日志留存只保留技术诊断所需的信息比如调用时间、错误码、性能指标不保留用户输入原文与模型输出。默认 30 天覆盖或自动清理并在隐私说明里明确写清楚。人工复核在高风险场景下模型输出必须先进入“待复核”状态页面明确标注“结果仅供参考最终决策由人工完成”。为每项结果记录复核人和复核时间。事件响应公开一个合规联系邮箱承诺收到数据主体请求后 30 个自然日内响应。对影响用户权益的严重事件保留事件记录并评估是否需要通知。这套东西写起来一页 A4 纸但实际操作时它真的能落地。别一上来就设计一个庞大的治理体系先守住最小可行边界再根据产品成熟度扩张。4.4 发布前30分钟自查表最后给一个我自己的“发布前 30 分钟自查表”它不是法务文档而是技术团队也能照做的检查项建议打印贴在项目发布台旁边市场目标用户里有没有欧盟国家和地区如果有合规文档是否已更新场景当前功能是否碰触高风险场景名目如果触碰人工复核和投诉渠道是否就绪数据是否涉及个人数据数据流图是否更新留存策略是否明确合同上游模型 API 条款有无变化下游客户合同里的“预期用途声明”是否已同步透明用户是否能感知到自己在与 AI 交互合成内容是否有标记联系页面是否提供了可联系的人类邮箱或客服入口这些检查项单个拿出来都不重但它们共同构成了一个“最小合规骨架”。我见过太多产品因为少一个投诉邮箱被客户揪着不放或者因为生成内容没有 AI 标识引发信任危机。30 分钟过一遍比事后写说明省时间。我个人在实际操作中的体会是合规方案如果做成一整套学术论文没人执行等于没做把它拆成一个个能打勾的任务反而推进得很快。对“调用国外大模型 API”的产品来说EU AI Act 不是一道“要不要管”的判断题而是一条“谁在用、在哪里用、用来做什么”的动态链路。先别急着给自己下豁免结论拿出半天时间把链路捋一遍把这套询问沉淀成团队的默认流程成本低收益却可能是一次危机公关的代价。