Blog

  • Policías ocultan uso de tecnología de vigilancia para evitar escrutinio público

    Policías ocultan uso de tecnología de vigilancia para evitar escrutinio público

    Agencias policiales en Estados Unidos están instruyendo a sus oficiales a no mencionar —ni en detenciones ni en informes— el uso de lectores automatizados de patentes (ALPR) y otras tecnologías de vigilancia. La práctica no es nueva, pero su sistematización en políticas escritas expone una tensión directa entre el derecho ciudadano a conocer el uso de fondos públicos y la discrecionalidad operativa que las fuerzas de seguridad se autoasignan.

    Los ALPR (Automated License Plate Readers) son cámaras fijas o móviles que capturan y registran las patentes de vehículos en tiempo real, vinculándolas a bases de datos con geolocalización y marcas temporales. Junto con los simuladores de torres celulares (IMSI catchers) y el reconocimiento facial, conforman el núcleo de lo que en el debate anglosajón se denomina “spy tech” policial: herramientas de recolección masiva de datos sobre movimientos e identidades sin intervención judicial previa y, en muchos casos, sin conocimiento de los afectados.

    El condado de Iowa que prohíbe mencionar las cámaras en los informes

    La publicación 404 Media reveló que un condado en Iowa distribuyó entre sus efectivos una política de uso del sistema ALPR del proveedor Flock que incluye instrucciones en mayúsculas: “NO MENCIONE EL USO DE ALPR A LOS OCUPANTES DEL VEHÍCULO” y “NO MENCIONE EL USO DE ALPR EN SU INFORME O DENUNCIA A MENOS QUE SEA ABSOLUTAMENTE NECESARIO”. En lugar de ello, los agentes deben indicar que utilizaron “recursos del condado”. En Houston, según la misma fuente, la instrucción es ser “tan vago como sea permitido” al explicar los motivos de una intervención. Estas directivas no son errores aislados de redacción: son políticas escritas, aprobadas institucionalmente.

    La Electronic Frontier Foundation (EFF) señala que estas prácticas generan al menos tres daños concretos: impiden que los ciudadanos cuestionen en qué se gastan los fondos públicos destinados a tecnología de vigilancia; bloquean la cadena de descubrimiento probatorio que permite a los defensores impugnar la evidencia recolectada; y ocultan las tácticas a los propios jueces que deberían supervisar su legalidad. Muchos de los contratos con proveedores como Flock se firman con escasa o nula participación pública, lo que agrava el problema de accountability.

    Cuándo aplica la obligación de revelar y cuándo los departamentos eluden esa carga

    En el sistema jurídico estadounidense, la regla de exclusión y las obligaciones de descubrimiento (Brady/Giglio) exigen que la fiscalía revele al imputado los métodos y evidencias usados en su contra. Cuando un departamento instruye a sus agentes a omitir el uso de ALPR en los informes, esa cadena de revelación se corta antes de llegar al expediente judicial. La defensa no puede impugnar lo que no sabe que existe. La práctica también evade las solicitudes de registros públicos (equivalente funcional del acceso a la información pública), porque si no hay mención en los documentos internos, no hay nada que entregar. La ocultación, en definitiva, no es solo una decisión de relaciones públicas: tiene efectos jurídicos directos sobre el debido proceso.

    América Latina: los mismos sistemas, marcos de transparencia más débiles

    El debate importa para la región porque los mismos proveedores —y tecnologías equivalentes— operan en ciudades latinoamericanas. Buenos Aires, Ciudad de México, Bogotá y Santiago han expandido sus redes de cámaras de reconocimiento facial y lectura de patentes en los últimos años, con contratos cuya documentación técnica rara vez es accesible al público. A diferencia de Estados Unidos, donde existen leyes estatales de acceso a la información con plazos y sanciones concretas, en varios países de la región el derecho de acceso a la información pública coexiste con marcos sectoriales difusos para tecnología policial. En Argentina, la Ley 27.275 de Acceso a la Información Pública obliga a los organismos del Estado a responder solicitudes, pero no existe una regulación específica que exija a las fuerzas de seguridad documentar los sistemas de vigilancia automatizada que utilizan. En México, el Instituto Nacional de Transparencia (INAI) ha tramitado solicitudes sobre uso de reconocimiento facial, pero la cobertura es desigual entre municipios. Brasil cuenta con la Lei de Acesso à Informação (Ley 12.527/2011), aunque tampoco tiene un estándar específico para tecnología de vigilancia policial.

    Lo que el caso estadounidense pone en evidencia es que la ausencia de una regulación específica sobre vigilancia automatizada no es neutralidad: es un espacio que las instituciones tienden a ocupar con discrecionalidad creciente. Sin obligación expresa de registrar qué sistemas se usaron en cada detención, la cadena de auditoría se rompe antes de que cualquier ciudadano pueda activarla.

    La pregunta para los legisladores y autoridades de transparencia de la región no es si estas tecnologías se usan —se usan— sino si existe algún mecanismo que obligue a documentar ese uso antes de que llegue a un expediente judicial o, directamente, no llegue nunca.

  • IA y matemáticas: qué implica que OpenAI diga haber resuelto un problema abierto

    IA y matemáticas: qué implica que OpenAI diga haber resuelto un problema abierto

    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.

  • 220 millones de registros de viajeros expuestos: nueve años de datos aéreos filtrados

    220 millones de registros de viajeros expuestos: nueve años de datos aéreos filtrados

    Una brecha masiva expuso 220 millones de registros de pasajeros aéreos acumulados durante nueve años, incluyendo datos de pasaportes e información de identificación personal, según se informó el 8 de septiembre de 2026. El volumen y la antigüedad del dataset filtrado lo ubican entre los incidentes de mayor escala registrados en la industria de aviación.

    Según se informó, la filtración comprende registros generados entre aproximadamente 2017 y 2026, con datos que incluirían información de pasajeros, detalles de documentos de viaje y, según se indicó, números de pasaporte. No se ha confirmado públicamente qué aerolínea u operador de sistemas de reservas es el origen de los datos, ni si el acceso fue producto de un ataque externo o de una exposición por configuración incorrecta de infraestructura. Tampoco hay confirmación sobre el actor que habría obtenido o publicado los registros.

    Datos confirmados y variables sin verificar

    • Volumen reportado: 220 millones de registros de viajeros
    • Período cubierto: nueve años de información acumulada, según se informó
    • Tipos de datos comprometidos: información de pasajeros y detalles de pasaportes, según se informó
    • Aerolínea u operador de origen: no confirmado al cierre de esta nota
    • Vector de ataque o causa: no confirmado
    • Autoridades regulatorias notificadas: no hay confirmación pública

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta el momento es el volumen reportado y la naturaleza de los datos involucrados: información de identidad y documentos de viaje, categorías de alta sensibilidad bajo cualquier marco de protección de datos personales vigente. Lo que permanece sin verificar es la identidad del titular de los datos, el mecanismo de exposición y si alguna autoridad de control fue notificada. Tampoco está claro si los registros corresponden a una sola aerolínea, a un agregador de datos del sector o a un sistema de gestión de reservas (PNR) compartido entre múltiples operadores. Hasta que esas variables se confirmen, el alcance real del daño a personas físicas es imposible de determinar con precisión.

    Para América Latina, un incidente de esta naturaleza activa obligaciones inmediatas en múltiples jurisdicciones. Brasil exige notificación a la ANPD y a los titulares afectados en casos de riesgo relevante bajo la LGPD (Lei 13.709/2018). Argentina obliga a notificar a la AAIP conforme a la Ley 25.326 y su Disposición 4/2019 cuando el incidente involucra datos sensibles o puede causar daño a los titulares. México, bajo la LFPDPPP, establece la misma obligación para responsables que operan en el país. Si alguna de las aerolíneas afectadas tiene operaciones activas en la región —lo que es altamente probable dado el volumen de registros— esas obligaciones se activan con independencia de dónde estén almacenados los servidores.

    El próximo hito crítico es la identificación pública del titular de los datos: desde ese momento, los plazos de notificación a autoridades y titulares comenzarán a correr en cada jurisdicción donde la entidad opere.

  • Gobernanza de datos: el caso para pelear el presupuesto de TI

    Gobernanza de datos: el caso para pelear el presupuesto de TI

    La gobernanza de datos sigue perdiendo la batalla presupuestaria frente a infraestructura, ciberseguridad e inteligencia artificial en la mayoría de las organizaciones de la región. El argumento ya no puede ser solo técnico: quien conduce datos necesita hablar el idioma del CFO.

    Durante años, la gobernanza de datos fue tratada como un proyecto de cumplimiento o, en el mejor caso, como un habilitador silencioso de otros proyectos más visibles. El resultado es predecible: los presupuestos de TI se asignan a lo que tiene un caso de negocio claro y urgente, y la gobernanza rara vez llega con uno. Eso está cambiando, aunque despacio, y la presión viene de dos frentes simultáneos: los reguladores que exigen trazabilidad sobre datos personales y activos de IA, y los propios equipos de datos que no pueden escalar sin estructuras formales de ownership y calidad.

    Por qué la gobernanza de datos pierde frente a proyectos más visibles

    El problema central es de narrativa, no de relevancia. Un proyecto de migración a la nube tiene un costo visible, un plazo y un entregable. Un programa de gobernanza de datos entrega reducción de riesgo, consistencia en reportes y habilitación de analítica confiable, beneficios que son difíciles de monetizar en una sola línea de presupuesto. Según el marco DAMA-DMBOK, la gobernanza de datos es la función que define autoridad, responsabilidades y toma de decisiones sobre los activos de datos de una organización. Ese mandato abarca desde la definición de data stewards —responsables operativos del dato— hasta los procesos de data lineage (trazabilidad del origen, transformación y consumo de cada dataset), pasando por catálogos, políticas de calidad y gestión del ciclo de vida del dato. Ninguna de esas capacidades aparece sola en un dashboard de KPIs de negocio.

    El EDM Council, a través de su marco DCAM (Data Capability Assessment Model), propone cuantificar la madurez de governance en capabilities medibles y vincularlas a pérdidas económicas concretas: decisiones tomadas sobre datos duplicados, reportes regulatorios con errores que generan observaciones, o proyectos de machine learning que fracasan por falta de datos etiquetados y confiables. Ese lenguaje —pérdida evitable, costo de retrabajo, riesgo regulatorio con multa asociada— es el que abre conversaciones en comités de presupuesto.

    Cuándo aplica / cuándo NO

    Invertir en un programa formal de gobernanza de datos tiene sentido cuando la organización opera con múltiples fuentes de datos que alimentan decisiones críticas, cuando hay obligaciones regulatorias de reportar datos con trazabilidad —como las exigidas por la Comisión Nacional Bancaria y de Valores en México, el Banco Central de la República Argentina bajo la Comunicación A 7724 o la Comisión de Valores de Brasil—, o cuando los proyectos de IA generativa están frenados por falta de confianza en los datos de entrenamiento. No es la solución correcta para organizaciones en etapa temprana con un único sistema de registro y menos de diez personas consumiendo datos: en ese caso, el esfuerzo de governance supera el beneficio. La gobernanza escala con la complejidad; no es una capacidad que se instala de una vez, sino que crece con el volumen de actores, sistemas y decisiones que dependen del dato.

    El argumento regulatorio en América Latina ya es concreto

    En la región, la presión regulatoria está construyendo el caso de negocio que los equipos de datos no lograron construir solos. Brasil exige bajo la Lei Geral de Proteção de Dados (LGPD) que las organizaciones sean capaces de demostrar el ciclo de vida de los datos personales que tratan, lo que requiere capacidades equivalentes a data lineage y catálogo de activos. Argentina, a través de la Agencia de Acceso a la Información Pública (AAIP), ha intensificado la revisión de medidas de seguridad en tratamientos de datos personales amparados por la Ley 25.326. Colombia avanza en la implementación de su régimen de protección de datos bajo la Ley 1581 con inspecciones de la Superintendencia de Industria y Comercio. En todos esos contextos, la gobernanza de datos deja de ser una iniciativa opcional para convertirse en un requisito de operación.

    El CDO o Data Lead que lleva este argumento al comité de presupuesto tiene que presentar tres números: el costo potencial de una multa regulatoria por incapacidad de demostrar tratamiento lícito de datos, el costo de retrabajo en reportes por inconsistencias en datos maestros, y la estimación de proyectos de analítica o IA que no pudieron lanzarse por falta de datos confiables. Con esos tres números sobre la mesa, la conversación cambia. El paso siguiente es mapear cuáles de las diez capabilities del CDMC (Data Management Capability Assessment) ya existen informalmente en la organización y cuáles requieren inversión incremental: frecuentemente el 40% de la capacidad ya está presente, aunque sin formalizar ni medir.

    Governance sin presupuesto propio: el modelo no invasivo como punto de entrada

    Bob Seiner, referente del enfoque Non-Invasive Data Governance, sostiene que la gobernanza más efectiva formaliza lo que la organización ya hace, en lugar de imponer procesos nuevos desde cero. Ese enfoque es especialmente útil en contextos de presupuesto limitado: identificar quiénes ya toman decisiones sobre datos críticos, documentar esas responsabilidades como data stewardship formal, y construir desde ahí hacia políticas y catálogos. Es una entrada de bajo costo que genera evidencia de valor antes de pedir una línea presupuestaria propia. En empresas medianas de Brasil, Argentina o México, ese modelo ha permitido avanzar en madurez de governance sin requerir la creación de un equipo dedicado desde el día uno.

    Para profundizar en los marcos de referencia mencionados, el DAMA-DMBOK está disponible en dama.org y el modelo CDMC del EDM Council puede consultarse en edmcouncil.org; ambos ofrecen guías de autoevaluación que pueden servir como base para el caso de inversión ante la dirección.

  • La renuncia Clifford: cuando el gobierno de datos de salud falla desde adentro

    La renuncia Clifford: cuando el gobierno de datos de salud falla desde adentro

    Una renuncia de alto perfil en el sector salud volvió a poner sobre la mesa una pregunta incómoda: ¿quién responde cuando los datos clínicos se gestionan sin accountability real? El caso, identificado como “la renuncia Clifford” en medios especializados, no es un episodio aislado — es un síntoma de un problema estructural en la gobernanza de datos de salud que la región no puede ignorar.

    Los datos de salud ocupan la categoría más sensible en prácticamente todos los marcos legales de protección de datos personales vigentes. Son inmutables en su núcleo —un diagnóstico no se puede cambiar como una contraseña—, se generan de forma continua a lo largo de la vida de una persona, y su exposición o mal uso tiene consecuencias que van desde la discriminación laboral hasta la denegación de cobertura de seguros. Esa asimetría de riesgo exige un nivel de madurez en gobernanza de datos que pocas organizaciones de salud han alcanzado.

    Qué revela una renuncia sobre el ownership del dato clínico

    Cuando un ejecutivo o funcionario de alto rango abandona una organización de salud citando —implícita o explícitamente— desacuerdos sobre cómo se gestionan los datos, el problema raramente es técnico. Según se informó en relación con el caso Clifford, la tensión de fondo involucra decisiones sobre acceso, uso secundario y control de datos clínicos tomadas sin los controles de gobernanza adecuados. En términos de DAMA-DMBOK, esto apunta a una falla en dos capacidades críticas: data ownership y data stewardship. Sin un data steward designado con autoridad real sobre los datos clínicos —no solo responsabilidad nominal—, las decisiones sobre quién accede, con qué propósito y bajo qué retención quedan en un vacío organizacional que tarde o temprano produce una crisis.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica la trazabilidad del dato sensible como una capability no negociable para organizaciones que procesan información de salud en entornos cloud. La ausencia de data lineage documentado —es decir, el registro auditable de cómo se originó un dato, cómo fue transformado y a dónde fue entregado— es precisamente lo que permite que decisiones cuestionables queden sin registro formal y, por lo tanto, sin consecuencia.

    Cuándo aplica este riesgo de gobernanza — y cuándo NO

    Este tipo de riesgo aplica cuando una organización de salud centraliza datos clínicos de múltiples fuentes (historias clínicas electrónicas, laboratorios, wearables, aseguradoras) sin un marco de gobernanza que defina ownership por dominio, políticas de acceso diferenciadas por sensibilidad, y un proceso de change management que registre quién aprobó qué decisión sobre el dato. No aplica —o aplica con menor urgencia— en organizaciones que operan con datos completamente anonimizados bajo estándares auditables, o en sistemas de salud pública con marcos de acceso restringido y control parlamentario. La distinción importa porque el error más frecuente es aplicar controles de gobernanza uniformes sin distinguir entre datos clínicos identificables, datos pseudonimizados con llave de reidentificación, y datos efectivamente anonimizados.

    El marco legal en LATAM: LGPD, Ley 25.326 y el silencio de los reglamentos sectoriales

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) clasifica los datos de salud como datos sensibles en su artículo 11 y establece condiciones de tratamiento más restrictivas, incluyendo la obligación de realizar evaluación de impacto cuando el tratamiento pueda generar riesgo significativo. La Autoridade Nacional de Proteção de Dados (ANPD) ha señalado el sector salud como prioritario en su agenda de fiscalización para 2025-2026. En Argentina, la Ley 25.326 protege los datos de salud como categoría especial desde el año 2000, pero su reglamentación en el sector sanitario sigue fragmentada entre el Ministerio de Salud, las obras sociales reguladas por la Superintendencia de Servicios de Salud, y las clínicas privadas que operan sin auditorías sistemáticas de gobernanza de datos. México, por su parte, cuenta con la LFPDPPP y normas técnicas específicas del sector salud, pero la articulación entre el INAI y la Secretaría de Salud en materia de supervisión de datos clínicos continúa siendo débil en la práctica.

    Lo que el caso Clifford hace visible es la brecha entre el marco legal —que en la mayoría de los países de la región existe y es razonablemente robusto para datos sensibles— y la madurez operativa de las organizaciones de salud para implementarlo. Tener una política de protección de datos no equivale a tener gobernanza de datos. La política dice qué se debe hacer; la gobernanza define quién lo hace, cómo se audita, y qué pasa cuando alguien toma una decisión equivocada.

    Tres acciones concretas para CDOs en organizaciones de salud

    • Mapear el inventario de datos clínicos por nivel de sensibilidad y asignar un data steward con nombre, no con cargo genérico. Si hoy no podés responder en menos de 24 horas “quién aprobó el acceso de este sistema a estos datos”, hay un gap de ownership que necesita resolverse antes de la próxima auditoría.
    • Revisar si el data lineage cubre los flujos desde el sistema de origen clínico hasta cualquier plataforma analítica o de inteligencia artificial que consuma esos datos. El CDMC del EDM Council establece esto como capability de nivel 2; muchas organizaciones de salud en LATAM operan aún en nivel 0 o 1.
    • Establecer un proceso documentado de decisiones de gobernanza —quién puede autorizar un uso secundario de datos clínicos, con qué criterios, y con qué registro auditable. Este proceso debe sobrevivir la salida de cualquier ejecutivo, incluido el CDO.

    Las renuncias de alto perfil en organizaciones de salud no son el problema — son el aviso de que el problema ya existe. Para quienes gestionan datos clínicos en la región, el texto de referencia para construir ese proceso desde la base sigue siendo la Guía de Implementación de la LGPD para el sector salud publicada por la ANPD, disponible en el sitio oficial de la autoridad brasileña.

  • Agentes de IA que actúan sin autorización: qué implica jurídicamente

    Agentes de IA que actúan sin autorización: qué implica jurídicamente

    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.

  • Brecha en Mathspace expone datos de 1,07 millones de usuarios en Australia y Nueva Zelanda

    Brecha en Mathspace expone datos de 1,07 millones de usuarios en Australia y Nueva Zelanda

    Una brecha de seguridad en Mathspace, plataforma educativa de matemáticas, comprometió los datos de 1.079.819 personas en Australia y Nueva Zelanda tras el acceso no autorizado a un sistema interno de reportes. La compañía confirmó el incidente el 3 de septiembre de 2026.

    El acceso no autorizado afectó a un sistema de reportes interno desde el cual terceros descargaron información de usuarios. Los registros comprometidos corresponden a cuatro grupos: estudiantes, padres o tutores, docentes y personal de Mathspace. La empresa divulgó el incidente cuatro días después de confirmarlo, el 7 de septiembre de 2026, según informó DataBreaches.net. Hasta el momento no se ha publicado información sobre el vector de ataque ni sobre la identidad de los responsables.

    Datos confirmados al 7 de septiembre de 2026

    • Total de afectados: 1.079.819 personas en Australia y Nueva Zelanda
    • Poblaciones impactadas: estudiantes, padres o tutores, docentes y personal interno
    • Vector comprometido: sistema interno de reportes (acceso y descarga no autorizados)
    • Fecha de confirmación por parte de Mathspace: 3 de septiembre de 2026
    • Tipos de datos expuestos: nombres; información adicional no detallada públicamente hasta el cierre de esta nota

    Qué se sabe y qué falta confirmar sobre el alcance real

    Lo confirmado es el acceso y la descarga de registros desde el sistema de reportes, así como la cantidad de afectados y su categoría. Lo que permanece sin verificar incluye el tipo completo de campos expuestos más allá de los nombres, la duración del acceso no autorizado, y si los datos ya circulan en foros o mercados de datos robados. Tampoco se ha informado si la Oficina del Comisionado de Información de Australia (OAIC), autoridad competente bajo el Privacy Act 1988 y el Notifiable Data Breaches scheme, ya recibió la notificación formal requerida por ley. El NDB scheme obliga a notificar a la OAIC y a los afectados cuando una brecha es susceptible de causar daño serio, plazo que en la práctica se mide en días desde que la organización toma conocimiento.

    El perfil de los afectados es particularmente sensible: una proporción significativa son menores de edad en contexto escolar. En jurisdicciones de América Latina con legislaciones de protección de datos personales —como la Ley 25.326 en Argentina, la LGPD en Brasil o la LFPDPPP en México— los datos de menores reciben tratamiento agravado y las notificaciones a autoridades de control tienen plazos estrictos. Un incidente de esta naturaleza, si ocurriera con una plataforma EdTech operando en la región, activaría de inmediato los protocolos ante la AAIP (Argentina), la ANPD (Brasil) o el INAI (México), además de las obligaciones de notificación a los titulares.

    El próximo hito crítico es la notificación formal a la OAIC y la divulgación completa de los campos de datos comprometidos, información que determinará si el alcance real del daño supera lo hasta ahora comunicado.

  • Dos organizaciones con el mismo nombre, dos ataques, una sola la divulgó

    Dos organizaciones con el mismo nombre, dos ataques, una sola la divulgó

    Dos entidades médicas estadounidenses llamadas “Nephrology Associates” sufrieron ciberataques en 2026. Solo una de ellas lo divulgó públicamente. El silencio de la segunda plantea preguntas directas sobre obligaciones de notificación que también aplican en América Latina.

    El caso fue reportado por DataBreaches.net el 3 de septiembre de 2026 luego de que el sitio detectara lo que inicialmente pareció ser un doble ataque a una misma víctima. La investigación posterior confirmó que se trata de dos organizaciones de salud distintas, sin relación entre sí, que coinciden en el nombre. El primer incidente ocurrió el 7 de marzo e involucra a la entidad con sede en Kansas. Esa organización cumplió con los pasos de notificación requeridos bajo la normativa federal estadounidense (HIPAA) y lo hizo público. La segunda entidad, hasta la fecha de publicación del reporte, no había realizado ninguna divulgación.

    Datos confirmados sobre los dos incidentes

    • Dos entidades distintas con el nombre “Nephrology Associates” fueron atacadas en 2026.
    • El incidente de Kansas se registró el 7 de marzo de 2026 y fue divulgado conforme a HIPAA.
    • La segunda entidad no había realizado ninguna divulgación pública al 3 de septiembre de 2026, según DataBreaches.net.
    • DataBreaches.net confirmó que ambas organizaciones son independientes y no están relacionadas entre sí.

    Qué se sabe y qué falta confirmar

    Lo confirmado es que ambas entidades fueron atacadas y que solo una notificó. Lo que no ha sido verificado públicamente incluye: el tipo de ataque sufrido por la segunda organización, si hubo exfiltración de datos de pacientes, el número de personas potencialmente afectadas, y si la entidad silenciosa inició algún proceso de notificación de forma privada ante las autoridades sin hacerlo público. DataBreaches.net no publicó el nombre completo ni la ubicación de la segunda entidad al momento de la nota, según se informó. Tampoco hay confirmación de qué grupo o actor de amenaza estuvo detrás de cada ataque.

    El escenario tiene un paralelo directo en América Latina. Brasil, bajo la Lei Geral de Proteção de Dados (LGPD), establece en su artículo 48 que el controlador debe comunicar a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados cualquier incidente de seguridad que pueda acarrear riesgo o daño relevante en un plazo razonable, fijado por regulación en hasta 72 horas desde el conocimiento del incidente. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) regula la notificación bajo la Ley 25.326 y su Disposición 11/2006, aunque sin un plazo tan estricto como el brasileño. En México, el INAI exige notificación conforme a la LFPDPPP cuando el incidente afecte derechos patrimoniales o morales de los titulares. En todos estos marcos, el silencio de un responsable de tratamiento frente a un incidente confirmado constituye una infracción autónoma, con independencia de si el ataque en sí fue evitable.

    El próximo hito a seguir es si la segunda entidad presenta una notificación ante el Departamento de Salud de Estados Unidos (HHS) antes del vencimiento del plazo de 60 días calendario que HIPAA establece desde la detección del incidente, lo que fijaría como fecha límite aproximada en octubre de 2026.

  • Honeywell paga $2 millones por incumplir ciberseguridad en contrato del Pentágono

    Honeywell paga $2 millones por incumplir ciberseguridad en contrato del Pentágono

    Honeywell Aerospace Inc. acordó pagar 2.042.518 dólares para resolver alegaciones del Departamento de Justicia de Estados Unidos por incumplir requisitos de ciberseguridad en un contrato con el Departamento de Defensa, según anunció el DOJ el 1 de septiembre de 2026.

    El acuerdo se enmarca en la False Claims Act (FCA), la ley federal estadounidense que establece responsabilidad civil para contratistas que presenten declaraciones falsas o fraudulentas al gobierno. Según se informó, Honeywell Aerospace —con sede en Estados Unidos— habría facturado servicios bajo un contrato del Pentágono sin haber cumplido efectivamente con los controles de ciberseguridad exigidos en ese acuerdo. El caso fue revelado públicamente el 1 de septiembre de 2026 mediante un comunicado oficial del DOJ.

    Datos confirmados del acuerdo con el DOJ

    • Monto acordado: 2.042.518 dólares
    • Empresa: Honeywell Aerospace Inc.
    • Marco legal aplicado: False Claims Act (EE. UU.)
    • Contraparte afectada: Departamento de Defensa de Estados Unidos (DoD)
    • Anuncio del DOJ: 1 de septiembre de 2026

    Qué se sabe y qué falta confirmar

    Lo confirmado es que Honeywell Aerospace acordó el pago sin que ello implique necesariamente una admisión de responsabilidad, práctica habitual en este tipo de settlements bajo la FCA. Lo que no ha sido detallado públicamente es cuáles controles de ciberseguridad específicos fueron incumplidos, ni por cuánto tiempo se extendió el incumplimiento, ni si existió una brecha de datos asociada al contrato en cuestión. Tampoco se ha informado si el caso fue iniciado por un denunciante interno —los llamados qui tam relators— o por auditoría directa del DoD.

    El caso suma a una serie de acciones del DOJ bajo la denominada Civil Cyber-Fraud Initiative, lanzada en 2021, que busca precisamente usar la FCA como herramienta de enforcement para contratistas federales que declaren cumplimiento de estándares como el NIST SP 800-171 o el CMMC (Cybersecurity Maturity Model Certification) sin haberlos implementado efectivamente. El mensaje regulatorio es claro: el incumplimiento contractual en materia de ciberseguridad tiene consecuencias patrimoniales directas, no solo reputacionales.

    Para el ecosistema de proveedores del Estado en América Latina, el caso tiene lectura directa. En Brasil, los contratos de tecnología con la administración pública federal están sujetos a la Instrução Normativa SGD/ME nº 1/2019 y a los marcos de seguridad de la información del GSI; en Argentina, el Decreto 1066/2023 establece requisitos de ciberseguridad para organismos del Estado, con impacto en sus proveedores tecnológicos. En México, la Estrategia Nacional de Ciberseguridad carece aún de un mecanismo de enforcement equivalente a la FCA, lo que deja sin sanción patrimonial efectiva a los contratistas que declaren cumplimientos no verificados. La pregunta que este caso instala en la región es cuántos contratos públicos de tecnología se adjudican con declaraciones de cumplimiento de seguridad que nadie audita.

    El próximo indicador a seguir es si el DOJ publica los detalles del incumplimiento específico de Honeywell, lo que permitirá determinar si el caso sienta precedente para contratistas que operan simultáneamente con gobiernos de la región.

  • CEPAL exige estadísticas oficiales más robustas para gobernar datos en LATAM

    CEPAL exige estadísticas oficiales más robustas para gobernar datos en LATAM

    La Comisión Económica para América Latina y el Caribe (CEPAL) emitió un llamado formal a los gobiernos de la región para fortalecer sus sistemas de estadísticas oficiales, argumentando que sin datos públicos confiables es imposible diseñar políticas efectivas ni avanzar hacia una gobernanza de datos sostenible. El planteo, formulado en septiembre de 2025, pone en evidencia una brecha estructural que afecta tanto a los Estados como a las organizaciones privadas que dependen de insumos estadísticos para tomar decisiones.

    El diagnóstico de la CEPAL no es nuevo, pero su urgencia ha escalado. La proliferación de fuentes de datos no oficiales —plataformas privadas, sensores, redes sociales— genera una paradoja: hay más datos que nunca disponibles, pero los marcos institucionales para darles sentido, validarlos y usarlos en políticas públicas siguen siendo débiles. La calidad del dato público es la base sobre la cual se construyen modelos de planificación, distribución de presupuesto y evaluación de impacto. Cuando esa base falla, todo lo que se construye encima es frágil.

    Qué plantea la CEPAL: datos oficiales como infraestructura crítica

    Según se informó, el organismo regional subrayó que los institutos nacionales de estadística de América Latina enfrentan déficits crónicos de financiamiento, recursos humanos especializados y marcos normativos actualizados. La CEPAL vincula directamente la debilidad estadística con la incapacidad de los Estados para medir el avance de los Objetivos de Desarrollo Sostenible (ODS), gestionar crisis y diseñar intervenciones focalizadas en poblaciones vulnerables. En ese sentido, el llamado no es solo técnico: es una advertencia sobre la soberanía de datos de los países frente a actores privados que sí tienen capacidad analítica instalada.

    El argumento central es que los datos estadísticos oficiales son infraestructura pública, comparable a rutas o redes eléctricas. Descuidarlos no solo deteriora la toma de decisiones del Estado; crea un vacío que organizaciones privadas —y a veces actores externos— terminan llenando con sus propios conjuntos de datos, bajo sus propias condiciones de acceso y uso. Eso tiene consecuencias directas sobre quién controla el relato de lo que ocurre en la región.

    Argentina, Brasil y México: tres velocidades distintas en estadística pública

    El panorama regional es heterogéneo. Brasil mantiene el Instituto Brasileiro de Geografia e Estatística (IBGE) como una de las agencias estadísticas más robustas de América Latina, con capacidad censal, encuestas continuas y apertura de microdatos bajo estándares comparables a los de economías avanzadas. Sin embargo, incluso el IBGE enfrenta presiones presupuestarias que, en años recientes, postergaron relevamientos clave. En México, el INEGI opera bajo un esquema de autonomía técnica reconocida, aunque el debate sobre la independencia efectiva del organismo resurge periódicamente en contextos de cambio de administración.

    Argentina presenta una situación más compleja: el INDEC atravesó una crisis de credibilidad severa entre 2007 y 2015, cuando la manipulación de índices de precios afectó la confiabilidad de sus series históricas. La recuperación institucional fue gradual y, según se informó, todavía persisten brechas en la producción de estadísticas subnacionales y en la integración de registros administrativos con encuestas de hogares. Colombia, por su parte, ha avanzado en la construcción del Sistema Estadístico Nacional bajo la coordinación del DANE, con proyectos de interoperabilidad que apuntan a reducir la duplicación de esfuerzos entre entidades públicas.

    Gobernanza de datos públicos: el eslabón que falta entre el dato y la política

    El llamado de la CEPAL toca un nervio específico para quienes trabajan en gobernanza de datos en el sector privado: la calidad del ecosistema estadístico público condiciona la calidad de cualquier análisis que use esos datos como insumo. Un modelo de riesgo crediticio que incorpora datos de desempleo del INDEC, del IBGE o del DANE es tan confiable como la fuente que lo alimenta. En términos del marco DAMA-DMBOK, esto remite directamente a la dimensión de calidad del dato (Data Quality Management) aplicada al nivel de los productores primarios de información.

    La CEPAL no habla de data governance en el sentido corporativo del término, pero su diagnóstico es isomorfo: sin definición clara de ownership sobre los datos, sin estándares de calidad aplicados en origen, sin linaje trazable entre el registro administrativo y el indicador publicado, la estadística oficial pierde valor. Los gobiernos que avanzan en interoperabilidad de registros —como lo está haciendo Chile con su plataforma de datos abiertos y Colombia con el DANE— están, en la práctica, construyendo capacidades equivalentes a las que cualquier organización privada madura busca certificar bajo marcos como el CDMC del EDM Council.

    Qué sigue: los hitos que definen si el llamado de CEPAL tiene efecto

    El impacto real de este tipo de pronunciamientos depende de si los gobiernos los traducen en presupuesto y normativa. Hay señales concretas a monitorear en los próximos meses: la discusión de los presupuestos nacionales 2026, donde el financiamiento a los institutos estadísticos será un indicador directo de voluntad política; el avance de los planes de digitalización de registros administrativos en Argentina y Perú; y la negociación de acuerdos de intercambio de datos entre organismos regionales como la CEPAL, el BID y el Banco Mundial, que pueden inyectar capacidad técnica donde los recursos nacionales son insuficientes.

    También vale observar si el llamado de la CEPAL se articula con las agendas de transformación digital que varios países tienen en marcha. En la práctica, la modernización estadística y la gobernanza de datos del Estado son procesos que deberían avanzar en paralelo, bajo marcos normativos que definan con precisión qué datos deben producirse, con qué frecuencia, bajo qué estándares y con qué mecanismos de auditoría independiente.

    Nuestro análisis: soberanía de datos empieza por estadística pública

    El discurso sobre soberanía de datos en América Latina suele centrarse en regular a las plataformas tecnológicas globales o en proteger datos personales frente a actores externos. La CEPAL pone el foco donde debería estar con más frecuencia: en la capacidad del propio Estado de producir, custodiar y usar datos de calidad. Sin esa base, cualquier estrategia de gobernanza regional es arquitectura sobre arena.

    Para los equipos de datos en el sector privado, el llamado tiene una implicancia práctica que a veces se subestima: la debilidad estadística pública eleva el costo de operar en la región. Cuando los datos oficiales son poco confiables o tienen brechas temporales, las organizaciones invierten recursos propios en construir proxies, contratar datos de terceros o trabajar con márgenes de incertidumbre más amplios. Eso no es solo un problema del Estado; es un costo de transacción que recae sobre cualquier actor que dependa de información contextual para tomar decisiones.

    La pregunta que queda abierta es si los países de la región están dispuestos a tratar sus institutos de estadística como lo que son: infraestructura crítica de datos públicos, no líneas prescindibles del presupuesto.