Gouvernance au-delà de la sécurité : connaissances, contexte et ontologie sur le lakehouse

Demandez à la plupart des organisations ce que signifie la gouvernance des données pour l'AI, et vous obtiendrez une réponse axée sur la sécurité : verrouiller, restreindre l'accès, réussir l'audit. Dans le secteur de la santé, la sécurité n'est pas négociable, mais elle est incomplète. La sécurité vous indique qui peut toucher aux données. Elle ne dit rien sur ce que les données signifient, si on peut leur faire confiance, ou si un modèle d'AI devrait un jour apprendre d'elles.

Notre Data Empowerment Program (DEP) part d'un principe différent : la gouvernance est une question de connaissance, de contexte et d'ontologie, et pas seulement de contrôles. Les éléments que la plupart des équipes considèrent comme une contrainte de conformité, tels que les balises de classification, les politiques de dé-identification, les fiches de modèle et les contrats de données, constituent la matière première de la sémantique des données de l'entreprise.

Vu sous cet angle, vous n'avez pas à choisir entre la gouvernance et l'AI ; au contraire, la gouvernance aide à concevoir l'AI. De nouvelles approches de la gouvernance doivent être mises en œuvre à l'ère de l'AI. La seule question est de savoir si vous ferez ce travail plus tard, juste pour réussir l'audit, ou dès maintenant, pour jeter les bases sur lesquelles repose votre AI.

Notre objectif est de montrer que le travail de sécurité et de gouvernance que vous réalisez déjà constitue le fondement même de votre AI. Gouvernez correctement les données, et l'AI pourra s'appuyer sur des modèles moins coûteux tout en offrant une plus grande confiance.

La gouvernance doit voir plus large à travers cinq piliers et un prisme unique

Partez du principe que chaque élément de gouvernance contribue à la sémantique. Chaque balise de classification est un concept. Chaque fiche de modèle est un contexte. Chaque contrat de données est une définition partagée. Chaque lien de lignage (lineage) est une relation. Vu ainsi, la suite de sécurité que vous utilisez déjà est la première ébauche de votre ontologie, et le catalogue est l'endroit où elle réside.

La gouvernance cesse alors d'être un bloc monolithique pour devenir les cinq facettes d'une seule et même discipline : les données elles-mêmes et la manière dont elles sont contrôlées, l'AI construite par-dessus, les personnes qui doivent la comprendre, les produits qui la diffusent dans l'entreprise, et le contexte partagé qui relie ces quatre éléments. C'est le même prisme, mais sous cinq angles différents.

Avec le DEP, nous concevons la sémantique à travers cinq piliers :

• Gouvernance des données — Catalogue, qualité, curation, lignage (lineage), avec sécurité et conformité intégrées telles que la classification PII, le contrôle d'accès, HIPAA/GDPR et les risques de confidentialité spécifiques à l'AI.
• Gouvernance des connaissances (AI/ML) — Documentation des modèles, gouvernance et normes d'AI responsable telles que les biais et l'équité, l'explicabilité, la supervision humaine et la préparation à l'EU AI Act.
• Culture des données (Data Literacy) — Formation, autonomisation en libre-service, certification des praticiens et KPIs tels que les taux d'adoption, les métriques d'utilisation et le ROI du programme.
• Gestion des données (Data Management) — L'architecture, le data engineering et les contrats de produits de données doivent inclure des accords de schéma, des SLAs et des seuils de qualité, ainsi que les obligations des producteurs et des consommateurs.
• Ontologie — Glossaire, taxonomie, graphe de connaissances - pour aboutir à une couche sémantique d'AI. Cela inclut le contexte pour les LLMs, l'ancrage (grounding) RAG et la préparation aux requêtes par chat.

Opérationnaliser la vision grâce aux agents

