Identidad y firma de agentes en Argentina.

Status: draft-01. Author: Naza. Date: 2026-05-08. License: CC-BY-4.0. DOI: 10.5281/zenodo.20159396. Comments: github.com/ar-agents/ar-agents/discussions.

1. Problem statement

Una sociedad de IA creada bajo el régimen propuesto por Sturzenegger necesita resolver, sin un humano en el ciclo, los mismos cuatro problemas que cualquier persona jurídica argentina:

(a) Identidad: probar al Estado quién es.
(b) Firma: emitir actos legales con autoría verificable.
(c) Notificación: recibir comunicaciones oficiales en un canal monitoreable.
(d) Pago: depositar impuestos y transferencias sin intervención manual.

Hoy Argentina resuelve (a) con CUIT + Clave Fiscal, (b) con cert X.509 emitido por AFIP/ARCA + firma digital para algunos casos, (c) con domicilio fiscal electrónico + GDE/TAD, (d) con cuenta bancaria habilitada para SUAF. Funciona razonablemente para humanos. Para agentes se rompe.

2. Identidad, propuesta

2.1La sociedad IA recibe un CUIT al constituirse, exactamente como una SA. No se inventa un “CUIT de agente”, el régimen reusa la primitiva existente. (Esto coincide con el plan Sturzenegger: la IA no es titular, la sociedad sí.)

2.2 La sociedad nombra un oficial digital, un humano físico que figura como representante legal en IGJ y que carga el cert X.509 inicial. El oficial puede ser el desarrollador, el inversor, o un servicio notarial.

2.3 Para autenticación frente a Mi Argentina, la sociedad usa el flow OIDC estándar: @ar-agents/mi-argentina. El sub que devuelve Mi Argentina identifica al oficial digital, no a la sociedad, la mapeo CUIT-↔-sub se hace en una tabla aparte que el RFC publica.

3. Firma, propuesta

3.1 Toda firma electrónica de la sociedad usa el cert X.509 emitido por ARCA al CUIT. Mismo mecanismo que existe hoy para WSAA, sin invenciones.

3.2 El cert vive en un HSM o un KMS gestionado (Vercel KV con encryption-at-rest, AWS KMS, Google Cloud KMS). NUNCA en disco del proceso del agente.

3.3 Para acciones que requieren acto notarial (cambio de directorio, fusión, disolución), el RFC requiere doble firma: cert ARCA + firma digital del oficial humano. Es la salvaguarda contra runaway-agent que la teoría legal actual demanda.

// Firma estándar (transacciones rutinarias)
sign(payload, certArca)

// Firma con doble factor (actos societarios)
const sigA = sign(payload, certArca);
const sigB = await human.confirm(payload); // bloqueante
const wrapped = wrap(payload, [sigA, sigB]);

4. Notificación, propuesta

4.1 Domicilio fiscal electrónico (DFE) ARCA sigue siendo el canal oficial. Sin cambios.

4.2 Para notificaciones publicadas en Boletín Oficial que afecten a la sociedad (resoluciones, designaciones, edictos), @ar-agents/boletin-oficial ofrece suscripciones por CUIT. La sociedad se subscribe a su propio CUIT + a los CUITs de sus contrapartes habituales y procesa los matches en su cola interna.

4.3 El RFC propone que el régimen exija un endpoint webhook público (HTTPS, autenticado con HMAC) por cada sociedad IA, registrado en IGJ. ARCA y Boletín Oficial entregan notificaciones ahí. Si un agente queda inactivo durante meses entre transacciones, las notificaciones se entregan igual al webhook registrado.

5. Pago, propuesta

5.1 La sociedad mantiene una cuenta bancaria habilitada para SUAF + débito automático ARCA. El cert X.509 se usa para autorizar transferencias programáticas via @ar-agents/banking.

5.2 Los pagos menores a 1M ARS se ejecutan automáticamente. Los pagos iguales o superiores a 1M ARS requieren confirmación humana programática (HITL: human-in-the-loop, humano en el ciclo de decisión), el toolkit ar-agents ya implementa el patrón en requireConfirmation. El humano firmante recibe el pedido, confirma desde Mi Argentina, y la transferencia se libera.

6. Apertura, open questions

6.1 ¿Quién es responsable cuando un agente ejecuta un fraude? El RFC actual es agnóstico, depende de cómo el proyecto Sturzenegger trate la responsabilidad piercing-the-veil.

6.2 ¿Cómo se renueva el cert X.509 sin intervención humana? Propuesta interim: el cert tiene 1 año de vida y la renovación requiere humano + Mi Argentina (vuelve a depender del oficial digital).

