Firma de Contratos con Agentes de IA: Guía QES eIDAS

Un agente de IA puede redactar un contrato e iniciar el flujo de firma, pero no debe modelarse como el firmante QES. El patrón robusto es un commit en dos fases: el agente propone un artefacto inmutable, un servicio de policy decide la aprobación necesaria, una persona autorizada revisa el payload exacto y el sistema valida la firma antes de hacer definitivo el contrato, pago o estado de cuenta.

Esta guía separa login, consentimiento, firma electrónica cualificada, sello electrónico y logs de auditoría. Es una guía técnica y comercial, no asesoramiento jurídico. Para selective disclosure, SD-JWT VC, mdoc y zero knowledge, consulta nuestra guía de zero-knowledge proofs en producción. Aquí resolvemos el paso siguiente: vincular la decisión de una persona real al documento preparado por el agente.

¿Puede un agente de IA firmar legalmente un contrato en la UE?

No lo trates como firmante QES. Una firma electrónica cualificada la crea una persona física y, según el artículo 25 del Reglamento eIDAS consolidado, tiene el efecto jurídico de una firma manuscrita. El agente puede preparar datos, calcular el digest e iniciar la solicitud. La autorización explícita de la persona sigue siendo la frontera de confianza.

Las EUDI Wallet deben ofrecer QES a las personas físicas por defecto. La gratuidad puede limitarse a usos no profesionales, por lo que un workflow empresarial aún necesita un plan comercial y técnico para firma, enrolment y validación. Así lo establece el Reglamento (UE) 2024/1183.

Una persona jurídica usa otro mecanismo: el sello electrónico. La FAQ de eSignature de la Comisión Europea separa la firma de una persona física del sello de una persona jurídica. El sello cualificado acredita origen e integridad, no el consentimiento humano de un representante. El sellado automatizado exige controles internos de autorización.

ID Austria, Handy-Signatur, EUDI Wallet y QES no son sinónimos

Handy-Signatur es un nombre legado. La información oficial de ID Austria confirma que ID Austria la sustituyó y que admite login y firma cualificada como acciones distintas. La documentación OpenID Connect de ID Austria cubre autenticación. Una respuesta OIDC no vincula al usuario con la versión 7 de un contrato.

Arquitectura: proponer, aprobar, validar y ejecutar

1. El agente propone. Produce datos estructurados y borrador, pero no elige al firmante ni rebaja la policy.
2. La aplicación congela. Renderiza el artefacto final, lo guarda de forma inmutable y calcula el digest en servidor. Todo cambio exige otra aprobación.
3. La policy autoriza. Resuelve persona, organización, mandato, límites, tipo contractual y segregación de funciones. Ante duda, falla cerrado.
4. La persona revisa. Muestra documento, contraparte, importe, duración, efectos irreversibles y versión. El resumen del agente es secundario.
5. QTSP o wallet firma. Usa una solicitud de un solo uso, con caducidad corta y estado de retorno ligado a la transacción.
6. El verificador comprueba. Valida bytes, certificado, cadena, revocación, tiempo, formato, digest y firmante. Un webhook de éxito no basta.
7. La aplicación ejecuta una vez. Usa outbox idempotente. Un callback repetido no repite el efecto.
8. El archivo conserva. Guarda artefacto, informe de validación, borrador, mandato, versión de policy, aprobación, IDs del proveedor y trace.

El manual de eSignature para EUDI Wallet describe recorridos dirigidos por wallet y por QTSP. En ambos, el usuario revisa y aprueba mientras un dispositivo cualificado crea la firma. La wallet pertenece a la frontera de autorización, no al tool loop del agente.

Contrato de solicitud neutral respecto al proveedor

{
  "idempotency_key": "contract:847:version:7",
  "artifact_sha256": "8c4f...",
  "artifact_version": 7,
  "intended_signer": "person_219",
  "represented_organisation": "org_44",
  "purpose": "Aceptar contrato de proveedor versión 7",
  "signature_level": "QES",
  "policy_version": "contract-signing/12",
  "expires_at": "2026-08-13T15:30:00Z"
}

