Curso avanzado sobre el linaje de los datos: guías prácticas, puntuación de cobertura y retorno de la inversión

Esta guía está dirigida a ingenieros de datos, responsables de gobernanza y directores de datos (CDO) que ya han superado la fase de «deberíamos implementar el linaje de datos» y necesitan saber cómo llevarlo a la práctica en un entorno moderno, cómo evaluar si está funcionando y cómo demostrar su valor a la organización.

Abarca: cómo evaluar tu cobertura actual de linaje e identificar las lagunas, guías de implementación específicas para cada pila tecnológica, cómo calcular el retorno de la inversión (ROI), fallos habituales en el linaje y cómo evitarlos, y cómo ampliar el linaje a los sistemas de IA.

Tipos de linaje de datos: una comparación

Antes de implementar el linaje, define qué tipos necesita tu organización. Los distintos tipos tienen fines diferentes y requieren enfoques técnicos distintos.

A qué tipos dar prioridad:

Empieza por el linaje técnico y el linaje a nivel de conjunto de datos para todos los flujos de trabajo; esto establece el gráfico de dependencias que hace posible el análisis de impacto. Añade el linaje a nivel de columna para cada flujo de trabajo que gestione datos regulados, información de identificación personal (PII) o métricas críticas para el negocio. Añade el linaje empresarial para que el gráfico técnico resulte interpretable para los analistas y los responsables de datos. Añade el linaje temporal y el de IA/ML a medida que el programa madure o cuando así lo exijan requisitos normativos específicos.

Evaluación de tu cobertura actual de linaje

Antes de invertir en mejoras del linaje, establece una referencia realista de tu situación actual. El marco de puntuación de brechas que se muestra a continuación ofrece una cifra única (de 0 a 100) que refleja el grado de madurez actual de tu linaje e identifica las mejoras con mayor impacto.

Las cuatro dimensiones

Cobertura (ponderación del 40 %): El porcentaje de tablas y columnas de su conjunto de datos que cuentan con documentación automatizada del linaje. Esta es la dimensión más importante, ya que un programa de linaje que solo cubra el 30 % de los activos deja sin gestionar el 70 % restante del conjunto de datos.

Medida: recuento de tablas con linaje / recuento total de tablas en el catálogo. Repetir el proceso para las columnas si se requiere cobertura a nivel de columna.

Actualidad (20 % del peso): El porcentaje de registros de linaje actualizados en los últimos 90 días. Un linaje que era preciso hace seis meses puede que ya no refleje las configuraciones actuales de los procesos. Un linaje obsoleto es, en cierto modo, peor que no tener linaje alguno, ya que genera una confianza errónea.

Métrica: número de registros de linaje cuyo campo «last_updated» tenga una fecha de hasta 90 días / número total de registros de linaje.

Profundidad (ponderación del 20 %): El porcentaje de registros de linaje que se rastrean a nivel de columna, en lugar de solo a nivel de conjunto de datos. El linaje a nivel de columna es considerablemente más costoso de implementar, pero mucho más valioso para el análisis de impacto y el cumplimiento normativo.

Medida: recuento de activos con linaje a nivel de columna / total de activos con cualquier tipo de linaje.

Validación (ponderación del 20 %): El porcentaje de entradas de linaje que cuentan con pruebas de conciliación automatizadas que confirman que el linaje es correcto. El linaje sin pruebas es documentación. El linaje con pruebas es documentación verificada.

Métrica: número de entradas de linaje que superan las pruebas automatizadas / número total de entradas de linaje.

Fórmula de la puntuación de diferencia

Puntuación = (% de cobertura × 0,40) + (% de actualidad × 0,20) + (% de profundidad × 0,20) + (% de validación × 0,20)

Ejemplo de cálculo:

• Cobertura: 60 % → 60 × 0,40 = 24
• Frescura: 80 % → 80 × 0,20 = 16
• Profundidad: 30 % → 30 × 0,20 = 6
• Validación: 50 % → 50 × 0,20 = 10
• Puntuación de la diferencia: 24 + 16 + 6 + 10 = 56

Niveles de madurez

Lo que te indica la puntuación

Una puntuación inferior a 45 indica que la prioridad es la infraestructura básica de la cadena de suministro: las mejoras en la cobertura y la frescura serán las que ofrezcan un mayor retorno de la inversión.

Una puntuación entre 45 y 65 indica que la profundidad a nivel de columna es la prioridad: el gráfico a nivel de conjunto de datos ya existe, y añadir cobertura a nivel de columna para los activos de alto valor es la siguiente mejora con mayor impacto.

