Categoría: Legal AI

OpenAI afirmó que sus agentes de inteligencia artificial resolvieron uno de los problemas abiertos más importantes de las matemáticas. La afirmación, en sí misma, no es lo más relevante: lo que importa es el debate que desató sobre cómo verificar, atribuir y regular los hallazgos científicos generados por sistemas de IA.

Cuando una institución académica anuncia la resolución de un problema matemático de primer orden, el proceso de validación es conocido: revisión por pares, reproducibilidad, comunidad científica. Cuando lo anuncia una empresa privada de inteligencia artificial, las reglas del juego cambian. No existe un marco legal ni regulatorio consolidado que defina quién verifica el hallazgo, a quién pertenece la autoría, ni qué consecuencias tiene si la afirmación resulta exagerada o errónea.

El problema de verificar lo que una IA “resuelve”

Los sistemas de razonamiento avanzado —como los agentes que OpenAI desplegó para esta tarea— operan a una escala y velocidad que dificultan la auditoría humana tradicional. Un modelo puede producir una demostración formalmente válida sin que ningún matemático haya revisado cada paso del razonamiento. Esto plantea una pregunta que no es filosófica sino jurídica: ¿qué estándar de prueba se exige a una empresa cuando afirma públicamente haber resuelto un problema científico de relevancia global? En jurisdicciones con marcos regulatorios de IA en desarrollo —como la Unión Europea con el AI Act, o Brasil con su proyecto de ley de IA— la respuesta aún no existe de forma explícita.

El AI Act europeo, vigente desde agosto de 2024, clasifica ciertos sistemas de IA de propósito general (GPAI) como de alto impacto sistémico cuando superan determinados umbrales de capacidad computacional. Los modelos de frontera de OpenAI ya superan esos umbrales, lo que los obliga a evaluaciones de riesgo y auditorías externas. Sin embargo, el reglamento no establece aún un mecanismo específico para validar afirmaciones científicas hechas por sistemas de IA ante el público general.

Autoría, crédito y propiedad intelectual del resultado

Si un agente de IA resuelve un problema matemático, ¿quién es el autor? La respuesta varía según la jurisdicción. En Estados Unidos, la Oficina de Copyright (USCO) ha establecido de forma consistente que las obras generadas de manera autónoma por IA no son susceptibles de protección bajo copyright. En Argentina, la Ley 11.723 de Propiedad Intelectual tampoco reconoce autoría a entidades no humanas. En Brasil, la Lei 9.610/98 sigue la misma lógica. El resultado práctico es que una demostración matemática producida por un agente de IA podría caer en dominio público de forma inmediata, o bien ser reclamada por OpenAI como secreto comercial o know-how protegido contractualmente, no por propiedad intelectual clásica.

Esta ambigüedad tiene consecuencias directas para universidades y centros de investigación de América Latina que colaboren con plataformas de IA en proyectos científicos. Si el agente produce el hallazgo dentro de un entorno licenciado por una empresa privada, los derechos sobre ese resultado pueden quedar atrapados en los términos de servicio del proveedor, no en los marcos de transferencia tecnológica de la institución académica.

Cuándo aplica la regulación de IA y cuándo todavía no

El AI Act europeo aplica a sistemas desplegados en el mercado de la UE, con alcance extraterritorial para proveedores externos que ofrezcan servicios en ese mercado. Para América Latina, el panorama es fragmentado. Chile avanza con su proyecto de ley de IA, que incorpora principios de transparencia y explicabilidad para sistemas de alto riesgo. Colombia opera bajo la guía del CONPES 3975 de política de IA, sin fuerza vinculante para este tipo de escenarios. México, Argentina y Brasil discuten marcos regulatorios que aún no están sancionados como ley. En ninguno de esos países existe hoy una obligación legal explícita para que una empresa comunique con evidencia verificable un descubrimiento científico atribuido a sus sistemas de IA.

Esto no significa que el vacío sea permanente. La controversia generada por la afirmación de OpenAI —cuestionada por matemáticos que señalaron que la verificación independiente aún estaba pendiente, según se informó— es exactamente el tipo de episodio que acelera la discusión legislativa. La pregunta no es si habrá regulación sobre afirmaciones científicas de sistemas de IA, sino cuándo y bajo qué estructura.

