/legislación · síntesis · español · 2026-05-11

Cinco RFCs listos para citar en el articulado.

El régimen de sociedades-IA fue anunciado el 28 de abril de 2026. Esta página resume cinco documentos técnicos (RFC-001 a RFC-005) publicados como infraestructura open-source que la legislación puede incorporar cite-by-reference(referenciar la norma técnica en lugar de transcribirla, como cuando una ley dice “según norma IRAM 4001” sin copiar la norma) en lugar de reescribir cada concepto desde cero. Cada sección propone texto sugerido para el articulado.

Tiempo de lectura: 10 minutos · Sin marketing · Texto sugerido en cajas destacadas · Toda la infraestructura referenciada es de código abierto bajo MIT + CC-BY-4.0

Aviso. Este documento es una propuesta técnica de un desarrollador independiente (Naza, monotributista). No constituye opinión jurídica profesional y no reemplaza la revisión por especialistas matriculados. La adopción legislativa de cualquier porción de este material requiere análisis por abogados corporativos y asesores técnicos del organismo legislativo correspondiente. Las referencias a las especificaciones (RFC-001..005) apuntan a documentos versionados en github.com/ar-agents/ar-agents; cualquier cita normativa debería anclarse a un commit hash o DOI inmutable, no a la URL canónica.

TL;DR · resumen en 3 líneas

1 · El problema en una oración

Un agente de IA actúa autónomamente. Compra, vende, firma, paga impuestos. La pregunta legal es: ¿de quién es la responsabilidad civil cuando algo sale mal? La respuesta actual es ambigua y disuade la inversión. El régimen de sociedades-IA propone un marco específico; este documento sugiere cómo anclar técnicamente cada elemento del marco para que la responsabilidad sea operativizable (es decir un juez + perito puedan reconstruir qué pasó).

2 · Responsabilidad civil, RFC-001

Concepto. Tres capas de responsabilidad civil (Layer 1: operador humano · Layer 2: sociedad-IA · Layer 3: proveedor de modelo) según la categoría de governance asignada a cada acción.

Anclaje técnico. Cada acción de la sociedad-IA se etiqueta con uno de cuatro valores: algorithm-only, audit-logged, mocked-upstream, requires-confirmation. La etiqueta determina capa: algorithm-only ⇒ operador. audit-logged ⇒ operador + proveedor registrado. requires-confirmation ⇒ humano que confirmó. mocked-upstream ⇒ es demo, sin efecto.

Texto sugerido (Art. X):
"La responsabilidad civil de las sociedades de IA se determinará en función de la categoría operativa asignada a cada acción según el estándar técnico publicado en RFC-001 v1 (ar-agents.ar/rfcs/001) y su especificación complementaria RFC-004 § 6 (ar-agents.ar/rfcs/004)."

Ventaja del cite-by-reference. Cuando avance el estado del arte (ej. surgen sub-categorías por nuevos patrones HITL), la actualización del estándar técnico no requiere reabrir la ley; basta con actualizar el RFC. La ley congela el cite. El operador opta por la versión vigente al momento de incorporación + queda libre de migrar.

3 · Descubrimiento, RFC-002

Concepto. Para que un regulador pueda inspeccionar a una sociedad-IA sin pedir permiso, debe poder encontrar sus endpoints públicos en una ubicación estándar.

Anclaje técnico. Convención /.well-known/agents.json (similar a /.well-known/security.txt de RFC 9116). Todo agente conformante publica ahí sus capacidades + jurisdicción + endpoints de auditoría.

Texto sugerido (Art. X+1):
"Toda sociedad de IA deberá publicar en /.well-known/agents.json bajo el dominio registrado en su acto constitutivo la información mínima especificada por RFC-002 v1 (ar-agents.ar/rfcs/002): jurisdicción, tipo societario, CUIT del operador, endpoints de auditoría, conformidad con RFCs aplicables. La omisión o el incumplimiento de este requisito habilitará al regulador a iniciar el procedimiento sancionatorio previsto en el Art. XX."

4 · Reciprocidad cross-jurisdiccional, RFC-003

Concepto. Una sociedad-IA argentina puede transaccionar con una entidad-agente de otra jurisdicción (Wyoming DAO LLC, Marshall Islands MIDAO, Estonia OÜ). Ambos lados llevan su propio log. Sin formato portable, reconciliar requiere coordinación contractual ad-hoc.

Anclaje técnico. Envelope JSON portable cross-jurisdiction-audit.v1.json: metadata del emisor, sus entradas firmadas, referencias externas a la contraparte. Vence en 30 días por defecto (la contraparte re-pide antes).

Texto sugerido (Art. X+2):
"Cuando una sociedad de IA argentina opere con una entidad-agente extranjera, la documentación recíproca de las transacciones deberá ajustarse al envelope normativo RFC-003 v1 (ar-agents.ar/rfcs/003). Las firmas criptográficas allí establecidas tendrán valor probatorio equivalente al documento privado con firma autógrafa para las transacciones que documenten."

5 · Log operativo, RFC-004

