DataTrends LATAM

Blog

  • ¿Dónde están sus datos? La pregunta que la IA obliga a responder

    ¿Dónde están sus datos? La pregunta que la IA obliga a responder

    La adopción masiva de inteligencia artificial en las organizaciones latinoamericanas ha disparado una pregunta que muchos equipos de datos no pueden responder con certeza: ¿dónde están realmente los datos que alimentan esos modelos? El problema no es nuevo, pero la IA lo volvió urgente. Sin un inventario preciso y un data lineage actualizado, cualquier iniciativa de IA corporativa construye sobre terreno inestable.

    Durante años, la gobernanza de datos fue tratada como un proyecto de infraestructura de segundo orden: importante en el papel, postergado en la práctica. Los datos se acumularon en silos departamentales, data lakes sin catalogar y sistemas heredados que nadie se atrevía a tocar. Ese desorden era manejable cuando los datos se usaban para reportes o dashboards. Deja de serlo cuando un modelo de lenguaje o un sistema de ML los consume sin discriminar calidad, origen ni clasificación de sensibilidad.

    El inventario como base de todo

    El primer paso que propone el DAMA-DMBOK para cualquier programa de gobierno de datos es el establecimiento de un inventario de activos de datos —lo que en la industria se conoce como data catalog. No se trata de una herramienta tecnológica per se, sino de una decisión organizacional: alguien tiene que ser responsable de saber qué datos existen, dónde residen, quién los usa y con qué propósito. Ese rol es el data steward, y en la mayoría de las empresas latinoamericanas todavía no está formalizado ni tiene capacidad de decisión real.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica la capacidad de localización y clasificación de datos como una de las capabilities fundacionales —equivalente al nivel 8 de su modelo de madurez— sin la cual ningún control de privacidad, seguridad o calidad puede implementarse de forma efectiva. Dicho de otro modo: si no sabés dónde están tus datos, no podés protegerlos, no podés auditarlos y no podés cumplir con ninguna obligación regulatoria.

    La presión regulatoria que ya llegó

    En América Latina, esta exigencia dejó de ser solo buena práctica para convertirse en obligación legal en varios frentes. En Brasil, la Lei Geral de Proteção de Dados (LGPD) requiere que las organizaciones puedan demostrar el propósito y la base legal de cada tratamiento de datos personales —algo imposible sin un registro de actividades de tratamiento actualizado. En Argentina, la Ley 25.326 y la reglamentación de la AAIP (Agencia de Acceso a la Información Pública) exigen que los responsables de bases de datos personales puedan informar a los titulares qué datos tienen y con qué fin. En México, la LFPDPPP impone obligaciones similares sobre el aviso de privacidad y los transfers de datos a terceros.

    Lo que la IA agrega a este escenario es una capa adicional de complejidad: cuando los datos personales se usan para entrenar o alimentar un modelo, el ciclo de vida del dato se vuelve difuso. ¿En qué punto el dato deja de ser “tratado” y pasa a ser parte del modelo? ¿Quién es el data steward de un dataset de entrenamiento? Estas preguntas no tienen respuesta regulatoria definitiva en la región, pero las autoridades de protección de datos ya las están formulando.

    Qué hace un CDO con esto el lunes

    La pregunta operativa no es filosófica. Un Chief Data Officer que está evaluando o ya tiene iniciativas de IA en producción debería revisar esta semana al menos tres cosas concretas:

    • Inventario de datasets en uso por modelos de IA: ¿están catalogados con clasificación de sensibilidad (dato personal, dato confidencial, dato público)? ¿Tienen data steward asignado?
    • Data lineage de extremo a extremo: ¿puede trazarse el origen de cada dataset hasta la fuente primaria? ¿Hay transformaciones no documentadas en el camino?
    • Revisión de acuerdos con proveedores de IA: ¿los contratos con vendors cloud o de modelos de terceros contemplan cláusulas sobre uso de datos para reentrenamiento? ¿Son consistentes con las bases legales declaradas en los registros de tratamiento?

    El framework Non-Invasive Data Governance de Bob Seiner plantea que los controles de gobernanza más efectivos son los que se integran en los procesos existentes sin crear burocracia nueva. Aplicado al contexto de IA, eso significa que el CDO no necesita un proyecto de 18 meses para responder dónde están sus datos: necesita asignar ownership de datos en los pipelines actuales y establecer una política mínima de clasificación antes de que cualquier dataset entre a un flujo de entrenamiento o inferencia.

    La ventana se está cerrando

    En Chile, el nuevo reglamento de la Ley 21.719 —que entrará en vigencia en 2026— incorpora requisitos de accountability que obligarán a las organizaciones a demostrar, no solo declarar, que tienen control sobre sus datos personales. Colombia avanza en la misma dirección con la actualización de la Ley 1581 bajo supervisión de la SIC (Superintendencia de Industria y Comercio). El patrón regional es claro: la carga de la prueba se invierte, y ya no alcanza con tener una política de privacidad publicada en el sitio web.

    Las organizaciones que lleguen a esa instancia sin un catálogo de datos operativo ni un modelo de ownership claro no tendrán un problema de compliance: tendrán un problema de negocio.

  • IA agéntica en la empresa: gobierno de datos antes de soltar las riendas

    IA agéntica en la empresa: gobierno de datos antes de soltar las riendas

    Los agentes de inteligencia artificial ya no solo responden preguntas: toman decisiones, ejecutan tareas encadenadas y operan con autonomía creciente dentro de los sistemas corporativos. Para los equipos de data governance, esto no es una promesa de eficiencia futura, es un problema de ownership y control que existe hoy.

    La adopción de arquitecturas agénticas en el mundo empresarial está acelerando a un ritmo que supera la madurez de los marcos de gobierno existentes. A diferencia de los modelos de IA conversacional, los agentes pueden acceder a bases de datos, invocar APIs, modificar registros y desencadenar flujos de trabajo sin intervención humana en cada paso. El resultado es un nuevo vector de riesgo que no encaja bien en los playbooks tradicionales de data governance ni en los controles de ciberseguridad convencionales.

    El problema de ownership que nadie quiere resolver primero

    Antes de discutir qué hace un agente, la pregunta crítica es a qué datos tiene acceso y quién responde por ese acceso. En la terminología del DAMA-DMBOK, el concepto de data stewardship —la responsabilidad operativa sobre un conjunto de datos— se vuelve especialmente relevante cuando el “consumidor” del dato es un sistema autónomo. Si un agente procesa datos de clientes para personalizar ofertas o tomar decisiones crediticias, el data steward de ese dominio debe definir explícitamente qué atributos puede consumir el agente, bajo qué condiciones y con qué registro de auditoría.

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica como capability crítica la clasificación de datos y el control de acceso basado en sensibilidad. En entornos agénticos, esta capability deja de ser un ejercicio anual de catalogación para convertirse en una guardrail operativa en tiempo real. Sin una clasificación actualizada y un catálogo de datos con data lineage trazable, no es posible saber qué está consumiendo un agente ni qué decisiones está tomando en base a qué información.

    Qué hace el CDO el lunes por la mañana

    El primer movimiento concreto es un inventario de agentes activos o en piloto. En la mayoría de las organizaciones medianas y grandes de la región, ya existe algún agente de IA en producción —muchas veces desplegado por un área de tecnología o una línea de negocio sin pasar por el proceso de data governance—. Mapear qué datos consume cada agente, con qué identidad técnica se autentica y qué logs genera es el punto de partida no negociable. Sin ese inventario, cualquier política es papel mojado.

    El segundo paso es revisar las políticas de acceso con privilegio mínimo aplicadas a identidades no humanas. Los agentes de IA deben operar con el mismo principio que una cuenta de servicio: acceso estrictamente necesario para la tarea definida, con revisión periódica. Esto implica coordinar con el equipo de IAM (Identity and Access Management) para que las identidades de agentes sean ciudadanos de primera clase en el modelo de gobernanza, no excepciones informales.

    El tercer elemento es definir un proceso de aprobación para nuevos agentes que toque datos sensibles o regulados. No alcanza con una revisión de seguridad técnica: debe incluir una evaluación de impacto en el ciclo de vida del dato, quién es el data owner del dominio afectado y qué obligaciones regulatorias están en juego.

    El contexto regulatorio LATAM no espera

    En Brasil, la LGPD (Lei Geral de Proteção de Dados) ya exige que los responsables del tratamiento puedan demostrar las bases legales de cada operación con datos personales. Cuando esa operación la ejecuta un agente autónomo, la carga de la prueba no desaparece: se traslada al proceso de diseño del sistema. La ANPD ha señalado en sus orientaciones sobre IA que la automatización de decisiones con impacto sobre titulares requiere mecanismos de explicabilidad y posibilidad de revisión humana. En Argentina, la AAIP trabaja en una actualización de la Ley 25.326 que incorporará principios similares. En México, el INAI ha emitido criterios sobre decisiones automatizadas en el marco de la LFPDPPP que obligan a informar al titular cuando una decisión significativa se toma sin intervención humana.

    Esto significa que el marco de gobierno para agentes de IA no puede diseñarse solo desde la lógica tecnológica: debe incorporar los requisitos de accountability, explicabilidad y derechos del titular desde el momento del diseño, no como parche posterior al despliegue. Privacy by design y governance by design son, en este contexto, la misma exigencia con distinto nombre.

    El riesgo de esperar a que el marco llegue solo

    La tentación organizacional es esperar a que exista un estándar consolidado —un ISO, un framework de la OCDE, una guía de la autoridad regulatoria local— antes de actuar. Ese enfoque es el que genera los incidentes que después obligan a responder en modo crisis. Los marcos de referencia como el NIST AI RMF ya ofrecen una estructura de gobernanza lo suficientemente concreta para empezar: identificar, medir, gestionar y gobernar el riesgo de sistemas de IA. Adaptarlo al contexto de agentes autónomos con acceso a datos sensibles es un trabajo que puede iniciarse hoy con los equipos existentes.

    “La gobernanza de datos no es un proyecto que se activa cuando hay un problema. Es la infraestructura que determina si el problema ocurre o no.”

    — Principio operativo, DAMA International

    La IA agéntica llegó a las empresas latinoamericanas con los mismos plazos de adopción que en cualquier otro mercado, pero con marcos regulatorios en construcción y equipos de governance todavía dimensionados para un mundo donde los datos los movían las personas.

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

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

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

    Un ataque al proveedor, un problema del retailer

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

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

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

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

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

    La responsabilidad no termina en el firewall propio

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

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

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

    Qué mirar en las próximas horas

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

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

  • CADA: la UE gira hacia la promoción de la IA y cambia las reglas del juego regulatorio

    CADA: la UE gira hacia la promoción de la IA y cambia las reglas del juego regulatorio

    La Comisión Europea presentó el Cloud and AI Development Act (CADA), una propuesta que redefine el enfoque regulatorio de la UE: ya no solo regula la inteligencia artificial, sino que la promueve activamente. El principio “AI first” queda codificado por primera vez en un instrumento legislativo europeo, y la señal que emite hacia el resto del mundo —incluida América Latina— es difícil de ignorar.

    Hasta ahora, el relato dominante sobre la UE y la IA era el de un bloque cauteloso, orientado al riesgo y dispuesto a sacrificar velocidad de adopción en nombre de la protección de derechos. El AI Act, aprobado en 2024, consolidó esa imagen. El CADA representa algo distinto: un reconocimiento explícito de que la regulación restrictiva, por sí sola, puede dejar a Europa fuera de la carrera tecnológica. La propuesta combina soberanía cloud con habilitación de IA, dos agendas que hasta ahora corrían en paralelo y que ahora convergen en un solo instrumento.

    Qué propone el CADA y por qué importa

    El Cloud and AI Development Act apunta a dos objetivos simultáneos: fortalecer la infraestructura cloud europea y crear condiciones más favorables para el desarrollo de sistemas de IA dentro del bloque. La codificación del principio “AI first” implica que, en el diseño de nuevas políticas y regulaciones, la habilitación del desarrollo de IA pasa a ser un criterio explícito de evaluación, no un efecto colateral deseable. Es un cambio de lógica: en lugar de preguntar “¿qué riesgos introduce esta tecnología?”, la pregunta ahora también incluye “¿qué barreras innecesarias estamos creando?”

    La propuesta también aborda el acceso a datos para el entrenamiento de modelos, la disponibilidad de infraestructura computacional dentro del territorio europeo y las condiciones bajo las cuales los desarrolladores —tanto grandes empresas como startups— pueden operar sin enfrentar cargas regulatorias asimétricas. Según se informó desde organismos de análisis de política tecnológica, el texto busca equilibrar la protección de derechos fundamentales ya consagrada en el AI Act con un marco que no desincentive la inversión en innovación.

    El giro estratégico detrás del texto

    El contexto importa tanto como el contenido. La UE lleva años observando cómo el liderazgo en modelos fundacionales se concentra en Estados Unidos y China. Las restricciones en el acceso a datos de entrenamiento, la fragmentación regulatoria entre Estados miembros y los costos de cumplimiento del AI Act generaron presiones crecientes de la industria tecnológica europea. El CADA es, en parte, una respuesta a esa tensión. No implica abandonar el enfoque de derechos —el GDPR y el AI Act siguen vigentes— sino añadir una capa de política industrial que la UE históricamente dejó en segundo plano cuando legisló sobre tecnología.

    “El CADA es tanto una ley de promoción y habilitación de la IA como una ley de soberanía cloud.”

    — Future of Privacy Forum, análisis del CADA, agosto 2025

    Este enfoque tiene precedentes fuera de Europa. Estados Unidos avanzó con ejecutivas y fondos de inversión en infraestructura de IA sin esperar marcos regulatorios comprehensivos. China integró la promoción de IA en sus planes quinquenales desde 2017. La novedad del CADA es que intenta hacer ambas cosas al mismo tiempo: regular y promover, dentro de un solo instrumento con base en el derecho comunitario.

    Implicancias para América Latina

    La región sigue de cerca los movimientos regulatorios europeos, y no solo por influencia académica. Brasil sancionó su Ley de IA —aprobada en 2025— con una arquitectura que bebe directamente del AI Act europeo, incluyendo la clasificación por niveles de riesgo y obligaciones diferenciadas para sistemas de alto impacto. Colombia avanza en su propio marco a través del documento CONPES 3988 y actualizaciones normativas en curso. Chile trabaja en un proyecto de ley de IA que también toma como referencia el modelo europeo. Si el CADA modifica sustancialmente la lógica del AI Act al incorporar el principio de habilitación, los marcos latinoamericanos que lo tomaron como modelo deberán evaluar si incorporan ese mismo equilibrio o si optan por mantener el sesgo regulatorio original.

    El debate es relevante para los equipos jurídicos y de cumplimiento de empresas que operan en ambos bloques. Una empresa con presencia en Brasil y en la UE que desarrolla sistemas de IA deberá navegar dos capas regulatorias que, hasta el AI Act, apuntaban en la misma dirección. Si el CADA introduce flexibilidades específicas para el desarrollo de modelos en suelo europeo, esa asimetría puede tener consecuencias prácticas en decisiones de inversión, localización de datos y estructuras de cumplimiento.

    La tensión que el CADA no resuelve

    El CADA no elimina las tensiones entre protección de datos y entrenamiento de modelos de IA. El GDPR sigue siendo la norma de referencia para el tratamiento de datos personales en la UE, y las autoridades de protección de datos —como el Comité Europeo de Protección de Datos— ya han señalado que la expansión del acceso a datos para IA debe respetar los principios de minimización y limitación de finalidad. Cómo coexistirán el principio “AI first” del CADA con esas restricciones es una pregunta que los organismos regulatorios europeos deberán resolver en los próximos meses, probablemente a través de guías y decisiones de supervisión que tendrán impacto directo en la industria global.

    El CADA puede ser el inicio de una reconfiguración profunda del modelo regulatorio europeo: si la UE logra combinar habilitación y protección de derechos sin sacrificar ninguno de los dos, habrá construido el manual que América Latina todavía está buscando.

  • Ransomware a Oldelval: la gobernanza que le falta a Vaca Muerta

    Ransomware a Oldelval: la gobernanza que le falta a Vaca Muerta

    Oldelval, que transporta el 75% del crudo de Vaca Muerta por más de 1.700 km de oleoductos, confirmó un ataque de ransomware. El mismo grupo —The Gentlemen— había vulnerado a EcoPetrol en Colombia una semana antes. El transporte no se interrumpió, pero el patrón regional expone un vacío: ningún país de la región tiene un marco de ciberseguridad para infraestructura energética.

    Qué pasó: ransomware en el corazón del sistema petrolero argentino

    Oleoductos del Valle (Oldelval) informó a la Comisión Nacional de Valores (CNV) de Argentina un incidente de ciberseguridad en sus sistemas administrativos, clasificado como un ataque de ransomware del tipo RaaS (Ransomware as a Service). El ataque fue reivindicado por un grupo que se presenta como The Gentlemen, el mismo que una semana antes había comprometido sistemas de EcoPetrol en Colombia, donde accedió a datos de unas 3.300 cuentas de usuarios y de 15 empresas vinculadas alojadas en servicios de nube.

    Oldelval opera la red principal de transporte de petróleo de Argentina: más de 1.700 kilómetros de oleoductos que conectan los yacimientos de la cuenca neuquina con las terminales de exportación de Puerto Rosales y Punta Colorada, en Bahía Blanca. Por sus ductos circula aproximadamente el 75% del crudo de Vaca Muerta, según la información reportada por la propia compañía a la CNV. Entre sus clientes figuran YPF (accionista principal con el 37% del paquete accionario), Vista Energy, Pan American Energy, Chevron, Shell, Tecpetrol, Pluspetrol, Pampa Energía y TotalEnergies.

    La empresa aseguró que el incidente está “100% controlado”, que el transporte de crudo no sufrió interrupciones y que los sistemas administrativos fueron restaurados. No detalló el vector de ataque ni confirmó si hubo exfiltración de datos o demanda de rescate. Oldelval indicó que avanza con las presentaciones ante las “autoridades competentes”, sin precisar cuáles.

    Contexto regulatorio: Argentina no tiene ley de ciberseguridad para infraestructura crítica

    Argentina carece de una ley integral de ciberseguridad para infraestructura crítica. La Decisión Administrativa 641/2021 creó el Comité de Ciberseguridad y definió lineamientos para el sector público, pero su alcance sobre operadores privados de infraestructura crítica energética es limitado. La Ley 26.388 de Delitos Informáticos (2008) tipifica conductas pero no establece obligaciones de protección, notificación de incidentes ni estándares mínimos de seguridad para operadores de infraestructura esencial.

    El ataque ocurre en un momento de expansión acelerada. El proyecto Duplicar Norte —un oleoducto de 207 kilómetros adjudicado a Techint— comenzará operaciones parciales a fines de 2026, con habilitación plena en el primer trimestre de 2027, según la información publicada por Infobae. En diciembre de 2024, Techint completó anticipadamente el módulo Duplicar Plus de 254 kilómetros. Cuando toda la red esté integrada con el sistema Vaca Muerta Sur, canalizará cerca del 80% de la producción regional hacia puertos de exportación.

    Mientras tanto, el proyecto de reforma de la Ley de Protección de Datos Personales (expediente 1751-D-2026, según la IAPP) se encuentra en el Congreso con provisiones sobre decisiones automatizadas y entornos de prueba regulatorios, pero no aborda específicamente la protección de infraestructura crítica.

    Por qué importa: gobernanza de datos en infraestructura energética

    El caso Oldelval no es solo un incidente de ciberseguridad: es un problema de gobernanza de datos en infraestructura crítica. Cuando un operador que transporta el 75% del crudo de la formación de esquisto no convencional más importante de América Latina sufre un ataque de ransomware, las preguntas relevantes no son solo técnicas (qué cortafuegos falló, qué dispositivo quedó expuesto) sino de gobernanza: ¿quién define los estándares de protección de datos operacionales en el sector energético? ¿Qué autoridad supervisa? ¿Qué obligación de notificación existe, más allá de la comunicación voluntaria a la CNV por ser una empresa con obligaciones de reporte bursátil?

    El patrón regional lo agrava. Que el mismo grupo ataque a EcoPetrol en Colombia y a Oldelval en Argentina en un lapso de dos semanas sugiere una campaña coordinada contra infraestructura energética latinoamericana — no incidentes aislados.

    Marco legal comparado: cómo protegen (o no) la infraestructura crítica en la región

    Brasil

    Brasil es el país con el marco más avanzado de la región en esta materia. La Autoridade Nacional de Proteção de Dados (ANPD) publicó en julio de 2026 los primeros resultados de su entorno de prueba regulatorio de inteligencia artificial, en el que monitorea a tres empresas que desarrollan soluciones de IA, identificando desafíos en “gobernanza, seguridad, transparencia y protección de datos”, según la IAPP. La ANPD también contrató especialistas para producir cinco estudios técnicos sobre temas que incluyen patrones oscuros, agentes de IA y tratamiento de datos en plataformas de envío a domicilio. Además, Brasil cuenta con la Ley General de Protección de Datos (Ley 13.709/2018, LGPD) con la ANPD como autoridad de control con capacidad sancionatoria, y el Decreto 10.748/2021 que instituyó la Red Federal de Gestión de Incidentes Cibernéticos para el sector público.

    Chile

    Chile se prepara para la entrada en vigencia de la Ley 21.719 de Protección de Datos Personales el 1 de diciembre de 2026, que modifica integralmente la ley de 1999 y crea la Agencia de Protección de Datos Personales. Sin embargo, a agosto de 2026 la autoridad aún no ha sido designada: dos listas de candidatos fallaron y no se anunciaron nuevas nominaciones. El gobierno publicó lineamientos para que los organismos públicos designen coordinadores institucionales y desarrollen políticas internas, pero la implementación para el sector privado — incluidos operadores de infraestructura crítica — permanece indefinida hasta que la agencia esté operativa. Chile también cuenta con la Ley 21.663 Marco de Ciberseguridad (2024), una de las más completas de la región, que establece obligaciones para operadores de infraestructura crítica de la información.

    Colombia

    Colombia actualizó su Modelo de Seguridad y Privacidad de la Información para incorporar lineamientos específicos sobre inteligencia artificial para entidades públicas, con medidas “técnicas, organizacionales y regulatorias” para gestionar riesgos de IA y proteger datos personales, según la IAPP. No obstante, el ataque a EcoPetrol — donde el grupo The Gentlemen accedió a datos de 3.300 cuentas de usuarios de 15 empresas afiliadas, según Infobae— demuestra que el modelo no ha prevenido compromisos significativos en el sector energético. Colombia tiene la Ley 1581 de 2012 de Protección de Datos Personales y la Superintendencia de Industria y Comercio (SIC) como autoridad, pero carece de regulación específica de ciberseguridad para infraestructura energética comparable a la Directiva (UE) 2022/2555 sobre seguridad de las redes y sistemas de información (NIS2).

    México

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (2010) y la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (2017). El país tiene un antecedente directo: Petróleos Mexicanos (Pemex) sufrió un ataque de ransomware en noviembre de 2019, atribuido al grupo DoppelPaymer, que afectó operaciones administrativas en múltiples instalaciones. Al igual que en el caso de Oldelval, no hubo interrupción de la producción. No hay legislación específica de protección de infraestructura crítica energética contra ciberataques.

    Qué hacer: acciones concretas según el rol

    Si sos delegado de protección de datos (DPO, por sus siglas en inglés) o responsable de datos en el sector energético: Verificar que los protocolos de respuesta a incidentes incluyan no solo la restauración operativa sino la evaluación de datos personales comprometidos (empleados, contratistas, proveedores), con los plazos de notificación que exija la jurisdicción aplicable.

    Si sos director de seguridad de la información (CISO, por sus siglas en inglés) o responsable de seguridad: Evaluar la exposición de los sistemas administrativos como vector de entrada. El hecho de que Oldelval haya separado exitosamente los sistemas operacionales —sistemas de control de supervisión y adquisición de datos (SCADA) y sistemas de control industrial (ICS)— de los administrativos es una señal positiva de segmentación, pero no elimina el riesgo de exfiltración de datos corporativos sensibles: contratos, información financiera, datos de clientes como YPF, Shell o Chevron.

    Si sos regulador o legislador: El patrón regional de The Gentlemen (Colombia y Argentina en dos semanas) justifica un tratamiento coordinado. Revisar si la legislación vigente obliga a operadores de infraestructura crítica a reportar incidentes de ciberseguridad, implementar estándares mínimos y someterse a auditorías periódicas.

    Qué monitorear: Si Oldelval revela exfiltración de datos en los próximos días, las implicancias regulatorias se amplían significativamente — especialmente si los datos comprometidos incluyen información comercial de las petroleras que son sus clientes. También monitorear si The Gentlemen publica datos en sitios de filtración como ha hecho con otras víctimas.

    Nuestro análisis

    El caso Oldelval confirma una asimetría que venimos señalando: la infraestructura energética latinoamericana se expande a ritmo acelerado — Argentina proyecta exportaciones de crudo por hasta 8.000 millones de dólares anuales — pero la gobernanza de datos y la regulación de ciberseguridad que debería acompañar esa expansión avanzan a un ritmo incompatible.

    El precedente de Colonial Pipeline en 2021 — un ataque de ransomware que paralizó el suministro de combustible en la costa este de Estados Unidos durante una semana y derivó en el pago de 75 bitcoines en concepto de rescate (aproximadamente 4,3 millones de dólares en ese momento, de los cuales el FBI recuperó 2,3 millones), según Infobae — debería haber sido suficiente para que los países productores de la región legislaran sobre protección de infraestructura crítica energética. Cinco años después, ningún país de América Latina tiene un marco equivalente a la Directiva (UE) 2022/2555 sobre seguridad de las redes y sistemas de información (NIS2), que desde octubre de 2024 obliga a los operadores de infraestructura esencial a implementar medidas de gestión de riesgos de ciberseguridad, reportar incidentes en plazos definidos y someterse a supervisión activa.

    Que Oldelval haya podido mantener el transporte de crudo operativo es un dato positivo — sugiere que la segmentación entre redes de tecnología operacional (OT) y de tecnología de la información (IT) funcionó. Pero la pregunta no es si esta vez se evitó el peor escenario, sino qué pasa cuando la próxima no funcione. Con una red que se duplica en capacidad y un volumen de exportación que se multiplica, el costo de un incidente que sí afecte el transporte de crudo ya no se mide en datos comprometidos: se mide en barriles que no llegan al puerto, contratos internacionales incumplidos y un golpe a la credibilidad de Argentina como proveedor energético confiable.

    La gobernanza de datos en infraestructura crítica no es un problema de IT: es un problema de política pública.

    Preguntas frecuentes

    ¿Se interrumpió el transporte de petróleo por el ataque a Oldelval?

    No. Oldelval confirmó que el transporte de crudo no sufrió interrupciones y que el incidente afectó únicamente los sistemas administrativos. La compañía declaró que el ataque está “100% controlado”.

    ¿Qué es The Gentlemen y por qué atacan infraestructura energética en LATAM?

    The Gentlemen es un grupo que opera bajo el modelo de Ransomware as a Service (RaaS). Reivindicó ataques contra EcoPetrol en Colombia y Oldelval en Argentina en un lapso de dos semanas. La hipótesis más fuerte apunta a atacantes extranjeros, aunque no se descartan actores locales.

    ¿Argentina tiene una ley de ciberseguridad para infraestructura crítica?

    No. Argentina no cuenta con una ley integral de ciberseguridad que establezca obligaciones específicas para operadores de infraestructura crítica privados. La Decisión Administrativa 641/2021 cubre lineamientos para el sector público, y la Ley 26.388 tipifica delitos informáticos pero no impone estándares de protección.

    Fuente principal: Infobae, “La operadora del oleoducto por el que circula el 75% del petróleo de Vaca Muerta sufrió un ciberataque en sus sistemas”, 2 de agosto de 2026 (https://www.infobae.com/economia/2026/08/02/la-operadora-del-oleoducto-por-el-que-circula-el-75-del-petroleo-de-vaca-muerta-sufrio-un-ciberataque-en-sus-sistemas/). Contexto regulatorio regional: IAPP, “Notas de la IAPP América Latina: Avances en la implementación de normas sobre IA y protección de datos”, agosto de 2026.

  • IA en las aulas sin gobierno de datos: la trampa que LATAM ya está repitiendo

    IA en las aulas sin gobierno de datos: la trampa que LATAM ya está repitiendo

    Un think tank de Hong Kong encendió una alerta que resuena mucho más allá de Asia: el uso de inteligencia artificial en las escuelas crece de forma desorganizada y sin un marco de gobierno de datos que lo sostenga. La fragmentación —distintas herramientas, distintos proveedores, sin ownership claro del dato educativo— es exactamente el patrón que se observa hoy en los sistemas educativos de América Latina.

    Según se informó a principios de agosto, el think tank hongkonés planteó que la proliferación de aplicaciones de IA en el entorno escolar genera silos de datos estudiantiles que ninguna autoridad central puede auditar, clasificar ni controlar. La recomendación fue directa: antes de escalar el uso de IA, los sistemas educativos necesitan una política unificada de gobierno de datos que defina quién es el data owner, qué datos se recopilan, con qué propósito y por cuánto tiempo. Sin esas respuestas, la promesa pedagógica de la IA se convierte en un pasivo de privacidad y un riesgo de cumplimiento.

    El problema no es la IA, es la ausencia de estructura

    La discusión de fondo no gira en torno a si las herramientas de IA son buenas o malas para el aprendizaje. El núcleo del problema es estructural: cuando cada docente, cada institución o cada distrito adopta soluciones por cuenta propia, el resultado es un ecosistema donde los datos de niños y adolescentes viajan hacia proveedores externos sin políticas de retención definidas, sin clasificación de sensibilidad y sin un data steward —responsable de custodia del dato— que responda ante una auditoría. En términos del DAMA-DMBOK, el área de conocimiento de Data Security y la de Data Lifecycle Management son las primeras víctimas de esta ausencia de gobierno.

    El fenómeno tiene nombre en la literatura especializada: shadow AI aplicada al sector público. Cuando la adopción tecnológica supera la capacidad de gobernanza institucional, los datos más sensibles —los de menores— quedan en el peor lugar posible: fuera del perímetro de control, pero dentro del alcance regulatorio.

    LATAM: el mismo patrón, marcos regulatorios distintos

    En América Latina, el problema se replica con particularidades locales que agravan el riesgo. Brasil, bajo la Lei Geral de Proteção de Dados (LGPD), establece que el tratamiento de datos de niños y adolescentes requiere consentimiento específico de los padres o tutores y que el interés superior del menor es el principio rector. Sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) aún no ha emitido una regulación sectorial específica para el ámbito educativo, lo que deja un vacío que las edtech están aprovechando. En Argentina, la Ley 25.326 de Protección de Datos Personales no contempla explícitamente la categoría de “dato educativo sensible generado por IA”, y la AAIP no ha publicado lineamientos para ese escenario. México presenta un cuadro similar: la LFPDPPP y su reglamento no fueron diseñados para la velocidad de adopción de IA generativa en aulas públicas.

    Colombia, en cambio, ofrece un antecedente interesante. La Superintendencia de Industria y Comercio (SIC) ha sido más activa en la emisión de conceptos sobre tratamiento de datos de menores, y el país avanza en un marco de ética e IA que podría incluir disposiciones para el sector educativo. Chile, con su Ley Marco de Ciberseguridad ya promulgada y la reforma a la Ley 19.628 en curso, está construyendo una arquitectura regulatoria que los responsables de datos en colegios deberán conocer antes de firmar cualquier contrato con un proveedor de IA.

    Qué hace un CDO educativo el lunes

    Para los responsables de datos en ministerios de educación, secretarías distritales o redes de colegios privados, el caso de Hong Kong ofrece un checklist de arranque concreto. Antes de autorizar cualquier nueva herramienta de IA en el aula, el área de gobierno de datos debería poder responder afirmativamente a estas preguntas:

    • ¿Existe un inventario actualizado de todos los sistemas que procesan datos de estudiantes menores de edad, incluyendo las herramientas adoptadas de forma informal por docentes?
    • ¿Cada conjunto de datos tiene un data owner designado con responsabilidad formal y un data steward operativo que lo custodie?
    • ¿Los contratos con proveedores de IA incluyen cláusulas de retención, eliminación y prohibición de uso secundario de datos estudiantiles alineadas con la normativa local?
    • ¿Existe un proceso de Data Protection Impact Assessment (DPIA) obligatorio antes de incorporar cualquier sistema de IA que procese datos de menores?

    Si alguna de esas respuestas es “no” o “no lo sé”, el riesgo regulatorio ya existe. El marco CDMC del EDM Council identifica la capacidad de “gestión de riesgos del dato” (capability 8) como prerequisito para cualquier iniciativa de IA a escala. Aplicado al sector educativo público latinoamericano, eso significa que la conversación de governance debe ocurrir antes —no después— de la compra de licencias.

    El dato del menor, el más difícil de recuperar

    Hay una asimetría que suele ignorarse en la discusión sobre IA educativa: un adulto puede revocar su consentimiento, cambiar de proveedor y migrar sus datos. Un estudiante de diez años cuyos patrones de aprendizaje, comportamiento y rendimiento fueron ingeridos por un modelo de IA durante tres años escolares no tiene esa opción práctica. El dato ya fue usado para entrenar; el modelo ya aprendió. La ventana de corrección en datos de menores es angosta, y eso eleva la exigencia de governance desde el primer día.

    La pregunta que los ministerios de educación de la región deberían hacerse no es cuánta IA incorporar, sino si tienen la estructura de gobierno de datos suficiente para que esa IA no les genere el próximo escándalo de privacidad infantil.

  • Gobernanza de datos geoespaciales: el debate que irrumpe en LATAM

    Gobernanza de datos geoespaciales: el debate que irrumpe en LATAM

    La gobernanza de datos geoespaciales se instaló como tema central en la São Paulo Climate Week, en un debate organizado por la Fundação Getulio Vargas (FGV). El evento puso de relieve una brecha estructural que pocas organizaciones de la región abordan formalmente: los datos de localización, cobertura terrestre y movilidad climática carecen, en la mayoría de los casos, de ownership definido, linaje documentado y políticas de calidad aplicables a su ciclo de vida completo.

    El encuentro reunió a referentes del sector público, academia y organizaciones de la sociedad civil para discutir cómo los datos geoespaciales —imágenes satelitales, registros de sensores remotos, capas de información territorial— se producen en volúmenes crecientes pero se gestionan con marcos de gobernanza rudimentarios o directamente inexistentes. La paradoja es conocida en la industria: cuanto más sofisticada la fuente del dato, más informal suele ser su administración interna.

    El problema de fondo: datos sin dueño

    En el lenguaje del DAMA-DMBOK, los datos geoespaciales representan un dominio de alta complejidad técnica con bajo nivel de madurez en stewardship —es decir, en la figura del data steward responsable de definir estándares, validar calidad y gestionar el acceso. A diferencia de los datos transaccionales o de clientes, los datasets geoespaciales suelen ser producidos por equipos de ingeniería o ciencia de datos sin una cadena clara de accountability hacia el negocio o la política pública. El resultado es que el dato existe, pero nadie puede responder con certeza de dónde viene, qué transformaciones sufrió ni si es apto para tomar decisiones de política climática.

    El modelo de madurez DCAM (Data Management Capability Assessment Model) del EDM Council ubica la gestión de datos geoespaciales en las capabilities asociadas a data quality y data lineage. En organizaciones que trabajan con este tipo de activos —agencias ambientales, ministerios de infraestructura, fondos de inversión con criterios ESG— la ausencia de linaje documentado es un riesgo operativo y reputacional concreto, no un problema abstracto de arquitectura.

    El contexto regulatorio presiona desde varios frentes

    Brasil no es el único país de la región donde este debate se vuelve urgente. La Lei Geral de Proteção de Dados (LGPD) ya planteó, desde 2020, que los datos de geolocalización pueden constituir datos personales cuando permiten identificar o inferir el comportamiento de individuos. Eso significa que un dataset de movilidad poblacional usado para modelado climático puede, simultáneamente, estar sujeto a controles de gobernanza corporativa y a obligaciones de privacidad ante la Autoridade Nacional de Proteção de Dados (ANPD). La intersección entre ambos marcos es territorio que pocas organizaciones brasileñas tienen mapeado formalmente.

    En Argentina, la Ley 25.326 de Protección de Datos Personales y su autoridad de aplicación, la AAIP, también contemplan la geolocalización como dato sensible cuando se combina con perfiles de comportamiento. Mientras tanto, el Instituto Nacional de Estadística e Informática (INEI) de Perú y el DANE de Colombia gestionan enormes volúmenes de datos geoespaciales censales con marcos de gobernanza que, según referentes del sector, todavía operan por debajo de los estándares que exigiría una auditoría bajo ISO/IEC 38505 —el estándar internacional de gobernanza de datos para órganos directivos.

    Qué puede hacer un CDO el lunes

    Para un Chief Data Officer o Data Governance Manager cuya organización usa datos geoespaciales —aunque sea de forma periférica—, el debate de São Paulo ofrece una señal de acción concreta. El primer paso es inventariar qué datasets geoespaciales existen en la organización, quién los produjo, con qué frecuencia se actualizan y si tienen un data steward formalmente asignado. En la mayoría de los casos, ese inventario no existe o está desactualizado. Herramientas de data catalog con soporte para metadatos geoespaciales —como OpenMetadata o Collibra con conectores GIS— permiten iniciar ese relevamiento sin necesidad de un proyecto de transformación de largo plazo.

    El segundo movimiento es evaluar si alguno de esos datasets cruza el umbral de dato personal bajo la regulación local aplicable. Si la organización opera en Brasil, la respuesta en muchos casos será afirmativa, lo que implica coordinar con el DPO (Data Protection Officer) para definir la base legal del tratamiento y documentar la evaluación de impacto correspondiente. No hacerlo es dejar un flanco abierto ante la ANPD en un contexto en que el regulador brasileño ha escalado su actividad de supervisión en los últimos doce meses.

    Una ventana que no estará abierta siempre

    El hecho de que la FGV lleve este debate a un evento de agenda climática internacional no es accidental. Los compromisos de descarbonización, reporte ESG y transparencia territorial que asumen gobiernos y empresas de la región dependen, en última instancia, de la calidad y trazabilidad de los datos geoespaciales que los sustentan. Si esos datos no tienen gobernanza, los compromisos tampoco la tienen.

    La gobernanza de datos geoespaciales dejó de ser un nicho técnico: es la infraestructura invisible de la agenda climática en América Latina, y su ausencia tiene costos medibles.

  • Governance sin control: el modelo de capacidades que está redefiniendo el rol del CDO

    Governance sin control: el modelo de capacidades que está redefiniendo el rol del CDO

    Un número creciente de organizaciones está abandonando el enfoque policial del gobierno de datos —basado en restricciones, aprobaciones y comités de control— para adoptar un modelo orientado a capacidades: habilitar a los equipos para trabajar con datos de forma autónoma, con calidad y con contexto. El programa de data governance de York University en Canadá es uno de los casos más citados recientemente como referencia de este cambio de paradigma, y sus principios tienen aplicación directa para los CDOs de la región.

    Durante años, el gobierno de datos fue sinónimo de fricción. Políticas que nadie leía, flujos de aprobación que demoraban semanas, y equipos de negocio que terminaban creando sus propias sombras de datos para esquivar los procesos formales. El resultado fue paradójico: más governance en el papel, menos calidad real en la práctica. El enfoque de York University invierte esa lógica: en lugar de preguntar “¿quién tiene permiso para tocar este dato?”, pregunta “¿qué capacidad necesita este equipo para usarlo bien?”

    Capabilities primero: qué significa en la práctica

    El modelo de capacidades en data governance no es nuevo en la teoría —el DAMA-DMBOK lo contempla dentro de su área de Data Governance como habilitador de las demás disciplinas—, pero su adopción práctica ha sido lenta. La diferencia clave está en el punto de partida: en lugar de construir una estructura de control y luego intentar que el negocio la adopte, se identifican primero las decisiones que los equipos necesitan tomar con datos, y se construye el andamiaje de governance para habilitarlas. Esto incluye definir data ownership operativo (no nominal), instrumentar data lineage —la trazabilidad del origen, transformación y uso de un dato— y asegurar que los data stewards, los custodios funcionales del dato en cada dominio, tengan herramientas reales y no solo responsabilidades en papel.

    Bob Seiner, referente del enfoque Non-Invasive Data Governance, ha argumentado consistentemente que la resistencia al gobierno de datos no es cultural sino de diseño: cuando governance se percibe como burocracia adicional, fracasa. Cuando se percibe como soporte para hacer el trabajo mejor, se adopta. El caso de York ilustra exactamente eso: los equipos de datos comenzaron a comprometerse con el programa cuando vieron que les resolvía problemas concretos —como saber quién es el dueño de una definición de negocio o cómo rastrear por qué un reporte y otro arrojan cifras distintas.

    El lunes a la mañana: qué hace un CDO con esto

    El modelo de capacidades exige una revisión honesta del estado actual del programa de governance. Una forma concreta de empezar es mapear las decisiones de datos más frecuentes en los dominios críticos —finanzas, clientes, operaciones— e identificar dónde el proceso actual agrega latencia sin agregar valor. Si un equipo de analítica tarda más en obtener acceso a un dataset que en analizarlo, hay un problema de diseño, no de cultura. Los indicadores a revisar incluyen: tiempo promedio de resolución de un data issue, cobertura de data ownership documentado sobre activos críticos, y porcentaje de datasets con lineage instrumentado en el catálogo.

    • Auditar qué porcentaje de los data stewards designados tienen capacidad real de decisión sobre sus dominios versus un rol meramente formal.
    • Revisar si el catálogo de datos corporativo es consultado activamente o solo se actualiza para cumplir con auditorías internas.
    • Identificar los tres flujos de aprobación de datos con mayor tiempo de ciclo y evaluar si pueden rediseñarse como habilitación en lugar de control.
    • Alinear el roadmap de governance con los OKRs de las áreas de negocio, no con los del equipo de TI.

    El contexto LATAM: entre el compliance y la madurez

    En América Latina, el gobierno de datos enfrenta una tensión adicional: muchos programas nacieron como respuesta a requisitos regulatorios —la Resolución 4793 de la Superintendencia Financiera de Colombia, la Comunicación A 8073 del BCRA en Argentina, o las exigencias de la LGPD en Brasil para mapeo de datos personales— y quedaron atrapados en una lógica de compliance reactivo. Eso es governance para el regulador, no governance para el negocio. El riesgo es construir capacidades de reporte hacia afuera mientras los equipos internos siguen operando con hojas de cálculo sin linaje y definiciones de negocio inconsistentes entre áreas.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), ofrece un camino para cerrar esa brecha: sus 14 capabilities permiten evaluar el nivel de madurez de forma objetiva y priorizar inversiones. Varios bancos de la región ya operan con prácticas equivalentes a las capabilities 7 y 8 del CDMC —gestión de calidad y clasificación de datos— impulsados por exigencias regulatorias, pero sin la certificación formal ni la articulación de un programa cohesivo. Formalizar eso es, precisamente, el tipo de quick win que un CDO puede mostrar en el corto plazo.

    El riesgo de confundir madurez con complejidad

    Uno de los errores más comunes al escalar un programa de governance es agregar capas de proceso bajo la suposición de que más estructura equivale a más madurez. El modelo de capacidades invierte esa ecuación: mide la madurez por el impacto habilitado, no por la cantidad de políticas aprobadas o comités activos. Un programa con tres políticas claras, data ownership real y un catálogo activo genera más valor que uno con veinte políticas que nadie aplica. La pregunta que debería guiar cada decisión de diseño es simple: ¿esto le facilita o le complica la vida al equipo que trabaja con el dato?

    El governance que no habilita termina siendo eludido — y los datos que no tienen dueño real no tienen calidad real.

  • Construir un navegador no es un delito informático: el fallo que redefine el CFAA

    Construir un navegador no es un delito informático: el fallo que redefine el CFAA

    El Noveno Circuito de Apelaciones de Estados Unidos rechazó la demanda de Amazon contra Perplexity AI y estableció que desarrollar un navegador con funciones de agente de IA no viola la Computer Fraud and Abuse Act (CFAA), siempre que sea el usuario quien ejecuta el acceso. El fallo tiene implicancias directas para el debate sobre responsabilidad de sistemas de IA en América Latina, donde reguladores y legisladores aún definen quién responde cuando un agente automatizado actúa en nombre de una persona.

    El caso surgió cuando Amazon demandó a Perplexity AI por su navegador Comet, que incluye un asistente de IA agentic —capaz de navegar sitios web de forma autónoma para comparar precios— y que, según Amazon, accedía a cuentas de usuarios de su plataforma sin autorización. La compañía argumentó que eso constituía acceso no autorizado bajo la CFAA, una ley federal de 1986 pensada originalmente para perseguir intrusiones informáticas, pero que con frecuencia ha sido invocada por grandes corporaciones para bloquear a competidores más pequeños.

    El argumento técnico que convenció al tribunal

    La Electronic Frontier Foundation (EFF) presentó un escrito amicus curiae en el que explicó al tribunal la arquitectura real del sistema: no es Perplexity quien accede a los servidores de Amazon, sino el usuario que opera el navegador. El Noveno Circuito adoptó esa lectura y, según se informó, destacó expresamente que la explicación de EFF “articula la naturaleza del sistema con mayor claridad”. El fallo concluye que el asistente de IA “es una herramienta, no una persona a efectos del estatuto”, y que esa herramienta es operada por el usuario, no por la empresa que la desarrolló.

    El tribunal también reconoció que la IA agentic plantea preguntas legales nuevas y que existe “escasa o nula jurisprudencia” sobre cómo atribuir responsabilidad a agentes de IA bajo el CFAA. Aun así, evitó pronunciarse sobre esas cuestiones más complejas: en este caso bastó con determinar que el control sobre el acceso residía en el usuario. Amazon podría tener otras acciones legales disponibles, señaló el tribunal, pero usar el CFAA era “legalmente infundado” y una mala política pública que podría exponer a los propios usuarios a responsabilidad penal.

    El patrón que el fallo intenta frenar

    La EFF subrayó que este tipo de litigios no es una anomalía: las grandes plataformas han utilizado el CFAA sistemáticamente para presionar a desarrolladores independientes que crean herramientas de acceso alternativas a sus servicios. El fallo del Noveno Circuito no solo beneficia a Perplexity, sino que sienta un precedente relevante para cualquier equipo que construya navegadores, scrapers, automatizaciones o agentes de IA que interactúen con plataformas de terceros. La distinción entre “el desarrollador accede” versus “el usuario accede mediante la herramienta” ahora cuenta con respaldo judicial explícito en una jurisdicción de alta influencia.

    Qué significa esto para la región

    En América Latina, la discusión sobre responsabilidad de agentes de IA todavía es incipiente. Brasil avanza con el PL 2338/2023 —su proyecto de ley de inteligencia artificial— que contempla criterios de atribución de responsabilidad para sistemas automatizados, aunque sin definir aún con precisión el rol del operador frente al desarrollador. México, por su parte, carece de un marco específico para IA, y la LFPDPPP no fue diseñada para resolver quién responde cuando un agente actúa sobre datos de un tercero. Argentina se encuentra en una situación similar: la Ley 25.326 establece obligaciones para quienes tratan datos personales, pero el escenario de un agente de IA que accede a información por instrucción del propio titular del dato abre preguntas que la norma no responde.

    El razonamiento del Noveno Circuito —centrado en quién ejerce el control efectivo sobre el acceso— puede ser una referencia útil para legisladores y autoridades de la región cuando tengan que resolver casos análogos. La distinción no es trivial: si el agente de IA es tratado como actor independiente, la cadena de responsabilidad se extiende al desarrollador; si se lo trata como herramienta del usuario, la responsabilidad primaria recae en quien lo activa. Esa diferencia puede determinar si un startup de automatización enfrenta o no una demanda millonaria.

    El lunes en la práctica

    Para equipos legales y de producto que trabajan con agentes de IA en LATAM, el fallo sugiere al menos tres acciones concretas: revisar los términos de servicio de las plataformas con las que sus agentes interactúan para identificar cláusulas de acceso que puedan ser invocadas como fundamento de una demanda; documentar con claridad en el diseño del sistema quién inicia y controla cada sesión de acceso; y comenzar a monitorear cómo los proyectos de ley de IA en Brasil, Colombia y Chile abordan la atribución de responsabilidad en cadenas humano-agente. La jurisprudencia estadounidense no es vinculante en la región, pero históricamente ha influido en la redacción de marcos normativos locales.

    Cuando las grandes plataformas usan el derecho como escudo competitivo, la claridad técnica se vuelve el argumento más poderoso — y los reguladores latinoamericanos deberían tomar nota antes de que el debate llegue a sus propios tribunales.

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

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

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

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

    El mecanismo: consentimiento aparente, transferencia real

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

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

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

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

    Qué implica esto para LATAM

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

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

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

    El desarrollador también es responsable

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

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

    Reguladores bajo presión

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

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