DataTrends LATAM

Etiqueta: Normativa

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

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

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

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

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

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

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

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

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

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

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

    El paralelo regulatorio en LATAM

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

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

    Confianza en los datos como activo regulatorio

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

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

    — Perspectiva editorial, DataTrends LATAM

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

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

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

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

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

    Cuatro leyes, un mismo problema de diseño

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

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

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

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

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

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

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

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

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

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

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

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

    Qué hace bien Snowflake de forma nativa

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

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

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

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

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

    Lo que necesita el CDO para cerrar la brecha

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

    El contexto regulatorio LATAM no perdona datos de baja calidad

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

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

    Qué hacer el lunes

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

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

  • Filtración masiva en Corea: USD 3,50 de compensación por persona enciende el debate

    Filtración masiva en Corea: USD 3,50 de compensación por persona enciende el debate

    La Corporación de Instalaciones de Seúl enfrenta una tormenta política tras ofrecer 5.000 wones —equivalentes a unos 3,50 dólares— como compensación a cada una de las 4,62 millones de personas afectadas por una brecha de datos personales. La cifra, considerada irrisoria por legisladores surcoreanos, reabre el debate global sobre cómo valuar el daño real que sufren los individuos cuando sus datos son comprometidos.

    El concejal Im Gyu-ho, del Partido Democrático de Corea, fue uno de los primeros en cuestionar públicamente la propuesta ante el Consejo Metropolitano de Seúl. Según se informó, el funcionario señaló que el monto no refleja ni el alcance del incidente ni la naturaleza de los datos expuestos, y exigió una revisión del esquema indemnizatorio. La cifra total que desembolsaría la corporación rondaría los 23 millones de dólares, pero distribuida entre millones de personas, el impacto individual resulta casi simbólico.

    El problema de fondo: ¿cuánto vale un dato personal?

    La controversia surcoreana no es un caso aislado: es la versión más reciente de un debate que ningún sistema regulatorio ha resuelto del todo. Establecer un valor monetario al daño derivado de una brecha de datos personales implica considerar factores heterogéneos —riesgo de fraude, estrés, pérdida de control sobre la propia identidad digital— que los marcos legales traducen en criterios distintos según la jurisdicción. En Europa, el RGPD habilita indemnizaciones por “daño moral” sin tope mínimo definido, lo que ha derivado en sentencias que van desde unos pocos euros hasta compensaciones de cuatro cifras por persona en casos de exposición de datos sensibles.

    En América Latina, el panorama es fragmentado. En Argentina, la Ley 25.326 de Protección de Datos Personales prevé acciones de daños y perjuicios, pero la práctica judicial aún no ha consolidado estándares claros de cuantificación por brecha masiva. En Brasil, la Lei Geral de Proteção de Dados (LGPD) contempla la responsabilidad civil del controlador y habilita a la Autoridade Nacional de Proteção de Dados (ANPD) a sancionar, aunque las primeras resoluciones sancionatorias recién están sentando precedente. México, a través del INAI y la LFPDPPP, también carece de una doctrina consolidada sobre montos compensatorios individuales en incidentes de escala masiva.

    Sanciones que no duelen: el riesgo del “precio del dato”

    Cuando la compensación por persona se fija en cifras que no generan incentivos reales para prevenir incidentes, el sistema regulatorio pierde efectividad disuasoria. Este es, precisamente, el argumento que subyace a la crítica del legislador Im Gyu-ho: si una entidad pública puede procesar de forma insegura los datos de 4,62 millones de ciudadanos y saldar la cuenta con 3,50 dólares por cabeza, el costo del incumplimiento es inferior al costo de invertir en controles preventivos. Esa lógica —el “precio del dato”— es exactamente lo que marcos como el RGPD intentaron romper con multas de hasta el 4% de la facturación global anual.

    “La compensación no refleja el alcance del incidente ni la naturaleza de los datos expuestos. Debe revisarse el esquema indemnizatorio.”

    — Im Gyu-ho, concejal del Partido Democrático de Corea, Consejo Metropolitano de Seúl

    Implicancias para la región

    El caso de Seúl ofrece una referencia concreta para los debates legislativos que se desarrollan en la región. En Colombia, la Ley Estatutaria 1581 y su regulación complementaria están siendo revisadas en el marco de una posible reforma. En Chile, la nueva Ley Marco de Ciberseguridad y la Ley de Protección de Datos Personales recientemente promulgada incorporan criterios de proporcionalidad en las sanciones. En todos estos contextos, la pregunta de fondo es la misma: ¿las multas y compensaciones previstas son suficientes para modificar el comportamiento de las organizaciones que procesan datos masivamente, o seguirán siendo un costo tolerable de operación?

    La discusión también interpela a entidades públicas, que en muchos países latinoamericanos quedan fuera o en zonas grises de los regímenes de responsabilidad por datos personales. Si los organismos estatales no están sujetos a los mismos estándares sancionatorios que el sector privado, el incentivo para invertir en seguridad y gobernanza de datos se debilita aún más. La Corporación de Instalaciones de Seúl —una entidad pública metropolitana— ilustra exactamente ese riesgo.

    Cuando la compensación por una brecha masiva cuesta menos que una taza de café por persona, no es un problema de matemáticas: es un problema de diseño regulatorio.

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

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

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

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

    Más que publicidad dirigida: usos de alto riesgo

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

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

    El problema del consentimiento en cadena

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

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

    — Electronic Frontier Foundation, informe técnico 2026

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

    Responsabilidad del desarrollador como controlador

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

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

    Defaults que deciden por el usuario

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

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