Chat with your Enterprise Data

Hola, me llamo Simon

Me alegra mucho estar aquí hoy. Os hablo desde Alemania, así que para mí es casi media tarde. De formación soy ingeniero de software. Trabajé mucho con Java, soy coautor de «Java by Comparison», un libro sobre cómo escribir código mantenible, y pasé tres años en un equipo de remote mob programming: cuatro o cinco personas en una llamada de Zoom todo el día, una sola pantalla compartida, cambiando de driver cada diez minutos y trabajando siempre juntos en una única cosa. También hice mucho trabajo de infraestructura con Kubernetes y el enfoque GitOps.

Y entonces pasó algo que nunca me habría esperado: me cambié de bando. Me pasé al lado oscuro, el mundo de los datos. Hace unos cinco años. Sinceramente, por aquel entonces ya no me quedaba mucha innovación en el mundo de la ingeniería de software; el mundo de los datos, en cambio, estaba explotando de innovación, impulsado por el auge del Data Mesh, el concepto que acuñó Zhamak Dehghani. Con mi coautor construimos datamesh-architecture.com como referencia y juntos tradujimos al alemán el libro Data Mesh de O’Reilly. Lo bonito es que la versión alemana está impresa en color. Peleamos por ello. En Estados Unidos sois un poco más tacaños con la impresión en color, la verdad.

Por mi doctorado en sistemas distribuidos nunca me fui del todo del mundo académico, y sigo publicando investigación con gente de King’s College London y de la HTW Berlin. Formo parte del Technical Steering Committee del proyecto BITOL de la Linux Foundation, que impulsa estándares abiertos alrededor de los Data Contracts y los productos de datos. Hace un tiempo tuvisteis aquí en Purdue una charla de Sean Perin, el presidente del TSC. Además, comantengo herramientas open source basadas en esos estándares. Y por último soy cofundador de Entropy Data, un marketplace de datos SaaS. Somos una startup pequeña: ya rentable, sin capital riesgo, bootstrapped y creciendo rápido. Esa es mi historia.

El white paper

Hoy quiero hablar de conversar con los datos de tu empresa. Hemos publicado un white paper en arXiv, arxiv.org/pdf/2601.08687, junto con gente de King’s College London y de la Jheronimus Academy of Data Science (JADS), en los Países Bajos. Ahí encontrarás mucho más detalle; todo lo que enseño aquí está también enlazado desde entropy-data.com/es/investigacion.

El objetivo, en una frase

La idea central es sencilla: queremos permitir que la IA responda cualquier pregunta de negocio aplicando las políticas de Data Governance.

Piensa en lo que eso significa. Le das una pregunta a la IA, o un agente de IA se la plantea por su cuenta, y al cabo de un rato simplemente tienes la respuesta. Con la gobernanza aplicada, porque los datos pueden ser muy sensibles: no está permitido hacer cualquier cosa con cualquier conjunto de datos. De eso quiero hablaros hoy.

Demo en vivo: de la pregunta a la respuesta

Déjame animar un poco esto con una demo. Por detrás tenemos un sistema que lo gestiona todo: un marketplace de productos de datos. Uso Claude, conectado al sistema mediante un conector MCP. Si todo está configurado, basta con hacer una pregunta de negocio. Vamos a probar: «¿Quiénes son nuestros mejores clientes?»

Claude lo toma como disparador y busca automáticamente datos relevantes. Ejecuta una búsqueda de «customers» y encuentra un producto de datos. Esos son metadatos de muy alto nivel. Así que a continuación hace un fetch para obtener el detalle completo: estructura, semántica, calidad y si tenemos acceso. Lo lee todo, decide que el producto de datos encaja bien, pero se da cuenta de que no tenemos acceso. Así que solicita acceso automáticamente, extrayendo un propósito concreto de mi pregunta.

Recibe un «enviado para aprobación, todavía sin aprobar». La IA es un poco descarada: aun así intenta ejecutar una consulta SQL, con un propósito adjunto para que sepamos por qué se lanza cada consulta, pero la solicitud está pendiente y la consulta falla. En otra pantalla apruebo la solicitud de acceso como owner. Claude lo intenta de nuevo, espera unos segundos a que el clúster serverless de Databricks se caliente y entonces llegan los resultados.

De «¿Quiénes son nuestros mejores clientes?» a una respuesta gobernada. Cada paso trazado. Cada consulta lleva un «por qué». Eso es conversar con los datos de tu empresa.

«Hoy este flujo lo dispara una persona, yo, pero igual de bien lo podría disparar un agente autónomo. No hay ninguna diferencia. Y vienen muchos de esos agentes.»

Un segundo ejemplo: «¿Cuáles son los principales motivos de los tickets de soporte?» El mismo flujo, pero los tickets de soporte son menos sensibles, así que el acceso se aprueba de forma automática. Buscar, recuperar, solicitar, consultar, responder: cero interacción humana en el proceso.

