Etiqueta: Ai Privacy

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

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

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

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

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

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

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

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

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

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

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

    El paralelo regulatorio en LATAM

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

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

    Confianza en los datos como activo regulatorio

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

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

    — Perspectiva editorial, DataTrends LATAM

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

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

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

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

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

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

    Más que publicidad dirigida: usos de alto riesgo

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

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

    El problema del consentimiento en cadena

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

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

    — Electronic Frontier Foundation, informe técnico 2026

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

    Responsabilidad del desarrollador como controlador

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

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

    Defaults que deciden por el usuario

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

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