6.3 ¿Qué pasa si Mi Argentina cambia el flow OIDC? El package ar-agents implementa discover() (refresh de endpoints vía .well-known/openid-configuration), el cambio se absorbe sin redeploy.

7. Roadmap, qué falta en ar-agents

@ar-agents/igj, APIs de IGJ para constitución, modificación de estatuto, balances. Hoy solo open data en CSV, gap real.

@ar-agents/gde, Gestión Documental Electrónica. No tiene API pública; el RFC propone seguirlo via TAD scraping hasta que el gobierno publique uno.

@ar-agents/firma-digital, Firma digital avanzada (FAD) ONTI, distinta del cert ARCA, requerida para actos societarios bajo Ley 25.506.

8. Implementación de referencia

Este RFC no es teoría, el toolkit @ar-agents/* ya implementa 16 de los 17 pasos técnicos del régimen propuesto. La lista cruzada de qué pieza técnica resuelve cada problema:

(a) Identidad: @ar-agents/identity (CUIT + ARCA padrón) + @ar-agents/mi-argentina (OIDC) + @ar-agents/identity-attest (HMAC-signed attestation con trustLevel) + @ar-agents/igj (constitución y registro societario).
(b) Firma: @ar-agents/firma-digital (CMS/PKCS#7 + AC-Raíz/ONTI heuristic + fingerprint pinning) + el cert WSAA existente en @ar-agents/identity y @ar-agents/facturacion.
(c) Notificación: @ar-agents/boletin-oficial (subscribe por CUIT / organismo / keyword) + el endpoint webhook propuesto en 4.3.
(d) Pago: @ar-agents/banking (CBU/CVU + BCRA Central de Deudores + transfers) + @ar-agents/mercadopago (MP API completo) + @ar-agents/facturacion (factura electrónica WSFE) + @ar-agents/agentic-commerce-bridge (ACP facilitator con auto-emisión).

El paso 17, domicilio legal digital via TAD/GDE, sigue siendo el bloqueante: requiere autorización gubernamental para alta de aplicación cliente, no admite acceso programático estable mediante scraping. El RFC propone que el régimen exponga el endpoint webhook (4.3) como sustituto operativo hasta que TAD ofrezca API.

9. Marco de responsabilidad

El backlash central al plan Sturzenegger es “¿quién responde si una sociedad-IA defrauda?” El RFC propone tres capas de responsabilidad concatenadas:

9.1 Responsabilidad operativa: el oficial digital (humano físico nombrado en IGJ) responde por toda acción ejecutada con el cert X.509. Es el equivalente del director suplente en una SA.

9.2 Responsabilidad de auditoría: cada tool call que la sociedad-IA ejecuta queda registrado en un audit log con HMAC-signed timestamps (el patrón AuditLogger ya implementado en @ar-agents/mercadopago). El log es prueba legal de qué hizo el agente, cuándo, contra qué tool.

9.3 Responsabilidad de operador (operator-of-record): cuando la sociedad-IA opera bajo el cert de un facade AR-residente (escribano, contador, plataforma SaaS), el operador comparte responsabilidad civil. Esto es lo que hoy se conoce como “intermediario calificado” en otros ordenamientos.

Las tres capas no son alternativas, son acumulativas. Una víctima de fraude tiene tres demandados con distintas barras probatorias.

10. Prior art y citations

Marshall Islands DAO LLC (2022), el primer régimen jurisdiccional reconociendo persona jurídica programática. MIDAO cubre (a) y (d) para DAOs cripto pero no tiene equivalente AR de (b) (firma estatal) ni (c) (notificación oficial).

Wyoming DAO LLC (Wyo. Stat. §17-31, 2021), precedente USA con la misma laguna en notificación. ClawBank.co construye sobre este régimen.

EU AI Act Art. 50 + 52 (vigor 2026-08), exige marcado verificable de outputs generados por IA y trazabilidad de decisiones. Compatible con la sección 9 de este RFC.

Mastercard Verifiable Intent + Google AP2 Mandates, patrones cripto-firmados para autorización de pagos por agentes. El RFC proposes adoptar AP2 como el formato estándar para órdenes de pago grandes (sección 5.2).

IETF draft-sharif-agent-audit-trail, propuesta de estándar para audit-trail de tool calls en agentes. La sección 9.2 de este RFC se alinea con esa propuesta.

Plan Sturzenegger, anuncio en Expo EFI 2026-04-28. Sin texto público todavía. Este RFC asume el contorno descripto en la conferencia y se va a actualizar cuando llegue el proyecto a Diputados.

Comentarios

Este RFC es un primer borrador. Se va a iterar contra: lectura del proyecto cuando llegue al Boletín Oficial, feedback de juristas, feedback de agentes que efectivamente intenten incorporarse. Comentarios públicos bienvenidos.