业务方与模型供应商如何分摊AI事故责任?

最近在公司内部聊AI合规的时候，我最烦大家老问“合规要花多少钱”这种问题。真正有用的问法是：这个AI功能到底落在业务哪一层，它在替谁做决定，出问题后谁来解释、谁来纠正？

我自己去年带团队用AI做客户推荐系统，结果出了个大事故。用户投诉说推荐的商品太偏，订单量直线下降。明明是业务方我定了“销量优先”的目标，AI模型也只是提供参考，我这个业务方得先扛起大半责任。模型供应商那边虽然提供了底座，但他们没见过我手里的真实用户数据流，也没控制我怎么把提示词写成“确定结论”。我得自己掏钱修补用户关系，供应商也得配合解释和更新版本。分摊责任这事儿，从来不是一拍两散，而是看谁真正握着控制权。

欧盟、美国和中国这边的治理思路完全不一样。欧盟靠《人工智能法案》分级落地，通用模型和特定高风险系统义务天差地别，企业得先认清自己在业务里扮演什么角色。美国的政策重创新，州里还有隐私保护和行业监管，联邦跟地方怎么切分规则，大家还在摸索。中国的治理更讲究场景化处理，从生成内容标识到数据使用，一环扣一环，不能只盯“AI专门规则”，还得往业务链里一条条核对。

不管哪边，模型供应商不可能把所有AI事故责任都甩给业务方。业务方却也不能把一切都推给模型——提示词怎么写、数据怎么接入、是否自动采纳输出、用户能不能申诉，这些我全能决定。合同里可以约定测试和通知义务，但最终面向用户或监管的责任，还是要看具体场景。

把钱全塞进“法务”或“模型采购”都太简单粗暴。我更喜欢按风险产生和控制的位置分账。模型层得问供应商提供了什么证据，版本变了测试还算不算；数据层得核对哪些信息进了训练或检索，谁有权删；应用层得看输出怎么影响实际决定，上线前谁批准，异常后谁处理。

我现在在团队里推“敏捷治理”流程：先建个AI使用台账，记录每个系统用途、目标市场、数据流向和人工介入方式。再按影响程度决定审查深度。内部辅助工具可以轻描淡写，影响招聘或对外服务的系统就得留足测试和纠错痕迹。上线不是结束，模型更新、数据来源或业务场景一变，就得触发复核。

资源有限的企业别追求面面俱到，但也不能因为叫“试点”就忽略它会不会真影响用户。文档再齐全，如果没人能暂停系统、解释一次决定或接收用户反馈，治理就还是纸上谈兵。预算决策得从业务场景倒推，先把钱和精力投到自己能控制、也最需要证明审慎义务的地方。

具体法定义务还是得按经营地、行业、系统用途和主体身份核对，上面这些只是我团队的内部打法，落地时还得找专业律师把关。