AI 代理能签署合同吗？可以，自 2000 年起。但事情没那么简单

AI能签署合同吗?能。美国法律自2000年起就承认由机器达成的合同,毕竟AI代理给人的感觉如此新兴。UETA已被49个州采纳,其第14条规定:即便没有人类审核每一步骤,合同也可以通过"电子代理人"的交互而成立。

联邦ESIGN法案(15 U.S.C. § 7001(h))用几乎相同的措辞给予支持。这两部法律起草时,立法者想的是EDI系统和库存达阈值就自动确认订单的电商机器人,而非GPT-5或Claude。但法规不会因技术变复杂而失效,只会持续适用:25年前的答案正悄然解决2026年的问题,而网上争论"AI合同"的人几乎没人意识到这条法规早已存在。

真正重要的并非"机器能否达成合同",这一点已有定论。真正悬而未决的问题是:*出问题时谁将承担法律责任*,以及*代理究竟拥有什么授权*。这属于代理法,而非合同成立法,是完全不同、更古老的理论。搞混这一区别,你要么过度信任从未获授权签约的代理,要么因法律早已解决的模糊不安而弃用一项本可合法使用的能力。

若想深入了解电子签名如何具备法律效力,我们关于DocuSign是否具有法律效力的指南详解了适用于任何"点击签署"主体的四项基本条件(意图、同意、关联、保存)。

UETA对"电子代理人"的定义相当宽泛:用于发起操作、或响应电子记录的计算机程序或自动化手段,且操作发生时没有个人审核。用大白话讲:一种自主行动、事先没有人类复核该具体操作的软件。

根据UETA第14条,合同可以通过电子代理人之间的交互而成立,即便没有任何个人审核过这些代理人的行为或最终条款。该条款还涵盖混合情形:一个电子代理人与一名明知自己行为将促成合同成立的真人交互。若想核对确切法条,可查阅Uniform Law Commission提供的UETA全文。

ESIGN第7001(h)节在联邦层面承担同样职责,以应对交易跨州、或落在尚未采纳UETA的地区(纽约州运行着自己的州电子签名法)。若想直接核对条文,ESIGN法案原文见Congress.gov。

实践层面:若AI代理填写模板、套用预设条款并发送接受确认,由此形成的合同不会仅因没有人类盯着那次点击而无效——成立问题已经解决,"是机器人做的"这种说法在2001年前后就已失效。

但这不意味着:任何人部署的任何代理都自动获得授权,可代表公司同意其达成的一切条款。这是独立的问题,也是真正值得关注的问题。

这属于代理法范畴,比计算机早几个世纪,回答的是:一方的行为何时会在法律上约束另一方?把"员工"换成"AI代理",大部分分析框架依然成立。

本人——你或你的公司——在代理人的实际授权范围内担责:你实际告知代理人可以做什么,例如仅签署$5,000以下的供应商合同、向新联系人发送保密协议、未经人工审核绝不承诺付款条款。

接下来是表见授权,最容易栽跟头。即便代理人超出指示范围,只要本人自身行为让对方合理相信代理人拥有该授权,本人仍可能担责。若AI代理已连续六个月自动签署$50,000的供应商交易而无人反对,法院不会在意你内部上限是$5,000——你已用自身行为制造出更大授权的表象。

第三项是追认。即便代理人超越授权,只要本人事后知情接受了该行为的利益,仍可能担责。默默留下货物,或继续履行你声称未经授权的合同,在法院看来很像接受。

这些都不是AI特有的规则,而是一个世纪以来规范员工代表公司签约的框架。新颖之处在于AI代理生成授权相关行为的速度远快于人类员工。

有必要在此坦诚说明:法院目前尚未有太多机会就LLM驱动的代理签署商业合同这类纠纷作出明确裁决。上述法律理论已经确立,历经数十年对人类和软件代理的检验。但法官如何将其套用到涉及自主LLM代理的具体事实情形,还是较新的问题,任何自称确切知道结果的人都是在猜测。框架本身是稳固的,但把它适用于这项具体技术的判例法仍在书写之中。

抛开猜测,实际情况是:AI代理与合同系统交互时,大多并非以戏剧化方式自主"签署"任何东西,而是通过API进行结构化、权限受限的工作,越来越多地通过模型上下文协议(MCP)完成。