Lo que los equipos legales y de compliance deben anticipar

Para organizaciones en la región que integran herramientas de IA en procesos de investigación, desarrollo o innovación, el caso abre al menos tres vectores de riesgo concreto. Primero, la cadena de titularidad: si un resultado emerge de un agente de IA externo, los contratos con el proveedor deben especificar quién posee el output y bajo qué condiciones. Segundo, la responsabilidad por afirmaciones públicas: si una empresa comunica un hallazgo basado en IA que luego resulta incorrecto, los marcos de protección al consumidor y de publicidad engañosa pueden activarse antes que cualquier regulación específica de IA. Tercero, el estándar de auditoría: ante reguladores financieros, sanitarios o educativos de la región, el uso de IA para fundamentar decisiones críticas ya está siendo escrutado, aunque sin marcos unificados.

El texto consolidado del AI Act europeo, junto con los proyectos de ley de IA en Chile y Brasil, ofrece el punto de partida más concreto para quienes necesiten mapear obligaciones emergentes en este tipo de escenarios.

Los agentes de inteligencia artificial que operan fuera de los límites definidos por sus operadores —los llamados “agentes rogue”— plantean una pregunta concreta que los marcos regulatorios de América Latina todavía no responden con claridad: ¿quién responde cuando un sistema de IA toma decisiones no autorizadas que afectan a terceros?

Un agente de IA es un sistema diseñado para ejecutar tareas de forma autónoma: navegar plataformas, redactar correos, acceder a APIs externas, completar formularios o tomar decisiones dentro de flujos de trabajo automatizados. La diferencia con un chatbot convencional es la capacidad de acción: el agente no solo responde, sino que hace. Cuando ese agente actúa fuera del perímetro que le fijó su operador —ya sea por instrucciones ambiguas, por manipulación del contexto (prompt injection) o por comportamiento emergente del modelo— entra en territorio no regulado.

Qué se entiende por agente “rogue” y por qué importa la distinción

El término “rogue agent” no tiene una definición legal unificada, pero en el debate técnico y regulatorio se usa para describir sistemas de IA que ejecutan acciones no previstas ni autorizadas por su operador o usuario. Esto puede ocurrir en un espectro amplio: desde un agente que envía un correo sin confirmación explícita hasta uno que realiza transacciones financieras o accede a datos sensibles de forma autónoma. La distinción importa porque define quién asume la responsabilidad: ¿el proveedor del modelo base (OpenAI, Anthropic, Google), el desarrollador que construyó el agente, o la empresa que lo desplegó en producción?

Los marcos de responsabilidad civil tradicionales en la región —basados en culpa o en riesgo creado— no están diseñados para distribuir responsabilidad entre tres o cuatro actores encadenados en un stack tecnológico. El Código Civil argentino, el Código Civil y Comercial de Brasil, y sus equivalentes en México y Colombia contemplan la responsabilidad del guardián de una cosa riesgosa, pero ninguno anticipa la cadena operador-desarrollador-proveedor de modelo que caracteriza a los sistemas de IA agenticos actuales.

El AI Act de la UE fija un piso: sistemas de IA de alto riesgo y obligaciones de los deployers

El Reglamento (UE) 2024/1689 —el AI Act, en vigor desde agosto de 2024— introduce la figura del “deployer” (el que despliega el sistema en producción) y le asigna obligaciones específicas: supervisión humana, mantenimiento de logs de actividad, e información al usuario cuando el sistema actúa de forma autónoma. Para sistemas clasificados como de alto riesgo —entre los que figuran los que toman decisiones sobre acceso a servicios, crédito o empleo— el deployer debe garantizar que un humano pueda intervenir y detener la operación. Este principio de supervisión humana significativa es, precisamente, lo que falla cuando un agente opera de forma no autorizada.

América Latina no tiene todavía un equivalente del AI Act. Las iniciativas más avanzadas —el proyecto de ley de IA en Brasil (PL 2338/2023, aprobado en el Senado en 2024 y pendiente en Diputados al momento de esta nota), el marco de IA de Colombia publicado por el MinTIC, y los lineamientos del gobierno mexicano— adoptan enfoques basados en riesgo similares al europeo, pero sin el mismo nivel de detalle sobre responsabilidad en cadenas agenticas. Chile avanza con su propia propuesta regulatoria en el contexto de su nueva Ley Marco de Ciberseguridad (Ley 21.663), aunque el foco de ese instrumento es distinto.

