Les stratégies de gouvernance des données pour l'IA

Un client écrit à votre support et demande la suppression de ses données. Vous savez exactement où elles sont : la table customers dans S3. Vous supprimez les lignes et vous répondez.

Six semaines plus tard, une revue juridique dresse la liste des endroits où les données de ce client se trouvaient réellement le jour de la demande. L'export brut dans la zone d'atterrissage. La table curée que la suppression a touchée. Les chunks de knowledge base construits à partir de ses tickets de support, toujours présents dans le vector store sous forme d'embeddings. Le log group CloudWatch qui contient chaque prompt et chaque complétion de l'assistant, dont trois conversations où un agent a collé la fiche de compte complète dans un prompt. Un CSV qu'un data scientist a tiré vers un notebook en mars. Et un modèle affiné qui a lu tout cela pendant son entraînement.

Vous avez supprimé une copie sur six et annoncé au client que c'était fait.

Rien de tout cela n'est une faille de sécurité. Chaque bucket était chiffré, chaque rôle était limité, chaque chemin réseau était privé. Ce qui manquait, c'est l'autre moitié : un ensemble de règles disant combien de temps chacune de ces copies a le droit d'exister, où elle a le droit de vivre, à quoi elle a le droit de servir, et qui tranche. C'est la gouvernance des données, et le guide de l'examen la nomme sous six mots : cycles de vie des données, journalisation, résidence, surveillance, observation, rétention.

La gouvernance est le règlement, la sécurité est la serrure

Gardez les deux séparées, parce qu'elles échouent différemment.

La sécurité demande : une partie non autorisée peut-elle atteindre cette donnée ? Elle répond avec IAM, le chiffrement, l'isolation réseau et la détection de menaces. Le topic précédent était presque entièrement de la sécurité.

La gouvernance demande : sous quelles règles cette donnée vit-elle, quel que soit celui qui l'atteint ? Combien de temps peut-on la garder, quels pays peuvent la traiter, pour quels usages est-elle approuvée, qui valide un nouvel usage, et comment le prouver plus tard.

Un jeu de données parfaitement sécurisé peut rester un échec de gouvernance. Personne n'a forcé le log group de l'histoire ci-dessus. Il était autorisé, chiffré, et conservé pour toujours parce que personne n'avait fixé de nombre. La serrure fonctionnait ; il n'y avait pas de règlement.

Cette distinction explique aussi pourquoi les questions de gouvernance sonnent différemment des questions de sécurité à l'examen. Un énoncé de sécurité dit « empêcher l'accès ». Un énoncé de gouvernance dit « ne doit pas être conservé au-delà de », « doit rester à l'intérieur de », « doit pouvoir démontrer ».

Le cycle de vie, et là où l'IA le multiplie

Tout jeu de données traverse les mêmes étapes : il est créé ou acquis, stocké, utilisé, archivé, puis détruit. Les applications traditionnelles gardent ce chemin étroit. Une base, une sauvegarde, une archive.

Les systèmes d'IA l'éclatent. Un seul ticket de support suit ce parcours :

1. Il atterrit en texte brut dans une zone d'atterrissage S3.
2. Il est caviardé et écrit dans une table curée d'un second bucket.
3. Il est découpé et vectorisé dans un vector store pour la récupération.
4. Il entre dans un corpus de fine-tuning, et son contenu influence les poids du modèle.
5. Il apparaît dans un prompt à l'inférence, et le prompt et la réponse atterrissent dans un log.
6. Il est repris dans un jeu d'évaluation pour une revue qualité.

Six emplacements à partir d'un enregistrement, avec des propriétaires différents, des services de stockage différents et des durées de vie naturelles différentes. La question de gouvernance n'est pas « avons-nous une politique de rétention ». Elle est « la politique nomme-t-elle les six ».

Une de ces six étapes n'est pas comme les autres, et c'est celle qu'on oublie. Les étapes 1 à 3, 5 et 6 contiennent de la donnée que vous pouvez supprimer. L'étape 4 non : ce qu'un modèle a appris pendant le fine-tuning ne se retire pas en supprimant un fichier. C'est pour cela que les contrôles avant ingestion du topic précédent sont aussi des contrôles de gouvernance. Tout ce que vous refusez d'entraîner est une copie dont vous n'aurez jamais à rendre compte.

