Qué es el linaje de datos y por qué lo exige el AI Act

Si alguien en tu organización pregunta de dónde viene un número en un informe ejecutivo y la respuesta tarda más de cinco minutos, tienes un problema de linaje. Si ese número alimenta un modelo de IA de alto riesgo y no puedes trazar su origen ante el regulador, tienes además un problema legal. El linaje de datos —la trazabilidad completa del recorrido de un dato desde su origen hasta su consumo— es una de las capacidades más ignoradas en la práctica y una de las más exigidas por el AI Act. Este artículo explica qué es, cómo funciona y cómo construirlo de forma sostenible.

Qué es el linaje de datos

El linaje de datos es la trazabilidad completa del recorrido de un dato: desde su origen en un sistema fuente —una base de datos transaccional, un archivo externo, una API, un sensor— hasta su punto de consumo final, que puede ser un dashboard, una API de negocio, un modelo de machine learning o un informe regulatorio. En ese recorrido, el dato pasa por múltiples transformaciones: se limpia, se agrega, se une con otros datos, se recalcula, se filtra. El linaje registra cada uno de esos pasos.

En términos prácticos, el linaje responde tres preguntas que en muchas organizaciones hoy no tienen respuesta inmediata:

  • ¿De dónde viene este dato? Qué sistema lo generó, cuándo y bajo qué condiciones.
  • ¿Qué le ha pasado por el camino? Qué transformaciones, filtros, agregaciones o enriquecimientos ha sufrido antes de llegar a su destino.
  • ¿Dónde se usa? Qué informes, modelos, APIs o decisiones dependen de este dato. Imprescindible para evaluar el impacto de un problema de calidad.

Tipos de linaje de datos: técnico, de negocio y operacional

No todos los linajes son iguales. Según el nivel de detalle y el contexto que capturan, se distinguen tres tipos que se complementan entre sí:

Linaje técnico

Registra el recorrido físico del dato a nivel de sistema: qué tabla alimenta a qué tabla, qué pipeline ejecuta qué transformación SQL, qué job de Airflow ejecuta qué tarea sobre qué dataset. Es el linaje que herramientas como dbt y OpenMetadata generan automáticamente a partir del código y los metadatos de las plataformas. Es necesario pero no suficiente: saber que la tabla fact_revenue viene de raw_transactions no explica qué regla de negocio se aplicó para calcularla.

Linaje de negocio

Añade el contexto de negocio al recorrido técnico: qué transformación de negocio representa cada paso, qué regla se aplicó, quién la definió y aprobó, y si el dato resultante está sujeto a alguna restricción regulatoria o de privacidad. Este es el linaje que los Data Stewards enriquecen manualmente sobre la base técnica automática. Es el que responde por qué el dato vale lo que vale, no solo cómo se calculó.

Linaje operacional

Registra las ejecuciones concretas: cuándo se ejecutó el pipeline, con qué datos de entrada, qué volumen procesó, si hubo errores y qué outputs generó. Es el linaje que permite reconstruir qué pasó exactamente en una ejecución concreta, imprescindible para investigar incidencias de calidad o responder ante el regulador sobre una decisión específica de un sistema de IA.

Por qué el AI Act convierte el linaje en una obligación

El AI Act no menciona explícitamente la palabra "linaje", pero sus artículos 10 y 12 lo presuponen de forma directa. Para los sistemas de IA de alto riesgo:

  • Artículo 10 — Gobernanza de datos: exige documentar los datasets de entrenamiento, validación y prueba: su origen, las transformaciones aplicadas, los criterios de selección y exclusión, y las métricas de representatividad. Sin linaje técnico y de negocio, esa documentación no es trazable: es un documento Word que alguien redactó una vez y que no refleja la realidad del dato.
  • Artículo 12 — Registro de eventos: exige que los sistemas de alto riesgo generen automáticamente logs suficientes para reconstruir las circunstancias de cualquier decisión relevante. Eso es linaje operacional aplicado al ciclo de vida del modelo: qué datos de entrada recibió, qué output produjo, en qué contexto y con qué nivel de confianza.

La consecuencia práctica es que una organización que despliega un sistema de IA de alto riesgo sin linaje documentado no puede cumplir el artículo 10 de forma sostenible. Puede generar un documento de cumplimiento puntual, pero ese documento quedará obsoleto en el momento en que el dataset o el pipeline cambie. Solo el linaje automatizado garantiza que la documentación se mantiene al día sin trabajo manual.

Para ver cómo encaja el linaje en el framework completo de gobernanza, consulta el artículo Cómo implementar un Data Governance Framework efectivo en la era del AI Act.

Cómo funciona el linaje de datos en la práctica