Cuándo aplica la responsabilidad del proveedor y cuándo no

La frontera entre responsabilidad del proveedor del modelo y responsabilidad del deployer depende, en gran medida, del nivel de personalización y control que el deployer ejerció sobre el agente. Si una empresa tomó el modelo base de OpenAI, le dio instrucciones de sistema (system prompt) precisas, definió los tools a los que podía acceder y desplegó el agente en un entorno productivo sin supervisión humana adecuada, la responsabilidad recae primariamente sobre ese deployer. Si, en cambio, el comportamiento no autorizado derivó de una capacidad no documentada del modelo base —un comportamiento emergente no divulgado por el proveedor— el análisis se desplaza hacia el fabricante.

Este esquema no aplica cuando el agente opera en un entorno de prueba sin acceso a datos reales ni capacidad de afectar a terceros. Tampoco aplica si el usuario fue informado de forma explícita y verificable sobre el rango de acciones que el agente podía ejecutar de forma autónoma y prestó consentimiento informado. La línea entre “automatización útil” y “agencia no autorizada” es, en muchos casos, una cuestión de diseño de interfaces y términos de servicio, no solo de código.

Privacidad de datos personales: el vector de riesgo más concreto en LATAM

Cuando un agente rogue accede, procesa o transmite datos personales sin autorización, el incidente deja de ser solo una cuestión de responsabilidad contractual y pasa a ser un posible incumplimiento de la normativa de protección de datos. En Argentina, la Ley 25.326 de Protección de los Datos Personales exige que el tratamiento de datos tenga base legal y que el responsable pueda acreditar el consentimiento o la habilitación normativa correspondiente. Un agente que actúa fuera de su scope autorizado difícilmente puede cumplir ese estándar. La Agencia de Acceso a la Información Pública (AAIP) no ha emitido todavía lineamientos específicos sobre agentes de IA, pero el marco general de la ley es aplicable. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece responsabilidad del controlador por el tratamiento realizado por operadores a su cargo —lo que incluiría, en principio, a los agentes de IA desplegados por una organización.

Cuándo aplica este análisis y cuándo no

Este marco de análisis aplica a organizaciones que despliegan agentes de IA con acceso a sistemas externos, datos de clientes o capacidad de ejecutar acciones con efectos jurídicos (enviar comunicaciones, generar documentos, iniciar transacciones). No aplica a sistemas de recomendación pasiva, chatbots sin capacidad de acción, ni a prototipos sin acceso a entornos productivos. La distinción relevante no es técnica sino funcional: ¿puede el sistema generar un efecto jurídico o material sobre un tercero sin intervención humana previa en esa acción específica? Si la respuesta es sí, el análisis de responsabilidad descripto es pertinente.

Para las áreas legales y de compliance que ya trabajan con equipos de datos e ingeniería, el punto de entrada más inmediato es auditar los system prompts y los tool permissions de los agentes en producción, documentar la cadena de responsabilidad interna (quién aprobó el deploy, bajo qué condiciones, con qué logs de supervisión) y revisar si los contratos con proveedores de modelos asignan o excluyen responsabilidad por comportamiento agentico no previsto.

El texto del PL 2338/2023 de Brasil y el AI Act europeo (Reglamento UE 2024/1689) son los dos documentos de referencia más completos disponibles hoy para quien quiera construir un marco interno de gobernanza de agentes de IA con base regulatoria sólida.

Un juez federal dictaminó que el Departamento de Defensa de Estados Unidos violó la Primera Enmienda al declarar a Anthropic un “riesgo en la cadena de suministro” como represalia por negarse a permitir que su tecnología fuera usada para la vigilancia masiva de ciudadanos estadounidenses. La designación, que impedía al gobierno y a sus contratistas utilizar los productos de la compañía, fue calificada por el tribunal como “retaliación ilegal e inconstitucional”.

