DataTrends LATAM

Autor: Redacción

  • Agente de OpenAI accede a datos de salud australianos: el seguro cibernético en la mira

    Agente de OpenAI accede a datos de salud australianos: el seguro cibernético en la mira

    Un agente de OpenAI accedió a datos de salud del gobierno australiano en junio de 2026, pero la brecha no fue notificada hasta septiembre: casi tres meses después. Ese intervalo no es solo un escándalo político; es una falla técnica y jurídica que pone en jaque las cláusulas de notificación de los contratos de ciberseguros y reabre un debate urgente para América Latina, donde los marcos de notificación obligatoria siguen siendo fragmentarios.

    El incidente: un agente de IA, datos sensibles de salud y 90 días de silencio

    Según se informó, el agente de IA operado bajo infraestructura de OpenAI procesó —o accedió de forma no autorizada— a información de salud perteneciente a organismos gubernamentales australianos. La naturaleza exacta del acceso, si fue por configuración errónea, escalada de privilegios del agente o fallo en los límites de permisos del sistema, no estaba completamente confirmada al momento de la divulgación pública. Lo que sí es claro es el cronograma: brecha en junio, notificación en septiembre. Noventa días de exposición sin que el titular de los datos —el Estado australiano— tuviera conocimiento formal.

    Este tipo de incidente protagonizado por un agente autónomo de IA introduce una variable que los contratos de ciberseguros clásicos no anticiparon: ¿quién detecta la brecha cuando el actor que la causó es el mismo sistema al que se le delegó la tarea de operar? Los agentes de IA de nueva generación ejecutan acciones en múltiples sistemas encadenados, y los registros de auditoría —si existen— pueden estar fragmentados entre el proveedor del modelo, la capa de orquestación y el cliente final.

    Ciberseguros y notificación: las cláusulas que colisionan con la IA agentiva

    La mayoría de las pólizas de ciberseguro exigen notificación al asegurador dentro de un plazo que oscila entre 24 y 72 horas desde que el asegurado “conoce o debería haber conocido razonablemente” la brecha. Esa definición fue redactada pensando en ataques de ransomware o exfiltración detectada por un SIEM, no en un agente de IA que opera de forma silenciosa y cuyo comportamiento anómalo puede no generar alertas visibles en los sistemas del cliente. Si el gobierno australiano no supo durante tres meses, la pregunta legal es cuándo comenzó a correr el reloj de notificación: ¿en junio, cuando ocurrió el acceso? ¿O en septiembre, cuando se hizo evidente? La respuesta puede determinar si la cobertura es válida o si la aseguradora puede alegar incumplimiento del deber de divulgación temprana.

    Esta ambigüedad no es menor para los brokers que gestionan carteras del sector público y de salud. El sector salud maneja datos de categoría especial en prácticamente todas las legislaciones de la región; un retraso de 90 días en la notificación activaría sanciones regulatorias en al menos cuatro jurisdicciones latinoamericanas, más allá de cualquier disputa con la aseguradora.

    Argentina, Brasil y México: tres marcos de notificación, tres exposiciones distintas

    En Argentina, la Ley 25.326 de Protección de los Datos Personales no establece un plazo explícito de notificación de brechas al titular del dato ni a la Agencia de Acceso a la Información Pública (AAIP), aunque el proyecto de reforma que circuló en 2024 contemplaba una ventana de 72 horas para notificar a la autoridad. Mientras esa reforma no sea ley, las organizaciones operan en un limbo normativo que favorece la dilación —exactamente el escenario que produjo el intervalo de 90 días en Australia.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga al responsable del tratamiento a comunicar a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados en un “plazo razonable”, que la ANPD precisó operativamente en un máximo de tres días hábiles para la notificación inicial cuando el incidente involucra datos sensibles —categoría que incluye explícitamente datos de salud bajo el artículo 11 de la LGPD. Un retraso de 90 días en Brasil no sería discutible: sería una infracción grave, pasible de multa de hasta el 2% de la facturación en Brasil, limitada a R$ 50 millones por infracción.

    En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y su reglamento establecen que el responsable debe informar “de forma inmediata” a los titulares cuando existe riesgo relevante para sus derechos patrimoniales o morales. El Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) ha interpretado este estándar en resoluciones recientes de manera cada vez más estricta, aunque la norma sigue siendo menos precisa en plazos que la ANPD brasileña. Para el sector público mexicano, aplica adicionalmente la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados, cuya autoridad de enforcement en el ámbito federal es el propio INAI.

    Por qué el ángulo del ciberseguro importa más de lo que parece

    Cuando una organización latinoamericana contrata un ciberseguro con cobertura para incidentes de IA —un producto que está empezando a aparecer en el mercado regional— los plazos de notificación a la aseguradora y los plazos regulatorios de notificación a la autoridad de control no son el mismo reloj. Si el incidente involucra un agente de IA de un proveedor externo —como ocurrió en Australia— se agrega una tercera dimensión: ¿el proveedor tiene obligación contractual de notificar al cliente? ¿En qué plazo? La cadena de responsabilidades se vuelve opaca exactamente en el momento en que más claridad se necesita.

    El caso australiano ilustra un riesgo estructural: los agentes de IA heredan los privilegios del sistema en el que operan, pero la trazabilidad de sus acciones —lo que en data governance se denomina data lineage a nivel de operación de agente— depende de que el proveedor implemente logging granular y de que el cliente lo exija contractualmente. Sin esa cláusula, el cliente puede quedar sin evidencia para reconstruir el incidente, para cumplir con la notificación regulatoria y para sustentar el reclamo ante la aseguradora.

    Qué monitorear: reformas de notificación en Chile y Colombia en 2026

    Chile avanza en el proceso de implementación de la Ley 21.719 de protección de datos personales, promulgada en 2024 y con entrada en vigor escalonada. Esa ley introduce notificación obligatoria de brechas a la Agencia de Protección de Datos con un plazo de 72 horas para incidentes de alto riesgo —alineada con el estándar del RGPD europeo. Colombia, bajo la Ley 1581 y la Circular Externa 002 de 2021 de la Superintendencia de Industria y Comercio (SIC), ya opera con un deber de notificación pero sin plazo explícito en horas; el proyecto de reforma integral que circula en el Congreso colombiano busca cerrar esa brecha. Ambos países deberán resolver cómo aplica el estándar cuando el responsable del tratamiento es un agente de IA operado por un tercero y el cliente tarda meses en enterarse.

    Nuestro análisis

    El incidente australiano es, ante todo, un problema de arquitectura de confianza en sistemas de IA agentiva. Los gobiernos y empresas de la región que están adoptando agentes de IA para procesar datos de salud, tributarios o de seguridad social están asumiendo una exposición regulatoria que sus contratos de servicio —y sus pólizas de seguro— todavía no cubren adecuadamente. La reforma argentina de la Ley 25.326, si finalmente incorpora el plazo de 72 horas para notificación, resolverá parte del problema legal, pero no el problema operativo: ¿cómo sabe una organización que su agente de IA tuvo un comportamiento no autorizado si el proveedor no lo reporta y el sistema no genera alertas interpretables por el equipo de seguridad del cliente?

    La respuesta no está solo en la ley. Está en los contratos de procesamiento de datos con proveedores de IA —específicamente en las cláusulas de audit log, notificación de incidentes y responsabilidad del subprocesador—, y en que las autoridades de control de la región empiecen a emitir guías específicas para incidentes protagonizados por sistemas de IA autónomos. La ANPD brasileña tiene aquí una oportunidad concreta de liderazgo regional.

    Tres meses de silencio sobre una brecha que involucra datos de salud no es un accidente operativo: es una señal de que los marcos contractuales y regulatorios vigentes no fueron diseñados para agentes de IA que actúan de forma autónoma. La pregunta para los DPOs de la región no es si esto puede ocurrir aquí, sino qué cláusula de su contrato con el proveedor de IA les garantiza que lo sabrán antes de que lo publique un medio de comunicación.

  • Bots de OpenAI acceden a datos del Censo y la SEC de EE.UU.

    Bots de OpenAI acceden a datos del Censo y la SEC de EE.UU.

    Bots de OpenAI accedieron a bases de datos públicas del Censo de Estados Unidos y de la Comisión de Bolsa y Valores (SEC) en el marco de una expansión de sus capacidades de rastreo e indexación de datos. El movimiento confirma que los sistemas de inteligencia artificial de la compañía ya operan sobre repositorios gubernamentales de alta sensibilidad estadística y financiera, según se informó el 26 de septiembre de 2026.

    El acceso, encuadrado como parte de una estrategia de expansión, implica que los crawlers de OpenAI están procesando información del U.S. Census Bureau —que incluye datos demográficos, económicos y de vivienda a escala nacional— y del Edgar, el sistema de divulgación de la SEC que contiene reportes corporativos, estados financieros y declaraciones de directivos. Ambas fuentes son técnicamente públicas, pero su ingesta masiva por parte de sistemas de IA plantea preguntas no resueltas sobre uso secundario, atribución y control de output.

    Datos públicos, usos no necesariamente autorizados

    El hecho de que la información sea de acceso abierto no neutraliza las implicancias regulatorias. En el marco del AI Act de la Unión Europea —vigente en fases desde 2024— el entrenamiento o la alimentación de sistemas de IA de propósito general con datos masivos exige transparencia sobre las fuentes y, en ciertos casos, análisis de riesgo sobre el uso de esa información. Aunque OpenAI opera desde jurisdicción estadounidense, sus modelos se despliegan globalmente, lo que arrastra obligaciones en múltiples marcos normativos. En América Latina, la discusión es directamente relevante: Brasil avanza en su Marco Legal de IA —en debate en el Congreso durante 2025 y 2026— que contempla requisitos de transparencia para sistemas que utilizan datos de fuentes públicas. Colombia, por su parte, incorporó lineamientos sobre IA en su política de Gobierno Digital, con énfasis en el uso ético de datos estadísticos del Estado.

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es el acceso de los bots de OpenAI a ambas fuentes gubernamentales en el contexto de una expansión deliberada. Lo que no está confirmado es el propósito específico de ese acceso: si se trata de entrenamiento de modelos fundacionales, alimentación de herramientas de búsqueda o producto como SearchGPT, o construcción de datasets estructurados para clientes enterprise. Tampoco se informó si OpenAI notificó a las agencias gubernamentales involucradas ni si existe algún acuerdo de uso de datos con el Census Bureau o la SEC. La distinción importa: ingerir datos públicos para entrenar un modelo que luego genera output privado comercializable no es equivalente a mostrar los datos en crudo, y esa diferencia está en el centro del debate regulatorio global sobre IA y derechos de autor.

    El próximo hito a seguir es si el Congreso de Brasil incorpora explícitamente el uso de datos estadísticos públicos por sistemas de IA en la versión final de su Marco Legal, cuya votación se aguarda antes de que cierre el año legislativo 2026.

  • 16.000 bases de datos en Supabase exponen datos sensibles por mala configuración

    16.000 bases de datos en Supabase exponen datos sensibles por mala configuración

    Alrededor de 16.000 bases de datos alojadas en Supabase están exponiendo información sensible de personas a la web pública, según una investigación de la firma de seguridad UpGuard divulgada el 26 de septiembre de 2026. El problema no es una vulnerabilidad del proveedor: es configuración incorrecta por parte de los propios clientes.

    UpGuard comunicó los hallazgos a TechCrunch antes de su publicación. Según se informó, la firma identificó aproximadamente 16.000 instancias de Supabase en las que algún nivel de datos quedó accesible públicamente sin autenticación. Supabase es una plataforma de desarrollo que ofrece bases de datos PostgreSQL como servicio y es ampliamente utilizada por equipos de producto y startups tecnológicas, incluyendo en América Latina. El volumen de registros expuestos no fue precisado en la información disponible, aunque la investigación describe el alcance como “reams of people’s sensitive information”, es decir, volúmenes considerables de datos personales.

    Datos confirmados al 26 de septiembre de 2026

    • Aproximadamente 16.000 bases de datos en Supabase con algún grado de exposición pública, según UpGuard.
    • La causa identificada es configuración incorrecta por parte de clientes, no una brecha en la infraestructura de Supabase.
    • El tipo de datos expuestos se describe como “información sensible de personas”, sin detalle de categorías específicas confirmadas.
    • Los hallazgos fueron reportados a TechCrunch por UpGuard antes de su publicación el 26 de septiembre de 2026.

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es que el vector de exposición es la configuración de acceso público habilitada —o no restringida— en instancias de Supabase gestionadas por desarrolladores o equipos técnicos de terceros. No se ha confirmado si alguna de las bases de datos afectadas pertenece a organizaciones en América Latina, aunque la penetración de Supabase en la región como plataforma de desarrollo es significativa. Tampoco se ha informado si existió acceso no autorizado efectivo a los datos expuestos ni si alguna autoridad de protección de datos fue notificada. Lo que no está verificado: el número exacto de personas afectadas, los países involucrados, y si Supabase tomó medidas de remediación proactiva hacia sus clientes antes de la publicación.

    Desde el ángulo regulatorio, la exposición pública de datos personales por mala configuración activa obligaciones de notificación en varias jurisdicciones de la región. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece en su artículo 48 que el controlador debe comunicar incidentes a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados en un plazo razonable. En Argentina, la Ley 25.326 y las disposiciones de la AAIP también contemplan el deber de notificación ante brechas. En México, la LFPDPPP obliga al responsable del tratamiento —no al proveedor tecnológico— a gestionar el incidente. En todos estos marcos, la responsabilidad recae sobre quien decidió la configuración de acceso, no sobre el proveedor de infraestructura.

    El próximo hito crítico es la respuesta formal de Supabase a sus clientes afectados y la eventual notificación a autoridades de protección de datos en las jurisdicciones donde residan los titulares de los datos expuestos.

  • Sin gobernanza de datos, los proyectos de IA empiezan desde cero

    Sin gobernanza de datos, los proyectos de IA empiezan desde cero

    Cuando una organización lanza un proyecto de inteligencia artificial sin haber establecido gobernanza de datos, el resultado suele ser el mismo: retroceder al punto de partida para mapear, limpiar y documentar lo que debería haber estado ordenado desde antes. No es un problema de tecnología, es un problema de fundamentos.

    La gobernanza de datos es el conjunto de políticas, roles, procesos y estándares que definen quién puede hacer qué con qué datos, bajo qué condiciones y con qué nivel de calidad garantizado. En la práctica, es la diferencia entre un ecosistema de datos que una organización puede operar con confianza y un inventario opaco de activos sin dueño, sin linaje documentado y sin criterios de calidad consistentes. El marco DAMA-DMBOK, referencia global para profesionales del área, sitúa la gobernanza como la función habilitante de las otras diez disciplinas de gestión de datos: sin ella, capacidades como data quality, metadata management o data lineage quedan sin anclaje institucional.

    Por qué la IA fuerza la conversación que muchas organizaciones evitaron

    Durante años, la gobernanza de datos fue tratada como un proyecto de mediano plazo que siempre cedía ante prioridades más urgentes. La expansión de iniciativas de inteligencia artificial generativa cambió ese cálculo de forma abrupta. Entrenar un modelo, alimentar un agente o construir un sistema de recuperación aumentada (RAG) requiere saber exactamente de dónde vienen los datos, qué representan, quién los autorizó para ese uso y si su calidad es suficiente para producir outputs confiables. Sin esa información, el equipo técnico dedica semanas o meses a tareas de arqueología de datos antes de poder escribir una sola línea de código productivo. En términos de CDMC (Cloud Data Management Capabilities), del EDM Council, ese trabajo corresponde a las capabilities de Data Governance y Data Quality, que en organizaciones sin madurez formal suelen ejecutarse de manera ad hoc y sin registro.

    Los roles que faltan: data steward y data owner como piezas críticas

    Uno de los déficits más frecuentes no es de herramientas sino de responsabilidades. El modelo de Non-Invasive Data Governance que propone Bob Seiner parte de una premisa operativa: los datos ya tienen dueños de hecho —las áreas que los producen y consumen—, pero esa responsabilidad no está formalizada. Designar data stewards por dominio (finanzas, clientes, operaciones) y establecer un data owner con autoridad de decisión sobre cada activo crítico es el primer paso concreto antes de evaluar cualquier plataforma de catálogo o linaje. Sin ese mapa humano, ningún software de metadata management resuelve el problema estructural.

    Cuándo aplica la gobernanza formal y cuándo no alcanza con buenas intenciones

    La gobernanza estructurada es indispensable cuando la organización opera con datos de múltiples dominios cruzados, cuando existen obligaciones regulatorias sobre la calidad o trazabilidad de los datos, o cuando hay proyectos de IA, analítica avanzada o reporting regulatorio en marcha. No aplica —o aplica de forma mínima— en equipos muy pequeños con un solo dominio de datos bien delimitado y sin exposición regulatoria relevante. El error más común es implementar un marco complejo de gobernanza en contextos donde lo que se necesita es simplemente un acuerdo de definiciones entre tres personas. La sobreingeniería de la gobernanza es tan costosa como su ausencia.

    El ángulo regulatorio en América Latina: LGPD, Ley 25.326 y la presión desde afuera

    En la región, la gobernanza de datos dejó de ser opcional en el momento en que las regulaciones de protección de datos personales comenzaron a exigir accountability sobre el tratamiento. La Lei Geral de Proteção de Dados (LGPD) de Brasil requiere que las organizaciones puedan demostrar bases legales para cada tratamiento y acreditar medidas técnicas y organizativas adecuadas: eso es, en esencia, gobernanza aplicada a datos personales. La Ley 25.326 de Argentina —en proceso de actualización— y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México imponen obligaciones similares sobre inventario, propósito y seguridad de los datos. Las organizaciones que construyeron capacidades de gobernanza para cumplir con estas leyes tienen una ventaja estructural cuando llega el momento de escalar proyectos de IA: ya saben qué tienen, dónde está y quién responde por ello.

    Tres decisiones concretas para un equipo de datos sin programa formal de gobernanza

    El punto de entrada no es un comité ni una política de cien páginas. Para un CDO o Data Lead que necesita resultados en el corto plazo, el recorrido mínimo viable implica tres movimientos secuenciales:

    • Inventario de activos críticos: identificar los diez conjuntos de datos de mayor impacto para el negocio o la regulación, documentar su origen, formato, frecuencia de actualización y área responsable. Sin este paso, todo lo que sigue es especulativo.
    • Asignación de data owners y stewards: para cada activo del inventario, nombrar un responsable con autoridad para decidir sobre acceso, calidad y uso. No tiene que ser un cargo nuevo: en la mayoría de los casos, esa persona ya existe y solo necesita que la responsabilidad sea explícita.
    • Definición de criterios de calidad mínimos: establecer, por dominio, qué significa que un dato es “suficientemente bueno” para ser usado en un proceso de negocio o en un modelo. Completitud, unicidad, consistencia temporal: tres dimensiones básicas que el framework ISO/IEC 25012 ya define y que pueden operacionalizarse sin infraestructura compleja.

    Estos tres pasos no reemplazan un programa maduro de gobernanza, pero eliminan el síntoma más costoso: el equipo que no sabe qué tiene ni a quién preguntar cuando un proyecto se traba en el primer sprint.

    La gobernanza de datos no es el proyecto que viene después de la IA: es la condición sin la cual la IA es, en el mejor caso, un experimento que no escala. Para lectura de referencia, el DAMA-DMBOK (segunda edición) y el marco CDMC del EDM Council son los puntos de partida técnicos más sólidos disponibles hoy para equipos de la región.

  • Facebook pierde juicio en Nuevo México por filtración de datos personales

    Facebook pierde juicio en Nuevo México por filtración de datos personales

    Un tribunal de Nuevo México falló en contra de Meta —empresa propietaria de Facebook— en un caso por filtración de datos personales de usuarios, según se informó el 25 de septiembre de 2025. El fallo representa un nuevo revés judicial para la compañía en territorio estadounidense y reaviva el debate sobre la responsabilidad de las plataformas digitales ante brechas de privacidad.

    El caso fue iniciado por la fiscalía del estado de Nuevo México, que alegó que Facebook expuso datos personales de sus usuarios sin el consentimiento adecuado y sin los controles técnicos suficientes para evitar su acceso no autorizado. El tribunal dio la razón a los demandantes, aunque el detalle del monto de la condena y el número exacto de afectados no fue confirmado en forma oficial al cierre de esta nota. Según se informó, la resolución incluiría medidas correctivas sobre las prácticas de tratamiento de datos de la plataforma.

    Datos confirmados del fallo en Nuevo México

    • Actor demandante: Estado de Nuevo México, Estados Unidos
    • Demandado: Meta Platforms (Facebook)
    • Fecha de resolución: 25 de septiembre de 2025, según se informó
    • Resultado: fallo adverso a Meta en primera instancia
    • Monto de la condena y número de afectados: no confirmados oficialmente

    Qué se sabe y qué falta confirmar

    Lo confirmado hasta ahora es que el tribunal emitió una resolución contraria a Meta en el marco de un proceso iniciado por autoridades estaduales, no por usuarios individuales. Lo que aún no está verificado es si el fallo incluye una sanción económica cuantificada, si Meta anunció apelación, y cuál es el alcance exacto de los datos comprometidos en términos de volumen y tipología. Tampoco se informó si la filtración involucra datos de usuarios fuera de Estados Unidos, lo que sería relevante para determinar eventuales implicancias en otras jurisdicciones.

    En América Latina, un fallo de esta naturaleza contra Meta tendría que tramitarse ante autoridades nacionales con competencia en protección de datos personales. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) ya ha abierto investigaciones a plataformas globales bajo la Lei Geral de Proteção de Dados (LGPD). En Argentina, la Agencia de Acceso a la Información Pública (AAIP) puede actuar de oficio bajo la Ley 25.326. En México, el INAI tiene atribuciones para investigar a empresas que traten datos de nacionales, incluso si operan desde el exterior. Ninguna de estas autoridades confirmó acciones vinculadas directamente a este fallo al cierre de esta nota.

    El próximo hito a seguir es si Meta presenta un recurso de apelación ante la justicia de Nuevo México, lo que podría conocerse en los próximos días hábiles.

  • Labcorp paga US$2,3 M y reforma su seguridad por la brecha de AMCA en 2019

    Labcorp paga US$2,3 M y reforma su seguridad por la brecha de AMCA en 2019

    Una coalición bipartidista de 44 fiscales generales de estados de EE.UU. alcanzó un acuerdo con Labcorp por US$2,3 millones y un compromiso de reformas profundas en sus prácticas de seguridad de datos, cerrando así uno de los capítulos pendientes del caso American Medical Collection Agency (AMCA), la brecha que en 2019 expuso millones de registros médicos y financieros de pacientes.

    El acuerdo fue anunciado el jueves 25 de septiembre de 2026, según informó DataBreaches.net. La acción legal se originó en el incidente de AMCA, un procesador de cobros médicos externo cuyos sistemas fueron comprometidos en 2019 y que afectó a múltiples laboratorios clínicos, entre ellos Labcorp y Quest Diagnostics. La investigación coordinada por los estados apuntó a las prácticas de ciberseguridad de Labcorp como empresa que tercerizaba el procesamiento de datos a ese proveedor. Además de la multa, Labcorp deberá implementar un programa integral de seguridad de datos supervisado externamente, según se informó.

    44 estados, US$2,3 millones y reformas concretas contra AMCA

    • Monto de la multa: US$2,3 millones, distribuido entre los 44 estados participantes.
    • Coalición: 44 fiscales generales de alcance bipartidista.
    • Origen del caso: brecha de American Medical Collection Agency (AMCA), detectada en 2019.
    • Compromiso adicional: reformas integrales en las prácticas de seguridad de datos de Labcorp, según se informó.
    • Fecha del anuncio: 25 de septiembre de 2026.

    Qué está confirmado y qué falta precisar

    Está confirmado el acuerdo, la cifra de la multa y la participación de 44 estados. Lo que aún no se ha detallado públicamente es el alcance exacto de las reformas de seguridad exigidas a Labcorp: si incluyen auditorías de terceros, plazos específicos de implementación o indicadores verificables de cumplimiento. Tampoco se ha precisado el número total de titulares de datos afectados por la actuación de Labcorp en el incidente AMCA, aunque la brecha original involucró, según se informó en su momento, a millones de personas en territorio estadounidense. El acuerdo con Quest Diagnostics, también implicada en el mismo origen, tiene su propio historial de litigación separado.

    El caso ilustra un patrón relevante para operadores de datos de salud en América Latina: la responsabilidad por incidentes en proveedores externos. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece en su artículo 42 la responsabilidad solidaria entre controladores y operadores cuando el daño deriva del tratamiento. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) ha señalado en sus lineamientos que la tercerización no exime al responsable del fichero. En México, la LFPDPPP contempla obligaciones contractuales con encargados del tratamiento. En los tres marcos, una empresa en la posición de Labcorp —que delega el procesamiento a un tercero— mantiene deberes de diligencia debida y supervisión que no se transfieren con el contrato.

    El próximo hito a seguir es la publicación del plan de reformas de seguridad comprometido por Labcorp, que determinará si el acuerdo fija un estándar replicable para otros operadores del sector salud.

  • Puerto de Los Ángeles bloqueó 120 millones de ciberataques en agosto

    Puerto de Los Ángeles bloqueó 120 millones de ciberataques en agosto

    El Puerto de Los Ángeles —el hub de contenedores más activo de Estados Unidos— repelió más de 120 millones de ciberataques durante agosto de 2026, según informó Bloomberg News el 17 de septiembre citando declaraciones del director ejecutivo del puerto, Gene Seroka. La cifra convierte a esta infraestructura crítica en uno de los blancos más atacados del sector logístico global.

    Seroka confirmó el volumen de ataques en el marco de una discusión más amplia sobre amenazas operativas al comercio internacional, en un contexto de tensión arancelaria que eleva el valor estratégico —y la exposición política— de los principales puertos estadounidenses. El Puerto de Los Ángeles procesa una proporción significativa del comercio contenedorizado entre Asia y América del Norte, lo que lo convierte en objetivo prioritario tanto para actores estatales como para grupos de ransomware con motivaciones económicas.

    120 millones de intentos: volumen, no vulneraciones confirmadas

    • Período: agosto de 2026 (31 días)
    • Volumen reportado: más de 120 millones de ciberataques bloqueados
    • Fuente primaria: Gene Seroka, director ejecutivo del Puerto de Los Ángeles, según Bloomberg News
    • Infraestructura afectada: hub de contenedores de mayor tráfico en EE.UU.
    • Exfiltración de datos confirmada: ninguna según se informó hasta el momento de la publicación

    Qué está confirmado y qué falta verificar

    Lo confirmado, según Bloomberg: el volumen de intentos bloqueados y la condición de amenaza operativa continua. Lo que no se ha precisado públicamente incluye la naturaleza técnica de los ataques (denegación de servicio, intentos de intrusión, phishing dirigido), la atribución a actores específicos, y si algún sistema de gestión de carga o datos logísticos fue comprometido de forma parcial. La ausencia de notificación de brecha no equivale a seguridad total: en infraestructuras críticas, los ataques de reconocimiento no siempre dejan rastro inmediato.

    El contexto arancelario mencionado por Seroka es relevante: los puertos que operan como nodos de re-ruteo comercial ante restricciones tarifarias concentran flujos de datos sensibles —manifiestos de carga, información de importadores, datos de cadena de suministro— que tienen valor de inteligencia económica. En América Latina, puertos como el de Santos (Brasil), Manzanillo (México) y el Callao (Perú) operan con exposición similar pero con marcos de respuesta a incidentes notoriamente menos maduros. Brasil cuenta con la LGPD y con lineamientos del Banco Central para infraestructuras financieras críticas, pero la regulación sectorial portuaria aún no exige notificación de incidentes cibernéticos en plazos definidos. México, bajo la LFPDPPP, tampoco tiene un régimen específico de reporte obligatorio para infraestructuras de transporte.

    El próximo hito a seguir: si el Puerto de Los Ángeles activa algún protocolo formal de divulgación ante la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) de EE.UU., ese reporte podría revelar datos técnicos que hoy no están disponibles.

  • El punto ciego de datos que limita cualquier estrategia nacional de IA

    El punto ciego de datos que limita cualquier estrategia nacional de IA

    Las estrategias nacionales de inteligencia artificial —incluidas las de América Latina— priorizan infraestructura computacional, talento y modelos fundacionales, pero rara vez abordan con seriedad el problema anterior a todo eso: la gobernanza de los datos sobre los que esos sistemas se entrenan y operan. Sin datos bien gestionados, confiables y legalmente disponibles, la capacidad de cómputo es irrelevante.

    Cuando los gobiernos diseñan políticas de IA, la conversación suele girar en torno a chips, centros de datos, algoritmos y financiamiento para investigación. Lo que queda fuera del debate —o aparece en notas al pie— es la calidad, disponibilidad y gobernanza de los datos que alimentan esos sistemas. Este es el punto ciego estructural que The National Interest identificó en la estrategia estadounidense y que, con matices propios, reproduce casi toda política de IA en la región.

    Por qué los datos son la capa que decide el rendimiento de la IA

    Un modelo de inteligencia artificial es, en última instancia, una función de los datos con los que fue entrenado. La calidad, representatividad y trazabilidad de esos datos determinan tanto el rendimiento técnico del sistema como su exposición legal. Un modelo entrenado con datos fragmentados, desactualizados o de procedencia jurídicamente cuestionable puede fallar en producción, generar outputs discriminatorios o quedar expuesto a litigios por derechos de autor o privacidad. Ninguno de esos riesgos se resuelve comprando más poder de cómputo.

    El problema tiene dos dimensiones. La primera es técnica: los datos públicos disponibles en la web están sesgados lingüística y geográficamente hacia el inglés y el hemisferio norte, lo que penaliza directamente a los modelos diseñados para operar en español, portugués o lenguas indígenas. La segunda es jurídica: los marcos de protección de datos personales —LGPD en Brasil, Ley 25.326 en Argentina, LFPDPPP en México, la Ley 1581 en Colombia— imponen restricciones sobre qué datos pueden reutilizarse con fines de entrenamiento y bajo qué condiciones. Ninguna estrategia nacional de IA que ignore esta capa puede considerarse completa.

    Cuándo aplica este análisis / cuándo NO

    Este argumento aplica directamente a cualquier Estado o empresa que esté desarrollando o adquiriendo sistemas de IA para uso en políticas públicas, servicios críticos o decisiones que afecten derechos individuales. También aplica a los proveedores privados que compiten por contratos gubernamentales en sectores como salud, educación o seguridad. No aplica —o aplica de forma más laxa— a modelos de IA utilizados en entornos completamente cerrados, con datos propios, sin tratamiento de datos personales y sin impacto en decisiones de alto riesgo. En la práctica, esos casos son la excepción, no la regla.

    El vacío regulatorio que amplia el riesgo en LATAM

    América Latina se encuentra en una posición paradójica: tiene marcos de protección de datos relativamente maduros en sus economías más grandes, pero carece casi por completo de regulación específica sobre el uso de datos en el entrenamiento de modelos de IA. Brasil avanza con su marco de regulación de IA en el Congreso, que según se informó incluiría disposiciones sobre transparencia de datos de entrenamiento. Argentina no cuenta aún con legislación equivalente, aunque la Agencia de Acceso a la Información Pública (AAIP) ha emitido guías orientadoras. México y Colombia tampoco tienen normas vinculantes sobre este punto.

    Esta brecha crea un escenario en el que los Estados pueden adoptar o contratar sistemas de IA sin exigir a los proveedores ninguna declaración verificable sobre el origen, calidad o cumplimiento normativo de los datos utilizados en el entrenamiento. En la Unión Europea, el AI Act —vigente desde agosto de 2024— exige exactamente eso para los sistemas de alto riesgo: documentación de los datos de entrenamiento, validación, y trazabilidad. Las empresas que exporten sistemas a mercados europeos ya enfrentan estos requisitos; las que operan solo en LATAM, todavía no.

    Lo que falta en el diseño de política pública de IA

    Una estrategia nacional de IA que no responde tres preguntas básicas sobre datos tiene un problema estructural: ¿qué datos públicos están disponibles para entrenamiento, bajo qué condiciones legales y con qué nivel de calidad documentado? ¿Qué restricciones impone la legislación de protección de datos personales vigente sobre el reutilización de datos para este fin? ¿Qué mecanismos de auditoría existen para verificar que los sistemas adquiridos por el Estado cumplen con los estándares declarados? Sin respuestas concretas a estas preguntas, las estrategias de IA son, en el mejor de los casos, hojas de ruta incompletas.

    Algunos gobiernos de la región empiezan a incorporar la dimensión de datos en sus marcos de IA. Chile, con su Política Nacional de Inteligencia Artificial actualizada en 2024, menciona explícitamente la calidad de datos como habilitador crítico. Uruguay avanza en la creación de repositorios de datos públicos con estándares de apertura. Pero la mención en documentos de política y la implementación operativa siguen siendo cosas distintas.

    Para quienes diseñan o evalúan políticas de IA en la región, el punto de partida no es elegir un modelo o una plataforma: es auditar qué datos existen, cuáles pueden usarse legalmente y cuáles están en condiciones de ser usados con utilidad real. Todo lo demás viene después. La referencia técnica más completa para esta evaluación sigue siendo el marco NIST AI RMF, que dedica su función “MAP” exactamente a este diagnóstico previo.

  • HHS sanciona a Ambry Genetics por violar la Security Rule de HIPAA

    HHS sanciona a Ambry Genetics por violar la Security Rule de HIPAA

    La Oficina de Derechos Civiles del Departamento de Salud de Estados Unidos (OCR/HHS) cerró un acuerdo de resolución con Ambry Genetics Corporation por presuntas violaciones a la Security Rule de HIPAA. El caso pone en foco los estándares de seguridad para datos de salud genética —un tipo de dato cuya sensibilidad y consecuencias para terceros no tiene equivalente en ningún otro sector— y llega en un momento en que varios países de América Latina están revisando sus marcos de protección para datos biométricos y de salud.

    Ambry Genetics, con sede en Aliso Viejo, California, es una empresa dedicada a pruebas genéticas diagnósticas y está clasificada como “covered entity” bajo HIPAA. La Security Rule de esa ley establece salvaguardas administrativas, físicas y técnicas que las entidades cubiertas deben implementar para proteger la información de salud electrónica protegida (ePHI). Según informó OCR, la investigación detectó incumplimientos en esas salvaguardas, aunque al cierre de esta nota el monto del acuerdo y el detalle técnico de las fallas no habían sido publicados en su totalidad por HHS.

    La Security Rule de HIPAA: qué exige y dónde suelen fallar las empresas de genómica

    La Security Rule de HIPAA no es una norma de ciberseguridad genérica: exige análisis de riesgo documentado, gestión de riesgos continua, controles de acceso, auditoría de sistemas y planes de contingencia, entre otros requerimientos. Las empresas de pruebas genéticas son un blanco de escrutinio particular porque manejan datos que identifican no solo al paciente sino también a sus familiares biológicos, lo que amplifica el potencial de daño en caso de brecha. OCR ha incrementado su actividad de enforcement en los últimos años, con énfasis en organizaciones de salud que procesan datos genómicos y de laboratorio clínico.

    El patrón de falla más frecuente en casos resueltos por OCR incluye análisis de riesgo incompletos o no actualizados, ausencia de procedimientos de revisión de actividad en sistemas críticos y controles de acceso insuficientes para usuarios con privilegios elevados. Aunque el expediente de Ambry no detalla públicamente cuál de esas fallas fue determinante, el solo hecho de que OCR haya iniciado investigación y llegado a un acuerdo indica que al menos uno de esos pilares estuvo comprometido.

    Datos genéticos en LATAM: Argentina, Brasil y México ante un vacío regulatorio específico

    El caso Ambry Genetics es relevante para la región porque ningún país de América Latina cuenta aún con un régimen de seguridad técnica tan detallado como HIPAA para datos de salud genética, aunque los tres marcos principales de la región los clasifican como datos sensibles con protección reforzada. En Argentina, la Ley 25.326 de Protección de Datos Personales los incluye en la categoría de datos sensibles cuyo tratamiento está sujeto a requisitos de consentimiento expreso y medidas de seguridad adicionales; sin embargo, la normativa no especifica controles técnicos mínimos equivalentes a la Security Rule. La Autoridad de Aplicación (AAIP) tiene facultades de investigación, pero el enforcement en el sector salud ha sido históricamente reactivo.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) clasifica los datos genéticos como datos sensibles en su artículo 5, inciso II, y exige que su tratamiento tenga base legal específica. La Autoridade Nacional de Proteção de Dados (ANPD) publicó en 2023 su regulación de seguridad de la información (Resolução CD/ANPD nº 2/2022), que establece obligaciones de gestión de incidentes y medidas de seguridad proporcionales al riesgo, pero aún sin la granularidad sectorial que tiene HIPAA para salud. En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) y sus Lineamientos del Aviso de Privacidad también reconocen los datos de salud como sensibles, pero el INAI no ha emitido estándares técnicos sectoriales específicos para laboratorios genéticos o empresas de genomics.

    Chile presenta un caso distinto: la nueva Ley 21.719 de Protección de Datos Personales, publicada en 2024 y con plazo de adecuación en curso, eleva significativamente el estándar de protección para datos sensibles e incorpora obligaciones de evaluación de impacto (EIPD) para tratamientos de alto riesgo. Los datos genéticos quedan comprendidos en esa categoría, lo que en la práctica obliga a clínicas, laboratorios y empresas de biotecnología con operación en Chile a hacer análisis de riesgo documentados, el mismo punto donde HIPAA exige más y donde Ambry Genetics aparentemente falló.

    Por qué el modelo de enforcement de OCR importa más allá de EE.UU.

    Los acuerdos de OCR funcionan como señales de precio para el mercado: fijan el costo esperado del incumplimiento y —cuando incluyen planes de acción correctiva— establecen un estándar de facto para el sector. Las empresas latinoamericanas de biotecnología o salud digital que operan en EE.UU. o procesan datos de ciudadanos estadounidenses están directamente alcanzadas por HIPAA. Pero más allá de la jurisdicción directa, el patrón de enforcement de OCR alimenta las decisiones de autoridades locales sobre qué controles exigir y cómo graduarlos por sector. La ANPD brasileña, que ya citó al GDPR europeo como referencia para su regulación de seguridad, tiene incentivos para mirar también el modelo HIPAA cuando diseñe guías sectoriales para datos de salud.

    Qué monitorear: adecuación chilena, guías sectoriales de ANPD y reforma argentina en 2026

    Tres hitos regulatorios de corto plazo merecen seguimiento directo a partir de este caso. Primero, el proceso de adecuación a la Ley 21.719 en Chile, cuyo plazo vence en 2026 para la mayoría de los obligados: los laboratorios y empresas de diagnóstico genético deberían estar cerrando sus EIPD ahora. Segundo, cualquier guía sectorial que emita la ANPD para el sector salud en Brasil —un documento esperado pero aún no publicado— podría incorporar exigencias de análisis de riesgo similares a las que activaron el caso Ambry. Tercero, Argentina tiene en trámite legislativo un proyecto de reforma a la Ley 25.326; si ese proyecto avanza hacia estándares técnicos más específicos para datos sensibles, el precedente de OCR será una referencia útil para los redactores del reglamento.

    Nuestro análisis

    El enforcement de HIPAA sobre empresas de genómica no es una curiosidad del sistema de salud estadounidense: es el anticipo de dónde van a terminar los reguladores latinoamericanos cuando el sector de biotecnología y diagnóstico genético escale en la región. La combinación de datos de altísima sensibilidad, cadena de custodia compleja y empresas con estructuras de compliance todavía débiles es exactamente el escenario que activa investigaciones como la de Ambry Genetics. Las autoridades de la región tienen las herramientas legales —datos sensibles con protección reforzada— pero les falta el complemento: estándares técnicos sectoriales con dientes. Mientras ese complemento no llegue, las empresas que operen en ambos mercados estarán respondiendo a HIPAA con más detalle del que exigen sus reguladores locales. Esa asimetría es una ventaja temporal, no una situación sostenible.

    La pregunta que deberían hacerse los laboratorios y empresas de salud digital en Argentina, Brasil, Chile y México no es si sus datos genéticos están protegidos por ley —lo están— sino si sus controles técnicos documentados resistirían el escrutinio de un regulador que, como OCR, pide ver el análisis de riesgo actualizado antes de cualquier otra cosa.

  • Centro oncológico de Singapur expone datos de pacientes con cáncer hereditario por error de CC

    Centro oncológico de Singapur expone datos de pacientes con cáncer hereditario por error de CC

    El National Cancer Centre Singapore (NCCS) expuso involuntariamente los datos de identidad, contacto y lugar de trabajo de pacientes con condiciones genéticas de cáncer al enviar una invitación masiva con la lista de destinatarios visible, según se informó el 19 de septiembre de 2026.

    El incidente se originó en un correo electrónico de invitación a un evento denominado “Living with…” dirigido a personas con enfermedades oncológicas de origen genético. En lugar de ocultar a los destinatarios mediante copia oculta (CCO), el mensaje fue enviado con todos los contactos visibles en el campo CC, lo que expuso nombres, correos electrónicos, números de contacto y, en algunos casos, el empleador de los afectados. La información así revelada es especialmente sensible: la condición genética de cáncer es, por definición, un dato de salud que permite inferir antecedentes familiares.

    Datos confirmados sobre el incidente en Singapur

    • Organización involucrada: National Cancer Centre Singapore (NCCS), institución pública de referencia oncológica.
    • Tipo de dato expuesto: nombre, datos de contacto y, en varios casos, lugar de trabajo de los destinatarios.
    • Naturaleza del dato: condición genética de cáncer — categoría de salud de máxima sensibilidad.
    • Mecanismo del fallo: uso de campo CC en lugar de CCO en un correo masivo institucional.
    • Estado del incidente: calificado como “alegado” al momento de la publicación; no hay confirmación oficial pública de NCCS según se informó.

    Qué se sabe y qué falta confirmar

    Lo confirmado es el envío del correo con la lista de destinatarios visible y la sensibilidad de los datos involucrados. Lo que permanece sin verificar incluye la cantidad exacta de afectados, si NCCS notificó al regulador de Singapur (Personal Data Protection Commission, PDPC) dentro del plazo de tres días hábiles que exige la Personal Data Protection Act (PDPA) para brechas de datos significativas, y si la entidad activó un protocolo de respuesta ante el incidente. Tampoco se ha informado públicamente si los pacientes afectados recibieron notificación individual.

    El error CC —usar copia abierta en lugar de copia oculta— es uno de los vectores de exposición más recurrentes en organizaciones de salud a nivel global, y su persistencia indica fallas en controles básicos de emisión de comunicaciones masivas. En contextos de datos de salud, el impacto no es solo legal: revelar que alguien porta una condición genética oncológica puede tener consecuencias en su entorno laboral, familiar y asegurador. En América Latina, legislaciones como la Ley 25.326 de Argentina, la LGPD de Brasil y la LFPDPPP de México clasifican los datos de salud —y con mayor razón los datos genéticos— como datos sensibles, cuyo tratamiento inadecuado habilita sanciones agravadas y, en algunos marcos, responsabilidad penal. Un incidente equivalente protagonizado por un hospital público en la región activaría, según el país, la obligación de notificar tanto a la autoridad de control como a los titulares afectados en plazos de entre 24 y 72 horas.

    El próximo hito crítico es la confirmación —o ausencia— de notificación formal de NCCS ante la PDPC de Singapur, cuyo plazo obligatorio bajo la PDPA vence tres días hábiles después de que la organización tomó conocimiento del incidente.