DataTrends LATAM

Autor: Redacción

  • AI Act: la prórroga de 16 meses que cambia el tablero de datos para LATAM

    AI Act: la prórroga de 16 meses que cambia el tablero de datos para LATAM

    La Unión Europea postergó hasta diciembre de 2027 las obligaciones de alto riesgo del AI Act —las que cubren scoring crediticio, selección de personal, servicios esenciales e infraestructura crítica—, extendiendo en 16 meses un plazo que originalmente vencía en agosto de 2026. Para las empresas latinoamericanas que operan bajo estándares europeos o que exportan servicios a ese mercado, la prórroga no es un alivio: es tiempo que no debe desperdiciarse.

    La decisión del Parlamento Europeo, confirmada en mayo de 2026, desplazó las obligaciones del Anexo III del AI Act. No se trata de un cambio de fondo en las exigencias —los requerimientos de documentación, trazabilidad de datos de entrenamiento, gestión de riesgos y supervisión humana siguen intactos—, sino de una señal de que la industria no estaba lista. Esa misma señal debería resonar con fuerza en los equipos de gobierno de datos de la región.

    Por qué la fecha importa más que el contenido

    El AI Act establece, para los sistemas de IA de alto riesgo, la obligación de demostrar que los datos utilizados para entrenar y validar modelos son representativos, están documentados y son gestionados con controles verificables. En términos de DAMA-DMBOK, eso equivale a tener operativas al menos las áreas de conocimiento de Calidad de Datos, Data Lineage y Gestión de Metadatos. El problema es que muchas organizaciones —europeas y latinoamericanas por igual— todavía no pueden responder con precisión quién es el data steward de un conjunto de entrenamiento, ni dónde se originaron esos registros.

    La prórroga no suspende las obligaciones para sistemas de IA de propósito general (GPAI) ni para los usos prohibidos, que ya están vigentes desde febrero de 2025. Lo que se posterga es precisamente el segmento más sensible para sectores financieros y de recursos humanos: el scoring y el filtrado automatizado de personas. Que esa capa específica haya necesitado más tiempo dice mucho sobre el estado real de madurez en gobierno de datos dentro de la industria de IA.

    El lunes a la mañana: qué hace un CDO con esta información

    La prórroga ofrece una ventana concreta. Un Chief Data Officer que quiera llegar a diciembre de 2027 con algo más que PowerPoints debería estructurar los próximos trimestres alrededor de tres prioridades verificables:

    • Inventario de datasets críticos: identificar qué conjuntos de datos alimentan —o podrían alimentar— modelos de scoring, contratación o asignación de servicios esenciales, con ownership documentado y clasificación de sensibilidad según el marco del EDM Council (CDMC Capability 8: Data Lineage).
    • Auditoría de linaje: mapear el recorrido completo de esos datos desde la fuente hasta el modelo, incluyendo transformaciones intermedias. Herramientas de data catalog con linaje automatizado dejan de ser un “nice to have” para convertirse en evidencia regulatoria.
    • Definición de roles de stewardship para IA: asignar data stewards específicos para los pipelines de entrenamiento y validación, separados de los stewards de reportes operativos. Esta distinción, poco común en la región, será exigible bajo el AI Act.

    En paralelo, conviene revisar los contratos con proveedores de modelos o plataformas de IA: el AI Act asigna responsabilidades al “deployer” —quien despliega el sistema en contexto de alto riesgo—, no solo al fabricante. Eso significa que una empresa en Buenos Aires o Ciudad de México que use un modelo europeo para evaluar crédito puede quedar alcanzada por las obligaciones aunque el modelo lo construya un tercero.

    El paralelo regulatorio en LATAM

    Brasil avanza en su Marco Legal de IA —aprobado en la Câmara dos Deputados en mayo de 2024 y en proceso de sanción definitiva—, que replica en parte la estructura de riesgos del enfoque europeo. La Lei Geral de Proteção de Dados (LGPD) ya exige, en su artículo 20, que los titulares puedan solicitar revisión de decisiones automatizadas significativas. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) emitió la Resolución 159/2024, que establece buenas prácticas para el uso de IA en el sector público con foco en explicabilidad y no discriminación. En México, la LFPDPPP no contempla explícitamente la IA, pero el INAI ha señalado que las decisiones automatizadas entran en el ámbito del derecho de acceso y rectificación. El vector regulatorio es claro: gobierno de datos y accountability algorítmica convergen.

    Lo que el AI Act llama “data governance for high-risk AI” no es distinto, en esencia, de lo que DAMA lleva años describiendo como gobierno corporativo de datos bien implementado: ownership claro, calidad medible, linaje documentado y metadatos útiles. La diferencia es que ahora hay fechas, multas y un regulador con jurisdicción extraterritorial.

    Confianza en los datos como activo regulatorio

    El concepto de “data trust” —confianza en los datos— suele tratarse como un valor abstracto en las presentaciones de estrategia. En un entorno regulado por el AI Act, se vuelve operativo: significa poder demostrar, ante una autoridad competente, que los datos que alimentaron un modelo de alto riesgo son exactos, representativos y fueron tratados con los controles adecuados. No alcanza con tenerlo; hay que poder probarlo.

    “La regulación de IA no crea nuevos problemas de datos: expone los que ya existían y les pone nombre, fecha y consecuencia.”

    — Perspectiva editorial, DataTrends LATAM

    Para los equipos de gobierno de datos en la región, la prórroga del AI Act es la última oportunidad de construir capacidades reales antes de que el reloj regulatorio venza de nuevo —y esta vez sin extensiones.

    Dieciséis meses adicionales no cambian la dirección del viaje: solo determinan si llegás preparado o corriendo.

  • El Senado de EE.UU. debatirá cuatro leyes sobre menores e internet con impacto en LATAM

    El Comité de Comercio del Senado de Estados Unidos votará esta semana cuatro proyectos de ley que buscan regular el acceso de menores a internet: KOSA, la SCREEN Act, la Youth AI Privacy Act y la CHATBOT Act. Según advirtió la Electronic Frontier Foundation (EFF), las normas propuestas no solo no protegen eficazmente a niños y adolescentes, sino que crearían nuevos problemas de privacidad y restricciones de contenido que afectarían a todos los usuarios, incluidos los adultos. El debate anticipa una tendencia regulatoria que ya resuena en América Latina.

    Los cuatro proyectos comparten un eje común: imponer sistemas de verificación de edad en plataformas digitales. La lógica es intuitiva —si los menores no pueden acceder a ciertos espacios sin acreditar su edad, estarían más protegidos de contenidos nocivos— pero la EFF señala que la premisa tiene una trampa técnica difícil de ignorar: verificar la edad implica recolectar más datos de todos los usuarios, no menos. En una carta enviada al comité, la organización argumentó que estas leyes empujan en la dirección contraria a la protección de la privacidad.

    Cuatro leyes, un mismo problema de diseño

    La Kids Online Safety Act (KOSA) obliga a las plataformas a adoptar medidas de seguridad para menores, pero según se informó, en versiones anteriores del texto esas obligaciones podían derivar en supresión de contenido legal. La SCREEN Act extiende requisitos de verificación de edad más allá de sitios para adultos, con implicancias que la EFF calificó como amenaza a la privacidad en sentido amplio. La Youth AI Privacy Act apunta a los sistemas de inteligencia artificial que interactúan con menores, introduciendo restricciones sobre recolección de datos en esos contextos, aunque con disposiciones que —según el análisis de la EFF— generan paradojas en su implementación. La CHATBOT Act, por su parte, busca que los chatbots se identifiquen como no humanos frente a audiencias jóvenes, pero impone un modelo de crianza único que no contempla la diversidad de configuraciones familiares.

    Para la EFF, el problema de fondo no es la intención sino el método: en lugar de avanzar hacia una ley federal de privacidad del consumidor —que protegería a todos los usuarios con independencia de su edad— o hacia una prohibición de la publicidad conductual que financia el ecosistema de vigilancia comercial, el Congreso estaría optando por soluciones que amplían la recolección de datos bajo el paraguas de la protección infantil.

    El modelo de “verificación de edad” ya tiene historia en la región

    La discusión estadounidense no ocurre en el vacío para América Latina. Brasil sancionó en 2023 modificaciones a su Marco Civil da Internet y reforzó en la LGPD (Lei Geral de Proteção de Dados) las restricciones al tratamiento de datos de menores de 18 años, exigiendo consentimiento parental verificable. En Argentina, la Ley 25.326 no contempla explícitamente el entorno digital para menores, una brecha que el proyecto de actualización de la norma —todavía sin aprobación parlamentaria— intenta cubrir. En Colombia, la Superintendencia de Industria y Comercio ha señalado que el tratamiento de datos de niños y adolescentes requiere autorización de sus representantes legales, pero la verificación efectiva de esa condición en plataformas masivas sigue sin solución técnica clara.

    El nudo que enfrenta el Senado de EE.UU. es exactamente el mismo que deberá resolver la región: cualquier mecanismo de verificación de edad que funcione a escala implica construir una infraestructura de identificación de usuarios que, si no está regulada con precisión, se convierte en un sistema de vigilancia generalizada. La discusión sobre quién administra esos datos, por cuánto tiempo y con qué propósitos es inseparable del diseño de estas leyes.

    El fondo del debate: ¿protección o restricción?

    Más allá de los textos específicos, el bloque de legislación impulsado en el Comité de Comercio refleja una tensión que los reguladores latinoamericanos también conocen bien: la presión política para “hacer algo” frente al daño digital a menores suele traducirse en medidas que afectan la arquitectura de privacidad de toda la red. La EFF propone un camino alternativo —privacidad universal, prohibición de rastreo conductual— que tiene menos atractivo mediático pero mayor coherencia técnica y jurídica.

    Los países de la región que están en proceso de actualizar sus marcos de protección de datos —Argentina, Perú, Ecuador— tienen una ventana para incorporar esa lógica desde el diseño normativo, en lugar de replicar el modelo de verificación de edad con sus consecuencias no deseadas. La experiencia europea con el GDPR y su tratamiento diferenciado de datos de menores ofrece referencias, aunque tampoco resuelve completamente el problema de la verificación a escala.

    Lo que se vote esta semana en Washington no vincula a ningún país de la región, pero sí establece un precedente sobre qué tipo de soluciones están dispuestas a aceptar las democracias cuando la protección infantil colisiona con la privacidad de todos.

  • Calidad de datos en Snowflake: hasta dónde llegan las herramientas nativas y qué debe resolver el CDO

    Calidad de datos en Snowflake: hasta dónde llegan las herramientas nativas y qué debe resolver el CDO

    Snowflake incorpora capacidades nativas de calidad de datos que resuelven casos de uso puntuales dentro de su plataforma, pero dejan expuestos los flancos más críticos para equipos de gobierno de datos: la cobertura cruzada entre fuentes, el data lineage end-to-end y la asignación formal de ownership sobre activos distribuidos. Para un CDO que opera en un entorno multicloud o híbrido, conocer exactamente dónde termina Snowflake y dónde empieza el problema de governance es la decisión que define la arquitectura del programa.

    Qué hace bien Snowflake de forma nativa

    La plataforma ofrece funciones integradas para definir métricas de calidad directamente sobre tablas y vistas mediante Data Metric Functions (DMFs), disponibles en el tier Enterprise. Estas permiten medir completitud, unicidad y freshness de forma programática, y programar ejecuciones periódicas sin necesidad de herramientas externas. Adicionalmente, el Data Quality Score de Snowflake consolida esas métricas en un indicador único por objeto, accesible desde Snowsight. Para organizaciones que tienen su data estate concentrado mayoritariamente dentro de Snowflake y cuentan con equipos de ingeniería capaces de escribir y mantener DMFs, esta capa es funcional y de bajo costo operativo.

    El catálogo nativo —Snowflake Horizon— extiende estas capacidades con clasificación automática de datos sensibles, políticas de acceso basadas en etiquetas (tag-based masking) y una vista de linaje a nivel de columna dentro del ecosistema Snowflake. La integración con herramientas de la suite es directa, lo que reduce la fricción de implementación para equipos que trabajan dentro de ese perímetro.

    El límite real: el data estate que vive fuera del perímetro

    El problema aparece en cuanto el data estate trasciende Snowflake, algo que en la práctica ocurre en la mayoría de las organizaciones medianas y grandes de la región. Fuentes on-premises, data lakehouses en AWS S3 o Azure Data Lake, instancias de SAP, Oracle o sistemas legados que alimentan pipelines críticos quedan fuera del alcance de las DMFs y del linaje de Horizon. En esos escenarios, la calidad medida dentro de Snowflake es una foto parcial: no refleja si los datos llegaron correctos desde el origen, ni si la transformación en el pipeline introdujo degradación.

    El DAMA-DMBOK v2 distingue entre calidad de datos como función operativa —medir y corregir— y governance de la calidad como función estratégica —definir estándares, asignar stewards, escalar issues y certificar activos para consumo. Las DMFs de Snowflake cubren la primera dimensión dentro del perímetro de la plataforma. La segunda requiere un programa con procesos, roles y herramientas que operen agnósticamente al stack tecnológico.

    Lo que necesita el CDO para cerrar la brecha

    La brecha de governance que dejan las herramientas nativas de Snowflake se cierra con tres decisiones concretas que un CDO debería tomar antes de extender el uso de la plataforma como hub analítico de la organización. Primero, mapear el data estate completo: identificar qué porcentaje de los datos críticos para el negocio —definidos por impacto regulatorio o por uso en decisiones de alto valor— reside efectivamente en Snowflake y qué porcentaje llega desde fuentes externas. Si ese segundo número supera el 30%, las métricas nativas son insuficientes como programa de calidad. Segundo, definir formalmente a los data stewards responsables de cada dominio de datos, independientemente de la plataforma donde residan. Según el Non-Invasive Data Governance de Bob Seiner, el steward no necesita un mandato formal para actuar, pero sí necesita visibilidad sobre los activos que ya administra informalmente. Las DMFs no asignan ownership: eso es una decisión de programa, no de herramienta. Tercero, evaluar si el catálogo activo cubre el linaje desde el origen hasta el consumo, incluyendo transformaciones fuera de Snowflake.

    El contexto regulatorio LATAM no perdona datos de baja calidad

    En América Latina, la presión regulatoria eleva el costo de una calidad de datos deficiente. Los bancos y fintechs en Brasil están obligados a reportar información de crédito al Banco Central bajo estándares del Sistema de Informações de Crédito (SCR), donde la exactitud y completitud de los datos tiene consecuencias directas en la supervisión prudencial. En Argentina, la Comunicación A 7724 del BCRA exige que las entidades financieras acrediten controles sobre la integridad de los datos utilizados en modelos de riesgo. En México, la CNBV ha alineado sus requerimientos de reportería con estándares de calidad que implican trazabilidad de origen. En todos estos casos, medir calidad solo dentro de Snowflake —sin cubrir el pipeline completo— no alcanza para acreditar cumplimiento ante el regulador.

    Las organizaciones que operan en estos marcos y usan Snowflake como plataforma central de analítica deben asegurarse de que sus programas de data quality incluyan controles en la capa de ingesta, validación en el pipeline de transformación y certificación formal de los activos que alimentan reportería regulatoria. Herramientas de governance de terceros que se integran con Snowflake —y extienden cobertura a otras fuentes— son la respuesta técnica habitual para cerrar esa brecha.

    Qué hacer el lunes

    Si tu organización usa Snowflake como plataforma principal, el primer paso es auditar cuántas DMFs están activas hoy y sobre qué porcentaje del inventario total de tablas críticas. Ese número revela inmediatamente la cobertura real del programa de calidad. Después, revisá el catálogo de datos activo —sea Snowflake Horizon, Collibra, Alation u otro— y verificá si el linaje de al menos los diez activos más sensibles llega hasta la fuente de origen. Si la respuesta es no en ambos casos, tenés dos brechas documentables para justificar inversión en governance ante el CFO o el directorio.

    Snowflake es una plataforma poderosa, pero un programa de calidad de datos no puede tener el mismo perímetro que una licencia de software.

  • EFF en DEF CON 34: cuando hackear el sistema significa defender derechos digitales

    EFF en DEF CON 34: cuando hackear el sistema significa defender derechos digitales

    La Electronic Frontier Foundation vuelve a Las Vegas para la semana de seguridad más concurrida del año, con una agenda que combina litigio, desarrollo de herramientas y formación para poblaciones vulnerables. La presencia de EFF en BSides, Black Hat y DEF CON 34 no es solo simbólica: es la expresión de una estrategia que reconoce que los derechos digitales no pueden depender exclusivamente de los tribunales.

    DEF CON 34 convoca cada verano a miles de hackers, investigadores de seguridad, analistas de política y activistas en Las Vegas. En ese ecosistema, EFF ocupa un lugar peculiar: es al mismo tiempo litigante, desarrolladora de software y educadora en derechos digitales. La organización lleva años argumentando que la defensa de la privacidad y la libertad de expresión requiere intervenir en tres frentes simultáneos —legal, técnico y comunitario— porque ninguno por sí solo es suficiente.

    Herramientas como política pública

    Entre los proyectos que EFF lleva al terreno técnico se encuentran Privacy Badger, un complemento de navegador que bloquea rastreadores invisibles, y Certbot, la herramienta que automatizó la adopción masiva de HTTPS y hoy protege millones de sitios. A estos se suma la guía Surveillance Self-Defense, un recurso de autodefensa digital orientado a periodistas, activistas y cualquier persona que opere en entornos de riesgo. Estas herramientas no nacen de un ejercicio académico: son respuestas directas a amenazas documentadas que los sistemas legales tardan años en procesar.

    El argumento central de EFF es que la tecnología no es neutral. Cuando los sistemas de vigilancia se despliegan antes de que los marcos regulatorios los alcancen, la única defensa disponible en el corto plazo es técnica. Este enfoque tiene una lógica que resuena con fuerza en América Latina, donde la brecha entre la adopción tecnológica y la capacidad regulatoria es especialmente pronunciada.

    El vacío regulatorio en la región

    En América Latina, el panorama de protección de datos personales es fragmentado. Brasil cuenta con la LGPD y una Autoridade Nacional de Proteção de Dados (ANPD) que ha comenzado a emitir resoluciones con dientes. México tiene la LFPDPPP, aunque el INAI ha enfrentado cuestionamientos presupuestarios que limitan su capacidad operativa. Argentina opera bajo la Ley 25.326, cuya modernización lleva años debatiéndose sin resolución definitiva. En ese contexto, las herramientas de autodefensa digital como las que promueve EFF no son un lujo sino una necesidad práctica para organizaciones de la sociedad civil, medios independientes y ciudadanos en general.

    Colombia, Chile y Perú han avanzado en sus marcos normativos de protección de datos, pero la capacidad de enforcement sigue siendo desigual. Cuando una autoridad no puede responder en tiempo real a una amenaza de vigilancia, la pregunta que queda es quién protege al usuario en el ínterin. La respuesta de EFF —herramientas de código abierto, guías de autoprotección y formación directa a comunidades vulnerables— es una de las pocas que opera en esa escala de tiempo.

    La convergencia entre técnica y derecho

    Lo que hace relevante la presencia de EFF en DEF CON no es la distribución de remeras con puzzles integrados —aunque la tradición hacker de los acertijos tiene su propio valor cultural— sino la conversación que se produce en esos espacios entre abogados, ingenieros y activistas. Es allí donde se diseñan las próximas líneas de defensa: qué vulnerabilidades de privacidad merecen litigio estratégico, qué herramientas deben desarrollarse, qué comunidades necesitan formación urgente.

    “EFF’s relentless work in the legal system makes a meaningful difference for privacy and free expression everywhere. But we also know that your rights won’t wait while the wheels of justice turn.”

    — Electronic Frontier Foundation, comunicado DEF CON 34

    Esa tensión entre los tiempos del derecho y los tiempos de la tecnología es uno de los debates más urgentes en la región. Las leyes de protección de datos fueron diseñadas para entornos analógicos o para Internet en sus primeras fases. La vigilancia algorítmica, el rastreo por biometría facial y la recolección masiva de metadatos operan en una velocidad que los procesos administrativos y judiciales difícilmente alcanzan.

    Comunidad como infraestructura

    El modelo de EFF apuesta a que la comunidad técnica —hackers, investigadores de seguridad, desarrolladores— es una forma de infraestructura de derechos digitales. No como sustituto del Estado o del marco legal, sino como capa complementaria que opera cuando los otros mecanismos fallan o llegan tarde. En LATAM, ese modelo tiene antecedentes: organizaciones como Derechos Digitales en Chile, Datos Protegidos, o el Centro de Estudios en Libertad de Expresión e Información (CELE) en Argentina operan en esa misma intersección entre derecho y técnica, aunque con recursos significativamente menores.

    La pregunta que DEF CON 34 deja abierta para la región es si América Latina puede construir su propia capa de infraestructura comunitaria de derechos digitales antes de que el vacío regulatorio sea demasiado costoso de cerrar.

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

  • Gobernanza de datos en el siglo XXI: del marco teórico a la acción concreta

    Gobernanza de datos en el siglo XXI: del marco teórico a la acción concreta

    La gobernanza de datos dejó de ser un proyecto de TI para convertirse en una capacidad organizacional crítica. En un contexto donde los marcos regulatorios de América Latina se consolidan y la presión sobre los datos corporativos aumenta, los equipos liderados por Chief Data Officers enfrentan una brecha persistente: saben qué es gobernanza de datos, pero pocas organizaciones logran operacionalizarla de manera sostenible.

    Durante años, la conversación en torno a la gobernanza de datos giró alrededor de definiciones, políticas y organigramas. El resultado fue previsible: documentos bien redactados que nadie consulta, comités de gobierno que se reúnen trimestralmente sin poder de decisión real, y data stewards —responsables temáticos del dato dentro de un dominio de negocio— que desconocen qué activos tienen a su cargo. El problema no es conceptual. Es de diseño institucional y de priorización ejecutiva.

    El dato como activo que se gestiona, no que se almacena

    El DAMA-DMBOK (Data Management Body of Knowledge), referencia estándar de la industria, organiza la gestión de datos en once áreas de conocimiento que van desde la arquitectura hasta la calidad y la seguridad. Sin embargo, la mayoría de las organizaciones latinoamericanas que dicen “tener gobernanza” operan únicamente en dos o tres de esas áreas, típicamente calidad de datos y alguna forma de catálogo. Lo que queda fuera —data lineage, ownership formal, clasificación por criticidad, ciclo de vida del dato— es precisamente lo que diferencia una función de gobernanza madura de una iniciativa de limpieza de datos con otro nombre.

    El EDM Council, con su marco CDMC (Cloud Data Management Capabilities), ofrece una perspectiva complementaria orientada a entornos cloud y regulados. Sus doce capabilities permiten medir la madurez de forma granular. Lo relevante para la región es que varios bancos brasileños que reportan al Banco Central bajo las resoluciones del CMN ya operan con prácticas equivalentes a los niveles intermedios del CDMC —especialmente en clasificación de datos y controles de acceso— aunque sin la certificación formal ni la trazabilidad documentada que exige un programa de gobernanza robusto.

    El marco regulatorio regional como palanca, no como amenaza

    En América Latina, la presión regulatoria está empujando la agenda de gobernanza desde afuera hacia adentro. La LGPD brasileña (Lei Geral de Proteção de Dados) obliga a las organizaciones a mapear sus datos personales, definir bases legales de tratamiento y designar un Encarregado —rol que en la práctica recae sobre el DPO o se superpone con funciones de governance. En Argentina, la Ley 25.326 está en proceso de reforma con un proyecto que incorpora estándares más cercanos al GDPR europeo, incluyendo la figura del delegado de protección de datos y evaluaciones de impacto. En México, la LFPDPPP y sus lineamientos del INAI ya exigen documentación de flujos de datos personales que es, en esencia, data lineage aplicado a un subconjunto crítico del inventario corporativo.

    Este contexto crea una oportunidad concreta: usar el cumplimiento regulatorio como caso de negocio para financiar el programa de gobernanza más amplio. Un CDO que logra articular “necesitamos catálogo de datos y data lineage para responder a los requerimientos de la ANPD o la AAIP” tiene un argumento presupuestario mucho más sólido que uno que habla de “madurez de datos” en abstracto.

    Qué hace un CDO con esto el lunes a la mañana

    El punto de partida no es un framework completo. Es una decisión de scope. Bob Seiner, referente del modelo Non-Invasive Data Governance, sostiene que la gobernanza efectiva parte de reconocer y formalizar lo que la organización ya hace informalmente —quién responde preguntas sobre un dato, quién aprueba cambios en una definición de negocio— antes de imponer estructuras nuevas. Aplicado a la realidad latinoamericana, esto significa identificar los tres o cinco dominios de datos más críticos para el negocio (clientes, productos, finanzas, por ejemplo), asignar data stewards con nombre y apellido en cada uno, y establecer un mecanismo mínimo de resolución de conflictos sobre definiciones y calidad.

    • Auditar qué áreas del DAMA-DMBOK están cubiertas formalmente y cuáles operan de manera ad hoc o directamente no existen.
    • Mapear los dominios de datos que tienen impacto regulatorio directo (datos personales bajo LGPD/Ley 25.326/LFPDPPP) y usarlos como piloto del programa de gobernanza.
    • Identificar los data stewards informales actuales —las personas que hoy de facto responden preguntas sobre el dato— y formalizarlos antes de crear roles nuevos.
    • Establecer una métrica de calidad de datos por dominio y reportarla al Comité de Dirección junto con el riesgo regulatorio asociado.

    La trampa del perfeccionismo y el costo de la espera

    Uno de los patrones más comunes en organizaciones que llevan años “implementando gobernanza” sin resultados visibles es la búsqueda del modelo perfecto antes de ejecutar. Se diseña el catálogo ideal, se debaten taxonomías durante meses, se espera la herramienta correcta. Mientras tanto, los datos críticos siguen sin owner formal, los pipelines se multiplican sin documentación y los auditores —ya sean internos o de la autoridad regulatoria— encuentran los mismos gaps año tras año. John Ladley, en su obra sobre data governance, es explícito al respecto: la gobernanza de datos es un programa de gestión del cambio con componentes técnicos, no un proyecto tecnológico con componentes de gestión del cambio. Invertir esa relación es la causa más frecuente de fracaso.

    En un entorno donde las regulaciones latinoamericanas están madurando más rápido que los programas internos de gobernanza, la pregunta ya no es si implementar un marco —sino cuánto cuesta cada mes de demora.

  • África construye su propio modelo de gobernanza de datos personales: qué puede aprender LATAM

    África construye su propio modelo de gobernanza de datos personales: qué puede aprender LATAM

    Benín se posicionó como referente regional en protección de datos personales al compartir su experiencia en el Foro Africano de Gobernanza de Datos Personales, un espacio que busca articular estándares comunes para el continente. La iniciativa pone en evidencia una dinámica que América Latina conoce bien: la tensión entre marcos legales nacionales fragmentados y la necesidad de interoperabilidad regional. Para los equipos de gobierno de datos en LATAM, el movimiento africano ofrece un espejo incómodo pero útil.

    Un foro, muchos marcos: el desafío de la armonización

    El encuentro reunió a representantes de autoridades de protección de datos y organismos gubernamentales de distintos países africanos con el objetivo de construir criterios compartidos sobre gestión de datos personales. Benín, que cuenta con una autoridad de protección de datos activa y legislación específica en la materia, expuso según se informó su modelo de implementación como caso de referencia. El eje no fue técnico sino institucional: cómo una autoridad nacional puede operar con recursos limitados y aun así generar capacidades de enforcement creíbles.

    El paralelo con América Latina es directo. La región cuenta con al menos ocho marcos legales de datos personales activos —entre ellos la LGPD brasileña, la Ley 25.326 argentina, la LFPDPPP mexicana, la Ley 1581 colombiana y la Ley 19.628 chilena en proceso de reforma— pero la coordinación entre autoridades sigue siendo incipiente. La Red Iberoamericana de Protección de Datos (RIPD) cumple un rol de articulación, aunque sin poder vinculante sobre las decisiones de cada autoridad nacional.

    El ownership del dato como problema de gobernanza, no de tecnología

    Lo que el foro africano pone sobre la mesa —y que resuena en la agenda de cualquier CDO de la región— es que los desafíos de gobernanza de datos personales raramente son técnicos en su origen. Son problemas de ownership: quién decide qué se recolecta, quién es responsable cuando el dato se comparte entre entidades, y qué controles de acceso existen a lo largo del ciclo de vida del dato. En términos del DAMA-DMBOK, esto corresponde al dominio de Data Security y Data Governance en su intersección: definir roles de data steward con responsabilidad explícita sobre datos sensibles y garantizar que esa responsabilidad esté documentada en el catálogo de datos.

    El marco CDMC (Cloud Data Management Capabilities) del EDM Council establece en su capability 9 los controles de privacidad como componente integrado de la arquitectura de datos, no como capa adicional. Organizaciones en Brasil que operan bajo LGPD con obligación de reportar incidentes a la ANPD en 72 horas ya están, en la práctica, obligadas a tener ese nivel de madurez. El problema es que muchas lo implementan de forma reactiva, como respuesta a una auditoría, y no como parte del modelo operativo de gobierno.

    Qué hace un CDO con esto el lunes

    El movimiento africano hacia estándares regionales debería funcionar como señal de alerta temprana para equipos de DG en LATAM. Cuando una región emergente comienza a armonizar marcos de gobernanza de datos personales, los socios comerciales y reguladores globales elevan sus expectativas de interoperabilidad. Esto tiene consecuencias prácticas: un CDO que hoy no tiene mapeado el flujo transfronterizo de datos personales de su organización —especialmente en operaciones que cruzan Brasil, Argentina y México— está operando con un riesgo regulatorio no cuantificado.

    Los pasos concretos para esta semana son tres. Primero, revisar si el data catalog corporativo tiene campos de clasificación de sensibilidad activos y si están siendo completados por los data stewards asignados, no por el equipo de IT de forma genérica. Segundo, verificar si existen acuerdos de transferencia de datos documentados para cada flujo transfronterizo, especialmente hacia proveedores cloud con infraestructura fuera de la región. Tercero, contrastar el inventario de tratamientos de datos personales con los requisitos de notificación de la autoridad local: en Argentina, la AAIP exige inscripción de bases de datos; en Colombia, el Registro Nacional de Bases de Datos (RNBD) ante la SIC cumple una función equivalente.

    La gobernanza como ventaja competitiva regional

    Más allá del cumplimiento, la experiencia africana sugiere que los países y organizaciones que invierten en construir capacidades de gobernanza de datos personales antes de que la presión regulatoria sea máxima terminan en mejor posición para atraer inversión y operar en mercados exigentes. En LATAM, el sector financiero es el que más avanzó en esta dirección: los bancos chilenos bajo supervisión de la CMF y las entidades financieras argentinas que reportan al BCRA bajo la Comunicación A 8073 ya operan con controles de calidad y linaje de datos que se superponen con los requerimientos de privacidad, aunque sin certificación formal bajo un marco como CDMC.

    La pregunta que deja el foro africano no es si LATAM necesita mayor armonización regulatoria —eso ya está en la agenda— sino si las organizaciones de la región van a esperar que esa armonización llegue desde arriba o van a construir la madurez de gobernanza que les permita operar en cualquier escenario regulatorio que venga.

  • Data lineage de extremo a extremo: por qué el eslabón mainframe sigue roto

    Data lineage de extremo a extremo: por qué el eslabón mainframe sigue roto

    El data lineage —la capacidad de rastrear el origen, las transformaciones y el destino de cada dato en una organización— se ha convertido en un requisito no negociable para el gobierno corporativo de datos. Sin embargo, la mayoría de las implementaciones tienen un punto ciego crítico: los sistemas mainframe y legados que, en industrias como banca, seguros y retail, siguen concentrando los registros más sensibles y de mayor volumen.

    En la práctica, cuando un CDO pide un mapa completo del flujo de datos desde el origen hasta el consumo, suele recibir una cadena con eslabones faltantes. Las plataformas modernas de data catalog documentan con precisión lo que ocurre en capas cloud o en pipelines construidos sobre tecnologías abiertas, pero el momento en que un dato nació en un sistema COBOL o en un archivo VSAM queda fuera del grafo. Eso no es lineage de extremo a extremo: es lineage a partir del segundo paso.

    El problema de la brecha de origen

    La integración entre Ataccama y Rocket Software apunta exactamente a cerrar esa brecha. Rocket Software aporta capacidad de extracción de metadatos técnicos desde entornos IBM z/OS —incluyendo programas COBOL, JCL, DB2 y estructuras de datos VSAM— mientras que Ataccama ONE los absorbe y los vincula al grafo de lineage que conecta con el resto del ecosistema de datos moderno. El resultado es un linaje continuo que no se interrumpe cuando el dato proviene de un mainframe.

    Según se informó, la integración permite mapear automáticamente las transformaciones que ocurren dentro del código COBOL sin intervención manual, un cuello de botella histórico que obligaba a los equipos de data stewardship a documentar esas capas a mano o simplemente ignorarlas. Para organizaciones con decenas de miles de programas batch activos, la documentación manual no es una opción realista.

    Por qué el lineage incompleto es un riesgo de governance

    Desde la perspectiva del DAMA-DMBOK, el data lineage es un componente central del área de conocimiento de Metadata Management y un prerequisito operativo para la gestión efectiva de calidad de datos y de ciclo de vida. Sin lineage completo, el impact analysis —saber qué reportes, modelos o decisiones se ven afectados si cambia una tabla fuente— es parcial en el mejor caso y engañoso en el peor. En entornos regulados, eso tiene consecuencias directas.

    El problema se amplifica cuando los datos de origen mainframe alimentan modelos de inteligencia artificial o agentes automatizados de decisión. Si el sistema no puede trazar la procedencia del dato que entrenó un modelo o que ingesta un agente en tiempo real, la organización queda expuesta a riesgos de explicabilidad que ya están siendo objeto de escrutinio regulatorio en varias jurisdicciones.

    El ángulo regulatorio en América Latina

    En la región, la presión por tener lineage auditable no es solo una aspiración de madurez técnica: es una exigencia emergente. En Brasil, la ANPD ha enfatizado en sus guías de adecuación a la LGPD que las organizaciones deben poder demostrar el flujo completo de datos personales, desde la recolección hasta el descarte. En Argentina, la Comunicación A 7724 del BCRA —que regula la gestión de riesgos tecnológicos en entidades financieras— requiere trazabilidad sobre los procesos que afectan datos críticos. Los bancos argentinos que todavía operan núcleos bancarios sobre mainframe IBM están, en muchos casos, en deuda con ese requisito porque su lineage se interrumpe precisamente en esa capa.

    En Colombia, la Superintendencia Financiera ha impulsado estándares de gobierno de datos que incluyen mapeo de flujos de información como condición para la aprobación de modelos internos de riesgo. Las entidades que no pueden demostrar el origen de los datos que alimentan esos modelos enfrentan observaciones formales en los procesos de supervisión. La brecha de lineage en mainframe, lejos de ser un problema técnico interno, tiene implicancias regulatorias concretas.

    Qué hace un CDO con esto el lunes

    El primer paso accionable es un inventario de opacidad: identificar cuántos de los pipelines catalogados en la plataforma actual tienen como origen un sistema mainframe o legado sin cobertura de lineage. Ese número —que en bancos medianos de la región suele superar el 40% de los flujos críticos, según estimaciones de consultoras especializadas— define la urgencia del caso de negocio. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), clasifica el lineage end-to-end como una capability de nivel 2 dentro del dominio de Data Quality and Controls; organizaciones que no pueden acreditar esa cobertura difícilmente alcanzan niveles de certificación relevantes.

    El segundo paso es evaluar si la arquitectura actual de metadata management tiene un conector hacia los entornos z/OS o si depende de documentación manual gestionada fuera del catalog. Si la respuesta es la segunda, el riesgo de desactualización es permanente: cada cambio en un programa COBOL que no se refleja en el grafo de lineage es un punto ciego nuevo. La integración entre herramientas especializadas en extracción de metadatos mainframe y plataformas de gobierno modernas es, hoy, la solución técnica más viable para organizaciones que no pueden —ni quieren— migrar esos sistemas en el corto plazo.

    La apuesta por la continuidad, no por la migración

    El enfoque de integración entre capas —en lugar de exigir la migración del sistema de origen como condición para tener lineage— reconoce una realidad que muchos fabricantes de plataformas modernas evitan admitir: los mainframes no van a desaparecer en los próximos cinco años en la banca latinoamericana. Según se informó en distintos foros del sector, más del 70% de las transacciones financieras en la región siguen procesándose sobre arquitecturas z/OS o equivalentes. Diseñar una estrategia de governance que ignore esa capa es diseñar una estrategia incompleta.

    El lineage que no llega hasta el origen no es lineage: es una historia que empieza a la mitad.

  • Bangladesh bajo la lupa: organizaciones exigen fin a la vigilancia estatal masiva

    Bangladesh bajo la lupa: organizaciones exigen fin a la vigilancia estatal masiva

    Una coalición internacional de organizaciones de derechos digitales emitió una declaración conjunta exigiendo que Bangladesh ponga fin a sus prácticas de vigilancia e interceptación de comunicaciones. El llamado se produce en un contexto de creciente preocupación global por el uso de herramientas de monitoreo estatal contra periodistas, activistas y ciudadanos comunes, y resuena con fuerza en una región latinoamericana que también enfrenta debates pendientes sobre los límites del espionaje gubernamental.

    Un patrón de vigilancia sistemática

    Según se informó, las autoridades de Bangladesh habrían desplegado capacidades de interceptación de comunicaciones de manera sostenida, apuntando a disidentes políticos, periodistas y defensores de derechos humanos. La declaración conjunta —liderada por organizaciones como Access Now junto a otras firmas de la sociedad civil global— denuncia que estas prácticas operan fuera de todo marco legal adecuado, sin controles judiciales efectivos ni mecanismos de rendición de cuentas. El documento insta al gobierno bangladesí a suspender de inmediato el uso de tecnologías de vigilancia intrusiva y a adoptar salvaguardas legales acordes a los estándares internacionales de derechos humanos.

    El caso de Bangladesh no es aislado en el mapa global de la vigilancia estatal. En los últimos años, herramientas como Pegasus —el spyware del grupo NSO— han sido detectadas en decenas de países, incluyendo varios de América Latina. México, El Salvador y Colombia figuraron entre los Estados donde, según reportes de Citizen Lab y Amnistía Internacional, periodistas y activistas fueron objetivo de este tipo de software. La denuncia sobre Bangladesh renueva la urgencia de establecer estándares vinculantes internacionales.

    El vacío legal como vector de abuso

    Uno de los argumentos centrales de la declaración es que la ausencia de marcos normativos claros habilita el abuso. En Bangladesh, según se informó, la legislación vigente otorga amplias facultades de interceptación a los servicios de seguridad con escasa supervisión independiente. Este patrón es conocido en la región latinoamericana: países como Argentina cuentan con la Ley 25.326 de Protección de Datos Personales, pero las normas sobre vigilancia estatal siguen siendo un terreno fragmentado. Brasil avanzó con la Lei Geral de Proteção de Dados (LGPD), aunque los marcos específicos de inteligencia y espionaje permanecen sujetos a debate legislativo. México, por su parte, enfrenta cuestionamientos estructurales sobre el uso de herramientas de intercepción por parte de dependencias federales, a pesar de que la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) establece principios de finalidad y proporcionalidad.

    “Los gobiernos no pueden invocar la seguridad nacional como cheque en blanco para espiar a su propia población sin controles democráticos efectivos.”

    — Declaración conjunta, organizaciones de derechos digitales firmantes

    Estándares internacionales y el rol de la sociedad civil

    La declaración hace referencia explícita a los Principios de Necesidad y Proporcionalidad, el marco internacional que establece condiciones mínimas para que cualquier vigilancia estatal sea considerada legítima. Entre esas condiciones se cuentan: base legal clara, objetivo legítimo, supervisión judicial independiente, notificación al afectado cuando sea posible y acceso a recursos legales efectivos. Ninguno de estos requisitos, según las organizaciones firmantes, se cumple en el caso bangladesí. La sociedad civil regional tiene antecedentes en este tipo de presión: en América Latina, redes como Derechos Digitales, R3D y EFF han jugado roles protagónicos en litigios y campañas que pusieron límites a la vigilancia gubernamental en distintos países.

    Implicancias para la agenda regional

    El llamado internacional sobre Bangladesh llega en un momento en que varios países de América Latina debaten reformas a sus marcos de inteligencia y seguridad. Chile avanza en la actualización de su Ley 19.628, mientras que en Colombia la Superintendencia de Industria y Comercio mantiene activa la discusión sobre los límites del tratamiento de datos por parte del Estado. La presión de la sociedad civil global —articulada en declaraciones como esta— contribuye a elevar el estándar de lo que se considera aceptable, generando precedentes que las organizaciones locales utilizan como palanca en sus propias disputas domésticas.

    Cuando la vigilancia estatal opera sin controles, la pregunta no es si habrá abusos, sino cuándo saldrán a la luz —y qué tan tarde será para quienes los padecieron.