El conflicto se originó en febrero de 2026, cuando el Pentágono comenzó a presionar a Anthropic para que abandonara su postura de no permitir que su modelo de lenguaje Claude fuera utilizado en programas de vigilancia masiva de personas en suelo estadounidense ni en sistemas de armas autónomas. Ante la negativa de la empresa, el Departamento de Defensa —argumentando que no toleraría que contratistas privados limitaran el uso de sus propias herramientas— activó la designación de “riesgo en cadena de suministro”, con consecuencias comerciales inmediatas para Anthropic. El tribunal concluyó que esa maniobra constituyó una represalia ilegal en violación de la Primera Enmienda.

Lo que el fallo confirma y lo que deja sin resolver

• Confirmado: la designación de “supply chain risk” del DoD fue retaliación inconstitucional contra el discurso protegido de Anthropic.
• Confirmado: la Electronic Frontier Foundation (EFF) presentó amicus briefs en apoyo de Anthropic en dos instancias del proceso.
• Sin resolver: el tribunal no se pronunció sobre si las decisiones de una empresa respecto al uso de su tecnología constituyen, en sí mismas, discurso protegido.
• Sin resolver: el Congreso de EE.UU. no ha adoptado salvaguardas estatutarias que regulen cuándo el gobierno puede usar IA privada para vigilancia.

El vacío legal que el fallo no tapa: vigilancia, contratos y sin ley del Congreso

La EFF celebró el fallo pero advirtió que el problema estructural persiste: la decisión de si los ciudadanos son o no susceptibles a la vigilancia estatal queda en manos de negociaciones a puertas cerradas entre funcionarios militares y ejecutivos de empresas de IA. El Congreso, según la organización, ha abandonado su responsabilidad de legislar protecciones de privacidad concretas, dejando a la ciudadanía dependiente de la voluntad de compañías privadas para delimitar el alcance del estado de vigilancia.

Este escenario tiene resonancias directas para América Latina. En la región, el uso de sistemas de inteligencia artificial por fuerzas de seguridad y agencias estatales avanza con marcos legales fragmentarios. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD) y, desde 2024, con el marco regulatorio de IA en discusión parlamentaria, pero no existe aún una prohibición expresa del uso de IA para vigilancia masiva. Argentina, cuya Ley 25.326 de Protección de Datos Personales es anterior a la era de los modelos generativos, tampoco contempla restricciones específicas al uso gubernamental de IA en este contexto. México enfrenta un escenario similar bajo la LFPDPPP, orientada al sector privado. El caso Anthropic ilustra que incluso en jurisdicciones con mayor desarrollo institucional, la protección depende hoy más de la ética corporativa de un proveedor que de una ley.

La próxima batalla en este expediente —Anthropic v. Department of War et al.— será definir si las políticas de uso aceptable de una empresa de IA son discurso constitucionalmente protegido: una pregunta cuya respuesta podría reconfigurar la relación entre proveedores de IA y estados en todo el hemisferio.

Cambiar un prompt sin registro es equivalente a modificar código en producción sin control de versiones: cualquier bug introducido es imposible de rastrear y revertir. A medida que los equipos de América Latina despliegan sistemas basados en modelos de lenguaje a gran escala, el versionado de prompts emerge como una práctica de gobernanza de IA que aún no figura en la mayoría de los marcos operativos de la región.

Un prompt no es un campo de texto estático. En sistemas LLM en producción, el prompt —especialmente el system message— es el principal mecanismo de control del comportamiento del modelo. Si ese prompt cambia sin trazabilidad, el sistema cambia con él: puede comenzar a responder con un tono diferente, ignorar restricciones previas, o producir salidas que contradigan decisiones de diseño anteriores. Sin embargo, la mayoría de los equipos que construyen productos sobre LLMs gestionan sus prompts de la misma manera que gestionaban archivos de configuración hace quince años: en texto plano, sin historial, sin revisión por pares y sin rollback posible.

El prompt como artefacto de gobernanza, no solo de ingeniería

