En mayo de 2026, el regulador tecnológico de Singapur (IMDA) publicó la versión 1.5 del Model AI Governance Framework for Agentic AI (Marco de Gobernanza de IA Agéntica). Es el primer marco regulatorio emitido por un gobierno nacional dedicado específicamente a los riesgos de la IA agéntica — no los modelos de lenguaje en general, sino los sistemas que toman decisiones, encadenan acciones y operan con mínima supervisión humana. Probablemente la referencia más avanzada publicada hasta ahora en este campo.
El documento no es filosofía: incluye cuatro dimensiones operativas, casos de implementación de Tencent, PwC, OCBC, MSD y otros, y fue elaborado con retroalimentación de decenas de organizaciones del sector privado e instituciones de investigación. Es el tipo de referencia que puede contribuir a fijar el piso de expectativas regulatorias en industrias que ya se preguntan cómo auditar agentes autónomos.
Para quienes construyen o usan sistemas de IA en industrias reguladas de Argentina — estudios jurídicos, fintechs, healthtech — el documento importa por dos razones concretas: primero, porque el marco normativo argentino ya apunta en la misma dirección; segundo, porque es probable que muchos de los criterios técnicos que establece comiencen a reflejarse en auditorías, due diligence y cláusulas contractuales en los próximos años.
Los cuatro pilares
El framework organiza la gobernanza de agentes en cuatro dimensiones que forman un ciclo:
1. Evaluar y delimitar riesgos (assess and bound risks). Antes de desplegar un agente, identificar las tareas que puede ejecutar, los sistemas a los que puede acceder y los daños que puede causar si actúa fuera de los parámetros esperados. Esto incluye evaluar riesgos de ejecución en cascada (cascading failures) — cuando un agente delega en otro, el error inicial se amplifica en la cadena. Ejemplo concreto: un agente A consulta un agente B por jurisprudencia; B comete un error; A reintenta la consulta; el sistema hace dos intentos que generan duplicados de acción o registros contradictorios. El marco exige establecer límites técnicos explícitos sobre alcance de acción.
2. Responsabilidad humana significativa (meaningful human accountability). Que haya una persona responsable no es suficiente: la responsabilidad tiene que ser ejercible en la práctica. El framework distingue entre supervisión nominal y supervisión efectiva, y alerta sobre automation bias —la tendencia a validar outputs del sistema sin revisión real, especialmente cuando el agente “parece” competente.
3. Controles técnicos estructurales (technical controls). Un principio explícito: privilegiar restricciones arquitecturales y controles de acceso deterministas frente a depender solo de instrucciones textuales. Si el agente no debe acceder a cierto sistema, la restricción va en la arquitectura (listas blancas de comandos permitidos, separación de entornos dev/staging/producción), no en el prompt del sistema. Un ejemplo: en lugar de instruir “no accedas a la BD de producción”, configura el entorno de ejecución para que físicamente no pueda conectarse. Esta dimensión cubre también la trazabilidad de acciones — cada decisión del agente registrada con contexto y razón — y logs inmutables que permitan auditar qué hizo el sistema y por qué.
El framework introduce también el principio de retención mínima de datos (minimal footprint): los agentes deben solicitar solo los permisos mínimos para cada tarea, no retener información más allá de lo requerido (con TTL definido en logs), y preferir acciones reversibles. Para estudios jurídicos y fintechs, esto tiene consecuencias directas: un agente que procesa expedientes debe tener acceso solo al expediente específico, por la duración específica de la tarea, y no almacenar copias innecesarias (riesgo de fuga de datos y responsabilidad por almacenamiento indebido).
4. Responsabilidad del usuario final (end-user responsibility). El framework distingue entre operadores —quienes despliegan el sistema y definen sus parámetros— y usuarios finales —quienes interactúan con él en el uso cotidiano—, con cargas normativas diferenciadas para cada rol. En el contexto argentino, esta distinción es particularmente relevante: un estudio jurídico puede ser simultáneamente operador (diseña el flujo de trabajo con IA) y usuario final (aplica el output en sus escritos). En ambos roles, las obligaciones incluyen entender qué puede y qué no puede hacer el sistema, verificar outputs en contextos de alto riesgo, y no tratar la automatización como delegación total de juicio.
Lo que ya existe en Argentina
La Disposición 2/2023 de la Subsecretaría de Tecnologías de la Información — publicada en el Boletín Oficial el 2 de junio de 2023 — aprueba las “Recomendaciones para una Inteligencia Artificial Fiable”. No es ley, pero es el instrumento de política pública más específico sobre IA que tiene el Estado argentino hasta ahora, y sus principios organizadores son consistentes con los pilares del MGF de Singapur.
El artículo 3 de la Disposición establece los principios que deben orientar los sistemas de IA en el sector público: transparencia, explicabilidad, trazabilidad, supervisión humana, y no discriminación. Cada uno de esos principios tiene una contraparte directa en alguna de las cuatro dimensiones del framework de Singapur.
En la práctica legal, esto toma forma concreta: el profesional que utiliza herramientas de IA no puede simplemente presentar un output sin poder dar cuenta de su origen o del proceso que lo generó. Lo que exige es exactamente la dimensión 3 del MGF: trazabilidad de las decisiones del sistema, no solo del resultado.
Esto no es coincidencia. Tanto el regulador de Singapur como los ordenamientos que comienzan a reflexionar sobre IA están respondiendo al mismo problema: los sistemas de IA producen outputs sin que el operador pueda explicar el proceso, y eso genera riesgos en contextos donde la explicabilidad importa (judicial, regulatorio, médico).
El caso de Tencent como espejo técnico
El framework incluye el caso de Tencent CodeBuddy como ejemplo de implementación concreta de la dimensión 3. Lo que describe Tencent no es un sistema de control de prompts sino una arquitectura de permisos granulares: el agente de código no puede acceder a producción, no puede ejecutar comandos que no estén en la lista permitida, y cada acción queda registrada con razón y contexto.
Quienes trabajan con Claude Code o herramientas similares reconocerán el patrón: es exactamente el modelo de permisos por herramienta que implementan los runtimes modernos. La novedad del MGF es que un regulador de Estado lo tomó como referencia explícita y lo convirtió en dimensión de compliance.
Para un estudio jurídico que está evaluando si adoptar agentes IA para revisar contratos o preparar escritos: la pregunta que va a aparecer en las próximas auditorías no es “¿usan IA?”, sino “¿pueden mostrar qué hizo el sistema y por qué, y quién fue responsable de revisar el output?”.
El riesgo que el framework nombra y el sector no
La dimensión 2 introduce un concepto que el MGF llama automation bias (sesgo de automatización) y trata como riesgo técnico, no como error humano. La idea es simple: cuando un sistema parece competente, los operadores dejan de revisar con atención. El riesgo no está en que el agente falle visiblemente — está en que falle de forma plausible.
En contexto legal, eso tiene consecuencias específicas. Un agente que cita jurisprudencia incorrecta de forma confiada es más peligroso que uno que claramente no encuentra nada. Ejemplo: un sistema genera como resultado “la jurisprudencia de la CSJN en el fallo X establece que…” con cita completa (tribunal, año, expediente) — el abogado confía en la estructura de la respuesta y no verifica; después descubre que el fallo no existe. El daño es mayor que si el sistema hubiera dicho “no encontré jurisprudencia” porque el profesional basó su estrategia en una autoridad falsa.
El framework propone como contramedida el diseño activo de puntos de pausa: momentos en el flujo donde el sistema requiere confirmación humana antes de continuar, independientemente de que el output parezca correcto. Para un estudio jurídico: un punto de pausa obligatorio antes de firmar un escrito que contenga citas jurídicas generadas por IA; otro antes de ejecutar cambios en una BD de clientes; otro antes de enviar un email que representa al cliente.
Esta es la tensión que el MGF nombra: la obligación de poder dar cuenta del proceso es, en la práctica, la obligación de haber tenido esos puntos de pausa documentados. Sin registro de dónde vino la decisión y quién la revisó, el sistema pierde legitimidad ante un auditor, incluso si el output final es correcto.
Por qué este documento importa ahora
Los frameworks de Singapur tienen historial de influencia en regulaciones posteriores. El Model AI Governance Framework original de 2019-2020 anticipó varias preocupaciones que posteriormente aparecieron también en el enfoque del EU AI Act. El MGF for Agentic AI de 2026 está llegando en el momento en que los agentes autónomos pasan de demos a producción.
En Argentina, el marco normativo de IA todavía está en construcción. La Disposición 2/2023 es una recomendación, no una obligación. El BCN Dossier de julio 2025 relevó más de quince proyectos de ley sobre IA presentados en el Congreso —el estado de avance legislativo puede haber evolucionado desde esa fecha. Eso significa que quienes construyen hoy tienen un margen de decisión que va a ir cerrándose.
Adoptar los cuatro pilares del MGF como criterio de diseño antes de que sean requisito regulatorio tiene ventaja concreta: los sistemas que ya cumplen con el estándar no necesitan ser rediseñados cuando la obligación llegue. Y en industrias reguladas, el rediseño posterior siempre es más caro que el diseño correcto desde el inicio.
Checklist práctico — Evaluación de IA Agéntica para Estudios Jurídicos y Fintechs
Antes de desplegar un agente en producción, validar:
- Riesgos delimitados: ¿Qué tareas ejecuta el agente? ¿A qué sistemas accede? ¿Cuál es el daño máximo si actúa fuera de parámetros? ¿Se evaluaron riesgos de ejecución en cascada (un agente delega en otro y amplifica el error)?
- Responsabilidad ejercible: ¿Hay una persona designada como responsable? ¿Puede esa persona revisar qué hizo el sistema antes de que el output llegue al cliente/usuario final? ¿Se documentan esos puntos de pausa?
- Controles arquitecturales: ¿El agente tiene restricciones en la arquitectura (listas blancas, separación de entornos, permisos granulares) o depende solo de instrucciones en el prompt? ¿Hay logs inmutables que registren cada acción con contexto?
- Retención mínima: ¿El agente solicita solo los permisos necesarios para cada tarea? ¿Retiene datos solo por el tiempo requerido? ¿Se eliminan copias de datos sensibles después de la tarea?
- Pruebas multi-agente: Si el sistema orquesta múltiples agentes, ¿se han testeado escenarios de falla (un agente cae, el otro reintenta, se generan duplicados)?
- Cláusulas contractuales: ¿Los contratos con proveedores de IA incluyen obligaciones de auditoría, SLAs sobre trazabilidad, responsabilidad por incumplimiento, notificación de incidentes?
- Documentación auditoria: ¿Existe un registro que muestre cómo se decidió desplegar el sistema, quién lo validó y por qué?
Referencia: Model AI Governance Framework for Agentic AI v1.5 — IMDA, mayo 2026. Disposición 2/2023 JGM publicada en Boletín Oficial el 02-06-2023.
