DataTrends LATAM

Blog

  • Gobernanza de datos en salud: por qué el dato clínico exige reglas distintas

    Gobernanza de datos en salud: por qué el dato clínico exige reglas distintas

    El dato clínico es el activo más sensible que gestiona una organización de salud: identifica, predice y, si se pierde el control, discrimina. Expertos del sector coinciden en que sin una gobernanza de datos robusta no hay atención centrada en el paciente, sino solo tecnología costosa sin dirección.

    Hablar de gobernanza de datos en salud no es hablar de burocracia interna. Es hablar de quién tiene autoridad sobre un expediente clínico, cómo se classifica un diagnóstico antes de que llegue a un sistema de análisis, y qué ocurre con ese dato cuando el paciente cruza de un prestador a otro. La definición operativa que maneja la industria, alineada con el DAMA-DMBOK, es clara: gobernanza de datos clínicos es el conjunto de políticas, roles y procesos que determinan quién puede usar un dato, para qué y con qué controles. Sin esa estructura, los proyectos de IA clínica, interoperabilidad y medicina personalizada colapsan antes de llegar a producción.

    El dato clínico tiene propiedades que complican su gobierno

    A diferencia del dato transaccional de un e-commerce, el dato clínico es longitudinal —acompaña al paciente décadas—, multifuente —laboratorio, imagen, farmacia, wearable— y jurídicamente sensible desde el momento de su creación. Esto impone exigencias específicas sobre el data lineage: no alcanza con saber dónde vive el dato, hay que poder reconstruir cada transformación que sufrió desde la consulta médica hasta el modelo predictivo. En sistemas hospitalarios que operan con múltiples EHR (electronic health records) y proveedores de nube, esa trazabilidad suele romperse en la primera integración. El rol del data steward clínico —distinto al steward financiero— debe incluir competencias en terminología médica estandarizada (HL7 FHIR, SNOMED CT, ICD-10) además de las capacidades habituales de governance.

    Cuándo aplica / cuándo NO una arquitectura de gobernanza estándar en salud

    Una arquitectura de gobernanza corporativa estándar aplica en salud cuando el objetivo es gestionar datos administrativos: facturación, RRHH, proveedores. No aplica —o aplica con modificaciones profundas— cuando el dato es parte del acto médico. En ese caso, los frameworks deben incorporar dimensiones de consentimiento informado, finalidad de tratamiento y minimización de datos que en otros sectores son opcionales. El EDM Council (CDMC) tiene controles específicos para datos regulados que pueden adaptarse, pero ningún marco genérico reemplaza la política de datos clínicos diseñada para el contexto sanitario específico de cada país. Un hospital que aplica DCAM capability 8 (data risk and compliance) sin adaptarlo a la normativa de salud local opera con un control de papel.

    En América Latina, la regulación sectorial presiona antes que los marcos voluntarios

    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, lo que impone requisitos de consentimiento específico y restringe el uso secundario —incluyendo el entrenamiento de modelos de IA— sin base legal explícita. La Autoridade Nacional de Proteção de Dados (ANPD) ha señalado el sector salud como área de atención prioritaria. En Argentina, la Ley 25.326 de Protección de Datos Personales también categoriza los datos de salud como sensibles, y las clínicas y hospitales que operan bases de datos están obligados a inscribirse ante la AAIP. En México, la LFPDPPP y su reglamento aplican a los prestadores privados, mientras que el sector público enfrenta un régimen mixto que genera fricciones operativas cuando se intenta compartir datos entre IMSS, ISSSTE y prestadores privados en proyectos de interoperabilidad. En Colombia, la Ley 1581/2012 sigue la misma lógica de datos sensibles con requisitos de autorización expresa. Ninguno de estos marcos jurídicos resuelve por sí solo el problema operativo: la gobernanza de datos es la capa que traduce la obligación legal en control técnico.

    Tres fricciones que aparecen siempre en proyectos de datos clínicos

    • Ownership difuso: el expediente clínico tiene múltiples custodios (médico, institución, paciente) y la política de datos raramente define quién tiene autoridad de decisión sobre cambios en el dato maestro del paciente.
    • Calidad en origen: los datos que ingresan al sistema de análisis provienen de digitación manual, formularios no estandarizados y sistemas legados con codificaciones propias. Sin data quality rules en el punto de captura, el modelo downstream hereda el error.
    • Consentimiento no granular: el formulario de consentimiento del paciente raramente distingue entre uso para atención directa, investigación anónima, entrenamiento de IA o compartición con aseguradoras. Esa falta de granularidad expone a la institución ante la autoridad de control cuando llega una solicitud de ejercicio de derechos.

    Resolver estas tres fricciones no es un proyecto de tecnología: es un proyecto de gobernanza con entregables concretos —política de ownership, diccionario de datos clínicos, registro de consentimientos con versionado— antes de que entre en escena cualquier plataforma.

    Para profundizar en los requisitos de tratamiento de datos sensibles en salud, el texto completo de la LGPD (artículo 11) y la Resolución CD/ANPD Nº 15/2024 sobre seguridad de la información son punto de partida obligado para cualquier equipo que opere en Brasil o aspire a interoperar con prestadores brasileños.

  • Reconocimiento facial en tiempo real llega al metro de Londres

    Reconocimiento facial en tiempo real llega al metro de Londres

    La policía ferroviaria británica comenzó a desplegar reconocimiento facial en vivo en el metro de Londres, con la estación Victoria como primer punto de implementación. La medida activa alertas entre organizaciones de privacidad, que advierten que la tecnología está dejando de ser excepcional para volverse rutinaria en el espacio público.

    El sistema, operado por la British Transport Police (BTP), permite identificar en tiempo real a personas que circulan por las instalaciones del Underground comparando sus rostros contra bases de datos de individuos buscados. No se trata de un piloto experimental: según se informó, la decisión es operativa y el despliegue progresivo comenzó en agosto de 2026. La elección de Victoria —una de las estaciones con mayor tráfico de pasajeros en toda la red— no es menor: cualquier tecnología instalada ahí alcanza escala masiva desde el primer día.

    Por qué Victoria y por qué ahora

    El argumento de las autoridades sigue el patrón estándar de seguridad pública: identificar sospechosos, prevenir delitos, proteger a los viajeros. Lo que distingue este caso es la velocidad con que el reconocimiento facial en vivo pasó de ser una tecnología cuestionada a una herramienta operativa normalizada en el Reino Unido. La policía metropolitana de Londres ya la venía usando en exteriores; extenderla al subterráneo cierra el círculo de vigilancia en los desplazamientos cotidianos de millones de personas. Grupos como Big Brother Watch llevan años documentando las tasas de error de estos sistemas —en particular su desempeño desproporcionadamente peor con personas de piel oscura— sin que eso haya frenado la expansión.

    El marco legal que habilita —y el que no regula— la biometría masiva en el Reino Unido

    En el Reino Unido post-Brexit, el régimen de protección de datos está contenido en el UK GDPR y la Data Protection Act 2018. Los datos biométricos califican como categoría especial, lo que en teoría exige una base legal reforzada para su tratamiento. Sin embargo, la excepción de prevención e investigación de delitos —artículo 10 de la DPA 2018— ha operado como puerta de entrada para estos despliegues sin que exista una ley específica sobre reconocimiento facial en espacios públicos. El Information Commissioner’s Office (ICO) ha emitido advertencias pero no ha bloqueado ningún despliegue policial. El resultado práctico es una tecnología que avanza más rápido que su propio marco normativo.

    Cuándo aplica el reconocimiento facial en vivo y cuándo no debería

    Los defensores del sistema distinguen entre reconocimiento facial retrospectivo —analizar imágenes ya capturadas tras un delito— y reconocimiento en vivo, que implica identificar personas en tiempo real sin causa previa. El primero tiene amparo jurídico más sólido; el segundo introduce vigilancia masiva de facto sobre toda persona que transite por el área monitoreada, con independencia de si es buscada o no. La diferencia es constitucional: el reconocimiento en vivo invierte la presunción de inocencia al tratar a todos los transeúntes como sujetos de escrutinio policial preventivo.

    América Latina: el mismo debate, marcos regulatorios más débiles

    Lo que ocurre en el Underground de Londres es un espejo adelantado de tensiones que ya se viven en la región. En Buenos Aires, el sistema de reconocimiento facial en el espacio público fue suspendido en 2022 por orden judicial tras comprobarse errores de identificación y uso irregular de la base de datos; la causa involucró a la Agencia de Acceso a la Información Pública (AAIP). En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos biométricos como datos sensibles bajo el artículo 11, pero no existe aún una prohibición expresa del reconocimiento facial en vivo por parte de autoridades de seguridad. En México, la LFPDPPP regula el tratamiento de datos biométricos en el sector privado con mayor precisión que en el sector público, donde los marcos son más difusos. Colombia avanza en una reforma integral a su Ley 1581 de 2012, pero el uso policial de biometría no está en el centro del debate legislativo actual. En ningún país de la región existe hoy una norma que fije con claridad los requisitos de proporcionalidad, supervisión judicial previa y auditoría de sesgos para el reconocimiento facial en vivo en espacios públicos.

    La pendiente normativa: de la excepción al estándar

    La advertencia de los grupos de privacidad británicos apunta a un riesgo sistémico que trasciende la geografía: cuando una tecnología se normaliza operativamente antes de que exista regulación específica, el costo político de prohibirla o revertirla crece con cada despliegue adicional. El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act), que entró en vigor en agosto de 2024, prohíbe en su artículo 5 el uso de sistemas de identificación biométrica remota en tiempo real en espacios públicos para propósitos policiales, con excepciones acotadas. Ese estándar no aplica al Reino Unido ni a ningún país latinoamericano, pero constituye hoy la referencia de más alto rango disponible para legisladores que quieran establecer límites.

    El texto íntegro del AI Act, incluyendo las prohibiciones de biometría en tiempo real, está disponible en el Diario Oficial de la Unión Europea (Reglamento 2024/1689). Para el debate regional, el fallo judicial de Buenos Aires de 2022 y la resolución de la AAIP asociada siguen siendo la referencia jurisprudencial más concreta de América Latina sobre los límites del reconocimiento facial en el espacio público.

  • AI Act de la UE: qué deben revisar las empresas de LATAM antes de 2026

    AI Act de la UE: qué deben revisar las empresas de LATAM antes de 2026

    El AI Act de la Unión Europea ya no es un problema exclusivo de las empresas europeas. Las obligaciones del reglamento alcanzan a cualquier organización global que comercialice o despliegue sistemas de inteligencia artificial en territorio de la UE, y eso incluye a firmas latinoamericanas con operaciones, clientes o socios en Europa. Con los primeros plazos de cumplimiento ya vigentes y los correspondientes a sistemas de alto riesgo aproximándose, revisar la estrategia de compliance dejó de ser optativo.

    El Reglamento (UE) 2024/1689 —conocido como AI Act— entró en vigor el 1 de agosto de 2024. Su aplicación es escalonada: las prohibiciones absolutas sobre prácticas de IA inaceptables (manipulación subliminal, sistemas de puntuación social, reconocimiento de emociones en ciertos contextos) comenzaron a regir desde febrero de 2025. Las obligaciones para sistemas de IA de propósito general (GPAI), incluyendo los modelos de lenguaje de gran escala, aplican desde agosto de 2025. Los requisitos para sistemas de alto riesgo —los de mayor complejidad técnica y documental— vencen en agosto de 2026. El calendario no admite demoras.

    Qué define al AI Act como norma de alcance extraterritorial

    El artículo 2 del AI Act establece su ámbito de aplicación con claridad: alcanza a proveedores que comercializan o ponen en servicio sistemas de IA en la UE, independientemente de dónde estén establecidos. También alcanza a los “deployers” —empresas que utilizan sistemas de IA en sus operaciones— cuando estos se encuentran en la UE. Esto significa que una empresa con sede en Buenos Aires, Ciudad de México o São Paulo que venda software con componentes de IA a clientes europeos, o que use plataformas de IA de proveedores globales para procesar datos de ciudadanos de la UE, queda dentro del alcance del reglamento. El modelo de extraterritorialidad es análogo al del GDPR, cuya aplicación ya genera litigios y multas a empresas latinoamericanas con presencia digital en Europa.

    La clasificación de riesgo es el eje del sistema. Los sistemas de alto riesgo —listados en el Anexo III del reglamento— incluyen herramientas de reclutamiento y selección de personal, sistemas de scoring crediticio, plataformas de evaluación educativa y soluciones para infraestructura crítica. Para estas categorías, las obligaciones incluyen: documentación técnica exhaustiva, registro en una base de datos de la UE, supervisión humana, evaluación de conformidad previa al despliegue y un sistema de gestión de riesgos activo durante todo el ciclo de vida del sistema.

    El estado regulatorio de IA en Argentina, Brasil y México

    Ningún país de América Latina tiene aún una ley de IA equivalente al AI Act, pero los tres principales mercados de la región se encuentran en movimiento regulatorio activo. En Argentina, el Ministerio de Ciencia, Tecnología e Innovación publicó en 2023 una Guía para el Uso de IA Responsable en el Sector Público, de carácter no vinculante. La Agencia de Acceso a la Información Pública (AAIP) ha señalado que los sistemas de IA que traten datos personales quedan sujetos a la Ley 25.326, lo que abre la puerta a sanciones si un sistema automatizado produce decisiones sin las garantías del artículo 14 de esa norma —que reconoce el derecho a no ser objeto de decisiones basadas exclusivamente en tratamiento automatizado.

    Brasil avanza con el Proyecto de Ley 2338/2023, que sigue una arquitectura de riesgo similar al AI Act europeo y define categorías de sistemas de alto y muy alto riesgo con obligaciones diferenciadas. El proyecto está en el Senado y, según se informó, podría ser votado antes de que concluya 2025. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió en 2023 el Relatório de Atividade de Fiscalização sobre el uso de IA y datos personales, marcando la voluntad de intervenir antes de que exista una ley específica. En México, la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) aplica a decisiones automatizadas que afecten a titulares, pero el país carece de un marco sectorial de IA. El INAI ha publicado documentos de posición, sin fuerza vinculante.

    Esta brecha regulatoria crea un escenario de asimetría: las empresas latinoamericanas que operan en Europa deben cumplir el AI Act sin contar con marcos locales que las guíen en cómo hacerlo. El riesgo no es solo de multa europea —que puede alcanzar hasta 35 millones de euros o el 7% de la facturación global anual para las infracciones más graves— sino de quedar excluidas de cadenas de suministro de software y servicios que ya exigen declaraciones de conformidad a sus proveedores.

    Tres brechas operativas que las empresas deben cerrar antes de agosto de 2026

    El cumplimiento del AI Act no es solo un ejercicio jurídico. Requiere capacidades técnicas y de gobernanza que muchas organizaciones latinoamericanas aún no tienen formalizadas. Las brechas más frecuentes identificadas en análisis comparativos de cumplimiento incluyen:

    • Ausencia de inventario de sistemas de IA: sin un catálogo actualizado de los modelos y herramientas en uso —incluyendo las adquiridas a terceros— es imposible clasificar el riesgo ni asignar responsabilidades. Esto es equivalente a carecer de un data catalog en gobernanza de datos.
    • Falta de documentación técnica estandarizada: el AI Act exige para sistemas de alto riesgo documentación que cubra el diseño, los datos de entrenamiento, las métricas de rendimiento y los planes de monitoreo post-despliegue. La mayoría de los equipos técnicos de la región no produce este tipo de artefactos de forma sistemática.
    • Vacío en la cadena de responsabilidad proveedor-deployer: cuando una empresa usa un modelo de IA de un proveedor global (OpenAI, Google, Microsoft, entre otros), el AI Act distribuye obligaciones entre proveedor y deployer. Sin contratos que reflejen esa distribución, el deployer asume riesgos que no anticipó.

    Qué monitorear: los próximos hitos del AI Act y sus efectos en la región

    El plazo de agosto de 2026 para sistemas de alto riesgo es el más urgente, pero no el único hito relevante. La Oficina de IA de la Comisión Europea —creada específicamente para supervisar la implementación del reglamento— publicará estándares armonizados y guías técnicas durante 2025 y 2026. Las empresas que ya operan bajo el GDPR deben prestar especial atención a la interacción entre ambos reglamentos: el AI Act no deroga el GDPR, y los sistemas de IA que traten datos personales quedan sujetos a las dos normativas en paralelo. En la práctica, esto significa que una evaluación de impacto de algoritmos puede requerir tanto una Data Protection Impact Assessment (DPIA) bajo GDPR como una evaluación de conformidad bajo AI Act.

    Para empresas latinoamericanas sin presencia física en Europa, el mecanismo de enforcement más probable en el corto plazo no será una inspección de la Comisión, sino la presión contractual de clientes y socios europeos que exijan declaraciones de conformidad como condición de negocio. Esto ya ocurre con el GDPR: muchos contratos B2B europeos incluyen desde hace años cláusulas de adecuación de privacidad. El AI Act seguirá el mismo camino.

    Nuestro análisis

    El AI Act replica el patrón del GDPR: nace en Europa, pero su efecto de arrastre normativo alcanza a cualquier empresa que quiera hacer negocios en ese mercado. Lo que todavía no ocurrió —y ocurrirá— es que los marcos regulatorios de Brasil, México y Argentina converjan hacia estándares similares, en parte por presión de organismos multilaterales y en parte porque sus propias empresas tecnológicas necesitan esa convergencia para competir globalmente. El PL 2338/2023 de Brasil, si se aprueba con su arquitectura actual, será el primer AI Act latinoamericano y funcionará como referencia regional, del mismo modo en que la LGPD impulsó actualizaciones en las leyes de privacidad de Argentina, Colombia y Chile. Las organizaciones que empiecen a documentar sus sistemas de IA y a clasificarlos por riesgo ahora no solo estarán preparando su cumplimiento europeo: estarán adelantando trabajo que sus reguladores locales les van a exigir dentro de dos o tres años.

    La pregunta no es si el AI Act aplica a tu empresa latinoamericana. La pregunta es cuántos de tus sistemas de IA en producción podrían clasificar como alto riesgo bajo sus criterios, y si tenés la documentación para demostrarlo.

  • Gobernanza de datos clínica: por qué sin ownership el expediente del paciente falla

    Gobernanza de datos clínica: por qué sin ownership el expediente del paciente falla

    En salud, un dato sin dueño claro es un dato que tarde o temprano daña a alguien. La gobernanza de datos robusta —con data stewards definidos, catálogos activos y linaje trazable desde el origen clínico— es la precondición técnica y organizacional para que el modelo de atención centrada en el paciente deje de ser un objetivo declarativo y se convierta en práctica operativa.

    El concepto de atención centrada en el paciente exige que la información clínica esté disponible, sea confiable y pueda integrarse a lo largo de todo el ciclo de cuidado: desde el primer contacto en atención primaria hasta el alta hospitalaria o el seguimiento ambulatorio. Ese flujo no es posible si los datos de salud están fragmentados en silos departamentales, si no existe un responsable formal del dato —el data steward clínico— y si los sistemas de registro no comparten un esquema semántico común. La gobernanza de datos no es, en este contexto, un problema de IT: es una decisión institucional con consecuencias clínicas directas.

    El dato clínico tiene cuatro problemas de ownership que ningún EHR resuelve solo

    Un sistema de historia clínica electrónica (EHR, por sus siglas en inglés) captura el dato, pero no garantiza su calidad ni su coherencia longitudinal. Los cuatro problemas más frecuentes en entornos hospitalarios son la duplicidad de registros de paciente (un mismo individuo con múltiples identificadores), la ausencia de definiciones maestras para términos clínicos críticos (como “diagnóstico principal” o “fecha de egreso”), la falta de linaje que permita rastrear de dónde proviene un valor y quién lo modificó, y la inexistencia de un proceso formal de certificación de calidad antes de que el dato alimente tableros de gestión o modelos predictivos. Según el marco DAMA-DMBOK, estos problemas corresponden a brechas en las áreas de conocimiento de Gestión de la Calidad del Dato y Gestión de Metadatos, y ninguna herramienta tecnológica los soluciona si no hay una estructura organizacional que asigne accountability.

    Cuándo aplica la gobernanza clínica de datos — y cuándo NO

    La gobernanza de datos en salud aplica siempre que una organización tome decisiones clínicas, operativas o regulatorias basadas en datos de pacientes: hospitales, clínicas, aseguradoras de salud, laboratorios y sistemas nacionales de información sanitaria. Aplica también cuando se alimentan modelos de inteligencia artificial con datos de historia clínica, porque un modelo entrenado sobre datos sin gobierno reproducirá los sesgos y errores del registro original. Lo que la gobernanza clínica de datos NO reemplaza es la seguridad informática (controles de acceso, cifrado, gestión de incidentes) ni la privacidad en sentido estricto (consentimiento informado, derechos de acceso y rectificación del paciente): estos son dominios complementarios que requieren sus propios programas. La confusión entre los tres dominios —gobernanza, seguridad y privacidad— es uno de los errores más comunes en los proyectos de transformación digital hospitalaria en la región.

    LATAM: tres marcos regulatorios que exigen capacidades de gobernanza sin nombrarlas así

    En América Latina, varios marcos regulatorios del sector salud implican requisitos de facto de gobernanza de datos, aunque no los llamen por ese nombre. En Brasil, la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) clasifica los datos de salud como datos sensibles y exige que el operador demuestre exactitud y actualización del dato —lo que requiere procesos de calidad y linaje—. En Argentina, la Ley 25.326 de Protección de Datos Personales establece el principio de exactitud de los datos (art. 4°), que en un hospital se traduce en la necesidad de un proceso de validación y corrección del registro clínico. En México, la LFPDPPP y las Normas Oficiales Mexicanas del sector salud —en particular la NOM-004-SSA3-2012 sobre el expediente clínico— establecen estándares de integridad y conservación que son, en esencia, requisitos de governance sin el vocabulario técnico correspondiente. Las instituciones que aún tratan estos marcos como obligaciones de IT y no como programas de gobierno del dato enfrentan el doble riesgo del incumplimiento regulatorio y de la degradación silenciosa de la calidad de su información clínica.

    Tres capacidades mínimas para un CDO de salud que opera en la región

    Cualquier programa de gobernanza de datos clínicos funcional en LATAM necesita al menos tres capacidades instaladas. Primero, un Master Data Management (MDM) de paciente: un identificador único, validado y mantenido, que permita vincular registros a lo largo del tiempo y entre sistemas. Segundo, un catálogo de datos con definiciones acordadas entre las áreas clínicas, financieras y de IT, donde cada elemento crítico —diagnóstico, medicamento, evento adverso— tenga un steward asignado con nombre y apellido. Tercero, un proceso de medición periódica de calidad del dato con indicadores formales (completitud, exactitud, consistencia) publicados internamente y vinculados a decisiones de mejora. El EDM Council (CDMC) ofrece un marco de certificación que varios sistemas de salud en Europa y Norteamérica ya están adoptando; en la región, la adopción es aún marginal, pero los requisitos regulatorios mencionados arriba convergen hacia las mismas capacidades.

    Los marcos regulatorios de salud en Brasil, Argentina y México ya exigen —con distinto vocabulario— lo mismo que un programa de gobernanza de datos clínica: exactitud, trazabilidad y accountability del dato del paciente. La brecha no es de regulación; es de implementación.

  • Juez federal regula el manejo de datos robados a Change Healthcare en litigio

    Juez federal regula el manejo de datos robados a Change Healthcare en litigio

    Un juez federal de Minnesota emitió una orden judicial que establece reglas estrictas sobre cómo los datos robados durante el ciberataque a Change Healthcare en 2024 pueden ser utilizados en el marco del litigio colectivo en curso contra UnitedHealth Group. La magistrada Dulce J. Foster aprobó el plan el 7 de agosto de 2026, según informó Becker’s.

    La orden aplica a la demanda consolidada contra UnitedHealth Group y varias empresas vinculadas, y regula el acceso, almacenamiento y circulación de la información exfiltrada durante uno de los ciberataques más graves registrados contra el sector salud en Estados Unidos. El ataque de 2024 comprometió datos de salud de decenas de millones de personas, según se informó en su momento, e interrumpió operaciones de facturación médica en todo el país.

    Orden de protección sobre datos exfiltrados: qué establece

    La medida judicial define condiciones específicas bajo las cuales abogados, peritos y partes del proceso pueden acceder al material robado que ahora forma parte del expediente. Este tipo de orden —denominada “protective order” en el sistema estadounidense— es un mecanismo procesal que busca evitar que datos sensibles incorporados como evidencia sean utilizados fuera del ámbito del juicio o sufran una exposición adicional. El hecho de que se haya formalizado un protocolo diferenciado para este material refleja la sensibilidad excepcional de los registros involucrados, que incluyen información de salud protegida bajo HIPAA.

    El expediente colectivo reúne múltiples demandas contra UnitedHealth Group por su presunta responsabilidad en el incidente, incluyendo alegaciones sobre controles de seguridad insuficientes y demoras en la notificación a los afectados. La aprobación de reglas específicas de manejo sugiere que el volumen y la naturaleza de los datos exfiltrados representan un desafío procesal sin precedentes para los tribunales federales.

    Datos confirmados y qué falta verificar

    • Fecha de aprobación de la orden: 7 de agosto de 2026.
    • Autoridad firmante: magistrada Dulce J. Foster, Distrito Federal de Minnesota.
    • Demandada principal: UnitedHealth Group y otras empresas del grupo.
    • Origen de los datos: ciberataque a Change Healthcare, ocurrido en 2024.
    • Alcance del ataque: datos de decenas de millones de personas, según se informó.

    Lo que aún no está confirmado públicamente incluye el detalle exacto de las restricciones impuestas por la orden, qué categorías específicas de datos quedan bajo el protocolo diferenciado y si la medida contempla algún mecanismo de supervisión independiente sobre el cumplimiento de las partes. Tampoco se ha informado si la orden establece plazos de destrucción o devolución del material una vez concluido el proceso.

    Para los equipos jurídicos y de cumplimiento en América Latina, el caso tiene relevancia directa. Brasil, bajo la LGPD (Lei Geral de Proteção de Dados), exige notificación a la ANPD ante incidentes con “risco ou dano relevante” a los titulares; Argentina, bajo la Ley 25.326 y las disposiciones de la AAIP, contempla obligaciones similares. La pregunta que este litigio deja abierta —si las medidas de seguridad previas eran razonables— es exactamente el estándar que los reguladores latinoamericanos aplican al evaluar responsabilidad del responsable del tratamiento. Un fallo adverso contra UnitedHealth podría convertirse en referencia comparada para futuros casos en la región.

    El próximo hito procesal a seguir es la definición del calendario de descubrimiento probatorio, que determinará en qué condiciones los datos robados serán efectivamente presentados como evidencia ante el tribunal.

  • IA en banca: por qué datos, privacidad y gobernanza frenan la transformación

    IA en banca: por qué datos, privacidad y gobernanza frenan la transformación

    Los CEOs del sector financiero reconocen el potencial transformador de la inteligencia artificial en la banca, pero señalan que la gobernanza de datos, la privacidad y la calidad de la información siguen siendo los obstáculos más difíciles de resolver. Sin datos confiables y marcos sólidos de gobierno, la IA en banca no escala: automatiza el caos.

    La promesa de la IA en servicios financieros —desde la detección de fraude hasta la personalización crediticia y la atención automatizada al cliente— lleva años circulando en las salas de directorio. Lo que está cambiando es el diagnóstico de los propios líderes sobre por qué esa promesa no se materializa a la velocidad esperada. Según se informó en declaraciones de CEOs del sector bancario, los tres cuellos de botella recurrentes son la calidad de los datos internos, las exigencias de privacidad y la ausencia de marcos de gobernanza que conecten ambos planos.

    El dato sucio como límite estructural de la IA bancaria

    Un modelo de IA entrena sobre los datos que recibe. Si esos datos tienen inconsistencias de origen, duplicaciones entre sistemas core y periféricos, o metadatos sin propietario definido, el modelo hereda esos problemas y los amplifica. En la industria financiera, donde coexisten sistemas legacy de los años 80 con plataformas cloud modernas, la fragmentación del dato no es una excepción: es la norma. El DAMA-DMBOK identifica la calidad del dato como uno de las diez áreas de conocimiento centrales en gobernanza, y en banca esa dimensión se vuelve crítica antes de cualquier proyecto de IA: si no hay data stewards definidos por dominio (clientes, productos, transacciones, riesgo), nadie puede certificar qué dato alimenta qué modelo.

    El Marco de Capacidades de Gestión de Datos del EDM Council (DCAM) establece que la capacidad 8 —gestión de calidad del dato— es prerequisito para habilitar analítica avanzada. La mayoría de los bancos medianos de América Latina operan por debajo de ese umbral sin saberlo, porque nunca realizaron una evaluación formal de madurez. Implementar IA sobre esa base equivale a construir sobre arena.

    Privacidad: la regulación que no es opcional en ninguna jurisdicción bancaria de la región

    Los bancos operan con datos personales sensibles por definición: ingresos, comportamiento de gasto, historial crediticio, identidad biométrica. En América Latina, ese universo de datos está cubierto —con distintos niveles de madurez regulatoria— por la Ley General de Protección de Datos de Brasil (LGPD), la Ley 25.326 de Argentina y su autoridad de aplicación AAIP, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares de México (LFPDPPP), y la Ley 1581 de Colombia, entre otras. Cualquier sistema de IA que procese esos datos para fines distintos a los originalmente declarados al titular puede configurar una infracción, incluso si el resultado es técnicamente correcto.

    El riesgo específico en IA bancaria es el uso de datos de clientes para entrenar modelos sin base legal suficiente o sin mecanismos de exclusión disponibles para el titular. Brasil, a través de la ANPD, ya ha publicado notas técnicas sobre el uso legítimo de datos personales en sistemas automatizados. Argentina avanza en la modernización de la Ley 25.326, con un proyecto que incorpora disposiciones específicas sobre decisiones automatizadas con impacto en personas. Las instituciones que no documentan hoy qué datos alimentan qué modelos enfrentarán mañana solicitudes de acceso (DSAR) que no podrán responder.

    Gobernanza de IA: cuándo aplica y cuándo la banca no puede eludirla

    La gobernanza de IA en el sector financiero aplica en cualquier caso donde un sistema automatizado tome o asista decisiones con impacto directo sobre un cliente: aprobación o rechazo de crédito, clasificación de riesgo, detección de fraude con bloqueo de cuenta, o asignación diferenciada de productos. En todos esos escenarios, los marcos regulatorios emergentes —incluida la orientación del Comité de Basilea sobre riesgo operacional y el AI Act de la Unión Europea, que impacta a bancos con operaciones en Europa— exigen explicabilidad, supervisión humana y registros de auditoría. Un banco que no puede explicar por qué un modelo rechazó un crédito no cumple con la mayoría de las regulaciones de protección al consumidor financiero vigentes en la región.

    Lo que no aplica es la confusión entre gobernanza de datos y gobernanza de IA. Son capas distintas: la primera regula el activo (el dato); la segunda, el sistema que lo procesa. Ambas son necesarias. Un banco puede tener datos bien gobernados y aun así desplegar modelos sin accountability. El NIST AI Risk Management Framework (AI RMF) ofrece una estructura práctica para mapear riesgos por tipo de sistema y contexto de uso, adaptable al entorno regulatorio latinoamericano.

    Lo que los bancos de LATAM deben resolver antes de escalar

    En la región, la adopción de IA en banca avanza a distintas velocidades. Los bancos digitales nacidos post-2015 —Nubank en Brasil, Uala en Argentina, Mercado Pago en toda la región— parten de arquitecturas de datos modernas que facilitan la trazabilidad. Los bancos tradicionales, en cambio, enfrentan el costo y la complejidad de modernizar el dato antes de poder usarlo en producción con IA. El Banco Central de Brasil, mediante resoluciones sobre open finance, ya impone estándares de calidad e interoperabilidad que funcionan como palanca de modernización de datos: los bancos que reportan al BCB bajo esos esquemas están, en la práctica, construyendo capacidades de data lineage —trazabilidad de origen y transformación del dato— que son el primer requisito de cualquier IA auditable.

    En México, la Comisión Nacional Bancaria y de Valores (CNBV) ha incorporado criterios de gestión de riesgos tecnológicos que incluyen sistemas algorítmicos, aunque sin un marco específico de IA. En Argentina, el BCRA requiere planes de continuidad y gestión de modelos bajo la Comunicación A 7724, lo que obliga a documentar el ciclo de vida de los modelos aunque no se llame explícitamente gobernanza de IA. Esas regulaciones sectoriales existentes son el punto de entrada real para estructurar la gobernanza, no un obstáculo adicional.

    Para profundizar en los estándares aplicables, el NIST AI RMF está disponible en ai.nist.gov y el marco DCAM del EDM Council en edmcouncil.org; ambos ofrecen herramientas de autoevaluación adaptables al contexto financiero latinoamericano.

  • Atlantic Dama encalla en San Antonio Este: sin vínculo con datos

    Atlantic Dama encalla en San Antonio Este: sin vínculo con datos

    La noticia sobre el reflotamiento del buque Atlantic Dama en el Puerto de San Antonio Este, publicada por el portal Data Portuaria el 9 de agosto de 2026, no guarda relación con gobernanza de datos, privacidad, inteligencia artificial ni regulación digital. El artículo fue indexado por error bajo la fuente DAMA/DMBOK/CDMC en Google News.

    El evento describe un incidente de navegación marítima en aguas argentinas: el buque Atlantic Dama encalló en el Puerto de San Antonio Este y fue posteriormente reflotado según informó el portal especializado en logística portuaria Data Portuaria. Se trata de un suceso de índole operativa y marítima sin contenido relevante para las verticales editoriales de DataTrends LATAM —gobernanza de datos, privacidad, Legal AI o regulación digital.

    Por qué esta nota no se publica en DataTrends LATAM

    DataTrends LATAM cubre exclusivamente temas de gobernanza de datos corporativa, protección de datos personales, regulación de inteligencia artificial y marcos normativos digitales en América Latina. Un incidente de encallamiento marítimo —sin ángulo de datos, privacidad ni regulación tecnológica— queda fuera del alcance editorial del medio. La coincidencia de nombres entre “Data Portuaria” y las siglas DAMA (Data Management Association) generó una indexación errónea en el feed de Google News monitoreado.

    Acción correctiva: filtro de fuentes en el pipeline de ingestión

    Este caso ilustra un problema concreto de calidad en pipelines de monitoreo de medios: la coincidencia semántica superficial entre términos —”Data Portuaria” vs. DAMA International— puede contaminar feeds de inteligencia editorial si no existen filtros de relevancia temática en la etapa de ingestión. Los equipos que utilizan Google News RSS o herramientas similares para monitoreo de regulación y gobernanza de datos deben implementar al menos un nivel de clasificación por entidad y categoría temática antes de escalar contenido a revisión humana.

    La nota no se publica; el feed de monitoreo será ajustado para excluir coincidencias por nombre de fuente sin validación temática.

  • CRASA debatió gobernanza de datos e IA en su comité de política regional

    CRASA debatió gobernanza de datos e IA en su comité de política regional

    El Comité Legal y de Política de CRASA —la asociación de reguladores de telecomunicaciones del sur y este de África— abrió formalmente una sesión de trabajo dedicada a inteligencia artificial, gobernanza de datos y regulación regional de las TIC. El encuentro señala un punto de inflexión: los reguladores de una de las regiones con mayor crecimiento de infraestructura digital del mundo reconocen que sus marcos normativos no están diseñados para los ecosistemas de datos actuales. Para América Latina, que enfrenta el mismo desfasaje entre velocidad tecnológica y capacidad regulatoria, el movimiento africano ofrece una referencia metodológica concreta.

    CRASA y los 16 reguladores que coordinan el sur de África

    CRASA (Communications Regulators’ Association of Southern Africa) agrupa a las autoridades regulatorias de telecomunicaciones de 16 países del sur y este del continente africano. Su Comité Legal y de Política actúa como espacio de armonización normativa: cuando ese comité abre una sesión específica sobre IA y gobernanza de datos, no está explorando tendencias académicas sino evaluando si los instrumentos regulatorios existentes —licencias, obligaciones de reporte, regímenes de acceso a infraestructura— son suficientes para gobernar flujos de datos transfronterizos, sistemas automatizados de decisión y modelos de IA desplegados por operadores con presencia regional. Según se informó, la agenda incluyó el análisis del estado de avance de los marcos nacionales frente a los requerimientos de la economía digital.

    Por qué un comité de telcos discute gobernanza de datos en 2025

    La convergencia entre regulación de telecomunicaciones y gobernanza de datos no es una anomalía: es la consecuencia lógica de que los operadores de redes son, simultáneamente, los mayores recolectores de datos de comportamiento, geolocalización y comunicaciones de sus países. Cuando un regulador TIC fija condiciones para una licencia de operación, está —aunque no lo nombre explícitamente— estableciendo quién tiene acceso a qué datos, bajo qué condiciones y con qué obligaciones de retención. El Comité de CRASA está haciendo explícito algo que en muchas jurisdicciones permanece implícito: la regulación de infraestructura digital es, en el fondo, una forma de gobernanza de datos.

    Desde la perspectiva del DAMA-DMBOK, esto equivale a reconocer que el “data ownership” no puede resolverse solo dentro de las organizaciones —requiere un marco externo que defina derechos, responsabilidades y mecanismos de control a nivel sectorial y regional. Los reguladores africanos están intentando construir ese marco colectivamente, algo que en América Latina todavía se hace de manera fragmentada y fundamentalmente reactiva.

    Brasil, México y Colombia: tres velocidades en el mismo problema

    América Latina no parte de cero. Brasil cuenta con la Lei Geral de Proteção de Dados (LGPD, Lei nº 13.709/2018) y con la ANPD como autoridad de aplicación, que en 2024 emitió regulaciones sobre agentes de tratamiento y bases legales. Sin embargo, la ANPD no tiene mandato explícito sobre gobernanza corporativa de datos más allá de lo que impone la LGPD: no puede exigir que una empresa implemente un catálogo de datos, defina data stewards o mantenga linaje documentado, a menos que esa ausencia derive en una violación de los principios de seguridad o minimización de la ley.

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010) y el INAI como regulador, con un marco centrado en derechos ARCO que tiene escasa incidencia en cómo las empresas organizan internamente sus arquitecturas de datos. Colombia, por su parte, cuenta con la Ley 1581 de 2012 y la Superintendencia de Industria y Comercio (SIC), que ha avanzado en orientaciones sobre transferencias internacionales, pero aún no emitió guías técnicas sobre gestión del ciclo de vida del dato equivalentes a las que se esperan de un marco CDMC. El resultado es que las tres jurisdicciones más grandes de la región tienen marcos de privacidad razonablemente maduros pero marcos de gobernanza de datos corporativa virtualmente inexistentes desde el ángulo regulatorio.

    Lo que los CDOs de la región pueden tomar del modelo CRASA

    El valor del enfoque de CRASA no está en sus resoluciones —que todavía no se conocen públicamente— sino en su método: un comité sectorial que evalúa sistemáticamente si los instrumentos regulatorios existentes son adecuados para los activos de datos que los operadores manejan. Ese ejercicio de mapeo —”¿tenemos cobertura normativa para este tipo de dato, este tipo de sistema, este tipo de flujo transfronterizo?”— es exactamente lo que los marcos de gobernanza maduros como DCAM (Data Capability Assessment Model del EDM Council) proponen hacer a nivel organizacional.

    Un CDO en Argentina, Brasil o Colombia puede tomar ese modelo y aplicarlo internamente: mapear las capacidades de gobernanza existentes contra los requerimientos que la regulación sectorial ya impone —comunicaciones al BCRA bajo la Comunicación A 8073 para bancos argentinos, reportes de incidentes a la ANPD bajo el artículo 48 de la LGPD, o notificaciones a la SIC en Colombia— e identificar las brechas reales. Ese mapeo es el punto de partida para un roadmap de gobernanza que no sea aspiracional sino jurisdiccionalmente anclado. La semana que viene es una buena fecha para abrir ese inventario: quién es el data steward de cada dominio regulado, qué linaje está documentado, qué no.

    Qué monitorear: la agenda regulatoria TIC en LATAM durante el segundo semestre de 2025

    El movimiento de CRASA coincide con una ventana activa en la región. En Chile, la Ley 21.719 de Protección de Datos Personales —promulgada en diciembre de 2024 y con entrada en vigor escalonada— incluye obligaciones de seguridad y gobernanza que van más allá de los marcos anteriores. En Perú, la Ley 29733 está bajo revisión legislativa. En Brasil, la ANPD tiene en su agenda la regulación de decisiones automatizadas. Ninguno de estos procesos cuenta aún con un comité equivalente al de CRASA —un espacio de armonización técnica entre reguladores— lo que hace que el intercambio de experiencias entre países siga dependiendo de foros informales o de la intermediación de organismos como la CEPAL o la OEA.

    Nuestro análisis

    La sesión de CRASA importa menos por lo que resuelva que por lo que institucionaliza: la gobernanza de datos como agenda regulatoria sectorial, no solo como obligación de privacidad individual. Esa distinción es crucial. Mientras los marcos latinoamericanos siguen atando gobernanza de datos a derechos de titulares —un enfoque necesario pero insuficiente—, otros bloques regionales están construyendo la capa de gobernanza corporativa e interoperabilidad que permite que esos derechos sean ejercibles en la práctica. Una empresa que no sabe qué datos tiene, dónde están y quién es responsible de cada dominio no puede responder un DSAR en 30 días ni notificar una brecha en 72 horas. El orden lógico es: gobernanza primero, cumplimiento como resultado. Eso es lo que CRASA, al menos en el papel, está intentando formalizar.

    La pregunta concreta para los equipos de datos en la región: ¿puede su organización responder hoy, sin buscar en carpetas, quién es el data steward de cada sistema que toca datos regulados? Si la respuesta es no, ese es el primer gap que documentar.

  • Meta censura salud reproductiva: EFF presenta caso ante la Junta de Supervisión

    Meta censura salud reproductiva: EFF presenta caso ante la Junta de Supervisión

    La Electronic Frontier Foundation presentó un comentario público ante la Junta de Supervisión de Meta documentando un patrón sistemático: las plataformas del grupo —Instagram en particular— eliminan contenido legítimo sobre salud reproductiva al confundirlo con tráfico de medicamentos. El caso en análisis involucra una publicación de Instagram sobre medicamentos de prescripción durante el embarazo y el parto.

    El problema no es anecdótico. A través del proyecto Stop Censoring Abortion, la EFF recopiló cerca de cien testimonios de proveedores de salud, clínicas, educadores, investigadores y advocates cuyo contenido había sido eliminado o suprimido por plataformas de redes sociales. El denominador común: en casi todos los casos documentados, las publicaciones censuradas no violaban las reglas declaradas de las plataformas.

    La política de bienes restringidos de Meta y su aplicación sobre contenido médico legítimo

    Meta invoca con frecuencia su Política de Bienes y Servicios Restringidos, que prohíbe intentos de comprar, vender, intercambiar, donar o solicitar medicamentos farmacéuticos. El problema es que el sistema de moderación no distingue entre esa conducta prohibida y la discusión factual o educativa sobre esos mismos medicamentos. Según la documentación de la EFF, el contenido eliminado consistía abrumadoramente en información clínica, experiencias personales con la atención médica y datos para acceder a servicios legales, no en ofertas comerciales de fármacos.

    Los efectos concretos fueron significativos. La Miscarriage+Abortion Hotline tuvo su cuenta de Instagram restringida y publicaciones eliminadas a pesar de que su actividad se limitaba a informar sobre cómo obtener medicación de manera legal. Red River Women’s Clinic y el centro de investigación RISE de la Universidad de Emory enfrentaron situaciones similares. Se documentaron además bajas repentinas de cuentas, desranqueo de perfiles sin notificación y procesos de apelación que, según la EFF, rara vez llegaban a una resolución concreta.

    Cuándo aplica la restricción y cuándo no: el límite que los sistemas automáticos no logran trazar

    La política de Meta aplica —al menos en su formulación textual— a transacciones comerciales de medicamentos no autorizadas. No aplica, en principio, a la información médica de acceso público, a la educación sanitaria ni a los testimonios personales sobre experiencias de salud. El fallo documentado por la EFF ocurre en la capa de detección: los sistemas automáticos identifican palabras clave o patrones asociados a fármacos específicos sin evaluar el contexto de la publicación. El resultado es lo que la EFF denomina sobre-aplicación sistémica: el contenido con más probabilidad de ser eliminado es, paradójicamente, el que proviene de actores institucionales con perfiles verificables y contenido clínicamente preciso.

    Este tipo de sobre-moderación no es un error técnico menor. Cuando una clínica pierde su cuenta de Instagram sin posibilidad real de apelar, se interrumpe un canal de acceso a información que para muchas personas —especialmente en contextos de baja escolaridad o zonas rurales— puede ser el único disponible. La EFF sostiene que la Junta de Supervisión de Meta tiene ante sí la oportunidad de establecer un estándar claro: hablar sobre medicamentos no equivale a venderlos.

    El régimen de moderación de contenido y los derechos digitales en América Latina

    En América Latina, la tensión entre moderación de contenido y libertad de expresión en salud reproductiva adquiere dimensiones adicionales. Varios países de la región —entre ellos Argentina, Ecuador, Honduras y El Salvador— tienen marcos legales restrictivos sobre el aborto, lo que genera incentivos para que los sistemas de moderación sean aún más agresivos con contenido relacionado. En México, donde la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) regula el tratamiento de datos de salud como categoría sensible, la eliminación arbitraria de cuentas de salud también plantea interrogantes sobre el tratamiento que las plataformas dan a la información que recopilan antes de eliminar el contenido. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) ha comenzado a observar con mayor atención las prácticas de las plataformas sobre datos sensibles, categoría que bajo la Lei Geral de Proteção de Dados (LGPD) incluye explícitamente datos sobre salud. La sobre-moderación, en este marco, no es solo un problema de libertad de expresión: puede implicar tratamiento indebido de datos personales sensibles.

    La Junta de Supervisión de Meta es un mecanismo de rendición de cuentas de alcance global. Sus decisiones se aplican a todas las plataformas del grupo en todos los países donde operan. Eso significa que un fallo que establezca criterios más precisos para distinguir información médica legítima de transacciones comerciales prohibidas tendría efecto directo sobre millones de usuarios latinoamericanos.

    El comentario completo de la EFF ante la Junta de Supervisión de Meta, así como los testimonios recopilados a través del proyecto Stop Censoring Abortion, están disponibles en eff.org/pages/stop-censoring-abortion. La decisión de la Junta sobre el caso de medicamentos durante el embarazo aún está pendiente.

  • CISA advierte sobre Gunra Ransomware: doble extorsión contra infraestructura crítica

    CISA advierte sobre Gunra Ransomware: doble extorsión contra infraestructura crítica

    La Agencia de Ciberseguridad e Infraestructura de Estados Unidos (CISA) emitió el 10 de agosto de 2026 una alerta formal sobre Gunra, un ransomware-as-a-service (RaaS) activo desde 2025 que opera bajo un esquema de doble extorsión: cifra los datos de sus víctimas y amenaza con publicarlos en un sitio de filtraciones dedicado si no se paga el rescate. Los sectores afectados incluyen gobierno, infraestructura crítica y otras organizaciones.

    Gunra surgió como variante independiente en 2025 y escaló a modelo RaaS a lo largo de 2026, lo que significa que sus operadores reclutan afiliados externos que ejecutan los ataques a cambio de una porción del rescate cobrado. Este modelo reduce la barrera técnica de entrada para actores maliciosos y amplía significativamente la superficie de ataque. La alerta de CISA fue publicada bajo el programa #StopRansomware, que sistematiza avisos técnicos sobre amenazas activas para facilitar la respuesta de organizaciones públicas y privadas.

    Doble extorsión: cifrado más exfiltración confirmada

    El vector que distingue a Gunra es la combinación de cifrado de datos con exfiltración previa y amenaza de publicación. Los afiliados no solo inutilizan los sistemas de la víctima: antes de activar el cifrado, extraen información sensible y la alojan en un dedicated leak site (DLS) propio. Esto convierte cada ataque en un incidente de privacidad potencial, independientemente de si la organización logra restaurar sus sistemas desde respaldos. Según se informó en la alerta de CISA, los objetivos prioritarios son entidades gubernamentales e infraestructura crítica, categorías que en América Latina incluyen organismos de salud pública, energía, agua y sistemas financieros regulados.

    Datos confirmados

    • Gunra apareció por primera vez como variante de ransomware en 2025.
    • La expansión a modelo RaaS se confirmó en 2026.
    • Opera con doble extorsión: cifrado + publicación de datos exfiltrados en DLS propio.
    • Sectores objetivo declarados: gobierno, infraestructura crítica y otras organizaciones.
    • La alerta fue emitida por CISA el 10 de agosto de 2026 bajo el programa #StopRansomware.

    La alerta de CISA no detalla el número de víctimas confirmadas ni especifica países afectados fuera de Estados Unidos. Tampoco se informó el monto promedio de rescate exigido ni los vectores de acceso inicial utilizados por los afiliados. Estos datos permanecen sin confirmar al cierre de esta nota.

    Para las organizaciones en América Latina, el esquema RaaS de Gunra tiene implicancias directas en materia de notificación de brechas. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a notificar a la Autoridade Nacional de Proteção de Dados (ANPD) en un plazo razonable cuando hay exfiltración de datos personales. En Argentina, la Ley 25.326 y las disposiciones complementarias de la AAIP establecen la obligación de reportar incidentes de seguridad. En México, el INAI exige notificación bajo la LFPDPPP cuando datos personales bajo custodia de responsables privados son comprometidos. En todos estos casos, el modelo de doble extorsión activa automáticamente las obligaciones de reporte, incluso si la organización decide no pagar el rescate: la exfiltración ya ocurrió.

    Las organizaciones en la región con infraestructura crítica o datos gubernamentales bajo custodia deben verificar hoy si sus planes de respuesta a incidentes incluyen protocolos de notificación a autoridades de protección de datos ante exfiltración confirmada, no solo ante cifrado.