AI 智能体合同签署：eIDAS QES 集成指南
AI 智能体可以起草合同并启动签署流程，但不应被当作 QES 签署人。可靠的生产模式是两阶段提交：智能体提出不可变文件，策略服务判断所需批准，获授权人员审阅精确 payload，系统验证返回签名后，才让合同、付款或账户状态生效。
本文面向产品、工程、安全与采购团队，明确区分登录、同意、合格电子签名、电子印章与审计日志。本文提供技术和商业参考，不构成法律意见。关于 selective disclosure、SD-JWT VC、mdoc 与零知识取舍，请阅读零知识证明生产指南。本文聚焦下一步：如何把真人决定绑定到智能体准备的那份文件。
需要为智能体工作流加入可验证批准吗？
规划签署架构AI 智能体能在欧盟合法签署合同吗？
不要把智能体建模为 QES 自然人签署人。合格电子签名由自然人创建。根据合并版 eIDAS 法规第 25 条，QES 在欧盟具有与手写签名相同的法律效力。智能体可以准备数据、计算摘要并发起请求，但真人明确授权仍是信任边界。
EUDI Wallet 必须默认向自然人提供 QES 能力。免费使用可以限于非职业用途，因此企业流程仍需为签名服务、注册与验证制定商业和技术方案。依据见欧盟法规 2024/1183。
法人使用另一种机制：电子印章。欧盟委员会的eSignature FAQ区分自然人签名与法人印章。合格印章证明来源与完整性，并不自动表达代表人的同意。自动盖章必须置于内部授权控制之后。
ID Austria、Handy-Signatur、EUDI Wallet 与 QES 不是同义词
| 能力 | 证明什么 | 正确用途 |
|---|---|---|
| ID Austria 或 EUDI 登录 | 用户以可接受的电子身份完成认证。 | 建立会话。不要把登录回调当作合同批准。 |
| QES | 自然人以合格方式签署了精确数据。 | 在法律与风险分析选择 QES 时，对经审阅且不可变的 payload 使用。 |
| 合格电子印章 | 法人文件的来源与完整性。 | 用于受控的企业文件签发，授权与发布策略留在智能体之外。 |
| 智能体审计记录 | 模型、工具、策略与人员做过什么。 | 属于运营证据，不能替代 QES、印章或身份。 |
Handy-Signatur 已是旧称。ID Austria 官方说明确认 ID Austria 已取代它，并分别支持登录与合格签署。ID Austria OpenID Connect 文档覆盖身份认证。OIDC 成功响应不会把用户绑定到某个合同版本。
参考架构：提出、批准、验证、执行
- 智能体提出。模型生成结构化合同数据与草稿，但不能自行选择签署人或降低批准策略。
- 应用冻结文件。渲染最终 PDF、XML 或规范数据，进行不可变保存，并在可信服务端计算摘要。任何修改都产生新版本与新批准。
- 策略服务授权。实时解析人员、组织、授权范围、金额限制、合同类别与职责分离。授权缺失时关闭失败。
- 真人审阅。展示完整文档、对手方、金额、期限、不可逆后果与摘要绑定版本。智能体摘要只能作为辅助。
- QTSP 或钱包签署。使用短时有效的一次性请求，并把 return state 绑定到同一交易。
- 验证器检查。验证字节、证书资格、信任链、吊销证据、时间、格式、摘要与签署人。成功 webhook 不等于验证成功。
- 应用只执行一次。通过幂等 outbox 触发下游动作。重复回调不能产生第二次效果。
- 归档保留证据。保存签署文件、验证报告、草稿、授权快照、策略版本、批准事件、服务商 ID 与智能体 trace。
欧盟委员会的EUDI Wallet eSignature 手册描述了钱包驱动与 QTSP 驱动的 QES 流程。两种模式都由用户审阅并批准，再由合格设备创建签名。因此钱包应位于授权边界，而不是智能体的工具循环中。
服务商中立的签署请求
{
"idempotency_key": "contract:847:version:7",
"artifact_sha256": "8c4f...",
"artifact_version": 7,
"intended_signer": "person_219",
"represented_organisation": "org_44",
"purpose": "接受供应商合同第 7 版",
"signature_level": "QES",
"policy_version": "contract-signing/12",
"expires_at": "2026-08-13T15:30:00Z"
}采用 DRAFT -> FROZEN -> AWAITING_APPROVAL -> SIGNING -> VALIDATING -> EFFECTIVE，并设置 REJECTED、EXPIRED 与 FAILED 终态。只有验证器能进入 EFFECTIVE。EUDI Architecture and Reference Framework 1.5.1定义 Remote Signing Interface。保持领域模型稳定，把变化中的互操作细节隔离在适配器中。
EUDI 参考实现包含移动端 rQES 库、CSC API 组件与 RP-centric 签署应用。它们能加速互操作测试，但不能替代服务商资格审查、威胁建模与独立验证。
签名本身不能解决的风险
- 批准后发生 prompt injection：冻结字节，并把请求绑定到摘要。
- 签署人没有权限：执行时从可信来源重新解析授权。
- 用户只看摘要：展示完整文件与关键商业后果。
- 回调重放：使用 nonce、过期时间、幂等键、事件 ID 与 compare-and-set。
- 服务商误报成功：业务生效前独立验证签名。
- 批准疲劳：只升级不可逆或策略触发动作，并展示 diff。
验证不能依赖上线时复制的一份证书列表。奥地利监管机构说明其受监管信任列表如何接入成员国体系。生产系统应使用持续维护的 EU Trusted Lists 处理，并保存签署时使用的验证证据。
Build vs buy：采购信任服务，自建控制平面
不要把自建 QTSP、证书机构或 QSCD 当作普通产品功能。采购合格信任服务，自建合同版本、智能体权限、授权解析、批准 UX、策略判断、幂等执行、证据保留与运营报告。
选型时检查国家与身份覆盖、PAdES/XAdES/CAdES/ASiC、一次性或长期凭证、remote QES、Web 与 App handoff、签名且防重放的 webhook、验证报告、吊销与时间戳、恢复流程、职业用途成本，以及未来 EUDI Wallet 适配。衡量每份生效协议的成本，而不是每次 API 调用成本。AI 智能体 SLA 模板可把批准、验证与审计证据变成可测量承诺。
QES 不会让 AI 系统自动合规
有效签名只证明特定信任服务结果，不能证明模型准确、代表权有效、合同公平、数据处理合法或符合行业规则。若 EU AI Act 的高风险义务适用，第 12 条与第 14 条涉及日志和人工监督。QES 是系统中的一项控制，不是合规捷径。
Authentication 回答谁在场，Authorization 回答此人现在能做什么，Signature 回答批准了哪些精确数据，Validation 回答信任结果是否有效，Execution 回答效果是否只发生一次。一个 approved 布尔值承载不了这五个边界。
"智能体撰写提案，真人批准不可变 payload，验证器检查签名，应用只执行一次。四个责任主体让信任边界清晰可见。"
AI 智能体与 eIDAS 签名常见问题
AI 智能体能创建 QES 吗？
ID Austria 登录等于合同签署吗？
ID Austria 是否取代了 Handy-Signatur？
QES 与电子印章有何区别？
如何把人工批准绑定到合同？
团队应该自建 eIDAS 签署服务吗？
最终思考
安全架构应当刻意保持简单。智能体起草，应用冻结并计算哈希，策略服务解析权限，真人批准确切效果，验证器检查当前信任证据，之后幂等交易才生效。
把登录、签名、印章、验证和执行保持为不同状态。采购合格信任服务，把工程投入用于保护真实商业承诺的控制平面。
研究来源
研究与核查日期为 2026 年 8 月 13 日。请核对最新来源，并为具体交易获取法律意见。