Una puntuación superior a 65 significa que la validación y el linaje temporal son la prioridad: el programa básico de linaje está funcionando, y las próximas mejoras se centrarán en verificar su precisión y ampliarlo para abarcar casos extremos y sistemas de inteligencia artificial.

Guías de implementación de Stack

Guía práctica 1: Snowflake y dbt

Arquitectura: Los datos se importan a la capa de datos sin procesar de Snowflake. dbt transforma los datos sin procesar, a través de modelos de preparación e intermedios, en tablas de mart que utilizan las herramientas de BI.

Enfoque de captura de linaje: dbt genera un archivo manifest.json en tiempo de compilación que contiene el grafo completo de dependencias de cada modelo: qué modelos dependen de qué otros modelos y qué columnas de cada modelo se derivan de qué columnas de los modelos anteriores. En combinación con el historial de consultas de Snowflake, esto proporciona un linaje a nivel de columna a lo largo de toda la cadena de transformación.

Pasos para la implementación:

1. Analiza el archivo manifest.json tras cada ejecución de dbt para extraer las dependencias de los modelos y el linaje a nivel de columna.
2. Combínalo con el historial de consultas de Snowflake para registrar el linaje de las consultas que se ejecutan fuera de dbt.
3. Asigna los nombres de los modelos dbt a los nombres de las tablas de Snowflake utilizando el esquema de destino y la configuración de la base de datos.
4. Guarda el gráfico de linaje resultante en tu catálogo de metadatos, indexado por los nombres completos de las tablas y columnas de Snowflake.
5. Configura el catálogo para que vuelva a importar el archivo manifest.json cada vez que se ejecute dbt, de modo que el historial se mantenga actualizado.

Enfoque de pruebas: Escribir pruebas de conciliación que verifiquen que el recuento de filas y la distribución de los campos clave coincidan entre las tablas de origen y de destino para cada modelo de dbt. Las pruebas fallidas indican una ruptura en el linaje o un problema de calidad de los datos en la transformación.

Problemas habituales: Los metadatos de los alias de columnas de dbt no siempre se generan de forma predeterminada. Configura dbt para que capture los metadatos a nivel de columna y los incluya en el manifiesto. Sin esto, el linaje de las columnas se deduce del análisis sintáctico del SQL en lugar de declararse explícitamente, lo que reduce la precisión en transformaciones complejas.

Guía práctica 2: Databricks, Delta Lake y Unity Catalog

Arquitectura: Ingesta de datos en tiempo real y por lotes en Delta Lake. Los trabajos de Spark transforman los datos a través de las capas Bronze, Silver y Gold. Unity Catalog gestiona los metadatos y el acceso.

Enfoque de captura de linaje: Unity Catalog proporciona un seguimiento nativo a nivel de columna para las operaciones de Spark SQL y las escrituras en Delta Lake. Captura automáticamente el seguimiento de las operaciones ejecutadas a través del almacén SQL de Databricks y los cuadernos de Spark. Para las operaciones de Spark basadas en Python, el seguimiento debe capturarse mediante instrumentación explícita o un cliente de metadatos compatible con el seguimiento.

Pasos para la implementación:

1. Activa la captura del historial de Unity Catalog en la configuración del espacio de trabajo de Databricks.
2. Asegúrate de utilizar operaciones de Spark SQL siempre que sea posible, en lugar de llamadas a la API de DataFrame de Python: Unity Catalog captura automáticamente el linaje basado en SQL, pero requiere una instrumentación explícita para las operaciones de Python.
3. En el caso de los trabajos de Python Spark, añade la instrumentación de linaje a nivel de trabajo: registra las tablas de origen, las tablas de destino y el tipo de transformación (unión, agregación, filtro) en un almacén de metadatos de linaje.
4. Conecta tu catálogo de metadatos a la API de linaje de Unity Catalog para obtener registros de linaje de forma programada o mediante un desencadenante basado en eventos.
5. En el caso de los flujos de streaming, se debe registrar el historial a nivel de micro-lote, incluyendo el tema o flujo de origen, la lógica de transformación y la tabla Delta de destino.

Enfoque de pruebas: Utilizar la capacidad de «viaje en el tiempo» de Delta Lake para validar el linaje comparando los datos actuales con una versión histórica que se sabe que es correcta. Las pruebas de detección de desviaciones en el esquema verifican que los cambios en el esquema de las etapas anteriores se hayan propagado correctamente a través de las capas de transformación.

