DataTrends LATAM

Blog

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

  • KOSA: la ley de protección infantil de EE.UU. que amenaza la privacidad de todos

    KOSA: la ley de protección infantil de EE.UU. que amenaza la privacidad de todos

    El Senado de Estados Unidos avanza en la votación de la Kids Online Safety Act (KOSA), una ley que, bajo la bandera de proteger a los menores en internet, introduciría requisitos masivos de verificación de edad y generaría nuevas bases de datos sensibles susceptibles de filtraciones y abusos. La Electronic Frontier Foundation advierte que el proyecto no refuerza la privacidad, sino que crea riesgos inéditos para todos los usuarios, sin importar su edad. El debate resuena con fuerza en América Latina, donde varios países también discuten marcos para regular el acceso de menores a plataformas digitales.

    Una “duty of care” con un costo oculto

    El núcleo de KOSA es la imposición de un “deber de cuidado” a los servicios en línea —redes sociales incluidas— para evitar que los menores accedan a contenidos que la ley considera dañinos. El problema estructural es evidente: para cumplir esa obligación, las plataformas necesitan saber cuáles de sus usuarios son menores de edad. Y para saberlo, deben verificarlo. Eso implica recolectar credenciales de identidad, realizar análisis faciales, cruzar registros bancarios u obtener otro tipo de información personal sensible que, hasta hoy, no era condición de acceso a servicios digitales legítimos.

    El resultado práctico no es una internet más segura para los niños, sino una internet donde todos los usuarios —adultos incluidos— deben identificarse antes de leer, hablar o participar en espacios públicos digitales. Cada sistema de verificación de edad construye una nueva base de datos centralizada que puede ser vulnerada, mal utilizada o exigida por gobiernos con agendas muy distintas a la protección infantil. La EFF señala que estas arquitecturas de identificación obligatoria representan un riesgo sistémico de privacidad que afecta a la totalidad de la población conectada.

    Censura algorítmica disfrazada de protección

    Más allá de la verificación de edad, KOSA delega en los fiscales generales de cada estado la facultad de determinar qué contenidos son “apropiados” para los menores en las plataformas. Eso significa que funcionarios electos —con mandatos políticos propios— quedan habilitados para presionar a las empresas tecnológicas sobre decisiones editoriales que afectan al discurso lícito en línea. La ley, en lugar de fortalecer el rol de las familias, lo desplaza hacia el Estado.

    “KOSA y los otros proyectos que se votan esta semana empujan a los servicios en línea a adoptar sistemas que exigen a las personas identificarse antes de poder hablar, leer o participar en internet.”

    — Electronic Frontier Foundation, análisis legislativo, agosto de 2026

    El proyecto se presenta en un paquete legislativo más amplio que incluye el SCREEN Act, el CHATBOT Act y la Youth AI Privacy Act. Cada uno de estos instrumentos apunta a regular distintos aspectos del uso infantil de tecnología, pero comparten una lógica común: ampliar el flujo de datos personales que las plataformas deben recopilar para cumplir con obligaciones de identificación etaria. La suma de estas leyes configura un ecosistema regulatorio que, paradójicamente, incrementa la exposición de los datos de los propios menores que busca proteger.

    El espejo latinoamericano

    El dilema que plantea KOSA no es exclusivo del debate legislativo estadounidense. En Brasil, la Lei 14.811/2024 introdujo obligaciones para plataformas digitales respecto al uso de algoritmos con menores, y la ANPD ha comenzado a pronunciarse sobre cómo aplicar los principios de la LGPD en contextos de usuarios infantiles. En Argentina, la Ley 25.326 no contempla mecanismos específicos de verificación de edad, aunque la AAIP ha impulsado lineamientos sobre tratamiento de datos de niños, niñas y adolescentes. Colombia y Chile también tienen en desarrollo o discusión marcos sectoriales que podrían incorporar este tipo de obligaciones.

    El riesgo que expone el caso KOSA es relevante para todos esos procesos: cualquier regulación que obligue a las plataformas a verificar la edad de sus usuarios sin establecer garantías técnicas y legales robustas —minimización de datos, propósito limitado, prohibición de reutilización— puede convertirse en un mecanismo de vigilancia masiva disfrazado de política pública de infancia. La verificación de edad sin privacidad by design no protege a los menores; los expone junto al resto de la población.

    Protección real versus recolección expandida

    Existen alternativas técnicas y legales que permiten moderar el acceso de menores a contenidos sin exigir la identificación universal de todos los usuarios. Controles parentales robustos a nivel de sistema operativo o dispositivo, estándares de diseño que limiten patrones adictivos por defecto, y auditorías algorítmicas con supervisión independiente son herramientas que no requieren construir bases de datos de identidad. La EFF plantea que el Congreso estadounidense podría haber optado por ese camino, pero eligió uno que prioriza la arquitectura de control sobre la arquitectura de privacidad.

    La pregunta que deberían hacerse los legisladores latinoamericanos que observan este debate es incómoda pero necesaria: ¿estamos construyendo regulaciones que protegen a los menores, o regulaciones que simplemente recolectan más datos sobre todos?

  • EFF y 18 organizaciones piden vetar ley que criminalizaría el rastreo web anónimo

    EFF y 18 organizaciones piden vetar ley que criminalizaría el rastreo web anónimo

    Una coalición de 19 organizaciones de derechos civiles, encabezada por la Electronic Frontier Foundation, exige al gobernador de Nueva York que vete el proyecto de ley conocido como Stealth Crawler Prohibition Act. La norma, que obliga a los rastreadores web a revelar su identidad y propósito, es cuestionada por amenazar la privacidad digital, el periodismo independiente y la arquitectura abierta de internet. El debate trasciende fronteras: en América Latina, donde el scraping anónimo sostiene investigaciones de interés público, el antecedente neoyorquino encendió alertas.

    El proyecto Senate Bill 9934A avanzó en la legislatura de Nueva York bajo la premisa de proteger a los medios de comunicación locales del impacto económico de los bots que recopilan su contenido. Sin embargo, su alcance es mucho más amplio. La norma exigiría que cualquier rastreador web automatizado revele quién lo opera y con qué fin, y facultaría a los medios a solicitar citaciones judiciales para desanonimizar el tráfico automatizado, incluso sin probar daño alguno ni conducta indebida. Para las organizaciones firmantes, eso convierte una herramienta cotidiana y legítima en una actividad potencialmente criminalizada.

    Rastreadores anónimos: mucho más que bots de scraping

    Los llamados “stealth crawlers” son programas que acceden a páginas web públicas sin identificarse como tales ante el servidor. Lejos de ser exclusivos de actores maliciosos, son la columna vertebral de proyectos de alto valor social. La EFF los utiliza, por ejemplo, en Privacy Badger, su herramienta de bloqueo de rastreadores publicitarios. El medio de periodismo de datos The Markup los empleó para documentar cómo Amazon prioriza sus propias marcas sobre productos de competidores mejor calificados, identificándose ante los servidores como un navegador Firefox ordinario para obtener los mismos resultados que vería cualquier usuario. Si la ley neoyorquina hubiera estado vigente, esa investigación podría haber quedado expuesta a demandas o directamente archivada.

    La coalición que firmó la carta a la gobernadora Kathy Hochul advierte que la norma “deanonimiza y criminaliza el acceso automatizado a la web abierta” sin exigir ninguna demostración de perjuicio concreto. El estándar propuesto por el proyecto —revelar identidad y propósito explícito— resulta incompatible con la forma en que operan la investigación periodística, la vigilancia de ciberseguridad y la academia, todas actividades que requieren, en distintos grados, operar sin revelar sus métodos al sujeto investigado.

    El riesgo para el periodismo que la ley dice proteger

    La paradoja central del proyecto es que, al pretender defender a los medios locales, podría terminar silenciando al periodismo de investigación que más depende de estas herramientas. Los outlets con recursos pueden contratar acceso a datos vía APIs o acuerdos comerciales. Los medios pequeños e independientes, por el contrario, suelen apoyarse en el rastreo anónimo para acceder a información pública que, de otra forma, estaría fuera de su alcance. Obligarlos a identificarse ante el servidor equivale, en algunos casos, a alertar al sujeto investigado antes de publicar la historia.

    “Esta legislación daña la libre expresión y establece un precedente peligroso al deanonimizar y criminalizar efectivamente el acceso automatizado a la web abierta, amenazando la privacidad digital y comprometiendo la arquitectura fundacional de internet.”

    — Carta conjunta de EFF y 18 organizaciones de derechos civiles, dirigida a la gobernadora Kathy Hochul

    Resonancias en América Latina

    El debate neoyorquino no es ajeno a la región. En América Latina, el scraping de fuentes públicas es una práctica extendida entre equipos de periodismo de datos, organismos de control fiscal y organizaciones de la sociedad civil que monitorean compras públicas, precios de medicamentos o contaminación ambiental. Marcos como la Ley 25.326 de Argentina, la LGPD de Brasil y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México regulan el tratamiento de datos personales, pero ninguno prohíbe el acceso a información pública disponible en la web abierta. Si un estándar similar al neoyorquino se instalara como referencia legislativa en la región, podría colisionar con garantías de acceso a la información pública y con el derecho a la privacidad de quienes investigan, no solo de quienes son investigados.

    Colombia, Chile y Perú se encuentran en distintas etapas de modernización de sus marcos de protección de datos. En ese contexto, legislar sobre rastreo web sin distinguir entre actores maliciosos y herramientas legítimas podría generar un efecto de congelamiento normativo que inhiba prácticas de investigación valiosas. La presión de los grandes medios para proteger su contenido frente a la IA generativa es legítima, pero los instrumentos elegidos importan: una ley que deanonimiza el acceso a la web pública no es una ley de derechos de autor, es una ley de vigilancia.

    El trasfondo: contenido periodístico e IA generativa

    Detrás del proyecto neoyorquino subyace la tensión no resuelta entre la industria de medios y las empresas de inteligencia artificial que entrenan sus modelos con contenido periodístico sin compensación. Esa disputa es real y merece respuesta legislativa. Sin embargo, las organizaciones firmantes señalan que la Stealth Crawler Prohibition Act es un instrumento demasiado amplio para un problema acotado: afecta por igual al bot de OpenAI y al investigador independiente que verifica si una empresa contamina un río. La solución a la crisis del financiamiento periodístico no puede ser construida sobre la erosión de las herramientas que hacen posible el periodismo de datos.

    Si Nueva York aprueba esta ley, sentará un precedente que otros legisladores —también en América Latina— podrían replicar sin medir sus consecuencias para la investigación periodística y la transparencia pública.