AI Agent Contract Signing: eIDAS QES Integration Guide

An AI agent can draft a contract and start a signing workflow, but it should not be treated as the qualified electronic signatory. The production pattern is a two-phase commit: the agent proposes an immutable artifact, a policy service decides whether a signature is required, an authorised person reviews and approves the exact payload, and the system verifies the returned signature before any contract, payment or account state becomes final.

This guide is for product, engineering, security and procurement teams integrating eIDAS signatures into agentic workflows. It explains the boundary between login, consent, qualified electronic signatures, electronic seals and audit logs. It is a technical and commercial guide, not legal advice. Counsel must decide which form requirements apply to each contract, country and sector.

The privacy-preserving credential problem is deliberately out of scope. For selective disclosure, SD-JWT VC, mdoc and zero-knowledge trade-offs, use our production guide to zero-knowledge proofs. This article owns the next step: how to bind a real person's decision to the exact document an agent prepared.

Can an AI agent legally sign a contract in the EU?

The useful engineering answer is no: do not model the agent as the human QES signatory. A qualified electronic signature is created by a natural person and, under Article 25 of the consolidated eIDAS Regulation, has the equivalent legal effect of a handwritten signature. An agent may prepare the data, calculate a digest, request approval and process the result. The person's explicit authorisation remains the trust boundary.

The revised framework requires EUDI Wallets to offer natural persons the ability to create QES by default. The free tier may be limited to non-professional use, so a business workflow still needs a commercial and technical plan for its signing service, enrolment and validation. The exact wording is in Regulation (EU) 2024/1183.

A legal person has a different primitive: the electronic seal. The European Commission's eSignature FAQ distinguishes a natural person's signature from a legal person's seal. A qualified seal supports origin and integrity. It does not by itself express a human representative's agreement. Automated sealing can be appropriate for company-issued records, but only behind internal authorisation controls.

ID Austria, Handy-Signatur, EUDI Wallet and QES are not synonyms

In Austria, Handy-Signatur is legacy terminology. The current ID Austria guidance says ID Austria replaced Handy-Signatur and supports both login and qualified electronic signing. Those are separate actions even when the same identity ecosystem appears in both journeys.

The distinction is visible in the integration surface. The official ID Austria OpenID Connect documentation covers authentication. A successful OIDC response tells your application who logged in under that flow. It does not bind that user to version 7 of a supplier agreement. The signing step must identify the artifact, display it for review and collect separate authorisation.

The reference architecture: propose, approve, verify, commit

1. Agent proposes. The model produces structured contract inputs and a human-readable draft. It cannot select its own signer, relax the approval policy or mark the transaction approved.
2. Application freezes the artifact. Render the final PDF, XML or canonical data, store it immutably and calculate the digest on a trusted server. Every later change creates a new version and a new approval request.
3. Policy engine authorises the request. Resolve the current person, organisation, mandate, amount limit, contract class, jurisdiction and segregation-of-duties rule. Fail closed when authority is missing or stale.
4. Human reviews the exact effect. Show the document, counterparty, amount, duration, irreversible effects and digest-linked version. The approval screen must not show only the agent's summary.
5. QTSP or wallet creates the signature. Redirect or deep-link the user to the qualified flow. Use a single-use request with a short expiry and a return state bound to the same transaction.
6. Verifier validates. Check the signed bytes, certificate qualification, trust chain, revocation evidence, signing time, format, digest and intended signatory. A success webhook alone is not validation.
7. Application commits once. Transition the contract to effective and trigger downstream work through an idempotent outbox. Duplicate callbacks must return the existing result, not execute the effect again.
8. Archive preserves evidence. Retain the signed artifact, validation report, original draft, signer and mandate snapshot, policy version, approval event, provider IDs and agent trace under the applicable retention rules.

The Commission's 2026 EUDI Wallet eSignature manual describes both wallet-driven and qualified-trust-provider-driven QES journeys. In both, the user reviews and approves while a qualified device creates the signature locally or remotely. That is why the wallet belongs at the authorisation boundary, not inside the agent's tool loop.

A provider-neutral signing request contract

Keep provider details behind an adapter. Your domain object should express the business commitment, not one vendor's redirect parameters.

{
  "request_id": "sigreq_01J...",
  "idempotency_key": "contract:847:version:7",
  "artifact_sha256": "8c4f...",
  "artifact_version": 7,
  "intended_signer": "person_219",
  "represented_organisation": "org_44",
  "purpose": "Accept supplier agreement version 7",
  "signature_level": "QES",
  "policy_version": "contract-signing/12",
  "expires_at": "2026-08-13T15:30:00Z"
}