Problemas habituales: La cobertura del linaje de Unity Catalog es completa para las operaciones basadas en SQL, pero requiere trabajo adicional para los trabajos de Python Spark que utilizan la API de DataFrame. Las organizaciones con grandes cargas de trabajo en Python deberían planificar la implementación explícita de la instrumentación del linaje en esos flujos de trabajo.

Guía práctica 3: Apache Airflow y un almacén de datos en la nube

Arquitectura: Airflow coordina los trabajos ETL y ELT en un almacén de datos en la nube (BigQuery, Redshift o Snowflake). Las tareas individuales ejecutan transformaciones SQL, llamadas a API y cargas de archivos.

Enfoque de captura de linaje: La base de datos de metadatos de Airflow contiene el historial de ejecución de cada DAG y cada tarea. Las herramientas de linaje pueden extraer el linaje a nivel de tarea analizando los registros de ejecución de tareas de Airflow: qué DAG se ejecutaron, qué tareas se ejecutaron, qué entradas leyeron y qué salidas generaron. Las tareas basadas en SQL proporcionan linaje a nivel de columna mediante el análisis de SQL. Las tareas no SQL requieren una instrumentación explícita del linaje.

Pasos para la implementación:

1. Conecta una herramienta de seguimiento de linajes a la base de datos de metadatos de Airflow para extraer los registros de ejecución de DAG y tareas.
2. En el caso de las tareas SQL, analiza el código SQL ejecutado en cada tarea para extraer las tablas de origen, las tablas de destino y la lógica de transformación a nivel de columna.
3. Para las tareas que no sean de SQL (operadores de Python, llamadas a API, cargas de archivos), añade anotaciones de linaje explícitas a cada tarea utilizando las funciones de linaje de Airflow o un cliente de metadatos personalizado.
4. Asigna los resultados de las tareas de Airflow a las tablas correspondientes de Warehouse utilizando las configuraciones de conexión definidas en el almacén de conexiones de Airflow.
5. Almacena los registros de historial en tu catálogo de metadatos junto con el ID de la tarea, el ID del DAG, la marca de tiempo de ejecución, los activos de origen y los activos de destino.

Enfoque de pruebas: Escribir sensores de Airflow que comprueben la actualidad de las tablas posteriores y el recuento de filas tras cada ejecución del DAG. Las alertas que se activan cuando los datos esperados no llegan dentro del plazo establecido en el SLA desencadenan una investigación del linaje.

Problemas habituales: La calidad de la documentación del linaje de Airflow depende directamente de la calidad del código SQL y de las anotaciones de cada tarea. Las tareas que ejecutan SQL dinámico (SQL generado en tiempo de ejecución a partir de variables) requieren un tratamiento especial para extraer un linaje preciso; el análisis estático del SQL dinámico produce resultados incompletos o incorrectos.

Guía práctica 4: Kafka y los flujos de datos en tiempo real

Arquitectura:Los eventosse transmiten desde los sistemas de origen a través de temas de Kafka. Los consumidores procesan los eventos y escriben los resultados en bases de datos, almacenes de datos o temas de Kafka posteriores.

Enfoque de captura del linaje:El linaje de los flujos de datosse captura a nivel de los consumidores: cada consumidor declara sus temas de entrada, las transformaciones que aplica y sus destinos de salida. El Registro de esquemas realiza un seguimiento de las versiones de los esquemas para cada tema, lo que proporciona el componente temporal del linaje. Las herramientas de linaje se conectan al Registro de esquemas y a las configuraciones de los consumidores para construir el gráfico de linaje de los flujos de datos.

Pasos para la implementación:

1. Registra cada tema de Kafka en el Registro de esquemas con un esquema definido. El Registro de esquemas proporciona el historial de esquemas que permite el linaje temporal.
2. Configura cada aplicación de consumo para que genere metadatos de linaje al iniciarse y al procesar un lote: tema de entrada, versión del esquema utilizada, transformación aplicada, tema de salida o tabla de destino.
3. Conecta tu catálogo de metadatos al Registro de esquemas para registrar la evolución de los esquemas a lo largo del tiempo.
4. Para los consumidores que escriben en un almacén o en una base de datos, amplía el gráfico de linaje desde el tema de Kafka, pasando por el consumidor, hasta la tabla de destino, utilizando el mismo enfoque de linaje a nivel de columna que en los guiones de procesamiento por lotes anteriores.
5. Configurar la supervisión de la actualidad del linaje: el linaje en tiempo real debería actualizarse a los pocos minutos de que se produzcan cambios en el proceso, no a diario.

