Briefing operativo para el Estado argentino.

1 · Quién soy

Naza, 26 años, monotributista categoría A (servicios informáticos), domicilio en Monte Grande, Buenos Aires. Sin formación jurídica formal. Sin financiamiento estatal, sin financiamiento privado, sin contratos con servicios de inteligencia ni seguridad. Trabajo documentado en github.com/naza00000. Antes construí Astro (astro.ar) y Publi (publi.ar), dos productos AI consumer en Argentina; este proyecto es infraestructura, no producto consumer.

2 · Qué construí, técnicamente

• 17 paquetes npm bajo @ar-agents/* con licencia MIT. Cubren 16 de las 17 piezas operativas que una sociedad-IA argentina necesita para operar end-to-end (identidad / firma / dinero / operación al cliente / monitoreo del BO / registro corporativo). La pieza que falta (alta de aplicación cliente en TAD/GDE) requiere autorización gubernamental y no tiene proceso público.
• 5 RFCs publicados bajo CC-BY-4.0, propuestas técnico-normativas que la legislación puede incorporar cite-by-reference. Texto sugerido para articulado en /legislación.
• Audit log forense firmado dual con HMAC-SHA256 + Ed25519. Cualquier organismo (regulador, perito judicial, AAIP) puede verificar sin pedir la clave privada al operador. Detalle técnico en /auditor (1 página imprimible) + /architecture/audit-log (code-level deep-dive).
• Generador de citaciones inmutables (/cite): BibTeX, APA y Chicago anclados a commit hash de GitHub. Permite que el articulado de la ley cite versión exacta de un RFC sin depender de la URL canónica mutable. DOI inmutable en Zenodo agregado al roadmap.
• Comparativa internacional (/jurisdicciones), análisis lado-a-lado con Wyoming DAO LLC, Marshall Islands MIDAO, Estonia e-Residency, Singapore VCC + AI Verify y EU AI Act Art. 50.

3 · Lo que esto le ahorra al Ministerio

• Trabajo técnico previo: los 5 RFCs cubren las decisiones operacionales que cualquier diseño regulatorio del régimen tendría que tomar igual. Estimación honesta: 4-6 meses de definición técnica + revisión de pares ya hechos, publicados y abiertos a comentario público en GitHub Discussions.
• Referente citable open-source: el articulado puede incorporar cite-by-reference en lugar de transcribir especificaciones técnicas dentro de la ley. Si la spec evoluciona, no requiere reabrir el debate legislativo, la ley fija el cite a una versión específica (commit hash o DOI Zenodo).
• Implementación de referencia que cualquier sociedad puede usar el día 1 de la ley: sin costo de licencia, sin dependencia de proveedor único, sin lock-in. Esto baja la fricción de adopción del régimen.
• Comparativa internacional cuantitativa para fundamentar posicionamiento competitivo. Si el ministerio necesita defender públicamente “Argentina vs Wyoming vs Estonia vs Marshall Islands”, los datos ya están sistematizados.

4 · Lo que esto NO es

• No es un proyecto comercial vendiéndose al Estado. El código es MIT, el sitio es gratis, el demo es público, los RFCs son CC-BY-4.0. Cualquier consultora (Globant, Accenture, BGH) puede implementarlo para un cliente sin pedirme permiso. Si en el futuro hay servicios pagos (hosting managed, soporte SLA, custodia de claves), están separados en /cloud , pero la infra de base se queda libre por diseño.
• No es opinión jurídica profesional. No soy abogado matriculado. Los RFCs son drafts técnicos y necesitan revisión por especialistas (derecho corporativo, AAIP, derecho de la prueba) antes de cualquier adopción legislativa. Por eso publiqué /co-firmar: invitación abierta a académicos y juristas argentinos para sumar co-autoría sin compromiso comercial.
• No es una propuesta SIDE / inteligencia / seguridad estatal. El manifiesto es explícito: civil-comercial-OSS, no participo de contratos con servicios de inteligencia ni seguridad. Si el Estado necesita Palantir-grade tooling, hay otros lugares; este proyecto se queda en la capa civil.
• No es token / DAO / cripto. No hay token de governance, no hay yield farming, no hay tesorería on-chain. La diferenciación con $SAIRI / WAGMI.law está explícita en /jurisdicciones.

5 · Limitaciones honestas (que un asesor escéptico encontraría primero)

• Único maintainer. Si yo me caigo, el proyecto se ralentiza. Mitigaciones: código MIT en GitHub público con historial completo; npm provenance attestations; roadmap de archivar RFCs en Zenodo (CERN) para preservación 20+ años. Cualquier consultora podría tomar el código y darle continuidad mañana.
• Infraestructura corre en proveedores extranjeros (Vercel US, Upstash sa-east-1, npm US, GitHub US). Para uso civil no es bloqueante, pero para producción regulada por Ley 25.326 (AAIP) requiere o DPA con cada proveedor o migración a residencia argentina. /cloud contempla “Government tier” con residencia AR + HSM auditable como path planeado, no como solución hoy.
• Registro tiene 5 entradas, todas mías. El /registro es honesto sobre esto. Lo que muestra es la implementación de referencia + 4 demos del autor, no un ecosistema. La ley todavía no existe; los operadores reales aparecen cuando aparezca el régimen.
• RFCs en estado draft. Las specs están en draft-01. La etapa siguiente requiere revisión por co-firmantes externos (jurista + académico) y archivo inmutable en Zenodo. Citarlas en articulado final de una ley antes de que pasen a estado stable no se recomienda; para discusión legislativa preparatoria, sí.

6 · Lo que estoy proponiendo (no pidiendo)

En orden de menor a mayor compromiso institucional:

1. Conciencia técnica del equipo del Ministro de que la implementación de referencia existe, antes de que el articulado se redacte. Evita supuestos técnicos contradictorios con el stack que ya funciona. Cero compromiso.
2. Reunión técnica de 30 minutos con quien el ministerio designe (Subsec TIC, asesor del Ministro, equipo Sandbox de Desregulación). Sin honorarios, sin agenda comercial. Demo en vivo, código abierto, preguntas duras bienvenidas.
3. Apertura de TAD/GDE para alta de aplicación cliente programática. Es la única pieza técnica que depende del Estado y que no puedo resolver yo solo. Si el ministerio incluye esto en el alcance de la reforma, el ciclo de incorporación programática de sociedades-IA se cierra.
4. Eventual referencia en el articulado a las specs existentes. Si después de revisión por especialistas (paso 7) algún RFC se considera incorporable, el ministerio puede citarlo con commit hash inmutable o DOI Zenodo. Sin compromiso de exclusividad, la cita es a un documento público CC-BY-4.0.

7 · Por qué necesito que circule esto antes que la redacción de la ley

Una ley redactada sin input técnico tiende a fijar definiciones que después complican la implementación: estándares criptográficos obsoletos, asunciones sobre identidad digital que chocan con OIDC/PKCE, requisitos de retención que ignoran cómo funciona realmente un audit log append-only. Los 5 RFCs cubren esas decisiones desde el lado del código. Si llegamos antes que el draft del articulado, evitamos errores costosos de revertir después; si llegamos después, los errores se cristalizan.

Esto no es lobby. Es un dev solo escribiéndole al asesor que recibió este link, diciendo: hay material útil acá, está abierto, no cuesta nada usarlo o ignorarlo, conviene mirar antes de decidir.

8 · Contacto

Naza
Email: clementenaza@gmail.com: respuesta en <48hs.
Monte Grande, Buenos Aires.
GitHub: @naza00000 · Twitter: @nazaclemente.

Para asistentes / secretarías: agendar 30 minutos por videollamada (Google Meet preferido, también Zoom o Teams). Sin necesidad de NDA, todo el material es público bajo MIT + CC-BY-4.0.

9 · Material de respaldo

• /al-ministro: carta abierta personal, CC0, 9-may-2026.
• /legislación: síntesis técnica con texto sugerido cite-by-reference.
• /auditor: 1-pager imprimible para reguladores.
• /jurisdicciones: comparativa con Wyoming / Marshall / Estonia / Singapore.
• /rfcs/001 a /rfcs/005: las 5 specs técnicas.
• /play: demo interactivo, 30 segundos, sin setup.
• /registro: registro público con disclosure honesto.
• /security: threat model STRIDE + OWASP LLM Top 10.
• /cloud: tier comercial (separado del código abierto).