Notre vision en Diagnostic en cinq piliers ne resterait qu'une simple présentation théorique si la plateforme ne permettait pas de la traduire en quelque chose d'opérationnel. Dès lors que vos éléments de gouvernance se présentent sous forme de métadonnées structurées et lisibles par machine, ils cessent d'être de simples documents pour de véritables ensembles d'instructions pour les agents.

Lorsque nous parlons d'« agent », nous y pensons de deux manières : les « agents de construction » (build agents) qui assemblent et livrent des produits de données, et les « agents analytiques » (analytic agents) qui répondent aux questions métier par-dessus ; chacun étant lié à un seul produit de données.

Commençons par les agents de construction. Les agents de construction automatisent le cycle de vie de livraison des produits de données, du mappage des sources jusqu'à la mise en production, en passant par l'ETL, les tests et la dé-identification. Tout ce dont ils ont besoin réside dans Unity Catalog sous forme de métadonnées gouvernées : mappages source-destination, définitions métier, niveaux de classification, politiques de dé-identification, contrats de données et fiches de modèle. La plateforme s'appuie sur les balises, les commentaires, les indicateurs de certification, le lignage (lineage) et les termes liés au glossaire. Le catalogue n'est pas seulement l'endroit où vous documentez la gouvernance ; c'est l'environnement d'exécution sur lequel s'appuient les agents.

Chaque agent fonctionne en boucle. Il lit les instructions du catalogue, effectue une tâche concrète (comme générer le code d'un pipeline, exécuter une suite de tests, produire des données dé-identifiées ou déployer un jeu de données certifié), puis réinscrit les preuves sous forme de résultats de tests, de scores de qualité, de lignage (lineage) ou de données de capture de changement. Ce processus se répète.

En pratique, nous séquençons d'abord les agents de De-ID (dé-identification) et de test. Ils éliminent d'emblée les risques les plus élevés et le travail manuel le plus lourd. Commencer là où le retour sur investissement est le plus rapide permet de créer une dynamique dès le départ. Tout au long de la boucle, aucun agent n'agit sur des données qui ne sont pas décrites dans le catalogue.

Les catalogues modernes rendent cette approche évolutive car ils peuvent générer automatiquement des descriptions de colonnes et de tables qu'un gestionnaire (steward) pourra approuver, classifier automatiquement les champs sensibles et capturer le lignage (lineage) au niveau des colonnes sans aucune intervention manuelle. Le rôle de l'humain passe de la rédaction des métadonnées à leur approbation, ce qui correspond exactement au type de travail de jugement que les humains doivent effectuer.

Le cycle de vie de construction des données et de l'AI : preuve et contexte continu

Les agents de construction opèrent au sein d'un cycle de vie de bout en bout conçu pour livrer simultanément deux actifs : le produit de données gouverné (mappage, curation, pipeline) et l'agent analytique qui s'exécute par-dessus (couche sémantique, configurations de prompts, suites d'évaluation).

Cette approche marque un changement fondamental, passant d'une ingénierie centrée sur les pipelines (déplacer les données d'un point A à un point B) à une ingénierie centrée sur le contexte (rendre les données compréhensibles et exploitables pour les LLMs). Plutôt que de certifier uniquement la qualité du code, les étapes de validation (gates) de ce cycle de vie valident la sémantique, le contexte et la propriété (ownership).

Deux propriétés fondamentales distinguent ce framework d'un SDLC traditionnel :

• Il apporte ses propres preuves : la preuve de la fiabilité est un sous-produit naturel de la livraison, plutôt qu'un exercice d'audit d'urgence préparé après coup.
• Il améliore continuellement le contexte : le comportement en production alimente une boucle AgentOps, transformant les requêtes ayant échoué, les groupes d'hallucinations et les votes négatifs des utilisateurs en un backlog sémantique pour le prochain sprint.