Linaje automático con dbt

dbt es hoy el estándar de facto para transformación de datos en stacks modernos con Snowflake, BigQuery o Databricks. Una de sus capacidades más valiosas para la gobernanza es el linaje automático: como dbt conoce las dependencias entre modelos —qué modelo SQL depende de qué otro— genera automáticamente un grafo de linaje que muestra el recorrido completo desde las tablas fuente (source) hasta los modelos finales (mart). Este grafo se publica en dbt Docs y se expone a herramientas de catálogo como OpenMetadata sin configuración adicional.

El linaje de dbt cubre el recorrido dentro de la capa de transformación. Para un linaje verdaderamente end-to-end, hay que conectarlo con el linaje de ingesta —qué sistema fuente alimenta las tablas raw— y con el linaje de consumo —qué dashboards o modelos de IA consumen los marts finales.

Linaje end-to-end con OpenMetadata

OpenMetadata conecta los linajes de las distintas capas del stack en un único grafo navegable. A través de sus conectores, importa el linaje técnico de dbt, el linaje de ingesta de Airflow o Fivetran, y el linaje de consumo de Power BI o Tableau. El resultado es una vista completa del recorrido del dato desde el sistema transaccional hasta el dashboard o el modelo de IA, con cada paso documentado y navegable desde la interfaz del catálogo.

Sobre ese grafo técnico, los Data Stewards pueden añadir el contexto de negocio: descripciones de las transformaciones, reglas aplicadas, propietarios de cada paso y clasificaciones de sensibilidad. El linaje de negocio se construye de forma incremental sobre la base técnica automatizada.

Linaje en Snowflake con Access History

Snowflake registra de forma nativa el historial de acceso y las dependencias entre objetos: qué consulta leyó qué tabla, qué vista materializada depende de qué tabla base, qué usuario ejecutó qué operación. Esta información, combinada con el linaje de dbt y los conectores de OpenMetadata o Purview, permite construir un linaje operacional completo sin infraestructura adicional. En entornos con múltiples aerolíneas compartiendo la misma plataforma de datos, este linaje operacional es además la evidencia técnica que respalda las revisiones de acceso y las auditorías de seguridad.

Herramientas para automatizar el linaje de datos

Herramienta Tipo de linaje Integración principal Nivel de automatización Coste
dbt + dbt Docs Técnico (transformación) Snowflake, BigQuery, Databricks, Redshift Alto — nativo en el código Gratuito
OpenMetadata Técnico end-to-end dbt, Airflow, Snowflake, Power BI, Tableau Alto — conectores automáticos Open source / SaaS de pago
Microsoft Purview Técnico + negocio Azure, Power BI, SQL Server, M365 Alto en ecosistema Microsoft Precio por uso (Azure)
Apache Atlas Técnico (Hadoop) Hive, Spark, Kafka, HBase Medio — requiere configuración Open source
Collibra Técnico + negocio Snowflake, dbt, Tableau, SAP Alto con conectores enterprise Alto (licencia enterprise)
Alation Técnico + negocio Snowflake, BigQuery, Looker, Tableau Alto — crawling automático Medio-alto

Para la mayoría de organizaciones con un stack moderno en cloud, la combinación dbt + OpenMetadata cubre el linaje end-to-end con coste mínimo y alta automatización. El salto a soluciones enterprise tiene sentido cuando la complejidad del entorno, los requisitos de workflow de negocio o las necesidades de compliance superan lo que las opciones open source pueden ofrecer.

Cómo implementar linaje de datos paso a paso

Paso 1: empieza por los dominios críticos, no por todo

El error más frecuente es intentar construir el linaje de todos los datos de la organización desde el primer día. El resultado es un proyecto que nunca termina. Empieza por los tres o cinco dominios que más impacto tienen en el negocio o en el cumplimiento regulatorio: los datos que alimentan sistemas de IA de alto riesgo, los que sustentan los informes de dirección o los que están sujetos a regulación específica (datos financieros, datos personales, datos operacionales críticos).

Paso 2: automatiza el linaje técnico antes de documentar el de negocio

Configura los conectores de tu herramienta de linaje con las plataformas de datos antes de escribir una sola descripción manual. El linaje técnico debe fluir automáticamente. Si el grafo técnico depende de trabajo manual, estará desactualizado desde el primer cambio en el código o en el esquema. Con dbt y OpenMetadata, esta configuración inicial puede completarse en menos de una semana en stacks estándar.

Paso 3: asigna Data Stewards para enriquecer el contexto de negocio