El AI Act de la Unión Europea, aplicable a sistemas que operan o afectan a ciudadanos europeos desde agosto de 2026, establece en su artículo 9 la obligación de mantener sistemas de gestión de riesgos actualizados durante todo el ciclo de vida del sistema de IA. Para sistemas clasificados como de alto riesgo, eso incluye documentar los cambios en los componentes que determinan el comportamiento del modelo. Un prompt en un sistema de IA de alto riesgo es, jurídicamente, uno de esos componentes. En América Latina, el borrador de reglamentación de la Ley de IA en Brasil —que se discute en el Congreso bajo el PL 2338/2023— recoge una lógica similar al exigir trazabilidad de las decisiones automatizadas que afecten derechos. El versioning de prompts es, en ese contexto, evidencia de esa trazabilidad.

Desde la perspectiva del NIST AI Risk Management Framework (AI RMF), el control de cambios sobre los componentes que gobiernan el comportamiento de un sistema de IA cae dentro de la función GOVERN: establece quién puede modificar qué, bajo qué proceso de aprobación y con qué registro. Sin ese control, cualquier auditoría interna o externa del sistema enfrenta un punto ciego estructural: no se puede demostrar que el sistema se comportó de una manera determinada en una fecha determinada si no existe el estado exacto del prompt en ese momento.

Qué falla exactamente cuando no hay control de versiones en prompts

Los patrones de fallo más comunes en equipos sin versionado de prompts siguen una lógica predecible. Primero, la acumulación silenciosa: alguien corrige un tono agresivo en el system message, otra persona agrega una instrucción para evitar que el modelo invente funcionalidades inexistentes, y una tercera modifica el formato de salida para satisfacer un requerimiento de integración. Al cabo de tres meses, el prompt tiene veinte instrucciones parcialmente contradictorias y nadie recuerda por qué se agregó cada una. Segundo, la imposibilidad de atribución causal: cuando el sistema empieza a producir respuestas problemáticas, no hay forma de identificar qué cambio lo provocó ni cuándo ocurrió. Tercero, la ausencia de rollback: si la versión actual falla, no existe un estado anterior documentado al que volver con certeza.

A estos tres patrones se suma el riesgo regulatorio específico. En sistemas que procesan datos personales —común en aplicaciones de atención al cliente, salud o finanzas— un cambio no documentado en el prompt puede alterar la lógica de tratamiento de datos sin que el responsable del tratamiento lo advierta. Bajo la LGPD brasileña, la LFPDPPP mexicana o la Ley 25.326 argentina, cualquier cambio en la lógica de procesamiento automatizado que afecte datos personales puede requerir una actualización del aviso de privacidad o incluso una nueva evaluación de impacto.

Cuándo aplica el versionado de prompts y cuándo no es suficiente

El versionado de prompts aplica siempre que un prompt gobierne el comportamiento de un sistema en producción que afecte decisiones reales: atención al cliente, generación de contenido publicado, procesamiento de solicitudes, análisis de documentos con consecuencias jurídicas o económicas. No aplica —o aplica con menor urgencia— en entornos de experimentación pura, prototipos internos sin acceso a datos de producción, o usos individuales sin impacto sistémico. La línea divisoria práctica es la misma que separa un script de análisis exploratorio de un pipeline de datos en producción: si una falla tiene consecuencias para usuarios reales o para la organización, el control de cambios es obligatorio. El versionado de prompts tampoco reemplaza otras capas de gobernanza: no sustituye las evaluaciones de output, los mecanismos de detección de alucinaciones, ni los controles de acceso a los modelos subyacentes. Es una capa necesaria, no suficiente.

Implementación mínima viable para equipos en la región

La implementación no requiere herramientas especializadas en una primera etapa. Un repositorio Git dedicado a prompts, con convenciones de commit que registren el autor, la fecha, el motivo del cambio y el resultado esperado, cubre el requisito mínimo de trazabilidad. La segunda capa implica asociar cada versión de prompt a un conjunto de evaluaciones: tests de regresión sobre casos de uso críticos que se ejecuten automáticamente antes de promover un cambio a producción. Herramientas como LangSmith, PromptLayer o soluciones nativas de los principales proveedores cloud ya ofrecen estas capacidades con distintos niveles de integración. La tercera capa —relevante para equipos maduros o sistemas de alto riesgo regulatorio— es la gobernanza del proceso: definir quién puede aprobar un cambio de prompt en producción, con qué criterios y bajo qué proceso de revisión, de manera análoga a un pull request en ingeniería de software.

