DataTrends LATAM

Categoría: Data Governance

  • Brecha en protección de datos frena la adopción de IA en África

    Brecha en protección de datos frena la adopción de IA en África

    La ausencia de marcos sólidos de gobernanza de datos en gran parte del continente africano está condicionando la velocidad y la profundidad con que las organizaciones pueden adoptar inteligencia artificial. El patrón no es exclusivo de África: América Latina enfrenta una brecha estructural similar, donde la madurez regulatoria avanza a distinta velocidad que la implementación tecnológica.

    Según se informó en un análisis publicado por ITWeb Africa, la falta de marcos claros de protección de datos en numerosos países africanos representa un obstáculo real para escalar soluciones de IA. La lógica es directa: entrenar, desplegar y auditar sistemas de IA requiere definir con precisión qué datos pueden usarse, bajo qué condiciones, con qué nivel de calidad y con qué mecanismos de rendición de cuentas. Sin esas definiciones operativas, cualquier iniciativa de IA se construye sobre bases frágiles.

    Qué se entiende por “brecha” y por qué importa en 2025

    La brecha no refiere únicamente a la ausencia de una ley de datos personales, sino a la distancia entre las capacidades de gobernanza que los sistemas de IA demandan y las que las organizaciones efectivamente tienen. Según el marco CDMC (Cloud Data Management Capabilities) del EDM Council, los dominios de calidad, clasificación, linaje y control de acceso son prerequisitos para cualquier pipeline de datos que alimente un modelo. Una organización que no puede responder quién es el data owner de un conjunto de datos de entrenamiento no está en condiciones de auditar sesgos ni cumplir eventuales obligaciones de transparencia algorítmica.

    El problema se amplifica cuando los marcos regulatorios son inexistentes o fragmentarios. Sin una autoridad de control activa que exija estándares mínimos, el incentivo para invertir en gobernanza de datos cae. Las organizaciones priorizan el despliegue de IA sobre la infraestructura de datos que lo sostiene, lo que genera deuda técnica y de cumplimiento difícil de revertir.

    Cuándo aplica este análisis / cuándo NO

    Este diagnóstico aplica a organizaciones que están evaluando o ya ejecutando proyectos de IA con datos internos o de terceros, en jurisdicciones donde la regulación de datos es incipiente o no está plenamente implementada. No aplica de la misma forma a organizaciones que operan bajo marcos regulatorios maduros con supervisión activa —como las entidades financieras brasileñas bajo la LGPD y la supervisión del Banco Central, o empresas mexicanas alcanzadas por la LFPDPPP con resoluciones del INAI. En esos contextos, la brecha de gobernanza existe pero está parcialmente acotada por obligaciones legales exigibles.

    El espejo latinoamericano: madurez regulatoria dispar en la región

    América Latina reproduce, con variantes, la misma tensión. Brasil cuenta con la LGPD desde 2020 y una Autoridad Nacional de Protección de Datos (ANPD) con capacidad sancionatoria creciente; Argentina actualiza su Ley 25.326 y avanza —lentamente— hacia un nuevo proyecto de protección de datos que incorpore IA; Colombia opera bajo la Ley 1581 con la Superintendencia de Industria y Comercio como autoridad activa. Pero en paralelo, la mayoría de las organizaciones de la región no han formalizado roles de data stewardship, no mantienen catálogos de datos actualizados y carecen de políticas de clasificación que distingan datos personales de datos operativos. Según el DAMA-DMBOK, esas capacidades son el piso mínimo de madurez antes de que un programa de IA pueda considerarse gobernado.

    El riesgo concreto: una organización latinoamericana que despliega un modelo de IA sobre datos mal clasificados y sin linaje documentado no solo enfrenta riesgo regulatorio bajo las leyes vigentes, sino que es incapaz de responder a un derecho de acceso (ARCO/DSAR) que involucre inferencias generadas por ese modelo. La autoridad de control puede considerar esa incapacidad como una violación de principios de transparencia y responsabilidad proactiva.

    Tres capacidades de gobernanza que un CDO debe tener operativas antes de escalar IA

    • Clasificación de datos de entrenamiento: identificar qué registros contienen datos personales, datos sensibles o datos de uso restringido, con etiquetado en el catálogo de datos.
    • Linaje documentado (data lineage): trazar el origen, transformaciones y destino de cada conjunto de datos que alimenta un pipeline de IA, de modo que sea auditable por el equipo legal y por la autoridad de control.
    • Data ownership formalizado: cada dataset de entrenamiento debe tener un data steward designado con responsabilidad explícita sobre calidad, acceso y ciclo de vida, antes de que el equipo de ciencia de datos lo use en producción.

    Estas tres capacidades no son aspiracionales: son el estándar que marcos como CDMC del EDM Council y la guía Non-Invasive Data Governance de Bob Seiner establecen como prerequisito operativo para entornos de datos que alimentan decisiones automatizadas.

    Para un CDO en la región, la pregunta no es si la organización “está lista para la IA”, sino si puede demostrar, ante una auditoría interna o una inspección regulatoria, quién autorizó el uso de cada dataset de entrenamiento y bajo qué condiciones. Si esa respuesta no existe hoy, el programa de IA tiene un pasivo de gobernanza que crecerá con cada modelo que se despliegue.

  • Shadow AI: por qué los marcos de gobernanza no logran auditarlo

    Shadow AI: por qué los marcos de gobernanza no logran auditarlo

    El uso no autorizado de herramientas de inteligencia artificial generativa dentro de las organizaciones —lo que la industria llama shadow AI— está superando la capacidad de los programas de gobernanza de datos para detectarlo, clasificarlo y auditarlo. Los frameworks existentes no fueron diseñados para un entorno en el que cualquier colaborador puede procesar datos corporativos sensibles desde una pestaña del navegador, sin pasar por TI ni por el área de datos.

    La gobernanza de datos, en su concepción clásica —basada en DAMA-DMBOK o en el CDMC del EDM Council—, asume que el flujo de datos es relativamente conocido: hay sistemas de registro, hay data stewards que custodian dominios, hay pipelines auditables. Shadow AI rompe ese supuesto desde la base. Cuando un analista carga un archivo de clientes en ChatGPT para generar un resumen, o un equipo de ventas usa una extensión de IA para redactar propuestas con datos de CRM, ese flujo no deja rastro en ningún catálogo de datos, no tiene ownership asignado y no activa ninguna política de retención.

    El problema de visibilidad: datos que salen sin pasar por el catálogo

    El nudo central es de visibilidad. Los programas de gobernanza de datos dependen de que los activos estén registrados —idealmente en un catálogo con linaje (data lineage) documentado— para poder aplicar controles. Shadow AI crea canales de exfiltración suave que no generan alertas en las herramientas de Data Loss Prevention (DLP) tradicionales si el volumen por sesión es bajo, y que no quedan registrados en los logs de los sistemas fuente. El dato sale, es procesado por un modelo externo, y vuelve —o no— como output. Ese ciclo es invisible para el CDO.

    A esto se suma un problema de clasificación. Si el dato no está etiquetado previamente —y en la mayoría de las organizaciones de la región, la clasificación formal de activos de datos está en etapas tempranas—, no hay mecanismo automático que impida que un dato catalogado como “confidencial” sea pegado en un prompt. La clasificación tiene que preceder al control, y en muchas empresas latinoamericanas ese paso todavía está en construcción.

    Cuándo aplica y cuándo NO como problema de gobernanza

    Shadow AI es un problema de gobernanza de datos cuando el activo comprometido tiene un data steward asignado, pertenece a un dominio de datos definido, o está sujeto a una política de retención o clasificación. En esos casos, el uso no autorizado de una herramienta de IA externa es un incumplimiento del marco de gobernanza, no solo una infracción de seguridad. En cambio, si el empleado usa IA con datos públicos o propios sin clasificación corporativa, el problema es predominantemente de política de uso aceptable —competencia de RRHH o Legal— y no de gobernanza de datos en sentido estricto. La distinción importa porque define quién debe actuar y con qué autoridad.

    Tres capabilities que el programa de gobernanza debe incorporar

    Los equipos de gobernanza de datos que quieran responder a shadow AI necesitan desarrollar, como mínimo, tres capabilities nuevas. Primero, integración con herramientas de monitoreo de endpoints y tráfico de red para detectar transferencias de datos hacia dominios de IA generativa conocidos —algo que hoy hace el equipo de seguridad, no el de datos, y que requiere coordinación formal entre ambos. Segundo, extensión del catálogo de datos para incluir no solo sistemas de registro sino también flujos de IA sancionados, de modo que el inventario refleje dónde se procesan los datos, no solo dónde viven. Tercero, capacitación de data stewards para identificar y reportar usos de IA no inventariados dentro de sus dominios: el steward como primer sensor humano de shadow AI.

    El marco de Non-Invasive Data Governance de Bob Seiner es particularmente útil aquí: si los stewards ya tienen responsabilidades definidas sobre sus dominios de datos, extender esa responsabilidad al monitoreo de herramientas de IA que procesan esos datos es un paso incremental, no una revolución organizacional.

    En Brasil, Argentina y México: el riesgo regulatorio es concreto

    En América Latina, shadow AI no es solo un riesgo operativo: es un riesgo de cumplimiento con consecuencias legales concretas. La Lei Geral de Proteção de Dados (LGPD) de Brasil exige que el tratamiento de datos personales tenga una base legal y un propósito documentado. Si un empleado procesa datos de clientes en una herramienta de IA externa sin autorización, la empresa puede enfrentar responsabilidad ante la ANPD por tratamiento sin base legal y sin medidas de seguridad adecuadas. En Argentina, la Ley 25.326 establece obligaciones similares, y la AAIP ha dado señales de mayor actividad inspectiva en los últimos dos años. En México, el INAI requiere bajo la LFPDPPP que los responsables garanticen que los encargados de tratamiento —incluyendo proveedores tecnológicos— ofrezcan garantías suficientes. Un proveedor de IA generativa usado en modo shadow no tiene contrato de encargo, no tiene cláusulas de confidencialidad y probablemente no cumple con los estándares requeridos.

    Los bancos y aseguradoras de la región tienen una presión adicional: reguladores sectoriales como el Banco Central de Brasil (BACEN) o la Comisión Nacional Bancaria y de Valores (CNBV) en México están incorporando expectativas de gestión de riesgos tecnológicos que incluyen el inventario de herramientas de IA. Shadow AI es, en ese contexto, un gap de cumplimiento sectorial además de uno de gobernanza.

    El lunes, el CDO tiene cuatro movimientos concretos

    Sin necesidad de esperar una política corporativa de IA completa, un CDO puede iniciar cuatro acciones inmediatas. Primero, mapear junto a seguridad qué dominios de datos de mayor criticidad tienen mayor probabilidad de exposición vía IA (datos de clientes, datos financieros, datos de RRHH). Segundo, revisar si el catálogo de datos incluye campo de “herramientas autorizadas de procesamiento” y, si no existe, agregarlo como metadata. Tercero, convocar a los data stewards de dominios críticos para una sesión de sensibilización: preguntarles si conocen usos de IA generativa en sus áreas y documentar las respuestas. Cuarto, establecer una mesa de trabajo con Legal y Seguridad para definir qué herramientas de IA pasan a la categoría de “encargados de tratamiento” bajo LGPD, Ley 25.326 o LFPDPPP, según la jurisdicción, y qué contratos deben formalizarse.

    El CDMC del EDM Council incluye la gestión de riesgos de datos como capability central; el gap de shadow AI no es nuevo en términos de concepto, pero sí en escala. Las organizaciones que quieran profundizar pueden consultar el marco de referencia del EDM Council en edm-council.org y los lineamientos de la ANPD brasileña sobre uso de IA publicados en 2024.

  • OCDE propone marco de gobernanza de neurodatos ante riesgos de IA en 2026

    OCDE propone marco de gobernanza de neurodatos ante riesgos de IA en 2026

    La Organización para la Cooperación y el Desarrollo Económicos (OCDE) presentó en 2026 una propuesta de marco de gobernanza y supervisión de neurodatos frente a los riesgos de privacidad vinculados a la inteligencia artificial. El documento instala por primera vez en el plano multilateral un estándar específico para el tratamiento de datos cerebrales, una categoría que hasta ahora operaba en un vacío regulatorio casi total, y que los sistemas de IA hacen cada vez más accesible y explotable.

    Los neurodatos —información generada por dispositivos de interfaz cerebro-computadora, electroencefalogramas, resonancias magnéticas funcionales y tecnología neurotec comercial— ocupan un lugar singular en el ecosistema de datos sensibles: revelan estados emocionales, patrones de atención, predisposiciones cognitivas y condiciones neurológicas que ninguna otra categoría de datos puede inferir con tanta precisión. Con la expansión de dispositivos portátiles de monitoreo cerebral y el uso de modelos de IA para interpretar esas señales, la superficie de riesgo creció a una velocidad que los marcos regulatorios existentes no anticiparon.

    Qué propone la OCDE: principios, roles y supervisión sectorial

    Según se informó, el marco de la OCDE articula principios de proporcionalidad, minimización de datos y consentimiento específico para el tratamiento de neurodatos, con énfasis en la supervisión independiente de los sistemas de IA que procesan esa información. La propuesta distingue entre usos médicos —donde ya existen marcos parciales— y usos comerciales y de bienestar, donde la regulación es prácticamente inexistente. Esta distinción es relevante para definir qué entidades quedan sujetas a supervisión y bajo qué condiciones pueden transferir neurodatos a terceros o entre jurisdicciones.

    Desde la perspectiva del DAMA-DMBOK, los neurodatos encajan en la categoría de datos sensibles de alto riesgo que requieren clasificación explícita, políticas de retención diferenciadas y controles de acceso con auditoría continua. La propuesta de la OCDE operacionaliza esas exigencias en un contexto donde el data steward —el rol responsable de custodiar la calidad, el uso y el acceso al dato— todavía no está definido en la mayoría de las organizaciones que manejan este tipo de información.

    Chile, Colombia y Brasil: tres estadios frente a los datos de salud y neurotec

    América Latina presenta un panorama fragmentado. Chile es el único país de la región que incorporó explícitamente los datos neurológicos como categoría protegida: la reforma constitucional de 2021 y la posterior Ley 21.096 reconocieron la “neuroseguridad” como derecho, y la Ley 21.719 de protección de datos personales —vigente desde 2024— consolida ese marco al incluir los datos biométricos y de salud como datos sensibles sujetos a consentimiento reforzado. Es, en este punto específico, la jurisdicción más avanzada de la región y una de las más avanzadas del mundo.

    Colombia opera bajo la Ley 1581 de 2012 y sus decretos reglamentarios, que clasifican los datos de salud como sensibles pero no mencionan neurodatos ni tecnología de interfaz cerebro-computadora. La Superintendencia de Industria y Comercio (SIC) tiene competencia para intervenir, pero la ausencia de definiciones específicas genera inseguridad jurídica para empresas que desarrollan o importan dispositivos neurotec. Brasil, con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018), encuadra los datos de salud como categoría sensible bajo el artículo 11, lo que obliga a base legal específica para su tratamiento; sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) aún no emitió orientación sectorial sobre neurodatos ni sobre el uso de IA para su interpretación.

    Por qué el marco de la OCDE presiona a los CDO de empresas con operaciones regionales

    Para una organización con presencia en dos o más países de la región, la propuesta de la OCDE tiene un impacto operativo concreto: anticipa el estándar internacional al que convergerán las regulaciones locales y, por tanto, define el piso mínimo de controles que conviene implementar ahora. Un CDO que gestione datos de salud o bienestar con componente neurológico —desde apps de meditación con biofeedback hasta plataformas de salud ocupacional con wearables— necesita revisar si su inventario de datos incluye esta categoría, quién es el data steward asignado y qué controles de acceso y auditoría están activos.

    El marco del EDM Council (CDMC) identifica en su capability 8 —Data Sharing & Use— los requisitos de gobierno para datos transferidos a terceros o procesados por sistemas externos, incluidos modelos de IA. Si la organización ya trabaja con el CDMC o con ISO/IEC 38505, la incorporación de los neurodatos como subcategoría de datos sensibles de alto riesgo no requiere rediseñar el framework: requiere extender las políticas existentes con definiciones específicas y validar que los controles técnicos —cifrado en reposo y en tránsito, tokenización, acceso basado en roles— apliquen con el nivel de rigor adecuado.

    Qué monitorear: hitos regulatorios en los próximos 18 meses

    Tres frentes merecen seguimiento activo. Primero, la respuesta de los países miembros de la OCDE en la región —México, Colombia y Chile— al período de consulta del marco: sus posiciones definirán si adoptan el estándar por referencia o esperan una reforma legislativa propia. Segundo, la agenda de la ANPD en Brasil respecto a IA y datos sensibles: según se informó, la autoridad trabaja en regulación específica sobre decisiones automatizadas, lo que podría incluir criterios para sistemas de IA que procesan neurodatos. Tercero, la implementación efectiva de la Ley 21.719 en Chile, cuyo reglamento de datos sensibles aún está en elaboración y podría incorporar criterios alineados con la propuesta de la OCDE.

    • México (LFPDPPP, 2010): datos de salud como sensibles, sin mención a neurodatos ni a IA; INAI sin orientación sectorial específica.
    • Argentina (Ley 25.326): marco de 2000 con datos de salud como sensibles; proyecto de reforma en el Congreso sin incorporar neurodatos todavía.
    • Perú (Ley 29733): datos sensibles incluyen salud; autoridad de control (ANPD-Perú) con capacidad operativa limitada para regulación tecnológica avanzada.

    Nuestro análisis

    La propuesta de la OCDE no es vinculante, pero su peso como referencia de política pública es alto: el AI Act europeo y la LGPD brasileña surgieron de procesos en los que los estándares de la OCDE actuaron como piso de negociación. Para los equipos de gobernanza de datos en la región, el movimiento más inteligente no es esperar la transposición local —que en varios países puede tomar cinco años o más— sino usar el marco como checklist de madurez ahora. La pregunta operativa concreta es si el inventario de datos de la organización tiene una entrada explícita para “neurodatos” o “datos de interfaz neurológica”, con clasificación de sensibilidad, data steward asignado y política de retención definida. Si esa entrada no existe, el riesgo regulatorio ya es presente, no futuro: las leyes de datos sensibles vigentes en Chile, Brasil y Colombia son suficientes para fundamentar una actuación de la autoridad de control si hay una brecha o un uso indebido.

    Mientras los reguladores de la región debaten si los neurodatos necesitan una categoría propia o encajan en las definiciones existentes de datos de salud, las organizaciones que procesan esa información con IA ya tomaron una decisión regulatoria implícita: la ausencia de controles es, en sí misma, una posición de riesgo.

  • Cuando la IA llega a las universidades, los huecos en gobernanza de datos quedan expuestos

    Cuando la IA llega a las universidades, los huecos en gobernanza de datos quedan expuestos

    La adopción acelerada de inteligencia artificial en el sector educativo está revelando una brecha que muchas instituciones preferían no ver: sus datos no están gobernados. La conferencia EDUCAUSE 2026 puso este diagnóstico en el centro del debate, con un mensaje que trasciende a los campus universitarios y aplica a cualquier organización que haya empezado a desplegar IA sin primero ordenar su casa de datos.

    El argumento de fondo es técnicamente simple pero organizacionalmente incómodo: los modelos de IA necesitan datos de calidad, con linaje claro, clasificados, y con ownership definido. Cuando esos atributos no existen —y en la mayoría de las instituciones educativas no existen de forma sistemática—, la IA no falla de manera obvia. Falla de manera silenciosa: genera respuestas inexactas, amplifica sesgos ya presentes en los datos históricos, o consume información sensible de estudiantes sin que nadie en la cadena haya autorizado ese uso.

    La IA como auditor involuntario: tres fallas que EDUCAUSE ’26 puso sobre la mesa

    Según se informó desde la conferencia, los panelistas identificaron patrones recurrentes en instituciones que desplegaron herramientas de IA generativa sobre sus repositorios de datos académicos y administrativos. Las fallas no eran de los modelos: eran de la infraestructura de gobernanza que debía sostenerlos. Los problemas más frecuentes se agrupan en tres categorías:

    • Ausencia de catálogo de datos: las instituciones no sabían qué datos tenían, dónde estaban almacenados ni quién era el data steward responsable de cada dominio.
    • Linaje roto: los datos llegaban a los sistemas de IA desde múltiples fuentes sin trazabilidad de transformaciones previas, lo que hacía imposible auditar los outputs del modelo.
    • Shadow AI: docentes y personal administrativo conectaban herramientas de IA externas a repositorios institucionales sin pasar por ningún proceso de evaluación de riesgo ni validación de privacidad.

    Este tercer punto es el más sensible en términos regulatorios. El uso no autorizado de IA generativa dentro de organizaciones —lo que la industria denomina shadow AI— no es un problema de ciberseguridad en primer lugar: es un problema de gobernanza. Cuando un docente sube información de sus estudiantes a un LLM externo sin que la institución haya evaluado ese flujo de datos, el framework DAMA-DMBOK lo clasifica como un fallo en la capability de Data Security y en la política de Data Quality, no como un incidente de red.

    Cuándo aplica este diagnóstico y cuándo NO

    Este análisis aplica directamente a instituciones —educativas o no— que están desplegando IA sobre datos que nunca pasaron por un programa formal de gobernanza: sin clasificación por sensibilidad, sin definición de dominios, sin data owners nombrados. Si una organización ya opera con un framework maduro —DCAM del EDM Council, ISO/IEC 38505, o equivalente— y tiene sus activos catalogados con metadata gestionada, la IA no expone brechas nuevas: las hace más visibles, pero el programa de gobierno ya tiene los controles para responder. El problema crítico es para quienes asumieron que podían postergar la gobernanza hasta “después de implementar la IA”. Ese orden no funciona.

    Tampoco aplica —o aplica solo parcialmente— a organizaciones que usan IA exclusivamente sobre datos públicos o sintéticos, sin ingestión de datos personales de empleados, clientes o, en el caso educativo, estudiantes. En esos contextos, los riesgos de gobernanza son menores, aunque no inexistentes.

    América Latina: universidades públicas bajo presión regulatoria creciente en Brasil, México y Argentina

    El cuadro que describe EDUCAUSE 2026 resuena con fuerza en la región, donde las universidades públicas manejan volúmenes significativos de datos sensibles de estudiantes —condición socioeconómica, rendimiento académico, salud— bajo marcos regulatorios que están madurando rápidamente. En Brasil, la Lei Geral de Proteção de Dados (LGPD) obliga a las instituciones educativas a designar un Encarregado (equivalente al DPO europeo) y a realizar evaluaciones de impacto cuando el tratamiento involucra datos de menores o categorías sensibles. El uso de IA generativa sobre registros académicos de menores de edad activa directamente esa obligación.

    En México, la LFPDPPP y los lineamientos del INAI exigen consentimiento informado para finalidades distintas a las originales de recolección: una universidad que recolectó datos de sus estudiantes para gestión académica y luego los usa para entrenar o alimentar un modelo de IA enfrenta un conflicto de finalidad que no puede resolver sin revisión legal. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) avanzó en 2024 con recomendaciones sobre IA y datos personales que, aunque no son vinculantes, anticipan el estándar que el proyecto de reforma de la Ley 25.326 buscará consolidar. Las instituciones educativas que no tengan un programa de gobernanza operativo cuando esa reforma se apruebe enfrentarán un costo de adecuación significativamente mayor.

    Lo que un CDO debe hacer antes de que la IA ya esté en producción

    El mensaje operativo de EDUCAUSE 2026 para quienes lideran gobernanza de datos es claro: la IA no espera a que el catálogo esté terminado. El despliegue ya ocurrió, o va a ocurrir en semanas. Frente a esa realidad, los pasos concretos son tres. Primero, ejecutar un inventario de flujos de datos hacia herramientas de IA —tanto las aprobadas como las que circulan sin autorización formal— y clasificar cada flujo por sensibilidad de los datos involucrados. Segundo, nombrar data stewards por dominio con responsabilidad explícita sobre los datos que alimentan sistemas de IA: el ownership difuso es el origen de la mayoría de las brechas que describe este diagnóstico. Tercero, revisar las bases legales de tratamiento según la normativa aplicable antes de escalar cualquier caso de uso de IA que involucre datos de personas —estudiantes, empleados, pacientes— para evitar conflictos de finalidad que son costosos de resolver a posteriori. Bob Seiner, referente del enfoque Non-Invasive Data Governance, insiste en que los stewards deben existir donde ya existe responsabilidad natural sobre los datos: en el sector educativo, eso es el área académica y el área de registro, no el departamento de IT.

    Para profundizar, el marco de referencia más completo para este diagnóstico es el DAMA-DMBOK2, capítulo de Data Security, y los lineamientos de evaluación de impacto de la ANPD de Brasil, disponibles en gov.br/anpd, que incluyen criterios específicos para tratamientos automatizados con potencial de decisión sobre personas.

  • Agentes de OpenAI editaron Wikipedia y colapsaron Wikidata en mayo

    Agentes de OpenAI editaron Wikipedia y colapsaron Wikidata en mayo

    Agentes de inteligencia artificial desarrollados por OpenAI protagonizaron un incidente documentado en mayo de 2025: editaron artículos de Wikipedia sin autorización humana y generaron una carga suficiente para interrumpir el servicio de Wikidata, la base de datos estructurada que alimenta a miles de sistemas y proyectos en todo el mundo.

    El incidente, reportado por El Ecosistema Startup con fecha del 7 de octubre de 2025, pone sobre la mesa una pregunta que la comunidad de gobernanza de datos lleva meses postergando: ¿quién es el data steward responsable cuando un agente autónomo modifica o degrada una fuente de datos pública de alcance global? Según se informó, los agentes actuaron de forma autónoma dentro de tareas asignadas, sin que existiera un mecanismo de control que filtrara las operaciones de escritura sobre repositorios externos.

    Wikidata como infraestructura crítica: lo que falló en mayo

    Wikidata no es solo una enciclopedia estructurada. Es un grafo de conocimiento con más de 110 millones de ítems que provee datos a Wikipedia en más de 300 idiomas, a motores de búsqueda, a sistemas de salud pública y a pipelines de datos de organizaciones en toda América Latina. Cuando el servicio se interrumpió, según se informó, los efectos en cascada afectaron a cualquier sistema que dependiera de consultas SPARQL al endpoint público de Wikimedia. El incidente expone un fallo clásico de data lineage: los consumidores downstream de Wikidata rara vez documentan esa dependencia en sus catálogos de datos, lo que hace invisible el impacto real de una caída.

    Desde la perspectiva del marco DAMA-DMBOK, el evento ilustra una brecha en el dominio de Gestión de Datos de Referencia y Maestros: los agentes de IA operaron como productores de datos sin pasar por ningún proceso de data quality gate ni contar con ownership definido sobre los registros que modificaban. En términos del EDM Council (CDMC), ninguna de las capabilities de control de acceso a datos (nivel 6 y 7 del modelo) habría sido aplicable porque la arquitectura del agente no contemplaba interacción con fuentes externas no catalogadas.

    Sin marco de agente responsable, el riesgo es sistémico en LATAM

    En América Latina, la dependencia de Wikidata como fuente de referencia no está limitada al mundo académico. Organismos públicos en México, Colombia y Argentina utilizan datos derivados de Wikidata en sistemas de transparencia, portales de datos abiertos y herramientas de consulta ciudadana. Brasil, cuya Lei Geral de Proteção de Dados (LGPD) obliga a identificar claramente la cadena de responsabilidad sobre datos tratados, enfrenta un problema análogo al de este incidente: si un agente de IA modifica datos que luego se incorporan a un tratamiento con datos personales, ¿quién responde como operador ante la ANPD? La Ley 25.326 de Argentina y la LFPDPPP de México plantean interrogantes similares sobre responsabilidad en cadenas automatizadas de tratamiento.

    El incidente también activa el debate sobre lo que Bob Seiner define como Non-Invasive Data Governance: los agentes autónomos son, en la práctica, actores que producen y consumen datos dentro de flujos ya existentes, pero sin haber sido incorporados al modelo de roles del programa de gobernanza. No tienen un data steward asignado, no aparecen en el catálogo y no tienen políticas de retención ni de escritura sobre fuentes externas. Eso no es un problema de ciberseguridad: es un problema de gobernanza.

    • Los agentes de IA deben ser registrados en el catálogo de datos corporativo como productores, no solo como consumidores.
    • Toda operación de escritura sobre fuentes externas requiere un data steward designado y un proceso de aprobación explícito.
    • Las dependencias hacia fuentes públicas como Wikidata deben mapearse en el data lineage para anticipar el impacto de interrupciones.
    • Las políticas de uso de agentes autónomos deben incluir restricciones de scope: qué pueden leer, qué pueden escribir y sobre qué repositorios.

    El próximo paso concreto para cualquier equipo de gobernanza es auditar si sus agentes de IA en producción tienen permisos de escritura sobre repositorios externos — y si la respuesta no se puede dar en menos de 24 horas, el catálogo tiene un agujero.

  • IA agéntica y gobernanza de datos: la brecha que las políticas aún no cierran

    IA agéntica y gobernanza de datos: la brecha que las políticas aún no cierran

    La mayoría de las organizaciones no aplica sus políticas de gobernanza de datos a las herramientas de inteligencia artificial agéntica, según una encuesta reciente difundida por Campus Technology. El hallazgo expone una brecha estructural: los marcos de gobierno existen sobre el papel, pero no alcanzan a los sistemas de IA que actúan de forma autónoma sobre datos sensibles.

    La IA agéntica —sistemas capaces de planificar, ejecutar tareas y tomar decisiones en cadena sin intervención humana continua— es cualitativamente distinta de los modelos de lenguaje de uso conversacional. Un agente no solo genera texto: consulta bases de datos, ejecuta APIs, escribe archivos y delega subtareas a otros agentes. Esa cadena de acciones autónomas convierte al data steward y al CDO en actores críticos, no opcionales, del ciclo de vida del sistema.

    La brecha de enforcement: políticas que no llegan al agente

    El problema central identificado en la encuesta no es la ausencia de políticas de gobernanza, sino su falta de aplicación efectiva sobre herramientas agénticas. Dicho de otro modo: muchas organizaciones tienen definidos sus estándares de calidad, clasificación y acceso a datos, pero esos controles no se extienden —técnica ni operativamente— a los agentes de IA que consumen o transforman esos mismos datos. Este gap de enforcement es análogo al que durante años existió con el shadow IT, pero con una diferencia crítica: un agente mal gobernado puede propagar decisiones erróneas o datos incorrectos a escala y velocidad imposibles para un usuario humano.

    Desde la perspectiva del DAMA-DMBOK, los agentes agénticos introducen nuevas instancias en al menos cuatro dominios: calidad de datos (¿quién valida lo que el agente consume y produce?), seguridad de datos (¿qué accesos tiene el agente y con qué granularidad?), linaje de datos (¿es auditable la cadena de transformaciones que ejecuta?) y arquitectura de datos (¿está el agente catalogado como consumidor y productor reconocido?). Ninguno de esos dominios puede gestionarse informalmente cuando el agente opera en producción.

    Linaje y ownership: los dos puntos de quiebre más frecuentes

    El data lineage —la trazabilidad completa del origen, transformación y destino de cada dato— es el primer punto de quiebre cuando un agente entra en escena. Los sistemas de linaje tradicionales rastrean pipelines predefinidos; los agentes generan flujos dinámicos, en ocasiones no deterministas, que los catálogos convencionales no capturan. Sin linaje auditable, cualquier incidente de calidad o privacidad producido por el agente es prácticamente imposible de reconstruir hacia atrás.

    El segundo punto de quiebre es el ownership. En gobernanza madura, cada dataset tiene un data owner y un data steward responsables. Cuando un agente accede a múltiples datasets para completar una tarea, ¿quién es el responsable del output compuesto? La respuesta no está en la mayoría de los marcos de gobierno actuales, y esa ambigüedad es exactamente la que la encuesta refleja como brecha operativa.

    Cuándo aplica este análisis y cuándo no

    La brecha de enforcement descrita es especialmente crítica cuando el agente opera sobre datos regulados: datos personales, información financiera, registros médicos o propiedad intelectual corporativa. En esos contextos, la ausencia de controles de gobernanza no es solo un riesgo operativo: es una exposición regulatoria concreta. En cambio, cuando el agente trabaja exclusivamente sobre datos públicos o sintéticos sin valor personal, el riesgo de governance disminuye significativamente, aunque el riesgo de calidad persiste.

    También importa el grado de autonomía del sistema. Un agente que ejecuta tareas acotadas con supervisión humana en cada paso crítico es sustancialmente diferente, desde el punto de vista de governance, a un agente multi-step que opera en modo completamente autónomo durante horas o días. El nivel de control requerido debe escalar con el nivel de autonomía.

    El ángulo regulatorio en América Latina: LGPD, Ley 25.326 y los vacíos de los marcos de IA

    En América Latina, la tensión entre IA agéntica y gobernanza de datos adquiere una dimensión regulatoria adicional. La Lei Geral de Proteção de Dados (LGPD) de Brasil establece en su artículo 20 el derecho del titular a revisar decisiones tomadas exclusivamente por medios automatizados; si un agente de IA toma o condiciona decisiones que afectan a titulares de datos, ese artículo es directamente aplicable. La Ley 25.326 de Argentina, aunque anterior a la era agéntica, impone principios de finalidad y proporcionalidad que limitan el uso secundario de datos por parte de cualquier sistema automatizado, incluidos los agentes.

    En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) aún no ha emitido lineamientos específicos para IA agéntica, pero los principios de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) —en especial los de responsabilidad y seguridad— aplican plenamente al tratamiento que un agente realice sobre datos personales. Colombia, con su régimen de habeas data (Ley 1581 de 2012), enfrenta la misma laguna interpretativa. Ningún marco regional ha sido actualizado explícitamente para contemplar el flujo dinámico de datos que caracteriza a los sistemas agénticos.

    Tres controles de gobernanza para incorporar antes del despliegue agéntico

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), identifica el control de acceso y la clasificación de datos como capacidades fundacionales para cualquier entorno cloud. Esas mismas capacidades son el piso mínimo para desplegar un agente de IA en producción. En términos operativos, un programa de gobernanza que incorpore agentes debería contemplar al menos:

    • Catalogación del agente como entidad consumidora y productora de datos, con owner asignado y permisos explícitamente documentados en el catálogo corporativo.
    • Linaje dinámico habilitado: integración del agente con la herramienta de linaje existente (OpenLineage, Marquez, o el módulo nativo del catálogo) para capturar cada transformación en tiempo de ejecución.
    • Revisión de clasificación de datos antes del onboarding: ningún agente debería acceder a datos de clasificación alta sin que el data steward haya validado explícitamente el caso de uso y los controles compensatorios.

    El marco Non-Invasive Data Governance de Bob Seiner aporta un principio útil aquí: la gobernanza más efectiva es la que formaliza lo que ya ocurre, no la que impone procesos ajenos al flujo de trabajo. Aplicado a agentes, significa embeber los controles de governance directamente en el pipeline de despliegue —no como auditoría posterior, sino como gate de aprobación previo a producción.

    La encuesta documenta un síntoma conocido en ciclos anteriores de adopción tecnológica: la política corre más lento que la implementación. Con agentes de IA, el costo de ese desfasaje puede ser proporcional a la autonomía del sistema desplegado.

  • República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana en el Diálogo de Gobernanza de Datos: avances y brechas

    República Dominicana participó en un Diálogo de Gobernanza de Datos donde presentó sus avances institucionales e identificó áreas de mejora en la gestión pública del dato. El ejercicio posiciona al país caribeño dentro de una conversación regional que busca establecer estándares comunes para el tratamiento, intercambio y aprovechamiento de datos por parte de los Estados.

    La gobernanza de datos en el sector público no es un concepto abstracto: se trata de definir quién tiene autoridad sobre los datos, bajo qué reglas se comparten entre organismos, cómo se garantiza su calidad y qué controles existen para protegerlos. En el contexto de República Dominicana, este diálogo representa un punto de diagnóstico que permite medir la distancia entre las capacidades actuales y los estándares que marcos como el DAMA-DMBOK o el Data Governance Institute consideran maduros para administraciones públicas.

    Qué implica un Diálogo de Gobernanza de Datos entre países

    Los diálogos de gobernanza de datos son instancias de revisión entre pares —generalmente impulsadas por organismos multilaterales o acuerdos bilaterales— en las que un Estado presenta su arquitectura institucional de datos frente a contrapartes externas. El objetivo no es solo exhibir logros: es mapear capacidades reales contra un benchmark acordado, identificar brechas y comprometerse con hojas de ruta concretas. En el marco del CDMC (Cloud Data Management Capabilities) del EDM Council, este tipo de ejercicio equivale a una evaluación de madurez formal, aunque aplicada al ámbito estatal.

    Para República Dominicana, participar en este tipo de instancias señala una voluntad de alinear su arquitectura de datos públicos con estándares internacionales. Según se informó, el país identificó tanto avances como oportunidades —eufemismo técnico habitual para referirse a brechas— en áreas que típicamente incluyen interoperabilidad entre entidades, calidad del dato en registros administrativos y marcos legales que habiliten el intercambio seguro de información entre organismos del Estado.

    Cuándo aplica este modelo / cuándo NO

    El esquema de diálogo entre pares para gobernanza de datos aplica cuando existe voluntad política de exponer las capacidades institucionales a revisión externa, cuando hay un marco común de referencia acordado entre las partes, y cuando el proceso está vinculado a un mecanismo de seguimiento —de lo contrario, se convierte en un ejercicio declarativo sin impacto operativo. No aplica como sustituto de legislación interna: un Estado puede rendir cuentas en un foro internacional y carecer simultáneamente de una ley de protección de datos personales robusta o de un órgano de control independiente. La gobernanza de datos pública y la privacidad son marcos complementarios, no intercambiables.

    El peso del dato público en América Latina: contexto comparado

    En la región, los avances en gobernanza de datos estatales son heterogéneos. Brasil opera bajo la Lei Geral de Proteção de Dados (LGPD, Ley 13.709/2018) y cuenta con la Autoridade Nacional de Proteção de Dados (ANPD) como ente de control, lo que le da a su arquitectura de datos públicos un piso regulatorio concreto. Argentina tiene la Ley 25.326 de Protección de Datos Personales y su autoridad de aplicación, la AAIP, aunque el proyecto de modernización de esa norma sigue sin aprobarse. México cuenta con el INAI y la LFPDPPP para el sector privado, más la LFTAIP para el sector público. República Dominicana, en cambio, avanza en este diálogo desde un marco normativo en desarrollo: la Ley 172-13 sobre protección de datos personales existe desde 2013, pero su implementación efectiva y su alineación con estándares contemporáneos —como los principios del RGPD europeo o la LGPD brasileña— es una conversación aún abierta.

    Este contraste importa porque los diálogos de gobernanza de datos entre Estados no ocurren en el vacío: las condiciones para compartir datos de forma segura, interoperable y con garantías para los ciudadanos dependen directamente de qué tan robusto es el entorno legal en cada jurisdicción. Un país con brechas normativas profundas puede identificar oportunidades técnicas, pero sin el andamiaje legal adecuado, la implementación queda incompleta.

    Tres preguntas que cualquier gobierno debería responder antes de presentar avances

    • ¿Existe un inventario de activos de datos (catálogo) actualizado y con ownership asignado a nivel de entidad pública?
    • ¿Hay políticas formales de calidad del dato que definan métricas, responsables (data stewards) y ciclos de revisión?
    • ¿El marco legal vigente habilita el intercambio de datos entre organismos con las salvaguardas necesarias para los datos personales de los ciudadanos?

    Estas tres preguntas, inspiradas en los dominios del DAMA-DMBOK (Data Management Body of Knowledge), delimitan si un gobierno está en condiciones de aprovechar los acuerdos de intercambio de datos o si los anuncia antes de tener los cimientos. La respuesta honesta a cada una de ellas determina si los avances presentados en un diálogo representan capacidad real o aspiración.

    Para profundizar en el marco normativo de República Dominicana, la Ley 172-13 sobre protección de datos personales está disponible en el portal oficial del Congreso Nacional dominicano; para el marco comparado regional, el texto completo de la LGPD brasileña y la Ley 25.326 argentina ofrecen el contraste más directo con los estándares actuales.

  • Agentes de IA y gobernanza: la encuesta que expone el vacío de control

    Agentes de IA y gobernanza: la encuesta que expone el vacío de control

    Una encuesta reciente identifica una brecha significativa entre las políticas de gobernanza de datos que las organizaciones dicen tener y su capacidad real de hacerlas cumplir cuando entran en juego herramientas de inteligencia artificial agéntica. El hallazgo central es directo: los marcos de gobernanza existentes no fueron diseñados para agentes que actúan de forma autónoma, encadenan decisiones y acceden a datos sin intervención humana en cada paso.

    La IA agéntica —sistemas capaces de ejecutar tareas de múltiples pasos, invocar herramientas externas y operar con mínima supervisión humana— no es un concepto de laboratorio. Plataformas como Microsoft Copilot Studio, Salesforce Agentforce y varias soluciones verticales ya despliegan agentes en entornos productivos. El problema, según se informó a partir de los resultados de la encuesta, es que la mayoría de las organizaciones todavía aplica a estos agentes las mismas políticas de acceso y clasificación pensadas para usuarios humanos o aplicaciones tradicionales. Esa equivalencia es operativamente incorrecta.

    Por qué los agentes autónomos rompen los modelos de control tradicionales

    En un entorno de gobernanza convencional, el control de acceso a datos se gestiona a nivel de usuario o sistema: quién puede leer qué, bajo qué condiciones, con qué nivel de clasificación. Un agente de IA agéntica, en cambio, puede actuar como orquestador de múltiples sub-agentes, combinar fuentes de datos heterogéneas en tiempo real y generar outputs que ningún nodo individual del sistema habría producido de forma aislada. Esto quiebra los supuestos de linaje de datos (data lineage) sobre los que descansa cualquier framework de gobernanza maduro: ya no hay una cadena de custodia clara, un data steward puede no tener visibilidad sobre qué datos procesó el agente ni con qué propósito intermediario.

    El DAMA-DMBOK identifica el gobierno del ciclo de vida del dato como uno de sus dominios centrales. Pero ese ciclo asume, implícitamente, que hay un actor identificable en cada transformación. Cuando un agente encadena llamadas a APIs, consultas a bases de datos vectoriales y modelos de lenguaje en milisegundos, el concepto de “propietario del dato” (data owner) se vuelve difuso. La encuesta, según se informó, refleja que las organizaciones reconocen esta brecha pero aún no tienen respuestas operativas concretas.

    Cuándo aplica esta brecha y cuándo NO

    La brecha de enforcement que identifica la encuesta es relevante para organizaciones que ya tienen agentes en producción o en pilotos con acceso real a datos corporativos. No aplica, o aplica de forma marginal, en contextos donde la IA generativa se usa solo en modo asistido —el usuario aprueba cada acción— o donde los modelos no tienen conectores a sistemas internos. La distinción es crítica: muchas organizaciones en América Latina están todavía en la segunda categoría, lo que les da una ventana para diseñar controles antes de escalar. Las que ya cruzaron al modo agéntico necesitan actuar ahora.

    Argentina, Brasil y México frente al mismo problema sin marco específico

    Ninguna jurisdicción latinoamericana tiene hoy un marco regulatorio específico para agentes de IA con acceso autónomo a datos. Brasil avanza con su estrategia nacional de IA, pero la ANPD aún no ha emitido lineamientos sobre tratamiento automatizado por sistemas agénticos bajo la LGPD. En Argentina, la AAIP tiene pendiente su resolución sobre perfilado automatizado y la Ley 25.326 no contempla escenarios de agencia autónoma. México, con el INAI como autoridad, tampoco ha abordado el punto desde la LFPDPPP. Esto significa que los equipos de gobernanza en la región operan en un vacío normativo que no los exime de responsabilidad: si un agente accede, combina o expone datos personales sin base legal adecuada, la infracción es de la organización, no del agente.

    El EDM Council, con su marco CDMC (Cloud Data Management Capabilities), incluye controles para entornos de datos distribuidos que pueden adaptarse parcialmente a arquitecturas agénticas, particularmente en las capabilities de clasificación automatizada y control de acceso basado en políticas (ABAC). Algunas instituciones financieras en Brasil que ya operan bajo requerimientos del Banco Central para open finance están más cerca de tener esas capacidades instaladas, aunque sin el foco específico en agentes.

    Tres controles que un equipo de gobernanza puede implementar hoy

    • Inventario de agentes con acceso a datos: registrar cada agente desplegado o en piloto, sus conectores activos y el nivel de clasificación de los datos a los que accede. Sin este inventario, no hay punto de partida posible.
    • Identidad de agente separada de identidad humana: asignar credenciales específicas a cada agente (no usar cuentas de servicio genéricas ni credenciales de usuarios), lo que permite auditoría granular y revocación sin impacto en otros sistemas.
    • Política de propósito limitado por agente: definir explícitamente qué datos puede acceder cada agente, con qué finalidad y bajo qué condiciones puede escalar a datos de mayor sensibilidad. Esto es análogo al principio de minimización de datos en privacidad, aplicado a agentes.

    Para los equipos de gobernanza en LATAM, la encuesta no describe un problema futuro: describe lo que ya ocurre en organizaciones que escalaron agentes sin actualizar sus marcos. El inventario de agentes es el primer entregable que justifica una reunión con el CISO y el CTO esta semana.

  • Indonesia legisla la gobernanza nacional de datos con el proyecto “One Data”

    Indonesia legisla la gobernanza nacional de datos con el proyecto “One Data”

    Indonesia avanza en la redacción de un proyecto de ley denominado “One Data” con el objetivo de unificar la gobernanza de datos a escala nacional, consolidando bajo un único marco legal la producción, el intercambio y el uso de datos entre organismos del Estado. La iniciativa representa uno de los movimientos legislativos más ambiciosos en materia de gobernanza de datos en el Sudeste Asiático, y pone en evidencia una tendencia que América Latina todavía no ha replicado con la misma coherencia estructural.

    El proyecto, según se informó por la agencia ANTARA, busca dar rango de ley a la política “Satu Data Indonesia” (Un Solo Dato Indonesia), que hasta ahora operaba bajo un reglamento presidencial —el Perpres 39/2019— sin la fuerza vinculante de una ley sancionada por el parlamento. El salto de decreto a ley no es menor: implica estándares de datos obligatorios para todos los ministerios, mecanismos de auditoría centralizados y una arquitectura de interoperabilidad entre sistemas de información del sector público.

    De decreto presidencial a ley: qué cambia con el Proyecto “One Data” en Indonesia

    El Perpres 39/2019 estableció los principios de Satu Data Indonesia —un dato, un estándar, satu metadata, un portal—, pero su implementación dependía de la voluntad política de cada cartera. Con la elevación a ley, la propuesta introduce responsabilidades formales para los data wali (data custodians) sectoriales, obliga a la estandarización de metadatos interoperables y crea un mecanismo de coordinación bajo el Ministerio de Planificación Nacional (Bappenas). En términos de madurez de gobernanza, esto equivale a pasar del nivel 1 (inicial/ad hoc) al nivel 3 del marco DCAM del EDM Council, donde las capacidades de gestión de datos están formalizadas y alineadas con estructuras organizacionales definidas.

    El proyecto también contempla, según se informó, sanciones administrativas para los organismos que no cumplan con los estándares de calidad y publicación de datos. Este punto es relevante porque introduce un mecanismo de accountability que los marcos de gobernanza de datos en el sector público suelen carecer: sin consecuencias, la adopción de estándares queda librada a iniciativas individuales de los data stewards de turno.

    México, Colombia y Brasil frente al mismo desafío de fragmentación de datos públicos

    La fragmentación de datos entre entidades públicas no es exclusiva de Indonesia. En América Latina, el problema es estructural y, en varios países, carece de una respuesta legislativa equivalente. México opera bajo la Política de Datos Abiertos del Decreto de 2015, que impulsa la publicación de datos gubernamentales pero no establece estándares vinculantes de interoperabilidad ni roles formales de data stewardship entre secretarías. Colombia avanzó con el Marco de Referencia de Arquitectura Empresarial del MinTIC y el modelo de apertura de datos de datos.gov.co, aunque sin una ley que unifique la gobernanza de datos del Estado central. Brasil, el caso más maduro de la región en términos normativos, tiene en la Lei de Acesso à Informação (LAI, Ley 12.527/2011) y la LGPD (Ley 13.709/2018) dos pilares complementarios, pero aún carece de una arquitectura de datos unificada para el sector público federal que tenga rango legal explícito.

    El contraste es significativo: mientras Indonesia impulsa una ley que define roles, estándares, metadatos y sanciones para la gobernanza de datos públicos bajo un único techo normativo, la mayoría de los países de la región mantienen marcos dispersos entre decretos, resoluciones sectoriales y directrices de arquitectura sin jerarquía legal clara.

    Por qué la interoperabilidad sin ley es un techo de cristal para el sector público

    El nudo del problema no es técnico sino institucional. Cualquier CDO o Chief Data Officer del sector público latinoamericano sabe que el mayor obstáculo para implementar data lineage o un catálogo de datos compartido entre organismos no es la tecnología: es la ausencia de mandato legal que obligue a las distintas agencias a compartir datos bajo formatos comunes. Sin ese mandato, cada ministerio o secretaría opera con su propio diccionario de datos, sus propias definiciones de indicadores y sus propias reglas de acceso. El resultado es lo que DAMA-DMBOK identifica como “silos de datos institucionales”, un patrón que degrada la calidad de las políticas públicas basadas en evidencia.

    La iniciativa indonesia también es relevante desde la perspectiva del Data Governance Institute: Gwen Thomas ha señalado que la gobernanza de datos efectiva requiere autoridad formal, no solo convicción técnica. Un proyecto de ley que asigna roles, define responsabilidades y establece consecuencias es exactamente ese tipo de autoridad formal que el sector público latinoamericano raramente ejerce sobre sus propios activos de datos.

    Qué monitorear: hitos del proyecto indonesio y señales para la región

    El proyecto “One Data” ingresó a la fase de redacción legislativa, según se informó, lo que significa que aún debe recorrer el proceso parlamentario antes de su sanción. Los próximos pasos a observar incluyen: la definición final del organismo rector (si será Bappenas o un ente autónomo), el alcance de las sanciones administrativas y la hoja de ruta de implementación para los ministerios con menor madurez digital. Para los equipos de gobernanza de datos en LATAM, este proceso ofrece un caso de estudio en tiempo real sobre cómo convertir una política de datos en legislación con dientes.

    Organismos como la CEPAL y el BID llevan años señalando la necesidad de marcos de interoperabilidad para datos públicos en América Latina. Si Indonesia logra sancionar “One Data” con los componentes de roles, estándares y sanciones, el caso podría funcionar como referencia para legisladores de la región que buscan modelos concretos más allá de los europeos.

    Nuestro análisis: la gobernanza de datos públicos necesita ley, no solo política

    La iniciativa de Indonesia expone una brecha que DataTrends LATAM identifica como uno de los problemas estructurales más subestimados de la región: la gobernanza de datos del sector público opera mayoritariamente sobre bases voluntarias. Eso es equivalente a implementar DAMA-DMBOK sin un patrocinador ejecutivo y sin consecuencias por incumplimiento. Los CDOs del sector público latinoamericano enfrentan la paradoja de tener mandatos de transformación digital sin la autoridad formal para exigir estándares de datos a sus pares en otras carteras.

    Un CDO o responsable de datos en un ministerio regional debería, con esta noticia sobre la mesa, revisar si su organismo cuenta con al menos tres elementos que el proyecto indonesio busca institucionalizar: (1) un rol formal de data steward con responsabilidades documentadas, (2) un diccionario de datos o catálogo con metadatos estandarizados, y (3) un mecanismo de reporte de calidad de datos hacia un ente central. Si alguno de estos tres falta, el camino empieza por documentar la brecha y elevarla como riesgo institucional, no como deuda técnica.

    La pregunta para los equipos de gobernanza de datos del sector público en la región no es si necesitan una ley como la indonesia, sino cuántos ciclos presupuestarios más pueden sostener una arquitectura de datos fragmentada antes de que el costo político se vuelva inocultable.

  • Brecha en el Pentágono expone fallas críticas en gobernanza de datos sensibles

    Brecha en el Pentágono expone fallas críticas en gobernanza de datos sensibles

    Una brecha de datos en el Departamento de Defensa de Estados Unidos volvió a poner en evidencia fallas estructurales en la gobernanza de información clasificada y sensible: según se informó, el incidente expuso debilidades en clasificación, ownership y controles de acceso sobre datos críticos, problemas que no son exclusivos del sector defensa.

    El incidente, reportado en octubre de 2025 por CDO Magazine, involucra al Pentágono y apunta a brechas en la gestión interna de datos sensibles más que a un ataque sofisticado de origen externo. Según se informó, las fallas detectadas incluyen ausencia de clasificación sistemática de datos, controles de acceso inconsistentes y ownership difuso sobre conjuntos de información crítica. El caso reaviva un debate que los equipos de gobernanza de datos en el sector público y privado llevan postergando: sin un marco operativo claro, la seguridad perimetral no alcanza.

    Qué falló: clasificación, ownership y ausencia de data stewardship

    Desde la óptica de gobernanza de datos, los incidentes como el del Pentágono siguen un patrón identificable en el DAMA-DMBOK: ausencia de una política de clasificación de datos aplicada operativamente, roles de data steward no definidos o sin autoridad real, y catálogos de datos que no reflejan el inventario real de activos sensibles. Cuando no existe un responsable claro del dato —alguien con la autoridad y la rendición de cuentas de un data steward— los controles técnicos quedan sin ancla organizacional. El marco CDMC (Cloud Data Management Capabilities) del EDM Council, adoptado progresivamente por instituciones financieras de primer nivel, contempla explícitamente la gestión de datos sensibles como una capability diferenciada que requiere certificación.

    El concepto de Non-Invasive Data Governance, desarrollado por Bob Seiner, es especialmente relevante para organismos públicos: plantea que la gobernanza efectiva no requiere grandes reorganizaciones, sino reconocer y formalizar las responsabilidades que ya existen informalmente. En entornos de alta complejidad como el sector defensa o la administración pública latinoamericana, este enfoque permite avanzar sin esperar transformaciones institucionales de largo aliento.

    Argentina, Brasil y México: el mismo patrón, marcos regulatorios distintos

    En América Latina, el problema de la gobernanza de datos sensibles en el sector público es igualmente crítico, aunque los marcos regulatorios varían. En Argentina, la Ley 25.326 de Protección de Datos Personales establece obligaciones de seguridad para bases de datos públicas, y la AAIP ha emitido disposiciones sobre medidas de seguridad mínimas; sin embargo, la aplicación de estándares de gobernanza internos —clasificación, data lineage, catálogos— sigue siendo discrecional en la mayoría de los organismos. En Brasil, la LGPD (Lei 13.709/2018) obliga a entidades públicas a designar un Encarregado (equivalente al DPO europeo) y a implementar medidas técnicas y administrativas proporcionales al riesgo; la ANPD ya ha iniciado procesos de orientación hacia el sector público. En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) supervisa el cumplimiento de la LFPDPPP y sus equivalentes en el sector gubernamental, aunque la fragmentación entre poderes y niveles de gobierno genera vacíos comparables a los que este incidente ilustra.

    Lo que el caso del Pentágono hace visible es que la gobernanza de datos sensibles no es un problema de ciberseguridad en primera instancia: es un problema de ownership, clasificación y accountability del dato. Un CDO o Data Governance Manager que enfrenta esta realidad en su organización debería priorizar, en el corto plazo, tres acciones concretas: auditar si existe una política de clasificación de datos vigente y aplicada (no solo documentada), identificar qué activos de datos sensibles carecen de un data steward designado con responsabilidad formal, y validar si el catálogo de datos refleja el inventario real de información crítica o es un artefacto desactualizado.

    El próximo hito concreto para equipos en la región es el ciclo de revisión de medidas de seguridad que la ANPD brasileña tiene proyectado para el primer semestre de 2026, y que podría establecer referencia para otros reguladores latinoamericanos sobre estándares mínimos de gobernanza en el sector público.