Les gestionnaires humains (stewards) servent de garant de la responsabilité pour ces deux propriétés : les agents proposent, les humains approuvent. Bien que la gestion de cinq étapes de validation sur deux parcours puisse sembler créer des goulots d'étranglement fastidieux, la plupart des étapes peuvent être franchies en quelques heures seulement. Les approbations se font directement au sein des outils de développement standards. Des suites de tests automatisées associent les résultats de qualité des données, les scores d'évaluation et le lignage (lineage) avant même l'ouverture d'un ticket. Une réunion formelle de validation est une exception pour mener une investigation, et non la procédure standard.

La certification AI est le moteur qui sous-tend les étapes de validation

Le mécanisme qui rend ces étapes de validation objectives plutôt qu'arbitraires est la certification AI. Enregistrée directement dans Unity Catalog, cette certification agit comme une fiche d'évaluation automatisée et interrogeable, plutôt que comme une attestation juridique manuelle. Elle régit l'éligibilité au déploiement selon quatre dimensions fondamentales :

• Évaluation automatisée vs humaine : les scores de gouvernance, de qualité et de sémantique sont calculés automatiquement à partir de tables système interrogeables, de résultats de pipelines et de sessions d'évaluation. Le score de propriété (ownership) et le sceau final de déploiement nécessitent la signature explicite d'un gestionnaire (steward).
• Expiration continue : la certification est dynamique. Une modification de schéma, une mise à jour de contrat ou l'échec d'une suite d'évaluation révoque instantanément la certification jusqu'à ce que les vérifications soient réexécutées et réussies.
• Application au niveau de la couche de données : les contrôles d'accès s'effectuent via le contrôle d'accès basé sur les attributs (ABAC) au niveau de la couche de données, et non de la couche applicative. Si un utilisateur ne peut pas interroger une ligne en SQL, aucun agent ne peut la récupérer via une recherche vectorielle ou des embeddings.
• Isolation stricte des limites : les environnements hors production (SIT, régression, test de modèles) consomment exclusivement des données synthétiques ou dé-identifiées. Cela garantit que les PHI de production ne quittent jamais la zone gouvernée.

Quand l'agent se trompe, qui corrige ?

La certification et les barrières de validation prouvent qu'un agent était digne de confiance lors de sa mise en production. Mais la question que se posent les responsables de la gouvernance n'est pas « comment cela fonctionne-t-il ? », mais plutôt « qui est responsable lorsqu'il donne une mauvaise réponse ? ». La réponse doit être un nom précis, pas un comité de pilotage.

Pour résoudre ce problème, chaque agent analytique (par exemple, un Databricks Genie Agent) est lié à un unique produit de données gouverné avec un propriétaire désigné. Lorsqu'un agent renvoie un résultat incorrect parce qu'une métrique sous-jacente a été mal définie, le problème ne relève pas de l'équipe d'ingénierie AI. Il va directement au Data Product Owner, qui corrige la définition dans le catalogue. Lier un agent à un produit de données certifié et limité à un domaine est également le levier de précision le plus puissant disponible : un agent ciblé qui interroge des métadonnées certifiées surpasse systématiquement un modèle global qui tente de deviner des informations sur l'ensemble du patrimoine de l'entreprise.

Surtout, cette définition de métrique partagée est appliquée et non simplement documentée. Une fois qu'une métrique certifiée est définie dans le catalogue, l'agent de réponse est tenu d'effectuer ses calculs directement à partir de celle-ci. Cela transforme une documentation statique en une logique d'exécution active.

La responsabilité est maintenue grâce à une limite stricte de ce que l'AI est autorisée à faire sans surveillance : aucun agent ne déploie de code en production, ne modifie de politique ou ne traite de données non classifiées sans intervention humaine. Bien que les scores de certification soient calculés automatiquement, la barrière de validation finale nécessite toujours une signature humaine. Si le catalogue ne décrit pas explicitement un actif de données, le système choisit par défaut la suppression plutôt que de deviner. À l'exécution, cette politique de verrouillage par défaut (fail-closed) impose des limites claires :