一个现实工作流是:运行在Claude或ChatGPT内的AI代理调取合同模板,从对话或CRM记录填入对方名称和条款,准备好等待签署。根据配置,代理要么送人工审核签署,要么在预授权限度内(消费上限、模板清单、对方白名单)自行完成发送并跟踪。我们的电子签名API指南介绍了这类集成如何连接外部系统。

Chaindoc的MCP服务器就是具体的例子,而非假设。截至2026年年中它处于私测阶段,让Claude Desktop等助手能直接在对话中基于模板创建文档、发送签署请求并查询状态,用的是开发者已在用的同一套API集成层。我们对Chaindoc MCP服务器的深入解读说明了人工审批环节设在何处。

这一模式普遍适用:AI负责准备和常规执行,人类在关键节点保留授权决定权,审计轨迹记录谁执行了每个操作。我们的审计轨迹合规指南说明了合法轨迹需要什么,而代理驱动的工作流只会提高这个门槛,因为你不仅要证明谁签了字,还要证明哪个系统在何种授权下发起了请求。

这一切无需靠猜测解决。若你正在合同工作流附近部署AI代理,以下是实用清单,按团队最容易忽略的顺序排列。

1. 1
   部署前书面设定授权限度。明确界定代理人能做什么:金额上限、已批准合同类型、对方或模板ID白名单。模糊范围("处理常规供应商事务")正是日后表见授权纠纷的根源。
2. 2
   为超出预批准范围的事项设人工审批关卡。代理人可起草、填写、排队,超上限或不在模板清单的事项一律先转人工。仅此一条就能预防多数"等等,我们真同意过吗?"的事故。
3. 3
   完整、可导出的代理行为审计轨迹。不只是"3:42签署",而要记录哪个系统发起请求、依据什么授权、用了什么模板和条款、谁批准了最后一步。纠纷触及追认问题时,这份记录起决定性作用。
4. 4
   独立的完整性验证,而非仅靠内部日志。"代理执行了X操作"的私有数据库记录,可信度取决于该数据库本身。区块链锚定的文件哈希——Chaindoc为每份已签文件内置的机制——意味着完整性检查不会多年后只依赖某公司内部记录,无论签署者是人类还是获授权的代理。

跳过任何一条未必违法,机器达成合同本身合法,但你在积累日后要处理的风险,大概率会在纠纷发生时才去梳理,而那正是弄清代理究竟被授权做什么的最糟时机。

欧盟《AI法案》已于2024年8月生效,是针对AI系统的治理与风险分级框架,原始文本可通过EUR-Lex查阅。它将AI系统划分为不同风险等级,施加与之匹配的义务——透明度要求、人工监督规定、文档留存责任。

一个常被忽略的区别是:《AI法案》规范的是AI*系统*本身,而非它可能帮助生成的*合同*。它不触及合同成立规则,不取代UETA或ESIGN,也不改变代理人在授权范围内或超出授权行事时谁承担责任。欧盟合同有效性仍通过eIDAS和成员国合同法判定,与《AI法案》出现前的框架完全相同。

《AI法案》带来的新增内容是:若你处理合同的AI代理被归类为较高风险,会附加透明度、人工监督和风险文档义务,与上述合同法和代理法问题并存,而非取而代之。它是合规叠加,而非替代性法律体制。在欧盟运营应将其视为追加检查清单,而非替代品。

这是诚实的预测,而非笃定的结论:法律基础不会是瓶颈所在。UETA第14条和ESIGN第7001(h)节已解决成立问题,也没有明显压力要重新审视这段行之有效四分之一世纪、从未引发争议的条文。

未来几年的动向会发生在两方面。首先是围绕AI代理授权范围界定与审计轨迹的标准和最佳实践,很可能由保险承保方和采购团队率先推动,而非监管机构,因为正是他们需要为这类风险定价。其次,随着涉及LLM驱动代理的纠纷进入法院并依据既有代理框架获得裁决,判例法会缓慢积累,逐步缩小AI特定事实情形中表见授权问题的不确定性。

几乎可以确定不会发生的是:出台一部宣布"AI不能签署合同"的新法律。那艘船在2000年就已启航,无论网上争论此话题的多数人是否意识到这一点。