Y un último ejemplo: «Exporta un CSV con las direcciones de email de clientes para una campaña de email de lujo, solo clientes de alta fidelidad». Esta vez entra en juego la gobernanza. Las condiciones de uso del producto de datos prohíben el uso para marketing. La IA se niega. Con un modelo más antiguo a veces conseguía convencerla de saltárselo, así que añadimos un segundo guardián en el propio servidor MCP. Aunque convenzas a la IA, el servidor detiene la consulta al vuelo. Los límites de gobernanza se extienden a los agentes, y eso importa, porque un agente puede pedir acceso para un propósito e intentar luego usar los datos para otro. Eso no está permitido.

Repasamos los casos de uso

Volvamos a las diapositivas. ¿Qué hemos visto? Acceso gobernado y auditado a los datos a través de la IA.

• Encontramos el producto de datos adecuado para una pregunta de negocio.
• Solicitamos acceso con un propósito concreto.
• Consultamos los datos de la forma correcta.
• Auditamos el porqué de cada consulta SQL.
• Bloqueamos las consultas SQL cuyo propósito no está cubierto por la gobernanza.

Y todo ello de forma automática. Esa última palabra es la que importa: cuando lleguen los agentes, si no tienes esto automatizado no vas a poder seguir el ritmo.

La foto completa

La arquitectura es sencilla. El mundo agéntico arriba (ChatGPT, Claude, Copilot). Los datos reales abajo (Postgres, Databricks, Snowflake). Y en el medio un servidor MCP que actúa como una capa fina de gobernanza con tres responsabilidades:

• Descubrimiento: encontrar y evaluar productos de datos.
• Gobernanza: solicitar acceso, comprobar las condiciones de uso del Data Contract y aplicar las políticas globales.
• Consulta: ejecutar SQL con barreras de seguridad delante.

Técnicamente, construir esto hoy no es difícil: Claude Code te escribe casi todo. La pregunta interesante es por qué funciona tan bien.

Dos razones por las que funciona

La primera razón es la obvia: los agentes de IA son cada vez mejores. Has visto la magia: Claude planificó sus pasos por detrás, los ejecutó en orden, se recuperó de los errores y yo no tuve que pedirle nada de eso.

Pero la respuesta de verdad son unos buenos metadatos. Sin ellos, mi demo habría sido malísima. Déjame repasar los factores de éxito, los tipos de metadatos que hacen que esto funcione de verdad.

Factor de éxito n.º 1: productos de datos

El marketplace que había por detrás ofrecía los datos en forma de productos de datos. La idea: no vuelcas todas las tablas de tu empresa en el marketplace, solo los datos que alguien posee y quiere compartir como producto.

Eso consigue dos cosas. Reduce el contexto, y cuanto más pequeño es el contexto, mejor para la IA. Y eleva la calidad y la propiedad: con mentalidad de producto construyes para un consumidor, sea humano o agente. Como formato usamos el estándar abierto Open Data Product Standard (ODPS) v1.0.0, que da a los metadatos una estructura predecible.

Factor de éxito n.º 2: Data Contracts

Un Data Contract define la propiedad, la estructura, la semántica, la calidad y las condiciones de uso de los datos que fluyen entre un productor y sus consumidores. Piensa en una especificación OpenAPI, pero para datos. Lo puede leer una persona, es perfecto para las herramientas y es ideal para la IA: son los mejores metadatos que puedes asociar a un conjunto de datos, porque se pueden tomar como fuente de verdad.

En datacontract.com puedes ver cómo queda esto en la práctica. Un contrato suele ser un fichero YAML con los datos fundamentales (id, nombre, versión, estado), un esquema (tablas, columnas, tipos lógicos y físicos, clasificaciones como PII), calidad de datos (por ejemplo order_status ∈ {pending, shipped, cancelled}, o SQL arbitrario, a veces absoluto y a veces en porcentaje, porque el mundo de los datos es caótico), propiedad y canales de Slack, condiciones de uso (qué puedes y qué no puedes hacer, por ejemplo nada de marketing), SLAs (retención, frescura, nunca con más de 24 horas de antigüedad) y, al final, el servidor (Postgres, Databricks, Snowflake, S3, Iceberg… allá donde vivan los datos de verdad).

El estándar aquí es ODCS v3.1.0. El editor open source te permite escribir contratos con un formulario, con un diagrama o en YAML puro. La Data Contract CLI, con unas 800 estrellas en GitHub, lee un contrato, se conecta a la fuente de datos real y verifica que se cumplen todas las garantías. Esa verificación automática es lo que hace que el contrato sea lo bastante fiable como para alimentar la fase de descubrimiento de la IA.

Factor de éxito n.º 3: semántica

Para hacer joins entre tablas, la IA tiene que saber si dos columnas se pueden unir, si order_id en una tabla significa realmente lo mismo que order_id en otra. Sobre todo cuando los joins encadenan varios productos de datos.

Para eso definimos la semántica: un glosario de negocio o grafo de conocimiento. Order ID se define una sola vez en el dominio de ventas, y los Data Contracts apuntan a esa definición compartida. El mismo concepto, el mismo puntero, la misma verdad en todas partes. Con la semántica en su sitio, la IA escribe los joins de SQL correctos sin tener que adivinar.