• Pour les agents analytiques : au lieu de spéculer ou de déduire le contexte à partir de données brutes, l'agent refuse explicitement de répondre, en renvoyant un message transparent (par exemple, « Ce jeu de données ne dispose pas de la certification active ou du mappage sémantique requis pour traiter votre demande. »)
• Pour les agents de build : si un schéma non classifié ou un contrat manquant est détecté lors de l'assemblage du pipeline, l'exécution s'arrête automatiquement avant d'atteindre les environnements de préproduction, enregistrant un indicateur d'actif non mappé pour examen par le steward.

Définir ces garde-fous sur le papier est facile, mais les mettre en pratique nécessite de remplacer les comités de gouvernance vagues par quatre rôles distincts et responsables :

• Data Product Owner : responsable des définitions et de la qualité d'un produit gouverné. Il est le point de contact unique lorsqu'une réponse est fausse.
• Ingénieur de gouvernance Data & AI : traduit les politiques en métadonnées de catalogue exécutables (classifications, contrats, lignage) afin que les règles s'appliquent à l'exécution plutôt que de rester dans un PDF.
• Steward : examine les résultats automatisés et valide les étapes de mise en production. L'automatisation propose, le steward décide.
• Sécurité / IAM : gère les niveaux de classification et les attributs d'accès qui déclenchent automatiquement l'anonymisation et les autorisations au niveau des lignes.

Tester rigoureusement sans compromettre la sécurité

Le cycle de vie que nous avons décrit cache un prérequis indispensable : chacune de ces étapes de test et d'évaluation nécessite des données réalistes pour s'exécuter – et dans le secteur de la santé, vous ne pouvez pas tester de vraies PHI. Le défi consiste donc à disposer partout de données de test réalistes sans compromettre la sécurité.

L'anonymisation est le moyen de préserver l'utilité analytique et la sécurité des données. D'où l'agent d'anonymisation tire-t-il ses connaissances ? Pas d'un tableur mis à jour manuellement. Il s'appuie sur les politiques de sécurité déjà générées par les outils de l'entreprise. Le flux se déroule en trois étapes :

• Découvrir - Les scanners de découverte automatique et les moteurs de politique InfoSec classifient les colonnes et les fichiers sensibles.
• Organiser - Les classifications sont intégrées au catalogue sous forme de métadonnées de politique organisées ; l'agent lit cette organisation et s'exécute.
• Exécuter - Ingérer les métadonnées et produire des données synthétiques ou des fichiers sources anonymisés. Conforme à la règle Safe Harbor de la HIPAA, intègre sur le plan référentiel et exploitable pour l'analyse.

Pour l'équipe sécurité et IAM, c'est un échange à double sens. Les politiques InfoSec cessent d'être des PDF et deviennent exécutables : les niveaux de classification et les règles de rétention pilotent automatiquement l'anonymisation. En retour, la sécurité bénéficie d'une vue continuellement mise à jour des données sensibles, d'une protection par verrouillage par défaut pour tout élément nouvellement découvert, et d'analyses résiduelles qui génèrent des preuves d'audit à chaque exécution. Le modèle d'accès reste le même de bout en bout. Étant donné que toute récupération de données par l'agent hérite des autorisations de catalogue de l'utilisateur qui effectue la requête, les approches RAG ne peuvent pas afficher l'embedding d'une ligne que l'utilisateur n'est pas autorisé à voir. Les mêmes règles ABAC s'appliquent aussi bien à SQL qu'à la recherche vectorielle, et les agents agissent avec les droits de l'utilisateur demandeur, et non avec un compte de service privilégié. Chaque prompt de l'agent est enregistré avec le lignage utilisé pour y répondre, sous la même gouvernance que les données elles-mêmes.

