保修难题：当你的 AI 功能出错时，谁来买单？

每一份软件保修条款都假设了确定性行为。你交付一个函数，相同的输入返回相同的输出，而保修覆盖的是文档描述的行为与实际行为之间的差距。AI 功能彻底打破了这一假设。

当你的 LLM 驱动功能告诉客户错误的信息——而这个错误信息让他们蒙受了经济损失——传统的保修条款让所有人都在互相指责。

这不是假设场景。2020 年至 2025 年间，美国累计的生成式 AI 诉讼案件已超过 700 起，同比增长率高达 137%。管理软件责任的法律基础设施是为确定性世界构建的，而这种不匹配已经在造成真实损失。

加拿大航空先例：你对聊天机器人的承诺负责

这个让每个产品团队都开始关注的案例发生在 2024 年 2 月。Jake Moffatt 向加拿大航空的聊天机器人询问丧亲票价。聊天机器人告诉他可以先购买全价机票，然后再申请丧亲折扣。这是错误的——加拿大航空的实际政策明确排除了追溯申请。

当 Moffatt 要求部分退款时，加拿大航空拒绝了。然后他们提出了一个应该让每家部署 AI 功能的公司都感到担忧的论点：他们声称聊天机器人是一个"独立的法律实体"，应该对自己的行为负责。不列颠哥伦比亚省民事解决仲裁庭完全驳回了这一论点——加拿大航空对其网站上的所有信息负责，无论是来自静态页面还是聊天机器人。该航空公司赔偿了 812 美元，金额虽小，但确立了一个重大原则。

如果你部署的 AI 系统向客户做出了声明，那些声明就是你的声明。模型的非确定性本质不能作为辩护理由。你没有编写那些具体的文字也不能作为辩护理由。是你选择将系统放在客户面前的，你就要对它所说的话负责。

为什么"AI 生成——请独立验证"无法保护你

AI 功能最常见的风险缓解策略是免责声明："此内容由 AI 生成，请独立验证。"在非监管的消费者场景中，这可能会降低一些风险敞口。但在受监管行业中，这在法律上是不充分的——而且在其他领域也越来越不够用。

看看监管格局：

• 医疗健康：加州的 AB 3030 法案要求使用生成式 AI 进行患者沟通的医疗服务提供者必须包含特定的免责声明以及联系人类医生的说明。但免责声明只是底线，而非上限——只有医生（而非 AI 系统）可以就医疗必要性做出最终决定。
• 金融服务：用于信用评分或风险评估的 AI 模型必须遵守《公平信用报告法》。免责声明并不能免除你的实质性合规义务。
• 销售和营销：FTC 要求所有声明——包括 AI 生成的声明——必须真实且不具有误导性。在你的 AI 编造的产品推荐上贴一个免责声明并不能满足这一要求。

模式很清晰：监管机构将免责声明视为最低披露义务，而非责任保护盾。实质性的注意义务仍然在部署者身上。你不能将专业判断外包给语言模型，然后对后果免责。

这在实践中很重要，因为许多团队将免责声明视为责任分析的终点。它应该是起点。

没人谈论的保险缺口

这是一个应该让每个正在交付 AI 功能的工程领导者感到警觉的事实：你公司现有的保险政策很可能不覆盖 AI 特有的责任。

传统的错误与遗漏（E&O）保险和一般责任保险是为确定性软件故障编写的——bug、宕机、数据泄露。它们通常不覆盖：

• AI 幻觉导致的经济损失
• 生成内容的知识产权侵权
• AI 输出造成的诽谤或错误信息
• 因 AI 生成建议引起的专业渎职索赔

这个问题正在恶化，而非好转。2026 年 1 月，Verisk 发布了专门针对生成式 AI 的新一般责任排除条款。2026 年第一和第二季度续保的保单是首批纳入这些排除条款的保单。如果你的公司最近续保了一般责任保险，请检查它是否现在明确排除了 AI 相关索赔。

保险行业将此称为"沉默 AI"——既未明确包含也未明确排除在现有保单中的 AI 风险敞口。当索赔发生时，双方争论是否适用保险覆盖，而投保人通常是输家。

一些专门的 AI 保险产品正在出现。由 Chaucer 和 Axis Capital 支持的 Armilla 在 2025 年推出了需要持续模型质量评估的保险。Testudo 于 2026 年 1 月推出了面向部署生成式 AI 的企业的索赔保险产品。但这些都是早期产品，记录有限，而且它们要求的模型监控和评估基础设施是大多数团队尚未建立的。

