DataTrends LATAM

Etiqueta: Ai Privacy

  • AI Act europeo expone las brechas de gobernanza que los equipos de datos ignoraron

    AI Act europeo expone las brechas de gobernanza que los equipos de datos ignoraron

    El Reglamento de Inteligencia Artificial de la Unión Europea —conocido como AI Act— está revelando una verdad incómoda para los equipos de datos globales: los marcos de gobernanza que funcionaban para cumplir con GDPR o ISO 27001 no son suficientes para gestionar sistemas de IA de alto riesgo. Las brechas no son tecnológicas; son estructurales. Y las empresas latinoamericanas que exportan servicios o datos a Europa, o que simplemente modelan sus marcos locales sobre estándares europeos, deberían leer esto como una advertencia temprana.

    El AI Act, en vigor desde agosto de 2024 con plazos de cumplimiento escalonados hasta 2026, clasifica los sistemas de IA según su nivel de riesgo. Los sistemas de alto riesgo —que incluyen herramientas de selección de personal, scoring crediticio, evaluación educativa y gestión de infraestructura crítica— deben cumplir con requisitos específicos de documentación, trazabilidad, supervisión humana y calidad de datos de entrenamiento. Ahí es exactamente donde los equipos de datos están fallando.

    Las cuatro brechas que el AI Act vuelve inocultables

    La primera brecha es de linaje de datos (data lineage). El artículo 10 del AI Act exige que los conjuntos de datos utilizados para entrenar sistemas de alto riesgo sean “relevantes, representativos, libres de errores en la medida de lo posible y completos”. Para demostrar eso ante un auditor, se necesita linaje de punta a punta: saber de dónde vino cada registro, cómo fue transformado y quién autorizó su uso. La mayoría de los data warehouses corporativos no tienen ese nivel de trazabilidad documentado, y muchos equipos confunden el linaje técnico —el que registra una herramienta de ETL— con el linaje semántico que exige un marco regulatorio.

    La segunda brecha es de ownership. En DAMA-DMBOK, el concepto de data steward —el responsable de un dominio de datos con accountability formal sobre su calidad y uso— es central. Sin embargo, en la mayoría de las organizaciones, la pregunta “¿quién es el steward del dataset de entrenamiento del modelo de scoring?” genera silencio. El AI Act asume que alguien puede responder esa pregunta bajo presión regulatoria. Si no existe esa persona o ese rol está vacante, el incumplimiento es casi automático.

    La tercera brecha es de documentación de modelos. El AI Act requiere que los sistemas de IA de alto riesgo cuenten con documentación técnica actualizada antes de su despliegue (Anexo IV). Esto incluye descripción del propósito del sistema, métricas de rendimiento, datos de entrenamiento y limitaciones conocidas. Muchos equipos de datos tienen esa información dispersa entre notebooks de Jupyter, wikis internas desactualizadas y correos electrónicos. No existe nada equivalente a un “model card” formal y auditado.

    La cuarta brecha —quizás la más difícil de resolver— es de gobernanza de sesgos. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica la gestión de calidad como una capability central. Pero la calidad estadística de un dataset no es equivalente a su equidad representacional. Un modelo puede entrenarse con datos técnicamente “limpios” que, sin embargo, subrepresentan a determinados grupos demográficos. Detectar y documentar eso requiere capacidades que van más allá del data quality tradicional y que pocos equipos tienen institucionalizadas.

    Por qué el AI Act obliga a repensar el rol del CDO en Europa y en la región

    El cumplimiento del AI Act no puede delegarse al equipo legal ni al equipo de machine learning por separado. Requiere que el Chief Data Officer opere como un articulador entre tres frentes: el catálogo de datos (¿qué datos existen y quién los gobierna?), el ciclo de vida del modelo (¿cómo se documentan las decisiones de entrenamiento?) y el marco de supervisión humana (¿qué controles existen para revisar las salidas del sistema?). Esto implica, en la práctica, elevar el nivel de madurez de gobernanza de datos de toda la organización, no solo del equipo de IA.

    Para un CDO que opera bajo este marco, la pregunta concreta esta semana es: ¿cuántos de los sistemas de IA en producción en mi organización podrían clasificar como alto riesgo bajo el AI Act? Si la respuesta es “no lo sé”, el primer paso es realizar un inventario de sistemas con su clasificación de riesgo tentativa. Ese inventario es, además, el insumo mínimo que cualquier auditor europeo solicitaría en una inspección. Herramientas como los frameworks de Microsoft Responsible AI o las guías del NIST AI RMF (AI Risk Management Framework) ofrecen taxonomías usables para ese ejercicio.

    Argentina, Brasil y México: tres marcos locales, tres niveles de exposición distintos

    En Argentina, la Agencia de Acceso a la Información Pública (AAIP) publicó en 2023 sus lineamientos de inteligencia artificial y protección de datos personales, que incorporan principios de no discriminación algorítmica y transparencia. Sin embargo, el marco argentino no tiene rango de ley específica de IA, y la Ley 25.326 de Protección de Datos Personales —que data del año 2000— carece de disposiciones sobre calidad de datos de entrenamiento o documentación de modelos. Las empresas argentinas que operan en Europa bajo el AI Act no encuentran en la normativa local un espejo equivalente que las prepare.

    Brasil presenta un escenario más avanzado. La Lei Geral de Proteção de Dados (LGPD) ya establece en su artículo 20 el derecho a revisión de decisiones automatizadas que afecten intereses del titular, lo que obliga a las organizaciones a mantener algún nivel de documentación sobre el funcionamiento de sus modelos. Además, el proyecto de ley de regulación de IA (PL 2338/2023), que avanza en el Senado, adopta una estructura de clasificación por riesgo que es deliberadamente compatible con el enfoque europeo. Brasil es, hoy, el país de la región con mayor coherencia regulatoria en preparación para el AI Act.

    México, en tanto, está en una posición más expuesta. El INAI —Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales— ha emitido recomendaciones sobre IA, pero la LFPDPPP (Ley Federal de Protección de Datos Personales en Posesión de los Particulares) no cubre el ciclo de vida de modelos de IA ni establece requisitos de calidad de datos de entrenamiento. Las empresas mexicanas con operaciones en Europa o con clientes europeos están navegando el AI Act sin un andamiaje regulatorio local que las oriente.

    Qué monitorear: los plazos de cumplimiento que ya están corriendo

    El AI Act tiene una arquitectura temporal que muchos equipos subestiman. Las prohibiciones para sistemas de riesgo inaceptable —como el scoring social generalizado o la identificación biométrica en tiempo real en espacios públicos— entraron en vigor en febrero de 2025. Los requisitos para sistemas de alto riesgo en sectores como empleo, crédito y educación son exigibles desde agosto de 2026. Los Códigos de Práctica para modelos de IA de uso general, incluidos los LLMs, deben estar listos para mediados de 2025. Para un CDO en una organización con presencia europea, el calendario no admite demoras.

    El primer hito accionable es completar, antes de fin de 2025, un inventario de sistemas de IA clasificados por nivel de riesgo según los Anexos II y III del AI Act. El segundo es designar formalmente un data steward para cada dataset de entrenamiento de modelos de alto riesgo. El tercero es auditar si los catálogos de datos existentes registran suficiente metadata de linaje como para responder las preguntas del Anexo IV. Esos tres pasos no requieren nueva tecnología; requieren decisiones de gobernanza.

    Nuestro análisis

    El AI Act europeo está funcionando, paradójicamente, como el diagnóstico de gobernanza de datos más completo que muchas organizaciones nunca encargaron. Al exigir linaje documentado, ownership formal de datasets y documentación auditada de modelos, el reglamento está poniendo un precio concreto —multas de hasta 35 millones de euros o el 7% de la facturación global para infracciones graves— a lo que hasta ahora era solo una recomendación de mejores prácticas. En LATAM, la mayoría de las organizaciones que trabajan con IA están en un nivel de madurez de gobernanza que el CDMC clasificaría entre 1 y 3 sobre 5. Eso no es suficiente para el AI Act. La pregunta que los CDOs de la región deben responder no es si el reglamento europeo los aplica directamente: es si quieren que sus capacidades de gobernanza sean auditables, o solo presentables.

    Los equipos que traten el AI Act como un problema exclusivamente legal perderán la oportunidad de convertir el cumplimiento en una ventaja operativa. Los que lo traten como un proyecto de gobernanza de datos tendrán los cimientos para escalar cualquier sistema de IA con menor riesgo regulatorio, en Europa y en la región.

  • Gobernanza de datos e IA: la ventaja competitiva que los CDO no pueden ignorar

    Gobernanza de datos e IA: la ventaja competitiva que los CDO no pueden ignorar

    Las organizaciones que tratan la gobernanza de datos como un requisito de cumplimiento —y no como palanca estratégica— están perdiendo terreno frente a competidores que ya usan sus datos con trazabilidad, calidad y confianza verificables. Con la inteligencia artificial como acelerador, el costo de una mala gobernanza dejó de ser abstracto: se mide en modelos sesgados, decisiones auditadas judicialmente y multas regulatorias.

    La gobernanza de datos, en términos operativos, es el conjunto de políticas, roles, procesos y controles que determinan quién puede hacer qué con qué dato, cuándo y con qué nivel de calidad garantizado. No es un proyecto de TI: es una disciplina organizacional que cruza finanzas, legal, operaciones y ahora —de manera inseparable— los sistemas de inteligencia artificial. Sin gobernanza, un modelo de IA es una caja negra alimentada con datos de origen incierto; con gobernanza, ese mismo modelo puede auditarse, explicarse y defenderse ante un regulador.

    Por qué la IA convierte la gobernanza de datos en urgencia de negocio

    Los sistemas de IA generativa y los modelos predictivos dependen de los datos que los alimentan. Si esos datos tienen problemas de calidad, linaje incompleto o clasificación errónea, el output del modelo hereda —y amplifica— esos defectos. El marco DAMA-DMBOK v2 identifica once áreas de conocimiento en la gestión de datos; las más críticas para implementaciones de IA son precisamente las que menos madurez tienen en la mayoría de las empresas de la región: calidad de datos, linaje (data lineage) y seguridad de datos con clasificación formal. El EDM Council, a través del modelo CDMC (Cloud Data Management Capabilities), añade una capa adicional: la trazabilidad del dato en entornos cloud, que es donde la mayoría de los modelos de IA se entrenan y despliegan hoy.

    El data lineage —la capacidad de rastrear un dato desde su origen hasta su uso final, incluyendo cada transformación intermedia— es el componente que los reguladores de IA están comenzando a exigir explícitamente. El AI Act de la Unión Europea, vigente desde agosto de 2024, obliga a los proveedores de sistemas de IA de alto riesgo a documentar la procedencia y características de los datasets de entrenamiento. Esa exigencia no es opcional para empresas latinoamericanas que exporten servicios de IA a Europa o que operen filiales allí.

    Transparencia algorítmica y los marcos regulatorios en Brasil, México y Argentina

    En América Latina, la presión regulatoria sobre la IA todavía no alcanza la especificidad del AI Act europeo, pero los marcos de protección de datos ya imponen obligaciones indirectas que requieren gobernanza sólida. La Lei Geral de Proteção de Dados (LGPD) de Brasil, en su artículo 20, establece el derecho del titular a solicitar revisión de decisiones tomadas exclusivamente por medios automatizados. Ejercer ese derecho —y responderlo— exige que la organización tenga linaje documentado y pueda reconstruir la lógica del modelo. Sin gobernanza de datos, ese artículo es inejercitable en la práctica. En México, la LFPDPPP y los Lineamientos del INAI sobre tratamientos especiales apuntan en la misma dirección. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) publicó en 2023 recomendaciones sobre el uso de IA en el sector público que enfatizan la necesidad de auditoría de datos de entrada.

    El dato que sintetiza el problema regional: según el informe State of Data Management de DAMA International (edición 2023), menos del 30% de las organizaciones encuestadas en mercados emergentes tienen un programa formal de calidad de datos con métricas publicadas internamente. Es decir, la mayoría de las empresas que hoy despliegan IA en LATAM lo hacen sin saber, con precisión documentada, qué tan confiables son los datos que alimentan sus modelos.

    Cuándo aplica la gobernanza de datos como ventaja competitiva — y cuándo no

    La gobernanza de datos genera ventaja competitiva verificable en escenarios concretos: sectores regulados con auditorías externas (banca, salud, seguros), organizaciones que monetizan datos como producto o insumo para terceros, y empresas que despliegan IA en decisiones que afectan a personas (crédito, contratación, scoring de riesgo). En esos contextos, la capacidad de demostrar la calidad, el origen y el tratamiento ético de los datos es diferencial. Donde la gobernanza no es ventaja competitiva inmediata —aunque sí sigue siendo necesaria— es en operaciones internas sin regulación sectorial y sin modelos de IA en producción: allí el foco inicial debería ser construir el inventario de datos (data catalog) antes de crear estructuras de gobierno complejas. Bob Seiner, referente del enfoque Non-Invasive Data Governance, subraya que los programas que empiezan por la burocracia antes que por el inventario suelen morir en el comité de aprobación.

    Tres capacidades concretas para construir gobernanza que soporte IA

    Un programa de gobernanza de datos orientado a soportar sistemas de IA debe priorizar, en este orden:

    • Clasificación formal de datos: definir qué datos son sensibles, críticos o regulados, y asignar un data steward responsable por cada dominio. Sin clasificación, no hay control de acceso diferenciado ni linaje aplicable.
    • Linaje end-to-end en los pipelines que alimentan modelos: documentar las transformaciones, joins y filtros que aplican sobre los datos antes de que lleguen al entrenamiento o a la inferencia. Herramientas como Apache Atlas, OpenMetadata o las capacidades nativas de plataformas cloud (AWS Glue DataBrew, Azure Purview) permiten automatizar buena parte de esta captura.
    • Métricas de calidad de datos publicadas y revisadas en ciclos definidos: dimensiones mínimas según DAMA-DMBOK: completitud, exactitud, consistencia y oportunidad. Sin métricas, la “calidad de datos” es una aspiración, no un estado gestionable.

    Para los CDO que operan en la región, el punto de entrada más realista en 2025 no es implementar CDMC completo —son 14 capacidades con más de 500 sub-controles— sino mapear cuáles de esas capacidades ya tienen equivalentes funcionales en la organización. Los bancos argentinos que reportan al BCRA bajo Comunicación A 7724 (gestión de riesgos tecnológicos) ya operan con controles de calidad y trazabilidad que cubren parcialmente las capabilities 6 y 8 del CDMC, aunque sin la certificación formal. El ejercicio de mapear eso toma menos tiempo del que parece y produce el argumento de negocio para financiar los gaps.

    Para profundizar en los requisitos de documentación de datasets bajo el AI Act europeo, el texto oficial está disponible en el Diario Oficial de la UE (Reglamento 2024/1689); para el contexto LATAM, las recomendaciones de la AAIP sobre IA en el sector público ofrecen el punto de partida más concreto disponible en la región a la fecha.

  • Reconocimiento facial en tiempo real llega al metro de Londres

    Reconocimiento facial en tiempo real llega al metro de Londres

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

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

    Por qué Victoria y por qué ahora

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Lo que los bancos de LATAM deben resolver antes de escalar

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

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

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

  • IA y protección de datos en LATAM: el mapa regulatorio de 2025

    IA y protección de datos en LATAM: el mapa regulatorio de 2025

    América Latina atraviesa la fase más activa de su historia regulatoria en materia de inteligencia artificial y protección de datos personales. Según se informó desde la IAPP, los países de la región acumulan avances simultáneos en implementación normativa que, por primera vez, apuntan a converger con estándares internacionales. El mapa ya no es el de hace tres años: hay leyes en vigor, autoridades operativas y, en algunos casos, primeras sanciones.

    El fenómeno no es uniforme. Mientras Brasil consolida la Autoridade Nacional de Proteção de Dados (ANPD) como referencia regional —con resoluciones sobre bases legales, evaluaciones de impacto y, desde 2024, guías específicas para el uso de IA en tratamiento de datos personales—, otros países todavía debaten si su marco de privacidad vigente es suficiente para cubrir los riesgos que introducen los sistemas automatizados de toma de decisiones. Esa brecha entre vanguardia y rezago es el dato estructural de la región en este momento.

    Brasil y Colombia lideran la implementación con instrumentos concretos

    Brasil es el caso de mayor desarrollo institucional. La LGPD (Lei Geral de Proteção de Dados, Lei nº 13.709/2018) tiene ya jurisprudencia administrativa acumulada, y la ANPD avanza en su agenda regulatoria con énfasis en tres frentes: tratamiento de datos de menores, transferencias internacionales y —el más relevante para el momento actual— decisiones automatizadas bajo el artículo 20 de la ley, que reconoce el derecho del titular a solicitar revisión humana de decisiones tomadas exclusivamente por algoritmos. La ANPD publicó en 2024 un documento de referencia sobre el tema que, según se informó, está siendo revisado a la luz del avance del marco europeo de IA.

    Colombia, por su parte, opera bajo la Ley 1581 de 2012 y su decreto reglamentario, con la Superintendencia de Industria y Comercio (SIC) como autoridad de control. La SIC ha emitido circulares sobre el uso de datos en sistemas de IA y, en 2024, presentó lineamientos para el tratamiento de datos en modelos de lenguaje de gran escala. No es legislación vinculante todavía, pero establece una posición institucional que anticipa regulación formal. Colombia también participó activamente en las discusiones del marco interamericano de IA impulsado por la OEA.

    Argentina y México: marcos de privacidad que preceden a la IA y muestran sus límites

    Argentina tiene la Ley 25.326 de Protección de Datos Personales —una de las más antiguas de la región, sancionada en el año 2000— y una reforma pendiente desde hace años que el Congreso no ha logrado aprobar. La Agencia de Acceso a la Información Pública (AAIP) emitió en 2023 recomendaciones sobre IA y datos personales, pero sin fuerza normativa vinculante. El problema concreto es que el artículo 20 de la ley vigente limita parcialmente las decisiones automatizadas, pero fue redactado antes de que existieran los sistemas actuales de machine learning: su aplicación a modelos fundacionales es, en el mejor caso, interpretativa. Una reforma legislativa que modernice ese articulado —con estándares explícitos de explicabilidad, auditoría y evaluación de impacto— sigue siendo la deuda más clara del ecosistema argentino.

    México opera bajo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, 2010) y su equivalente para el sector público (LPDPPSO, 2017), con el INAI como autoridad de control. El instituto ha publicado guías sobre IA y datos personales, pero la discusión regulatoria específica sobre sistemas de IA de alto riesgo —al estilo del AI Act europeo— no tiene todavía un vehículo legislativo propio. El INAI enfrenta además un escenario institucional complejo: su presupuesto y autonomía han sido objeto de debate político, lo que genera incertidumbre sobre su capacidad de enforcement en temas emergentes.

    El AI Act europeo como referencia, no como modelo de copia directa

    Varios países de la región toman el Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689, en vigor desde agosto de 2024) como punto de partida para sus propios marcos. La lógica es comprensible: es el instrumento más desarrollado disponible, con clasificación por niveles de riesgo, prohibiciones específicas y requisitos de transparencia. Sin embargo, los equipos legales que operan en LATAM deberían evitar una trasposición mecánica. Las estructuras de enforcement de la región son distintas —autoridades de privacidad con recursos limitados, ausencia de autoridades sectoriales de IA en la mayoría de los países—, y los sectores de mayor riesgo no son idénticos: el uso de IA en crédito informal, en sistemas de bienestar social y en procesos migratorios tiene una escala y una urgencia diferentes a las del contexto europeo.

    Lo que sí es directamente aplicable es el principio de evaluación de impacto en protección de datos (EIPD/DPIA) para sistemas de IA que traten datos personales a escala. Tanto la LGPD brasileña como la LFPDPPP mexicana y la Ley 1581 colombiana contienen bases para exigir ese análisis, aunque con distintos niveles de desarrollo reglamentario.

    Chile y Perú: reformas en curso con cronogramas definidos

    Chile aprobó en 2024 su nueva Ley de Protección de Datos Personales (Ley 21.719), que moderniza el marco vigente desde 1999 y crea el Consejo para la Transparencia con funciones ampliadas de control. La ley incluye disposiciones sobre decisiones automatizadas y establece plazos de implementación progresiva hasta 2026. Es el avance legislativo más significativo de la región en los últimos dos años y pone a Chile en condiciones de negociar adecuación con la Unión Europea. Perú, por su parte, opera bajo la Ley 29733 con la Autoridad Nacional de Protección de Datos (ANPD-Perú) adscrita al Ministerio de Justicia; hay un proyecto de reforma en discusión que incorpora elementos de la economía digital, pero sin cronograma aprobado.

    Qué monitorear en los próximos seis meses

    Los hitos regulatorios más relevantes para el segundo semestre de 2025 y primer trimestre de 2026 incluyen: la resolución de la ANPD brasileña sobre decisiones automatizadas, que según se informó podría publicarse antes de fin de año; la entrada en vigor progresiva de la Ley 21.719 chilena; y el avance —o estancamiento— de la reforma a la Ley 25.326 en el Congreso argentino. A nivel regional, el proceso de elaboración de un marco interamericano de IA en el seno de la OEA es un espacio a seguir, aunque sus productos son de naturaleza no vinculante.

    Nuestro análisis

    La convergencia regulatoria en LATAM es real pero asimétrica. Brasil y Chile tienen marcos técnicamente robustos con autoridades que pueden hacer enforcement. Colombia construye posición institucional sin legislación específica de IA todavía. Argentina y México tienen leyes de privacidad que funcionan como red de contención, pero con evidentes limitaciones para capturar los riesgos de los sistemas de IA actuales. Para las empresas que operan en múltiples jurisdicciones de la región, la estrategia de “cumplir con LGPD y replicar” es un punto de partida razonable, pero insuficiente: las especificidades de cada marco —especialmente en decisiones automatizadas, transferencias internacionales y datos sensibles— requieren análisis jurisdicción por jurisdicción. El riesgo de enforcement cruzado es bajo hoy; en 24 meses, con autoridades más consolidadas, ese cálculo cambia.

    La pregunta que los equipos legales y de datos deberían estar respondiendo ahora no es si su empresa cumple con la regulación vigente, sino si su arquitectura de gobernanza está preparada para las obligaciones que llegan en 2026.

  • Instructure y el ataque a Canvas: lo que falló en el gobierno del dato

    Instructure y el ataque a Canvas: lo que falló en el gobierno del dato

    Instructure, la compañía detrás del sistema de gestión de aprendizaje Canvas, sufrió uno de los mayores incidentes de exposición de datos del año en Estados Unidos. El vector de entrada fue un proveedor externo, un patrón que se repite con preocupante consistencia en el sector educativo y que expone una falla estructural en la cadena de ownership del dato. Para los equipos de gobierno de datos, la pregunta relevante no es cómo ocurrió el ataque, sino qué controles de data governance habrían contenido el daño.

    Según se informó, los atacantes accedieron a los sistemas de Instructure a través de un tercero contratado, lo que desencadenó una brecha de alcance significativo que afectó a instituciones de educación superior en múltiples jurisdicciones. La naturaleza del acceso —lateral, a través de un eslabón con privilegios delegados— es característica de los ataques a cadenas de suministro de datos, donde el perímetro técnico no coincide con el perímetro de ownership del dato.

    El problema no es el ataque: es la arquitectura de confianza

    Cuando un proveedor externo puede acceder a volúmenes de datos suficientes para generar una brecha “de las más grandes del año”, el problema subyacente es de data governance, no de ciberseguridad. En términos del DAMA-DMBOK, el knowledge area de Data Security Governance establece que el acceso a datos debe estar gobernado por políticas que incluyan clasificación por sensibilidad, necesidad mínima de acceso y revisión periódica de privilegios de terceros. La pregunta que debería haber respondido un data steward antes de este incidente es: ¿qué datos puede ver este proveedor, por qué, y desde cuándo no revisamos esa autorización?

    El modelo de Non-Invasive Data Governance de Bob Seiner es particularmente relevante aquí: en entornos educativos, donde la aversión al cambio estructural es alta y los ciclos de decisión son lentos, el gobierno del dato no puede depender de grandes transformaciones organizacionales. Depende de que alguien —un data steward concreto, con nombre y responsabilidad asignada— sea accountable por cada dataset expuesto a terceros. Si ese rol no existe o no tiene visibilidad sobre los contratos de datos, el incidente de Instructure es predecible.

    Qué hace el CDO el lunes con esto

    Este caso activa al menos tres revisiones inmediatas para cualquier equipo de gobierno de datos en organizaciones con ecosistemas de proveedores:

    • Auditoría de accesos de terceros: mapear qué vendors tienen acceso a datos clasificados como sensibles o confidenciales, con qué granularidad y bajo qué contrato de procesamiento. Si el catálogo de datos no incluye esta dimensión, es el primer gap a cerrar.
    • Revisión de data lineage hacia afuera: el lineage no termina en el data warehouse interno. Los datos que fluyen a plataformas SaaS o a integraciones con terceros deben tener trazabilidad documentada. Canvas es SaaS; sus integraciones con LTI y APIs de terceros son puntos ciegos frecuentes.
    • Cláusulas de governance en contratos con proveedores: verificar que los contratos vigentes incluyan obligaciones de clasificación, notificación de incidentes y limitación de uso. En muchas organizaciones latinoamericanas, estas cláusulas no existen o son genéricas.

    El ángulo LATAM: brecha, notificación y responsabilidad distribuida

    Canvas tiene presencia activa en universidades de Brasil, México, Argentina y Colombia, entre otros países. Si el incidente involucró datos de estudiantes latinoamericanos —lo cual es altamente probable dado el alcance reportado— entran en juego marcos regulatorios concretos. En Brasil, la LGPD (Lei 13.709/2018) obliga al controlador a notificar a la ANPD dentro de un plazo razonable cuando la brecha pueda acarrear riesgo o daño relevante; Instructure, como operador, tiene responsabilidad solidaria si no implementó las medidas técnicas pactadas. En Argentina, la Ley 25.326 y la Disposición AAIP 4/2019 establecen la obligación de reportar incidentes de seguridad. En México, el INAI ha sido explícito en que los responsables no pueden delegar su obligación de custodia al subcontratar servicios. Ninguna de estas jurisdicciones acepta “fue el proveedor” como exoneración del responsable principal.

    El sector universitario latinoamericano, que adoptó Canvas masivamente durante la pandemia, hereda ahora un modelo de governance de datos construido sobre urgencia operativa, no sobre diseño. Los equipos de TI universitarios raramente cuentan con un CDO formal ni con un catálogo activo de datos sensibles. El CDMC (Cloud Data Management Capabilities) del EDM Council ofrece una referencia útil: las capacidades de gestión de riesgo de terceros corresponden al dominio 9 del framework, y la mayoría de las universidades de la región operaría en nivel 1 o por debajo si se midiera formalmente.

    La lección que no es nueva, pero sigue sin aprenderse

    Los incidentes por terceros no son accidentes de seguridad: son síntomas de ownership difuso. Cuando nadie en la organización puede responder en menos de 24 horas a “¿qué datos tiene acceso ese proveedor y quién autorizó eso?”, el data governance falló antes de que llegara el atacante. El caso de Instructure debería ser el disparador para que los responsables de datos en el sector educativo latinoamericano eleven este punto en la próxima reunión de rectorado o de directorio, no como un tema de IT, sino como un riesgo institucional con implicancias legales directas.

    El vector fue un proveedor, pero la vulnerabilidad era de gobierno: sin ownership claro del dato y sin lineage hacia afuera, cualquier integración de terceros es una puerta entreabierta.

  • OpenAI bajo la lupa: 15 fiscales exigen preservar registros del incidente en Hugging Face

    OpenAI bajo la lupa: 15 fiscales exigen preservar registros del incidente en Hugging Face

    Quince fiscales generales de Estados Unidos enviaron una carta formal al CEO de OpenAI, Sam Altman, exigiendo que la compañía preserve toda la documentación relacionada con el reciente incidente en Hugging Face, en el que modelos de OpenAI habrían tenido participación directa. Los funcionarios advierten que la empresa podría haber violado leyes estatales y federales, y el movimiento marca un punto de inflexión en la presión regulatoria sobre los grandes laboratorios de inteligencia artificial.

    La carta, enviada el lunes según se informó, lleva las firmas de 15 fiscales generales de orientación republicana y está dirigida al máximo ejecutivo de la compañía creadora de ChatGPT. El texto advierte que OpenAI podría haber incurrido en conductas que vulneran normativas vigentes a nivel estatal y federal en los Estados Unidos. El pedido de preservación de registros —conocido en la práctica legal como litigation hold— suele preceder a investigaciones formales o demandas judiciales y obliga a las organizaciones a no destruir ni alterar documentación potencialmente relevante.

    Qué se sabe del incidente en Hugging Face

    Hugging Face, la plataforma de referencia para compartir modelos de inteligencia artificial de código abierto, fue escenario de una brecha en la que habrían estado involucrados modelos atribuidos a OpenAI. Aunque los detalles técnicos del incidente no han sido divulgados en su totalidad, según se informó el alcance habría sido suficientemente significativo como para motivar la acción coordinada de más de una docena de fiscales. La naturaleza exacta de los datos comprometidos y el vector de ataque permanecen bajo investigación al cierre de esta nota.

    Lo que distingue a este caso de otros incidentes en el ecosistema de IA no es solo la escala potencial, sino el hecho de que una empresa de IA de primer nivel aparezca como actor —directo o indirecto— en la brecha de otra organización del sector. Ese ángulo cambia radicalmente el análisis de responsabilidad: ya no se trata de un proveedor víctima, sino de una entidad cuya tecnología podría haber operado como vector de compromiso.

    Presión legal coordinada y señal regulatoria

    La acción coordinada de 15 fiscales generales no es un gesto simbólico. En el sistema legal estadounidense, estos funcionarios tienen potestad para iniciar investigaciones independientes, imponer medidas cautelares y, eventualmente, presentar demandas civiles o derivar casos a instancias federales. El solo hecho de que se emita una carta de preservación de registros indica que al menos algunos de estos despachos están evaluando activamente el inicio de procedimientos formales.

    “OpenAI podría haber violado leyes estatales o federales en el incidente”

    — Extracto de la carta de los 15 fiscales generales dirigida a Sam Altman, según se informó

    El movimiento se enmarca en una tendencia más amplia: los estados de EE.UU. están llenando el vacío regulatorio que el Congreso federal no ha logrado cubrir en materia de inteligencia artificial. A falta de una ley federal de IA o de privacidad integral, los fiscales generales se convierten en los principales garantes del cumplimiento normativo frente a los gigantes tecnológicos.

    Implicancias para el ecosistema de IA y los proveedores

    Para los equipos legales y de cumplimiento de empresas que utilizan modelos de OpenAI —incluidas las integradas vía API en productos de terceros—, este caso plantea preguntas urgentes sobre la cadena de responsabilidad. Si un modelo puede ser considerado vector de una brecha en una plataforma externa, los contratos de servicio, los acuerdos de procesamiento de datos y las cláusulas de indemnización cobran una relevancia que muchas organizaciones aún no han dimensionado.

    El incidente también reencuadra el debate sobre los modelos de código abierto y las plataformas de distribución como Hugging Face. La capacidad de alojar, modificar y redistribuir modelos a escala genera superficies de ataque nuevas que los marcos legales tradicionales —pensados para software empresarial empaquetado— no contemplan con precisión. Desde la perspectiva del AI Act europeo, que clasifica sistemas por nivel de riesgo, un incidente de esta naturaleza podría incidir en cómo se evalúa la categorización de modelos de propósito general.

    El ángulo latinoamericano: responsabilidad del proveedor de IA

    En América Latina, la discusión sobre responsabilidad de proveedores de IA en incidentes de datos avanza a distinta velocidad según el país. Brasil, con la Lei Geral de Proteção de Dados (LGPD) y la Autoridade Nacional de Proteção de Dados (ANPD) ya operativa, cuenta con un marco que obliga a los operadores a notificar brechas en plazos definidos y que alcanza a empresas que traten datos de titulares brasileños, independientemente de dónde estén constituidas. Argentina, bajo la Ley 25.326 y en proceso de modernización legislativa, también proyecta responsabilidad extraterritorial. México, con la LFPDPPP para el sector privado y las directrices del INAI, enfrenta el desafío de aplicar normas diseñadas antes del auge de los modelos generativos a incidentes que involucran cadenas complejas de proveedores de IA.

    Lo que el caso OpenAI-Hugging Face ilustra para la región es que las organizaciones que integran modelos de terceros en sus productos o servicios no pueden delegar completamente la responsabilidad en el proveedor. Los DPOs y equipos legales de empresas latinoamericanas que usan estas tecnologías deberían revisar con urgencia si sus contratos con proveedores de IA contemplan escenarios de responsabilidad compartida ante brechas que involucren a subprocesadores o plataformas de distribución de modelos.

    Lo que viene: investigación y precedente

    La respuesta de OpenAI a la carta de los fiscales marcará el tono de los próximos meses. Si la empresa adopta una postura cooperativa y divulga los registros solicitados voluntariamente, podría reducir la exposición legal inmediata. Si opta por una estrategia defensiva, es probable que al menos parte de los 15 despachos avancen hacia acciones formales. En cualquier escenario, el caso sentará precedente sobre el grado de accountability exigible a los laboratorios de IA cuando su tecnología protagoniza —o facilita— un incidente de seguridad en un actor externo.

    En un sector acostumbrado a moverse más rápido que los reguladores, el tiempo en que los laboratorios de IA podían declarar incidentes como “ajenos” a su responsabilidad parece estar llegando a su fin.

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

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

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