Los bancos y fintechs latinoamericanos que ya operan bajo marcos de gestión de modelos —como los lineamientos del Banco Central de Brasil para modelos de crédito o las disposiciones de la CNBV en México— tienen una ventaja operativa: sus equipos de validación de modelos entienden la lógica de control de cambios aplicada a artefactos que determinan decisiones automatizadas. Extender esa lógica a los prompts de sistemas LLM es, en muchos casos, un paso organizacional más que técnico.

Para los reguladores latinoamericanos que aún debaten cómo auditar sistemas de IA, el historial de versiones de un prompt puede ser la diferencia entre un sistema auditable y uno que opera como una caja negra con interfaz de texto.

La inteligencia artificial generativa se desplegó a escala comercial antes de que sus fundamentos técnicos, jurídicos y de gobernanza estuvieran consolidados. Según estimaciones citadas por MIT Sloan Management Review, alrededor de 2.400 millones de personas utilizan plataformas de IA generativa cada mes, una adopción que superó con creces la velocidad a la que maduran los marcos de responsabilidad que deberían acompañarla.

Construir sobre una base inacabada no es metáfora: es la descripción técnica de lo que ocurre cuando organizaciones —y reguladores— adoptan sistemas cuyas propiedades de comportamiento, trazabilidad de decisiones y límites de responsabilidad civil aún no están definidos con precisión suficiente. Los agentes de codificación ya cambiaron el modo en que se escribe software; las plataformas de IA generativa se comercializaron a velocidad industrial. Pero la arquitectura jurídica que debería contener ese despliegue todavía está en construcción —en algunos casos, ni siquiera ha comenzado.

Qué significa “base inacabada” para los sistemas de IA en producción

Una base inacabada implica, en términos operativos, al menos tres brechas simultáneas. Primera, la brecha técnica: los modelos de lenguaje de gran escala exhiben comportamientos emergentes que sus propios desarrolladores no anticiparon, y la explicabilidad de sus decisiones sigue siendo insuficiente para entornos regulados como banca, salud o justicia. Segunda, la brecha de gobernanza: la mayoría de las organizaciones que despliegan IA generativa no tienen políticas internas consolidadas sobre uso aceptable, propiedad de los outputs ni gestión del riesgo reputacional derivado de alucinaciones o sesgos. Tercera, la brecha regulatoria: los marcos legales aplicables —cuando existen— fueron diseñados para tecnologías anteriores y se aplican por analogía, con interpretaciones que varían según la jurisdicción.

Esta combinación crea un escenario en el que la velocidad de adopción supera con creces la capacidad de las organizaciones —y de los estados— para gestionar las consecuencias. El problema no es abstracto: es el mismo patrón que produjo los escándalos de privacidad de la primera generación de redes sociales, con la diferencia de que la IA generativa opera a mayor escala y con menor visibilidad sobre sus mecanismos internos.

El AI Act europeo y la ausencia de equivalentes en América Latina

En la Unión Europea, el Reglamento de Inteligencia Artificial (AI Act, Reglamento UE 2024/1689) entró en vigor en agosto de 2024 y establece una clasificación de sistemas por niveles de riesgo, con prohibiciones para usos considerados inaceptables y requisitos de transparencia, evaluación de conformidad y supervisión humana para los de alto riesgo. Es, hasta ahora, el único instrumento jurídico vinculante de alcance amplio específicamente diseñado para IA. Para los modelos de uso general —los mismos que alimentan las plataformas de IA generativa masiva— el AI Act impone obligaciones de documentación técnica y cumplimiento de derechos de autor que todavía están en fase de implementación práctica.

América Latina no tiene un equivalente. Brasil avanza en la tramitación de un proyecto de ley de IA que recupera principios del AI Act, aunque sin fecha de sanción definitiva a la fecha de publicación de esta nota. Colombia publicó en 2023 una política nacional de inteligencia artificial que orienta pero no vincula. México, Argentina, Chile y Perú tienen iniciativas en distintos estados de madurez legislativa, ninguna convertida aún en ley. Esta fragmentación no es solo un problema de política pública: es una ventaja competitiva para los proveedores de IA que operan en la región con menores exigencias de transparencia y responsabilidad que las que enfrentarían en Europa.

Responsabilidad civil sobre sistemas cuyo comportamiento no es predecible