Enfoque de pruebas: La supervisión de la cola de mensajes no entregados detecta infracciones del esquema y fallos en la transformación. La supervisión del retraso de los consumidores detecta cuándo estos se quedan rezagados, lo que indica problemas en el estado del canal de datos que pueden afectar a la precisión del linaje.

Problemas habituales: El linaje de streaming es más complejo que el de procesamiento por lotes, ya que los esquemas de eventos evolucionan continuamente y los consumidores pueden estar ejecutando varias versiones a la vez. El Registro de esquemas es una infraestructura esencial: sin él, resulta prácticamente imposible mantener con precisión el linaje de streaming.

Guía práctica n.º 5: Pipelines de aprendizaje automático basados en Python

Arquitectura: Los scripts o marcos de trabajo de Python (scikit-learn, PyTorch, TensorFlow, MLflow) cargan conjuntos de datos, procesan características, entrenan modelos y registran los artefactos de los modelos.

Enfoque de captura del historial: El linaje de ML requiere registrar cuatro elementos: las versiones de los conjuntos de datos utilizados para el entrenamiento, las transformaciones de ingeniería de características aplicadas, los parámetros de entrenamiento del modelo y los resultados de la evaluación, así como la versión del artefacto del modelo registrada para su implementación. MLflow ofrece un seguimiento nativo de los experimentos en lo que respecta a parámetros, métricas y artefactos. El linaje del conjunto de datos se conecta con los flujos de datos previos que generaron los datos de entrenamiento.

Pasos para la implementación:

1. Utiliza MLflow (o un equivalente) para realizar un seguimiento de cada ejecución de entrenamiento: registra la versión del conjunto de datos de entrenamiento, la versión del conjunto de datos de validación, la configuración de la ingeniería de características, los hiperparámetros, las métricas de evaluación y el artefacto del modelo.
2. Vincula las referencias de los conjuntos de datos de entrenamiento al catálogo de datos, de modo que el linaje ascendente del conjunto de datos —desde el sistema de origen, pasando por todas las transformaciones, hasta la división para el entrenamiento— sea trazable desde el artefacto del modelo.
3. Para la ingeniería de características, registra las columnas de entrada, la lógica de transformación y los nombres de las características de salida de cada característica del conjunto de datos de entrenamiento.
4. Registra los artefactos del modelo en un registro de modelos (MLflow Model Registry, Databricks Model Registry o equivalente) indicando la ejecución de entrenamiento que los generó.
5. Conecta el registro de modelos a tu catálogo de datos para que cada versión del modelo cuente con una cadena de linaje visible que abarque desde los datos de origen, pasando por las características, hasta el artefacto del modelo.

Enfoque de pruebas:Las pruebas de validación de datosse ejecutan sobre los conjuntos de datos de entrenamiento antes de que comience el entrenamiento, con el fin de confirmar que los datos cumplen los umbrales de calidad definidos. Las pruebas de evaluación posteriores al entrenamiento confirman que los indicadores de rendimiento del modelo se encuentran dentro de los rangos aceptables antes de que el modelo se registre para su implementación.

Problemas habituales: Los cuadernos de Python utilizados para el desarrollo ad hoc de modelos a menudo no generan metadatos de linaje. Establece una política según la cual el entrenamiento de los modelos de producción deba realizarse mediante experimentos registrados en MLflow o un sistema equivalente, en lugar de utilizar cuadernos sin registrar. Las ejecuciones de entrenamiento no registradas no pueden auditarse ni reproducirse.

Cálculo del retorno de la inversión (ROI) del linaje de datos

El retorno de la inversión (ROI) de Lineage proviene de cuatro fuentes: una respuesta más rápida ante incidentes, la reducción de los costes de preparación de auditorías, la prevención de fallos en la producción y la mejora de la productividad de los analistas.

Reducción del tiempo de respuesta ante incidentes

Los incidentes relacionados con los datos —informes erróneos, procesos de procesamiento fallidos, valores inesperados— requieren una investigación de la causa raíz. Sin el linaje, los ingenieros rastrean los problemas manualmente a través de historiales de consultas, registros de procesos y documentación del sistema. Con el linaje, esa misma investigación recorre el gráfico de linaje desde el resultado afectado hasta el origen del problema.