Factor de éxito n.º 4: acuerdos de acceso

En la demo, la IA solicitó el acceso por mí. Por debajo rellenó un formulario, pero lo importante es que en el backend siempre sabemos:

• Quién tiene acceso a qué datos y por qué.
• Cuáles son los términos y condiciones de ese acceso: qué está permitido y qué no.

Eso es lo que hace reales las comprobaciones de gobernanza, y lo que nos permite construir un sistema así.

Por fin, un motivo para tener mejores metadatos

Antes de la IA le habría dado la razón al abogado del diablo. Conseguir que alguien invirtiera tiempo en metadatos era muy difícil: la gente de gobernanza aparecía pidiéndolos y la petición se quedaba para siempre al fondo del backlog. Ahora hay un bucle de retroalimentación que antes no existía:

Conversa con los datos de tu empresa → evalúa los resultados → si no son los que querías, mejora los metadatos → vuelve a preguntar → mejores resultados.

«La gente es egoísta: no va a invertir tiempo en ayudar a otros ni en cumplir una política por cumplirla. Pero cuando el beneficio es suyo, mejora los metadatos.»

Esa es la diferencia. Todo el que ve esta demo dice: «Esto es justo lo que quiero». Y la única forma de conseguirlo son mejores metadatos. Así que van a invertir.

Sí, la IA está de nuestro lado

Tres sitios en los que la IA ya ayuda hoy con los metadatos:

• Creación de metadatos: escribir y actualizar contratos y definiciones de producto.
• Monitorización de metadatos: comprobar si los metadatos cumplen tus políticas.
• Aprobación de accesos: el único paso que en la demo seguía siendo manual.

Creación de metadatos

Ya no hace falta teclear los metadatos a mano. Pídele a la IA que actualice un Data Contract, que lo promocione de borrador a activo o que rellene las clasificaciones que faltan. Dale contexto extra, tu Confluence, los datos reales, otro sistema de registro, y producirá metadatos mucho mejores que si solo tuviera el YAML.

Monitorización de metadatos

No quieres que tus metadatos se deterioren, porque en cuanto lo hacen, tus resultados de IA se deterioran también. Así que los monitorizas contra unas reglas: ¿qué es un buen producto de datos? ¿qué es un buen Data Contract? ¿qué estamos permitiendo?

La clave es que ahora esas reglas se pueden expresar en lenguaje natural. La IA de gobernanza toma un producto de datos más una política y devuelve un resultado de comprobación. La entrada son las políticas y los productos de datos, el modelo es un LLM y la salida es un conjunto de comprobaciones con feedback que los usuarios pueden marcar. Hemos construido un prototipo y funciona bien.

La gran ventaja: ahora quien no es experto puede definir qué significa «bueno». La gente de gobernanza sin formación en programación puede escribir reglas, monitorizar el sistema e iterar. Eso sí, las alucinaciones siguen siendo un problema: los usuarios pueden marcar los falsos positivos, pero todavía no hay una gran respuesta para los falsos negativos. Un compromiso honesto y un patrón muy potente.

Aprobación de accesos

¿Te acuerdas del único paso manual de la demo, cuando tuve que entrar en el sistema y pulsar aprobar? ¿Por qué no puede ayudarnos la IA al menos con eso? Así que también lo construimos: la Data Governance AI comprueba la solicitud de acceso contra las políticas y o bien la deja pasar, o bien señala infracciones concretas («Tratamiento de PII: la solicitud de acceso no indica un propósito claro para datos PII»), dejando que el owner apruebe o rechace con contexto.

Revisado por pares: la IA supera a los humanos aprobando accesos

No nos limitamos a construirlo, también lo evaluamos. Junto con la HTW Berlin y King’s College London, y con dos expertos en gobernanza (Head of Data Governance en e-commerce y en seguros), hicimos un estudio que fue aceptado en AIES 2025.

Los números principales:

• La IA de gobernanza emitió 3,6× más avisos que los expertos humanos, y detectó todos sus mismos problemas de cumplimiento.
• El 80 % de los avisos generados por la IA se consideró correcto tras una segunda revisión.
• Los casos de prueba sintéticos generados por el LLM simularon con eficacia escenarios reales de gobernanza.
• La supervisión humana sigue siendo necesaria para la precisión contextual y legal.

En la práctica: la IA acertó más que las personas, porque las personas no pueden tener todas las reglas en la cabeza y la IA sí. El paper completo está en entropy-data.com/es/investigacion.

En resumen

Hemos visto acceso gobernado y auditado a los datos a través de la IA: encontrar los datos adecuados para una pregunta, solicitar acceso con un propósito, consultar, auditar el porqué y bloquear las consultas que no encajan con las condiciones, todo automático. Esta es la capacidad hacia la que todo el mundo tiene que avanzar. MCP es el protocolo adecuado para la capa de gobernanza.

Prepárate

Olvídate de todo lo demás si quieres, pero quédate con esto: los agentes están llegando, y solo puedes estar listo con buenos metadatos y gobernanza automatizada.

Ponte a ello.