DataTrends LATAM

Autor: Redacción

  • IA en las aulas sin gobierno de datos: la trampa que LATAM ya está repitiendo

    IA en las aulas sin gobierno de datos: la trampa que LATAM ya está repitiendo

    Un think tank de Hong Kong encendió una alerta que resuena mucho más allá de Asia: el uso de inteligencia artificial en las escuelas crece de forma desorganizada y sin un marco de gobierno de datos que lo sostenga. La fragmentación —distintas herramientas, distintos proveedores, sin ownership claro del dato educativo— es exactamente el patrón que se observa hoy en los sistemas educativos de América Latina.

    Según se informó a principios de agosto, el think tank hongkonés planteó que la proliferación de aplicaciones de IA en el entorno escolar genera silos de datos estudiantiles que ninguna autoridad central puede auditar, clasificar ni controlar. La recomendación fue directa: antes de escalar el uso de IA, los sistemas educativos necesitan una política unificada de gobierno de datos que defina quién es el data owner, qué datos se recopilan, con qué propósito y por cuánto tiempo. Sin esas respuestas, la promesa pedagógica de la IA se convierte en un pasivo de privacidad y un riesgo de cumplimiento.

    El problema no es la IA, es la ausencia de estructura

    La discusión de fondo no gira en torno a si las herramientas de IA son buenas o malas para el aprendizaje. El núcleo del problema es estructural: cuando cada docente, cada institución o cada distrito adopta soluciones por cuenta propia, el resultado es un ecosistema donde los datos de niños y adolescentes viajan hacia proveedores externos sin políticas de retención definidas, sin clasificación de sensibilidad y sin un data steward —responsable de custodia del dato— que responda ante una auditoría. En términos del DAMA-DMBOK, el área de conocimiento de Data Security y la de Data Lifecycle Management son las primeras víctimas de esta ausencia de gobierno.

    El fenómeno tiene nombre en la literatura especializada: shadow AI aplicada al sector público. Cuando la adopción tecnológica supera la capacidad de gobernanza institucional, los datos más sensibles —los de menores— quedan en el peor lugar posible: fuera del perímetro de control, pero dentro del alcance regulatorio.

    LATAM: el mismo patrón, marcos regulatorios distintos

    En América Latina, el problema se replica con particularidades locales que agravan el riesgo. Brasil, bajo la Lei Geral de Proteção de Dados (LGPD), establece que el tratamiento de datos de niños y adolescentes requiere consentimiento específico de los padres o tutores y que el interés superior del menor es el principio rector. Sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) aún no ha emitido una regulación sectorial específica para el ámbito educativo, lo que deja un vacío que las edtech están aprovechando. En Argentina, la Ley 25.326 de Protección de Datos Personales no contempla explícitamente la categoría de “dato educativo sensible generado por IA”, y la AAIP no ha publicado lineamientos para ese escenario. México presenta un cuadro similar: la LFPDPPP y su reglamento no fueron diseñados para la velocidad de adopción de IA generativa en aulas públicas.

    Colombia, en cambio, ofrece un antecedente interesante. La Superintendencia de Industria y Comercio (SIC) ha sido más activa en la emisión de conceptos sobre tratamiento de datos de menores, y el país avanza en un marco de ética e IA que podría incluir disposiciones para el sector educativo. Chile, con su Ley Marco de Ciberseguridad ya promulgada y la reforma a la Ley 19.628 en curso, está construyendo una arquitectura regulatoria que los responsables de datos en colegios deberán conocer antes de firmar cualquier contrato con un proveedor de IA.

    Qué hace un CDO educativo el lunes

    Para los responsables de datos en ministerios de educación, secretarías distritales o redes de colegios privados, el caso de Hong Kong ofrece un checklist de arranque concreto. Antes de autorizar cualquier nueva herramienta de IA en el aula, el área de gobierno de datos debería poder responder afirmativamente a estas preguntas:

    • ¿Existe un inventario actualizado de todos los sistemas que procesan datos de estudiantes menores de edad, incluyendo las herramientas adoptadas de forma informal por docentes?
    • ¿Cada conjunto de datos tiene un data owner designado con responsabilidad formal y un data steward operativo que lo custodie?
    • ¿Los contratos con proveedores de IA incluyen cláusulas de retención, eliminación y prohibición de uso secundario de datos estudiantiles alineadas con la normativa local?
    • ¿Existe un proceso de Data Protection Impact Assessment (DPIA) obligatorio antes de incorporar cualquier sistema de IA que procese datos de menores?

    Si alguna de esas respuestas es “no” o “no lo sé”, el riesgo regulatorio ya existe. El marco CDMC del EDM Council identifica la capacidad de “gestión de riesgos del dato” (capability 8) como prerequisito para cualquier iniciativa de IA a escala. Aplicado al sector educativo público latinoamericano, eso significa que la conversación de governance debe ocurrir antes —no después— de la compra de licencias.

    El dato del menor, el más difícil de recuperar

    Hay una asimetría que suele ignorarse en la discusión sobre IA educativa: un adulto puede revocar su consentimiento, cambiar de proveedor y migrar sus datos. Un estudiante de diez años cuyos patrones de aprendizaje, comportamiento y rendimiento fueron ingeridos por un modelo de IA durante tres años escolares no tiene esa opción práctica. El dato ya fue usado para entrenar; el modelo ya aprendió. La ventana de corrección en datos de menores es angosta, y eso eleva la exigencia de governance desde el primer día.

    La pregunta que los ministerios de educación de la región deberían hacerse no es cuánta IA incorporar, sino si tienen la estructura de gobierno de datos suficiente para que esa IA no les genere el próximo escándalo de privacidad infantil.

  • Gobernanza de datos geoespaciales: el debate que irrumpe en LATAM

    Gobernanza de datos geoespaciales: el debate que irrumpe en LATAM

    La gobernanza de datos geoespaciales se instaló como tema central en la São Paulo Climate Week, en un debate organizado por la Fundação Getulio Vargas (FGV). El evento puso de relieve una brecha estructural que pocas organizaciones de la región abordan formalmente: los datos de localización, cobertura terrestre y movilidad climática carecen, en la mayoría de los casos, de ownership definido, linaje documentado y políticas de calidad aplicables a su ciclo de vida completo.

    El encuentro reunió a referentes del sector público, academia y organizaciones de la sociedad civil para discutir cómo los datos geoespaciales —imágenes satelitales, registros de sensores remotos, capas de información territorial— se producen en volúmenes crecientes pero se gestionan con marcos de gobernanza rudimentarios o directamente inexistentes. La paradoja es conocida en la industria: cuanto más sofisticada la fuente del dato, más informal suele ser su administración interna.

    El problema de fondo: datos sin dueño

    En el lenguaje del DAMA-DMBOK, los datos geoespaciales representan un dominio de alta complejidad técnica con bajo nivel de madurez en stewardship —es decir, en la figura del data steward responsable de definir estándares, validar calidad y gestionar el acceso. A diferencia de los datos transaccionales o de clientes, los datasets geoespaciales suelen ser producidos por equipos de ingeniería o ciencia de datos sin una cadena clara de accountability hacia el negocio o la política pública. El resultado es que el dato existe, pero nadie puede responder con certeza de dónde viene, qué transformaciones sufrió ni si es apto para tomar decisiones de política climática.

    El modelo de madurez DCAM (Data Management Capability Assessment Model) del EDM Council ubica la gestión de datos geoespaciales en las capabilities asociadas a data quality y data lineage. En organizaciones que trabajan con este tipo de activos —agencias ambientales, ministerios de infraestructura, fondos de inversión con criterios ESG— la ausencia de linaje documentado es un riesgo operativo y reputacional concreto, no un problema abstracto de arquitectura.

    El contexto regulatorio presiona desde varios frentes

    Brasil no es el único país de la región donde este debate se vuelve urgente. La Lei Geral de Proteção de Dados (LGPD) ya planteó, desde 2020, que los datos de geolocalización pueden constituir datos personales cuando permiten identificar o inferir el comportamiento de individuos. Eso significa que un dataset de movilidad poblacional usado para modelado climático puede, simultáneamente, estar sujeto a controles de gobernanza corporativa y a obligaciones de privacidad ante la Autoridade Nacional de Proteção de Dados (ANPD). La intersección entre ambos marcos es territorio que pocas organizaciones brasileñas tienen mapeado formalmente.

    En Argentina, la Ley 25.326 de Protección de Datos Personales y su autoridad de aplicación, la AAIP, también contemplan la geolocalización como dato sensible cuando se combina con perfiles de comportamiento. Mientras tanto, el Instituto Nacional de Estadística e Informática (INEI) de Perú y el DANE de Colombia gestionan enormes volúmenes de datos geoespaciales censales con marcos de gobernanza que, según referentes del sector, todavía operan por debajo de los estándares que exigiría una auditoría bajo ISO/IEC 38505 —el estándar internacional de gobernanza de datos para órganos directivos.

    Qué puede hacer un CDO el lunes

    Para un Chief Data Officer o Data Governance Manager cuya organización usa datos geoespaciales —aunque sea de forma periférica—, el debate de São Paulo ofrece una señal de acción concreta. El primer paso es inventariar qué datasets geoespaciales existen en la organización, quién los produjo, con qué frecuencia se actualizan y si tienen un data steward formalmente asignado. En la mayoría de los casos, ese inventario no existe o está desactualizado. Herramientas de data catalog con soporte para metadatos geoespaciales —como OpenMetadata o Collibra con conectores GIS— permiten iniciar ese relevamiento sin necesidad de un proyecto de transformación de largo plazo.

    El segundo movimiento es evaluar si alguno de esos datasets cruza el umbral de dato personal bajo la regulación local aplicable. Si la organización opera en Brasil, la respuesta en muchos casos será afirmativa, lo que implica coordinar con el DPO (Data Protection Officer) para definir la base legal del tratamiento y documentar la evaluación de impacto correspondiente. No hacerlo es dejar un flanco abierto ante la ANPD en un contexto en que el regulador brasileño ha escalado su actividad de supervisión en los últimos doce meses.

    Una ventana que no estará abierta siempre

    El hecho de que la FGV lleve este debate a un evento de agenda climática internacional no es accidental. Los compromisos de descarbonización, reporte ESG y transparencia territorial que asumen gobiernos y empresas de la región dependen, en última instancia, de la calidad y trazabilidad de los datos geoespaciales que los sustentan. Si esos datos no tienen gobernanza, los compromisos tampoco la tienen.

    La gobernanza de datos geoespaciales dejó de ser un nicho técnico: es la infraestructura invisible de la agenda climática en América Latina, y su ausencia tiene costos medibles.

  • Governance sin control: el modelo de capacidades que está redefiniendo el rol del CDO

    Governance sin control: el modelo de capacidades que está redefiniendo el rol del CDO

    Un número creciente de organizaciones está abandonando el enfoque policial del gobierno de datos —basado en restricciones, aprobaciones y comités de control— para adoptar un modelo orientado a capacidades: habilitar a los equipos para trabajar con datos de forma autónoma, con calidad y con contexto. El programa de data governance de York University en Canadá es uno de los casos más citados recientemente como referencia de este cambio de paradigma, y sus principios tienen aplicación directa para los CDOs de la región.

    Durante años, el gobierno de datos fue sinónimo de fricción. Políticas que nadie leía, flujos de aprobación que demoraban semanas, y equipos de negocio que terminaban creando sus propias sombras de datos para esquivar los procesos formales. El resultado fue paradójico: más governance en el papel, menos calidad real en la práctica. El enfoque de York University invierte esa lógica: en lugar de preguntar “¿quién tiene permiso para tocar este dato?”, pregunta “¿qué capacidad necesita este equipo para usarlo bien?”

    Capabilities primero: qué significa en la práctica

    El modelo de capacidades en data governance no es nuevo en la teoría —el DAMA-DMBOK lo contempla dentro de su área de Data Governance como habilitador de las demás disciplinas—, pero su adopción práctica ha sido lenta. La diferencia clave está en el punto de partida: en lugar de construir una estructura de control y luego intentar que el negocio la adopte, se identifican primero las decisiones que los equipos necesitan tomar con datos, y se construye el andamiaje de governance para habilitarlas. Esto incluye definir data ownership operativo (no nominal), instrumentar data lineage —la trazabilidad del origen, transformación y uso de un dato— y asegurar que los data stewards, los custodios funcionales del dato en cada dominio, tengan herramientas reales y no solo responsabilidades en papel.

    Bob Seiner, referente del enfoque Non-Invasive Data Governance, ha argumentado consistentemente que la resistencia al gobierno de datos no es cultural sino de diseño: cuando governance se percibe como burocracia adicional, fracasa. Cuando se percibe como soporte para hacer el trabajo mejor, se adopta. El caso de York ilustra exactamente eso: los equipos de datos comenzaron a comprometerse con el programa cuando vieron que les resolvía problemas concretos —como saber quién es el dueño de una definición de negocio o cómo rastrear por qué un reporte y otro arrojan cifras distintas.

    El lunes a la mañana: qué hace un CDO con esto

    El modelo de capacidades exige una revisión honesta del estado actual del programa de governance. Una forma concreta de empezar es mapear las decisiones de datos más frecuentes en los dominios críticos —finanzas, clientes, operaciones— e identificar dónde el proceso actual agrega latencia sin agregar valor. Si un equipo de analítica tarda más en obtener acceso a un dataset que en analizarlo, hay un problema de diseño, no de cultura. Los indicadores a revisar incluyen: tiempo promedio de resolución de un data issue, cobertura de data ownership documentado sobre activos críticos, y porcentaje de datasets con lineage instrumentado en el catálogo.

    • Auditar qué porcentaje de los data stewards designados tienen capacidad real de decisión sobre sus dominios versus un rol meramente formal.
    • Revisar si el catálogo de datos corporativo es consultado activamente o solo se actualiza para cumplir con auditorías internas.
    • Identificar los tres flujos de aprobación de datos con mayor tiempo de ciclo y evaluar si pueden rediseñarse como habilitación en lugar de control.
    • Alinear el roadmap de governance con los OKRs de las áreas de negocio, no con los del equipo de TI.

    El contexto LATAM: entre el compliance y la madurez

    En América Latina, el gobierno de datos enfrenta una tensión adicional: muchos programas nacieron como respuesta a requisitos regulatorios —la Resolución 4793 de la Superintendencia Financiera de Colombia, la Comunicación A 8073 del BCRA en Argentina, o las exigencias de la LGPD en Brasil para mapeo de datos personales— y quedaron atrapados en una lógica de compliance reactivo. Eso es governance para el regulador, no governance para el negocio. El riesgo es construir capacidades de reporte hacia afuera mientras los equipos internos siguen operando con hojas de cálculo sin linaje y definiciones de negocio inconsistentes entre áreas.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), ofrece un camino para cerrar esa brecha: sus 14 capabilities permiten evaluar el nivel de madurez de forma objetiva y priorizar inversiones. Varios bancos de la región ya operan con prácticas equivalentes a las capabilities 7 y 8 del CDMC —gestión de calidad y clasificación de datos— impulsados por exigencias regulatorias, pero sin la certificación formal ni la articulación de un programa cohesivo. Formalizar eso es, precisamente, el tipo de quick win que un CDO puede mostrar en el corto plazo.

    El riesgo de confundir madurez con complejidad

    Uno de los errores más comunes al escalar un programa de governance es agregar capas de proceso bajo la suposición de que más estructura equivale a más madurez. El modelo de capacidades invierte esa ecuación: mide la madurez por el impacto habilitado, no por la cantidad de políticas aprobadas o comités activos. Un programa con tres políticas claras, data ownership real y un catálogo activo genera más valor que uno con veinte políticas que nadie aplica. La pregunta que debería guiar cada decisión de diseño es simple: ¿esto le facilita o le complica la vida al equipo que trabaja con el dato?

    El governance que no habilita termina siendo eludido — y los datos que no tienen dueño real no tienen calidad real.

  • Construir un navegador no es un delito informático: el fallo que redefine el CFAA

    Construir un navegador no es un delito informático: el fallo que redefine el CFAA

    El Noveno Circuito de Apelaciones de Estados Unidos rechazó la demanda de Amazon contra Perplexity AI y estableció que desarrollar un navegador con funciones de agente de IA no viola la Computer Fraud and Abuse Act (CFAA), siempre que sea el usuario quien ejecuta el acceso. El fallo tiene implicancias directas para el debate sobre responsabilidad de sistemas de IA en América Latina, donde reguladores y legisladores aún definen quién responde cuando un agente automatizado actúa en nombre de una persona.

    El caso surgió cuando Amazon demandó a Perplexity AI por su navegador Comet, que incluye un asistente de IA agentic —capaz de navegar sitios web de forma autónoma para comparar precios— y que, según Amazon, accedía a cuentas de usuarios de su plataforma sin autorización. La compañía argumentó que eso constituía acceso no autorizado bajo la CFAA, una ley federal de 1986 pensada originalmente para perseguir intrusiones informáticas, pero que con frecuencia ha sido invocada por grandes corporaciones para bloquear a competidores más pequeños.

    El argumento técnico que convenció al tribunal

    La Electronic Frontier Foundation (EFF) presentó un escrito amicus curiae en el que explicó al tribunal la arquitectura real del sistema: no es Perplexity quien accede a los servidores de Amazon, sino el usuario que opera el navegador. El Noveno Circuito adoptó esa lectura y, según se informó, destacó expresamente que la explicación de EFF “articula la naturaleza del sistema con mayor claridad”. El fallo concluye que el asistente de IA “es una herramienta, no una persona a efectos del estatuto”, y que esa herramienta es operada por el usuario, no por la empresa que la desarrolló.

    El tribunal también reconoció que la IA agentic plantea preguntas legales nuevas y que existe “escasa o nula jurisprudencia” sobre cómo atribuir responsabilidad a agentes de IA bajo el CFAA. Aun así, evitó pronunciarse sobre esas cuestiones más complejas: en este caso bastó con determinar que el control sobre el acceso residía en el usuario. Amazon podría tener otras acciones legales disponibles, señaló el tribunal, pero usar el CFAA era “legalmente infundado” y una mala política pública que podría exponer a los propios usuarios a responsabilidad penal.

    El patrón que el fallo intenta frenar

    La EFF subrayó que este tipo de litigios no es una anomalía: las grandes plataformas han utilizado el CFAA sistemáticamente para presionar a desarrolladores independientes que crean herramientas de acceso alternativas a sus servicios. El fallo del Noveno Circuito no solo beneficia a Perplexity, sino que sienta un precedente relevante para cualquier equipo que construya navegadores, scrapers, automatizaciones o agentes de IA que interactúen con plataformas de terceros. La distinción entre “el desarrollador accede” versus “el usuario accede mediante la herramienta” ahora cuenta con respaldo judicial explícito en una jurisdicción de alta influencia.

    Qué significa esto para la región

    En América Latina, la discusión sobre responsabilidad de agentes de IA todavía es incipiente. Brasil avanza con el PL 2338/2023 —su proyecto de ley de inteligencia artificial— que contempla criterios de atribución de responsabilidad para sistemas automatizados, aunque sin definir aún con precisión el rol del operador frente al desarrollador. México, por su parte, carece de un marco específico para IA, y la LFPDPPP no fue diseñada para resolver quién responde cuando un agente actúa sobre datos de un tercero. Argentina se encuentra en una situación similar: la Ley 25.326 establece obligaciones para quienes tratan datos personales, pero el escenario de un agente de IA que accede a información por instrucción del propio titular del dato abre preguntas que la norma no responde.

    El razonamiento del Noveno Circuito —centrado en quién ejerce el control efectivo sobre el acceso— puede ser una referencia útil para legisladores y autoridades de la región cuando tengan que resolver casos análogos. La distinción no es trivial: si el agente de IA es tratado como actor independiente, la cadena de responsabilidad se extiende al desarrollador; si se lo trata como herramienta del usuario, la responsabilidad primaria recae en quien lo activa. Esa diferencia puede determinar si un startup de automatización enfrenta o no una demanda millonaria.

    El lunes en la práctica

    Para equipos legales y de producto que trabajan con agentes de IA en LATAM, el fallo sugiere al menos tres acciones concretas: revisar los términos de servicio de las plataformas con las que sus agentes interactúan para identificar cláusulas de acceso que puedan ser invocadas como fundamento de una demanda; documentar con claridad en el diseño del sistema quién inicia y controla cada sesión de acceso; y comenzar a monitorear cómo los proyectos de ley de IA en Brasil, Colombia y Chile abordan la atribución de responsabilidad en cadenas humano-agente. La jurisprudencia estadounidense no es vinculante en la región, pero históricamente ha influido en la redacción de marcos normativos locales.

    Cuando las grandes plataformas usan el derecho como escudo competitivo, la claridad técnica se vuelve el argumento más poderoso — y los reguladores latinoamericanos deberían tomar nota antes de que el debate llegue a sus propios tribunales.

  • SDKs publicitarios filtran ubicación sin consentimiento: lo que reveló la EFF

    SDKs publicitarios filtran ubicación sin consentimiento: lo que reveló la EFF

    Un informe de la Electronic Frontier Foundation (EFF) reveló que varios kits de desarrollo de software (SDKs) publicitarios comparten por defecto la ubicación de los usuarios con brokers de datos, sin su conocimiento ni consentimiento real. Entre los señalados figuran InMobi, BidMachine, HyBid de Verve y Petal Ads de Huawei. El hallazgo expone una cadena de transferencia de datos personales que opera de manera silenciosa dentro de millones de aplicaciones móviles.

    Los SDKs publicitarios son paquetes de código que los desarrolladores integran en sus apps para monetizarlas mediante publicidad. Su uso es masivo: prácticamente cualquier aplicación gratuita los incorpora. El problema, según documentó la EFF tras revisar la documentación pública de decenas de estos kits, es que varios de ellos activan por defecto la recolección y transmisión de la ubicación precisa del usuario en el momento en que la app recibe permiso de geolocalización, independientemente del propósito original para el que ese permiso fue otorgado.

    El mecanismo: consentimiento aparente, transferencia real

    El núcleo del problema no es técnico sino de diseño deliberado. Cuando un usuario autoriza a una app de delivery o navegación a acceder a su ubicación, no necesariamente entiende que esa misma señal puede activar un SDK publicitario que la reenvía a sistemas de rastreo de terceros. La investigadora Lena Cohen, tecnóloga de la EFF, lo describió con precisión:

    “Los valores predeterminados importan, no solo para los usuarios sino también para los desarrolladores. Si los desarrolladores no prestan atención a la configuración de compartición de ubicación de sus herramientas publicitarias, podrían exponer inadvertidamente la información de ubicación de los usuarios.”

    — Lena Cohen, tecnóloga senior, Electronic Frontier Foundation

    La investigación también señala que los SDKs utilizan incentivos económicos para estimular a los desarrolladores a habilitar la geolocalización: a mayor precisión de datos compartidos, mayores ingresos por publicidad. Esto crea una presión estructural para que la privacidad ceda frente a la monetización, incluso cuando los desarrolladores no tienen una intención explícita de vulnerar datos de sus usuarios.

    Qué implica esto para LATAM

    América Latina concentra algunos de los mercados de apps más activos del mundo. Brasil, México y Argentina figuran entre los diez países con mayor descarga de aplicaciones móviles a nivel global, según datos de la industria. Eso significa que millones de usuarios de la región están potencialmente expuestos a este mecanismo de fuga de datos, muchos de ellos sin ninguna protección legal efectiva activada en su favor.

    En Brasil, la Lei Geral de Proteção de Dados (LGPD) establece que el tratamiento de datos de geolocalización requiere base legal explícita y, en muchos casos, consentimiento específico. La Autoridade Nacional de Proteção de Dados (ANPD) ya emitió orientaciones sobre el principio de finalidad: los datos recabados para un propósito no pueden reutilizarse para otro sin nueva base legal. Un SDK que redirige datos de ubicación a brokers publicitarios sin que el usuario lo sepa difícilmente cumple ese estándar. En Argentina, la Ley 25.326 y las directrices de la AAIP apuntan en la misma dirección: el consentimiento debe ser informado, libre y específico para cada finalidad.

    México no es la excepción. La LFPDPPP obliga a los responsables del tratamiento a informar de manera clara con qué terceros se compartirán los datos y para qué fines. Si un desarrollador integra un SDK sin auditar su comportamiento en materia de geolocalización, puede estar transfiriendo datos a terceros sin haberlo declarado en su aviso de privacidad, lo que configura una infracción directa.

    El desarrollador también es responsable

    Un punto que la EFF subraya y que suele pasarse por alto en los debates regulatorios es la responsabilidad del desarrollador frente a las prácticas del SDK que incorpora. Integrar una librería de terceros no exime al responsable de la app de las obligaciones sobre los datos que fluyen a través de ella. En términos del RGPD europeo —referencia técnica para varias normativas latinoamericanas— el desarrollador actúa como responsable del tratamiento y el SDK como encargado; esa relación debe estar contractualmente documentada y el encargado debe operar bajo instrucciones del responsable, no al revés.

    La documentación poco clara o deliberadamente opaca de algunos SDKs, otro hallazgo de la EFF, agrava este problema: si el desarrollador no puede entender cómo configura la transmisión de datos la herramienta que usa, tampoco puede cumplir con sus obligaciones de información al usuario. El informe recomienda que los desarrolladores auditen activamente los SDKs que integran, desactiven el intercambio de ubicación cuando no sea estrictamente necesario, y exijan documentación clara a los proveedores.

    Reguladores bajo presión

    El informe de la EFF llega en un momento en que la regulación del mercado de brokers de datos de ubicación está ganando atención global. En Estados Unidos, la FTC ya tomó acciones contra empresas del sector. En LATAM, los marcos legales existen pero la supervisión activa del ecosistema de SDKs publicitarios sigue siendo prácticamente inexistente. Ninguna autoridad de protección de datos de la región ha publicado hasta la fecha guías específicas sobre las obligaciones de los desarrolladores respecto a las librerías de terceros que integran en sus aplicaciones.

    Mientras los reguladores latinoamericanos no pongan la lupa sobre el ecosistema de SDKs publicitarios, los marcos legales de privacidad de la región seguirán teniendo un punto ciego del tamaño de la economía de datos de ubicación.

  • Calidad de datos: la base sin la que el gobierno de datos no funciona

    Calidad de datos: la base sin la que el gobierno de datos no funciona

    Sin datos de calidad, un programa de data governance es una estructura vacía. La relación entre ambos conceptos no es complementaria sino constitutiva: la calidad del dato es la condición de posibilidad de cualquier decisión que el gobierno de datos pretenda respaldar. Para los equipos que lideran iniciativas de gobernanza en América Latina, entender esa relación en términos operativos marca la diferencia entre un framework decorativo y uno que genera valor real.

    El error más frecuente que cometen las organizaciones al arrancar un programa de gobernanza es tratar la calidad de datos como un proyecto paralelo o posterior. Se definen políticas, se asignan data stewards, se instala un catálogo de datos, y recién entonces alguien pregunta: ¿pero estos datos son confiables? Para ese momento, las decisiones ya se tomaron sobre cimientos inestables. El DAMA-DMBOK 2 es explícito al respecto: la gestión de la calidad del dato (Data Quality Management) es uno de los once knowledge areas del framework, y su integración con Data Governance no es opcional sino estructural.

    Qué significa “calidad” en un contexto de gobernanza

    La calidad de datos no se reduce a que los registros estén completos o sin errores tipográficos. En un marco de gobernanza robusto, la calidad se evalúa contra dimensiones precisas: completitud, consistencia, precisión, oportunidad, unicidad y validez. Cada dimensión responde a una pregunta de negocio distinta. Un dato puede ser preciso pero inoportuno —llegar fuera del ciclo de decisión—, o consistente en un sistema pero contradictorio al cruzarse con otro. El modelo de John Ladley en “Data Governance: How to Design, Deploy, and Sustain an Effective Data Governance Program” subraya que las reglas de calidad deben derivarse de los casos de uso del negocio, no de criterios técnicos aislados.

    Esto tiene una implicancia directa para el diseño del programa: los data stewards —los responsables funcionales del dato en cada dominio— son quienes deben definir qué significa “buena calidad” para su conjunto de datos, no el equipo de IT. Un steward de datos maestros de clientes en un banco tiene criterios de calidad distintos a los de un steward de datos de riesgo crediticio, aunque ambos trabajen con información del mismo cliente. Esta distinción es central en el enfoque de Non-Invasive Data Governance de Bob Seiner, que propone formalizar roles que ya existen en la organización en lugar de imponer estructuras nuevas.

    El costo de ignorarlo: casos concretos en la región

    En América Latina, la degradación de la calidad de datos tiene consecuencias regulatorias directas. Las entidades financieras en Brasil que reportan al Banco Central bajo el sistema SCR (Sistema de Informações de Crédito) enfrentan penalidades cuando los datos remitidos presentan inconsistencias. En Argentina, la Comunicación A 7724 del BCRA establece requisitos de integridad de la información para los reportes de gestión de riesgo, lo que obliga a los bancos a mantener controles de calidad que —aunque no se llamen así— son capabilities equivalentes a los que define el CDMC (Cloud Data Management Capabilities) del EDM Council. En México, la CNBV tiene requerimientos similares para la remisión de información regulatoria periódica.

    Más allá del sector financiero, organizaciones con grandes volúmenes de datos personales enfrentan un riesgo adicional: datos de baja calidad pueden derivar en tratamientos incorrectos de información personal, lo que en jurisdicciones con leyes activas como la LGPD brasileña o la Ley 25.326 argentina puede traducirse en incumplimientos con consecuencias sancionatorias. Un registro duplicado mal gestionado puede implicar el envío de comunicaciones a personas que ya ejercieron su derecho de supresión.

    Qué hace un CDO con esto el lunes

    El punto de entrada más práctico es el data quality scorecard por dominio. Antes de expandir el catálogo de datos o incorporar nuevas fuentes al data lineage, un CDO debería poder responder tres preguntas por cada dominio crítico: ¿cuál es la tasa de completitud actual?, ¿existe un SLA de calidad definido y acordado con el negocio?, y ¿hay un data steward asignado con capacidad de escalar issues de calidad? Si alguna de las tres respuestas es “no sé”, ese dominio es el punto de partida.

    • Mapear los dominios de datos críticos para el negocio y asignar un data steward con mandato explícito sobre calidad.
    • Definir al menos tres dimensiones de calidad medibles por dominio, con umbrales acordados con stakeholders de negocio.
    • Integrar los controles de calidad en el pipeline de datos, no como paso posterior sino como gate de ingesta.
    • Establecer un proceso de escalamiento claro cuando un dataset no alcanza el umbral mínimo de calidad para ser usado en decisiones.
    • Revisar si los controles de calidad actuales cubren los requisitos de reporte regulatorio aplicables en la jurisdicción.

    Herramientas como Great Expectations, Monte Carlo o los módulos nativos de calidad en plataformas como Collibra o Alation permiten automatizar buena parte de este monitoreo, pero la automatización sin ownership humano reproduce el problema a mayor velocidad. La tecnología es el habilitador; el data steward es el responsable.

    Gobernanza sin calidad es solo burocracia

    Los programas de data governance que no resuelven el problema de calidad generan uno nuevo: una capa de procesos y documentación que le da a la organización la ilusión de control sin el control real. Los comités se reúnen, las políticas se aprueban, el catálogo crece, y las decisiones siguen tomándose sobre datos que nadie confía del todo. Esa desconexión entre la estructura de gobernanza y la realidad del dato es, según el Data Governance Institute, una de las causas principales de abandono de iniciativas de este tipo en los primeros dos años.

    Un programa de gobernanza se mide, en última instancia, por si los datos que produce son usados con confianza. Todo lo demás es arquitectura.

  • Sin gobierno de datos, la IA agéntica es una apuesta a ciegas

    Sin gobierno de datos, la IA agéntica es una apuesta a ciegas

    La IA agéntica —sistemas capaces de tomar decisiones y ejecutar acciones de forma autónoma en cadena— está llegando a las organizaciones antes de que sus datos estén en condiciones de soportarla. Para los equipos de gobierno de datos en América Latina, esto no es una advertencia futura: es el problema del trimestre.

    A diferencia de los modelos de lenguaje que simplemente responden preguntas, los agentes de IA operan en loops: consultan fuentes, toman decisiones intermedias, invocan herramientas externas y producen efectos en sistemas reales. Cada paso de esa cadena depende de datos. Si esos datos tienen linaje (data lineage) desconocido, propietarios (data owners) indefinidos o clasificaciones inconsistentes, el agente amplifica el error en lugar de resolverlo. El output incorrecto de un chatbot es una molestia; el output incorrecto de un agente que procesa órdenes de compra o evalúa solicitudes de crédito es un problema de negocio —y potencialmente legal.

    El problema no es el modelo, es el dato que lo alimenta

    El DAMA-DMBOK define la calidad del dato como una de las diez áreas de conocimiento del gobierno de datos, y no por accidente: datos sin definición semántica consistente producen resultados no reproducibles. En el contexto agéntico, esto se agrava porque el agente puede encadenar múltiples fuentes sin intervención humana. Un pipeline donde el campo “cliente activo” tiene tres definiciones distintas en tres sistemas —CRM, ERP y data warehouse— ya era un riesgo en BI tradicional. En IA agéntica, ese campo puede activar o bloquear una acción autónoma con consecuencias directas.

    El EDM Council, a través de su framework CDMC (Cloud Data Management Capabilities), identifica el control de acceso basado en clasificación como una capability crítica. Para que un agente opere con datos sensibles de forma confiable, el catálogo de datos debe indicar no solo dónde está el dato, sino quién puede usarlo, bajo qué condición y con qué restricción regulatoria. Sin esa capa, el agente toma decisiones con datos a los que, en un proceso manual, ningún analista habría tenido acceso.

    Lo que el CDO necesita revisar esta semana

    El punto de partida operativo es el inventario de datos que ya están —o estarán pronto— disponibles para sistemas agénticos. Tres preguntas concretas para ese inventario:

    • ¿Cada dataset tiene un data steward identificado con responsabilidad formal sobre su calidad y clasificación?
    • ¿El data lineage está documentado hasta el nivel de campo, o solo a nivel de tabla o sistema?
    • ¿Las políticas de acceso reflejan sensibilidad regulatoria, o son herencias de permisos históricos que nadie auditó?

    Si la respuesta a cualquiera de esas tres preguntas es negativa o incierta, el dato en cuestión no debería alimentar un agente autónomo. Ese es el criterio mínimo, no el ideal. Bob Seiner, referente de Non-Invasive Data Governance, sostiene que las organizaciones no necesitan programas nuevos para gobernar datos en IA: necesitan hacer cumplir las políticas que ya definieron pero que nadie estaba aplicando con rigor. La IA agéntica simplemente hace visible lo que ya estaba roto.

    El contexto regulatorio de LATAM agrega urgencia

    En Brasil, la LGPD (Lei Geral de Proteção de Dados) establece responsabilidad para el controlador por el tratamiento automatizado de datos personales, incluyendo decisiones que afecten a titulares. Un agente de IA que clasifica clientes, aprueba solicitudes o genera comunicaciones personalizadas es, en términos jurídicos, un mecanismo de decisión automatizada sujeto a los artículos 20 y concordantes. Si el dato que lo alimenta no tiene trazabilidad ni control de calidad documentado, la organización no puede demostrar el cumplimiento ante la ANPD en caso de un reclamo. En Argentina, la situación es análoga bajo la Ley 25.326 y las resoluciones de la AAIP, que ya han señalado el tratamiento automatizado como área de atención prioritaria. En México, la LFPDPPP y los lineamientos del INAI sobre decisiones automatizadas imponen obligaciones similares para el sector privado.

    El punto de confluencia es claro: los marcos de privacidad de la región no esperan a que las organizaciones “maduren” su gobierno de datos antes de exigir accountability. La ANPD puede sancionar hoy por un tratamiento automatizado que no pueda auditarse. Eso convierte el data lineage y el data ownership en requisitos de compliance, no solo en buenas prácticas de arquitectura.

    Confianza como requisito de diseño, no como resultado

    El concepto de “trustworthy AI” —IA confiable— que promueven tanto la Unión Europea en su AI Act como los marcos emergentes en América Latina no se construye en la capa del modelo. Se construye en la capa del dato. Un agente que opera sobre un catálogo bien gobernado, con stewardship activo, lineage documentado y políticas de acceso auditadas, puede ser explicado, auditado y corregido. Uno que opera sobre un lago de datos sin gobierno es, por definición, una caja negra, independientemente de cuán sofisticado sea el modelo subyacente.

    Las organizaciones que lleguen tarde al gobierno de datos no van a poder desplegar IA agéntica confiable: van a desplegar riesgo agéntico.

  • El gobierno de datos como disciplina operativa: de política a práctica

    El gobierno de datos como disciplina operativa: de política a práctica

    El gobierno de datos acumula años de promesas y frameworks bien documentados, pero en la mayoría de las organizaciones sigue siendo un ejercicio de diseño más que de ejecución. La brecha no está en el conocimiento teórico — está en la distancia entre la política aprobada por el comité y la decisión que toma un analista a las 9 de la mañana del lunes. Cerrar esa brecha es el verdadero desafío operativo para los equipos de datos en 2025 y 2026.

    El problema de fondo: governance como artefacto

    Durante años, muchas organizaciones construyeron su programa de gobierno de datos alrededor de entregables: un glosario de negocio, un mapa de data lineage —la trazabilidad que permite saber de dónde viene un dato y cómo se transforma a lo largo de su ciclo de vida—, un catálogo de activos, políticas de clasificación. El problema no es que esos artefactos estén mal; el problema es que se actualizan trimestralmente, viven en herramientas que pocos consultan y no están conectados a los flujos de trabajo diarios. En la práctica, el dato se procesa igual con o sin ellos. El DAMA-DMBOK, en su segunda edición, ya advertía sobre esta trampa: un programa de governance que no se integra en los procesos operativos es, a efectos prácticos, decorativo.

    Bob Seiner, referente de la corriente Non-Invasive Data Governance, lleva más de dos décadas argumentando que el gobierno de datos debería operar sobre las responsabilidades que ya existen — no crear burocracia nueva — sino formalizar quién ya toma decisiones sobre los datos y hacer eso visible, medible y repetible. La operacionalización no implica agregar pasos; implica incrustar controles donde el trabajo ya ocurre.

    Qué significa “operativo” en la práctica

    Hablar de gobierno de datos operativo tiene al menos tres dimensiones concretas que vale distinguir. La primera es la integración en pipelines: las reglas de calidad, clasificación y ownership no se definen fuera del pipeline — se ejecutan dentro de él. La segunda es la asignación de data stewards —responsables de dominio de datos con mandato formal— que participan en las decisiones técnicas, no solo en las revisiones de política. La tercera es la medición continua: dashboards de calidad de datos vinculados a KPIs de negocio, no reportes mensuales en PDF.

    • Reglas de calidad y clasificación embebidas en los pipelines de ingesta y transformación.
    • Data stewards con capacidad de bloquear o escalar issues en tiempo real, no solo en reuniones de comité.
    • Métricas de governance como parte del scorecard del CDO, no en un reporte separado de compliance.
    • Catálogo de datos activo, vinculado al entorno de desarrollo, no a un portal que nadie visita.

    El contexto regulatorio empuja la urgencia en LATAM

    En América Latina, la presión externa para operacionalizar el gobierno de datos ya no es solo una buena práctica — empieza a ser una exigencia implícita en marcos regulatorios sectoriales. En Brasil, la ANPD ha orientado sus primeras resoluciones hacia la demostración de controles efectivos sobre datos personales, no solo sobre la existencia de políticas escritas: las empresas que no puedan mostrar evidencia operativa de su programa corren riesgo en cualquier proceso de fiscalización bajo la LGPD. En Argentina, la Comunicación A 8073 del BCRA exige a las entidades financieras capacidades de gestión del ciclo de vida del dato que, en el marco del EDM Council (CDMC), corresponden a niveles de madurez 7 y 8 — aunque la mayoría de los bancos locales aún no ha formalizado esa equivalencia ni la certifica. En México, el INAI ha intensificado la expectativa de que los responsables de tratamiento puedan demostrar, con evidencia, los controles aplicados sobre datos personales sensibles.

    “La governance que no se puede demostrar en producción no existe desde el punto de vista regulatorio. Una política aprobada en un comité no es un control.”

    — Principio operativo, EDM Council CDMC Framework

    Qué hace un CDO con esto el lunes

    La pregunta concreta para cualquier Chief Data Officer o Data Governance Manager es cómo avanzar sin necesidad de un proyecto de transformación de 18 meses. Una ruta práctica parte de identificar los tres o cuatro dominios de datos con mayor impacto regulatorio o de negocio — clientes, productos, proveedores, transacciones — y mapear quién toma decisiones sobre esos datos hoy, aunque no tenga título formal de data steward. Formalizar ese ownership es el primer paso hacia un control operativo real. El segundo es revisar si las reglas de calidad definidas en el glosario o en el catálogo están efectivamente implementadas en algún punto del pipeline, o solo existen en un documento Word. Si la respuesta es “solo en el documento”, ese es el gap prioritario. El tercer paso es conectar al menos una métrica de calidad de datos a un indicador de negocio que el área usuaria ya monitoree — eso cambia la conversación de compliance a valor.

    El ISO/IEC 38505, marco de governance de datos para órganos de dirección, refuerza este enfoque: la responsabilidad final sobre los datos no recae en el equipo de TI ni en el equipo de datos, sino en quienes toman decisiones de negocio. Operacionalizar governance es, en último término, hacer esa responsabilidad visible y exigible en el día a día.

    Un programa de gobierno de datos que no se puede demostrar en producción no es un programa — es una presentación de PowerPoint con fecha de vencimiento.

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

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

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

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

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

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

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

    LATAM: el sector público va a distintas velocidades

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

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

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

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

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

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

    El riesgo de no actuar

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

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

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

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

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

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

    Qué está detrás del incremento

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

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

    El marco regulatorio que amplifica el riesgo financiero

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

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

    Lo que un CDO debería revisar esta semana

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

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

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

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