Mejora típica: El tiempo medio de resolución (MTTR) de las incidencias relacionadas con los datos se reduce de entre 4 y 8 horas a menos de 30 minutos en los casos en que el fallo se produce en un proceso de tratamiento de datos rastreado.

Fórmula: Ahorro anual en la gestión de incidentes = (Incidentes al año) × (Horas ahorradas por incidente) × (Coste horario total de los ingenieros)

Ejemplo: 50 incidentes al año, cada uno de los cuales supone un ahorro de 4 horas a 100 dólares la hora = 20 000 dólares al año por cada ingeniero del equipo de investigación.

Reducción de los costes de preparación de la auditoría

La preparación de una auditoría normativa requiere recopilar la documentación sobre el linaje de los activos de datos objeto de la auditoría. Sin un sistema automatizado de linaje, se trata de un proceso manual que lleva semanas. Con un sistema automatizado de linaje, los informes de auditoría se generan bajo demanda a partir de los registros ya almacenados en el catálogo.

Mejora habitual:el tiempo de preparación de las auditoríasse reduce de entre 3 y 6 semanas a entre 1 y 3 días en el caso de las auditorías que abarcan activos de datos rastreados.

Fórmula: Ahorro anual en auditorías = (Ciclos de auditoría al año) × (Días ahorrados por auditoría) × (Coste diario total del tiempo del equipo de cumplimiento normativo)

Ejemplo: 4 ciclos de auditoría al año, cada uno de los cuales supone un ahorro de 15 días, con un equipo de cumplimiento normativo de 4 personas a 800 dólares por persona y día = 192 000 dólares al año.

Prevención de fallos en la producción

Los cambios en los esquemas y las modificaciones en los flujos de trabajo que afectan a los activos posteriores provocan fallos en la producción que perjudican a los sistemas de generación de informes, análisis y operativos. El análisis de impacto basado en el linaje permite a los ingenieros identificar y resolver los cambios que provocan fallos antes de su implementación.

Mejora típica: Los fallos de producción debidos a impactos no detectados en fases posteriores se reducen entre un 40 % y un 60 % tras implementar el seguimiento del linaje a nivel de columna en los procesos críticos.

Fórmula: Ahorro anual por prevención de fallos = (fallos evitados al año) × (coste medio por fallo — tiempo de ingeniería, impacto en el negocio, penalizaciones por incumplimiento del SLA)

Ejemplo: Evitar 10 fallos de producción al año con un coste medio de 15 000 dólares cada uno = 150 000 dólares al año.

Mejora de la productividad de los analistas

Los analistas que no pueden rastrear la procedencia de una métrica remiten el caso al equipo de datos para que la valide. El linaje, que muestra la ruta completa del cálculo desde la fuente hasta el panel de control —y que se puede consultar en el catálogo de datos—, elimina la mayoría de estas remisiones.

Mejora habitual:las consultas que los analistas remiten al equipo de datossobre cuestiones relacionadas con el linaje se reducen entre un 50 % y un 70 % tras la publicación del linaje empresarial para las métricas clave.

Fórmula: Ahorro anual en productividad de los analistas = (Escalaciones evitadas al mes) × 12 × (Tiempo medio por escalación) × (Coste horario total del tiempo del equipo de datos)

Ejemplo: Evitar 30 escalaciones al mes, de 2 horas cada una, a 80 dólares la hora = 57 600 dólares al año.

Cálculo del ROI total

Rentabilidad anual de la línea de negocio = Ahorro en respuesta a incidentes + Ahorro en auditorías + Ahorro por prevención de fallos + Ahorro por productividad de los analistas

Total del ejemplo:20 000 $+ 192 000 $ + 150 000 $ + 57 600 $ = 419 600 $ al año

Ejemplo de coste anual de la plataforma: 150 000 dólares

Rentabilidad de la inversión (ROI):(419 600 $ – 150 000 $) / 150 000 $ = 180 %

La mayoría de las organizaciones que cuentan con implementaciones maduras de trazabilidad logran un retorno de la inversión positivo en un plazo de entre 6 y 12 meses tras la puesta en marcha.

Fallos habituales en el linaje y análisis a posteriori

Error 1: Lineage se ha implementado, pero no se ha mantenido

Qué ocurrió: Una organización implementó el seguimiento de linajes en 200 flujos de trabajo en 2023. En 2025, el 60 % de los registros de linajes llevaba más de un año sin actualizarse. Los ingenieros dejaron de confiar en el seguimiento de linajes porque ya no reflejaba la configuración actual de los flujos de trabajo. El catálogo pasó a ser un artefacto histórico en lugar de una herramienta operativa.

