DataTrends LATAM

Blog

  • Nigeria endurece el gobierno de datos en sus agencias públicas: lecciones para LATAM

    Nigeria endurece el gobierno de datos en sus agencias públicas: lecciones para LATAM

    Nigeria endureció sus reglas de gobierno de datos para agencias del sector público, según se informó a comienzos de agosto de 2025. La medida establece requisitos formales de gestión, clasificación y responsabilidad sobre los datos que producen y custodian los organismos estatales, y coloca al país africano en una trayectoria que varios gobiernos de América Latina todavía no terminan de recorrer.

    El marco regulatorio nigeriano, impulsado desde la Nigeria Data Protection Commission (NDPC), apunta a que cada agencia gubernamental designe responsables formales del dato, implemente políticas de ciclo de vida de la información y reporte con periodicidad el estado de sus activos de datos. La lógica es la misma que sostiene el DAMA-DMBOK en su área de conocimiento de Data Governance: sin ownership claro, ningún programa de calidad o seguridad puede sostenerse en el tiempo. Lo notable es que Nigeria lo está aplicando de manera top-down sobre el Estado, no solo sobre el sector privado.

    El problema de fondo: datos públicos sin dueño

    Uno de los patrones más documentados en auditorías de gobierno de datos del sector público es la ausencia de data stewards formalmente designados. En la práctica, los registros administrativos —padrones, bases tributarias, historiales clínicos, datos catastrales— circulan entre dependencias sin un modelo claro de ownership. El resultado es duplicación, inconsistencia y, cuando ocurre un incidente, incapacidad de reconstruir el data lineage para determinar qué se expuso y desde cuándo. La iniciativa nigeriana ataca exactamente ese nodo: fuerza a cada agencia a mapear sus activos y asignar responsabilidades concretas.

    El modelo de referencia más cercano a lo que Nigeria está construyendo es el Data Management Capability Assessment Model (DCAM) del EDM Council, que estructura las capacidades de gobierno de datos en niveles de madurez medibles. En el contexto de gobierno, el nivel 3 del DCAM —donde los procesos de governance están definidos, documentados y medidos— sigue siendo aspiracional para la mayoría de los organismos públicos globales. Nigeria está intentando saltear los niveles informales e instalar ese piso de manera regulatoria.

    LATAM: el sector público va a distintas velocidades

    En América Latina, el panorama es heterogéneo. Brasil avanza con la LGPD (Ley 13.709/2018) y la Autoridade Nacional de Proteção de Dados (ANPD) ha publicado orientaciones específicas para el tratamiento de datos por parte de organismos públicos, pero la implementación interna de programas de data governance al interior de las agencias sigue siendo desigual. En Argentina, la Ley 25.326 de Protección de Datos Personales regula el tratamiento estatal, pero no existe un mandato equivalente al nigeriano que exija a cada ministerio o ente descentralizado tener un programa de gobierno de datos con ownership documentado. México, a través del INAI, ha avanzado en criterios de seguridad para datos personales en posesión del Estado, pero la dimensión de governance —más allá de privacidad— carece de un marco homogéneo entre dependencias federales y estatales.

    El caso nigeriano es relevante porque muestra que es posible legislar sobre data governance sectorial con exigencias operativas concretas: designación de roles, inventario de activos, políticas de retención y mecanismos de reporte. No es solo una declaración de principios.

    Qué puede hacer un CDO del sector público esta semana

    Para un Chief Data Officer o responsable de gobierno de datos en una agencia pública latinoamericana, el movimiento nigeriano es una señal de tendencia que conviene anticipar. Hay tres acciones concretas con bajo costo de arranque:

    • Levantar un inventario mínimo de activos de datos críticos — al menos los que se comparten con otros organismos o que tienen obligaciones legales de reporte — y asignar un data steward nominal a cada uno, aunque sea con dedicación parcial.
    • Documentar, aunque sea en una planilla, el flujo entre sistemas de origen y sistemas de consumo para los tres o cuatro procesos de datos más sensibles del organismo. Eso es data lineage básico, y habilita cualquier análisis de impacto posterior.
    • Mapear qué normativa sectorial ya exige, implícitamente, capacidades de governance: BCRA Comunicación A 8073 en Argentina para entidades financieras, resoluciones de la ANPD en Brasil, o lineamientos del INAI en México. Muchos organismos tienen obligaciones de facto sin un programa formal que las sostenga.

    La experiencia comparada —desde la estrategia de datos del gobierno del Reino Unido hasta iniciativas más recientes en Singapur y ahora Nigeria— muestra que los marcos de data governance en el sector público no surgen de la cultura organizacional espontánea. Requieren mandato explícito, roles formales y métricas de cumplimiento. Sin esos tres elementos, los programas se disuelven con el cambio de gestión.

    El riesgo de no actuar

    Cuando una agencia pública no tiene governance formal sobre sus datos, los problemas no aparecen en el día a día: aparecen cuando se necesita responder a una auditoría, cruzar bases con otro organismo, o —peor— cuando ocurre un incidente y no hay manera de determinar qué datos estaban en riesgo, quién era el responsable y cuál era la política de retención aplicable. En ese momento, la ausencia de data lineage y de ownership documentado se convierte en un problema legal, no solo operativo.

    Nigeria acaba de poner el estándar sobre la mesa. La pregunta para los organismos públicos de la región no es si van a necesitar programas formales de data governance, sino cuánto van a esperar para construirlos.

  • El costo de una brecha de datos en LATAM alcanza su punto más alto

    El costo de una brecha de datos en LATAM alcanza su punto más alto

    El precio de perder el control sobre los datos sigue subiendo en América Latina. Según se informó, el costo promedio de una brecha de datos en la región alcanzó cifras récord en el último período medido, presionando a las organizaciones a repensar sus modelos de gobierno del dato desde la raíz, no solo su postura de ciberseguridad.

    Durante años, la conversación sobre brechas de datos en LATAM se concentró casi exclusivamente en el vector técnico: el parche que faltaba, el firewall mal configurado, el endpoint desprotegido. Ese encuadre subestimó sistemáticamente una dimensión que los números ahora vuelven imposible de ignorar: el costo económico y reputacional de no tener gobernanza sobre el dato antes de que ocurra el incidente. Cuando no se sabe qué datos existen, dónde viven, quién es su owner y cuál es su nivel de clasificación, la superficie de exposición crece de manera silenciosa hasta que alguien la cuantifica en dólares.

    Qué está detrás del incremento

    Los factores que elevan el costo de una brecha van más allá del rescate o la remediación técnica. Los componentes que más peso tienen incluyen la notificación obligatoria a titulares y reguladores, las sanciones por incumplimiento normativo, el daño reputacional medido en pérdida de clientes, los costos legales derivados de demandas y, crecientemente, el tiempo de detección y contención. Precisamente este último indicador —cuánto tarda una organización en descubrir que fue comprometida— depende en gran medida de qué tan maduro es su programa de data governance: sin un catálogo de datos actualizado y sin data lineage formal, identificar qué registros fueron expuestos puede llevar semanas.

    El DAMA-DMBOK, estándar de referencia en gestión de datos, establece que la clasificación de datos y la definición de data stewards —los responsables formales de cada dominio de datos dentro de la organización— son capacidades habilitadoras para cualquier programa de respuesta a incidentes. Sin esa base, la organización llega tarde a la notificación, activa procesos de remediación incompletos y multiplica su exposición legal.

    El marco regulatorio que amplifica el riesgo financiero

    América Latina tiene hoy un ecosistema normativo que convierte cada brecha en una amenaza financiera concreta. Brasil opera bajo la LGPD (Lei Geral de Proteção de Dados), que habilita multas de hasta el 2% de la facturación de la empresa en Brasil, con tope de 50 millones de reales por infracción. Argentina actualiza progresivamente la aplicación de la Ley 25.326 bajo supervisión de la Agencia de Acceso a la Información Pública (AAIP), que ha intensificado sus requerimientos de notificación de incidentes. México, a través del INAI, aplica la LFPDPPP con sanciones que pueden escalar significativamente en casos de negligencia manifiesta. Colombia y Chile completan un cuadro regional donde ya no existe jurisdicción de escala sin exposición regulatoria real ante un evento de este tipo.

    Este entorno normativo transforma lo que antes era un costo técnico en un pasivo legal activo. Las organizaciones que no pueden demostrar ante la autoridad que tenían controles adecuados —políticas de retención, control de acceso basado en roles, registros de tratamiento— enfrentan el escenario más costoso: la sanción máxima sin atenuantes.

    Lo que un CDO debería revisar esta semana

    Para un Chief Data Officer o Data Governance Manager, el incremento en el costo de las brechas no es una señal de alarma abstracta: es un argumento de negocio con número. El modelo de madurez CDMC (Cloud Data Management Capabilities) del EDM Council identifica en su capability 8 —Data Protection and Privacy— los controles mínimos que una organización debe operar para limitar su exposición ante un incidente. Los bancos y aseguradoras de la región que ya reportan bajo marcos regulatorios locales (como la Comunicación A 8073 del BCRA en Argentina o las circulares de la CNBV en México) tienen parte de esa infraestructura construida, aunque rara vez la han conectado formalmente con su programa de gobierno del dato.

    • Auditar el inventario de datos sensibles: ¿existe un catálogo activo con clasificación por nivel de sensibilidad y con data owner asignado por dominio?
    • Revisar los SLA de detección y notificación: la LGPD exige notificar a la ANPD en un plazo razonable; la AAIP argentina tiene criterios similares. ¿Cuánto tarda hoy la organización en saber qué fue comprometido?
    • Mapear el data lineage de los activos más críticos: sin trazabilidad formal, la evaluación del impacto de una brecha es manual, lenta y costosa.
    • Conectar el programa de DG con el equipo legal: las multas más altas en la región se explican, en parte, por la desconexión entre quienes gestionan datos y quienes gestionan el riesgo regulatorio.

    El argumento para invertir en gobierno del dato solía ser la eficiencia operativa o la calidad analítica. Hoy, con los costos de brecha en máximos históricos para la región, el argumento más directo es la gestión del riesgo financiero y reputacional. Ese cambio de encuadre abre conversaciones en el C-suite que antes eran difíciles de sostener.

    Cuando una brecha de datos cuesta más que el programa de gobierno que la hubiera prevenido, la discusión sobre prioridades presupuestarias debería ser, al menos, más sencilla.

  • IA en reclutamiento: un nuevo marco de evaluación de riesgos marca el estándar global

    IA en reclutamiento: un nuevo marco de evaluación de riesgos marca el estándar global

    El Future of Privacy Forum (FPF) publicó junto a Dayforce, LinkedIn, UKG, Workday y Beamery un marco de evaluación de riesgos y un conjunto actualizado de buenas prácticas para el uso de inteligencia artificial en procesos de contratación y gestión del empleo. La actualización responde directamente al avance de la IA generativa en los flujos de trabajo de recursos humanos y amplía un informe previo publicado en 2023. Para América Latina, donde la adopción de estas plataformas crece sin un marco legal específico para IA en el empleo, el documento llega como referencia técnica de primer orden.

    De las herramientas tradicionales a la IA generativa

    Hasta hace dos años, el debate sobre IA en el reclutamiento giraba en torno a sistemas de puntuación de candidatos, análisis de currículums y herramientas de screening automatizadas. La irrupción de los modelos de lenguaje de gran escala reconfiguró ese panorama: hoy las mismas plataformas que gestionan nóminas pueden generar descripciones de puestos, redactar evaluaciones de desempeño o sintetizar feedback de entrevistas. Ese salto cualitativo es el que motivó la actualización del grupo de trabajo del FPF, que incorporó el análisis de riesgos específicos de la IA generativa —alucinaciones, sesgos amplificados en lenguaje natural, opacidad en los criterios de selección— a un documento que ya tenía base sólida.

    El grupo de trabajo que produjo el marco está compuesto por desarrolladores de software de recursos humanos con alcance global masivo. LinkedIn y Workday, por ejemplo, son plataformas activas en prácticamente todos los mercados latinoamericanos. Eso significa que las decisiones de diseño que estos actores adopten en materia de evaluación de riesgos tendrán impacto directo sobre millones de trabajadores y postulantes en la región, independientemente de si los reguladores locales exigen o no auditorías algorítmicas.

    Qué propone el marco de riesgos

    Aunque el texto completo del framework no ha sido divulgado en su totalidad al momento de la publicación de este artículo, los lineamientos centrales que se anticiparon apuntan a estructurar la evaluación en torno a tres dimensiones: el impacto potencial sobre derechos de los candidatos, la transparencia de los sistemas frente a los usuarios finales (tanto empleadores como postulantes) y la trazabilidad de las decisiones automatizadas. Este último punto es especialmente relevante: la capacidad de explicar por qué un sistema descartó o priorizó a un candidato es, en muchas jurisdicciones, una obligación legal y no solo una buena práctica.

    El documento también aborda la necesidad de instancias humanas de revisión en decisiones de alto impacto —contratación, despido, evaluación de desempeño—, lo que conecta directamente con los principios de no automatización total de decisiones que recogen tanto el Reglamento General de Protección de Datos europeo (GDPR) como la Ley General de Protección de Datos de Brasil (LGPD) en su artículo 20, que reconoce el derecho del titular a solicitar revisión humana de decisiones tomadas exclusivamente por medios automatizados.

    El vacío regulatorio en LATAM

    América Latina no tiene, hasta ahora, una norma específica que regule el uso de IA en el empleo con el nivel de detalle que existe, por ejemplo, en la Ley de Empleo de IA de la ciudad de Nueva York o en la propuesta de reglamento de la Unión Europea sobre IA —que clasifica los sistemas de IA en recursos humanos como de alto riesgo. Argentina cuenta con la Ley 25.326 de Protección de Datos Personales, que incluye disposiciones sobre decisiones automatizadas, pero su aplicación práctica al contexto del reclutamiento algorítmico es todavía incipiente. La Autoridad Nacional de Protección de Datos (ANPD) de Brasil es, en la región, la que ha avanzado más en interpretar la LGPD en contextos de tratamiento automatizado, aunque sin una guía sectorial específica para el empleo.

    México, Colombia, Chile y Perú también cuentan con marcos de protección de datos que habilitan interpretaciones protectoras frente a la discriminación algorítmica, pero la mayoría carece de criterios operativos para auditar un sistema de IA de selección de personal. En ese contexto, el marco del FPF puede funcionar como estándar de facto para empresas que operan en la región y que quieran demostrar due diligence ante eventuales litigios o investigaciones regulatorias.

    Implicancias para equipos de compliance y legal

    Para los equipos jurídicos y de cumplimiento que asesoran a empresas con procesos de selección automatizados en LATAM, el documento del FPF ofrece un lenguaje común con el que dialogar con los proveedores tecnológicos. Preguntar a un vendor si su sistema cuenta con una evaluación de impacto algorítmico, si mantiene logs de decisiones y si permite la revisión humana de casos rechazados ya no es un ejercicio académico: es la diferencia entre poder responder a un reclamo ante la ANPD o el INAI, o enfrentar una investigación sin documentación de respaldo. El FPF planea presentar el marco en un webinar el 28 de septiembre, lo que abre una oportunidad concreta para que equipos de la región accedan a la discusión de primer nivel.

    Cuando las plataformas globales de HR fijan estándares propios de evaluación de riesgos, la pregunta para los reguladores latinoamericanos no es si deben actuar, sino si llegarán antes o después de que el mercado ya haya definido las reglas.

  • El modelo hub-and-spoke llega al gobierno de datos municipal

    El modelo hub-and-spoke llega al gobierno de datos municipal

    La ciudad de Cleveland adoptó un modelo de gobernanza de datos hub-and-spoke para coordinar el uso de información entre dependencias municipales sin centralizar el control en una sola unidad. La apuesta refleja una tendencia creciente en el sector público: descentralizar la operación sin perder la coherencia del marco de gobierno. Para los gobiernos locales de América Latina que aún operan con silos departamentales y sin una estrategia formal de datos, el caso ofrece lecciones concretas.

    Qué es el modelo hub-and-spoke y por qué importa en el sector público

    El esquema hub-and-spoke —nodo central y radios— es un patrón organizacional que separa la definición de políticas y estándares (el hub) de la ejecución y custodia operativa de los datos (los spokes). En el contexto de gobernanza de datos, el hub suele ser una oficina o comité central de gobierno —con participación del Chief Data Officer o equivalente— que establece definiciones maestras, lineamientos de calidad y reglas de acceso. Los spokes son las áreas de negocio o dependencias que implementan esas políticas sobre sus propios dominios de datos, con data stewards designados que actúan como puente entre la política central y la realidad operativa de cada unidad.

    Este modelo está documentado en el DAMA-DMBOK como una de las estructuras organizacionales recomendadas para programas de data governance, particularmente en organizaciones grandes con múltiples dominios temáticos. Su ventaja frente a un esquema puramente centralizado es la escalabilidad: el hub no necesita conocer cada dataset de cada dependencia, sino garantizar que los stewards de cada spoke operen con el mismo lenguaje de datos. En un municipio grande, eso puede significar la diferencia entre un programa de gobernanza que funciona y uno que muere en el primer año por falta de adopción.

    Lo que Cleveland implementó

    Según se informó, Cleveland articuló su programa en torno a una oficina central de datos que define los marcos de referencia —incluyendo diccionario de datos, criterios de calidad y políticas de acceso— mientras cada área municipal opera como spoke con responsabilidad sobre sus propios activos de información. La clave del diseño no es técnica sino organizacional: los data stewards de cada dependencia tienen autoridad formal para tomar decisiones sobre sus dominios, pero dentro de los límites que fija el hub. Esto reduce la fricción política que suele paralizar los programas de gobernanza en el sector público, donde ninguna área quiere ceder control sobre sus datos a una unidad central.

    Un elemento destacado es la institucionalización del rol de data steward —no como función informal sino como responsabilidad explícita dentro del organigrama. Bob Seiner, referente del enfoque Non-Invasive Data Governance, sostiene que asignar responsabilidades de datos a personas que ya las ejercen informalmente —en lugar de crear estructuras nuevas— es la forma más efectiva de lograr adopción en organizaciones complejas. Cleveland parece haber seguido una lógica similar: formalizar lo que ya ocurría de facto en cada área, pero con estándares comunes.

    El lunes por la mañana: qué puede hacer un CDO con esto

    Para un Chief Data Officer o responsable de gobierno de datos en un municipio o entidad pública latinoamericana, el modelo de Cleveland ofrece un punto de partida accionable. Antes de replicar la estructura, conviene responder tres preguntas operativas:

    • ¿Existen ya personas en cada área que, de facto, responden consultas sobre los datos de su dependencia? Esos son los data stewards naturales — el primer paso es identificarlos y darles mandato formal.
    • ¿Hay un inventario mínimo de los datasets críticos por área, con owner definido y criterio de calidad documentado? Sin eso, el hub no tiene sobre qué legislar.
    • ¿La oficina central de datos tiene autoridad para definir estándares o solo hace recomendaciones? Sin poder de definición, el hub se convierte en un comité consultivo sin efecto real.

    Si las tres respuestas son negativas, el esfuerzo inicial debería concentrarse en el mapeo de activos y la designación formal de stewards —no en la tecnología. Un catálogo de datos sin ownership asignado es un documento muerto.

    El contexto latinoamericano: gobiernos locales sin CDO formal

    En América Latina, la gobernanza de datos en el sector público sigue siendo incipiente. Brasil avanzó con la Lei Geral de Proteção de Dados (LGPD) en la gestión de datos personales, lo que obligó a muchos municipios a designar un Encarregado de Dados —equivalente al DPO europeo— pero sin necesariamente desarrollar capacidades de gobierno de datos más amplias. En Argentina, la Ley 25.326 de Protección de Datos Personales impone obligaciones a organismos públicos sobre la gestión de registros personales, pero la mayoría de los municipios opera sin una estrategia de datos documentada. En México, el INAI supervisa el cumplimiento de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, pero el ecosistema municipal público queda en gran medida fuera del radar regulatorio.

    Esta brecha entre obligación legal y capacidad operativa es precisamente donde un modelo como el hub-and-spoke resulta más útil: no requiere inversión tecnológica significativa en la fase inicial, puede implementarse con recursos humanos existentes y genera valor visible —datos más confiables, procesos de respuesta a solicitudes de acceso más ordenados— en plazos cortos. Ciudades como Bogotá o Buenos Aires, que ya cuentan con alguna infraestructura de datos abiertos, tienen una base sobre la cual construir spokes departamentales sin partir de cero.

    La pregunta no es si el gobierno local necesita gobernanza de datos — lo necesita desde hace años. La pregunta es si hay voluntad política para darle a alguien la autoridad real de decir qué es un dato confiable y qué no.

  • Agentes de IA multimodales y el nuevo reto de gobernar datos en la nube

    Agentes de IA multimodales y el nuevo reto de gobernar datos en la nube

    La irrupción de sistemas multi-agente con capacidades multimodales en plataformas cloud como AWS redefine el perímetro del gobierno de datos corporativo. Cuando múltiples agentes de inteligencia artificial consumen, transforman y visualizan datos de forma autónoma, las estructuras tradicionales de data governance quedan expuestas en sus puntos más débiles: el data lineage, el ownership y la clasificación de activos.

    Los arquitectos de datos llevan años construyendo marcos de gobierno sobre pipelines predecibles: un origen, una transformación, un destino. Los sistemas multi-agente rompen esa lógica. Cada agente puede actuar como productor y consumidor de datos de manera simultánea, encadenar llamadas a APIs externas, generar visualizaciones y alimentar a otros agentes con outputs que nunca fueron previstos en el catálogo original. El resultado es un grafo de dependencias que ningún data steward puede rastrear manualmente.

    El problema del lineage en entornos agénticos

    El data lineage —la capacidad de trazar el origen, el recorrido y las transformaciones de un dato a lo largo de su ciclo de vida— es el primer capability en tensión cuando se despliegan arquitecturas multi-agente. Según el DAMA-DMBOK (Data Management Body of Knowledge), el lineage es un componente crítico del área de conocimiento de Metadata Management, y su ausencia compromete directamente la confianza en los datos de negocio. En entornos donde los agentes de IA operan con autonomía, capturar ese linaje de forma automatizada deja de ser una buena práctica para convertirse en un requisito de gobernabilidad.

    AWS propone resolver parte de este desafío con servicios como AWS Glue Data Catalog y Amazon DataZone, que permiten registrar activos, asignar ownership y documentar transformaciones. Sin embargo, la integración de agentes construidos sobre Amazon Bedrock introduce capas de interacción que los catálogos convencionales no estaban diseñados para absorber. Cada invocación de un modelo foundation que modifica o enriquece un dataset debería registrarse como un evento de transformación, con su contexto, su versión de modelo y sus parámetros. En la práctica, ese nivel de instrumentación raramente se implementa desde el día cero.

    Ownership difuso y el rol del data steward

    Uno de los principios centrales del Data Governance Institute (Gwen Thomas) es que todo dato debe tener un owner identificado con responsabilidad formal sobre su calidad y uso. En arquitecturas multi-agente, el ownership se vuelve difuso: ¿quién es el data steward de un dataset que fue generado por un agente a partir de la síntesis de tres fuentes distintas, ninguna de las cuales estaba en el catálogo corporativo? Esta pregunta no es teórica. Es el lunes a la mañana de cualquier equipo de governance que haya habilitado agentes de IA en producción sin un marco previo de clasificación y asignación de responsabilidades.

    La respuesta operativa pasa por extender el modelo de stewardship hacia los pipelines agénticos: cada agente debe tener un owner humano registrado, sus outputs deben clasificarse automáticamente según la taxonomía de datos corporativa, y las visualizaciones generadas deben heredar el nivel de sensibilidad del dato más restrictivo que hayan consumido. Bob Seiner, referente del modelo Non-Invasive Data Governance, señala que la clave está en respetar los roles y responsabilidades existentes en lugar de crear estructuras paralelas —un principio que aplica directamente cuando se incorporan agentes de IA como actores del ecosistema de datos.

    El contexto regulatorio latinoamericano no espera

    Para los equipos de governance en la región, la presión no es solo técnica. En Brasil, la LGPD exige que las organizaciones puedan demostrar el tratamiento de datos personales en cualquier punto del ciclo de vida del dato. Si un agente de IA procesa registros con información personal sin que eso quede registrado en el linaje, la organización queda expuesta ante la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 y las disposiciones de la AAIP establecen obligaciones similares de documentación y control. Colombia, bajo la Ley 1581, también exige principios de finalidad y limitación de uso que son directamente vulnerables cuando los agentes operan sin restricciones explícitas sobre qué datos pueden consumir y con qué propósito.

    El CDO que habilita un sistema multi-agente sin actualizar su Data Management Policy está, en los hechos, creando un punto ciego regulatorio. El lunes concreto implica tres acciones: primero, mapear todos los agentes en producción y pre-producción como actores en el catálogo de datos; segundo, definir qué clases de datos pueden consumir según la taxonomía vigente (datos públicos, internos, confidenciales, restringidos); y tercero, establecer un mecanismo de captura automática de eventos de transformación —ya sea mediante hooks en el orquestador de agentes o mediante integración con el Data Catalog existente.

    Visualización: el output que nadie gobierna

    Las visualizaciones generadas por agentes multimodales representan un caso particular que los marcos de governance raramente contemplan: son outputs derivados que pueden contener datos sensibles en forma de gráficos, tablas o dashboards, y que suelen compartirse fuera del perímetro corporativo sin pasar por controles de clasificación. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el control de distribución de activos de datos como una capability de nivel 9 —de los más avanzados en el modelo de madurez. Para la mayoría de las organizaciones latinoamericanas, ese control ni siquiera existe para visualizaciones estáticas, mucho menos para las generadas dinámicamente por IA.

    Gobernar agentes de IA no es un problema futuro: es el gap que ya existe entre los frameworks de governance que las organizaciones dicen tener y los entornos que están operando hoy.

  • Liechtenstein: roban datos de 31.000 personas en un país de 41.000 habitantes

    Liechtenstein: roban datos de 31.000 personas en un país de 41.000 habitantes

    Un ciberataque contra Liechtenstein comprometió los registros de 31.000 personas, según informó el gobierno del principado el pasado domingo. El dato es contundente por su proporción: el país tiene apenas 41.000 habitantes, lo que significa que casi tres de cada cuatro ciudadanos vio sus datos expuestos en un solo incidente. La crisis desencadenó la conformación de un equipo de emergencia encabezado por el primer ministro.

    La brecha no es solo un hecho noticioso europeo. Para los equipos de gobierno de datos en América Latina, el caso expone con brutal claridad un problema estructural que la región también enfrenta: la concentración de registros en sistemas con controles de acceso insuficientes y sin una clasificación de datos que permita detectar a tiempo cuándo un activo crítico está en riesgo. Que un Estado soberano con recursos y regulación europea pierda el equivalente al 75% de su padrón poblacional en un único evento debería funcionar como señal de alerta para cualquier organización que centralice datos personales a escala.

    Qué falló: la lectura desde data governance

    Aunque los detalles técnicos del ataque aún no fueron divulgados completamente, la magnitud del compromiso sugiere fallas en al menos tres dimensiones del marco DAMA-DMBOK: clasificación y sensibilidad de los datos (Data Security), trazabilidad de accesos sobre activos críticos (Data Lineage y auditoría) y ownership formal sobre los conjuntos de datos afectados. Cuando 31.000 registros pueden ser exfiltrados sin un mecanismo de detección temprana, el problema no es únicamente técnico: es de gobierno. La ausencia de un data steward con accountability sobre ese repositorio, o la falta de alertas sobre volúmenes anómalos de consulta, son fallas de proceso, no de firewall.

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el control de datos sensibles en entornos centralizados como una capability crítica (nivel 8). Un incidente de esta escala indica que el inventario de datos personales —qué existe, dónde está, quién accede y bajo qué condiciones— no estaba suficientemente maduro para detectar o contener la exfiltración.

    El vector de riesgo que LATAM no puede ignorar

    En América Latina, los registros estatales y los sistemas de salud concentran datos personales de millones de personas con niveles de madurez en gobierno de datos que, en muchos casos, no superan el nivel 3 del DCAM. Brasil, bajo la LGPD, exige que los operadores de datos personales implementen medidas técnicas y administrativas para proteger los datos de accesos no autorizados; la ley prevé notificación a la ANPD en casos de incidente relevante. Argentina, bajo la Ley 25.326 y las disposiciones de la AAIP, tiene obligaciones similares, aunque el régimen de notificación obligatoria de brechas sigue siendo uno de los puntos más débiles del marco vigente. México, con la LFPDPPP y su reglamento, obliga a los responsables a implementar medidas de seguridad proporcionales a la sensibilidad de los datos tratados.

    El problema regional es que la norma existe, pero el dato no tiene dueño. Sin un data steward formalmente designado, sin un catálogo de datos que registre los activos de mayor sensibilidad y sin revisiones periódicas de permisos de acceso, las leyes de protección de datos funcionan como obligaciones de papel: se cumple con la política, no con el control.

    Qué hace un CDO con esto el lunes

    El caso de Liechtenstein es un ejercicio de stress-test involuntario que cualquier Chief Data Officer puede replicar internamente esta semana. Las preguntas concretas a responder son:

    • ¿Cuál es el activo de datos personales más concentrado de la organización y quién es el data steward formalmente responsable de él?
    • ¿Existe un umbral de alerta definido para volúmenes anómalos de acceso o exportación sobre ese activo?
    • ¿El plan de respuesta ante brechas incluye el procedimiento de notificación a la autoridad de control (AAIP, ANPD, INAI, SIC según jurisdicción) con los plazos legales correspondientes?
    • ¿El inventario de datos del catálogo corporativo refleja la ubicación real de los registros más sensibles, o hay shadow data fuera del inventario formal?

    Estas no son preguntas para un ejercicio anual de compliance. Son indicadores que un equipo de gobierno de datos debería poder responder en menos de 24 horas. Si la respuesta a alguna de ellas es “no lo sabemos con certeza”, ese es el riesgo prioritario a gestionar antes de que la respuesta la dé un incidente.

    La escala importa, pero no es excusa

    Es tentador leer este caso como un problema de un Estado pequeño con recursos limitados. Pero la escala juega en ambas direcciones: Liechtenstein tiene menos datos que gestionar que cualquier banco mediano de Brasil o México, y aun así el impacto proporcional fue devastador. Las organizaciones latinoamericanas que operan bases de datos de millones de registros —telcos, bancos, aseguradoras, registros civiles— enfrentan una superficie de ataque exponencialmente mayor con, en muchos casos, gobiernos de datos menos maduros que los estándares europeos que Liechtenstein está obligado a cumplir bajo el GDPR como parte del Acuerdo EEE.

    Cuando el 75% de una población queda expuesta en un solo incidente, la pregunta no es si le puede pasar a tu organización, sino qué tan rápido lo sabrías.

  • Suiza: ataque a servidores SharePoint federales compromete 200 cuentas

    Suiza: ataque a servidores SharePoint federales compromete 200 cuentas

    Un ciberataque dirigido a los servidores SharePoint de la Oficina Federal de Tecnología de la Información, Sistemas y Telecomunicaciones de Suiza (FOITT, por sus siglas en alemán) resultó en el compromiso de aproximadamente 200 cuentas de usuario, según se informó el 4 de agosto de 2026. Como medida de contención inmediata, las autoridades bloquearon el acceso externo a la plataforma para todos los usuarios fuera de la administración federal. Las autoridades indicaron que, hasta el momento, no hay evidencia de exfiltración adicional de datos.

    El incidente pone en el centro del debate un problema recurrente en entornos de gobierno digital: la exposición de plataformas de colaboración corporativa —en este caso Microsoft SharePoint— a internet sin capas de segmentación suficientes. La FOITT opera la infraestructura tecnológica crítica del gobierno suizo, lo que convierte a este caso en un ejemplo paradigmático de los riesgos que enfrenta cualquier organización que centraliza la gestión de identidades y el acceso a documentos en una sola plataforma con superficie de ataque pública.

    Qué falló desde la óptica de governance

    Analizado desde el marco DAMA-DMBOK y los controles del CDMC (Cloud Data Management Capabilities) del EDM Council, el incidente revela al menos dos vectores críticos de fallo en governance: el primero es la ausencia o insuficiencia de controles sobre el ciclo de vida de las cuentas de acceso —200 cuentas comprometidas sugieren que el proceso de revisión periódica de permisos (access recertification) no estaba operando con la frecuencia necesaria—. El segundo es la clasificación y la segmentación de datos: si la plataforma SharePoint alojaba documentación sensible sin etiquetado de confidencialidad ni políticas de acceso diferenciado, el radio de exposición potencial es indeterminable hasta completar el análisis forense.

    El concepto de data ownership resulta especialmente relevante aquí. Bajo el modelo de Non-Invasive Data Governance que propone Bob Seiner, cada conjunto de datos en una plataforma colaborativa debería tener un data steward claramente asignado, responsable de validar quién accede y con qué propósito. Sin esa asignación, los incidentes como el de la FOITT escalan silenciosamente: nadie detecta accesos anómalos porque nadie tiene la responsabilidad explícita de monitorearlos.

    El lunes del CDO: qué revisar ahora

    Para un Chief Data Officer o Data Governance Manager, este incidente es una señal de alerta accionable. Los pasos concretos a priorizar son:

    • Auditar el inventario de cuentas con acceso a repositorios colaborativos (SharePoint, Confluence, Google Drive) e identificar cuentas inactivas o sin data steward asignado.
    • Verificar que los datasets clasificados como confidenciales o restringidos en el catálogo de datos estén efectivamente protegidos con controles de acceso basados en roles (RBAC) actualizados.
    • Revisar los procedimientos de notificación ante incidentes: ¿el equipo de governance participa del proceso de crisis o solo lo hace el equipo de seguridad? La coordinación es un gap frecuente.
    • Confirmar que el data lineage de los archivos críticos permite reconstruir qué información fue accedida, por quién y desde cuándo —condición indispensable para cualquier análisis de impacto post-incidente.

    Resonancias en América Latina

    El caso suizo no es ajeno a la realidad latinoamericana. En Argentina, la Ley 25.326 de Protección de Datos Personales —y su autoridad de aplicación, la AAIP— exige que los responsables de bases de datos implementen medidas de seguridad adecuadas al nivel de sensibilidad de la información tratada. Un incidente como el de la FOITT, ocurrido en el sector público argentino, podría derivar en una investigación de oficio por parte de la AAIP y en la obligación de notificación a los titulares afectados. En Brasil, la LGPD (Lei Geral de Proteção de Dados) establece plazos y condiciones similares bajo la supervisión de la ANPD. En Colombia, la Superintendencia de Industria y Comercio ha precedentes de sanciones a entidades públicas por controles insuficientes. La pregunta para los equipos de governance en la región es si sus plataformas colaborativas están bajo el mismo esquema de supervisión que sus bases de datos transaccionales —o si operan en un punto ciego del mapa de activos de datos.

    El vector SharePoint como patrón de riesgo

    No es la primera vez que SharePoint aparece como vector de compromiso en entornos gubernamentales. La plataforma, ampliamente adoptada en administraciones públicas de toda la región por su integración con el ecosistema Microsoft 365, concentra volúmenes significativos de documentación interna que raramente pasa por procesos formales de clasificación de datos. Los equipos de governance deberían tratar las plataformas de colaboración con el mismo rigor que aplican a sus data warehouses: catálogo, clasificación, ownership, control de acceso y auditoría de uso. Mientras eso no ocurra, el servidor SharePoint de cualquier ministerio o agencia pública seguirá siendo el eslabón más débil de la cadena.

    Un incidente de 200 cuentas comprometidas puede parecer acotado; la pregunta que debería mantener despierto a cualquier CDO de gobierno es cuántos de esos activos digitales ni siquiera figuran en su catálogo.

  • GoDaddy y el reporte de impacto 2025: qué aprende un CDO de su modelo de governance

    GoDaddy y el reporte de impacto 2025: qué aprende un CDO de su modelo de governance

    GoDaddy publicó su Reporte Global de Impacto para Stakeholders 2025, con un capítulo dedicado a gobierno responsable, operaciones, ciberseguridad y privacidad de datos. Más allá de la dimensión de RSE, el documento ofrece una radiografía de cómo una empresa de infraestructura digital a escala global estructura sus capacidades de data governance — y qué elementos son replicables para organizaciones en América Latina que aún están construyendo esos marcos.

    Un reporte de impacto como espejo de madurez

    Publicar un reporte de impacto para stakeholders es, en buena medida, un ejercicio de accountability sobre decisiones de governance ya tomadas. GoDaddy —que gestiona dominios, hosting y servicios de presencia digital para millones de pequeñas y medianas empresas en todo el mundo— articula en su edición 2025 una estructura que vincula explícitamente el gobierno de datos con la operación del negocio: no como función de soporte, sino como pilar de continuidad. Ese encuadre es relevante porque los equipos de datos en la región suelen batallar exactamente ese argumento frente a sus directorios.

    El reporte aborda, según se informó, políticas de clasificación de datos, procedimientos de respuesta ante incidentes y marcos de supervisión interna del tratamiento de información. Lo interesante desde una perspectiva de DAMA-DMBOK es que estas tres dimensiones corresponden a knowledge areas distintas — Data Security, Data Quality y Metadata Management, respectivamente — pero en la práctica corporativa tienden a fragmentarse entre equipos de IT, Legal y Compliance sin un ownership claro en el nivel de data stewardship.

    El dato que importa: ownership y accountability, no solo políticas

    Uno de los patrones más comunes que emerge cuando grandes proveedores de infraestructura digital divulgan sus marcos de governance es la brecha entre política documentada y accountability operativo. Bob Seiner, referente de Non-Invasive Data Governance, sostiene que el gobierno de datos efectivo no requiere nuevos roles sino clarificar quién ya es responsable de qué dato en su trabajo cotidiano. Cuando GoDaddy describe sus controles de privacidad y ciberseguridad como parte de “operaciones responsables”, está haciendo exactamente eso: anclar el governance en la cadena de decisión existente, no en una estructura paralela.

    Para un CDO o Data Governance Manager en América Latina, la pregunta concreta es: ¿mi organización puede producir un documento equivalente — aunque sea interno — que describa quién es el data owner de cada dominio crítico, cuál es el criterio de clasificación vigente y cuál es el proceso de notificación ante una brecha? Si la respuesta es no, ese es el punto de partida, no la certificación.

    El ángulo regulatorio que LATAM no puede ignorar

    Las empresas de infraestructura digital que operan en la región — ya sea como proveedoras de hosting, SaaS o servicios de dominio — están sujetas a múltiples marcos normativos simultáneos. En Brasil, la Lei Geral de Proteção de Dados (LGPD) exige que los operadores de datos implementen medidas técnicas y administrativas proporcionales al riesgo del tratamiento, con auditoría posible por parte de la Autoridade Nacional de Proteção de Dados (ANPD). En Argentina, la Ley 25.326 y su decreto reglamentario establecen obligaciones de seguridad que recaen tanto en el responsable como en el cesionario. En México, el INAI ha profundizado en los últimos años sus criterios sobre medidas de seguridad bajo la LFPDPPP.

    Esto significa que un proveedor como GoDaddy —o cualquier empresa regional que gestione datos de clientes de múltiples países— necesita un modelo de governance capaz de mapear qué dato corresponde a qué jurisdicción y qué obligación de notificación aplica. Ese mapeo no es un ejercicio legal: es data lineage aplicado a compliance. Sin un catálogo de datos con clasificación por sensibilidad y jurisdicción, el área Legal no puede cumplir sus plazos y el CDO no puede demostrar control.

    Qué hace un CDO con esto el lunes

    La publicación del reporte de GoDaddy es una oportunidad concreta para benchmarking interno. Tres acciones accionables para esta semana:

    • Revisar si la organización tiene documentado un marco de clasificación de datos con al menos tres niveles de sensibilidad (público, interno, restringido/confidencial) y si ese marco está operativo en los sistemas de almacenamiento principales — no solo en una política en PDF.
    • Validar que existe un data owner formal para cada dominio de datos crítico (clientes, transacciones, identidad) y que esa persona conoce sus responsabilidades. Si no existe, es el momento de iniciar el proceso de asignación usando el modelo de Non-Invasive Data Governance como punto de partida de baja fricción.
    • Confirmar que el procedimiento de notificación ante incidentes tiene un paso explícito de evaluación de impacto en datos personales, con tiempos definidos por jurisdicción (72 horas bajo LGPD para casos de riesgo, plazos similares bajo la normativa argentina vigente).

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica la trazabilidad de datos sensibles entre jurisdicciones como una capability de nivel intermedio-avanzado. Muchas organizaciones latinoamericanas operan con procesos equivalentes a ese nivel sin haberlo formalizado — y sin la certificación que lo acredite frente a auditores o reguladores. Formalizar lo que ya existe suele ser más rápido que construir desde cero.

    El verdadero valor de un reporte de impacto de governance no está en su publicación: está en si la organización que lo produce puede respaldar cada afirmación con un proceso verificable. Esa es la vara con la que también deberían medirse las empresas de la región.

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