DataTrends LATAM

Blog

  • El nuevo agujero de seguridad de las empresas no está en sus servidores: está en cómo sus empleados usan la IA

    El nuevo agujero de seguridad de las empresas no está en sus servidores: está en cómo sus empleados usan la IA

    Un ingeniero de Samsung tenía un problema simple: el código fuente de un equipo de fabricación de chips tiraba un error que no lograba destrabar. Como cualquier desarrollador del mundo en marzo de 2023, abrió ChatGPT, pegó el fragmento de código y le pidió ayuda para corregirlo. En minutos tuvo la solución. Lo que no sabía —o no dimensionó— es que acababa de sacar información de propiedad intelectual de la compañía y entregársela a un servidor externo, fuera de cualquier control corporativo. No fue el único: en las semanas siguientes, otro empleado subió a la misma herramienta el código de un test para detectar chips defectuosos, y un tercero grabó una reunión interna, la transcribió y le pidió a la IA que le armara la minuta. Tres personas, tres áreas distintas, un mismo gesto. Ninguna robó nada. Ninguna tuvo mala intención. Samsung terminó prohibiendo el uso de IA generativa en toda la compañía, pero para entonces la información ya había salido y no había forma de traerla de vuelta.

    Esto ya pasó. Y la pregunta que debería inquietar a cualquier empresa hoy no es si le puede pasar lo mismo, sino si ya le está pasando ahora mismo, sin que nadie se haya dado cuenta.

    El empleado común

    No hace falta ser ingeniero para que le suceda algo así. Lo hace la persona de recursos humanos que le pide a un chatbot gratuito que le redacte una carta de desvinculación con datos reales de un empleado. Lo hace el vendedor que sube una planilla de clientes para que la IA le arme una estrategia de ventas. Lo hace el abogado que pega un contrato en negociación para pedir una revisión más rápida. Ninguno de ellos piensa que está haciendo algo peligroso. Están, simplemente, tratando de hacer mejor su trabajo con la herramienta que tienen a mano.

    Ese comportamiento tiene nombre: Shadow AI, o “IA en las sombras”. Es el uso de chatbots, asistentes o aplicaciones de inteligencia artificial que los empleados incorporan a su rutina sin que el área de sistemas o de seguridad de la empresa lo sepa, lo apruebe o pueda monitorearlo. No es un fenómeno de una industria en particular ni de un tipo de empresa en particular. Es lo que hace, todos los días, una cantidad enorme de personas alrededor del mundo.

    Qué información se está cargando

    El problema no es abstracto. Tiene nombre y apellido, literalmente. Según Cyberhaven Labs, que analizó el comportamiento de aproximadamente siete millones de trabajadores, el 34,8% de los datos corporativos que hoy se comparten con herramientas de inteligencia artificial son sensibles, contra apenas el 10,7% de hace dos años. En otras palabras: la proporción de datos corporativos sensibles que los empleados introducen en herramientas de IA se triplicó en dos años.

    ¿Qué tipo de información es esa? Contratos en negociación. Currículums con datos personales de candidatos. Bases de datos de clientes. Código fuente. Números de una negociación que todavía no se cerró. Historias clínicas, en el caso de empresas de salud. Nada de eso es robado en el sentido tradicional del término. Simplemente se pega en una ventana de chat, y desde ese momento la información puede quedar procesada o almacenada por un tercero bajo condiciones que la empresa debe conocer y evaluar.

    El problema

    Acá aparece el núcleo real del asunto, y es una frase que vale la pena subrayar: el problema no es que los empleados usen inteligencia artificial. El problema es que las empresas todavía no saben qué información están entregándole.

    No es un problema de mala fe ni de falta de compromiso. Es un problema de visibilidad. Muchas organizaciones no tienen un inventario completo de qué herramientas de IA circulan puertas adentro, más allá de las pocas que aprobaron formalmente. Y lo que no se puede ver, no se puede proteger.

    La falsa sensación de seguridad

    Hay una ilusión bastante cómoda en muchas empresas: creer que el problema está resuelto porque alguien bloqueó ChatGPT desde la red corporativa. Pero bloquear una herramienta no significa controlar el uso de inteligencia artificial. Significa, en el mejor de los casos, controlar una puerta. Y mientras tanto, hay otras abiertas: el celular personal, una cuenta particular, una notebook, una extensión del navegador o una función de IA que apareció dentro de un software que la compañía ya utilizaba.

    “No tenemos ChatGPT habilitado” no es lo mismo que “nuestros empleados no usan inteligencia artificial”. La usan desde el celular, desde una cuenta personal, desde una notebook que sacan de la oficina, o desde una función de IA que ya viene incorporada, sin que nadie la haya activado a propósito, dentro de un software que la empresa contrató hace años para otra cosa. Prohibir una herramienta no elimina el hábito: solo lo empuja a un lugar todavía más difícil de ver.

    La pregunta incómoda es mucho más sencilla: ¿cuántos de esos datos que hoy creemos que están dentro de la empresa ya fueron copiados y pegados en una herramienta de IA? Probablemente nadie tenga la respuesta. Y ese es, precisamente, el problema.

    El costo

    Este no es un riesgo teórico, tiene un precio, y ese precio ya fue medido. Según el Cost of a Data Breach Report 2025 de IBM, una de cada cinco organizaciones relevadas reportó una filtración vinculada con Shadow AI. Entre las organizaciones que sufrieron incidentes relacionados con IA, el 97% dijo no contar con controles adecuados de acceso. El impacto económico es todavía más duro: cuando el Shadow AI está involucrado, el costo total de una filtración sube en promedio 670.000 dólares por encima del costo habitual de una brecha de seguridad.

    Y conviene hacer una aclaración antes de seguir: ni siquiera contratar una herramienta de IA de forma oficial y pagar por ella elimina el riesgo por completo. En marzo de 2023, un bug en la librería de código abierto Redis-py, utilizada por OpenAI para gestionar parte de la infraestructura de ChatGPT, hizo que durante una ventana de nueve horas algunos usuarios de ChatGPT Plus pudieran ver información relacionada con otros suscriptores activos. La información potencialmente expuesta incluía nombre, correo electrónico, domicilio de facturación, tipo de tarjeta, últimos cuatro dígitos y vencimiento. OpenAI señaló que el fallo pudo haber expuesto información de pago del 1,2% de los suscriptores Plus activos durante esa franja horaria y aclaró que no se habían expuesto números completos de tarjeta. Fue un error técnico. Pero deja una lección clara: la seguridad de los datos que viajan hacia una IA no depende solo de lo que hace el empleado. Depende también de la robustez del lado que los recibe, algo que ninguna empresa que delega esa información controla del todo.

    A esto se suma el costo legal y reputacional, que no siempre entra en una planilla de Excel pero pesa igual: datos personales de clientes o empleados que terminan, sin que nadie lo autorizara, siendo procesados por un proveedor de IA. En materia de protección de datos, eso puede implicar obligaciones y riesgos regulatorios concretos, además de eventuales problemas vinculados con secreto comercial, confidencialidad y responsabilidad frente a terceros.

    Qué debería hacer una empresa mañana mismo

    Prohibir la IA puede ser la decisión más sencilla de tomar y, al mismo tiempo, una de las menos útiles. Porque el empleado no deja de necesitar resolver el problema que tenía delante. Si la herramienta autorizada no existe, buscará otra. Y cuando la empresa finalmente descubra qué ocurrió, el dato ya habrá salido.

    La respuesta, entonces, es gobernarla. Y eso empieza con pasos simples, que cualquier empresa puede dar sin esperar una gran reforma regulatoria:

    • Mapear, primero que nada, qué herramientas de IA están usando realmente los equipos, más allá de las que la empresa aprobó formalmente.
    • Ofrecer una alternativa corporativa segura y accesible. Si la empresa no da una herramienta buena, el empleado va a buscar una por su cuenta, y ahí empieza todo de nuevo.
    • Escribir y comunicar una política clara, con ejemplos concretos de qué información nunca debe salir de los canales controlados: datos de clientes, información financiera, código fuente, contratos en negociación.
    • Entender que esto es, ante todo, un problema de gobernanza de datos, no una cuestión de disciplina individual. La responsabilidad final es de quien decide cómo se administra la información de la empresa, no de quien —de buena fe, y con la mejor intención— trató de resolver más rápido su trabajo del día.

    La inteligencia artificial ya está adentro de las empresas. El problema es que muchas todavía no saben por dónde entró, qué información está viendo ni qué está saliendo con ella.

    La discusión, entonces, ya no debería ser si los empleados pueden usar IA. La discusión es quién gobierna los datos cuando la IA empieza a formar parte del trabajo cotidiano.

    Porque cuando una empresa descubre qué información salió por una ventana, normalmente ya es demasiado tarde para cerrarla.

  • ICE revela un data lake central para análisis de control migratorio

    ICE revela un data lake central para análisis de control migratorio

    Una adquisición pública del Servicio de Control de Inmigración y Aduanas de Estados Unidos (ICE) reveló la existencia de un data lake centralizado que alimenta los sistemas de análisis utilizados en operaciones de enforcement migratorio, según informó Biometric Update el 24 de agosto de 2025.

    El hallazgo surgió de documentos de contratación pública —procurement— consultados por el medio especializado. La arquitectura descripta apunta a una plataforma de datos integrada que consolida información de múltiples fuentes para sustentar decisiones operativas del ICE, incluyendo, según se informó, capacidades de análisis biométrico y cruce de bases de datos. No se divulgaron detalles técnicos completos sobre los proveedores involucrados ni el volumen de registros almacenados.

    Datos confirmados sobre la arquitectura ICE

    • La existencia del data lake fue revelada a través de documentos de adquisición pública del ICE.
    • La plataforma sostiene sistemas de analytics aplicados a operaciones de enforcement migratorio.
    • La noticia fue publicada por Biometric Update el 24 de agosto de 2025.
    • No se confirmaron públicamente los proveedores tecnológicos contratados ni el alcance total de los datos almacenados.

    Qué se sabe y qué falta confirmar sobre el uso de datos personales

    Lo que los documentos de procurement confirman es la existencia de una infraestructura centralizada de datos operando en el núcleo del sistema de control migratorio estadounidense. Lo que permanece sin confirmar es qué categorías exactas de datos personales integran el lago, bajo qué marcos de retención y acceso opera, y si existen mecanismos de auditoría independiente sobre su uso. La participación de tecnología biométrica —mencionada en la fuente— eleva el nivel de sensibilidad del activo de datos involucrado, aunque los detalles operativos no fueron divulgados públicamente.

    Para los países de América Latina, la relevancia es directa: millones de ciudadanos de la región —mexicanos, guatemaltecos, venezolanos, colombianos, entre otros— figuran en los sistemas de datos migratorios de EE.UU. En el marco de la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México o de la Ley 25.326 de Argentina, el tratamiento de datos de nacionales en sistemas extranjeros no activa jurisdicción directa, pero sí plantea interrogantes sobre derechos ARCO efectivos y transferencias internacionales. Brasil, con la LGPD vigente y la ANPD como autoridad de control, enfrenta una situación análoga cuando los datos de sus ciudadanos en movilidad son procesados por plataformas de terceros países sin garantías equivalentes.

    El próximo hito a seguir es si el Congreso de EE.UU. o alguna organización de litigio estratégico solicita formalmente la divulgación de los contratos completos bajo la Freedom of Information Act (FOIA), lo que determinaría el alcance real de los datos personales de ciudadanos latinoamericanos en el sistema.

  • Auditoría de visibilidad en LLMs: cómo medir lo que la IA dice de tu empresa

    Auditoría de visibilidad en LLMs: cómo medir lo que la IA dice de tu empresa

    Cuando los motores de búsqueda tradicionales dominaban la visibilidad digital, las empresas podían auditar su posicionamiento con herramientas estándar. Con los grandes modelos de lenguaje (LLMs) como punto de consulta, ese tablero de puntuación desapareció: no hay ranking visible, no hay índice público, no hay certeza sobre qué dice un modelo cuando un usuario pregunta por tu categoría o tu marca.

    El problema tiene nombre propio en el ecosistema de inteligencia artificial aplicada al negocio: LLM visibility audit, o auditoría de visibilidad en modelos de lenguaje. La práctica consiste en medir sistemáticamente cómo —y con qué frecuencia— un LLM menciona, describe o posiciona a una organización, producto o concepto cuando recibe preguntas relevantes de un usuario. No es SEO. No es brand monitoring. Es una disciplina nueva que mezcla evaluación de modelos, ingeniería de prompts y análisis cualitativo de outputs.

    Por qué los LLMs cambian las reglas del juego para cualquier empresa con presencia digital

    Hasta hace poco, la visibilidad online era medible: impresiones, clics, posiciones en SERP, menciones en redes. Los LLMs generativos introducen una capa opaca entre el dato y el usuario. Cuando alguien le pregunta a un chatbot “¿cuál es la mejor solución de observabilidad de datos?” o “¿qué herramientas usan los equipos de datos en Latinoamérica?”, el modelo produce una respuesta sintetizada a partir de su entrenamiento —sin revelar fuentes, sin ordenar resultados, sin ofrecer transparencia sobre por qué menciona a ciertos actores y omite a otros. Para las empresas que compiten en mercados técnicos o de nicho, esa caja negra tiene consecuencias comerciales directas.

    El fenómeno no es trivial: analistas de Gartner proyectaron que para 2026 el tráfico orgánico a sitios web caerá hasta un 25% en sectores donde los LLMs respondan consultas de forma directa. Si el modelo no te menciona, simplemente no existís para ese usuario en ese momento de decisión.

    Cómo se estructura una auditoría de visibilidad en LLMs: cinco capas de análisis

    Una auditoría rigurosa no consiste en preguntarle al modelo “¿conocés a tal empresa?” y anotar el resultado. Requiere un protocolo reproducible que opere sobre al menos cinco dimensiones:

    • Frecuencia de mención: qué porcentaje de prompts relevantes al mercado generan una referencia a la organización auditada, sobre un conjunto de cientos o miles de consultas representativas.
    • Posición en la respuesta: si el modelo menciona a la empresa, ¿lo hace en primer lugar, en una lista, como alternativa secundaria o en un contexto negativo?
    • Exactitud factual: los modelos alucinen con regularidad. Parte de la auditoría consiste en comparar lo que el LLM afirma sobre una organización con lo que es verificablemente cierto: fundación, producto, clientes, geografías.
    • Cobertura de categoría: cuando el modelo define la categoría de mercado a la que pertenece la empresa, ¿la define correctamente? ¿La empresa aparece como referente o como entrante tardío?
    • Varianza entre modelos: GPT-4o, Claude, Gemini y Llama tienen datasets de entrenamiento y fechas de corte distintos. La misma consulta puede generar respuestas radicalmente diferentes entre modelos.

    Cuándo aplica una auditoría de visibilidad en LLMs — y cuándo NO

    Esta práctica es relevante cuando una organización compite en mercados donde los tomadores de decisión usan LLMs como primer punto de investigación: software B2B, consultoría tecnológica, servicios financieros especializados, salud digital. No aplica, o aplica con menor urgencia, para negocios cuyo canal de adquisición es completamente independiente de la búsqueda informacional —ventas directas de campo, marketplaces con algoritmo propio, o marcas de consumo masivo donde la intención de compra no pasa por preguntas abiertas a un chatbot. Tampoco reemplaza la auditoría SEO tradicional: ambas miden canales distintos que coexisten.

    El desafío técnico-legal que llega a LATAM: opacidad de modelos y derechos de rectificación

    En América Latina, la auditoría de visibilidad en LLMs abre una dimensión jurídica que todavía no tiene respuesta clara. Si un modelo afirma algo factualmente incorrecto sobre una empresa o sobre una persona —que una compañía tiene sede en un país distinto, que un profesional fue sancionado cuando no lo fue— ¿quién responde y bajo qué marco? En Brasil, la Lei Geral de Proteção de Dados (LGPD) reconoce el derecho de rectificación de datos inexactos en su artículo 18, inciso III, pero su aplicación sobre outputs de modelos generativos es un territorio sin jurisprudencia consolidada. En Argentina, la Ley 25.326 contempla el derecho de rectificación y actualización de datos personales, con supervisión de la Agencia de Acceso a la Información Pública (AAIP); sin embargo, la AAIP no ha emitido hasta la fecha lineamientos específicos sobre LLMs. México, a través del INAI, enfrenta la misma laguna regulatoria.

    El AI Act de la Unión Europea, aplicable a sistemas de IA de alto riesgo, exige documentación sobre los datos de entrenamiento y mecanismos de supervisión humana, lo que teóricamente permitiría auditar la fuente de una mención incorrecta. Para empresas latinoamericanas que operan o aspiran a operar en el mercado europeo, ese estándar empieza a ser una referencia práctica incluso antes de que exista legislación regional equivalente.

    Tres pasos para iniciar una auditoría de visibilidad sin infraestructura especializada

    No hace falta una plataforma dedicada para comenzar. Un equipo de datos con acceso a las APIs de los principales modelos puede construir un protocolo básico en semanas. El primer paso es definir el universo de consultas: entre 200 y 500 prompts que representen las preguntas reales que un comprador, periodista o investigador haría sobre la categoría. El segundo paso es ejecutar esas consultas de forma sistemática —automatizada vía API, no manual— y registrar los outputs en una estructura comparable. El tercer paso es codificar los resultados: mención positiva, mención neutral, mención negativa, ausencia, error factual. Con esa matriz, es posible calcular una métrica de visibilidad baseline y repetir el proceso cada vez que los modelos publiquen nuevas versiones o actualizaciones de entrenamiento.

    Para quienes diseñan estrategias de posicionamiento de marca o de producto en mercados técnicos, la pregunta ya no es si los LLMs influyen en la percepción —es si sus organizaciones tienen algún instrumento para saberlo antes de que el daño sea visible en pipeline.

  • Meta nombra a su primer Chief Data Officer: Alex Schultz asume el cargo

    Meta nombra a su primer Chief Data Officer: Alex Schultz asume el cargo

    Meta designó a Alex Schultz, hasta ahora Chief Marketing Officer de la compañía, como su primer Chief Data Officer. El movimiento, según se informó, se hizo efectivo en febrero de 2026 y marca un punto de inflexión en cómo la empresa propietaria de Facebook, Instagram y WhatsApp decide estructurar la autoridad sobre sus datos a nivel ejecutivo.

    La creación de un rol de CDO en Meta no es un cambio cosmético. Hasta ahora, la compañía operaba sin un ejecutivo con responsabilidad formal y exclusiva sobre la estrategia de datos corporativos. Que ese rol recaiga en el CMO saliente —alguien con dos décadas de exposición a los activos de datos de Meta para publicidad y medición— sugiere que la empresa no está separando el negocio de los datos del negocio de los datos: está consolidando ambos bajo una sola firma ejecutiva.

    Por qué un CMO como primer CDO de Meta no es una elección obvia

    El perfil típico de un CDO en empresas de tecnología proviene de ingeniería de datos, analytics o, con creciente frecuencia, del área legal y de privacidad. Schultz, en cambio, llega desde el marketing. Su carrera en Meta estuvo centrada en el uso de datos para crecimiento de usuarios y rendimiento publicitario, no en la arquitectura de datos ni en el cumplimiento regulatorio como foco principal. Eso plantea una pregunta de diseño organizacional: ¿el CDO de Meta será ante todo un habilitador comercial de los datos, o asumirá también la responsabilidad de gobernanza, calidad y cumplimiento que los reguladores globales empiezan a exigir explícitamente a las empresas de su escala?

    Según el marco DAMA-DMBOK, las funciones de un CDO de madurez alta incluyen la gestión del ciclo de vida del dato, la definición de políticas de calidad, el data lineage —trazabilidad del origen y transformación de cada dato— y la interacción con autoridades de control. En Meta, esas capacidades estuvieron distribuidas históricamente entre equipos de ingeniería, legal y producto. Centralizarlas bajo un CDO con un perfil comercial puede acelerar la monetización de datos, pero también puede generar tensiones con los equipos de privacidad si la función no tiene mandato claro sobre compliance.

    El contexto regulatorio que hace urgente esta designación en 2026

    Meta opera en un entorno regulatorio que, desde 2023, no ha hecho más que complejizarse. En Europa, la compañía acumuló multas superiores a 2.000 millones de euros bajo el Reglamento General de Protección de Datos (RGPD) por transferencias internacionales y bases legales de tratamiento. En Brasil, la Autoridade Nacional de Proteção de Dados (ANPD) tiene jurisdicción sobre millones de usuarios y ha mostrado disposición a actuar contra plataformas globales. En México, el Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales (INAI) y la Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) establecen obligaciones de seguridad y aviso que aplican a cualquier empresa que trate datos de ciudadanos mexicanos, independientemente de su sede. En Argentina, la Agencia de Acceso a la Información Pública (AAIP) supervisa el cumplimiento de la Ley 25.326, cuya reforma —en discusión desde hace años— incluiría figuras de responsabilidad ejecutiva más explícitas.

    Tener un CDO identificable y con autoridad real se convierte, en ese contexto, en algo más que una decisión de estructura interna: es una respuesta a la presión de los reguladores que exigen interlocutores ejecutivos con poder de decisión sobre datos. La pregunta que no responde la designación de Schultz es si su mandato incluirá esa dimensión regulatoria o quedará acotado a la estrategia comercial de datos.

    Cuándo aplica este modelo y cuándo no

    La decisión de Meta de promover internamente a un ejecutivo de negocio como CDO en lugar de contratar un perfil técnico o legal es replicable en organizaciones donde los datos son ante todo un activo de monetización y el equipo de ingeniería ya tiene madurez suficiente para operar sin supervisión ejecutiva directa. No es el modelo adecuado para organizaciones en etapas tempranas de gobernanza de datos, donde el CDO necesita construir capacidades básicas —catálogo, clasificación, ownership formal— antes de pensar en estrategia comercial. Tampoco es recomendable cuando la empresa enfrenta investigaciones regulatorias activas que requieren un perfil con experiencia específica en cumplimiento normativo de datos.

    Para empresas latinoamericanas de escala media que estén definiendo el perfil de su primer CDO, el caso Meta ilustra tanto las posibilidades como los riesgos del enfoque: un CDO con peso político interno puede mover la organización, pero sin mandato explícito sobre gobernanza, el rol puede convertirse en una capa adicional de gestión sin impacto real en la calidad ni en el cumplimiento de los datos.

    Lo que la designación revela sobre el momento del mercado

    Que una de las empresas con mayor volumen de datos del mundo no tuviera un CDO formal hasta 2026 dice algo sobre la velocidad a la que las presiones regulatorias y de gobernanza están alcanzando incluso a las organizaciones más grandes. Durante años, Meta pudo operar con una estructura distribuida porque la regulación era fragmentada y la presión de cumplimiento, manejable. Esa ecuación cambió. El nombramiento de Schultz es, en parte, una respuesta institucional a ese cambio: formalizar la autoridad sobre los datos cuando ya no es posible postergar esa decisión sin costos visibles.

    Para profundizar en los marcos de referencia que definen las responsabilidades del CDO moderno, el DAMA-DMBOK (Data Management Body of Knowledge) y el CDMC del EDM Council son los estándares más citados por autoridades regulatorias y equipos de gobernanza en América Latina.

  • Agentes de IA: el software dejó de responder y empezó a actuar

    Agentes de IA: el software dejó de responder y empezó a actuar

    La discusión sobre inteligencia artificial se corrió de lugar: el problema ya no es qué contesta un modelo, sino qué hace un agente en nombre de la organización —y si alguien puede probarlo después.

    Durante los últimos dos años discutimos la inteligencia artificial como si fuera un problema de contenido: qué responde el modelo, si alucina, si discrimina, si reproduce material ajeno. Esa discusión no terminó, pero quedó corta. Lo que hoy se está desplegando en las organizaciones de la región no responde: ejecuta. Abre un ticket, consulta una base, escribe en un CRM, cruza un padrón, aprueba un reintegro, contesta un correo, invoca a otro sistema y, cada vez con más frecuencia, invoca a otro agente.

    Ese desplazamiento —del asistente al agente— no es una mejora de producto. Es un cambio de naturaleza. Un modelo que sugiere deja al humano en el centro de la decisión. Un agente que actúa lo corre del centro. Y cuando el humano se corre, se corren con él tres cosas que el Derecho necesita para funcionar: la autoría del acto, la voluntad que lo respalda y la prueba de lo que efectivamente ocurrió.

    El punto ciego: nadie sabe cuántos agentes tiene

    En los relevamientos que venimos haciendo en Data Governance Latam, la pregunta que más incomoda no es sobre modelos ni sobre proveedores. Es mucho más simple: ¿cuántos agentes están corriendo hoy en su organización, con qué credenciales y contra qué datos? La respuesta casi nunca existe en un documento. Existe, en el mejor de los casos, en la cabeza de tres personas de distintas áreas que nunca se sentaron juntas.

    Esto no ocurre por negligencia. Ocurre porque la adopción de agentes no pasa por el circuito clásico de compra de tecnología. Vienen embebidos en suites que la empresa ya tiene licenciadas, se activan con un toggle, se configuran desde un área de negocio y se conectan a los mismos repositorios donde están los datos personales, las historias clínicas, los legajos del personal, la cartera comercial. El resultado es un parque de automatismos que crece más rápido que el inventario que debería describirlo.

    Un agente no es una herramienta más: es un tratamiento de datos con autonomía operativa y credenciales propias.

    Los riesgos que no están en el checklist

    El análisis de riesgo tradicional de IA —sesgo, exactitud, transparencia— sigue siendo necesario, pero no alcanza para describir lo que introduce un agente. Hay cuatro problemas que aparecen sistemáticamente y que rara vez están cubiertos por las políticas vigentes:

    • Permisos heredados. El agente suele operar con las credenciales del usuario que lo habilitó, o con una cuenta de servicio sobredimensionada. Hereda accesos que ese usuario jamás ejerció en la práctica, y los ejerce todos, a velocidad de máquina.
    • Superficie de ataque semántica. La inyección de instrucciones —en un correo, en un documento, en el contenido de una web que el agente lee— convierte a un dato de entrada en una orden. El perímetro deja de ser la red y pasa a ser el texto.
    • Cadena de terceros opaca. El agente llama a un modelo, que llama a una API, que llama a otro servicio. La transferencia internacional de datos deja de ser un evento contractual identificable y pasa a ser un comportamiento en tiempo de ejecución.
    • Ausencia de registro útil. Muchas plataformas registran que hubo una interacción, no qué datos se leyeron, con qué instrucción, bajo qué versión de modelo y con qué salida. Es un log contable, no un log probatorio.

    El problema no es el incidente: es no poder reconstruirlo

    Toda la arquitectura regulatoria en materia de protección de datos —de la Ley 25.326 al RGPD, de la Ley 21.719 chilena a la LGPD brasileña— descansa sobre el principio de responsabilidad proactiva. Y la responsabilidad proactiva, despojada de retórica, significa una sola cosa: capacidad de demostrar. No basta con haber hecho las cosas bien; hay que poder probar que se hicieron bien, ante un regulador, ante un juez o ante un titular que ejerce sus derechos.

    Ahí es donde el modelo agéntico expone la debilidad más seria. Cuando un proceso automatizado deriva en una filtración, en una decisión errónea o en un uso de datos fuera de finalidad, la primera pregunta del expediente no es técnica ni ética: es probatoria. Quién autorizó, qué instrucción recibió el sistema, a qué información accedió, en qué momento, y si la salida fue producto de una regla, de un modelo o de una manipulación externa. Sin trazabilidad diseñada de antemano, la accountability es una declaración de buenas intenciones que no sobrevive al primer requerimiento formal.

    Conviene anotar un dato de mercado que anticipa hacia dónde va esto: los aseguradores ya están ajustando la letra chica. Las coberturas cíber tradicionales fueron redactadas para incidentes con un atacante externo y un vector identificable, no para un sistema propio que actuó autónomamente dentro del perímetro. La discusión sobre exclusiones y sobre qué evidencia se exige para liquidar un siniestro va a llegar a los directorios antes que la mayoría de las normas específicas.

    La continuidad lógica del data governance

    Frente a este escenario aparece la tentación de tratar la gobernanza de IA como una disciplina nueva, con su propio comité, su propio marco y su propia consultoría. Creemos que es un error de diagnóstico, y en Data Governance Latam lo venimos sosteniendo desde antes de que los agentes fueran el tema de la temporada: gobernar agentes no es empezar de cero, es la continuidad lógica de gobernar datos.

    Quien ya construyó un inventario de bases y flujos tiene el esqueleto del inventario de agentes. Quien definió finalidades, bases de licitud y plazos de conservación tiene el criterio para evaluar si un automatismo puede acceder a un dato. Quien tiene un ROPA vivo, un procedimiento de evaluación de impacto y una matriz de roles y accesos ya construyó tres de los cinco controles que un agente necesita. Y quien trabajó la gestión de proveedores sabe que la pregunta relevante nunca fue el logo del proveedor, sino qué hace con los datos y qué evidencia entrega cuando algo sale mal.

    La organización que hizo ese trabajo no tiene que reinventarse: tiene que extender su marco a un actor nuevo que no es humano, no es un empleado, no es exactamente un sistema pasivo y sin embargo actúa con efectos jurídicos. La que no lo hizo va a descubrir que el problema nunca fue la IA. Era la gobernanza de datos que se venía postergando, ahora con un multiplicador de velocidad encima.

    Cinco preguntas para llevar al directorio

    Más allá de los marcos y las certificaciones, hay cinco preguntas que cualquier órgano de administración debería poder responder hoy, sin convocar a un consultor:

    1. Inventario. ¿Existe un registro único de agentes en producción, con responsable asignado por cada uno?
    2. Alcance. ¿Sabemos a qué datos accede cada agente y por qué necesita ese acceso y no uno menor?
    3. Intervención humana. ¿Qué decisiones puede tomar un agente sin validación humana, y quién definió ese umbral?
    4. Evidencia. Si mañana hay un requerimiento de la autoridad de control, ¿podemos reconstruir qué hizo el agente, con qué datos y bajo qué instrucción?
    5. Salida. ¿Existe un procedimiento probado para apagar un agente y contener su efecto, o solo sabemos cómo encenderlo?

    Ninguna de las cinco es una pregunta de tecnología. Las cinco son de gobierno.

    El horizonte normativo

    El marco regulatorio se está moviendo, aunque de manera despareja. En Europa, el AI Act ya definió obligaciones escalonadas y la revisión del régimen de responsabilidad por productos alcanza al software. En la región, la Ley 21.719 de Chile instala un estándar de cumplimiento con autoridad de control y régimen sancionatorio propio; Brasil discute su marco de IA sobre una base de protección de datos ya madura; y en Argentina el proyecto de reforma de la ley de datos personales continúa en debate, con una discusión pendiente sobre decisiones automatizadas que no se puede resolver copiando artículos ajenos.

    Pero apostar todo a la fecha de entrada en vigencia de una norma es un error de cálculo. La exigencia no va a llegar por vía regulatoria: va a llegar por contrato o mercado. Los cuestionarios de terceros, las cláusulas de auditoría de los clientes grandes, van a pedir evidencia de control sobre agentes bastante antes de que exista un régimen sancionatorio específico. Como siempre, la cadena de suministro regula más rápido que el legislador.

    La conclusión es incómoda pero simple: la IA agéntica no crea un problema nuevo de gobernanza de datos. Lo hace visible, lo acelera y lo vuelve imposible de postergar.

    En Data Governance Latam sabemos cómo ayudarte. Aguardamos tu contacto en contacto@datagovernancelatam.com

  • IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    IA que diseña fármacos: quién se lleva el crédito (y la responsabilidad)

    Cuando Insilico Medicine anunció que su plataforma de inteligencia artificial había “descubierto” una molécula candidata para tratar la fibrosis pulmonar, abrió sin quererlo un debate jurídico que va mucho más allá del marketing farmacéutico: si una IA diseña un fármaco, ¿a quién pertenece ese hallazgo y quién responde si falla?

    La atribución de autoría en ciencia siempre fue complicada. Pero la irrupción de sistemas de inteligencia artificial generativa en el descubrimiento de fármacos agrega una capa de ambigüedad que los marcos legales vigentes —pensados para inventores humanos— no resuelven con claridad. El caso de Insilico Medicine, que usó sus modelos computacionales para proponer una molécula prometedora contra la fibrosis pulmonar, ilustra exactamente esa tensión: la empresa no dudó en atribuirle a su IA el rol de descubridora, una afirmación con consecuencias directas sobre patentes, responsabilidad civil y regulación sanitaria.

    Patentes sin inventor humano: el límite que ya se está probando en tribunales

    El sistema de patentes fue diseñado bajo un supuesto que hoy tambalea: que detrás de cada invención hay una persona física. En Estados Unidos, la Corte de Apelaciones del Circuito Federal resolvió en 2022 que el sistema DABUS —desarrollado por Stephen Thaler— no podía figurar como inventor en una solicitud de patente porque la ley exige que el inventor sea humano. El Reino Unido llegó a la misma conclusión por la vía del Supremo en 2023. La pregunta que queda abierta es cuánto cambia la ecuación cuando la IA no figura como inventora pero es la que, en los hechos, genera la hipótesis central del compuesto.

    Insilico y otras empresas del sector —Exscientia, Recursion, Absci— posicionan a sus plataformas como co-diseñadoras o aceleradoras del proceso de descubrimiento. Desde el punto de vista de la estrategia de propiedad intelectual, esa distinción importa: si la IA “descubre” y el humano solo valida, la solidez jurídica de la patente puede cuestionarse por insuficiencia inventiva humana. Si el humano es quien dirige y la IA es una herramienta sofisticada —equivalente a un espectrómetro de masas muy avanzado—, la patente se sostiene. El lenguaje del press release, entonces, no es inocente.

    Responsabilidad downstream: quién responde cuando el fármaco falla en fase clínica

    La atribución de crédito no es solo una cuestión de ego corporativo o relaciones públicas. Tiene un correlato directo en la cadena de responsabilidad. Si un compuesto propuesto por IA llega a ensayos clínicos y genera efectos adversos imprevistos, los marcos de responsabilidad vigentes necesitan identificar un responsable: ¿el desarrollador del modelo, la empresa farmacéutica que lo adoptó, el equipo científico que validó la hipótesis, o el organismo regulador que habilitó el ensayo? La respuesta depende en parte de cómo se documentó la participación de la IA en cada etapa del proceso.

    Este problema no es teórico. La FDA de Estados Unidos ya publicó lineamientos preliminares sobre el uso de inteligencia artificial y machine learning en el desarrollo de dispositivos médicos, y está trabajando en marcos similares para el proceso de aprobación de nuevos fármacos. La EMA europea sigue una trayectoria paralela. La pregunta es si la atribución narrativa —lo que una empresa dice en un comunicado— puede tener efectos jurídicos en un litigio posterior sobre daños.

    El AI Act europeo y la clasificación de riesgo en aplicaciones biomédicas

    El Reglamento de Inteligencia Artificial de la Unión Europea (AI Act, Reglamento UE 2024/1689) clasifica como sistemas de alto riesgo a aquellos usados en el ámbito de la salud cuando toman o influyen decisiones relevantes. Un sistema de IA que propone moléculas para uso terapéutico humano califica, en principio, dentro de esa categoría: exige documentación técnica exhaustiva, supervisión humana verificable y trazabilidad de las decisiones del modelo. Eso significa que “la IA lo descubrió” no puede ser el final del relato regulatorio —tiene que haber un humano que pueda explicar, auditar y asumir la decisión.

    Cuándo aplica este debate / cuándo NO

    El conflicto de atribución se vuelve jurídicamente relevante cuando el output de la IA es la hipótesis central de una solicitud de patente, cuando el compuesto avanza hacia ensayos en humanos, o cuando la empresa hace afirmaciones públicas sobre la autoría del sistema. No aplica con la misma intensidad cuando la IA funciona como herramienta de cribado masivo (virtual screening) dentro de un proceso en el que el equipo científico genera y selecciona hipótesis de forma sustantiva. La distinción operativa —IA como autor versus IA como instrumento— es la que definirá los casos que lleguen a litigio en los próximos años.

    América Latina: marcos de IA en construcción, sector farmacéutico ya activo

    En la región, el debate llega antes que los marcos regulatorios. Brasil avanza con el Projeto de Lei 2.338/2023 sobre regulación de IA, que incluye disposiciones sobre sistemas de alto riesgo en salud pero no aborda específicamente la atribución de autoría inventiva a sistemas automatizados. Argentina no tiene legislación de IA aprobada al cierre de esta nota, aunque el INPI —Instituto Nacional de la Propiedad Industrial— ya enfrenta solicitudes que implican procesos asistidos por IA. México, por su parte, tiene una industria farmacéutica de escala regional y un IMPI que todavía opera bajo los criterios tradicionales de inventiva humana contemplados en la Ley Federal de Protección a la Propiedad Industrial. Ninguno de los tres países tiene hoy una respuesta clara para la pregunta que Insilico planteó en su press release.

    La presión llegará desde afuera hacia adentro: cuando una empresa extranjera intente patentar en México, Brasil o Argentina un compuesto cuyo origen sea un sistema de IA, las oficinas de propiedad industrial deberán decidir sin doctrina previa. Ese vacío no es neutral —favorece a quien primero defina el marco.

    Para profundizar en el marco regulatorio europeo, el texto completo del AI Act está disponible en el Diario Oficial de la Unión Europea (DO L, 12 de julio de 2024); el Proyecto de Lei 2.338/2023 de Brasil puede consultarse en el sitio del Senado Federal.

  • Marco de gobernanza de datos de GEI para el transporte Ro-Ro marítimo

    Marco de gobernanza de datos de GEI para el transporte Ro-Ro marítimo

    La industria del transporte marítimo Ro-Ro —buques que cargan y descargan vehículos por rampa— acaba de estrenar un marco sectorial de gobernanza de datos de gases de efecto invernadero (GEI). La iniciativa apunta a estandarizar cómo se recopilan, validan y reportan las emisiones a lo largo de la cadena logística, en un momento en que los reguladores internacionales y regionales exigen trazabilidad creciente sobre huella de carbono.

    El marco, según se informó, fue diseñado para dar respuesta a un problema de larga data en el sector: la ausencia de definiciones comunes sobre qué datos de emisiones deben capturarse, quién es su propietario, cómo deben verificarse y bajo qué estándar deben comunicarse a clientes y autoridades. Sin esa base compartida, los reportes de GEI de distintos operadores resultan incomparables entre sí y, en muchos casos, inauditables.

    Qué resuelve el marco: ownership del dato de carbono y linaje verificable

    En términos de gobernanza de datos, el nudo central que aborda este framework es el del data ownership y el data lineage aplicados a un dato no financiero: la tonelada de CO₂ equivalente. Históricamente, en rutas Ro-Ro los datos de consumo de combustible y emisiones quedaban dispersos entre el operador del buque, el agente de carga, el armador y el embarcador de vehículos. Nadie tenía ownership formal sobre el dato agregado, y el linaje —es decir, la cadena de custodia desde el sensor de flujo de combustible hasta el reporte regulatorio— era opaco o directamente inexistente. El marco busca asignar roles claros equivalentes a los de data steward por segmento de la cadena.

    La estructura propuesta, según se informó, define capas de responsabilidad: quién genera el dato primario (el operador del buque), quién lo consolida por viaje (el armador o gestor técnico) y quién lo reporta ante la autoridad competente o el cliente final. Esta arquitectura de roles se alinea con los principios del DAMA-DMBOK en su capítulo de gestión de datos de referencia y maestros, trasladados aquí a un dominio de datos ambientales.

    El contexto regulatorio que fuerza la estandarización: IMO, UE y la presión sobre puertos latinoamericanos

    El impulso detrás de este marco no es voluntario en sentido estricto. La Organización Marítima Internacional (OMI) tiene en vigencia su estrategia revisada de reducción de GEI con metas para 2030 y 2050, y la Unión Europea incorporó al transporte marítimo en su sistema EU ETS (Emissions Trading System) a partir de 2024. Eso significa que cualquier buque que opere en puertos europeos —incluidas escalas en rutas que tocan el Atlántico sur— debe reportar emisiones verificadas bajo el Reglamento MRV (Monitoring, Reporting and Verification) de la UE.

    Para América Latina, esto tiene una implicancia concreta: los puertos de Buenos Aires, Montevideo, Santos y Valparaíso operan como eslabones en rutas que conectan con Europa. Los armadores y operadores logísticos que usan esos puertos en tráfico Ro-Ro —principalmente exportaciones de vehículos terminados desde México y Brasil y maquinaria agrícola desde Argentina— quedan expuestos al EU ETS indirectamente, porque sus clientes europeos deben acreditar la huella de carbono de su logística de importación. Sin datos de GEI estructurados y auditables desde origen, esa acreditación no es posible.

    Cuándo aplica este marco y cuándo NO

    El framework aplica directamente a operadores de buques Ro-Ro y a los embarcadores —típicamente terminales automotrices, fabricantes de maquinaria y empresas de logística especializada— que necesiten reportar emisiones Scope 3 de transporte marítimo bajo estándares como el GHG Protocol o el CDP. También es relevante para puertos que estén construyendo sus propios inventarios de emisiones por actividad portuaria. No aplica, en cambio, a empresas de transporte terrestre o multimodal que no tengan exposición a la normativa marítima internacional, ni a operadores de rutas estrictamente domésticas sin conexión a puertos sujetos al EU ETS o al sistema MRV.

    Lo que un CDO de logística marítima necesita resolver primero

    Para un Chief Data Officer o Data Lead en una empresa naviera, terminal portuaria o exportador de vehículos con operaciones en la región, el punto de partida práctico es un inventario de fuentes de datos de consumo energético: sistemas de gestión del buque (BMS), registros de bunker, AIS y los propios manifiestos de carga. El siguiente paso es mapear quién tiene hoy acceso de escritura sobre esos registros —es decir, quién puede modificarlos— y establecer controles de calidad mínimos: completitud, frecuencia de actualización y trazabilidad de cambios. Sin ese diagnóstico, cualquier adhesión formal al nuevo marco será cosmética. El EDM Council (DCAM) ofrece una capability de gestión de datos críticos que puede adaptarse a este dominio ambiental como punto de referencia para medir madurez.

    Para profundizar en los requerimientos técnicos del sistema MRV de la UE aplicado al transporte marítimo, la fuente oficial es el Reglamento (UE) 2015/757 y sus modificaciones, disponibles en el portal EUR-Lex de la Comisión Europea.

  • Meta nombra a su primer Chief Data Officer: qué implica el rol

    Meta nombra a su primer Chief Data Officer: qué implica el rol

    Meta designó a Alex Schultz como su primer Chief Data Officer, según se informó en agosto de 2025. La creación formal del rol en una compañía de esa escala no es un movimiento cosmético: indica que la función de gobernanza de datos dejó de ser absorbible por el liderazgo de ingeniería o privacidad y exige representación propia en el C-suite.

    El cargo de CDO —Chief Data Officer— existe formalmente en el sector financiero y regulado desde principios de los 2010, impulsado en parte por la exigencia de marcos como Basel III y, más tarde, por las disposiciones del BCBS 239 para bancos sistémicamente importantes. Que una empresa de tecnología de consumo masivo como Meta lo cree recién ahora revela una brecha estructural: durante años, la gobernanza de datos fue disuelta entre equipos de producto, ingeniería y legal, sin un propietario ejecutivo único con mandato transversal.

    Qué hace un CDO que no hace un CTO ni un DPO

    La confusión entre roles es frecuente. El Chief Technology Officer (CTO) gobierna la arquitectura y la infraestructura; el Data Protection Officer (DPO) —exigido por el RGPD europeo y sus equivalentes latinoamericanos— responde específicamente por el tratamiento de datos personales y actúa como interlocutor ante las autoridades de control. El CDO, en cambio, tiene mandato sobre el dato como activo corporativo: su calidad, su ciclo de vida, su linaje (data lineage), los dominios y los data stewards que los gestionan, y la capacidad de la organización de monetizarlos o utilizarlos para decisiones confiables. Según el marco DAMA-DMBOK, estas funciones se agrupan en once áreas de conocimiento —desde arquitectura de datos hasta gestión de documentos y contenido— que raramente tienen un responsable único a nivel ejecutivo.

    El EDM Council, a través de su marco CDMC (Cloud Data Management Capabilities), describe doce capabilities que una organización madura debe demostrar. La ausencia de un CDO formal suele correlacionar con brechas en las capabilities 4 (Data Ownership) y 7 (Data Quality), precisamente porque sin un ejecutivo con mandato explícito, la asignación de ownership recae en acuerdos informales entre equipos.

    Por qué 2025 y no 2015: presión regulatoria como catalizador

    El timing no es casual. Meta opera bajo el escrutinio de la Comisión Europea tras las multas históricas impuestas por la Autoridad de Protección de Datos de Irlanda (DPC) en aplicación del RGPD —incluyendo la sanción de 1.200 millones de euros de mayo de 2023 por transferencias de datos a Estados Unidos—. A eso se suma la presión del AI Act europeo, vigente desde agosto de 2024, que para los sistemas de IA de alto riesgo exige trazabilidad de los datos de entrenamiento y mecanismos de gobernanza documentados. Un CDO con mandato formal es, en ese contexto, también una respuesta de arquitectura organizacional ante reguladores que preguntan quién responde por el dato.

    En América Latina, el mismo patrón se reproduce con menor visibilidad pública. La Lei Geral de Proteção de Dados de Brasil (LGPD, Lei 13.709/2018) exige la figura del Encarregado —equivalente funcional al DPO— pero no menciona al CDO. Sin embargo, la Autoridade Nacional de Proteção de Dados (ANPD) ha comenzado a fiscalizar la existencia de programas de gobernanza de datos como parte de la evaluación de accountability. En Argentina, la AAIP (Agencia de Acceso a la Información Pública) y el proyecto de modernización de la Ley 25.326 apuntan en la misma dirección: las empresas que procesan datos a escala ya no pueden invocar “responsabilidad difusa” ante un incidente.

    Cuándo aplica el rol de CDO / cuándo NO

    El CDO tiene sentido operativo cuando la organización supera ciertos umbrales de complejidad: múltiples dominios de datos con owners distintos, pipelines de analítica que cruzan unidades de negocio, o exigencias regulatorias que requieren demostrar linaje y calidad ante un auditor externo. No es una figura necesaria en organizaciones pequeñas con un único dominio de datos o en empresas donde el CTO puede absorber esa responsabilidad sin conflicto de mandatos. Bob Seiner, referente de Non-Invasive Data Governance, argumenta que el rol ejecutivo sólo funciona si hay data stewards operativos debajo: sin esa red, el CDO se convierte en un cargo de nombre sin palancas reales de cambio.

    En el sector financiero latinoamericano, bancos que reportan al Banco Central de Brasil o al BCRA bajo marcos de riesgo operacional ya operan con capabilities equivalentes a las del CDMC, aunque en muchos casos sin la certificación formal ni el título ejecutivo. La designación de Meta puede funcionar como señal de mercado que acelere la formalización de esos roles en empresas de tecnología y retail de la región.

    Lo que hace un CDO en las primeras semanas del mandato

    Más allá del anuncio, la efectividad del rol depende de decisiones tempranas. Schultz —quien, según se informó, ya ocupaba el cargo de Chief Marketing Officer en Meta— deberá establecer en qué dominios de datos no existe ownership formal asignado, cuál es el estado del catálogo de datos corporativo y si hay una definición acordada de calidad mínima aceptable por dominio. La primera entrega concreta suele ser un mapa de dominios con stewards nombrados, un inventario de activos críticos y una propuesta de estructura de gobierno que separe las decisiones que toma el CDO de las que delega. Sin esos productos en las primeras doce semanas, el cargo pierde tracción ejecutiva rápidamente.

    Para organizaciones de la región que aún debaten si crear el rol, el marco DAMA-DMBOK (segunda edición, disponible en dama.org) y el CDMC del EDM Council ofrecen los criterios más precisos para evaluar si la complejidad de su portafolio de datos justifica —o exige— un CDO con mandato propio.

  • Contratos de datos: el acuerdo que la IA obliga a formalizar

    Contratos de datos: el acuerdo que la IA obliga a formalizar

    Los data contracts —acuerdos formales sobre cómo se produce, entrega y consume un dato entre equipos— dejaron de ser una práctica de vanguardia para convertirse en un requisito operativo. La presión llega desde la capa de inteligencia artificial: cuando un modelo falla, la causa más frecuente no es el algoritmo sino el dato que lo alimenta, y sin un contrato que defina responsabilidades, nadie sabe a quién corresponde resolver el problema.

    Un data contract es, en su definición operativa, un acuerdo explícito y versionado entre el equipo productor de un dato y los equipos que lo consumen. Especifica el esquema, la frecuencia de actualización, los SLAs de calidad, el propietario (data owner) y las condiciones bajo las cuales el contrato puede modificarse. La analogía con los contratos de API es útil: así como una API define qué esperar de un servicio, el data contract define qué esperar de un dataset. La diferencia es que los contratos de datos incluyen semántica de negocio, no solo estructura técnica.

    Por qué la IA accelera la adopción de data contracts en 2025

    Los pipelines de machine learning e inteligencia artificial generativa son especialmente frágiles frente a cambios silenciosos en los datos de entrada: un campo que pasa de texto libre a codificado, una frecuencia que se reduce de diario a semanal, un valor nulo que antes era cero. Sin data contracts, estos cambios se propagan sin aviso hasta el modelo, que comienza a producir outputs degradados o directamente incorrectos. El costo de detectar esa degradación aguas abajo —en producción, en una decisión de negocio— es ordenes de magnitud mayor que haberlo detectado en la fuente. Los equipos de datos que operan sin data contracts en un entorno de IA están, en la práctica, gestionando riesgo operativo sin instrumentos formales.

    El marco DAMA-DMBOK v2 no usa el término “data contract” de forma explícita, pero el concepto es la instancia operativa de lo que el estándar llama Data Architecture y Data Quality agreements: acuerdos documentados sobre expectativas y responsabilidades entre productores y consumidores. El EDM Council, en su CDMC (Cloud Data Management Capabilities), lo incorpora en las capabilities de control de acceso y linaje (data lineage) como prerequisito para auditar el flujo de datos sensibles. Autores como Andrew Jones —quien popularizó el término en su forma moderna— argumentan que el data contract es la unidad mínima de gobernanza en arquitecturas orientadas a datos.

    Qué contiene un data contract útil: cinco elementos que no pueden faltar

    • Esquema versionado: nombre, tipo y descripción de cada campo, con historial de cambios.
    • SLA de calidad: completitud mínima, tasa de nulos aceptable, latencia máxima de entrega.
    • Data owner identificable: persona o equipo con nombre, no un área genérica.
    • Política de cambios: notificación mínima ante modificaciones de esquema o frecuencia (generalmente 5 a 15 días hábiles).
    • Clasificación del dato: etiqueta de sensibilidad (público, interno, confidencial, restringido) alineada con la política de data governance corporativa.

    Cuándo aplica / cuándo NO

    Los data contracts son pertinentes cuando hay al menos dos equipos distintos que producen y consumen el mismo dato, cuando ese dato alimenta un modelo de IA, un reporte regulatorio o una decisión de negocio crítica, y cuando los cambios en el dato pueden propagarse sin visibilidad hacia consumidores. No aplican —o no es prioritario formalizarlos— en datasets experimentales de uso único, en exploraciones de ciencia de datos sin destino productivo, o en equipos de menos de cinco personas donde la coordinación informal todavía funciona. El error más común es intentar contratar todos los datos al mismo tiempo: la recomendación práctica es comenzar por los datasets que alimentan modelos en producción o que son fuente de reportes regulatorios.

    En LATAM: bancos, telcos y el reporte regulatorio como driver de adopción

    En América Latina, el driver de adopción más concreto no es la IA sino el reporte regulatorio. Los bancos que reportan al Banco Central de Brasil (BACEN) bajo las exigencias de Open Finance, o los que reportan al BCRA argentino bajo la Comunicación A 7724 y sus actualizaciones, ya operan con acuerdos tácitos de calidad de datos entre áreas. La diferencia es que esos acuerdos raramente están documentados como data contracts formales: viven en correos electrónicos, en reuniones de comité de datos, o en la memoria de un data steward que lleva cinco años en la organización. Cuando esa persona se va, el conocimiento se va con ella. Las telcos en México y Colombia enfrentan el mismo problema con los datos que alimentan sus modelos de churn prediction y scoring crediticio alternativo: la informalidad del acuerdo se vuelve riesgo operativo en cuanto el modelo entra en producción.

    Un CDO que quiera dar el primer paso concreto puede empezar auditando los cinco datasets más críticos de su organización —los que alimentan modelos productivos o reportes regulatorios— y verificar si existe documentación explícita del esquema, el owner y el SLA de calidad. Si la respuesta es no para dos o más de esos cinco, la formalización de data contracts es la prioridad de gobernanza del trimestre, antes que cualquier inversión en catálogo o linaje. Un catálogo sin contracts es un inventario sin compromisos: describe lo que existe, pero no garantiza lo que se puede usar.

    La especificación abierta de data contracts impulsada por la comunidad está disponible en datacontract.com, con plantillas en YAML compatibles con las principales plataformas de datos; es el punto de partida más directo para equipos que quieren adoptar el estándar sin construir desde cero.

  • Gobernanza de datos deficiente pone en riesgo las inversiones en gemelos digitales

    Gobernanza de datos deficiente pone en riesgo las inversiones en gemelos digitales

    Un gemelo digital sin gobernanza de datos sólida no es un activo estratégico: es un modelo de simulación alimentado con basura. Expertos de la industria advierten que las organizaciones que invierten en digital twins sin madurar primero sus capacidades de gobierno del dato están comprando deuda técnica cara.

    La promesa de los gemelos digitales —réplicas virtuales de activos físicos, procesos o sistemas que permiten simulación, monitoreo y optimización en tiempo real— depende de una condición que pocas organizaciones discuten en las presentaciones de venta: la calidad, consistencia y trazabilidad de los datos que los alimentan. Sin esas tres propiedades garantizadas por un marco formal de gobernanza, el gemelo diverge del mundo real y sus predicciones dejan de ser útiles. En el peor caso, generan decisiones equivocadas con la ilusión de respaldo técnico.

    Por qué el gemelo digital amplifica los problemas de datos existentes

    Un gemelo digital no corrige datos defectuosos: los escala. Si los sensores de una planta industrial reportan lecturas inconsistentes, si los metadatos de los activos están incompletos, o si no existe un data steward —responsable formal del dato dentro de la organización— que valide las fuentes de ingesta, el modelo virtual incorpora esas fallas y las proyecta hacia adelante. Lo que parece un problema de IoT o de ingeniería es, en el fondo, un problema de ownership del dato mal definido.

    El marco DAMA-DMBOK identifica la calidad del dato y el linaje —data lineage, es decir, la trazabilidad completa del origen, transformación y destino de cada dato— como capabilities centrales de cualquier programa de gobernanza. Ambas son precondiciones, no complementos, para un gemelo digital operativo. Sin linaje verificable, es imposible auditar por qué el gemelo generó un determinado output ni corregirlo de manera reproducible.

    Cuándo aplica y cuándo NO la gobernanza como requisito previo

    La gobernanza de datos es condición necesaria cuando el gemelo digital opera sobre activos críticos —infraestructura energética, plantas de manufactura, redes de transporte, edificios hospitalarios— donde una simulación incorrecta puede derivar en decisiones de mantenimiento o inversión con consecuencias físicas o financieras significativas. También aplica cuando el gemelo integra fuentes heterogéneas: datos de sensores, ERP, sistemas SCADA y registros históricos que pertenecen a diferentes dominios con diferentes propietarios. En esos escenarios, la ausencia de un modelo de dominio de datos acordado y un catálogo actualizado hace que la integración sea, en la práctica, manual y frágil.

    La exigencia de gobernanza completa puede ser menos urgente en proyectos piloto acotados, con una única fuente de datos controlada y sin impacto en decisiones operativas críticas. Aun así, el EDM Council —a través de su marco DCAM (Data Management Capability Assessment Model)— recomienda establecer desde el piloto los roles de stewardship y los criterios de calidad, porque retrofitear gobernanza sobre un gemelo digital ya en producción es exponencialmente más costoso.

    Tres fallas de gobernanza que destruyen valor en implementaciones reales

    • Ownership difuso del dato de ingesta: cuando ningún equipo tiene responsabilidad formal sobre la calidad de los datos que entran al gemelo, los errores se descubren tarde y se escalan sin resolverse.
    • Ausencia de catálogo de datos: sin un inventario centralizado de qué datos alimentan el modelo, con qué frecuencia y desde qué sistemas, el mantenimiento del gemelo se convierte en arqueología técnica cada vez que hay un cambio en la infraestructura fuente.
    • Métricas de calidad ausentes o decorativas: definir umbrales de completitud, consistencia y latencia para cada fuente de ingesta, y monitorearlos activamente, es la diferencia entre un gemelo que se usa para tomar decisiones y uno que se usa para hacer presentaciones.

    El escenario en América Latina: inversión en gemelos digitales sin infraestructura de gobierno

    En la región, los sectores de minería, petróleo y gas, y manufactura automotriz han sido los primeros adoptantes de digital twins, con proyectos activos en Brasil, Chile, México y Colombia. Sin embargo, según conversaciones con practitioners de la industria, la mayoría de estas implementaciones se inician desde áreas de tecnología u operaciones sin involucrar a equipos de gobernanza de datos —cuando estos existen formalmente, lo que no siempre ocurre. El resultado habitual es un gemelo funcional en el corto plazo que se vuelve inmanejable cuando escala o cuando el proveedor tecnológico original no está disponible para hacer ajustes.

    En Brasil, la LGPD (Lei Geral de Proteção de Dados) agrega una capa adicional de complejidad: los gemelos digitales que integran datos de empleados, clientes o ciudadanos deben mapear el tratamiento de datos personales dentro del modelo, lo que exige linaje y clasificación desde el diseño. En Chile, con la Ley 21.719 de datos personales promulgada en 2024, el requisito de accountability obliga a documentar las decisiones automatizadas que se apoyen en sistemas de simulación cuando afecten a personas identificables.

    Lo que un CDO debe resolver antes de aprobar el presupuesto del gemelo digital

    Antes de que una organización comprometa inversión en una plataforma de digital twin, el Chief Data Officer o quien ejerza esa función debe responder cuatro preguntas operativas: ¿Están definidos los data stewards para cada dominio de datos que alimentará el modelo? ¿Existe un catálogo de datos con cobertura suficiente sobre esas fuentes? ¿Se han establecido y se monitorean SLAs de calidad del dato para esas fuentes? ¿El proveedor del gemelo soporta integración con la capa de linaje existente o requiere construir una paralela? Si alguna respuesta es negativa, el proyecto de gemelo digital debería esperar —o el presupuesto debería incluir la maduración previa de esas capacidades. Bob Seiner, autor de Non-Invasive Data Governance, señala consistentemente que la gobernanza más efectiva es la que formaliza lo que ya está ocurriendo informalmente: en el contexto de un digital twin, eso significa documentar y acordar desde el inicio quién es responsable de cada dato que entra al modelo.

    Para profundizar en los frameworks de referencia, el DAMA-DMBOK 2.0 y el DCAM del EDM Council están disponibles en sus sitios oficiales; ambos incluyen secciones específicas sobre calidad del dato y linaje aplicables directamente a arquitecturas de ingesta para gemelos digitales.