Le data lineage pour l’IA consiste à documenter, de façon continue et exploitable, la chaîne complète allant des sources de données jusqu’aux décisions générées par un LLM : quelle donnée a été injectée dans quel contexte, sous quelle version, via quelle transformation. Sans cette couche, un auditeur ou un directeur conformité ne peut vérifier ni la légitimité des données utilisées, ni la reproductibilité du raisonnement ; l’EU AI Act en fait désormais une exigence opposable pour tout système à risque élevé, et les ETI l’anticipent avant même d’y être contraintes. La distinction avec le lineage classique est fondamentale : le LLM ne calcule pas une agrégation déterministe, il génère un output probabiliste dont l’origine doit être prouvable à chaque inférence.
Pourquoi le lineage traditionnel ne suffit-il pas aux flux vers les LLM ?
Le lineage traditionnel trace des colonnes SQL d’une source vers un rapport : transformations figées, résultat reproductible à l’identique. Les LLM fonctionnent autrement : ils consomment du contexte assemblé à l’exécution (chunks issus d’un index vectoriel, prompt système, historique de session) et produisent un output probabiliste qui n’est pas une simple agrégation de lignes.
Les outils de data catalog classiques (dbt, Collibra, Alation) savent tracer une transformation SQL ou un modèle supervisé. Ils ne voient pas ce qui s’est passé dans la fenêtre de contexte au moment de l’inférence. Résultat : vous avez un graphe de lineage impeccable jusqu’au chunk vectorisé, puis un trou noir entre le retrieval et la réponse finale. C’est précisément ce vide que l’AI Act cible quand il parle de documentation de la chaîne de traitement.
Trois écarts structurels expliquent cette limite :
- Non-déterminisme : deux inférences sur les mêmes données peuvent produire deux réponses différentes selon la température, la version du modèle ou l’ordre des chunks.
- Contexte dynamique : dans un système RAG, les documents injectés varient à chaque requête selon le score de similarité ; le lineage doit être capturé par appel, pas par pipeline.
- Opacité des poids : le lineage technique ne dit rien sur pourquoi le modèle a retenu tel fragment plutôt qu’un autre — c’est là que lineage et traçabilité décisionnelle divergent fondamentalement.
Comment cartographier le cycle de vie d’une donnée depuis la source jusqu’à l’inférence ?
La cartographie du cycle de vie complet exige de couvrir quatre niveaux : ingestion (source, format, date de validité), transformation (pipeline ETL/ELT, modèle dbt, filtres qualité), indexation (embedding model, version de l’index vectoriel, politique de chunking) et inférence (prompt final envoyé, chunks sélectionnés, version du LLM, timestamp). Chaque niveau doit produire des métadonnées persistées et interrogeables après coup.
Commencez par les agents qui prennent des décisions à enjeu (scoring crédit, triage, recommandation contractuelle) avant d’étendre à l’ensemble du système. C’est le même cadrage que nous appliquons dans notre démarche de modélisation et cartographie des données.
Quels indicateurs clés prouvent la provenance et la qualité des données d’un agent IA ?
Les indicateurs de provenance et qualité d’un agent IA ne sont pas les KPI classiques de la data quality (taux de complétude, doublons). Ils doivent répondre à des questions concrètes : cette donnée était-elle encore valide au moment de l’inférence ? Était-elle autorisée pour cet usage ? A-t-elle subi une transformation susceptible d’introduire un biais mesurable ?
- Data freshness : délai entre la mise à jour de la source et la date d’indexation dans le vecteur store — critique pour les données tarifaires ou réglementaires.
- Chunk relevance score : score de similarité cosinus entre la requête et chaque chunk injecté, loggué par appel.
- Schema version : version du schéma source au moment de l’ingestion, pour détecter les dérives silencieuses.
- Data consent / usage policy : flag indiquant si la donnée était dans le périmètre autorisé (RGPD, contrat fournisseur) pour l’usage ciblé.
- Model version hash : empreinte du modèle d’embedding et du LLM utilisés ; deux versions différentes sur le même corpus peuvent produire des interprétations divergentes.
Ces indicateurs ne sont utiles que s’ils sont persistés dans un log structuré (JSON, Parquet) interrogeable, pas seulement dans des traces applicatives écrasées toutes les 24 heures. Si vos données ne répondent pas encore à ces critères de base, notre article sur les prérequis data avant un projet IA pose les fondations nécessaires.
Comment documenter automatiquement le pipeline pour les audits de conformité ?
Automatiser cette documentation, c’est instrumenter chaque maillon du pipeline LLM pour qu’il émette des événements structurés sans intervention manuelle. Un wiki de lineage tenu à la main est périmé dès la mise à jour suivante du pipeline, et aucun auditeur ne le croira à jour.
Trois approches complémentaires fonctionnent en production :
- OpenLineage + Marquez : standard ouvert supporté nativement par Airflow et Spark. Chaque job émet un événement START/COMPLETE avec les datasets en entrée et en sortie, extensible aux pipelines LLM via des facets personnalisées.
- LangSmith, Langfuse ou Phoenix (Arize) : outils spécialisés LLM qui capturent automatiquement la chaîne d’appels (retrieval, prompt, génération) avec les métadonnées associées, exportables en JSON pour audit.
- Data catalog connecté : les outils de data catalog scannent les métadonnées de vos outils existants (Snowflake, dbt, Power BI) pour reconstruire le graphe automatiquement, jusqu’au vecteur store si le connecteur est disponible.
L’audit AI Act ne demande pas un outil unique : il demande que la chaîne soit reconstituable depuis les artefacts persistés. Un export JSON horodaté des logs d’inférence, croisé avec le graphe dbt et la politique d’usage des données, satisfait la plupart des exigences pour les systèmes à risque limité. Pour les systèmes à risque élevé, l’exigence monte d’un cran : la documentation doit être produite avant le déploiement, pas après incident.
Quelle est la différence concrète entre lineage de données et traçabilité des décisions IA ?
Le lineage de données et la traçabilité des décisions IA répondent à deux questions distinctes : le lineage dit d’où vient la donnée et comment elle a été transformée ; la traçabilité décisionnelle dit pourquoi le système a produit cette réponse sur la base de cette donnée. Cette distinction est au cœur des débats actuels en gouvernance des données IA : un lineage parfait ne suffit pas à expliquer une décision contestée.
Pour un LLM, la traçabilité décisionnelle implique de capturer l’identité des chunks retenus dans la fenêtre de contexte, leur ordre de présentation, la version exacte du prompt système, et idéalement un mécanisme d’attribution qui relie l’output à des fragments précis. C’est ce que les équipes juridiques appellent l’explicabilité, et ce que l’AI Act encadre pour les décisions à effet significatif sur les personnes.
Un système de recommandation RH alimenté par un LLM peut avoir un lineage impeccable (CV sources traçables, pipeline ETL documenté) et pourtant produire des décisions inexplicables si le prompt système contient des biais non documentés. Lineage et traçabilité décisionnelle sont complémentaires, pas substituables. En production, c’est exactement la couche que prend en charge notre offre Run, Ops & gouvernance IA.
FAQ
Quels outils intégrer pour lier les logs d’exécution des agents à la donnée source ?
Les frameworks d’observabilité LLM (LangSmith, Langfuse, Phoenix d’Arize) capturent la chaîne d’appels et les métadonnées de retrieval. Côté data, OpenLineage assure le lien avec les sources. La clé est un identifiant de corrélation partagé, un run_id propagé de l’ingestion jusqu’à l’inférence, qui permet de joindre les deux graphes dans votre data catalog sans reconstruction manuelle.
Comment gérer l’évolution des schémas de données dans un système RAG sans casser la traçabilité ?
Versionner l’index vectoriel à chaque changement de schéma source est la seule approche fiable : un chunk indexé sous le schéma v1 n’est pas comparable à un chunk v2 sans métadonnée de version. Maintenez un registre des versions d’index (date, schéma source, modèle d’embedding) et taguez chaque chunk à l’indexation. Les causes de dérive sont détaillées dans notre article sur les hallucinations RAG en entreprise.
Le lineage en temps réel est-il nécessaire pour la conformité AI Act ?
Non. L’AI Act impose une traçabilité reconstituable a posteriori, pas un monitoring en temps réel. Pour la plupart des systèmes à risque élevé, un lineage en quasi-temps-réel (latence de quelques minutes, log structuré persisté) suffit. Le temps réel strict ne se justifie que pour des décisions irréversibles en flux continu, comme le trading algorithmique ou le triage médical d’urgence.
Le data lineage protège-t-il contre les hallucinations des LLM ?
Indirectement. Le lineage ne supprime pas les hallucinations, mais il permet de les détecter et d’en identifier la cause : chunk obsolète, document hors périmètre, prompt mal calibré. En traçant les sources effectivement injectées, vous pouvez post-analyser les réponses erronées et corriger le pipeline à sa racine plutôt que de filtrer les outputs en sortie.
Vos flux LLM sont-ils aujourd’hui reconstituables pour un audit ? Demandez votre diagnostic : nous cartographions avec vous les gaps de traçabilité et les priorités d’instrumentation.
