La dignité des données commence avant le modèle.
Le formulaire posé sur le mauvais bureau
Le débat sur la dignité des données commence souvent trop tard. Il commence après l’entraînement d’un modèle, après que le jeu de données a été collecté, fusionné, filtré, dédupliqué, normalisé, intégré, évalué, empaqueté, déployé et défendu par quelqu’un du service juridique qui n’a pas assez dormi. À ce stade, la conversation prend une tournure morale, ce qui est utile, et aussi légèrement théâtrale, ce qui l’est moins. Les gens demandent si le modèle a respecté les personnes derrière les données. La réponse honnête est généralement que le modèle n’en a jamais eu l’occasion. La décision avait été prise des mois plus tôt, sur un formulaire dont personne ne voulait assumer la responsabilité.
J’ai un jour vu une équipe de recherche en santé faire cette découverte lors d’une réunion censée porter sur la qualité du modèle. Le modèle n’était pas le problème. Le problème était une petite colonne de saisie intitulée réutilisation autorisée. Elle avait trois valeurs possibles : oui, non et vide. Vide signifiait que personne ne savait. Dans le pipeline d’exportation, vide avait été traité comme oui, car sinon l’expérience aurait été gênante. Ce n’était pas de la malveillance. C’était pire pour la gouvernance : c’était une valeur par défaut. Le champ le plus discret du tableur avait plus d’autorité que le comité d’éthique.
L’équipe pouvait réentraîner, s’excuser, documenter et s’améliorer. Mais le problème de dignité ne commençait pas dans le réseau de neurones. Il commençait lorsqu’un enregistrement arrivait sans objectif clair, sans responsable attitré, sans règle de conservation, sans moyen de préserver le retrait, et sans contrat technique qui refuse l’incertitude. Le modèle ne faisait que rendre plus rapide le manque de respect antérieur. On reproche souvent aux machines d’être froides, mais beaucoup des choix les plus froids sont faits par des humains chaleureux qui cliquent sur importer.
La dignité des données commence avant le modèle, car les données deviennent politiques au moment où elles sont collectées. Un enregistrement n’est pas seulement une ligne. C’est un fragment d’une personne, d’une entreprise, d’une communauté, d’un lieu de travail, d’un parcours de patient, d’un service public, d’un environnement de capteurs ou d’un jugement professionnel. Traiter ce fragment avec dignité ne consiste pas à l’envelopper d’un langage sentimental. Il s’agit de conserver autour de lui suffisamment de vérité pour que les systèmes ultérieurs ne puissent pas prétendre qu’il est apparu de nulle part.
Le consentement n’est pas un parfum
De nombreuses organisations traitent le consentement comme un parfum agréable ajouté à un processus une fois le gros du travail terminé. Un paragraphe est placé dans une politique. Une case à cocher est ajoutée à un portail. Une ligne dans le registre mentionne un intérêt légitime. Tout le monde se détend, du moins jusqu'à ce que quelqu'un demande ce que le modèle était réellement autorisé à apprendre. Puis la salle découvre que le langage juridique et l'autorisation opérationnelle sont liés de la même manière qu'un menu est lié au dîner. L'un est une promesse. L'autre doit être cuisiné.
Le consentement opérationnel a une structure. Il précise quelle finalité est autorisée, quels acteurs peuvent traiter le dossier, quelles transformations sont permises, quels dérivés héritent de la limite, combien de temps le dossier peut vivre, comment le retrait est géré, et quelle preuve atteste du choix ultérieurement. Si ces éléments ne sont pas suffisamment lisibles par machine pour influencer le pipeline, ils ne constituent pas un consentement dans un système d'IA. Ce sont des documents à thème de consentement. La documentation a sa place, mais on ne devrait pas lui demander d'arrêter un traitement par lots par la force morale.
Cela devient particulièrement important lorsque les données passent de leur finalité première à l'entraînement, à la récupération, à l'évaluation, à la surveillance ou à l'analyse de produits. Une plainte soumise à une municipalité peut être utile pour améliorer un classifieur. Une note clinique peut être utile pour extraire des symptômes. Une transcription de support client peut être utile pour un chatbot. L'utilité ne crée pas la dignité. Elle crée la tentation. La question de la dignité est de savoir si la nouvelle finalité a été déclarée, si les personnes et les institutions concernées pouvaient raisonnablement s'y attendre, et si le système peut faire respecter la réponse lorsque les données deviennent pratiques.
Le consentement vieillit également. Un dossier collecté il y a cinq ans peut avoir été créé sous des hypothèses qui ne correspondent plus à la pratique actuelle. Une personne peut s'être rétractée. Un contrat peut avoir expiré. Un accord de partage de données peut avoir autorisé l'analyse mais pas l'entraînement du modèle. Un champ peut avoir été anonymisé suffisamment pour un rapport, mais pas assez pour un index d'incorporation qui peut être interrogé toute la journée par des employés créatifs. Une ancienne permission ne devrait pas être traitée comme un pot de confiture au fond du placard. La date compte.
Le contexte est une propriété technique
Il existe une habitude paresseuse de séparer les données du contexte, comme si le contexte était mou et les données dures. Dans les systèmes réels, c'est souvent l'inverse qui est vrai. La valeur des données peut être un nombre, un code, un nom, un horodatage ou un champ de texte. Sa signification dépend de la méthode de collecte, de l'unité, de la portée, de l'incertitude, de l'autorité de la source, des règles d'exclusion, de la langue, des valeurs manquantes et de la situation dans laquelle elle a été enregistrée. Retirez tout cela et les données ne deviennent pas neutres. Elles deviennent trop confiantes.
Une lecture de capteur provenant d'un pont n'est pas seulement une vibration. C'est une vibration provenant d'un appareil spécifique, calibré à une date précise, monté à un endroit précis, mesuré dans des conditions météorologiques spécifiques, échantillonné à une fréquence spécifique et interprété par rapport à un historique de maintenance. Un enregistrement de paiement n'est pas seulement un montant. Il s'inscrit dans un contrat, un processus de règlement, un modèle de fraude, une convention monétaire et une habitude humaine de saisir des virgules là où les décimales voulaient vivre. Le modèle peut ne voir que des jetons ou des vecteurs, mais l'institution reste responsable des noms manquants.
La dignité des données exige donc la préservation du contexte comme exigence d'ingénierie. Les descriptions de schéma doivent être versionnées. Les systèmes sources doivent être nommés. Les transformations doivent être enregistrées. Les valeurs manquantes doivent être distinguées des zéros, des refus, des inconnues et des états non applicables. Les étiquettes doivent indiquer qui les a posées, selon quelle directive et avec quel désaccord. Les exemples d'évaluation doivent indiquer pourquoi ils ont été sélectionnés. Un ensemble de données sans contexte n'est pas une matière première. C'est une rumeur sous forme de tableau.
Ceci n'est pas un plaidoyer pour des métadonnées à l'infini. Les métadonnées à l'infini, c'est ainsi que les bonnes idées partent finir leur retraite dans un catalogue que personne n'ouvre. L'enjeu, ce sont des métadonnées sélectives et opérationnelles : le contexte nécessaire pour décider si l'enregistrement peut être utilisé, s'il signifie encore ce que le système pense qu'il signifie, et si une personne ultérieure peut contester le résultat. La dignité n'exige pas tous les faits concernant l'enregistrement. Elle exige les faits qui empêchent l'enregistrement de devenir un étranger à lui-même.
La dette de dignité
La dette technique est familière parce que les ingénieurs la voient dans les builds, les incidents, les changements lents et les petites malédictions tapées dans les messages de commit. La dette de dignité des données est plus silencieuse. Elle s'accumule lorsque l'origine est floue, que la permission est ambiguë, que le contexte est abandonné, que la rétention est ignorée, que les étiquettes ne sont pas documentées, que l'accès est trop large, ou que les données dérivées sont traitées comme inoffensives parce qu'elles ne ressemblent plus à la source. La dette peut ne pas faire échouer un test. Elle attend une réclamation, un audit, un litige, une sortie nuisible ou un journaliste patient.
Ce qui est dangereux avec la dette de dignité, c'est qu'elle se compose par l'utilité. Un ensemble de données pratique est copié. Un ensemble copié devient un feature store. Le feature store alimente un modèle. La sortie du modèle devient un enregistrement. L'enregistrement devient un retour d'apprentissage. Chaque étape semble pragmatique. Chaque étape rend aussi plus difficile de répondre à la question initiale : qu'avions-nous le droit de faire avec ces données, et que devions-nous aux personnes derrière elles. Au moment où la question atteint la direction, la réponse a été répartie sur huit systèmes et une personne qui a changé de département.
Les équipes sérieuses traitent la dette de dignité comme tout autre risque opérationnel. Elles l'enregistrent, la chiffrent, désignent des responsables et décident quelles utilisations sont bloquées jusqu'à ce que la dette soit remboursée. Si un ensemble de données ne peut pas prouver son origine, il ne devrait pas entrer dans un entraînement à fort impact. Si le retrait ne peut pas être propagé, l'utilisation devrait être limitée. Si les artefacts dérivés ne peuvent pas être tracés, le modèle ne devrait pas soutenir des décisions importantes. Si les étiquettes ont été produites sous de mauvaises directives, l'évaluation ne devrait pas être utilisée comme un certificat d'équité. C'est ennuyeux de la meilleure des façons. L'ennui, c'est ainsi que les adultes maintiennent les ponts debout.
Il y a une tentation de résoudre la dette de dignité avec une grande plateforme. Les plateformes peuvent aider, mais le premier geste est généralement plus petit et plus discipliné : refuser les inconnues à l'entrée, séparer la finalité du stockage, enregistrer la lignée aux frontières de transformation, maintenir les droits attachés aux dérivés et rendre la suppression testable. Un système qui ne peut pas supprimer avec confiance ne peut pas honnêtement prétendre avoir respecté le retrait. Il ne peut que prétendre qu'il espère que les données sont devenues timides.
Les données dérivées restent des données
L’IA rend la dignité des données plus difficile à préserver, car elle crée des dérivés qui semblent anodins. Un document devient un fragment. Un fragment devient un plongement vectoriel. Une conversation d’assistance devient un résumé. Une note clinique devient une étiquette. Une requête de recherche devient un événement d’analyse. Une réponse de modèle devient un nouvel enregistrement. Une correction humaine devient une donnée de renforcement. Chaque artefact peut perdre la forme de l’original tout en conservant assez de sens pour avoir de l’importance. Le masque change. L’obligation, elle, peut demeurer.
Les plongements vectoriels sont un exemple utile, car ils sont faciles à mal comprendre. Comme ils ne sont pas un texte lisible, on les traite comme si la dignité s’était évaporée. Pourtant, un plongement vectoriel peut encore révéler des similarités, des appartenances, des regroupements sensibles ou un contexte commercial. Il peut aider à reconstruire ou à déduire des faits. Il peut porter les conséquences d’étiquettes biaisées. Il peut persister après la suppression de la source. L’appeler un vecteur ne le rend pas socialement sans poids. Beaucoup de choses dans la vie semblent inoffensives lorsqu’elles sont écrites en décimales. Les soldes bancaires, par exemple.
Les données dérivées ont besoin de règles d’héritage. Quelles obligations suivent de la source vers le fragment, le vecteur, le cache, le résumé, la caractéristique, le journal de requêtes, l’échantillon d’évaluation et la sortie du modèle. Quels dérivés doivent être supprimés lorsque la source est supprimée. Lesquels peuvent être conservés parce qu’ils sont suffisamment agrégés ou juridiquement indépendants. Lesquels nécessitent un consentement distinct. Lesquels sont des enregistrements à part entière. Sans héritage, chaque système en aval improvise sa propre dignité. L’improvisation est charmante dans le jazz. En matière de gouvernance des données, elle produit souvent des comptes rendus de réunion.
Ces règles d’héritage devraient être conçues avant la collecte, et non après le premier lancement d’un modèle. Il ne s’agit pas de figer l’innovation, mais de lui donner un socle. Les ingénieurs peuvent construire plus vite lorsqu’ils savent quels dérivés sont autorisés, quelles limites exigent un examen et quelles métadonnées doivent voyager avec les données. Les chercheurs peuvent explorer sans transformer chaque expérience en séance de spiritisme juridique. Les utilisateurs et les personnes concernées en retirent un bénéfice plus important : l’institution peut expliquer ce qui est arrivé à leurs données sans consulter le folklore.
Le modèle est un témoin tardif
Lorsqu’un système d’IA se comporte mal, l’enquête se tourne souvent d’abord vers le modèle. C’est compréhensible. Le modèle est visible, coûteux et confiant à tort d’une manière qui fait de bonnes captures d’écran. Mais le modèle est souvent un témoin tardif de décisions antérieures. Il reflète les choix de collecte, d’étiquetage, d’exclusion, de nettoyage, de conservation et d’évaluation. Ne demander qu’au modèle de devenir digne, c’est comme demander à la dernière personne d’une course de relais d’améliorer le témoin.
Les model cards, les audits, les évaluations, les exercices d'équipe rouge et les outils d'explicabilité comptent tous. Ils font partie de l'histoire de la dignité, surtout lorsque les systèmes touchent des personnes. Mais ils ne peuvent pas récupérer une autorisation qui n'a jamais été recueillie, un contexte qui a été écarté ou une traçabilité qui n'a pas été journalisée. Ils peuvent révéler l'écart. Ils ne peuvent pas rendre cet écart moralement acceptable. C'est pourquoi les contrôles précoces ne sont pas de la bureaucratie. Ce sont les conditions qui rendent la responsabilité ultérieure plus qu'une simple formalité.
Il en va de même pour l'équité. Un examen d'équité après l'entraînement peut détecter des taux d'erreur inégaux, des groupes manquants, des variables proxy ou des seuils préjudiciables. Il ne peut pas toujours déterminer si le jeu de données a exclu des personnes lors de la collecte, si les étiquettes ont capturé un préjugé institutionnel, si un champ signifiait la même chose d'un site à l'autre, ou si une règle de consentement a filtré l'échantillon d'une manière qui a modifié la population. L'équité sans dignité des données, c'est travailler avec un miroir qui a peut-être été déformé à la fabrication.
Il y a aussi un avantage pratique à commencer tôt : plus une règle de dignité entre tôt dans le pipeline, moins elle coûte cher à appliquer. Un enregistrement refusé à l'entrée coûte peu. Un jeu de données mis en quarantaine avant l'entraînement coûte plus cher. Un modèle retiré de la production coûte beaucoup plus cher. Une perte publique de confiance coûte le montant que la finance inscrit après que tout le monde cesse de prétendre qu'il ne s'agit que de communication. La dignité est souvent décrite comme un coût éthique. Dans les systèmes sérieux, elle coûte moins cher que le nettoyage.
L'intendance est un vrai métier
La dignité des données a besoin d'intendants, pas de mascottes. Un intendant n'est pas la personne dont le nom apparaît sur une diapositive pour donner un visage humain au diagramme de gouvernance. Un intendant a l'autorité de décider si un jeu de données peut être utilisé, de bloquer un usage risqué, d'exiger des métadonnées, d'approuver la conservation, de gérer le retrait et d'expliquer une décision aux auditeurs et aux personnes concernées. Sans autorité, l'intendance devient décorative. La gouvernance décorative est facile à repérer : elle comporte de nombreux comités et très peu de verbes.
L'intendant a aussi besoin de leviers techniques. Il lui faut des tableaux de bord qui montrent la traçabilité et l'usage, pas seulement le volume de stockage. Il lui faut des alertes lorsqu'un jeu de données est réutilisé en dehors de son objectif. Il lui faut des contrats avec les équipes d'ingénierie sur les métadonnées requises. Il lui faut un chemin de suppression qui a été testé. Il lui faut un moyen de signaler l'incertitude sans regarder le pipeline la transformer silencieusement en oui. Il lui faut un budget suffisant pour corriger la dette de dignité avant qu'elle ne fasse la une. C'est un travail, pas une étiquette de vertu.
Une bonne intendance est collaborative. Le juridique comprend l'autorité. La sécurité comprend l'accès. Les ingénieurs de données comprennent les flux. Les experts métier comprennent le sens. Les équipes produit comprennent l'usage prévu. Les chercheurs comprennent l'incertitude. Les opérations comprennent ce qui se passe à trois heures du matin. La dignité des données échoue lorsque l'une de ces perspectives est déclarée propriétaire de tout le problème et que tous les autres retournent à leurs tableaux de bord. Le dossier traverse les fonctions ; la responsabilité doit faire de même.
Il y a une humilité humaine dans tout cela. La dignité des données n'exige pas qu'une organisation sache tout. Elle exige que l'organisation sache ce qu'elle sait, ce qu'elle ne sait pas, qui peut décider et où les limites sont appliquées. C'est moins glamour qu'un support de stratégie sur l'IA responsable. C'est aussi plus susceptible de survivre au contact avec un véritable travail d'importation.
Ce que la dignité signifie concrètement dans l'infrastructure
L'infrastructure de la dignité des données n'a rien de mystique. Elle se compose de registres de sources, d'étiquettes d'objectif, d'états de consentement, de contrats de données, d'événements de lignage, de périmètres d'accès, de tâches de conservation, de preuves de suppression, de directives d'étiquetage, de versions de jeux de données, de registres d'évaluation et de files de relecture. Si cette liste semble banale, tant mieux. Les systèmes éthiques les plus fiables ressemblent souvent à de la plomberie. On ne les remarque que lorsque quelqu'un a oublié de les installer.
À la collecte, un enregistrement doit arriver avec une source déclarée, un objectif, une base légale ou un état d'autorisation, une classe de sensibilité et un steward. Lors de la transformation, le système doit émettre des événements de lignage et préserver les limites pertinentes. Lors de l'utilisation, l'environnement d'exécution doit vérifier que l'objectif correspond. Au stockage, la conservation et la suppression doivent être exécutables, pas seulement théoriques. À l'évaluation, les exemples doivent porter leur origine et leur logique de sélection. À la relecture, les personnes concernées et les opérateurs internes doivent disposer d'un moyen de contester un usage abusif. Rien de tout cela n'exige de prétendre que toutes les données sont sacrées. Cela exige d'admettre que les données ont une vie.
La décision de conception la plus importante est de faire de l'inconnu un état de première classe. Inconnu ne veut pas dire oui. Inconnu ne veut pas dire inoffensif. Inconnu est un signal pour demander, mettre en quarantaine, limiter ou refuser. De nombreux échecs de dignité surviennent parce que les systèmes sont allergiques à l'incertitude. Ils préfèrent un booléen net même lorsque le monde réel n'en a pas fourni un. C'est ainsi que des cellules vides deviennent des autorisations. Un système digne laisse l'incertitude ralentir les choses. La machine s'en sortira. Elle n'a pas été invitée à déjeuner pour ses sentiments.
Il n'existe pas d'architecture de dignité parfaite. Il existe de meilleurs défauts et de pires défauts. Les meilleurs défauts gardent le contexte proche, propagent les limites, enregistrent les mouvements, exigent une utilisation secondaire explicite et rendent le retour en arrière possible. Les pires défauts aplatissent l'objectif, copient librement, font confiance à tout le monde, ne suppriment que sur le papier et découvrent leurs obligations quand le calendrier d'audit le décide. Le choix n'est pas entre innovation et dignité. Le choix est entre des systèmes qui se souviennent de ce qu'ils doivent et des systèmes qui espèrent que personne ne posera de questions.
La leçon
La dignité des données est souvent présentée comme un grand principe, mais elle devient réelle dans de petites décisions techniques prises avant l'apparition du modèle. Ce qui doit être connu à la collecte. Quels inconnus arrêtent le flux. Quels droits accompagnent les dérivés. Quels contextes sont préservés. Quels objectifs sont autorisés. Quels stewards peuvent dire non. Quelles suppressions peuvent être prouvées. Ces choix déterminent si un modèle ultérieur peut être responsable ou simplement éloquent.
La voie du respect n’est ni contre les données, ni contre l’IA. Elle est pour la mémoire. Elle exige que les enregistrements portent suffisamment d’origine, de permission, de contexte et d’obligation pour rester liés aux personnes et aux institutions qui les ont produits. Un modèle entraîné sur de telles données a plus de chances d’être utile sans devenir extractif par accident. Un modèle entraîné sans ces fondations peut encore impressionner. Tout comme un bâtiment sans fondations impressionne pendant une courte période excitante.
Commencez avant le modèle. Commencez par le formulaire, le contrat, le schéma, l’état de consentement, la directive d’étiquetage, la règle de conservation, la politique de dérivation et l’intendant disposant d’une autorité réelle. C’est là que la dignité entre dans le système. Tout ce qui suit n’est que préservation ou contrôle des dégâts.