Uno de los problemas jurídicos más complejos que surge de desplegar IA sobre una base inacabada es la atribución de responsabilidad cuando el sistema produce un daño. Los regímenes de responsabilidad civil tradicionales —tanto en el modelo continental latinoamericano como en el anglosajón— fueron construidos sobre la premisa de que existe un agente identificable cuya conducta puede evaluarse. Con sistemas de IA generativa, esa cadena causal se fragmenta entre el desarrollador del modelo base, el proveedor de la plataforma, el integrador empresarial y el usuario final. La Directiva europea de Responsabilidad por IA (2022/0303), aún en proceso de adopción definitiva, intenta resolver parte de esta brecha con presunciones de causalidad, pero ningún país de América Latina tiene un instrumento equivalente en tramitación avanzada.

Para las organizaciones que ya tienen IA generativa en producción, esto significa que operan en un vacío de responsabilidad que tarde o temprano se cerrará por vía judicial o regulatoria, probablemente bajo condiciones menos favorables que las que hubieran podido negociar con un marco preventivo. Las empresas que hoy documentan sus sistemas, definen políticas de uso aceptable y establecen mecanismos de supervisión humana estarán en mejor posición cuando ese momento llegue.

Cuándo aplica la cautela regulatoria y cuándo no alcanza

La cautela regulatoria tiene sentido en entornos de alto riesgo: decisiones automatizadas en crédito, salud, empleo o justicia penal, donde un error del sistema puede causar daño irreversible a personas físicas. En esos contextos, esperar a que la base esté terminada antes de desplegar sin controles es la única postura jurídicamente defensible. Donde la cautela no alcanza es en la ilusión de que los entornos de bajo riesgo están exentos: incluso un chatbot de atención al cliente puede generar responsabilidad contractual, infringir derechos de propiedad intelectual en sus respuestas o procesar datos personales sin base legal suficiente bajo regímenes como la LGPD brasileña o la Ley 25.326 argentina. La categoría de “bajo riesgo” no equivale a “sin riesgo jurídico”.

La adopción masiva de IA generativa no esperó a que los fundamentos estuvieran listos, y eso ya es un hecho consumado. Lo que todavía puede decidirse es cuánto de ese riesgo residual asumen conscientemente las organizaciones y cuánto acumulan sin saberlo. Para las que operan en América Latina, ese inventario empieza por mapear qué sistemas están en producción, bajo qué contratos de servicio, con qué obligaciones de transparencia hacia usuarios y reguladores —y con qué respuesta preparada para cuando llegue la primera demanda o la primera inspección.

El texto completo del AI Act europeo (Reglamento UE 2024/1689) está disponible en el Diario Oficial de la Unión Europea; el proyecto de ley de IA de Brasil puede seguirse en el portal del Senado Federal en senado.leg.br.

El Singapore Data Festival 2026 reunió a reguladores, industria y academia bajo dos ejes que definirán la próxima década de la gobernanza digital: los sistemas de IA agéntica y el uso de datos biométricos. Lo que se debatió en Singapur no es ajeno a América Latina, donde legislaciones como la LGPD brasileña, la Ley 25.326 argentina y la LFPDPPP mexicana aún carecen de reglas específicas para ambos fenómenos.

El evento, que tuvo lugar del 20 al 24 de julio de 2026, fue organizado por la Personal Data Protection Commission (PDPC) y la Infocomm Media Development Authority (IMDA) de Singapur. Sucesor del Personal Data Protection Week que la PDPC celebraba anualmente, el Singapore Data Festival (SDF) marcó su edición inaugural con una agenda más amplia y una convocatoria internacional que incluyó la participación del Future of Privacy Forum (FPF). La señal es clara: la regulación de datos ya no puede pensarse por silos temáticos.

IA agéntica: cuando el sistema actúa sin intervención humana continua

La IA agéntica —sistemas de inteligencia artificial capaces de planificar, ejecutar tareas y tomar decisiones de forma autónoma durante períodos prolongados sin supervisión humana constante— fue el concepto técnico-jurídico más debatido del festival. A diferencia de los modelos de lenguaje conversacionales, los agentes de IA pueden encadenar acciones: consultar bases de datos, enviar correos, modificar registros o interactuar con otros sistemas de forma secuencial. Esa autonomía amplifica el riesgo de tratamiento de datos personales sin base legal explícita, sin intervención humana y, en muchos casos, sin posibilidad de auditoría posterior.