C'est là le véritable déclic : un modèle d'autorisation unique pour les données, les modèles, les embeddings et la piste d'audit — et non un catalogue de données raccordé à un registre de modèles distinct, lui-même raccordé à un magasin de vecteurs distinct. Le travail de gouvernance devient la fondation de l'AI plutôt qu'un projet parallèle.

Capturer des métriques, prouver les résultats, gagner la confiance

Remarquez ce que le cycle de vie a fait pendant tout ce temps : chaque étape, chaque barrière de validation, chaque certification a produit des métriques. Regroupez les quatre dimensions de certification en un seul score de préparation à l'AI (AI-readiness) par jeu de données, et rendez-le opérationnel, pas seulement théorique. La sémantique n'atteint 100 % que lorsque chaque colonne comporte une définition liée à un glossaire et que la table dispose d'un contrat de données signé ; la propriété (Ownership) n'atteint 100 % que lorsqu'un propriétaire désigné répond aux incidents.

Le résultat qui découle de cette évaluation constitue l'analyse de rentabilité de l'ensemble du programme DEP : les métriques prouvent les résultats de l'AI, la preuve gagne la confiance, et la confiance est ce qui transforme un projet pilote en un usage quotidien. Aucun utilisateur métier n'adopte un agent parce que le schéma d'architecture est élégant. Ils l'adoptent parce que les chiffres étaient exacts la semaine dernière et que la personne responsable les a corrigés lorsqu'ils ne l'étaient pas. Le score explique pourquoi les chiffres sont corrects dès le départ : plus le score est élevé, moins le modèle a besoin de deviner. Il n'a pas à déduire la signification d'une colonne, à compenser les doublons ou à halluciner des jointures, car le catalogue le lui a déjà indiqué.

Ne courez pas après les gros titres sur les modèles. Visez la rentabilité des modèles.

Chaque semaine apporte un modèle plus grand et plus coûteux. Voici ce que le cycle de l'engouement médiatique oublie : lorsque le catalogue fournit déjà la signification, la qualité et le contexte, le modèle n'a plus besoin de le faire. Des modèles plus petits ou à poids ouverts (open-weights) répondent à la plupart des besoins de reporting et d'analyse sur des données gouvernées.

Les modèles de pointe (frontier models) sont souvent utilisés pour masquer des lacunes sous-jacentes dans les métadonnées. Lorsque les schémas et les règles métier sont explicitement catalogués, des modèles plus petits et spécialisés par domaine offrent une précision identique pour une fraction du coût en jetons (tokens).

Il s'agit d'un choix de rapport coût-qualité, et non d'un plafond de qualité. Adaptez la taille du travail quotidien, réservez les dépenses liées aux modèles de pointe aux problèmes qui en ont réellement besoin, et le coût ne contraindra jamais l'AI à s'arrêter. Corrigez les données. Adaptez la taille du modèle. Conservez la précision. C'est ce que les bases de la gouvernance apportent à une stratégie AI : non pas une AI moins chère, mais une AI imparable.

Passez à l'action : commencez par un seul produit de données

N'essayez pas de mener de front une refonte complète à l'échelle de l'entreprise. Prouvez l'efficacité du modèle en soumettant un seul produit de données à l'ensemble du cycle de vie :

1. Analyser : activez l'analyse de découverte automatique sur un seul schéma cible.
2. Définir : définissez des seuils de certification explicites dans Unity Catalog pour la complétude, la sémantique et la qualité.
3. Lier : associez un agent analytique au jeu de données, ainsi qu'une suite d'évaluation dédiée et un parcours de test anonymisé.
4. Attribuer : nommez un unique Data Product Owner responsable des définitions et de la résolution des incidents.

Une fois la boucle lancée, répétez le processus un produit de données certifié à la fois. La sécurité vous indique qui peut accéder à vos données, mais la gouvernance vous indique ce qu'elles signifient et si une IA peut leur faire confiance.

La gouvernance n'est pas une barrière devant une entreprise axée sur les données. Bien mise en œuvre, elle en est le socle.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original