DataTrends LATAM

Categoría: Data Governance

  • Uruguay apuesta a la cooperación internacional como eje de su gobernanza de datos

    Uruguay apuesta a la cooperación internacional como eje de su gobernanza de datos

    Uruguay consolidó un nuevo paso en su estrategia de gobernanza de datos al avanzar en acuerdos de cooperación internacional, según informó el gobierno uruguayo a través de su portal oficial GUB.UY. El movimiento posiciona al país como uno de los actores más activos de la región en materia de alineación normativa transfronteriza, en un contexto en que América Latina debate cómo coordinar marcos regulatorios sin perder soberanía sobre los datos.

    La iniciativa, anunciada en octubre de 2025, se inscribe en una tendencia global: los países reconocen que la gobernanza de datos no puede ser exclusivamente doméstica cuando los flujos de información cruzan fronteras en milisegundos. Uruguay, con una trayectoria reconocida en protección de datos —fue el primer país de América Latina en obtener la declaración de adecuación de la Unión Europea bajo el GDPR— vuelve a buscar que su marco normativo sea compatible con estándares internacionales de alto nivel.

    La Ley 18.331 de Uruguay y el valor de la adecuación europea como palanca diplomática

    La arquitectura regulatoria uruguaya descansa sobre la Ley 18.331 de Protección de Datos Personales y su decreto reglamentario 414/009, con la Unidad Reguladora y de Control de Datos Personales (URCDP) como autoridad de control. Ese andamiaje fue suficiente para que la Comisión Europea confirmara la adecuación del país, lo que significa que las transferencias de datos personales desde la UE hacia Uruguay no requieren garantías adicionales. Esa credencial diplomática —que solo comparten unos pocos países fuera del espacio europeo— es la que habilita a Montevideo a sentarse en mesas de cooperación de igual a igual con bloques que de otro modo impondrían condiciones unilaterales. La nueva iniciativa de cooperación internacional, según se informó, busca capitalizar exactamente esa posición de partida.

    Argentina, Brasil y Chile: tres velocidades distintas en la carrera de la armonización

    El contraste con los vecinos regionales es significativo. Brasil opera desde 2020 con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) y cuenta con la Autoridade Nacional de Proteção de Dados (ANPD), que avanza en la reglamentación de transferencias internacionales con un enfoque de adecuación propio —aún sin reconocimiento formal de la UE—. Argentina, por su parte, tiene vigente la Ley 25.326 de Protección de los Datos Personales desde el año 2000, con una declaración de adecuación europea que data del mismo período pero cuyo mantenimiento está bajo escrutinio dado que la norma no fue actualizada para reflejar los estándares del GDPR; el proyecto de reforma que impulsa la Agencia de Acceso a la Información Pública (AAIP) lleva años sin alcanzar sanción legislativa. Chile, en tanto, aprobó en 2024 la nueva Ley 21.719 de Protección de Datos Personales, que moderniza el marco anterior y crea la Agencia de Protección de Datos Personales, aunque los plazos de implementación se extienden hasta 2026. Ninguno de estos tres países tiene hoy la combinación que ofrece Uruguay: norma vigente, autoridad operativa y adecuación europea confirmada. Esa brecha explica por qué Montevideo puede liderar conversaciones regionales de armonización sin necesitar el permiso de socios más grandes.

    Flujos de datos transfronterizos: qué cambia para empresas con operaciones en la región

    Para una empresa con operaciones en varios países de América Latina, la fragmentación regulatoria tiene costos concretos: contratos de transferencia distintos por jurisdicción, cláusulas contractuales tipo adaptadas a cada marco, y equipos jurídicos que deben monitorear estados de adecuación que cambian. Si Uruguay logra articular acuerdos bilaterales o multilaterales que establezcan puentes de reconocimiento mutuo —similar a lo que el G7 discute bajo el enfoque de “data free flow with trust”—, el beneficio operativo sería directo para compañías que usan al país como hub regional de procesamiento. La URCDP, con recursos acotados para una autoridad de control, tiene el desafío de sostener compromisos internacionales sin descuidar la supervisión doméstica; ese equilibrio será determinante para que los acuerdos no queden en declaraciones de intención.

    Qué monitorear: hitos regulatorios y negociaciones abiertas en el segundo semestre de 2025

    Hay al menos tres frentes a seguir de cerca. Primero, el contenido específico de los acuerdos anunciados: con qué países o bloques se firmaron, qué mecanismos de reconocimiento mutuo contemplan y si incluyen cláusulas de auditoría cruzada. Segundo, el estado de la reforma de la Ley 25.326 en Argentina: si el proyecto avanza, podría activar una renovación de la adecuación europea para Buenos Aires y cambiar el mapa regional. Tercero, la implementación efectiva de la Ley 21.719 chilena, que cuando entre en vigor plena tendrá una de las autoridades de control más nuevas y potencialmente más activas del cono sur. La convergencia —o divergencia— entre estos procesos determinará si la iniciativa uruguaya encuentra interlocutores regionales o queda aislada como un ejercicio bilateral con Europa.

    Nuestro análisis: la apuesta uruguaya tiene sentido, pero depende de vecinos que aún no llegaron

    Uruguay tiene un activo genuino: es el único país de América Latina que cumple simultáneamente con adecuación europea vigente, autoridad de control operativa y marco legal moderno. Eso le da credibilidad negociadora que ningún país de la región puede replicar hoy. El riesgo es que la cooperación internacional, sin masa crítica regional, produzca más ceremonias que infraestructura. La cooperación transfronteriza en gobernanza de datos necesita que al menos Brasil o Argentina normalicen sus marcos —Brasil está más cerca— para que los acuerdos uruguayos tengan efecto multiplicador. Sin eso, Montevideo puede ser un hub de referencia normativa para la UE, pero no un nodo de armonización latinoamericana. La diferencia entre los dos escenarios vale miles de millones de dólares en inversión de centros de datos y contratos de servicios digitales para la región.

    ¿Puede Uruguay sostener su ventaja regulatoria mientras Argentina reforma su ley y Chile termina de implementar la suya, o el liderazgo normativo del país pequeño depende de que sus vecinos grandes sigan retrasados?

  • Bank of America y el caso que convierte la gobernanza de datos en control antilavado

    Bank of America y el caso que convierte la gobernanza de datos en control antilavado

    Un análisis publicado por ACAMS —la principal asociación global de profesionales en prevención del lavado de dinero— reencuadra el caso Bank of America como una señal regulatoria de primer orden: cuando la gobernanza de datos falla en una institución financiera, esa falla deja de ser un problema de compliance técnico y pasa a ser evidencia de debilidad en los controles de crimen financiero. El cambio de encuadre tiene consecuencias directas para CDOs y equipos de gobierno de datos en bancos latinoamericanos.

    Durante años, la gobernanza de datos en el sector financiero fue tratada como una disciplina de arquitectura interna: quién es dueño de qué dato, cómo se cataloga, qué tan limpio está el pipeline de reporting. Las multas regulatorias llegaban por fallas en KYC (conoce a tu cliente), SAR (reportes de actividades sospechosas) o monitoreo de transacciones —no por “mala gobernanza”. Lo que el caso Bank of America, según el análisis de ACAMS, pone sobre la mesa es que esas dos dimensiones ya no son separables.

    Qué señala ACAMS sobre el caso Bank of America y los controles AML

    Según se informó en la publicación de ACAMS, el caso ilustra cómo deficiencias en la calidad, trazabilidad y ownership de los datos subyacen directamente a fallas en los programas de antilavado de dinero (AML, por sus siglas en inglés). En otras palabras: si un banco no puede demostrar que sus datos de cliente son íntegros, auditables y tienen un data steward identificable, tampoco puede demostrar que su programa de prevención funciona. Los reguladores están comenzando a tratar esa incapacidad como una falla de control, no como una deuda técnica.

    El marco conceptual que emerge es el siguiente: la gobernanza de datos pasa a ser considerada una capability de control financiero, equiparable a los controles de transacciones o a los modelos de scoring de riesgo. Esto eleva la gobernanza de datos al mismo nivel de escrutinio que los programas BSA/AML en jurisdicciones con supervisión federal estricta, y abre la puerta a que autoridades en otras regiones adopten la misma lógica.

    Brasil, Argentina y México: marcos AML que presionan sobre la calidad del dato

    En América Latina, la intersección entre AML y gobernanza de datos ya tiene referentes regulatorios concretos, aunque la articulación explícita todavía es incipiente. En Brasil, el Banco Central do Brasil (BCB) y el COAF (Conselho de Controle de Atividades Financeiras) exigen a las instituciones financieras la gestión de registros de clientes bajo estándares que, en la práctica, requieren capacidades de data lineage y data quality auditables. La Resolução BCB nº 44/2021 establece requisitos de integridad de información en programas PLD/FT (Prevenção à Lavagem de Dinheiro / Financiamento do Terrorismo) que ningún banco puede cumplir sin gobierno de datos operativo.

    En Argentina, la Unidad de Información Financiera (UIF) viene reforzando sus requerimientos de reporte electrónico estructurado —vía ROS y REOSC— que presuponen que los datos de transacciones y clientes tienen owner definido, son trazables y están sujetos a controles de calidad. Los bancos que reportan al BCRA bajo Comunicación A 8073 ya operan con capacidades de gobierno del dato que se solapan parcialmente con los requisitos CDMC del EDM Council, aunque sin la certificación formal. En México, el SITI (Sistema Interinstitucional de Transferencias de Información) administrado por la CNBV obliga a las entidades financieras a mantener registros estructurados y auditables que implican, en la práctica, un data stewardship funcional sobre los datos transaccionales.

    Por qué la distinción entre “calidad de datos” y “control de crimen financiero” dejó de ser operativa

    El problema estructural que el caso Bank of America expone no es nuevo en la literatura de gobernanza: el DAMA-DMBOK 2 ya articulaba que la calidad del dato tiene dimensiones de conformidad regulatoria, no solo de utilidad analítica. Lo que cambia ahora es el origen de la consecuencia: no es un auditor interno que marca una observación de data quality, sino un regulador financiero que la convierte en hallazgo de control AML. Para un CDO en el sector bancario, eso transforma el presupuesto de gobernanza de un ítem discrecional a un requisito de gestión de riesgo regulatorio.

    Bob Seiner, referente en Non-Invasive Data Governance, ha argumentado consistentemente que la gobernanza de datos es más efectiva cuando se ancla en responsabilidades que ya existen en la organización, en lugar de crear estructuras paralelas. En el contexto AML, ese argumento se vuelve urgente: los compliance officers ya tienen responsabilidades legales sobre los controles antilavado; si la gobernanza de datos no está integrada a esa cadena de responsabilidad, el banco queda expuesto a que una falla técnica de datos se interprete como una falla deliberada de control.

    Qué hacer desde el rol de CDO en un banco de la región

    Para un Chief Data Officer o Data Governance Manager en una institución financiera latinoamericana, el caso Bank of America impone una revisión concreta de las siguientes dimensiones:

    • Ownership formalizado: cada dataset crítico para AML —listas de clientes, transacciones, alertas de monitoreo— debe tener un data steward identificado por nombre y cargo, no solo por dominio funcional genérico.
    • Data lineage auditable: los reguladores esperan poder rastrear cómo se construyó un reporte de actividad sospechosa. Sin lineage, el banco no puede demostrar integridad del proceso.
    • Métricas de calidad vinculadas a riesgo AML: no alcanza con reportar completitud y exactitud como KPIs internos; hay que mostrar cómo esos indicadores impactan en la capacidad de detección de operaciones sospechosas.
    • Articulación con compliance: el CDO debe tener una cadencia regular con el Chief Compliance Officer para mapear qué datos subyacen a cada control AML y qué nivel de madurez de gobernanza requiere cada uno.
    • Catálogo de datos con clasificación de riesgo regulatorio: priorizar la catalogación de activos de datos según su rol en reportes exigidos por UIF, COAF, CNBV u otras autoridades locales equivalentes.

    El marco CDMC (Cloud Data Management Capabilities) del EDM Council, y en particular sus capacidades 7 y 8 sobre gestión de datos de referencia y controles de calidad, ofrece un punto de partida estructurado para instituciones que quieran alinear su madurez de gobernanza con los requerimientos emergentes de los reguladores AML regionales.

    Nuestro análisis

    La lectura de ACAMS sobre el caso Bank of America no es un accidente editorial. ACAMS es la voz institucional del ecosistema AML global, y cuando esa comunidad adopta el lenguaje de la gobernanza de datos como control de crimen financiero, está enviando una señal a los reguladores de América Latina sobre el estándar que se espera. En Brasil, Argentina y México, las autoridades financieras tienen los instrumentos legales para hacer esa lectura: lo que falta, en muchos casos, es la articulación explícita entre los equipos de datos y los equipos de compliance dentro de las propias instituciones. Los bancos que resuelvan esa brecha interna antes de que el regulador la señale tendrán una ventaja de riesgo significativa. Los que esperen la sanción para construir el programa de gobernanza estarán recorriendo el camino más costoso.

    La pregunta que los CDOs del sector financiero en la región deberían responder hoy es directa: si su regulador local auditara mañana el lineage de los datos que alimentan sus reportes AML, ¿podría el equipo de gobernanza demostrarlo en tiempo real?

  • Cuando la voz se convierte en dato: qué enseña la litigación sobre huellas de voz

    Cuando la voz se convierte en dato: qué enseña la litigación sobre huellas de voz

    Las huellas de voz —voiceprints— son datos biométricos, y los tribunales ya están dictaminando sobre quién los puede capturar, almacenar y usar. Para los equipos de gobernanza de datos, esa jurisprudencia emergente no es un asunto legal abstracto: es una guía práctica para diseñar controles que soporten el escrutinio judicial.

    Un voiceprint es la representación matemática única de la voz de una persona, derivada de características fisiológicas y de comportamiento que permanecen estables a lo largo del tiempo. En la práctica, cualquier sistema que grabe, analice o compare voces para identificar o autenticar individuos está tratando datos biométricos. Eso cambia radicalmente el régimen de obligaciones aplicable: ya no se trata de datos de contacto o preferencias de usuario, sino de una categoría especial con requisitos de consentimiento, limitación de finalidad, plazos de retención y medidas de seguridad reforzadas.

    Por qué la litigación en EE. UU. sobre voiceprints importa fuera de ese país

    La mayoría de los casos de biometría de voz ventilados en tribunales estadounidenses invocan la Biometric Information Privacy Act (BIPA) de Illinois, vigente desde 2008. Esa ley exige consentimiento explícito previo a la recolección, prohíbe la comercialización de datos biométricos y fija plazos de destrucción. Las demandas colectivas bajo BIPA han resultado en acuerdos millonarios contra operadores de centros de llamadas, plataformas de voz sobre IP y sistemas de autenticación de bancos. Lo que estos fallos revelan no son solo sanciones económicas: revelan qué controles de gobernanza estaban ausentes cuando ocurrió el litigio. Esa información es transferible a cualquier jurisdicción.

    En América Latina, el marco legal para datos biométricos está fragmentado pero es exigente. La Ley General de Protección de Datos Personales de Brasil (LGPD) clasifica los datos biométricos como datos sensibles en su artículo 5, inciso II, y exige base legal específica para su tratamiento. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) ha emitido criterios que equiparan la biometría a datos sensibles bajo la Ley 25.326. México, a través del INAI, ha sancionado a organizaciones por capturar huellas vocales sin consentimiento expreso en servicios de atención telefónica. Chile, con su nueva Ley 21.719 de protección de datos personales, en vigor desde 2026, incluye disposiciones explícitas para datos biométricos con estándares próximos al GDPR.

    Qué falla en gobernanza cuando llega un litigio por voz

    El análisis de casos bajo BIPA y de resoluciones de autoridades latinoamericanas muestra un patrón recurrente de fallas de gobernanza, no de fallas tecnológicas. Los problemas más frecuentes son:

    • Ausencia de clasificación: los voiceprints no estaban identificados como datos biométricos en el catálogo o inventario de datos de la organización, y por tanto no recibían los controles de categoría especial.
    • Ownership difuso: el data steward responsable del activo no estaba asignado, lo que generó confusión sobre quién debía gestionar el consentimiento y los plazos de retención.
    • Ausencia de data lineage: no existía trazabilidad sobre dónde se almacenaban las grabaciones, qué sistemas las procesaban ni a qué terceros se transferían.
    • Políticas de retención sin cumplimiento efectivo: muchas organizaciones tenían políticas escritas pero carecían de controles automatizados para eliminar grabaciones al vencer el plazo.
    • Consentimiento genérico: los avisos de privacidad mencionaban “grabación de llamadas” sin distinguir entre grabación de audio para control de calidad y creación de un modelo biométrico de identificación.

    Cuándo aplica el régimen biométrico y cuándo no

    No toda grabación de voz genera un voiceprint. Una llamada grabada para control de calidad que se almacena como archivo de audio y no se analiza con algoritmos de identificación biométrica no es, en principio, un dato biométrico en el sentido jurídico. El umbral se cruza cuando el sistema extrae un template matemático de características vocales con el propósito de identificar o autenticar a la persona. Esa distinción técnica debe estar reflejada en el catálogo de datos con metadatos de clasificación precisos: “grabación de audio” y “voiceprint” son activos distintos con regímenes distintos. En términos del DAMA-DMBOK, esto corresponde a la función de Data Classification dentro del dominio de Data Security, y su correcta aplicación depende de que el data steward tenga visibilidad sobre qué hace el sistema con el audio una vez capturado.

    Tampoco aplica el régimen biométrico cuando el tratamiento del audio es puramente para transcripción automática sin extracción de características de identidad. Sin embargo, si esa transcripción luego alimenta un modelo que aprende a reconocer al hablante, el régimen biométrico se activa en esa segunda capa. Muchos incidentes de gobernanza ocurren exactamente ahí: el tratamiento inicial parecía inocuo, pero un componente de inteligencia artificial incorporó la función de identificación sin que los equipos de datos lo advirtieran.

    Controles concretos que la jurisprudencia exige tener documentados

    Los patrones de litigación permiten inferir qué controles deben estar en pie y poder demostrarse ante un tribunal o una autoridad de control. En el marco del EDM Council (CDMC), esto corresponde a las capabilities de Data Protection y Data Risk Management. Los controles mínimos que los casos judiciales han identificado como ausentes incluyen: un registro de actividades de tratamiento que diferencie explícitamente la captura de audio de la generación de voiceprints; cláusulas contractuales con proveedores de telefonía e IA que establezcan prohibiciones de uso secundario; procedimientos de eliminación verificable de templates biométricos con logs auditables; y mecanismos de consentimiento granular que distingan entre “grabación de llamada” y “creación de perfil biométrico de voz”. Un CDO que opera centros de atención al cliente o sistemas de autenticación por voz debería revisar esta semana si esos controles existen, están asignados a un owner y tienen evidencia de ejecución.

    En Argentina, la AAIP puede requerir esa evidencia en el marco de una inspección de oficio. En Brasil, la ANPD tiene competencia para iniciar procedimientos sancionatorios con multas de hasta el 2% de la facturación en Brasil, con un tope de 50 millones de reales por infracción. En México, el INAI ha precedentes de resoluciones contra empresas de telecomunicaciones por exactamente este tipo de tratamiento.

    El texto completo de la BIPA de Illinois, referencia central en la jurisprudencia analizada, está disponible en el sitio oficial de la Asamblea General del Estado de Illinois (ilga.gov), y el artículo 5 de la LGPD brasileña en la plataforma de legislación federal de Brasil (planalto.gov.br); ambos son puntos de partida obligados para cualquier equipo que esté revisando su inventario de datos biométricos.

  • DAMA llega a Kenia: qué significa para la gobernanza de datos en el Sur Global

    DAMA llega a Kenia: qué significa para la gobernanza de datos en el Sur Global

    El lanzamiento oficial de DAMA Kenya extiende la red global de gobernanza de datos al África Oriental, sumando una nueva comunidad de práctica a un framework que ya tiene presencia en más de 50 países. Para la región latinoamericana, el movimiento confirma una tendencia que los CDOs locales deberían leer con atención: los marcos de referencia como el DAMA-DMBOK dejan de ser patrimonio de economías avanzadas y se convierten en infraestructura profesional de mercados emergentes.

    DAMA International —la asociación global dedicada a la gestión y gobernanza de datos— formalizó su capítulo en Kenia según informó CIO Africa. El nuevo capítulo se incorpora a una red que incluye nodos activos en Europa, América del Norte, India, Australia y varios países de América Latina. La iniciativa apunta a profesionalizar el ejercicio de la gestión de datos en un mercado que combina expansión acelerada de infraestructura digital con marcos regulatorios todavía en consolidación.

    Qué es DAMA y qué ofrece el DMBOK a una comunidad que recién se organiza

    DAMA International publica el Data Management Body of Knowledge (DMBOK), el estándar de facto para la disciplina de gestión de datos a nivel global. El DMBOK estructura el campo en once áreas de conocimiento —entre ellas gobernanza de datos, arquitectura, calidad, seguridad, metadatos y master data management (MDM)— y sirve de base para certificaciones profesionales como el CDMP (Certified Data Management Professional). Un capítulo local no solo difunde el framework: organiza exámenes, genera comunidad de práctica y conecta a los profesionales del país con el ecosistema global. Para mercados donde la disciplina de datos no cuenta con una comunidad articulada, ese efecto de red es frecuentemente más valioso que el contenido técnico en sí mismo.

    El patrón de expansión de DAMA y lo que indica para América Latina

    La expansión de DAMA hacia África Oriental sigue un patrón ya visible en América Latina: capítulos que nacen impulsados por consultores y ejecutivos que buscan un lenguaje común con sus pares globales, y que terminan funcionando como catalizadores de demanda de gobernanza formal en sus mercados. En la región, DAMA tiene presencia documentada en Brasil, Argentina, México y Colombia. El capítulo brasileño es el más maduro, con comunidad activa en São Paulo y Rio de Janeiro, y suele articularse con las exigencias que la LGPD (Lei Geral de Proteção de Dados) impone sobre ciclo de vida del dato, lineage y ownership. En Argentina, donde la Ley 25.326 de Protección de los Datos Personales está en proceso de actualización legislativa, los data stewards y CDOs que operan bajo marcos DAMA tienen una ventaja concreta al momento de mapear flujos de datos personales y demostrar accountability ante la Agencia de Acceso a la Información Pública (AAIP).

    Cuándo aplica el modelo de capítulo DAMA / cuándo NO

    Un capítulo DAMA agrega valor real cuando existe una masa crítica de profesionales que ya trabajan con datos de manera sistemática y necesitan certificación, red de pares y actualización continua. No reemplaza una estrategia de gobernanza corporativa ni equivale a adoptar el DMBOK como política interna: son planos distintos. Una organización puede certificar a su equipo en CDMP y operar con una gobernanza de datos deficiente si no hay patrocinio ejecutivo, ownership de dominios definido y procesos de calidad activos. Del mismo modo, un mercado puede tener un capítulo DAMA vibrante y carecer de regulación de datos que exija estándares mínimos. El capítulo es condición necesaria para elevar la madurez del mercado, no condición suficiente.

    Lo que los CDOs de LATAM pueden extraer del caso Kenia

    El lanzamiento de DAMA Kenya es un recordatorio de que la gobernanza de datos se está profesionalizando de forma simultánea en múltiples mercados emergentes. Para un CDO en Ciudad de México, Buenos Aires o Bogotá, eso implica al menos tres lecturas concretas. Primero, la escasez de talento certificado en DMBOK no es exclusiva de LATAM: es un problema global con soluciones locales, y los capítulos son uno de los mecanismos para atacarla. Segundo, los marcos como el CDMC (Cloud Data Management Capabilities) del EDM Council —que comparte terreno con el DMBOK en áreas de calidad y lineage— están siendo adoptados por reguladores financieros de mercados emergentes como referencia de madurez; en Brasil, el Banco Central ya utiliza vocabulario de governance alineado con estos estándares en sus exigencias de open finance. Tercero, la consolidación de comunidades DAMA regionales genera benchmarks comparables: un CDO que participa activamente en su capítulo local puede medir la madurez de su organización contra peers reales, no solo contra cuestionarios genéricos de autoevaluación.

    Para organizaciones que aún no tienen representación formal en DAMA, el momento de evaluar la afiliación corporativa o individual es antes de que la demanda de certificación provenga de un requisito regulatorio o contractual, no después. Los capítulos de Argentina, Brasil, México y Colombia cuentan con información de membresía en el sitio de DAMA International.

    La referencia completa del DAMA-DMBOK v2 está disponible en dama.org; el EDM Council publica el framework CDMC —que incluye los niveles de madurez de cloud data management— en edmcouncil.org.

  • Colombia supera la OCDE en gobierno digital, pero la integración de datos públicos es su talón de Aquiles

    Colombia supera la OCDE en gobierno digital, pero la integración de datos públicos es su talón de Aquiles

    Colombia logró posicionarse por encima del promedio de la OCDE en madurez de gobierno digital, según se informó a partir de la edición más reciente del índice de la organización. El dato es relevante en una región donde Brasil, México y Argentina aún consolidan sus marcos de interoperabilidad. Sin embargo, el diagnóstico también expone una brecha estructural: superar métricas de adopción tecnológica no equivale a tener datos públicos integrados, interoperables y gobernados de manera coherente.

    Qué mide la OCDE y dónde quedó Colombia en el índice 2025

    El índice de Gobierno Digital de la OCDE evalúa seis dimensiones: digital by design, gobierno impulsado por datos, gobierno como plataforma, gobierno abierto, proactividad y fiabilidad. Colombia habría obtenido una puntuación agregada que supera el promedio de los 38 miembros plenos de la organización, según se informó desde Portafolio.co. El logro no es menor: el país no es miembro pleno de la OCDE —aunque se encuentra en proceso de adhesión— y compite en el índice junto a naciones con infraestructuras digitales consolidadas desde hace más de una década.

    La dimensión donde Colombia acusa mayor rezago, según la misma fuente, es la integración de servicios: la capacidad de que distintas entidades del Estado compartan datos entre sí para ofrecer trámites sin fricción al ciudadano. Esa brecha no es técnica en su origen —es de gobernanza: quién es el responsable del dato, bajo qué condiciones se comparte, quién resuelve conflictos de calidad o clasificación entre entidades.

    La Ley 1581 de 2012 y el Decreto 1413 de 2023 como marco de fondo

    Colombia opera su ecosistema de datos públicos bajo un doble marco normativo. Por un lado, la Ley Estatutaria 1581 de 2012 regula la protección de datos personales y establece restricciones al intercambio de información entre entidades públicas cuando ese intercambio involucra datos de ciudadanos. Por otro, el Decreto 1413 de 2023 —que adopta la Política de Gobierno Digital— obliga a las entidades del orden nacional a implementar estándares de interoperabilidad a través de la plataforma X-Road Colombia, adaptación local del sistema estonio. La tensión entre ambos marcos es real: los equipos jurídicos de muchas entidades interpretan la Ley 1581 como un freno al intercambio de datos, cuando en rigor la norma permite el tratamiento con base legal distinta al consentimiento si existe una función pública legítima.

    El Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) y el Departamento Nacional de Planeación (DNP) comparten responsabilidad en este ecosistema, pero la línea de ownership sobre los datos sectoriales —salud, tributario, registral— sigue siendo difusa. Esa difusión de responsabilidad es exactamente lo que los marcos de gobernanza de datos describen como ausencia de data stewardship efectivo a nivel organizacional.

    Brasil, México y Chile: tres modelos de integración con distinto grado de madurez

    La comparación regional permite calibrar dónde está parada Colombia. Brasil avanzó con la Lei Geral de Proteção de Dados (LGPD, Lei 13.709/2018) y, en paralelo, con el programa Conecta Gov, que articula APIs entre ministerios bajo supervisión de la Secretaria de Governo Digital (SGD). La ANPD brasileña ha emitido resoluciones específicas sobre el tratamiento de datos en contexto de gobierno digital, lo que da certeza jurídica al intercambio intersectorial. México, por su parte, opera la Plataforma Nacional de Transparencia bajo el INAI, pero la fragmentación entre poderes federales y estados hace que la interoperabilidad sea más aspiracional que efectiva; la LFPDPPP aplica al sector privado y la Ley General de Protección de Datos Personales en Posesión de Sujetos Obligados (2017) regula el sector público, aunque su enforcement sigue siendo inconsistente. Chile presenta el caso más avanzado en términos de diseño institucional: la Ley 21.719 de Protección de Datos Personales —promulgada en 2024— contempla disposiciones específicas para el tratamiento por parte de órganos del Estado y establece la futura Agencia de Protección de Datos con competencia sobre el sector público, algo que Colombia todavía no tiene de manera plena con la Superintendencia de Industria y Comercio (SIC).

    Por qué el dato de integración importa más que el ranking agregado

    Un índice agregado puede enmascarar desequilibrios internos. Que Colombia puntúe bien en dimensiones como gobierno abierto o proactividad —donde la publicación de datasets y la comunicación proactiva al ciudadano suman puntos— no resuelve el problema operativo de que un trámite de subsidio habitacional requiera que el ciudadano aporte documentación que el Estado ya posee en otro sistema. Esa fricción tiene un costo medible: según estimaciones del Banco Mundial para países de ingreso medio-alto, la falta de interoperabilidad en servicios públicos puede representar hasta un 2% del PIB en ineficiencia administrativa acumulada. Colombia no ha publicado una estimación propia de ese costo.

    Para los equipos de gobernanza de datos en el sector público colombiano, el diagnóstico de la OCDE es una palanca de gestión concreta. El Modelo de Gestión de Datos del sector público colombiano —articulado en la Guía para la Gestión de Datos del MinTIC— tiene correspondencia con el marco DAMA-DMBOK en sus componentes de calidad, integración y metadatos, pero su adopción efectiva por entidad varía de manera significativa. La ausencia de un catálogo de datos centralizado con ownership asignado por dominio es el punto de mayor fricción.

    Nuestro análisis: el riesgo de confundir madurez digital con gobernanza de datos

    El resultado de Colombia en el índice OCDE es genuinamente positivo y merece reconocimiento. Pero el riesgo político de un ranking favorable es que desvía la atención de las brechas que el propio índice señala. La dimensión de integración de servicios no es un detalle técnico: es el test de si el Estado puede operar como una plataforma de datos coherente o si sigue siendo un archipiélago de silos. La OCDE, en sus recomendaciones de Gobierno Digital de 2022 (OECD Recommendation on Digital Government Strategies), es explícita al señalar que la interoperabilidad requiere acuerdos de gobernanza antes que infraestructura tecnológica. Colombia tiene la infraestructura —X-Road funciona— pero los acuerdos de gobernanza intersectorial siguen siendo ad hoc, bilaterales y frágiles ante cambios de gobierno.

    El punto de acción más urgente no es técnico: es definir quién tiene autoridad para resolver desacuerdos de datos entre entidades. Esa figura —equivalente a un data steward ejecutivo con mandato transversal— no existe formalmente en el organigrama del Estado colombiano. Mientras no exista, cada integración de servicios será una negociación política, no un proceso gobernado.

    Superar a la OCDE en el promedio agrega un logro al historial; resolver la integración de datos públicos sería el argumento real para la adhesión plena.

  • Por qué escalar IA más allá de las POC exige gobernanza de datos primero

    Por qué escalar IA más allá de las POC exige gobernanza de datos primero

    Empresas de Argentina y Chile están atascadas en el mismo punto: los pilotos de inteligencia artificial funcionan, pero no escalan. El cuello de botella rara vez es el modelo; casi siempre es la gobernanza de datos que debería sostenerlo.

    Superar la prueba de concepto (POC, por sus siglas en inglés) es el desafío que hoy define la madurez de IA corporativa en la región, según informó Revista Mercado. El patrón es repetido: un equipo de datos construye un prototipo convincente, la dirección aprueba presupuesto, y el proyecto se frena cuando intenta consumir datos productivos a escala. Los datos no tienen dueño claro, no están catalogados, los pipelines no están documentados y el modelo entrenado en el sandbox no puede replicarse en producción con los controles que el negocio exige.

    El gap entre POC y producción: un problema de ownership, no de algoritmos

    En el marco DAMA-DMBOK, la transición de un piloto a un sistema productivo activa al menos cuatro capabilities críticas: calidad de datos, integración y arquitectura, seguridad de datos, y metadatos. Cuando esas capabilities no están operativas, el modelo de IA hereda los problemas del dato subyacente — sesgo, inconsistencia, falta de linaje — y falla en producción de maneras que son difíciles de diagnosticar si no existe un data catalog con trazabilidad activa. El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el ownership del dato como prerequisito del nivel 3 de madurez; sin un data steward asignado por dominio, los proyectos de IA corporativa no avanzan más allá del nivel 1.

    El data lineage — la trazabilidad end-to-end de cada atributo desde su origen hasta el consumo por el modelo — no es un lujo técnico: es el mecanismo que permite a un auditor o a un regulador entender por qué el sistema tomó una decisión. En Argentina, esto adquiere relevancia concreta: la Agencia de Acceso a la Información Pública (AAIP) tiene competencia para examinar tratamientos automatizados de datos personales bajo la Ley 25.326, y cualquier sistema de IA que tome decisiones con impacto en personas físicas puede quedar alcanzado por esa obligación de transparencia.

    Qué falla estructuralmente en las organizaciones argentinas y chilenas

    Tres patrones se repiten en la región cuando los proyectos de IA no logran salir de la POC:

    • Datos sin clasificación ni ownership: los atributos no tienen un data steward responsable, lo que impide aplicar controles de acceso granulares cuando el modelo pasa a operar sobre datos sensibles o regulados.
    • Ausencia de catálogo activo: los equipos de IA descubren en producción que los datos que usaron en el piloto no estaban autorizados para ese uso, o que su definición de negocio difiere entre sistemas fuente.
    • Linaje no documentado: cuando el modelo produce un resultado inesperado, no existe forma de trazar qué dato de entrada lo causó, lo que hace imposible la corrección sistemática y el cumplimiento de obligaciones de explicabilidad.

    En Chile, el escenario regulatorio agrega presión adicional: la Ley 21.719 de protección de datos personales, promulgada en 2024, incorpora principios de minimización y finalidad que obligan a revisar si los datos usados para entrenar modelos fueron recolectados con un propósito compatible. Esa validación requiere linaje y un inventario de datos actualizado — exactamente lo que falta en la mayoría de las organizaciones que hoy tienen POCs detenidas.

    Cuándo aplica el problema de gobernanza / cuándo NO

    No todos los proyectos de IA atascados tienen un problema de gobernanza de datos. Si el piloto opera sobre datos sintéticos o sobre un dataset acotado y estático que ya está bajo control, el cuello de botella puede ser de infraestructura, de change management o de modelo de negocio. El problema de gobernanza es determinante cuando el escalado implica incorporar datos de múltiples sistemas fuente, cuando los datos incluyen información personal o regulada, o cuando el modelo debe operar en tiempo real sobre flujos de datos en producción. En esos escenarios — que describen la mayoría de los casos corporativos relevantes en banca, retail y salud en Argentina y Chile — la gobernanza no es paralela al proyecto de IA: es su prerequisito.

    El paso concreto que los equipos de datos pueden dar esta semana

    Antes de escalar cualquier POC de IA, un Chief Data Officer o Data Governance Manager debería ejecutar un inventario de los dominios de datos que el modelo consumirá en producción y verificar tres condiciones: que cada dominio tenga un data steward nombrado con responsabilidad formal, que los atributos clave estén catalogados con definición de negocio acordada, y que el linaje desde el sistema fuente hasta el modelo esté documentado al menos a nivel de dataset. Si alguna de esas tres condiciones no se cumple, el escalado va a encontrar el mismo muro que encontraron los pilotos anteriores. No es necesario completar un programa de gobernanza full antes de avanzar — la táctica correcta, en línea con el enfoque de Non-Invasive Data Governance de Bob Seiner, es asignar stewardship sobre los dominios específicos que el proyecto de IA necesita, no sobre toda la organización a la vez.

    El marco regulatorio de Argentina y Chile ya exige respuestas sobre el origen y el uso de los datos en sistemas automatizados; la pregunta para los equipos de datos no es si van a necesitar gobernanza, sino si la van a construir antes o después del próximo piloto fallido.

  • Registros empresariales generados por IA: el desafío de gobernanza que nadie tenía en el mapa

    Registros empresariales generados por IA: el desafío de gobernanza que nadie tenía en el mapa

    Cuando un modelo de lenguaje redacta un informe financiero, genera minutas de reunión o produce un contrato borrador, ese documento existe en un limbo institucional: no es un dato en bruto ni un registro humano verificable. La proliferación de este tipo de contenido al interior de las organizaciones está creando una categoría nueva de problema para los equipos de gobernanza de datos, y la mayoría de los frameworks vigentes no la contempla.

    El problema de fondo no es técnico: es de ownership y de linaje. Un registro de negocio tradicional —una factura, un acta, un reporte de auditoría— tiene un emisor identificable, una fecha de creación verificable y, en muchos casos, una firma legal. Un documento producido por IA generativa puede haber partido de decenas de fuentes, haber sido transformado por un modelo que nadie en la organización puede auditar completamente, y haber llegado a producción sin un data steward que lo haya revisado. ¿Quién es el owner? ¿Cuál es su linaje? ¿Qué pasa cuando ese registro es cuestionado en un proceso legal o regulatorio?

    El quiebre que introduce la IA generativa en el data lineage

    El concepto de data lineage —la trazabilidad completa del origen, transformación y movimiento de un dato a lo largo de su ciclo de vida— es uno de los pilares del DAMA-DMBOK y del CDMC del EDM Council. Ambos frameworks asumen que los datos tienen una fuente identificable y que las transformaciones son reproducibles y auditables. Los registros generados por IA rompen esa cadena de dos maneras simultáneas: primero, el modelo mismo es una caja negra que combina parámetros entrenados con fuentes que pueden ser confidenciales, propietarias o incluso reguladas; segundo, el output puede variar ante el mismo prompt, lo que hace que la reproducibilidad —condición básica de cualquier auditoría— sea estructuralmente débil. En términos de CDMC, una organización que opera con registros de IA sin política explícita está, en la práctica, fuera de cumplimiento en las capabilities vinculadas a data quality y data risk.

    Validez legal e implicancias regulatorias en Argentina, Brasil y México

    La cuestión no es solo de gobernanza interna: tiene consecuencias regulatorias directas. En Argentina, la Ley 25.326 de Protección de Datos Personales exige que los datos tratados sean exactos, adecuados y actualizados en relación con la finalidad para la que fueron recabados. Un registro generado por IA que contenga datos personales —un resumen de historial de cliente, por ejemplo— puede no cumplir ese estándar si el modelo alucinó información o combinó datos de sujetos distintos. En Brasil, la LGPD (Lei 13.709/2018) va en la misma dirección e impone responsabilidad al controlador por la exactitud de los datos que trata, independientemente de cómo fueron producidos. En México, la LFPDPPP y los Lineamientos del INAI sobre decisiones automatizadas obligan a que el responsable pueda explicar el tratamiento. Un registro generado por un LLM sin documentación del proceso difícilmente supera ese umbral. Ninguna de estas jurisdicciones tiene aún una norma específica sobre registros de IA, pero sus marcos generales de datos personales ya son aplicables.

    Cuándo aplica este riesgo y cuándo no

    No todo documento producido con asistencia de IA cae en esta categoría de riesgo. El problema se activa cuando el registro generado: (1) es tratado como fuente de verdad en procesos de decisión —crediticios, de compliance, de recursos humanos—; (2) contiene o referencia datos personales o datos sensibles; (3) es susceptible de ser requerido en una auditoría regulatoria, un proceso judicial o una solicitud de acceso de un titular de datos; o (4) ingresa a un data warehouse o data lake sin etiquetado de origen. Un borrador de comunicación interna revisado y validado por un humano antes de su uso final tiene un riesgo mucho menor, siempre que quede registro de esa revisión. La clave es la intervención humana documentada como punto de control en el flujo.

    • Registros financieros o contables con datos generados por IA sin validación humana documentada.
    • Perfiles de clientes o resúmenes de historial producidos por LLMs y almacenados como fuente de verdad.
    • Minutas o actas de reunión generadas automáticamente e ingresadas directamente a sistemas de record.
    • Contratos o cláusulas producidas por IA sin revisión legal trazable.

    Lo que un CDO puede hacer antes de que el regulador lo pregunte

    El primer movimiento es de inventario: identificar qué flujos de trabajo en la organización están produciendo hoy registros de negocio con IA generativa, aunque sea de forma no autorizada —el fenómeno de shadow AI es real y ya documentado en organizaciones de la región. Ese inventario alimenta una decisión de clasificación: ¿cuáles de esos registros son, por su función, equiparables a registros formales de negocio? Una vez identificados, el segundo paso es definir una política de etiquetado de origen —AI-generated content tagging— que permita distinguirlos en el catálogo de datos. Frameworks como el Non-Invasive Data Governance de Bob Seiner proponen anclar estas políticas en los flujos donde el dato ya existe, sin crear estructuras paralelas: la misma lógica aplica aquí. El tercer paso es designar un data steward responsable de la validación antes de que el registro ingrese a cualquier sistema de record, y documentar esa intervención. Sin ese log de validación, el registro no tiene linaje verificable y la organización queda expuesta ante cualquier auditoría.

    Los marcos regulatorios de LATAM no esperaron a tener normas específicas de IA para ser aplicables a este problema: la LGPD, la Ley 25.326 y la LFPDPPP ya alcanzan los registros generados por IA cuando contienen datos personales. Para profundizar en los estándares de linaje y calidad aplicables, el CDMC del EDM Council y el capítulo 13 del DAMA-DMBOK sobre calidad de datos son los puntos de partida más completos disponibles hoy.

  • Registros empresariales generados por IA: el nuevo problema de gobernanza

    Registros empresariales generados por IA: el nuevo problema de gobernanza

    Los registros empresariales generados por inteligencia artificial —contratos borrador, informes de auditoría, minutas de reunión, análisis financieros— ya conviven con la documentación humana en los repositorios corporativos sin que la mayoría de los marcos de gobernanza de datos sepa distinguirlos. El desafío no es tecnológico: es de ownership, linaje y política de retención.

    Durante décadas, un “registro empresarial” tenía un autor identificable, una fecha de creación confiable y un proceso de aprobación trazable. Esas tres propiedades son las que los marcos de gestión documental —desde ISO 15489 hasta las políticas de retención de registros del DAMA-DMBOK— asumen como punto de partida. La irrupción de herramientas de IA generativa en flujos de trabajo cotidianos rompe esa cadena de supuestos: un contrato puede tener a un modelo de lenguaje como primer redactor, un ser humano como revisor parcial y ningún sistema de registro que capture esa distinción.

    Qué es un registro generado por IA y por qué importa la distinción

    Un registro generado por IA es cualquier documento, entrada de base de datos o artefacto informacional cuyo contenido sustantivo fue producido —total o parcialmente— por un sistema de inteligencia artificial sin intervención editorial humana equivalente a autoría. La distinción importa por al menos tres razones operativas: la exactitud del contenido no está garantizada por un juicio humano, la atribución de responsabilidad ante un error es ambigua, y las políticas de retención diseñadas para documentos humanos pueden no ser legalmente válidas cuando el origen es automatizado. En contextos de litigio o auditoría regulatoria, la incapacidad de demostrar quién —o qué— produjo un registro puede convertirse en un pasivo.

    El problema de linaje: sin origen claro, sin confiabilidad posible

    El concepto de data lineage —trazabilidad del dato desde su origen hasta su uso final— es central en cualquier programa maduro de gobernanza. El DAMA-DMBOK lo trata como un componente de la gestión de metadatos; el EDM Council, en su marco CDMC, lo incluye como capability crítica para demostrar confiabilidad a reguladores. Cuando un documento es generado por un modelo de lenguaje grande (LLM), el “origen” del contenido no es un sistema transaccional ni un analista con nombre y apellido: es una combinación de pesos estadísticos entrenados sobre corpus que la organización no controla. Sin capturar ese contexto —qué modelo, qué versión, qué prompt, qué fecha, qué validación humana— el linaje del registro es, en la práctica, inexistente. Un catálogo de datos que no distinga entre un informe escrito por un controller y uno generado por un agente de IA está operando con metadatos falsos.

    Ownership y data stewardship ante contenido sin autor humano

    El modelo de data stewardship —popularizado por Bob Seiner bajo el enfoque de Non-Invasive Data Governance— asigna responsabilidad sobre los datos a quienes ya los usan en sus procesos, sin crear roles artificiales. Ese modelo asume que hay una persona que “usa” el dato y, por tanto, puede responder por él. Con registros generados por IA, el steward de facto es quien activó la herramienta, pero esa persona frecuentemente no revisó el contenido con el nivel de detalle suficiente para garantizar su exactitud. Las organizaciones necesitan extender sus matrices de ownership para contemplar explícitamente esta categoría: quién aprueba, quién valida y quién retiene la responsabilidad sobre un registro cuya redacción fue delegada a un sistema automatizado.

    Cuándo aplica este desafío y cuándo no

    Este problema es urgente en organizaciones que ya desplegaron herramientas de IA generativa en funciones como legales, finanzas, recursos humanos o cumplimiento normativo, y que producen documentos con valor probatorio o regulatorio. No aplica de la misma forma a usos de IA limitados a análisis exploratorio interno sin salida documental formal, ni a sistemas de automatización de reportes estructurados con reglas determinísticas —donde el linaje sigue siendo trazable. La línea divisoria está en si el output del modelo puede llegar a ser citado como evidencia, presentado ante un regulador o incorporado a un expediente.

    América Latina: regulación de registros y el silencio sobre la IA generativa

    En la región, los marcos regulatorios sobre gestión documental y registros empresariales aún no contemplan explícitamente el origen automatizado del contenido. En Argentina, la Ley 25.506 de firma digital y las normas del Archivo General de la Nación establecen condiciones de autenticidad para documentos electrónicos, pero no abordan la cuestión del contenido generado por IA. En Brasil, las empresas supervisadas por el Banco Central operan bajo resoluciones que exigen trazabilidad de decisiones —especialmente en crédito y cumplimiento— lo que ya genera tensión con el uso de modelos de IA en la producción de informes regulatorios. En México, las instituciones financieras reguladas por la CNBV deben documentar sus procesos de toma de decisiones; un informe de riesgo generado por un LLM sin atribución clara podría no satisfacer ese requisito. Ninguna de estas jurisdicciones tiene aún una guía específica sobre cómo clasificar, retener o autenticar registros con origen en IA generativa.

    El paso concreto para un equipo de gobernanza es incorporar al catálogo de datos una nueva dimensión de metadatos: “origen de contenido” con valores posibles como “humano”, “IA-asistido” y “IA-generado”. Esa distinción permite aplicar políticas de retención diferenciadas, exigir validación humana documentada antes de que un registro adquiera estatus oficial, y responder con precisión si un regulador o contraparte legal pregunta cómo se produjo un documento. Implementarlo no requiere un proyecto de transformación: requiere una decisión de política y una actualización del esquema de metadatos en el catálogo existente.

    Para los equipos de gobernanza que aún no clasifican el origen del contenido en sus catálogos, la pregunta no es si un auditor o regulador lo pedirá, sino cuándo.

  • Base de datos de Vibetech expuso 13,7 millones de registros sin protección

    Base de datos de Vibetech expuso 13,7 millones de registros sin protección

    Una base de datos sin contraseña ni autenticación vinculada a Vibetech, empresa india de desarrollo de software con IA y servicios IT, quedó expuesta en línea con 13,7 millones de registros que incluyen credenciales y datos sensibles provenientes de brechas previas, según informó el investigador de ciberseguridad Jeremiah Fowler.

    El hallazgo fue publicado por ExpressVPN a partir del trabajo de Fowler, quien identificó el repositorio accesible públicamente sin ninguna medida de control de acceso. Los registros contenían, según se informó, credenciales filtradas en incidentes anteriores —un patrón conocido como “breach compilation”— además de otra información sensible cuya naturaleza exacta no fue completamente detallada en la divulgación inicial. La fecha de exposición y el tiempo que el repositorio estuvo accesible no fueron confirmados de manera precisa al momento del reporte.

    Datos confirmados al 15 de octubre de 2026

    • 13,7 millones de registros expuestos en total
    • Empresa responsable: Vibetech, con sede en India, dedicada al desarrollo de software con IA y servicios IT
    • Tipo de exposición: base de datos accesible sin autenticación ni contraseña
    • Contenido confirmado: credenciales y datos sensibles de brechas anteriores (breach compilation)
    • Descubridor: Jeremiah Fowler, investigador independiente de ciberseguridad
    • Divulgación publicada por: ExpressVPN

    Qué se sabe y qué falta confirmar

    Hasta el momento de la publicación, no se confirmó si Vibetech fue notificada antes de la divulgación pública, ni si la base de datos fue cerrada de forma inmediata tras el hallazgo. Tampoco se precisó si los 13,7 millones de registros corresponden a usuarios únicos o incluyen duplicados, un dato crítico para evaluar el alcance real del impacto. Se desconoce si los datos expuestos corresponden a clientes de Vibetech, a usuarios de terceros cuyos datos la empresa procesaba, o si se trata de un repositorio de inteligencia sobre brechas previas utilizado internamente. La ausencia de autenticación sugiere una falla en los controles básicos de configuración de infraestructura —no necesariamente un ataque externo—, aunque esta distinción no ha sido confirmada oficialmente. Desde el ángulo de la gobernanza de datos, el incidente expone una falla de ownership: cuando una base de datos que contiene datos de brechas previas queda sin un data steward asignado que supervise su clasificación y acceso, el riesgo de exposición accidental se multiplica, independientemente de la intención.

    Para las organizaciones latinoamericanas que contratan servicios de desarrollo de software con proveedores offshore —un modelo cada vez más frecuente en Argentina, México, Colombia y Brasil—, este caso activa obligaciones concretas bajo marcos locales. La Ley 25.326 argentina exige que los responsables de bases de datos garanticen medidas de seguridad adecuadas; si un proveedor externo procesa datos por encargo y los expone, la responsabilidad puede recaer también sobre el comitente local. En México, la LFPDPPP y su Reglamento establecen obligaciones equivalentes para los encargados del tratamiento. La LGPD brasileña, por su parte, requiere notificación a la ANPD en casos de incidentes que puedan acarrear riesgo relevante a los titulares, con plazos que no superan los tres días hábiles desde que el controlador toma conocimiento.

    El próximo hito crítico es la confirmación por parte de Vibetech —o de la autoridad competente india, el MeitY— sobre si la base de datos fue cerrada y si se activaron protocolos de notificación hacia los afectados o las organizaciones cuyos datos fueron procesados.

  • IA agéntica y gobernanza de datos: el nuevo desafío para los CDO

    IA agéntica y gobernanza de datos: el nuevo desafío para los CDO

    Los sistemas de IA agéntica —aquellos capaces de tomar decisiones y ejecutar tareas de forma autónoma, encadenando acciones sin intervención humana por cada paso— redefinen quién consume datos en una organización, con qué frecuencia y con qué nivel de privilegio. Para los equipos de gobernanza de datos, eso no es una evolución incremental: es un cambio de supuesto sobre el que está construido todo el marco de control.

    Un agente de IA no es un usuario que consulta un dashboard ni un modelo que recibe un dataset curado. Es un proceso autónomo que puede leer registros, escribir en sistemas, invocar APIs y tomar decisiones sobre datos en tiempo real, a veces sin que ninguna persona revise cada acción. Kroll, firma especializada en riesgo y asesoría financiera, advirtió recientemente sobre el impacto específico de estos sistemas en los marcos de gobernanza corporativa de datos, señalando que las organizaciones que adoptan IA agéntica sin adaptar sus controles quedan operando con un modelo de governance diseñado para actores humanos en un entorno donde los actores ya no lo son.

    Qué rompe la IA agéntica en un marco de gobernanza tradicional

    La gobernanza de datos convencional, tal como la articula el DAMA-DMBOK, asume que los datos fluyen entre sistemas y personas identificables, con roles definidos: data owner, data steward, data custodian. El acceso se controla por identidad humana, los permisos se auditan por usuario y el linaje (data lineage) se traza a partir de transformaciones documentadas. Un agente de IA agéntica opera de forma diferente: actúa bajo la identidad de una cuenta de servicio, accede a múltiples dominios de datos en una sola sesión, genera outputs que se convierten en inputs de otros agentes, y puede modificar registros sin que haya un steward que valide cada operación.

    Esto genera al menos tres brechas estructurales. Primero, el ownership del dato se vuelve ambiguo: si un agente combina datos de Recursos Humanos, CRM y sistemas financieros para generar una recomendación, ¿quién es el data owner responsable del output? Segundo, el linaje se fragmenta: las herramientas actuales de catalogación —Collibra, Alation, Microsoft Purview— no fueron diseñadas para capturar cadenas de razonamiento de agentes LLM como parte del linaje. Tercero, la clasificación de datos deja de ser estática: un agente puede cruzar datos de bajo riesgo y producir inferencias de alto riesgo (por ejemplo, combinar datos de ubicación y horarios laborales para inferir condición de salud), sin que ningún proceso de clasificación lo haya anticipado.

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

    Este impacto es real en organizaciones que ya desplegaron o están piloteando agentes de IA conectados a sistemas de producción: CRMs, ERPs, bases de datos de clientes, repositorios de documentos legales o financieros. No aplica —o aplica de forma muy limitada— a organizaciones que usan IA generativa solo como interfaz de usuario sin acceso a sistemas internos, ni a modelos predictivos clásicos que consumen datos en batch sin escribir de vuelta. La distinción operativa clave es si el agente tiene capacidad de acción sobre sistemas reales (write access, API calls con efecto) o solo de consulta.

    Controles de governance adaptados a agentes: tres capacidades mínimas

    El EDM Council, en su marco CDMC (Cloud Data Management Capabilities), identifica el control de acceso basado en propósito y la trazabilidad de uso como capabilities centrales. Aplicadas a agentes de IA, esas capacidades se traducen en tres requerimientos mínimos que un CDO debería evaluar antes de autorizar cualquier despliegue agéntico en producción:

    • Identidad de agente auditada: cada agente debe operar bajo una identidad de servicio única, con permisos granulares por dominio de datos y sin acceso heredado de cuentas de administrador genéricas.
    • Linaje extendido a outputs de agentes: los catálogos de datos deben registrar no solo qué datos consumió el agente, sino qué decisión tomó con ellos y qué sistemas impactó, como un nodo más en el grafo de linaje.
    • Clasificación dinámica de inferencias: el proceso de clasificación de datos debe contemplar los outputs de agentes como nuevos activos de dato, no como simples logs, y aplicar las mismas reglas de sensibilidad que aplican a los datos de origen.

    El escenario regulatorio en América Latina ya presiona en esta dirección

    En Brasil, la LGPD (Lei Geral de Proteção de Dados) exige que el tratamiento automatizado de datos personales sea transparente y que los titulares puedan solicitar revisión humana de decisiones que los afecten. Un agente de IA que procesa datos de empleados o clientes y toma decisiones sobre esa base queda directamente dentro del alcance del artículo 20 de la LGPD. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) aún no emitió lineamientos específicos sobre decisiones automatizadas con IA agéntica, pero la Ley 25.326 de Protección de Datos Personales establece el derecho a no ser sometido a decisiones con efectos jurídicos basadas exclusivamente en tratamiento automatizado. En México, el INAI ha señalado en criterios recientes que los responsables deben poder explicar cualquier tratamiento automatizado que impacte a titulares. Ninguno de estos marcos distingue si el agente automatizado es un algoritmo clásico o un LLM con capacidad agéntica: el tratamiento de datos personales activa las obligaciones de cualquier forma.

    Esto implica que los CDO de organizaciones con operaciones en Brasil, Argentina o México que estén evaluando despliegues agénticos deben incluir en el análisis de impacto no solo la arquitectura técnica, sino también si el agente toma decisiones sobre datos personales y si existe un mecanismo de revisión humana documentado. La ausencia de ese mecanismo es, en los tres marcos legales citados, una brecha de cumplimiento, no solo una deuda técnica.

    Para los equipos de gobernanza de datos, la pregunta concreta no es si adoptar IA agéntica, sino si los controles de ownership, linaje y clasificación que hoy tienen pueden rastrear a un agente tan bien como rastrean a un analista humano. Si la respuesta es no, ese gap es el punto de partida.