La rétention : le réglage dont la valeur par défaut est « toujours »

La rétention est l'endroit où une politique écrite rencontre une valeur de configuration réelle, et les valeurs par défaut correspondent rarement à ce que la politique dit.

Relisez la ligne CloudWatch Logs. Par défaut, les données de log sont stockées indéfiniment dans CloudWatch Logs. Pour un log applicatif ordinaire, c'est un problème de coût. Pour une application d'IA avec les logs d'invocation de modèle activés, le log group contient les corps complets des requêtes et des réponses, ce qui en fait un stockage permanent de tout ce que les utilisateurs ont tapé dans le modèle et de tout ce que le modèle a répondu. Il hérite de la sensibilité de la conversation, pas de celle d'un log normal.

Un plan de rétention travaillé pour un assistant interne ressemble à ceci :

Remarquez que « supprimer après N jours » et « conserver pendant N ans » utilisent le même outil dans deux directions opposées, et que deux des six lignes ne sont pas du tout une règle de lifecycle. La gouvernance n'est pas une fonctionnalité.

Une correction mérite d'être dite explicitement, parce que c'est une hypothèse fréquente : réduire une période de rétention ne supprime pas la donnée immédiatement. CloudWatch marque les événements expirés pour suppression et termine généralement l'opération sous 72 heures. Si une politique exige une suppression démontrable à une date, intégrez ce délai dans le calcul.

La résidence : où la donnée a le droit d'être

La résidence des données est l'exigence que la donnée soit stockée, et souvent traitée, à l'intérieur d'une géographie nommée. Elle apparaît dans la banque, la santé et le secteur public, et AWS y répond d'abord par le choix de la Région : vous choisissez la Région, vos données y restent tant que vous ne les déplacez pas.

L'IA générative ajoute une subtilité que l'examen apprécie, parce que c'est le seul endroit où un service AWS peut traiter votre requête dans une Région que vous n'avez pas nommée.

L'inférence multi-Région d'Amazon Bedrock route une requête vers la Région d'un ensemble qui a de la capacité, ce qui augmente le débit et absorbe les pics de trafic. Il existe deux types de profile, et un seul respecte une frontière de résidence :

AWS énonce la recommandation clairement : choisissez le géographique quand vous avez des exigences de résidence, le global quand vous cherchez le débit maximal et des économies sans restriction géographique.

Trois détails gardent le sujet honnête. L'inférence multi-Région peut router vers des Régions que vous n'avez pas activées manuellement dans votre compte, donc « nous n'avons jamais ouvert cette Région » n'est pas un contrôle. Tout le trafic reste sur le réseau AWS et est chiffré en transit, donc il s'agit d'une question de juridiction et non d'exposition. Et chaque requête multi-Région est enregistrée dans CloudTrail dans votre Région source, avec un champ additionalEventData.inferenceRegion qui nomme le lieu réel du traitement, ce qui vous permet d'auditer la résidence après coup au lieu de la supposer.

Si votre organisation veut la frontière imposée plutôt que choisie, cela passe par une service control policy sur aws:RequestedRegion au niveau d'AWS Organizations, au-dessus de ce que chaque équipe configure de son côté.

La journalisation : deux traces d'un même appel d'IA

Pour un service AWS classique, « activer la journalisation » veut dire une chose. Pour un appel d'IA générative, cela en veut dire deux, et elles capturent des moitiés différentes.

La conséquence de gouvernance de cette dernière ligne est celle à retenir. Activer les logs d'invocation est le bon choix pour l'auditabilité et l'investigation d'incident, et cela crée un nouveau stockage de vos textes les plus sensibles. Il demande le même traitement que la donnée source : une clé KMS, une policy d'accès serrée, un réglage de rétention, et une place dans votre carte de suppression. Des équipes l'activent pour la conformité et échouent ensuite à un autre contrôle de conformité à cause des logs qu'elles viennent de créer.

Surveillance et observation

Le guide de l'examen liste la surveillance et l'observation comme deux mots distincts, et la séparation est utile même si la frontière est souple.