Sobre el grafo técnico automático, los Data Stewards añaden el contexto de negocio: qué transformación de negocio representa cada paso, qué regla se aplicó, quién la aprobó y si hay restricciones de uso. Esta fase es iterativa: no hace falta documentar todo de golpe. Empieza por los nodos más consultados —las tablas o modelos que más preguntas generan— y expande desde ahí.

Paso 4: vincula el linaje con el catálogo y el control de acceso

El linaje aislado tiene valor limitado. Su potencial completo se activa cuando está integrado con el catálogo de datos —donde el usuario puede ver el linaje de cualquier activo directamente desde su ficha— y con el control de acceso —donde el Data Owner puede ver qué datos de su dominio alimentan qué sistemas downstream antes de aprobar o denegar un acceso. Para ver cómo estructurar estas integraciones, consulta el artículo Qué es un catálogo de datos y para qué sirve realmente.

Paso 5: documenta las fichas de dataset de IA con el linaje como base

Para cada sistema de IA de alto riesgo, crea una ficha de dataset que use el linaje como columna vertebral: origen del dato, transformaciones aplicadas (con referencia al nodo del grafo de linaje), criterios de selección y exclusión, y propietario de cada capa. Esta ficha es la evidencia documental del artículo 10 del AI Act. Con el linaje automatizado como base, se mantiene actualizada sola cuando el pipeline cambia; sin él, es un documento estático que envejece desde el momento en que se crea.

Lo que he visto en entornos complejos

Linaje roto entre capas en un grupo multi-aerolínea

En un entorno con varias aerolíneas compartiendo plataforma de datos en Snowflake, el linaje técnico dentro de cada aerolínea estaba razonablemente bien documentado en dbt. El problema era el linaje cross-entidad: los datos que fluían de los sistemas de una aerolínea a los modelos compartidos del grupo no tenían trazabilidad documentada. Cuando el equipo de auditoría preguntaba de dónde venía un campo específico en el reporting consolidado, la investigación tardaba días.

La solución fue extender los conectores de OpenMetadata para cubrir el flujo cross-entidad —incluyendo los jobs de integración entre schemas de Snowflake— y designar un Data Steward corporativo por dominio responsable de mantener el contexto de negocio de los nodos de integración. El linaje consolidado redujo el tiempo de respuesta ante consultas de auditoría de días a minutos.

Linaje como base de las fichas de dataset para AI Act

En proyectos donde los datos de entrenamiento de modelos analíticos provenían de múltiples tablas de Snowflake procesadas por dbt, el linaje automático generado por dbt Docs y enriquecido en OpenMetadata proporcionó la base técnica para las fichas de dataset que el artículo 10 del AI Act requiere. En lugar de redactar un documento de cumplimiento desde cero, el equipo de gobernanza exportó el grafo de linaje del dataset de entrenamiento —con origen, transformaciones y propietarios— y lo completó con las métricas de calidad y representatividad que los Data Stewards habían documentado. El resultado fue una ficha actualizable automáticamente, no un PDF estático.

Impacto de la ausencia de linaje en incidencias de calidad

En entornos sin linaje documentado, una incidencia de calidad en un dato —un campo nulo que no debería serlo, un valor fuera de rango, una duplicidad inesperada— puede tardar horas o días en localizarse porque nadie sabe qué pipelines afecta ni qué sistemas downstream dependen del dato afectado. Con linaje end-to-end, la misma incidencia se localiza en minutos: el grafo muestra exactamente qué tablas y dashboards están usando el campo afectado, lo que permite priorizar la remediación y comunicar el impacto real a los Data Owners correspondientes.

Errores frecuentes en la implementación del linaje de datos

  • Linaje solo técnico, sin contexto de negocio. Saber que la tabla A alimenta a la tabla B no es suficiente para el AI Act ni para el negocio. El contexto de qué transformación de negocio representa ese paso es lo que convierte el linaje técnico en evidencia de cumplimiento real.
  • Linaje manual en spreadsheets. Documentar el linaje en Excel o en una wiki garantiza que estará desactualizado en semanas. El linaje sostenible es el que se genera automáticamente desde el código y los metadatos de las plataformas.
  • Cobertura parcial que da falsa seguridad. Tener linaje dentro de la capa de transformación pero no en la ingesta ni en el consumo da una imagen incompleta que puede ser más peligrosa que no tener ninguna: induce a pensar que la trazabilidad está resuelta cuando en realidad tiene huecos críticos.
  • Linaje desconectado del catálogo. Un grafo de linaje que solo existe en la herramienta de linaje y no es navegable desde el catálogo de datos es una capacidad que poca gente usa. La integración entre linaje y catálogo es lo que hace que el linaje sea accesible para el usuario de negocio, no solo para el equipo técnico.
  • No actualizar el linaje cuando cambia el pipeline. Si el proceso de actualización del código no incluye la actualización del linaje de negocio, el grafo técnico evolucionará solo pero el contexto de negocio quedará obsoleto. El mantenimiento del linaje de negocio debe ser parte del proceso de cambio, no una tarea separada que se hace "cuando hay tiempo".

