Etiqueta: Normativa

  • Microsoft corrige casi mil vulnerabilidades en Patch Tuesday de septiembre 2026

    Microsoft corrige casi mil vulnerabilidades en Patch Tuesday de septiembre 2026

    Microsoft lanzó su ciclo de actualizaciones de seguridad de septiembre de 2026 —conocido como Patch Tuesday— con casi mil fallas corregidas, según se informó. El volumen es uno de los más altos registrados en un solo ciclo mensual por la compañía.

    El paquete de actualizaciones fue publicado el segundo martes de septiembre, en línea con el calendario mensual fijo que Microsoft mantiene desde 2003. Según se informó desde el portal especializado Nivel4 Ciberseguridad, el total de vulnerabilidades parcheadas se aproxima a las mil, aunque el desglose por severidad —crítica, importante, moderada— no fue detallado en la información disponible al cierre de esta nota.

    Qué se sabe y qué falta confirmar

    Lo confirmado es el volumen inusualmente alto de correcciones en un único ciclo mensual. No se ha informado si alguna de las vulnerabilidades parcheadas se encontraba siendo explotada activamente en el momento de la publicación —dato crítico para priorizar el despliegue de parches en entornos corporativos—. Tampoco se han identificado públicamente CVEs específicos con puntaje CVSS 9.0 o superior que requieran atención inmediata, según la información disponible.

    • Ciclo: Patch Tuesday, septiembre de 2026
    • Total de fallas corregidas: aproximadamente 1.000, según se informó
    • Productos afectados: no especificados en la información disponible
    • Explotación activa confirmada: sin datos al cierre de esta nota

    Relevancia para organizaciones en Argentina, México y Brasil

    En América Latina, el Patch Tuesday tiene implicancias directas sobre el cumplimiento normativo de protección de datos. En Argentina, la Ley 25.326 y las directrices de la AAIP exigen medidas de seguridad adecuadas para el tratamiento de datos personales; un sistema sin parchear que luego sufre una brecha puede comprometer esa adecuación. En Brasil, la LGPD (Lei 13.709/2018) establece en su artículo 46 la obligación del controlador de adoptar medidas técnicas capaces de proteger los datos personales de accesos no autorizados, lo que incluye la gestión oportuna de vulnerabilidades. En México, la LFPDPPP y su reglamento contemplan el principio de seguridad con estándares equivalentes.

    El próximo Patch Tuesday está programado para el segundo martes de octubre de 2026: los equipos de seguridad y compliance tienen hasta esa fecha para evaluar y priorizar el despliegue de las actualizaciones de septiembre en sus entornos de producción.

  • Corea del Sur eleva multas por brechas de datos al 10% de los ingresos

    Corea del Sur eleva multas por brechas de datos al 10% de los ingresos

    Corea del Sur acaba de reescribir la ecuación costo-beneficio de la protección de datos para las empresas que operan en su territorio. Desde el 12 de septiembre de 2025, las compañías que filtren información personal de 10 millones de personas o más —por dolo o negligencia grave— quedan expuestas a multas de hasta el 10% de sus ingresos globales anuales. El mensaje del regulador es explícito: la protección de datos debe ser una inversión preventiva, no un costo operativo que se absorbe después del incidente.

    La reforma fue impulsada por la Comisión de Protección de Información Personal de Corea (PIPC, por sus siglas en inglés), la autoridad de control equivalente a lo que en la región son la ANPD brasileña, la AAIP argentina o el INAI mexicano. La PIPC viene acumulando experiencia sancionatoria desde que se consolidó como ente autónomo en 2020, pero el techo anterior de multas era considerado insuficiente para disuadir a grandes corporaciones con facturación multimillonaria. El nuevo umbral del 10% sobre ingresos —no sobre utilidades— cambia radicalmente esa aritmética.

    La reforma coreana: 10 millones de registros como umbral de responsabilidad agravada

    La modificación introduce una distinción crítica: el régimen agravado del 10% aplica cuando la brecha involucra al menos 10 millones de titulares de datos y existe dolo o negligencia grave demostrable. Para incidentes de menor escala o negligencia ordinaria, el régimen general de la Ley de Protección de Información Personal (PIPA) coreana continúa vigente con sanciones menores. Este esquema escalonado no es una novedad conceptual —el RGPD europeo ya diferencia entre infracciones “graves” y “muy graves” con topes del 2% y 4% del volumen de negocio global, respectivamente—, pero la escala del 10% supera cualquier régimen vigente en economías desarrolladas.

    El criterio de “ingresos globales” es el detalle más significativo para empresas multinacionales. Una plataforma digital con operaciones en Corea del Sur pero con matriz en Estados Unidos, Japón o Europa enfrentaría una multa calculada sobre su facturación consolidada, no solo sobre los ingresos generados en territorio coreano. Eso convierte a la PIPC en un regulador con alcance extraterritorial comparable al de la Autoridad de Protección de Datos irlandesa dentro del ecosistema del RGPD.

    LGPD, Ley 25.326 y LFPDPPP: los techos sancionatorios que Corea dejó atrás

    El contraste con América Latina es revelador. Brasil cuenta con el marco más cercano al estándar internacional: la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) habilita multas de hasta el 2% de los ingresos en Brasil —no globales— de la persona jurídica en su último ejercicio fiscal, con tope absoluto de 50 millones de reales por infracción. La Autoridade Nacional de Proteção de Dados (ANPD) comenzó a aplicar sanciones pecuniarias en 2023 y acumula resoluciones, pero el volumen de multas efectivas todavía es bajo en comparación con autoridades europeas de similar madurez institucional.

    En Argentina, la Ley 25.326 de Protección de Datos Personales —que data del año 2000 y es objeto de un proceso de reforma legislativa que lleva varios años sin resolución definitiva— establece sanciones que van de una advertencia a la inhabilitación del registro de base de datos, con multas que en la práctica han resultado simbólicas frente al tamaño de los actores infractores. La Agencia de Acceso a la Información Pública (AAIP) carece del régimen porcentual sobre ingresos que hoy tienen tanto la ANPD como la PIPC coreana. México, por su parte, mantiene el esquema de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010), con multas expresadas en días de salario mínimo —un mecanismo que erosiona el poder disuasorio frente a grandes corporaciones—, aunque el INAI ha impulsado reformas para modernizarlo.

    Colombia (Ley 1581/2012, reglamentada por la Superintendencia de Industria y Comercio) y Chile (nueva Ley 21.719, en proceso de implementación con autoridad de control en formación) completan un mapa regional donde ningún país supera el umbral del 4% sobre ingresos como sanción máxima aplicable, y donde la mayoría aún opera con techos nominales muy por debajo de esa cifra.

    Por qué el modelo coreano presiona a los directorios, no solo a los equipos de compliance

    Una multa calculada sobre el 10% de ingresos globales deja de ser un problema del departamento legal para convertirse en un riesgo de balance que requiere atención del directorio y del CFO. Esa es, precisamente, la intención declarada del regulador coreano: que la protección de datos compita con otras inversiones estratégicas dentro de la asignación de capital corporativo. La lógica es la misma que llevó al RGPD a adoptar multas porcentuales en lugar de montos fijos: cuando el techo sancionatorio es proporcional al tamaño del infractor, deja de existir el incentivo para que una empresa grande simplemente “pague y siga”.

    Para empresas latinoamericanas con operaciones en Corea del Sur —o que procesen datos de ciudadanos coreanos— la reforma es directamente aplicable. Para quienes no tienen presencia en Asia, el movimiento coreano funciona como señal de hacia dónde se dirigen los regímenes de privacidad que buscan credibilidad sancionatoria real. Brasil está en ese camino; Argentina y México tienen reformas pendientes que podrían incorporar esta lógica si los proyectos legislativos prosperan.

    Qué monitorear: la ANPD brasileña y el proyecto de reforma argentina en 2025-2026

    Dos hitos merecen seguimiento inmediato en la región. En Brasil, la ANPD avanza en la revisión de su regulación de seguridad y notificación de incidentes (Resolución CD/ANPD nº 2/2022), y cualquier actualización del régimen sancionatorio deberá pasar por el Congreso para modificar la LGPD, algo que el ecosistema de privacidad brasileño ya discute abiertamente. En Argentina, el Poder Ejecutivo presentó en 2023 un proyecto de modernización de la Ley 25.326 que contempla un esquema de multas graduadas; su suerte legislativa sigue siendo incierta, pero la reforma coreana agrega presión internacional al debate local. Las organizaciones con operaciones en múltiples jurisdicciones deberían documentar ya cuál es su exposición máxima bajo cada régimen vigente, y comparar ese número contra el presupuesto que hoy destinan a prevención.

    Nuestro análisis: el 10% como nueva referencia de credibilidad regulatoria

    La reforma coreana no es solo una decisión de política doméstica: es una declaración sobre qué nivel de sanción se necesita para cambiar el comportamiento corporativo en materia de protección de datos. El RGPD demostró que los porcentajes sobre ingresos —y no los montos fijos— son el único mecanismo que genera incentivos reales para empresas de escala global. Corea del Sur va más lejos que Europa en ese mismo eje. América Latina, con la excepción parcial de Brasil, todavía opera con regímenes diseñados para otro tamaño de mercado y otro tipo de infractor. El riesgo de esa brecha no es solo reputacional: es que las empresas que operan en múltiples jurisdicciones optimicen su inversión en privacidad hacia donde el regulador tiene mayor capacidad de daño económico, dejando a los titulares latinoamericanos con menor protección efectiva. Eso no es un problema de texto legal; es un problema de arquitectura de incentivos que los reguladores de la región tienen pendiente resolver.

    ¿Cuándo un regulador latinoamericano tendrá los dientes suficientes para que el cálculo costo-beneficio de una brecha masiva deje de favorecer a quien la provoca?

  • Costa Rica lanza hoja de ruta de 36 meses para gobernanza de datos en salud pública

    Costa Rica lanza hoja de ruta de 36 meses para gobernanza de datos en salud pública

    Costa Rica formalizó una hoja de ruta de 36 meses para implementar gobernanza de datos en su sistema de salud pública, según se informó a principios de septiembre de 2025. La iniciativa posiciona al país como uno de los pocos en América Central con un plan estructurado de data governance sectorial, y su diseño —centrado en calidad del dato, interoperabilidad y roles de ownership— ofrece una referencia concreta para la región.

    El plan costarricense articula tres horizontes temporales: el primero enfocado en diagnóstico de madurez y definición de roles (data stewards, data owners); el segundo en implementación de un catálogo de datos clínico-administrativos y mecanismos de calidad; y el tercero en interoperabilidad con sistemas externos y medición de impacto. La secuencia sigue una lógica reconocible para cualquier practicante del DAMA-DMBOK: primero se establece el who antes del how, evitando el error frecuente de implementar herramientas sin estructuras de accountability previas.

    Qué implica una hoja de ruta sectorial en salud: roles, calidad y catálogo en 36 meses

    El sector salud es, en términos de gobernanza de datos, uno de los más complejos: combina datos clínicos sensibles, sistemas heredados de décadas, múltiples actores (hospitales, clínicas, laboratorios, aseguradoras) y marcos regulatorios de privacidad que restringen el flujo de información. Diseñar un roadmap para ese entorno en solo 36 meses es ambicioso. La clave estará en si Costa Rica logra asignar data stewards con autoridad real sobre dominios específicos —historia clínica electrónica, facturación, epidemiología— o si los roles quedan como títulos formales sin capacidad de decisión sobre el dato.

    Según se informó, el plan contempla también la definición de métricas de calidad del dato aplicadas a los registros hospitalarios, un área donde los sistemas latinoamericanos suelen acumular deuda técnica significativa: duplicación de pacientes, campos vacíos en registros críticos, inconsistencias entre sistemas de admisión y facturación. Sin una baseline de calidad documentada, cualquier iniciativa de analítica o interoperabilidad queda sobre arena.

    Brasil, Colombia y Chile: tres modelos de gobernanza en salud pública con distinto grado de avance

    Costa Rica no parte de cero en el contexto regional. Brasil opera desde 2020 la Rede Nacional de Dados em Saúde (RNDS), impulsada por el Ministerio de Salud, que establece estándares de interoperabilidad basados en HL7 FHIR y exige a los establecimientos adherirse a un modelo de datos federado. La LGPD (Lei 13.709/2018) actúa como piso normativo para el tratamiento de datos sensibles de salud, clasificados en el artículo 11 como categoría especial con restricciones específicas de base legal. Brasil es hoy el caso de mayor escala en la región, aunque la heterogeneidad entre estados federales genera inconsistencias de implementación.

    Colombia avanzó con la Política Nacional de Datos de Salud del Ministerio de Salud y Protección Social, apoyada en la Resolución 866 de 2021, que establece estándares técnicos para la interoperabilidad del sector. La Ley 1581 de 2012 (régimen general de protección de datos) y su decreto reglamentario 1074 de 2015 proveen el marco para el tratamiento de datos sensibles, aunque persisten vacíos en la aplicación sectorial específica para salud. Chile, por su parte, avanza con el proyecto de nueva Ley de Protección de Datos Personales —ya aprobada en el Congreso y en proceso de implementación reglamentaria— que incorpora un régimen reforzado para datos de salud, y con el Plan Nacional de Salud Digital 2030 que contempla componentes de interoperabilidad, sin que se haya formalizado aún un marco de gobernanza de datos con la especificidad del costarricense.

    En ese mapa, el diferencial de Costa Rica no es el tamaño ni el presupuesto —la Caja Costarricense de Seguro Social (CCSS) opera en un país de cinco millones de habitantes— sino la existencia de una hoja de ruta documentada, con fases, entregables y, según se informó, mecanismos de seguimiento. Esa granularidad es exactamente lo que suele faltar en los planes regionales de transformación digital en salud, donde las declaraciones de intención superan ampliamente a los planes de ejecución.

    El modelo CDMC del EDM Council como referencia para medir madurez en salud

    Para los equipos de gobernanza que quieran benchmarkear el plan costarricense —o diseñar uno propio—, el Cloud Data Management Capabilities (CDMC) del EDM Council ofrece una estructura de 14 capabilities distribuidas en seis categorías, varias de ellas directamente aplicables al sector salud: control de acceso a datos sensibles, linaje, calidad y catalogación. El CDMC fue diseñado inicialmente para el sector financiero, pero su adopción en salud crece porque permite demostrar compliance con reguladores sin necesidad de reconstruir el marco desde cero. Alternativamente, el Marco de Referencia de Gobernanza de Datos de DAMA International (DMBOK2, 2017) provee las once áreas de conocimiento que cualquier roadmap sectorial debería mapear antes de fijar cronogramas.

    Un error frecuente en iniciativas similares en la región es saltear el diagnóstico de madurez —usando, por ejemplo, el Data Management Maturity (DMM) del CMMI Institute— y pasar directamente a la adquisición de herramientas de catalogación o calidad. El resultado es predecible: plataformas sin adopción, data stewards sin autoridad y presupuestos consumidos sin baseline medible.

    Qué monitorear en los próximos 12 meses del plan costarricense

    Los primeros 12 meses de cualquier roadmap de gobernanza son el filtro real entre iniciativa y programa sostenible. Para Costa Rica, los hitos críticos que valdría observar son: la formalización de los roles de data ownership en la CCSS con mandatos documentados; la publicación del inventario o catálogo de dominios de datos del sistema de salud; y la definición de métricas de calidad con valores baseline para al menos tres dominios críticos (identidad del paciente, diagnóstico, prestación). Si esos tres entregables existen al término del primer año, el plan tiene sustancia operativa. Si no, el riesgo de que el roadmap quede como documento de política sin implementación es alto, un patrón que la región conoce bien.

    Para organizaciones de salud en otros países que observen este caso, la señal más valiosa no es el cronograma en sí sino la decisión de hacer explícito el modelo de accountability: quién es dueño de cada dominio de datos, con qué autoridad y medido con qué indicadores. Esa claridad conceptual, plasmada en un documento oficial, es más rara en el sector público latinoamericano de lo que debería.

    Nuestro análisis

    El plan costarricense merece atención regional no por su escala, sino por su método. En un sector donde “transformación digital en salud” suele significar comprar un ERP o migrar a la nube, formalizar un roadmap de gobernanza con fases, roles y métricas es una decisión de madurez institucional infrecuente en América Central. La pregunta que determinará si este plan es referencia o anécdota es una sola: ¿la CCSS asignó data stewards con poder de veto sobre decisiones de calidad y acceso, o solo creó un comité asesor? La diferencia entre ambos modelos no es semántica; es la distancia entre gobernanza operativa y gobernanza decorativa. Equipos en Argentina, Colombia o Perú que estén diseñando iniciativas similares en el sector público deberían pedir acceso al marco de roles antes de replicar el cronograma.

    Un roadmap de 36 meses en salud pública es una promesa institucional: su valor real se mide en los primeros 12, cuando los roles pasan de organigramas a decisiones reales sobre el dato.

  • OpenAI dice resolver un Problema del Milenio: el escándalo que opaca el hito

    OpenAI dice resolver un Problema del Milenio: el escándalo que opaca el hito

    OpenAI anunció que sus agentes de inteligencia artificial resolvieron uno de los Problemas del Milenio, los desafíos matemáticos más importantes del mundo con un premio de un millón de dólares cada uno. El anuncio llegó envuelto en acusaciones que, según se informó, opacaron rápidamente lo que habría sido un hito sin precedentes para el campo.

    Los Problemas del Milenio son siete preguntas matemáticas abiertas seleccionadas por el Clay Mathematics Institute en el año 2000. Hasta la fecha, solo una había sido resuelta por un ser humano —la conjetura de Poincaré, por Grigori Perelman en 2003—. Que un sistema de inteligencia artificial reclame haber resuelto otra coloca el anuncio en una categoría de importancia que trasciende a la propia empresa. También lo convierte en un objetivo inmediato de escrutinio dentro de la comunidad matemática y regulatoria.

    Por qué la controversia importa tanto como el resultado

    El problema no es solo si la solución es válida —algo que la comunidad matemática tardará semanas o meses en verificar de forma rigurosa—. El problema central es cómo OpenAI realizó y comunicó el anuncio. Según se informó, las acusaciones que rodean el caso cuestionan la transparencia del proceso de validación y la forma en que la compañía presentó el hallazgo públicamente. En un campo donde la demostración debe ser reproducible y sometida a revisión por pares, la velocidad del ciclo de relaciones públicas corporativo choca de frente con los tiempos del método científico.

    Este episodio ilustra una tensión estructural que se repetirá: las empresas de IA tienen incentivos comerciales para anunciar avances de forma rápida y contundente, mientras que la ciencia exige validación lenta, abierta y adversarial. Cuando ambas lógicas colisionan en dominios de alta consecuencia —matemáticas, medicina, derecho—, el daño reputacional puede ser duradero y las implicancias regulatorias, significativas.

    Qué define un “agente” que resuelve matemáticas y por qué eso importa legalmente

    OpenAI empleó lo que denomina “agentes” —sistemas de IA capaces de planificar, ejecutar pasos intermedios y usar herramientas externas de forma autónoma— para atacar el problema. Esto es relevante desde una perspectiva de gobernanza de IA: un agente autónomo que genera una demostración matemática no es equivalente a un modelo que responde una pregunta. Plantea preguntas sobre autoría, sobre responsabilidad por errores en la cadena de razonamiento, y sobre quién certifica que el output es correcto antes de que sea presentado públicamente como verdad.

    En el marco del AI Act de la Unión Europea —vigente de forma gradual desde 2024—, los sistemas de IA de alto riesgo requieren supervisión humana efectiva antes de que sus outputs se utilicen en contextos críticos. Una demostración matemática reclamada como válida sin verificación independiente previa al anuncio público podría, en determinadas lecturas del reglamento, constituir un uso que excede los controles requeridos para un sistema de propósito general con impacto de alto perfil. América Latina no tiene aún un marco equivalente consolidado, aunque Brasil avanza con su Proyecto de Ley 2338/2023 de regulación de IA y Colombia publicó su política nacional de IA con principios de transparencia y rendición de cuentas que apuntan en la misma dirección.

    Cuándo aplica la regulación de IA y cuándo no en este tipo de escenario

    El AI Act europeo clasifica los sistemas según riesgo, no según la naturaleza del output. Un agente matemático no cae automáticamente en la categoría de alto riesgo —que incluye educación, empleo, infraestructura crítica, biometría—. Sin embargo, cuando el output de ese agente es presentado como una verdad científica validada y tiene impacto en la reputación pública de una disciplina, el debate regulatorio se desplaza hacia la transparencia y la gobernanza de los modelos de propósito general (GPAI, por sus siglas en inglés). El AI Act establece para estos modelos obligaciones de documentación técnica, reporte de incidentes graves y, para los de mayor capacidad sistémica, evaluaciones de riesgo adversarial. OpenAI, como proveedor de modelos GPAI de alta capacidad sistémica, está dentro de ese perímetro regulatorio en Europa.

    Fuera de Europa, la regulación es más difusa. En México, el INAI no tiene competencia sobre sistemas de IA en sí mismos. En Argentina, la AAIP publicó lineamientos no vinculantes sobre IA y datos personales en 2023, pero carecen de fuerza coercitiva sobre anuncios de esta naturaleza. El vacío regulatorio no significa ausencia de consecuencias: las acusaciones de transparencia pueden traducirse en investigaciones del Congreso, presión de organismos de competencia o daño reputacional con efectos sobre adopción empresarial.

    El patrón de anuncio-controversia-validación tardía en IA

    Este no es el primer caso en que un avance de IA en matemáticas o ciencias genera primero titulares y luego correcciones. AlphaFold de DeepMind fue validado de forma positiva por la comunidad científica, pero el proceso tomó tiempo y la empresa abrió el código. Los modelos de lenguaje grande que “resuelven” olimpiadas matemáticas han sido repetidamente cuestionados por errores en pasos intermedios que el resultado final ocultaba. El patrón sugiere que el sector necesita protocolos de divulgación responsable —responsible disclosure— equivalentes a los que existen en ciberseguridad: antes de publicar, validar; antes de validar, documentar.

    Para las organizaciones latinoamericanas que evalúan adoptar agentes de IA en funciones analíticas o de soporte a decisiones, este episodio es una señal de alerta sobre la cadena de confianza: ¿quién verifica el output antes de que llegue a un decisor? ¿Existe un proceso formal de revisión humana? ¿El proveedor documenta las limitaciones del sistema de forma accesible? Estas preguntas no son teóricas: son el núcleo de cualquier programa de gobernanza de IA que aspire a ser robusto.

    Para profundizar en el marco regulatorio europeo aplicable a modelos de propósito general, el texto consolidado del AI Act está disponible en el Diario Oficial de la Unión Europea (Reglamento 2024/1689). El Proyecto de Ley 2338/2023 de Brasil puede consultarse en el sitio del Senado Federal.

  • 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.

  • 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.