La surveillance repose sur des seuils et fonctionne automatiquement. Vous définissez ce que « anormal » veut dire sous forme de nombre, et quelque chose alerte quand cela arrive. Pour une charge de travail d'IA : taux d'erreur et throttling des invocations dans CloudWatch, nombre d'interventions des guardrails, coût pour mille invocations, latence au 99e centile, et une règle Config qui passe en non conforme quand quelqu'un désactive les logs d'invocation.

L'observation est le regard continu sur ce que le système fait réellement, y compris ce pour quoi vous n'aviez écrit aucun seuil. Dérive des données et dérive de qualité du modèle avec SageMaker Model Monitor, métriques de biais recalculées sur le trafic réel avec SageMaker Clarify, revue humaine par échantillonnage des sorties, et lecture périodique des prompts que les utilisateurs envoient vraiment. L'observation est ce qui vous apprend que l'assistant sert à quelque chose que personne n'avait prévu, un constat de gouvernance qu'aucune alarme n'était configurée pour attraper.

Les deux comptent, et la raison est propre à l'IA : un système d'IA ne tombe pas proprement. Un serveur web mal configuré renvoie des 500. Un modèle qui dérive renvoie des réponses fluides, bien formées, plausibles, et de moins en moins justes. La surveillance de disponibilité ne verra rien.

La partie qui n'est pas un service

Deux éléments de gouvernance n'ont aucune console AWS, et ce sont les deux premiers.

La classification range chaque jeu de données dans un niveau (public, interne, confidentiel, restreint, par exemple) et attache les règles au niveau plutôt qu'à des buckets individuels. Exigences de chiffrement, Régions approuvées, durées de rétention, et droit d'usage pour l'entraînement dépendent tous de cette seule étiquette. Sans elle, chaque nouveau jeu de données relance la discussion.

La propriété nomme un humain responsable de chaque jeu de données. Le propriétaire de la donnée la classifie, approuve les demandes d'accès et approuve les nouveaux usages, y compris « peut-on faire du fine-tuning là-dessus ». AWS vous donne l'outillage pour enregistrer et appliquer ces décisions, avec les tags, le Glue Data Catalog et les permissions Lake Formation. Il ne peut pas les prendre.

Le tagging est le point de rencontre entre les deux et la machinerie. Un tag cohérent comme DataClassification=Restricted sur les buckets, les log groups et les jobs d'entraînement est ce qui permet à une règle Config de vérifier la conformité par niveau de politique plutôt que par nom de ressource, et ce qui permet de ventiler les rapports de coût et d'accès par sensibilité.

Conseils pour l'examen

• « Gouvernance des données » dans un énoncé pointe vers des règles sur la donnée (rétention, résidence, finalité, propriété), pas vers des contrôles d'accès. Si le scénario dit « empêcher l'accès non autorisé », vous êtes revenu à la sécurité.
• La rétention CloudWatch Logs n'expire jamais par défaut. Ce seul fait répond à plusieurs formes de questions sur des logs qui grossissent sans fin ou qui gardent de la donnée au-delà d'une échéance.
• L'Event history CloudTrail, c'est 90 jours d'événements de management et ce n'est pas configurable. Une rétention plus longue passe par un trail vers S3 ou un event data store CloudTrail Lake.
• Les règles S3 Lifecycle sont le mécanisme à la fois pour déplacer la donnée vers un stockage moins cher et pour la supprimer à date.
• « Les données doivent rester dans l'UE » avec Amazon Bedrock signifie un inference profile géographique, pas global.
• CloudTrail enregistre l'appel ; les logs d'invocation de modèle Bedrock enregistrent le contenu. Une question sur ce que contenait un prompt appelle le second, qui est inactif par défaut.
• Dérive, recalcul de biais et revue humaine échantillonnée relèvent de l'observation. Alarmes et seuils relèvent de la surveillance.

La règle à emporter : la gouvernance est l'ensemble des décisions qui doivent exister avant qu'un contrôle ait quoi que ce soit à appliquer. Durées de rétention, frontières de résidence, classifications et propriétaires sont des entrées, et chaque service de la dernière leçon de ce topic se contente de vérifier que la réalité leur correspond. La leçon suivante traite de l'origine de ces décisions, en commençant par le cadre qu'AWS nomme pour cadrer un cas d'usage d'IA générative.