模型卡（model card）是一件研究产物。而数据表（datasheet）是一份合同。采购团队通常会像阅读后者一样阅读前者，而交付它的 AI 厂商现在正受限于其工程团队原以为只是叙述性的声明。
这是丢掉续约最干脆利落的方式：你转发了发布在模型索引页上的同一个 PDF，客户的法务团队将其中四句话摘录到了附件 B（Schedule B）中，十二个月后你发现“预期用途：通用问答”已变成关于服务范围的合同陈述。你的团队用 BLEU 分值来衡量这些句子，而他们的团队现在正用违约代价来衡量。
错误不在于模型卡写错了。在编写的那一刻，它几乎肯定是准确的。错误在于两种不同的专业文化在阅读同一份文档时，对“一个句子是什么”有着两种截然不同的看法。研究人员编写模型卡是为了告知下游关于行为的决策。采购评审人员则将任何厂商提供的文档视为承诺界面——在未经协商修改之前，每一项声明都是一个条款。双方都没有注意到体裁上的错配，因为在页面上，这份产物看起来确实像文档。
为什么模型卡不适合交给采购部门
模型卡在 2018 年被提出，作为机器学习社区的一种透明度工具。最初的构想非常明确：模型卡的存在是为了让决定是否部署模型的从业者了解模型的优缺点、评估所用的人群，以及作者预期模型会失效的地方。该文档是一种研究规范，而非厂商陈述，其受众被假定为具备足够技术背景，能将“预期用途”理解为作者对行为的思考，而非厂商承诺提供的服务。
这种构想在接触到企业销售时土崩瓦解。一旦模型卡成为厂商对安全调查表回复的一部分，受众就变了。现在的读者是拿着检查清单的第三方风险评审员、拿着模板的采购官，或者——最危险的——按小时计费专门寻找约束性语言的客户外部法律顾问。他们中没有一个人会像作者预期的那样阅读模型卡。他们像阅读任何其他厂商文档一样阅读它：作为一种陈述，如果被附加到主协议中或被主协议引用，它就具有法律效力。
这种体裁错配之所以重要，是因为编写模型卡的初衷是诚实地披露局限性，而不是为了精确地限制责任。模型卡中的“局限性”是研究披露。而厂商合同中的“局限性”则是除外条款。同一个词承担着两种不同的功能，而从未见过模型卡的采购评审员每次都会默认采用第二种理解。
你在不经意间做出的合同承诺
浏览一份典型的模型卡，问问哪些句子会被采购评审员标记出来。这份清单会让你感到不安。
“预期用途”被解读为服务范围。如果模型卡上写着该模型旨在用于英语问答，下游客户可能会辩称，你已经陈述了其对该用途的适用性——而除此之外的不适用性就成了你需要去声明免责的问题，而不是他们需要承担的风险。“训练数据”被解读为数据来源，这涉及版权赔偿，而你的工程团队并不会追踪这些内容。“评估结果”被解读为性能陈述，在任何传统的厂商合同中，这都会受到 SLA 的限制并有相应的信用赔付。你的模型卡两者都没有。“已知局限性”被解读为你已经承认模型会出错的清单，客户的法律顾问会将其视为你对风险的承认以及你监控的义务。
这些解读都不是作者的本意。但对于一个从工程文化跨越到采购文化且没有翻译层的文档来说，这些解读都是合理的。模型卡的编写是为了告知研究人员关于行为的信息。而合同现在的编写则是针对模型卡的。两个团队都没有为这种交接做设计，且两个团队都会在各自的文档上签字，而没有意识到他们已经束缚了对方。
最令人痛苦的版本是基准测试结果。三月份发布的一份列出某项评估套件得分为 92% 的模型卡，到了十二月份就不再是同一个产物了——模型已经重新训练了两次，基准测试也更新了，得分不再具有可重复性。但合同仍然引用最初的模型卡，客户仍然基于一个从未打算作为保证的数字在运作。当他们的审计员要求提供你达到所述性能的证据时，工程团队诚实的回答——“我们在六个月前就更换了那个评估指标”——听起来就像是在逃避。
双交付物规范
解决方法是停止让研究交付物承担合同职能，并将合同性质的工作作为一份独立文档来编写。
一份技术模型卡（Model Card）应留在它该在的地方：放在模型索引中，置于开发者门户之后，以构建该模型的团队口吻编写。它为工程受众描述行为、局限性、评估方法、训练数据摘要以及已知的失败模式。它的职责是帮助下游开发者做出正确的集成决策。它被允许诚实地反映局限性，因为它的读者知道如何阅读研究性文章。
一份独立的供应商尽职调查包才是提交给采购部门的交付物。其中的声明由法务编写或由法务共同编写。其中的每一项承诺都有明确定义的范围、通知机制、补救路径，并在适当情况下设有责任上限。它解决了采购评审人员真正关心的问题：数据保留窗口、处理区域、审计权、子处理者名单、安全认证、弃用通知期、事件通知 SLA，以及包括输出内容在内的补偿范围和退出协助。除非基准测试分数配有保证达标的条件以及未达标时的补救措施，否则它不应包含这些分数。
这两份交付物在设计上存在重叠。尽职调查包可以引用技术模型卡，就像规格说明书（Datasheet）引用应用说明（Application Note）一样：提供有用的背景信息，而非合同约束面。但是，采购部门签字认可的文档必须以采购部门习惯的文体编写。你不能把一份研究交付物丢进合同谈判中并称之为文档；你提交的是合同交付物，并称之为合同。
弥合差距的模式 一旦你接受了双交付物规范，就有三种运营模式值得实施。
第一，建立面向客户的文档层级，将“模型如何表现”与“供应商承诺什么”区分开。这主要是一个发布环节的变更。技术模型卡位于一个 URL 下，并带有页眉说明其仅描述行为而非合同范围的陈述。尽职调查包位于另一个需要客户登录的 URL 下，并随合同条款进行版本化，它是采购部门在谈判中唯一应该参考的文档。当客户索要“模型卡”时，询问他们实际需要哪种交付物，并将其引导至正确的位置。
第二，针对任何进入采购渠道的工程声明建立审批流程。如果销售人员准备在 RFP（招标书）响应中包含基准测试数据，这些数字必须经过审核，由法务提出两个问题：这在今天是否依然属实，以及我们是否愿意为此提供担保。任何一个问题的答案都可能是“否”。这两个答案共同决定了最终发送的内容。建立该流程是因为失败模式并非工程部门写了虚假信息，而是工程部门以一种法务会用不同方式表达的语调写了真实信息。
第三，在尽职调查包中制定明确的召回和通知协议。Anthropic 为退役模型发布了 60 天的弃用窗口期。Microsoft 承诺预览模型升级会有 30 天通知期，在宣布官方替代方案前会有大约 90 到 120 天。OpenAI 会发布停用日期。这些供应商学会了发布通知期，是因为如果不明示截止日期，客户就会推断出无限期的支持。你的尽职调查包应该以书面形式明确规定这段期限，以及发送通知的渠道。从“我们最终会弃用这个模型”到“我们将在弃用日期前 N 天通过书面形式通知你，并提供记录在案的迁移路径”之间的差距，就是研究交付物与合同交付物之间的差距，而这一差距正日益成为客户续约的关键。
文档失效背后的组织失效 这种情况不断发生的原因是：AI 团队编写模型卡，法务团队编写合同，而双方团队在客户采购团队将两者绑定到同一份文档之前，都没有阅读过对方承诺了什么。
AI 团队编写模型卡是因为他们拥有模型。法务团队编写合同是因为他们负责企业条款。客户的采购团队是第一个同时持有这两份文档的读者，他们在没有提醒任何一方的情况下就把它们钉在了一起。当供应商方面的任何人注意到模型卡中的一句话现在被列入附件 B 时，合同已经签署，客户已经开始运行，此时撤销该引用的代价比履行它的代价还要高。
结构性的解决办法是，任何通过采购渠道离开工程部门的交付物都需要一个共同负责人（Co-owner）。他不是一个随便扫一眼问题的评审员，而是一个名字出现在文档上、职责是像采购评审员一样阅读文档的共同负责人。这个角色可以设在法务部、方案工程部、客户信任部，或专门的 AI 治理职能部门；头衔并不重要，重要的是这一原则：该文档必须有人负责以接收者的文体进行阅读。如果没有这个角色，你就是在将合同起草工作外包给编写模型卡的人，而那个人并没有打算起草合同。
欧盟《AI 法案》中的价值链条款使得这种组织失效的代价更加高昂。第 25 条规定了提供者与供应组件的各方之间应达成书面协议，其中明确了合规所需的必要信息、能力和技术访问权限。其隐含的假设是，供应商和部署者将提前以书面形式清晰地分配义务。因意外而演变为合同的模型卡与提前分配义务背道而驰；它是意外分配。阅读这些合同的监管机构不会同情那些将研究披露内容被他人变成合同条款的供应商。
工程领导者实际上需要做些什么 如果你领导一支向企业客户交付模型的工程团队，其实际意义非常明确。
停止向采购团队发送模型卡 (model cards)。发送尽职调查包 (due-diligence package)。如果你还没有尽职调查包，在下一次企业销售之前建立一个，而不是在销售之后。与法务部门共同编写；不要让工程团队单独编写，也不要让法务部门在没有模型团队参与的情况下编写。将其版本与合同挂钩，而不是与模型挂钩，因为采购审核人员是根据他们签署的协议来跟踪版本的，而不是根据你的仓库 (registry) 跟踪的制品。
审计你的销售团队目前正在转发的内容。如果模型卡被粘贴到 RFP (征求建议书) 回复中，或者附在安全问卷中，那就是产生体裁错位的地方。将这些引用替换为尽职调查包，并相应地更新预设的 RFP 回复。如果客户的审核人员明确要求提供“模型卡”，请询问他们想要核实什么，并提供适合该核实的制品，而不是研究用的那个。
将模型卡本身视为一个研究制品，并保持其诚实性。诚实编写——包括局限性和已知失效模式——的约束，对于工程和研究端的消费者来说确实非常有价值。不要为了让采购人员读起来更“安全”而对其进行注水；这会损害它的实际作用。相反，要确保采购人员阅读的是最初专门为他们编写的文件。
架构层面的认识很简单，但也让人略感不适：任何从工程文化跨越到采购文化的制品，都必须为目的地编写，而不是源头。模型卡是为工程师编写的研究制品。供应商承诺书是为采购编写的合同制品。它们不是同一份文件，也不应该是同一份文件。如果团队允许它们混为一谈，那么在最糟糕的情况下，你将会发现这种区别——比如在续约谈判中，你坐在客户对面，而对方的律师正在读着一张你的团队中从未有人打算将其作为合同使用的卡片。
余下内容仅对会员开放。 会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
— 完整文章，包含未公开存档的部分 — 可落地的工作框架，附带权衡与决策依据 — 新文章抢先看，先于公开发布 登录以继续阅读→ 随时取消 · 一次订阅，畅读全部
