IA encadrée
Un modèle hérite de toutes les obligations de vos données
Ajouter une fonction d'IA ne crée pas un nouveau régime de conformité. Cela déplace des données personnelles dans un composant plus difficile à inspecter, et les obligations suivent.
La question qui bloque les fonctions d'IA dans les organisations régulées est rarement « est-ce que ça marche ». C'est « que se passe-t-il quand quelqu'un demande l'effacement de ses données, et qu'une partie est passée dans un prompt il y a huit mois ».
Cette question a une réponse. Elle est simplement plus facile à donner quand on a conçu pour elle que quand on la reconstitue sous contrainte de calendrier.
La frontière est là où la donnée sort de votre contrôle
Tracez une ligne : le point où une donnée personnelle passe dans quelque chose que vous ne pouvez plus inspecter après coup. Un modèle hébergé est de l'autre côté. Un magasin de vecteurs que vous n'avez pas configuré aussi. Un pipeline de logs qui capture les corps de requête complets également.
Tout ce qui est de l'autre côté demande une réponse à quatre questions :
- Ce qui est envoyé — la liste des champs, pas « le contexte de l'utilisateur »
- Où c'est traité — juridiction, et sous quel contrat
- Combien de temps c'est conservé — chez eux, pas chez vous
- Ce qui se passe à l'effacement — y compris pour tout ce qui en est dérivé
Si une question n'a pas de réponse, c'est ça, le constat. Notez-le comme un manque, pas comme un risque à évaluer plus tard.
La recherche vectorielle est une copie, et une copie a sa propre durée de vie
Ce que les équipes sous-estiment le plus systématiquement, c'est la partie récupération. Un document indexé en embeddings est une copie dérivée. Supprimer la ligne source ne supprime pas le vecteur, et un vecteur qui renvoie toujours les bons voisins porte toujours l'information — ce qu'un régulateur appelle précisément une donnée personnelle.
Le motif qui fonctionne est ennuyeux :
- Indexer par référence et jamais par valeur, pour que le fragment porte un identifiant et non le texte
- Reconstruire plutôt que corriger quand la source change, parce qu'une mise à jour partielle laisse des orphelins
- Donner à l'index la même horloge de rétention que la source, appliquée par le même job
Les jeux d'évaluation sont aussi des données personnelles
Une suite de tests constituée à partir de vraies conversations est un jeu de données de vraies personnes, posé dans un dépôt, copié sur chaque poste qui le clone. Il demande le même traitement que la production, ou il doit être synthétique. Choisissez délibérément ; l'accident, c'est de ne choisir ni l'un ni l'autre.
Ce qu'il faut écrire avant le premier prompt en production
| Question | Où ça se range |
|---|---|
| Quels champs atteignent le modèle | Cartographie des flux |
| Quel sous-traitant, sous quelles conditions | Registre des traitements |
| Rétention de leur côté | Contrat, puis registre |
| Chemin d'effacement, copies dérivées comprises | Runbook, testé |
| Ce que coûte une mauvaise réponse | Analyse de risque |
Rien de tout cela ne ralentit une bonne fonctionnalité. Cela ralentit celle qui allait être arrêtée en revue de toute façon — et la ralentit plus tôt, quand changer la conception coûte encore peu.
À lire ensuite
- Des contrats d’événements entre contextes bornés
Deux équipes s'accordent sur un payload, livrent, et découvrent six mois plus tard qu'elles ne s'étaient jamais accordées sur son sens. Le schéma n'a jamais été le contrat.
- Des runbooks qui survivent aux réorganisations
La documentation d'exploitation est presque toujours écrite pour qui sait déjà. Écrivez-la pour le troisième lecteur : celui qui arrive à 3 h du matin, dans dix-huit mois.