DataTrends LATAM

Categoría: Privacidad

  • NHS admite brecha de datos: enviaba información de trasplantes por pagers sin cifrar

    NHS admite brecha de datos: enviaba información de trasplantes por pagers sin cifrar

    El Servicio Nacional de Salud del Reino Unido (NHS) reconoció una brecha de datos tras confirmarse que enviaba información médica sensible de pacientes en lista de trasplante a través de una red de pagers sin cifrado. El hallazgo, producto de una investigación de la BBC, expuso nombres, fechas de nacimiento y tipos de órganos ofrecidos o necesitados circulando en texto plano.

    Según se informó, los datos se transmitían de forma rutinaria mediante dispositivos pager —tecnología de radiofrecuencia de los años ochenta— cuya señal puede interceptarse con equipos de bajo costo disponibles en el mercado. La investigación periodística detectó que el sistema afectaba específicamente a pacientes del programa de trasplantes, uno de los perfiles clínicos de mayor sensibilidad, dado que los datos expuestos incluyen información de salud que en la mayoría de los marcos regulatorios modernos recibe protección reforzada.

    Datos confirmados al 14 de agosto de 2026

    • El NHS reconoció públicamente la existencia de la brecha tras la publicación de la investigación de la BBC.
    • Los datos transmitidos incluían: nombre completo del paciente, fecha de nacimiento y tipo de órgano involucrado (ofrecido o requerido).
    • La red de pagers utilizada no contaba con cifrado en la transmisión de datos.
    • El uso de pagers para comunicaciones clínicas era, según se informó, una práctica rutinaria y no un evento aislado.
    • No se ha confirmado públicamente si hubo acceso no autorizado efectivo a los datos interceptados.

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

    Lo confirmado hasta ahora es que el NHS reconoció el incidente y que la práctica era sistemática, no accidental. Lo que permanece sin verificar es el número total de pacientes afectados, el período durante el cual se realizaron estas transmisiones y si la Oficina del Comisionado de Información del Reino Unido (ICO) —autoridad de control bajo el UK GDPR— ya recibió la notificación formal de la brecha. Bajo el régimen de protección de datos vigente en el Reino Unido, las organizaciones tienen 72 horas para notificar a la autoridad cuando el riesgo para los titulares es probable. Tampoco se ha informado si el NHS activó algún protocolo de notificación individual hacia los pacientes afectados.

    El incidente tiene repercusión directa para la región. En Argentina, la Ley 25.326 de Protección de los Datos Personales clasifica los datos de salud como datos sensibles y exige medidas de seguridad adecuadas para su tratamiento; la AAIP puede ordenar el cese del tratamiento y aplicar sanciones ante incumplimientos. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece la misma categoría de dato sensible para información de salud y fija la obligación de notificación a la ANPD en plazos que la propia autoridad ha ido precisando mediante resoluciones. En México, la LFPDPPP y su reglamento obligan a los responsables a implementar medidas de seguridad físicas, técnicas y administrativas; el uso de canales no cifrados para datos de salud difícilmente superaría un escrutinio del INAI. El caso NHS es, en ese sentido, un espejo incómodo: los sistemas de salud pública de la región también operan con infraestructura heredada que no fue diseñada con privacidad en mente.

    El próximo hito a seguir es la confirmación de si la ICO recibió la notificación formal dentro del plazo de 72 horas exigido por el UK GDPR y si iniciará una investigación sobre el alcance total del incidente.

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

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

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

  • Brecha en proveedor logístico de Bol expone datos de clientes en la dark web

    Brecha en proveedor logístico de Bol expone datos de clientes en la dark web

    El retailer neerlandés Bol notificó a sus clientes que información personal pudo haber sido vista o copiada por terceros no autorizados que accedieron a los sistemas de uno de sus socios logísticos. Los datos comprometidos ya aparecieron publicados en la dark web, según se informó, convirtiendo el incidente en el segundo caso resonante en el comercio minorista holandés en pocas semanas, tras el aviso similar emitido por la cadena de lujo De Bijenkorf.

    Un ataque al proveedor, un problema del retailer

    Bol fue enfático en aclarar que sus propios sistemas no fueron vulnerados. Sin embargo, esa distinción tiene un peso limitado para los consumidores afectados: los datos son igualmente suyos, independientemente de en qué servidor estuvieran almacenados. Este es el patrón clásico del ataque a la cadena de suministro digital — el actor principal no es el blanco directo, pero termina siendo el rostro de la crisis ante sus usuarios. La empresa emitió un comunicado advirtiendo que “alguna información de clientes pudo haber sido visualizada o copiada”, sin detallar el volumen exacto de registros expuestos ni la naturaleza precisa de los datos involucrados.

    La coincidencia temporal con el caso De Bijenkorf no es anecdótica. Sugiere que uno o más actores maliciosos están apuntando sistemáticamente a operadores logísticos que prestan servicios a múltiples retailers, maximizando el impacto de un único punto de compromiso. Este vector — conocido en la industria como third-party breach — es precisamente el que los marcos regulatorios modernos buscan cubrir con obligaciones de due diligence sobre proveedores.

    El GDPR y la notificación: el reloj ya corre

    Bajo el Reglamento General de Protección de Datos (GDPR), tanto el responsable del tratamiento como el encargado tienen obligaciones claras ante una brecha de seguridad. El responsable — en este caso Bol, dado que es quien tiene la relación contractual con el cliente final — debe notificar a la autoridad competente, la Autoriteit Persoonsgegevens (AP) de los Países Bajos, dentro de las 72 horas de haber tomado conocimiento del incidente. Si los datos expuestos representan un riesgo alto para los derechos de los individuos, también corresponde la notificación directa a los afectados. La aparición de los datos en la dark web eleva considerablemente ese nivel de riesgo.

    El caso tiene lectura directa para América Latina. En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece en su artículo 48 la obligación de notificar a la Autoridade Nacional de Proteção de Dados (ANPD) y a los titulares afectados en “prazo razoável”, cuya interpretación la ANPD ha ido precisando en resoluciones sucesivas. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) contempla la notificación de brechas en su normativa, aunque el proyecto de reforma de la Ley 25.326 busca alinear plazos y obligaciones más explícitamente con el estándar europeo. En México, la LFPDPPP no establece un plazo específico de notificación, una laguna que el sector señala como pendiente de resolver.

    La responsabilidad no termina en el firewall propio

    Lo que el incidente de Bol pone sobre la mesa es una pregunta que todo responsable de privacidad en e-commerce y retail debería estar respondiendo ahora mismo: ¿qué nivel de acceso a datos de clientes tienen los proveedores logísticos, y bajo qué controles? Los contratos de tratamiento de datos (Data Processing Agreements o DPA, en la nomenclatura del GDPR) deben especificar medidas técnicas y organizativas mínimas, y su cumplimiento no puede auditarse una sola vez al año. En la región, muchas empresas de retail transfieren datos de envío — nombre, dirección, teléfono, en algunos casos correo electrónico e historial de compras — a operadores logísticos sin cláusulas contractuales que contemplen escenarios de brecha y responsabilidades de notificación.

    “La cadena de responsabilidad sobre los datos personales no termina donde termina el sistema propio. Termina donde termina el dato.”

    — Principio rector del enfoque de responsabilidad proactiva bajo GDPR y LGPD

    Qué mirar en las próximas horas

    Quedan abiertas varias variables que determinarán la gravedad final del caso: el tipo de datos expuestos (si incluyen información financiera o de autenticación, el riesgo escala significativamente), el número de registros publicados en la dark web, y la respuesta formal de la Autoriteit Persoonsgegevens. También será relevante saber si el mismo operador logístico prestaba servicios a De Bijenkorf, lo que confirmaría o descartaría la hipótesis de un ataque coordinado contra un proveedor compartido. Los clientes de Bol, mientras tanto, deberían estar atentos a correos de phishing que utilicen sus datos para parecer legítimos — una táctica habitual una vez que la información personal circula en foros clandestinos.

    En retail, el dato del cliente viaja con el paquete — y la responsabilidad legal, también.

  • SDKs publicitarios filtran ubicación sin consentimiento: lo que reveló la EFF

    SDKs publicitarios filtran ubicación sin consentimiento: lo que reveló la EFF

    Un informe de la Electronic Frontier Foundation (EFF) reveló que varios kits de desarrollo de software (SDKs) publicitarios comparten por defecto la ubicación de los usuarios con brokers de datos, sin su conocimiento ni consentimiento real. Entre los señalados figuran InMobi, BidMachine, HyBid de Verve y Petal Ads de Huawei. El hallazgo expone una cadena de transferencia de datos personales que opera de manera silenciosa dentro de millones de aplicaciones móviles.

    Los SDKs publicitarios son paquetes de código que los desarrolladores integran en sus apps para monetizarlas mediante publicidad. Su uso es masivo: prácticamente cualquier aplicación gratuita los incorpora. El problema, según documentó la EFF tras revisar la documentación pública de decenas de estos kits, es que varios de ellos activan por defecto la recolección y transmisión de la ubicación precisa del usuario en el momento en que la app recibe permiso de geolocalización, independientemente del propósito original para el que ese permiso fue otorgado.

    El mecanismo: consentimiento aparente, transferencia real

    El núcleo del problema no es técnico sino de diseño deliberado. Cuando un usuario autoriza a una app de delivery o navegación a acceder a su ubicación, no necesariamente entiende que esa misma señal puede activar un SDK publicitario que la reenvía a sistemas de rastreo de terceros. La investigadora Lena Cohen, tecnóloga de la EFF, lo describió con precisión:

    “Los valores predeterminados importan, no solo para los usuarios sino también para los desarrolladores. Si los desarrolladores no prestan atención a la configuración de compartición de ubicación de sus herramientas publicitarias, podrían exponer inadvertidamente la información de ubicación de los usuarios.”

    — Lena Cohen, tecnóloga senior, Electronic Frontier Foundation

    La investigación también señala que los SDKs utilizan incentivos económicos para estimular a los desarrolladores a habilitar la geolocalización: a mayor precisión de datos compartidos, mayores ingresos por publicidad. Esto crea una presión estructural para que la privacidad ceda frente a la monetización, incluso cuando los desarrolladores no tienen una intención explícita de vulnerar datos de sus usuarios.

    Qué implica esto para LATAM

    América Latina concentra algunos de los mercados de apps más activos del mundo. Brasil, México y Argentina figuran entre los diez países con mayor descarga de aplicaciones móviles a nivel global, según datos de la industria. Eso significa que millones de usuarios de la región están potencialmente expuestos a este mecanismo de fuga de datos, muchos de ellos sin ninguna protección legal efectiva activada en su favor.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece que el tratamiento de datos de geolocalización requiere base legal explícita y, en muchos casos, consentimiento específico. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió orientaciones sobre el principio de finalidad: los datos recabados para un propósito no pueden reutilizarse para otro sin nueva base legal. Un SDK que redirige datos de ubicación a brokers publicitarios sin que el usuario lo sepa difícilmente cumple ese estándar. En Argentina, la Ley 25.326 y las directrices de la AAIP apuntan en la misma dirección: el consentimiento debe ser informado, libre y específico para cada finalidad.

    México no es la excepción. La LFPDPPP obliga a los responsables del tratamiento a informar de manera clara con qué terceros se compartirán los datos y para qué fines. Si un desarrollador integra un SDK sin auditar su comportamiento en materia de geolocalización, puede estar transfiriendo datos a terceros sin haberlo declarado en su aviso de privacidad, lo que configura una infracción directa.

    El desarrollador también es responsable

    Un punto que la EFF subraya y que suele pasarse por alto en los debates regulatorios es la responsabilidad del desarrollador frente a las prácticas del SDK que incorpora. Integrar una librería de terceros no exime al responsable de la app de las obligaciones sobre los datos que fluyen a través de ella. En términos del RGPD europeo —referencia técnica para varias normativas latinoamericanas— el desarrollador actúa como responsable del tratamiento y el SDK como encargado; esa relación debe estar contractualmente documentada y el encargado debe operar bajo instrucciones del responsable, no al revés.

    La documentación poco clara o deliberadamente opaca de algunos SDKs, otro hallazgo de la EFF, agrava este problema: si el desarrollador no puede entender cómo configura la transmisión de datos la herramienta que usa, tampoco puede cumplir con sus obligaciones de información al usuario. El informe recomienda que los desarrolladores auditen activamente los SDKs que integran, desactiven el intercambio de ubicación cuando no sea estrictamente necesario, y exijan documentación clara a los proveedores.

    Reguladores bajo presión

    El informe de la EFF llega en un momento en que la regulación del mercado de brokers de datos de ubicación está ganando atención global. En Estados Unidos, la FTC ya tomó acciones contra empresas del sector. En LATAM, los marcos legales existen pero la supervisión activa del ecosistema de SDKs publicitarios sigue siendo prácticamente inexistente. Ninguna autoridad de protección de datos de la región ha publicado hasta la fecha guías específicas sobre las obligaciones de los desarrolladores respecto a las librerías de terceros que integran en sus aplicaciones.

    Mientras los reguladores latinoamericanos no pongan la lupa sobre el ecosistema de SDKs publicitarios, los marcos legales de privacidad de la región seguirán teniendo un punto ciego del tamaño de la economía de datos de ubicación.

  • Filtración masiva en Corea: USD 3,50 de compensación por persona enciende el debate

    Filtración masiva en Corea: USD 3,50 de compensación por persona enciende el debate

    La Corporación de Instalaciones de Seúl enfrenta una tormenta política tras ofrecer 5.000 wones —equivalentes a unos 3,50 dólares— como compensación a cada una de las 4,62 millones de personas afectadas por una brecha de datos personales. La cifra, considerada irrisoria por legisladores surcoreanos, reabre el debate global sobre cómo valuar el daño real que sufren los individuos cuando sus datos son comprometidos.

    El concejal Im Gyu-ho, del Partido Democrático de Corea, fue uno de los primeros en cuestionar públicamente la propuesta ante el Consejo Metropolitano de Seúl. Según se informó, el funcionario señaló que el monto no refleja ni el alcance del incidente ni la naturaleza de los datos expuestos, y exigió una revisión del esquema indemnizatorio. La cifra total que desembolsaría la corporación rondaría los 23 millones de dólares, pero distribuida entre millones de personas, el impacto individual resulta casi simbólico.

    El problema de fondo: ¿cuánto vale un dato personal?

    La controversia surcoreana no es un caso aislado: es la versión más reciente de un debate que ningún sistema regulatorio ha resuelto del todo. Establecer un valor monetario al daño derivado de una brecha de datos personales implica considerar factores heterogéneos —riesgo de fraude, estrés, pérdida de control sobre la propia identidad digital— que los marcos legales traducen en criterios distintos según la jurisdicción. En Europa, el RGPD habilita indemnizaciones por “daño moral” sin tope mínimo definido, lo que ha derivado en sentencias que van desde unos pocos euros hasta compensaciones de cuatro cifras por persona en casos de exposición de datos sensibles.

    En América Latina, el panorama es fragmentado. En Argentina, la Ley 25.326 de Protección de Datos Personales prevé acciones de daños y perjuicios, pero la práctica judicial aún no ha consolidado estándares claros de cuantificación por brecha masiva. En Brasil, la Lei Geral de Proteção de Dados (LGPD) contempla la responsabilidad civil del controlador y habilita a la Autoridade Nacional de Proteção de Dados (ANPD) a sancionar, aunque las primeras resoluciones sancionatorias recién están sentando precedente. México, a través del INAI y la LFPDPPP, también carece de una doctrina consolidada sobre montos compensatorios individuales en incidentes de escala masiva.

    Sanciones que no duelen: el riesgo del “precio del dato”

    Cuando la compensación por persona se fija en cifras que no generan incentivos reales para prevenir incidentes, el sistema regulatorio pierde efectividad disuasoria. Este es, precisamente, el argumento que subyace a la crítica del legislador Im Gyu-ho: si una entidad pública puede procesar de forma insegura los datos de 4,62 millones de ciudadanos y saldar la cuenta con 3,50 dólares por cabeza, el costo del incumplimiento es inferior al costo de invertir en controles preventivos. Esa lógica —el “precio del dato”— es exactamente lo que marcos como el RGPD intentaron romper con multas de hasta el 4% de la facturación global anual.

    “La compensación no refleja el alcance del incidente ni la naturaleza de los datos expuestos. Debe revisarse el esquema indemnizatorio.”

    — Im Gyu-ho, concejal del Partido Democrático de Corea, Consejo Metropolitano de Seúl

    Implicancias para la región

    El caso de Seúl ofrece una referencia concreta para los debates legislativos que se desarrollan en la región. En Colombia, la Ley Estatutaria 1581 y su regulación complementaria están siendo revisadas en el marco de una posible reforma. En Chile, la nueva Ley Marco de Ciberseguridad y la Ley de Protección de Datos Personales recientemente promulgada incorporan criterios de proporcionalidad en las sanciones. En todos estos contextos, la pregunta de fondo es la misma: ¿las multas y compensaciones previstas son suficientes para modificar el comportamiento de las organizaciones que procesan datos masivamente, o seguirán siendo un costo tolerable de operación?

    La discusión también interpela a entidades públicas, que en muchos países latinoamericanos quedan fuera o en zonas grises de los regímenes de responsabilidad por datos personales. Si los organismos estatales no están sujetos a los mismos estándares sancionatorios que el sector privado, el incentivo para invertir en seguridad y gobernanza de datos se debilita aún más. La Corporación de Instalaciones de Seúl —una entidad pública metropolitana— ilustra exactamente ese riesgo.

    Cuando la compensación por una brecha masiva cuesta menos que una taza de café por persona, no es un problema de matemáticas: es un problema de diseño regulatorio.

  • SDKs publicitarios exponen la ubicación de usuarios sin que los desarrolladores lo sepan

    SDKs publicitarios exponen la ubicación de usuarios sin que los desarrolladores lo sepan

    Una investigación de la Electronic Frontier Foundation (EFF) identificó que varios kits de desarrollo de software (SDKs) publicitarios para Android comparten la ubicación de los usuarios por defecto, muchas veces sin que los propios desarrolladores de aplicaciones lo noten. El dato preocupa especialmente en América Latina, donde los marcos de protección de datos personales exigen consentimiento explícito para el tratamiento de datos de geolocalización.

    El mecanismo es técnicamente sencillo pero con consecuencias de largo alcance: cuando un desarrollador integra un SDK publicitario en su aplicación y el usuario le otorga permisos de ubicación —por ejemplo, para mostrar contenido relevante según la ciudad—, ese SDK puede reenviar automáticamente las coordenadas a redes de publicidad programática y, desde allí, a brokers de datos de localización. La configuración por defecto, según la EFF, es la que habilita esta transferencia sin ninguna acción adicional del desarrollador.

    Más que publicidad dirigida: usos de alto riesgo

    La investigación documenta que los datos de geolocalización captados a través de sistemas publicitarios han sido utilizados para fines que van mucho más allá del marketing. Entre los casos citados figuran investigaciones migratorias de agencias como ICE en Estados Unidos, la exposición de la identidad de personas LGBTQ+, el seguimiento de sindicalistas y el rastreo de personal militar. Estos usos ilustran por qué la geolocalización está clasificada como dato sensible en la mayoría de las legislaciones de protección de datos personales vigentes en la región.

    La EFF identificó de manera puntual a SDKs —entre ellos InMobi— que en su documentación pública reconocen recolectar y compartir datos de ubicación por defecto cuando la app tiene los permisos habilitados. El problema no es solo técnico: también es de diseño. Los incentivos financieros del ecosistema publicitario empujan a que la configuración por defecto favorezca la máxima recopilación de datos, y la documentación para desarrolladores suele ser ambigua respecto al alcance real del tratamiento.

    El problema del consentimiento en cadena

    Desde la perspectiva de la privacidad, el nudo central es quién consiente qué y a quién. Cuando un usuario acepta que una app de clima o de transporte acceda a su ubicación, difícilmente imagina que ese dato viajará a una red de intercambio publicitario en tiempo real (RTB, por sus siglas en inglés) y luego a múltiples brokers de datos. Este desfase entre la expectativa del usuario y el flujo real de la información es exactamente lo que las regulaciones de datos personales buscan corregir.

    “Los desarrolladores podrían estar exponiendo inadvertidamente la información de ubicación de sus usuarios si no prestan especial atención a la configuración de sus herramientas publicitarias.”

    — Electronic Frontier Foundation, informe técnico 2026

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece que el tratamiento de datos de geolocalización requiere base legal específica, y que el consentimiento debe ser libre, informado e inequívoco para cada finalidad. La Autoridade Nacional de Proteção de Dados (ANPD) ya ha señalado en sus guías de segurança que el uso de SDKs de terceros no exime al desarrollador de responsabilidad como controlador de datos. En México, la LFPDPPP obliga a los responsables del tratamiento a informar con claridad en el aviso de privacidad sobre las transferencias a terceros, lo que incluye redes publicitarias. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) considera que la geolocalización puede calificar como dato sensible según el contexto, activando las protecciones reforzadas de la Ley 25.326.

    Responsabilidad del desarrollador como controlador

    Un error frecuente en el ecosistema de aplicaciones móviles es asumir que la responsabilidad legal termina donde empieza el SDK. No es así. En la mayoría de los marcos legales de la región, el desarrollador que integra un SDK sigue siendo el responsable del tratamiento frente al usuario. Esto implica que debe conocer qué datos recopila cada componente de terceros, con qué finalidad, con quién los comparte y bajo qué base legal. Las prácticas de privacy by design —incorporar la privacidad como criterio de arquitectura desde el inicio del desarrollo— no son solo una buena práctica: en varias jurisdicciones latinoamericanas son una obligación implícita o explícita.

    La recomendación práctica para equipos de desarrollo pasa por tres acciones concretas: auditar los SDKs publicitarios integrados y revisar su documentación de privacidad con criterio legal, no solo técnico; desactivar explícitamente la recolección de datos de ubicación en los SDKs cuando esa funcionalidad no es esencial para la app; y actualizar los avisos de privacidad para reflejar con precisión los flujos de datos hacia terceros, incluyendo redes de RTB y brokers. En Colombia, la Superintendencia de Industria y Comercio (SIC) ha sancionado a empresas por transferencias de datos no informadas adecuadamente al titular, lo que convierte esta revisión en una necesidad urgente también para apps distribuidas en ese mercado.

    Defaults que deciden por el usuario

    El concepto de “privacidad por defecto” —privacy by default— exige que la configuración inicial de cualquier sistema sea la más protectora posible para el usuario, sin que este tenga que intervenir para lograrlo. Los SDKs publicitarios identificados operan exactamente al revés: la configuración por defecto maximiza la recolección. Este diseño no es un accidente; responde a un modelo de negocio donde la granularidad del dato de ubicación tiene valor monetario directo. Cambiar ese default requiere que el desarrollador intervenga activamente, y eso solo ocurre si conoce el problema.

    En un ecosistema donde la geolocalización ya fue usada para perseguir a migrantes, exponer identidades y rastrear sindicalistas, la pregunta para cada desarrollador que integra un SDK publicitario no es si debería preocuparse, sino si puede permitirse no hacerlo.

  • Rastreadores de fitness: cómo los wearables fallan en proteger tus datos de salud

    Rastreadores de fitness: cómo los wearables fallan en proteger tus datos de salud

    Relojes inteligentes, pulseras de actividad, anillos biométricos. El mercado de dispositivos wearables orientados a la salud no para de crecer, y con él, una pregunta que pocos fabricantes parecen estar dispuestos a responder con transparencia: ¿qué hacen realmente con los datos que recolectan?

    Un ecosistema de datos altamente sensibles

    Los dispositivos de monitoreo físico no registran simplemente cuántos pasos dio su usuario en el día. Acumulan información sobre ritmo cardíaco, patrones de sueño, niveles de oxígeno en sangre, ciclos menstruales y hasta indicadores de estrés. Se trata de datos de salud de alta sensibilidad que, en manos equivocadas —o simplemente mal gestionados—, pueden derivar en discriminación, vigilancia o manipulación comercial.

    Según informó la Electronic Frontier Foundation (EFF) en un análisis reciente, la mayoría de los fabricantes de smartwatches, anillos inteligentes y bandas de actividad carece de informes de transparencia básicos y no implementa controles de privacidad que sí están al alcance de su capacidad técnica. El diagnóstico es claro: pueden hacer mucho más, y no lo hacen.

    Lo que los fabricantes deberían garantizar

    La EFF identificó un conjunto de prácticas que las empresas del sector deberían adoptar de forma estándar pero que hoy brillan por su ausencia en la mayoría de los productos disponibles en el mercado:

    • Minimización de datos: recolectar únicamente la información estrictamente necesaria para la función declarada del dispositivo.
    • Cifrado de extremo a extremo en la transmisión y almacenamiento de datos biométricos.
    • Transparencia sobre terceros: informar claramente si los datos son compartidos con aseguradoras, anunciantes o plataformas de análisis.
    • Derecho de eliminación efectivo: permitir que el usuario borre su historial de forma real e irrevocable, no solo desde la interfaz de la app.
    • Publicación de informes de transparencia que detallen solicitudes gubernamentales y accesos no autorizados.

    El desafío regulatorio en América Latina

    Mientras el debate avanza en Estados Unidos, la región latinoamericana enfrenta sus propios desafíos normativos en torno a los datos biométricos y de salud. En Brasil, la Lei Geral de Proteção de Dados (LGPD) clasifica los datos de salud como categoría sensible y exige consentimiento explícito para su tratamiento, aunque la fiscalización sobre dispositivos de consumo masivo todavía es incipiente. En Argentina, la Ley 25.326 de Protección de Datos Personales —actualmente en proceso de modernización legislativa— también contempla protecciones especiales para datos sensibles, pero fue sancionada en un contexto tecnológico muy anterior al boom wearable.

    México, por su parte, cuenta con la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP), que obliga a los responsables del tratamiento a informar sobre el uso de los datos y a garantizar derechos de acceso, rectificación, cancelación y oposición. Sin embargo, la aplicación práctica sobre empresas tecnológicas extranjeras que operan sus servidores fuera del país continúa siendo un punto débil del sistema.

    En Colombia, la Ley 1581 de 2012 y sus decretos reglamentarios avanzan en una dirección similar, mientras que Chile transita la implementación de su nueva Ley de Protección de Datos Personales, promulgada en 2024, que introduce estándares más cercanos al GDPR europeo.

    El usuario, último eslabón de la cadena

    Más allá del marco legal, existe una responsabilidad individual que muchas veces se subestima. Thorin Klosowski, activista sénior de seguridad y privacidad de la EFF, señaló en una entrevista reciente que los usuarios tienden a asumir que sus datos están protegidos simplemente porque la app tiene un ícono de candado o una política de privacidad extensa. Esa confianza, advirtió, frecuentemente no está respaldada por las prácticas reales de las empresas.

    Algunas recomendaciones básicas para quienes ya utilizan estos dispositivos incluyen revisar qué permisos tiene la aplicación asociada, desactivar la sincronización con plataformas de terceros cuando no sea imprescindible y verificar si el fabricante permite eliminar la cuenta y todos los datos asociados de manera definitiva.

    Una brecha de confianza que el mercado no puede ignorar

    El crecimiento sostenido del mercado wearable en América Latina —impulsado por el aumento en el acceso a smartphones y una mayor conciencia sobre el bienestar personal— convierte este debate en urgente. Las empresas que lleguen primero a ofrecer garantías reales de privacidad no solo cumplirán con la ley: construirán una ventaja competitiva difícil de replicar en un mercado donde la confianza del consumidor empieza a ser un activo tan valioso como el hardware mismo.

  • Bares LGBTQ+ y escáneres de ID: el dilema entre seguridad y privacidad

    Bares LGBTQ+ y escáneres de ID: el dilema entre seguridad y privacidad

    En el barrio Castro de San Francisco, varios bares y clubes nocturnos LGBTQ+ instalaron terminales de verificación de identidad que van mucho más allá de confirmar la edad de sus clientes. El sistema en cuestión, comercializado bajo el nombre PatronScan, escanea documentos de identidad, captura fotografías de los asistentes y, según se informó, comparte esa información con otros establecimientos participantes de la red. La revelación encendió alertas entre activistas de privacidad y especialistas legales, y abrió un debate que excede las fronteras de California.

    Un sistema de seguridad o una base de datos encubierta

    PatronScan no es un producto nuevo. Según documentación periodística publicada ya en 2019, la empresa construyó una red que permite a los bares adheridos marcar a determinados clientes y compartir esa información con otros locales. En la práctica, significa que una persona que fue expulsada de un establecimiento —por cualquier motivo— puede quedar registrada en un sistema al que acceden múltiples negocios, sin que ella lo sepa ni haya prestado consentimiento explícito.

    La empresa sostiene que su uso es legal en California y aclaró, según se informó, que no realiza reconocimiento facial en América del Norte ni ningún tipo de análisis automatizado de imágenes. Sin embargo, la sola recopilación y circulación de datos provenientes de documentos de identidad oficiales plantea interrogantes jurídicos de fondo.

    La tensión con las leyes de privacidad

    California cuenta con una norma específica sobre privacidad de documentos de identidad que, tras una enmienda de 2018, prohíbe a las empresas retener o utilizar información obtenida del escaneo de un documento oficial, salvo en casos acotados: verificación de edad, cumplimiento de una obligación legal o prevención de fraude. La pregunta que queda sin respuesta clara es si construir una base de datos compartida entre locales encaja en alguna de esas excepciones.

    Este tipo de tensión normativa no es exclusiva de Estados Unidos. En América Latina, marcos regulatorios como la Lei Geral de Proteção de Dados (LGPD) de Brasil, la Ley 25.326 de Argentina o la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México establecen principios similares: los datos personales deben recopilarse con una finalidad específica, con consentimiento informado y no pueden cederse a terceros sin base legal suficiente. Un sistema como PatronScan, trasplantado a cualquiera de estos países, enfrentaría cuestionamientos directos bajo esas legislaciones.

    Colombia, por su parte, cuenta con la Ley 1581 de 2012 y su decreto reglamentario, que exigen autorización previa, expresa e informada del titular para el tratamiento de sus datos. Chile avanza en la misma dirección con su nueva Ley 21.719, que refuerza las obligaciones de responsabilidad proactiva para quien trate datos personales.

    El peso simbólico de los espacios LGBTQ+

    Más allá del análisis técnico-legal, hay una dimensión que la Electronic Frontier Foundation (EFF) señaló con precisión: los espacios LGBTQ+ han funcionado históricamente como refugios donde las personas podían reunirse sin ser monitoreadas ni catalogadas. La paradoja es evidente cuando esos mismos espacios se convierten en nodos de recolección de datos.

    En contextos donde la identidad sexual o de género puede ser motivo de discriminación, persecución o violencia —realidad documentada en múltiples países de la región— la existencia de bases de datos que registran quién asistió a qué lugar y con qué frecuencia representa un riesgo que va más allá de la incomodidad. Una filtración, un acceso indebido o una solicitud gubernamental pueden tener consecuencias concretas para personas vulnerables.

    Consentimiento, proporcionalidad y responsabilidad

    El caso PatronScan ilustra un problema estructural del ecosistema de datos: la proliferación de sistemas de recopilación masiva en entornos donde los usuarios tienen escaso poder de negociación. Nadie negocia los términos del escaneo de su cédula en la puerta de un bar.

    Los principios de minimización de datos y proporcionalidad —presentes en prácticamente todas las legislaciones de privacidad modernas— apuntan exactamente a este escenario: si el objetivo es verificar que alguien es mayor de edad, no hay justificación para retener el nombre, el domicilio, la fecha de nacimiento y una fotografía, ni para compartir ese conjunto de datos con terceros.

    La pregunta que deja abierta este caso no es solo regulatoria. Es también cultural: ¿en qué momento normalizamos que entrar a un espacio de ocio nocturno implique ceder datos personales a una red privada de establecimientos? La respuesta, en cualquier latitud, debería incomodarnos.