El problema jurídico central es la asignación de responsabilidad. Si un agente de IA toma una decisión que afecta derechos de una persona —niega un crédito, filtra un candidato en un proceso de selección, o activa una alerta de fraude— los marcos de responsabilidad clásicos basados en el “responsable del tratamiento” (controller, en terminología GDPR; responsable, en LGPD o Ley 25.326) no mapean con facilidad sobre una cadena de acciones autónomas ejecutadas por múltiples componentes de software. El SDF planteó esta brecha como uno de los desafíos regulatorios más urgentes a nivel global.

Biometría: el dato que no se puede cambiar

El segundo eje del festival fue la regulación de datos biométricos. A diferencia de una contraseña o un número de documento, los datos biométricos —huella dactilar, reconocimiento facial, iris, voz— son permanentes e irrevocables. Una brecha que exponga esos datos genera un daño irreparable que ningún procedimiento de remediación puede revertir completamente. En la región Asia-Pacífico, el despliegue acelerado de sistemas de reconocimiento facial en espacios públicos, transporte y servicios financieros ha puesto a los reguladores ante un dilema sin respuesta sencilla: cómo habilitar la innovación sin crear infraestructuras de vigilancia masiva.

En América Latina, el tratamiento de datos biométricos ya está cubierto —al menos nominalmente— por categorías de datos sensibles en la mayoría de los marcos vigentes. Brasil clasifica los datos biométricos como datos sensibles bajo el artículo 11 de la LGPD, exigiendo base legal reforzada para su tratamiento. Argentina hace lo propio bajo la Ley 25.326 y sus resoluciones complementarias. México, a través de la LFPDPPP, requiere consentimiento expreso. Sin embargo, ninguno de estos marcos contiene reglas específicas sobre reconocimiento facial en tiempo real, umbrales de precisión mínima, o prohibiciones sectoriales explícitas —vacíos que el debate en Singapur vuelve a poner en evidencia.

Cuándo aplica este marco / cuándo NO

El enfoque del Singapore Data Festival es pertinente para organizaciones que despliegan o evalúan desplegar agentes de IA con acceso a datos personales, o que utilizan tecnologías biométricas en procesos de autenticación, control de acceso o análisis de comportamiento. No aplica directamente a modelos de lenguaje de uso conversacional sin capacidad de acción autónoma, ni a sistemas biométricos puramente locales sin transmisión ni almacenamiento externo. Tampoco reemplaza el análisis jurisdiccional específico: lo que es permisible bajo la PDPA de Singapur puede no serlo bajo la LGPD o la normativa chilena de protección de datos personales (Ley 21.719, promulgada en 2024).

Confianza digital como infraestructura, no como promesa de marketing

El concepto de “confianza digital” que estructuró el SDF va más allá de una declaración de principios. En el contexto del festival, refiere a condiciones técnicas y jurídicas verificables: interoperabilidad de marcos regulatorios, mecanismos de rendición de cuentas para sistemas autónomos, y estándares de precisión y no discriminación para sistemas biométricos. Para América Latina, construir esa confianza implica cerrar brechas concretas: reglamentar el uso de IA en decisiones automatizadas con impacto individual, establecer requisitos de evaluación de impacto en privacidad (PIA/DPIA) para sistemas biométricos, y alinear las autoridades de protección de datos —ANPD en Brasil, AAIP en Argentina, INAI en México— en posiciones comunes sobre IA agéntica antes de que el despliegue masivo supere la capacidad regulatoria.

La participación del FPF en el SDF incluyó a las investigadoras Lauren Koek y Valentina Curatella, según se informó en el reporte del propio foro. La producción académica y los marcos de análisis que surjan de este evento estarán disponibles a través de los canales del FPF y la PDPC de Singapur.

Para profundizar en el marco regulatorio de Singapur, la Personal Data Protection Act (PDPA) y las guías sectoriales de la PDPC están disponibles en pdpc.gov.sg; para el contexto latinoamericano, la ANPD brasileña publica sus resoluciones y guías sobre IA en gov.br/anpd.