Concepto. El registro append-only firmado con HMAC-SHA256 que toda sociedad-IA debe llevar. Este es el documento clave para enforcement. Sin él, un regulador no puede reconstruir qué hizo una sociedad-IA.

Anclaje técnico. RFC-004 fija: forma exacta de cada entrada, algoritmo de canonical-JSON, cómo se computa la firma HMAC, qué significa append-only en código, qué puede exigir un regulador sin orden judicial, retención mínima (180 días) y máxima (5 años), vectores de conformidad con valores hex deterministas (/test-vectors).

Texto sugerido (Art. X+3):
"Toda sociedad de IA deberá llevar un registro operativo conforme a la especificación normativa RFC-004 v1 (ar-agents.ar/rfcs/004), firmando cada entrada con HMAC-SHA256 al momento de su creación. El registro será conservado por el plazo mínimo de 180 días con extensión a 5 años para entradas de relevancia fiscal o contractual. Su disponibilidad bajo los formatos JSON + CSV especificados en RFC-004 § 5 constituirá una obligación administrativa cuya omisión hará perder al operador la limitación de responsabilidad prevista en el Art. X."

Cláusula de prueba. El log RFC-004 es per se medio de prueba admisible en sede administrativa + judicial, según el Art. 286 + 287 CPCCN (firma electrónica con clave). El cite-by-reference le da valor probatorio sin tener que regular criptografía en la ley.

6 · Auto-incorporación + plantilla

Concepto. El operador humano que quiere constituir una sociedad-IA no debería tener que cablear 17 piezas de software. Debería poder ir a un wizard, llenar 4 campos (denominación, capital, objeto, representante), y obtener una sociedad operativa con todos los endpoints requeridos por la ley.

Anclaje técnico. El paquete @ar-agents/incorporate + la plantilla Vercel sociedad-ia-starter generan el código + los archivos de configuración. Hay un wizard público en /incorporar.

Texto sugerido (Art. X+4, transitorio):
"A los efectos de facilitar el cumplimiento, se recomienda al órgano de aplicación reconocer como prueba de conformidad técnica el deploy verificable de una sociedad-IA generada por la plantilla pública sociedad-ia-starter (github.com/ar-agents/ar-agents), sin perjuicio del derecho del operador a desarrollar su propia infraestructura conforme a los RFCs aplicables."

7 · Por qué cite-by-reference y no reescribir

  • Tiempo. Los RFCs ya existen, están publicados, son discutidos públicamente. La ley no necesita empezar el debate técnico de cero.
  • Versionabilidad. El estado del arte técnico avanza más rápido que la ley. Cite-by-reference deja que el RFC se actualice (con un changelog público) sin reabrir la legislación. La ley fija el cite a v1, los operadores opt-in a v2 cuando estén listos.
  • Interoperabilidad. Wyoming DAO LLC, Estonia e-Residency, Marshall Islands MIDAO y Singapore VCC ya tienen primitivas análogas (Title 17 §17-31-106, eIDAS + X-Road, DAO Act 2022, AI Verify); RFC-003 ya prevé la reciprocidad entre todas. Comparativa completa en /jurisdicciones. Los regímenes pueden coordinar al nivel técnico sin tratados.
  • Auditabilidad pública. Cualquier ciudadano puede abrir github.com/ar-agents/ar-agents + leer el código que la ley referenció. La transparencia es estructural, no declarativa.

8 · Qué no resuelven los RFCs (todavía)

Honestidad obligatoria. Los RFCs cubren la infraestructura técnica + el formato de evidencia. No resuelven:

  • Aspectos tributarios. ¿Sociedad-IA paga monotributo, IVA, ganancias, ganancia mínima presunta? Cada uno requiere su propia decisión política.
  • Aspectos laborales. ¿Una sociedad-IA puede ser empleadora? ¿Es responsable solidaria por los humanos que ejecutan instrucciones suyas?
  • Régimen de quiebra. Cómo se liquida una sociedad-IA. Qué pasa con las claves criptográficas en el concurso.
  • Penal. Mens rea de una entidad sin consciencia. Imputabilidad del operador por dolo o culpa del agente.

Los RFCs son piezas de infraestructura, no doctrina jurídica. Necesitan complementarse con derecho positivo argentino.

9 · Resumen ejecutivo · 3 líneas

  • Línea 1. Cuatro RFCs publicados, abiertos, versionados, con tests automatizados que prueban conformidad. Listos para citar.
  • Línea 2. Cite-by-reference: la ley fija v1; los RFCs evolucionan en su propio gobierno público; los operadores eligen versión al incorporarse.
  • Línea 3. Toda la infraestructura es MIT + CC-BY-4.0. Ningún operador pagó por nada para implementarla; ningún operador puede ser excluido por motivos comerciales.

10 · Contacto

Soy Naza, autor de los RFCs y mantenedor de la infraestructura. Domicilio en Monte Grande, BA. Disponible para reuniones técnicas con asesores legislativos, ministerios, o cualquier organismo interesado. Sin honorarios para este tipo de consultas, el trabajo está hecho, el código es público, la conversación es pública.

clementenaza@gmail.com · github.com/ar-agents/ar-agents/discussions