Gouvernance de la donnée pour l'IA. Le prérequis que tout le monde saute.

Quatre couches de données, quatre modes d'échec.

Quand nous emmenons une équipe dirigeante dans le travail de gouvernance que l'IA exige, nous commençons généralement par nommer les quatre couches à gouverner ensemble. La première est constituée des systèmes source, plateformes opérationnelles et analytiques qui détiennent l'enregistrement canonique des clients, transactions, contenus et opérations. La deuxième est le feature store ou la couche curée où la donnée est transformée pour usage par les modèles et les agents. La troisième est l'index de recherche, le vector store ou le système de recherche que l'agent interroge au moment de l'inférence. La quatrième est la piste de sortie, le journal de ce que l'agent a produit, quand, pour qui et dans quel contexte.

Chaque couche a son mode d'échec propre, et la plupart des entreprises avec lesquelles nous travaillons ont une gouvernance qui couvre une ou deux des quatre. Les systèmes source ont généralement des contrôles d'accès et une piste d'audit parce que les fonctions finance et audit les exigent depuis des années. Les feature stores sont souvent gouvernés de manière informelle par l'équipe data. Les index de recherche sont souvent assez récents pour n'avoir aucun contrôle. Les pistes de sortie existent sous forme fragmentée à travers des outils de log qui n'ont jamais été conçus pour porter une conversation d'audit.

La conversation qui produit de vrais progrès est celle qui nomme les quatre couches explicitement, attribue un propriétaire à chacune, et accepte que le travail de gouvernance ne soit pas un seul projet mais un petit portefeuille avec quatre chantiers parallèles.

Les trous de gouvernance que nous voyons revenir.

Quatre trous spécifiques reviennent dans presque chaque diagnostic que nous menons. Le premier est l'absence de propriétaire des contrôles d'accès dans l'index de recherche. Le vector store contient des chunks de documents source, mais la logique de contrôle d'accès du document d'origine n'est pas toujours répercutée sur le chunk. Un collaborateur qui n'aurait pas pu lire le PDF original peut parfois poser une question à l'agent et recevoir un morceau de son contenu dans la réponse.

Le deuxième est un traitement des PII documenté dans une politique mais non appliqué à l'exécution. L'équipe data a une règle affichée sur le masquage des identifiants client avant qu'ils n'atteignent la fenêtre de contexte du modèle. Le chemin de code qui construit le contexte contourne parfois ce masquage quand un développeur est pressé. Le trou entre la politique et le runtime est là où atterrit la question du régulateur.

Le troisième est un lignage rompu. Quand le régulateur ou l'auditeur interne demande comment une sortie précise a été produite, l'équipe peut généralement répondre pour le modèle et le prompt, mais pas pour la transformation en amont qui a produit la feature ayant influencé la réponse. La chaîne de lignage casse quelque part entre le système source et l'index de recherche, et le travail de récupération devient forensique plutôt que systématique.

Le quatrième est une rétention incohérente. La donnée source a une règle de rétention. Le feature store en a une différente. L'index de recherche n'en a souvent aucune, et la piste de sortie est parfois conservée indéfiniment pour des raisons de débogage. Un régulateur qui demande l'exercice du droit à l'oubli ne peut pas obtenir une réponse propre quand les politiques de rétention divergent entre les quatre couches.

Une base pragmatique avant le premier agent en production.

La version de cette base qui fonctionne tend à être courte et concrète. Nous nommons une source canonique pour chaque domaine de données que l'agent utilisera. Nous documentons et appliquons les contrôles d'accès au niveau de l'index de recherche, en miroir des règles du système source. Nous masquons ou tokenisons les PII avant que le modèle ne les voie, avec un masquage appliqué par une bibliothèque partagée plutôt que par la discipline des développeurs. Nous instrumentons le lignage de la source jusqu'à la piste de sortie pour que toute réponse produite par l'agent puisse être tracée jusqu'à ses entrées. Nous nous accordons sur une règle de rétention qui tient sur les quatre couches et qui est honorée par le pipeline de suppression.

Aucun de ces mouvements n'exige une nouvelle technologie dans la plupart des cas. Ils exigent que l'équipe data et l'équipe d'ingénierie IA s'accordent sur un runtime partagé, avec des bibliothèques partagées et des logs partagés. La conversation prend généralement plus de temps que l'implémentation, et c'est la conversation qui se capitalise.

Les équipes avec qui nous travaillons qui ont bien établi cette base rapportent que le deuxième et le troisième agent qu'elles mettent en production coûtent bien moins cher, parce que la plomberie de gouvernance est déjà en place. Celles qui sautent la base rapportent que chaque nouvel agent rouvre les mêmes batailles, et ces batailles deviennent plus difficiles à mesure que la pression d'audit monte.

Comment phaser la gouvernance sans geler le pipeline.

L'erreur que nous voyons le plus souvent quand une organisation essaie de prendre la gouvernance au sérieux est de déclarer un programme complet qui doit s'achever avant que tout nouveau travail IA puisse être mis en production. Le pipeline se fige, le soutien politique à la gouvernance s'érode, et le prochain agent sort dix-huit mois plus tard via un contournement tactique qui défait l'intention d'origine.

Le phasage qui fonctionne est celui qui adosse la gouvernance aux trois ou quatre premiers vrais cas d'usage. Pour chaque cas, l'équipe construit la base de gouvernance dont le cas a vraiment besoin, contribue les parties réutilisables à la plateforme partagée, et livre. Après trois ou quatre cycles, la plateforme porte assez de la base pour que les nouveaux cas héritent de l'essentiel plutôt que de tout reconstruire.

L'avantage de ce phasage est que le travail de gouvernance est visiblement rattaché à de la valeur livrée. L'inconvénient est qu'il exige de la discipline de la part des équipes data et ingénierie pour vraiment contribuer à la plateforme plutôt que livrer et passer. Cette discipline est, d'après notre expérience, le plus grand prédicteur du fait que la base de gouvernance mûrit dans le temps ou reste figée.

La gouvernance comme fonctionnalité, pas comme frein.

Le cadrage qui fonctionne le mieux avec les équipes dirigeantes que nous accompagnons est de traiter la gouvernance comme une fonctionnalité du programme IA plutôt que comme une taxe sur lui. Un stack IA bien gouverné est plus rapide à étendre, plus facile à défendre devant un régulateur, et bien moins coûteux à opérer à l'échelle que l'alternative. Les équipes que nous avons vues atteindre cet état décrivent le même basculement dans la conversation : la question de savoir si un nouvel agent peut sortir passe d'un débat sur le risque à une vérification face à un runtime partagé, et le débat se déplace là où il aurait dû être dès le départ, c'est-à-dire sur la valeur du cas d'usage.

Si votre organisation se prépare à mettre en production son premier ou son deuxième agent, le mouvement pratique que nous recommandons est de nommer les quatre couches de données, d'attribuer un propriétaire à chacune, et de produire la base d'une page qui dit ce qui est en place pour chacune. La première fois où la conversation a été explicitement menée est presque toujours le moment où les trous deviennent visibles et où le trimestre de travail suivant s'impose.

Les équipes Consulting et Tech Factory de nos bureaux de Paris, Dubaï, Singapour et Bali sont joignables depuis le formulaire ci-dessous. Nous répondons sous un jour ouvré, avec un partner qui suivra le dossier.