Usa DRAFT -> FROZEN -> AWAITING_APPROVAL -> SIGNING -> VALIDATING -> EFFECTIVE y estados terminales REJECTED, EXPIRED y FAILED. Solo el verificador entra en EFFECTIVE. El EUDI Architecture and Reference Framework 1.5.1 define una Remote Signing Interface. Mantén estable el modelo de dominio y aísla la interoperabilidad cambiante en adaptadores.

Las implementaciones de referencia EUDI incluyen librerías móviles rQES, componentes CSC API y una aplicación centrada en el relying party. Aceleran las pruebas, pero no sustituyen la cualificación del proveedor, el threat model ni la validación independiente.

Riesgos que la firma no resuelve

• Prompt injection tras aprobar: congela bytes y vincula la solicitud a su digest.
• Firmante sin autoridad: resuelve el mandato desde una fuente fiable al ejecutar.
• Aprobar solo el resumen: muestra el artefacto completo y sus efectos materiales.
• Replay: usa nonce, expiración, idempotency key, event ID y compare-and-set.
• Falso éxito: valida la firma antes de activar el efecto comercial.
• Fatiga de aprobación: escala acciones irreversibles o exigidas por policy y muestra diffs.

La validación no puede depender de certificados copiados al lanzar. El regulador austríaco explica cómo su lista de confianza supervisada se integra con las listas de los Estados miembros. Usa procesamiento actualizado de EU Trusted Lists y conserva la evidencia disponible al firmar.

Build vs buy: compra el trust service, construye el control plane

No construyas un QTSP, una autoridad certificadora o un QSCD como feature normal. Compra el servicio cualificado. Construye versionado contractual, permisos del agente, mandatos, UX de aprobación, policy, ejecución idempotente, evidencia y reporting.

Evalúa países e identidades, PAdES/XAdES/CAdES/ASiC, credenciales one-shot o reutilizables, remote QES, handoff web y móvil, webhooks firmados y replay-safe, informe de validación, revocación, timestamping, recuperación, coste profesional y futura ruta EUDI. Mide el coste por acuerdo efectivo, no por llamada. La plantilla de SLA para agentes de IA convierte aprobación, validación y evidencia en compromisos medibles.

Una QES no hace compliant a un sistema de IA

Una firma válida demuestra un resultado concreto del trust service. No demuestra precisión del modelo, poder de representación, legalidad de datos, equidad contractual ni cumplimiento sectorial. Cuando aplican las obligaciones de alto riesgo del AI Act, los artículos 12 y 14 tratan logging y supervisión humana. La QES es un control, no un atajo de compliance.

Authentication responde quién está presente. Authorization, qué puede hacer. Signature, qué datos aprobó. Validation, si el resultado de confianza es válido. Execution, si el efecto ocurrió una sola vez. Un único booleano approved no puede representar esas cinco fronteras.

"El agente redacta la propuesta. La persona aprueba el payload inmutable. El verificador comprueba la firma. La aplicación ejecuta una sola vez. Cuatro responsables hacen visible la frontera de confianza."

Fuentes de investigación

Investigado y revisado el 13 de agosto de 2026. Comprueba las fuentes actuales y solicita asesoramiento jurídico para la transacción concreta.

1. Reglamento (UE) n.º 910/2014 consolidado, artículo 25.
2. Reglamento (UE) 2024/1183, EUDI Wallet y QES.
3. FAQ de eSignature de la Comisión Europea.
4. Información general de ID Austria.
5. Integración OpenID Connect de ID Austria.
6. Manual eSignature de EUDI Wallet.
7. EUDI Architecture and Reference Framework 1.5.1.
8. Implementaciones de referencia EUDI.
9. RTR y la lista de confianza austríaca.
10. Reglamento (UE) 2024/1689, AI Act.