1. 先说结论API 调用从来不是合规的免责牌“调用国外大模型 API产品还要管 EU AI Act 吗”这是某位做 SaaS 的开发者在交流群里抛给我的问题。他的产品逻辑很简单前端收集用户输入后端调用某家海外模型服务商的接口把返回结果整理后展示。在他看来模型不是自己训练的数据不在自己的服务器上中间只隔了一层 API怎么算也不该轮到自己操心。我听到这个问题时第一反应是别急着用“模型在哪”来回答得先想清楚你的产品到底在替用户做什么。如果你只是做一个内部实验工具关起门来自己跑那确实离各种 AI 治理框架非常远。但只要产品面向真实用户尤其是面向欧盟市场或未来有出海打算情况就会完全不同。用户感知到的不是“某家模型服务商”而是你做的这个产品本身。用户提交了简历、病历、法律文书系统给出一份自动判断他们不会关心这是哪家的基础模型跑出来的只会认为“你们的产品给了一个不公平的结果”。责任不会因为模型接口在海外就消失链条反而会在产品这一端越扣越紧。所以这个问题的答案其实很直接要管而且越早管越好。这里说的“管”不是让每个产品团队都去啃厚厚的法规条文而是把 AI 治理落成产品开发里的一堆具体动作披露、日志、人工复核、数据最小化、可撤回机制。这些事不玄乎后面我会逐一展开并且给出可以直接抄走的落地方法。2. 海外大模型服务商救不了你的产品责任2.1 你是在“使用 AI”不是在“转发 API”很多团队容易把自己想成“管道工”用户发送请求我们转发给模型再把结果传回来好像这样就能置身事外。这种想法在技术实现上说得通但在产品责任的逻辑上站不住。实际使用者是产品本身调用是产品的内部行为你完全决定了什么时候调、传什么字段、把结果用在哪里。我举一个印象很深的例子。某位做智能写作辅助的开发者产品逻辑是帮用户生成营销文案。他早期觉得模型在海外合规的事就归服务商管。直到一个欧洲客户要求提供“AI 功能影响说明”他才意识到自己连最基本的用户告知页面都没有。后来补了几项东西对话界面标注“本内容由 AI 生成”、后台记录每个请求的模型版本和输出摘要、给用户提供关闭 AI 辅助的开关。这些改动成本不高但把产品从“黑盒工具”变成了“可解释的辅助功能”。这里的关键认知是模型服务商对底层模型负责你对产品形态负责。用户在什么场景下看到输出、输出如何被解读、错误结果会造成什么影响这些只有产品团队自己清楚。服务商的合规文档再完善也覆盖不了你的具体业务逻辑。2.2 API 客户端的义务不是一个“零”如果把 AI 治理的义务拆开看模型提供方确实要承担训练数据治理、模型评估这一类上游工作但 API 调用方这一侧也有一堆事情要做。常见的就有向用户披露产品使用了 AI给 AI 生成内容做标识留存可追溯的操作日志在高风险场景下提供人工复核出现错误时能快速撤回内容。这些都不是“加分项”而是产品功能的一部分。打个比方这就像你买了一台发动机装进自己造的车上卖给别人。发动机制造商对发动机的性能和安全性负责但你作为整车厂商要对整车碰撞安全、用户说明书、售后维护负责。你不能说“发动机是哪家造的撞了车跟我没关系”。AI 模型 API 就是这台发动机产品就是整车责任不会因为零件来自别处就消失。3. 风险定级不看法条看产品功能怎么用3.1 同一个模型在不同场景里风险等级完全不同关于 AI 治理很多技术人最大的误解是“我用的是通用文本生成 API能有什么风险”。这个想法忽略了一个核心原则风险分级不是按模型定的而是按用途定的。同一个文本生成模型放在商品描述生成工具里是低风险放在简历自动筛选系统里可能就是高风险。低风险用途的特征一般是输出不直接决定用户的重要权益错误结果容易被用户识别和纠正即使出错也不会造成严重损失。高风险用途则相反输出会影响个人的工作机会、信贷获取、医疗服务或基本生活权益。换句话说判断标准不是“模型够不够强”而是“输出错了会有什么后果”。所以我建议产品团队不要只盯着模型能力而是把产品功能清单摆出来逐个问一遍这个功能为什么需要 AI输出会直接影响用户决策吗错误输出有多大的破坏力有没有人工兜底手段这些问题回答完风险大概的轮廓就出来了。3.2 一张功能风险评估表建立产品 AI 底账我在实际项目里常用的方法很简单做一张表格把每个用到模型的模块都登记进去字段包括功能模块、模型用途、是否涉及个人信息、输出可验证性、影响级别、治理动作。表格的价值不只是记录更是逼着团队把隐藏的 AI 应用全部翻出来。曾经有位开发者跟我一起梳理他的数据分析平台翻了一遍才发现某个图表自动解读功能也在偷偷调用大模型给用户输出分析结论而界面上没有任何提示。这个功能上线已经几个月几乎没人注意到它的存在。如果没有这张表这类“影子 AI 功能”就会一直游离在治理范围之外。功能模块模型用途是否涉及个人信息输出可验证性影响级别需要落地的治理动作客服知识问答文本生成昵称、咨询记录可引用原文验证低界面披露 请求日志简历初筛分类打分完整简历解释性弱高人工复核 求职者告知会议纪要整理摘要生成会议内容部分可核对中AI 生成标识 用户确认商品评论情感分析文本分类无直接个人信息可对照原文低输出标签 抽检复核这张表不是一次做完就扔而是建议跟着产品迭代持续维护。每个新功能上线前先在表里登记一轮再决定需不需要额外治理动作。做久了你会发现团队对“AI 边界”的敏感度会明显提升很多风险在设计阶段就被摁住了。4. 数据流到 API 之外治理责任留在产品之内4.1 发送给模型服务商的数据仍是你需要负责的数据每次调用外部模型 API产品都会把一部分数据发送给第三方。很多团队只关心“接口通不通”“延迟高不高”很少认真核对发送出去的字段清单。直到需要回答用户的数据处理问题时才发现自己根本不清楚某次请求到底传了什么。尤其是产品面向欧盟用户时“用户数据流向哪里”会成为一个非常实际的产品问题。用户提交的内容、生成的结果、操作日志都可能经过外部模型接口。产品团队至少要做两件事第一检查发送的字段是否最小化能不能只传完成任务所必需的部分第二确认服务商对数据的留存和删除策略评估用户提出删除请求时产品能否响应。我见过一个智能翻译工具用户上传了一整份合同产品为了提取关键条款直接把完整文档发给了模型接口。而实际算法只需要合同里的几个段落。这就是典型的数据过度传输。如果用户问“你们和第三方共享了我的完整合同吗”产品只能回答“是”而这个“是”完全可以通过技术手段避免。4.2 数据最小化少传一个字就少一分风险数据最小化做起来并不复杂关键是产品开发时要有这个意识。给模型的输入最好经过一层预处理能抽摘要就不传全文能传字段就不传文档能脱敏就脱敏。比如邮箱、手机号、身份证这类信息绝大多数场景下根本不需要发给模型产品本地就能做脱敏或替换。更进一步产品可以设计一个“字段白名单”机制每次调用模型前自动检查传入参数是否在白名单里不在就直接拦截。这个机制本质上是一个技术护栏防止后加入的团队成员图省事把整份数据一股脑传上去。维护成本很低但对数据保护的提升非常明显。另外日志留存也是一个需要注意的平衡点。不要因为“留得越多越安全”就把完整输入输出都写进日志日志本身也会成为新的数据风险。常见的做法是只记录输入摘要、输出摘要、模型版本、请求时间、用户标识而不是把全文复制一份存起来。这样既支持排查和审计又不会额外堆积敏感数据。4.3 用户删除权不是一句空话要能真正执行用户的删除请求对 AI 产品来说是个麻烦事因为数据可能已经散落在多个环节产品数据库、日志系统、模型服务商的缓存。产品团队如果不在设计阶段考虑删除流程后面只能靠人工一封封邮件去协调。一个务实的做法是从产品设计之初就明确每个用户数据字段的存放位置和保留周期。用户发出删除请求后产品能在合理时间内清除自己侧的数据并向模型服务商发出同步删除指令。哪怕服务商的响应速度不如预期至少内部数据不会再成为隐患。这件事常见于隐私条款但实际执行必须依靠技术能力而不是一句承诺。5. 落地四件套披露、日志、复核、撤回5.1 用户披露不是免责声明而是要“看得见”产品在界面里标注 AI 参与这件事看上去只是一个文案改动实际设计起来比想象中更细。光是“怎么标”就有很多选择对话窗口旁边的角标、生成内容下方的水印、首次使用时的弹窗说明、设置页里的详细介绍。不同的产品形态适合不同的披露方式但原则是一致的——用户能明确知道自己在和 AI 打交道。我见过一种做得比较顺手的方案聊天机器人界面里每条由 AI 生成的消息下方都带一行小字“AI 生成请注意甄别”同时在用户第一次使用时弹出一条简短说明告诉用户这个产品集成了 AI 能力、会处理哪些信息、如何关闭 AI 功能。披露做得好用户信任度反而会上升并不会因为“用了 AI”就流失。5.2 日志别追求“大而全”要追求“查得到”AI 请求日志的设计有个常见的两极分化要么完全不记出了问题两眼一抹黑要么什么都记把敏感数据也存了一大堆。两个极端都不可取。合理的方案是记录这样几个字段请求时间、用户标识、功能模块、模型服务商、模型版本、输入摘要、输出摘要、处理状态、人工复核状态。这里强调“摘要”而不是“全文”是因为大多数排查场景只需要知道“这条输出是哪个版本模型生成的”“当时输入大概是哪些内容”。真正需要检查完整输入输出时可以临时按需取用而不是默认全部落盘。这样既能满足可追溯性又不会让日志系统成为新的数据泄露风险点。5.3 高风险功能必须有“人”兜底对于影响用户切身利益的功能人工复核是一条不能省的流程。技术上的做法是设置置信度阈值模型输出低于一定置信度时不直接展示给用户而是进入“待复核队列”由人工处理。这样既不会因为误杀导致功能瘫痪又避免了高风险场景下完全交给机器的风险。我见过一个简历筛选系统AI 给出的建议分低于阈值时界面直接显示“该候选简历建议人工评估”后台管理员可以看到模型判断依据和原始简历。这个设计让系统既能提效又有明确的责任人。做产品时不要迷信“全自动”该让人介入的地方就得留入口。5.4 出了事能喊停撤回机制是最后一道防线模型输出不可能保证百分百正确产品必须有快速“喊停”的能力。喊停包括两个层面一是功能层面能立刻关闭某个 AI 接口的调用二是内容层面能把已推送给用户的问题内容撤回或标记。最实在的做法是为每个 AI 功能设计独立的开关和版本号。出问题时运维人员可以只关掉出问题的那个功能而不是把整个服务停掉。同时后台要能根据日志 ID 快速定位受影响用户范围并支持批量撤回或添加更正说明。不要小看这条能力很多小团队在出事故时才发现自己连“哪些用户受影响”都查不出来。6. 常见误区速查这些想法我都踩过6.1 “模型服务商在海外管不到我”为什么错这个误区的根源是把“责任主体”混淆成“管辖地点”。如果你的产品面向欧盟用户提供服务那产品本身就在这套治理框架的影响范围内第三方模型服务商的地点在评价责任链时不作为决定性的单点因素。简单说用户和你的产品交易不是和模型服务商交易。我理解很多人觉得这种事离自己很远尤其团队规模不大的时候很难重视一个还没发生的“远期风险”。但产品在功能设计中留下合规痕迹的成本是递增的越早期做越便宜越后期做越痛苦。与其等到合作方发来问卷再补不如现在就把日志和数据台账建起来。6.2 “服务商有资质等于我合规”为什么不成立另一个常见认知是“我用的 API 来自大厂它的安全资质很全所以我不用操心”。这个想法错在把“供应链合规”当成了“产品合规”。模型服务商提供的安全能力只能证明模型本身经过了基本评估不能替代你对具体产品场景的判断。举个简单的例子服务商可以保证模型接口传输加密、数据不用于训练但它无法知道你产品里的用户提示词会不会诱导模型输出错误建议也无法替你判断“简历评分”这个功能需不需要人工复核。这些产品级的判断只能自己来做。6.3 上线前自查十连问我在帮团队做治理底账时习惯把问题收敛成一张速查表每次新功能上线前过一遍这个产品功能在哪个模块用了模型模型输出会被用在什么场景用户会据此做什么决策错误输出会造成什么影响影响面有多大用户知道某部分内容或建议来自 AI 吗每个 AI 请求都有对应的日志 ID 吗高风险场景下是否有明确的人工复核流程发给模型的字段是不是已经做最小化处理用户申请删除数据时产品能执行到什么程度模型版本升级时团队内部是否留有记录发现严重错误输出时产品能否快速撤回相关内容这些问题没有标准答案但每个问题都能帮你找到产品里的薄弱环节。我自己的经验是只要把十连问从头到尾过一遍几乎百分之百能翻出至少一两个之前没注意到的漏洞。7. 落到团队日常而不是变成一次性运动说实话AI 治理这件事最怕“一次性完成”的错觉。很多团队冲着一股劲把风险评估做完了然后把文档扔进共享盘再也不管。但产品在变、模型在变、数据流在变治理必须是持续动作。我建议把治理动作嵌进现有的研发流程而不是另起一套流程。功能评审时多问一句“这里用模型了吗”发布清单里多加一步“AI 日志检查”测试用例里多写一条“错误输出撤回演练”。这些改动分摊到每个迭代里成本几乎可以忽略但效果比半年一次的大检查好得多。我个人在实际操作中的体会是做 AI 治理不需要等法务介入产品和技术团队完全可以先动手。哪怕只是先建一张功能风险评估表、给每个 AI 请求加上日志 ID就已经走在了正确方向上。随着产品越做越复杂这些基础工作会成为你回答用户、应对合作方、甚至应对监管时的底气。最后分享一个小技巧把这份治理清单固化在研发流程的“发布检查项”里每次发版前让负责人逐项勾选。不用写长篇文档一个复选框就能让整个团队保持对 AI 责任边界的敏感度。时间久了大家自然会形成“先想清楚用途和后果再接入模型”的产品习惯。