Causa principal: El linaje se recopiló mediante una importación masiva única, en lugar de mediante una recopilación automatizada continua vinculada a la ejecución del proceso. Cuando se modificaron los procesos, los registros de linaje no se actualizaron.

Solución: La captura del linaje debe estar basada en eventos —activada por la ejecución de los flujos de trabajo, los cambios en los esquemas y las actualizaciones del catálogo— y no programarse como un trabajo por lotes periódico. Conecta la ingesta del linaje a los eventos de la plataforma de orquestación para que el linaje se actualice cuando se ejecuten los flujos de trabajo.

Error 2: Considerar que el linaje a nivel de conjunto de datos es suficiente para cumplir con la normativa

Qué ocurrió: Una entidad de servicios financieros implementó el linaje a nivel de conjunto de datos en todos los procesos de presentación de información regulatoria. Durante una auditoría conforme a la norma BCBS 239, las autoridades reguladoras solicitaron trazabilidad a nivel de campo, desde la fuente hasta la presentación regulatoria, para determinados indicadores de riesgo. El linaje a nivel de conjunto de datos no permitió responder a la pregunta. La entidad dedicó tres semanas a reconstruir manualmente el linaje a nivel de columna bajo la presión de la auditoría.

Causa principal:Se implementó el linaje a nivel de conjunto de datosporque resultaba más rápido y económico. El linaje a nivel de columna se consideró una mejora futura. Los requisitos normativos partían de la base de que existía trazabilidad a nivel de columna.

Solución:Definirlos requisitos de profundidad del linaje en función de las obligaciones normativas antes de comenzar la implementación. En el caso de los datos regulados de los sectores de servicios financieros, sanitario y farmacéutico, el linaje a nivel de columna no es opcional. Impleméntelo desde el principio en los flujos de trabajo regulados.

Error n.º 3: Implementación de Lineage sin tener en cuenta el contexto empresarial

Qué ocurrió:Unaempresa minorista implementó un linaje técnico completo a nivel de columna en todo su conjunto de datos. Los ingenieros podían rastrear cualquier campo a través de cualquier canalización. Sin embargo, los analistas y los usuarios de negocio no podían utilizar el linaje porque estaba expresado íntegramente en términos técnicos —nombres de tablas, nombres de columnas, operaciones SQL— sin ninguna correspondencia con conceptos o métricas de negocio.

Causa principal:La implementación del linajefue responsabilidad exclusiva del equipo de ingeniería de datos, sin ninguna aportación por parte de los administradores ni de los usuarios de negocio. Nunca se creó el linaje de negocio —la correspondencia entre los activos técnicos y los términos de negocio y los indicadores clave de rendimiento (KPI)—.

Solución: Implementa el linaje empresarial junto con el linaje técnico desde el principio. Colabora con los responsables de datos y los propietarios de dominios para asignar las métricas empresariales clave —ingresos, número de clientes, tasa de abandono— a sus cadenas de linaje técnico. Publica esta asignación en el catálogo de datos para que los analistas puedan encontrarla.

Error n.º 4: El seguimiento del origen de los datos de entrenamiento de la IA no se implementa hasta después de la auditoría del modelo

Qué ocurrió: Una organización sanitaria entrenó un modelo de apoyo a la toma de decisiones clínicas utilizando un conjunto de datos que incluía información procedente de un sistema fuente que había quedado obsoleto y había sido sustituido. El sistema fuente sustitutivo presentaba características de calidad diferentes. El rendimiento del modelo se deterioró tras su implementación. Cuando los auditores solicitaron la procedencia de los datos de entrenamiento, la organización no pudo presentar un registro completo del linaje, ya que no se había implementado el linaje de los datos de entrenamiento de la IA.

Causa raíz: Se implementó el linaje de datos para los flujos analíticos, pero no se extendió a los flujos de entrenamiento de IA. Los datos de entrenamiento se seleccionaron y procesaron fuera del entorno de datos regulado.

Solución:Ampliarel seguimiento del origen de los datos a los flujos de trabajo de IA antes de que los modelos entren en producción. Definir una política según la cual todo modelo de producción deba contar con un seguimiento documentado del origen de los datos de entrenamiento como condición para su implementación. Utilizar MLflow o una herramienta equivalente para realizar un seguimiento de las ejecuciones de entrenamiento y vincular las referencias a los conjuntos de datos de entrenamiento con el catálogo de datos de origen.