Use an explicit state machine such as DRAFT -> FROZEN -> AWAITING_APPROVAL -> SIGNING -> VALIDATING -> EFFECTIVE, with terminal states for REJECTED, EXPIRED and FAILED. Only the verifier may enter EFFECTIVE. Editing an artifact after FROZEN creates a new request. A provider callback must match the request, state, nonce and artifact digest before processing.

The current EUDI Architecture and Reference Framework 1.5.1 defines a Remote Signing Interface between the wallet and a qualified signature or seal remote-creation provider. Treat that specification as an evolving interoperability boundary. Keep your policy, document lifecycle and audit model stable while adapters change.

Teams can test against the Commission's EUDI reference implementations, which include mobile rQES libraries, wallet-driven CSC API components and an RP-centric signing application. Reference code accelerates interoperability testing. It does not remove the need to qualify a provider, threat-model the product and validate the signed output.

Threats the signature alone does not solve

Validation must follow the trust service, not a hard-coded certificate list copied at launch. Austria's regulator explains how its supervised trust list connects to the Member State system. In production, use maintained EU Trusted List processing or a validation service that preserves the evidence used at signing time.

When to use login, QES or an electronic seal

QES is not a universal requirement and should not be added merely because it sounds safer. It introduces enrolment, user interaction, cost, failure modes and retention duties. Start with the form requirement and dispute risk, then choose the lowest sufficient signature level. For organisation-generated output, compare the legal effect you need with what an eSeal proves.

Build versus buy: buy the trust service, build the control plane

Do not build your own QTSP, certificate authority or qualified signature creation device as a normal product feature. Procure the qualified trust service. Build the product-specific layer that the provider cannot know: contract versioning, agent permissions, mandate resolution, approval UX, policy evaluation, idempotent execution, evidence retention and operational reporting.

During provider selection, test these questions:

• Which countries, identity methods, certificates and PAdES, XAdES, CAdES or ASiC profiles are supported?
• Does the flow support one-shot and reusable credentials, remote QES, web and app handoff, and an accessible fallback?
• Can the API bind approval to your digest, purpose and transaction, and export a complete validation report?
• Are webhooks signed, replay-safe, ordered and recoverable through polling?
• What happens when the user rejects, abandons, loses the device or changes identity state?
• How are EU Trusted Lists, revocation data, timestamps and long-term validation evidence updated and preserved?
• What are the per-signature, enrolment, validation, support and archive costs for professional use?
• Can the adapter later support an EUDI Wallet route without changing the domain state machine?

Commercially, price the complete successful transaction. A cheap signature call followed by manual reconciliation, abandoned enrolment and unverifiable evidence is expensive. Track completion rate, time to approval, rejection, expiry, validation failure, duplicate suppression, human support time and cost per effective agreement. The AI agent SLA template shows how to turn those signals into measurable operating commitments.

QES does not make an AI system compliant

A valid signature proves a defined trust-service result. It does not prove that the model was accurate, the contract was fair, the signer had corporate authority, personal data use was lawful, or the AI system met sector rules. Where the EU AI Act's high-risk requirements apply, Articles 12 and 14 address logging and human oversight. A QES can be one control inside that system, not a compliance shortcut.

Use the same principle for agent permissions. Authentication answers who is present. Authorisation answers what that person may do now. Signature answers what exact data they approved. Validation answers whether the trust result is valid. Execution answers whether the intended side effect happened exactly once. Collapsing those five questions into one "approved" boolean is the architecture bug.

"The agent may write the proposal. The person approves the immutable payload. The verifier decides whether the signature is valid. The application commits once. Four owners make the trust boundary visible."

Research sources

Researched and checked on 13 August 2026. Regulations, specifications, national wallet programmes and provider capabilities change. Verify the current source and obtain legal advice for your transaction.

1. Consolidated Regulation (EU) No 910/2014, Article 25 on the legal effect of electronic signatures.
2. Regulation (EU) 2024/1183, EUDI Wallet functions and qualified signing.
3. European Commission eSignature FAQ, signatures, seals, qualified devices and validation.
4. ID Austria general guidance, current identity, login and qualified signature capabilities.
5. ID Austria OpenID Connect integration, the authentication interface.
6. EUDI Wallet eSignature manual, wallet-driven and QTSP-driven user journeys.
7. EUDI Architecture and Reference Framework 1.5.1, actors and Remote Signing Interface.
8. EUDI reference implementation repositories, rQES libraries and signing components.
9. RTR Austrian Trusted List guidance, supervision and machine-readable trust data.
10. Regulation (EU) 2024/1689, EU AI Act, Articles 12 and 14 where high-risk obligations apply.