实际结论：在你交付一个向客户做出声明、推荐或决策的 AI 功能之前，请询问你的法律团队当前的保险是否覆盖故障模式。答案可能会改变你的风险考量。

合同条款仍在追赶

大多数 SaaS 协议是为确定性软件设计的。保修部分通常说产品将"与其文档实质性一致"地运行。这种语言对 AI 功能立即失效，因为输出是概率性的——相同的输入可以产生不同的输出，供应商和客户都无法完全预测系统会说什么。

AI 供应商以激进的免责声明作为回应。标准姿态通常是这样的："本服务按现状提供，包含所有缺陷。输出通过机器学习过程生成，未经提供商测试、验证、认可或保证其准确、完整或最新。"

这造成了一种奇怪的局面：供应商向你销售一个做出声明、推荐或决策的产品——同时免除了对这些输出正确性的所有保证。客户承担了他们无法控制的输出的所有风险。

市场开始反击。随着 AI 被嵌入核心业务流程，买家越来越多地拒绝无保证的姿态。我们看到越来越多的交易包含：

• 性能基准：AI 必须维持的可衡量的准确率阈值
• 基于结果的 SLA：与输出质量而非仅仅正常运行时间挂钩的服务水平
• 补救义务：当输出不达标时，供应商必须修复或补偿
• 审计权：客户可以检查模型行为和治理实践

对于自主 AI（即自主采取行动的系统），这种转变更加剧烈。Mayer Brown 2026 年 2 月的分析指出，自主 AI 合同正在完全超越传统 SaaS 模型，融入了业务流程外包（BPO）协议的要素：服务定义、更广泛的赔偿以及承认 AI 正在行动而非仅仅计算的治理框架。

如果你正在将 AI 供应商集成到你的产品中，你的合同应该反映当 AI 出错时谁承担风险。如果合同说"按现状"而你将这些输出放在客户面前，你就接受了所有责任而没有任何控制权。

联邦层面的回应：AI LEAD 法案

这一监管空白在联邦层面也没有被忽视。2025 年 9 月，参议员 Durbin 和 Hawley 提出了第 2937 号参议院法案，即"AI LEAD 法案"，该法案将针对 AI 系统的开发者和部署者创建联邦产品责任诉因。

拟议的责任框架涵盖：

• 设计缺陷：AI 系统的设计存在不合理的危险
• 警告不足：对已知限制或风险的披露不充分
• 违反明示保证：系统未按描述执行
• 部署缺陷：交付时存在不合理的危险条件

在州级层面，仅 2025 年立法会议期间就提出了超过 1,000 项与 AI 相关的法案。各州正在根据 AI 专项法规授权私人诉权，创建两年前还不存在的新型责任途径。

方向很明确：立法正在朝着将 AI 系统更像产品而非服务的方向发展，并附带相应的产品责任义务。"这只是软件"的辩护理由保质期有限。

工程团队现在应该做什么

保修问题不仅仅是法律问题——它是工程问题。你在监控、评估和护栏方面做出的决策直接决定了公司的责任风险敞口。以下是关键要点：

在交付之前构建评估基础设施。 如果你无法持续衡量 AI 功能的准确性，你就无法设定保修阈值，无法证明合规性，也无法抗辩索赔。这不是可选的监控——它是你法律辩护的基础。

按责任风险对输出进行分类。 建议博客标题的 AI 与提供医疗计费代码的 AI 有着不同的风险特征。你的护栏、监控和人工审核要求应该随着出错成本的增加而扩展。

在系统边界将 AI 输出视为不可信输入。 就像你不会信任 Web 表单中的用户输入一样，当模型输出流入面向客户的界面、财务计算或合同承诺时，不要信任它们。验证、约束和审计。

现在就与法律团队合作制定合同条款。 如果你正在从供应商购买 AI，推动性能保证条款。如果你正在销售 AI 功能，了解你通过将输出放在客户面前隐含地保证了什么。"按现状"的免责声明可能无法经受住下一波立法的考验。

检查你的保险。 这是与你的保险经纪人进行五分钟对话就能为公司节省数百万的事情。具体询问当前保单中的 AI 排除条款，以及是否需要专业保险。

AI 功能的保修问题是客户合理期望与法律框架当前保障之间的差距。这个差距正在通过诉讼、立法和市场压力而缩小。现在就为问责制做好准备的团队将比那些等待诉讼来迫使行动的团队拥有显著优势。