Conclusión: el linaje de datos es la memoria del ecosistema de datos

Sin linaje de datos, la organización no sabe de dónde vienen sus números, no puede explicar por qué un modelo de IA tomó una decisión y no puede demostrar ante el regulador que sus datasets de entrenamiento son lo que dice que son. El linaje no es una funcionalidad avanzada para organizaciones con madurez excepcional: es la infraestructura básica de confianza en los datos.

Con el AI Act en aplicación plena, esa infraestructura pasa de ser una buena práctica a ser un requisito legal. Las organizaciones que ya tienen linaje automatizado tienen una ventaja significativa: el cumplimiento del artículo 10 es un subproducto de su operativa normal, no un proyecto adicional. Las que no lo tienen deben empezar ahora, por los dominios críticos y con la herramienta que mejor encaje en su stack actual.

Checklist: linaje de datos operativo

  • Dominios críticos identificados y priorizados para la implementación inicial del linaje.
  • Conectores de linaje técnico configurados con las plataformas de datos (dbt, Snowflake, Airflow, Power BI).
  • Grafo de linaje end-to-end visible: ingesta → transformación → consumo.
  • Linaje cross-entidad documentado en entornos con múltiples sistemas fuente o filiales.
  • Data Stewards asignados para el enriquecimiento del linaje de negocio por dominio.
  • Contexto de negocio documentado en los nodos críticos: qué transformación representa, qué regla se aplicó y quién la aprobó.
  • Linaje integrado y navegable desde el catálogo de datos.
  • Fichas de dataset de IA construidas sobre el grafo de linaje (art. 10 AI Act).
  • Linaje operacional (logging de ejecuciones) activo para sistemas de alto riesgo (art. 12 AI Act).
  • Proceso de actualización del linaje de negocio integrado en el ciclo de cambios de pipelines.
  • Dashboard de cobertura de linaje: porcentaje de activos con linaje documentado por dominio.

Preguntas frecuentes sobre linaje de datos

¿Qué es el linaje de datos?

El linaje de datos es la trazabilidad completa del recorrido de un dato desde su origen en un sistema fuente hasta su punto de consumo final, pasando por todas las transformaciones intermedias. Responde a tres preguntas: ¿de dónde viene este dato?, ¿qué le ha pasado por el camino? y ¿dónde se usa? Es la infraestructura de confianza que permite entender, auditar y defender cualquier dato de la organización.

¿Qué diferencia hay entre linaje técnico y linaje de negocio?

El linaje técnico registra el recorrido físico del dato: qué tabla alimenta a qué tabla, qué pipeline ejecuta qué transformación. El linaje de negocio añade el contexto: qué transformación de negocio representa ese paso, qué regla se aplicó, quién la aprobó y si el dato resultante está sujeto a restricciones. Ambas capas son necesarias; el linaje técnico sin contexto de negocio no es suficiente para cumplir el artículo 10 del AI Act.

¿Por qué el AI Act exige linaje de datos?

El artículo 10 obliga a documentar los datasets de entrenamiento de sistemas de IA de alto riesgo con trazabilidad de origen y transformaciones. El artículo 12 exige logging de eventos durante el ciclo de vida del sistema. Ambos requisitos presuponen una infraestructura de trazabilidad que solo el linaje automatizado puede mantener actualizada de forma sostenible. Sin linaje, la documentación de cumplimiento es un documento estático que envejece desde el momento en que se crea.

¿Qué herramientas automatizan el linaje de datos?

Las principales son: dbt para el linaje dentro de la capa de transformación, OpenMetadata para el linaje end-to-end con conectores a múltiples plataformas, Microsoft Purview para ecosistemas Azure, Apache Atlas para entornos Hadoop legacy, y Collibra o Alation para soluciones enterprise con linaje de negocio integrado. La combinación dbt más OpenMetadata cubre el 80% de los casos de uso en stacks modernos en cloud con coste mínimo.

¿Cuánto cuesta implementar linaje de datos?

En stacks con dbt y Snowflake, el linaje técnico básico puede automatizarse en menos de una semana con dbt Docs sin coste de licencia. Un linaje end-to-end con OpenMetadata self-hosted añade entre dos y cuatro semanas de configuración. Las soluciones enterprise como Collibra o Purview tienen costes de licencia significativos pero reducen el tiempo de implementación con soporte incluido. El coste real no es la herramienta: es el tiempo de los Data Stewards para enriquecer el linaje de negocio.