L'IA a besoin de moins de magie et de plus de responsabilité.
The answer that arrived without luggage
The first answer looked impressive. It summarised a long case file, identified the likely policy route, drafted a reply, and sounded as if it had spent the morning in a tidy office with a clean conscience. The manager liked it. The reviewer liked it less. She asked where the source paragraph came from, which version of the policy was used, whether the customer note was visible to the model, and why the recommendation skipped an exception that usually mattered. The room had the answer. It did not have its luggage.
That missing luggage is the problem. The AI output had travelled through prompts, retrieval, ranking, model inference, post-processing, and a user interface. Along the way it touched documents, access rights, cached snippets, tool permissions, system instructions, and a human workflow. By the time the answer reached the screen, most of that journey was invisible. The organisation could admire the result, but it could not properly hold it. It could not say which facts were carried, which were excluded, which rule bound the output, which person accepted it, or which record would survive the meeting.
This is why AI needs less magic and more custody. Magic thinking treats the model as the event. A question goes in, intelligence happens, an answer comes out. Custody thinking treats the model as one handler in a chain. The chain has inputs, rights, transformations, responsibilities, storage decisions, and exits. It asks who is allowed to hold something, for what purpose, under which constraints, for how long, with what proof, and with what remedy when the chain breaks.
Custody is not a colder word for control. It is care with a receipt. A museum does not own every object it safeguards. A records office does not invent every record it preserves. A laboratory does not make a sample more true by labelling it, but the label decides whether the result can be trusted later. AI systems need the same adult habits. They handle other people's data, institutional authority, model outputs, and decisions that may outlive the interface. A little less sparkle, a little more chain of custody. It will not make a better keynote. It will make a better system.
Magic is an expensive operating model
La magie séduit parce qu'elle supprime les frictions de l'histoire. Un flux de travail difficile devient une invite. Une base de connaissances faible devient un problème de capacité du modèle. Un responsable manquant devient une automatisation. Une règle floue devient une consigne de prudence. Le système semble fonctionner parce que le modèle produit un langage fluide là où un logiciel ordinaire buterait. La fluidité est utile. Elle est aussi une habile dissimulatrice de gouvernance inachevée.
Dans les opérations ordinaires, les lacunes ont des bords. Un champ manquant fait échouer un formulaire. Un code erroné échoue à la validation. Une erreur d'autorisation bloque l'accès. Dans les opérations d'IA, la lacune peut être convertie en prose. Le modèle peut répondre en contournant des preuves manquantes, déduire l'intention d'un langage ambigu, atténuer les contradictions et renvoyer un paragraphe qui semble complet. C'est puissant lorsque la tâche est à faible risque et que l'utilisateur peut juger. C'est dangereux lorsque le paragraphe devient une surface de décision, un enregistrement d'audit, une promesse client, une note clinique, une recommandation juridique ou une voie d'accès à un outil.
La magie est aussi coûteuse parce qu'elle reporte la responsabilité. Si personne ne sait quelle source a été utilisée, le coût apparaît lors de la correction. Si personne ne sait quelle version d'invite a façonné une réponse, le coût apparaît lors de l'évaluation. Si personne ne sait quel appel d'outil a modifié l'état, le coût apparaît lors de la réponse à incident. Si personne ne sait quelles données dérivées ont été conservées, le coût apparaît lors de la suppression, de la divulgation ou du litige. Le modèle était rapide. L'organisation devient lente plus tard, généralement avec plus de monde dans la salle et un café pire.
La garde rend les coûts cachés visibles plus tôt. Elle exige que le système sache ce qu'il détient. Elle exige de lier les données à leur finalité. Elle exige de préserver les preuves sans tout accumuler. Elle exige de séparer le brouillon de la décision. Elle exige d'enregistrer qui a diffusé un résultat dans le monde. Elle exige de savoir corriger ou retirer les artefacts. Cela semble ennuyeux parce que c'est ce qui empêche le glamour de devenir un passif. Il y a pire que l'ennui. L'une de ces choses est une réponse assurée que personne ne peut retracer.
La garde des données n'est pas un théâtre de la propriété des données
De nombreuses organisations parlent de posséder leurs données. La propriété n'est pas inutile, mais elle est trop grossière pour la gouvernance de l'IA. Une équipe peut posséder un ensemble de données et avoir une mauvaise garde. Elle peut ne pas savoir où se trouvent les copies, quels embeddings ont été dérivés, quelles invites contenaient des extraits sensibles, quels résumés subsistent dans les notes de cas, quels journaux contiennent des données personnelles, ou quel résultat de modèle en aval porte désormais un fait provenant d'une source corrigée ultérieurement. La propriété dit à qui appartient l'actif. La garde demande ce qui lui est arrivé.
L'IA crée plus d'objets sous garde que les applications traditionnelles. Il y a le document original. Il y a les morceaux analysés. Il y a les embeddings. Il y a les extraits récupérés. Il y a les assemblages d'invites. Il y a les brouillons générés. Il y a les modifications des relecteurs. Il y a les arguments d'appels d'outil. Il y a les explications, les scores, les classifications et les événements d'audit. Certains sont temporaires. Certains deviennent des enregistrements. Certains doivent être supprimés rapidement. Certains doivent être conservés. Certains doivent être séparés du chemin de service du modèle. Traiter tout cela comme un seul bloc appelé données est un moyen commode de perdre le contrôle poliment.
Une bonne garde distingue la possession, l'utilisation, la dérivation, la publication et la conservation. Un système peut posséder un enregistrement sans l'utiliser à une fin. Il peut utiliser une source pour la récupération sans stocker l'extrait dans le résultat. Il peut générer un résumé mais le marquer comme non faisant autorité. Il peut publier une réponse finale tout en ne conservant que des identifiants et des hachages comme preuve. Il peut maintenir une piste d'audit sous accès restreint tout en supprimant le contexte de travail. Ces distinctions ne sont pas une décoration juridique. C'est ainsi que les systèmes d'IA restent responsables sans devenir des machines de surveillance avec une meilleure typographie.
La difficulté tient à ce que la garde franchit les frontières organisationnelles. Les propriétaires de données, les équipes de modèles, les équipes de plateforme, les équipes juridiques, les opérateurs, les fournisseurs et les auditeurs touchent tous des morceaux de la chaîne. Si la garde ne vit que dans la documentation d'une seule équipe, elle échouera au moment de la passation. Le registre doit comporter des identifiants partagés, des définitions de rôles, des règles de conservation et des chemins de preuve qui survivent aux frontières entre équipes. Sinon, chaque incident devient une chasse au trésor avec invitations à des réunions de calendrier.
Les prompts ont aussi besoin d'une garde
Les prompts sont souvent traités comme du texte jetable, quelque part entre la configuration et les commérages de bureau. C'est compréhensible dans les expérimentations. C'est dangereux en production. Un prompt peut contenir des interprétations de politiques, des exemples cachés, des règles de ton, des conditions de refus, des permissions d'outils, une logique d'escalade et un contexte sensible. Il peut changer la façon dont un modèle utilise les preuves. Il peut changer si une sortie semble hésitante ou définitive. Il peut changer si un réviseur humain voit l'incertitude. Un prompt n'est pas seulement une formulation. C'est une instruction opérationnelle.
La garde des prompts signifie versionner les prompts, nommer leur objectif, enregistrer quelles sorties ils ont façonnées, restreindre qui peut les modifier, tester les changements sur des cas connus et préserver suffisamment d'historique pour expliquer les comportements passés. Cela signifie aussi séparer la politique durable de la formulation du prompt. Si une règle métier n'existe qu'à l'intérieur d'un prompt, l'organisation a transformé la gouvernance en un paragraphe doté de droits de déploiement. Les paragraphes sont utiles. Ce n'est pas un endroit merveilleux pour cacher l'autorité.
La garde des prompts exige également de l'humilité face aux fuites et aux dérives de prompts. Un prompt peut être copié dans un ticket, modifié par une équipe bien intentionnée, intégré dans un paramètre de fournisseur ou corrigé à la hâte pendant un incident. De petits changements peuvent altérer le refus, le ton, l'utilisation des sources et les appels d'outils. Sans garde, l'organisation ne peut pas dire si un modèle a empiré, si une source a changé ou si une instruction a bougé. Elle accomplira alors le rituel traditionnel consistant à débattre des impressions pendant que la cause racine attend dehors.
Cela ne signifie pas que chaque modification de prompt nécessite un comité. La gouvernance doit correspondre au risque. Une aide à la rédaction à faible risque peut avoir des contrôles plus légers qu'un prompt qui façonne des recommandations d'éligibilité. Mais même les contrôles légers ont besoin d'un registre. Qui l'a modifié. Pourquoi. Quels tests ont été exécutés. Quelle voie l'utilise. Quand doit-il être révisé. La garde des prompts n'est pas de la bureaucratie pour elle-même. C'est la différence entre l'apprentissage opérationnel et l'archéologie des prompts.
Les outils transforment la garde en action
The custody question becomes sharper when models can call tools. A generated paragraph may mislead. A tool call can change the world. It can update a record, send an email, create a ticket, approve a transaction, unlock access, delete content, or trigger a workflow. Once a model crosses from suggestion into action, custody must include permissions, argument validation, state transitions, idempotency, receipts, and rollback. The model output is no longer only content. It is a proposed act.
Tool custody starts with narrow authority. A model should not receive broad write access because a prompt says it will behave. The gateway should know which tool may be called, by whom, for which task, with which arguments, under which evidence conditions. Some calls should require human approval. Some should be read-only. Some should be impossible. A typed tool boundary is less glamorous than a demonstration of autonomous work. It is also much easier to explain to a regulator, a customer, or a tired engineer at 02:00.
Tool custody also means the system can reconstruct what happened. Which output proposed the call. Which evidence supported it. Which user or role approved it. Which state changed. Which external system acknowledged it. Which compensating action exists if it was wrong. Without this record, autonomous action becomes institutional memory loss at machine speed. The action happened. The explanation becomes a group project.
There is a simple rule worth keeping: the more an AI system can change, the stronger custody must become. Drafting a paragraph needs source and prompt custody. Ranking a queue needs data, policy, and appeal custody. Calling a write tool needs transaction custody. Affecting rights, money, health, access, or safety needs serious custody across the full chain. The word autonomy should not be allowed to float above these differences like a balloon at a procurement fair.
Retention is part of intelligence
AI teams often focus on what systems know. Custody also asks what systems should forget. Retention is not an administrative afterthought. It shapes risk, accountability, privacy, and learning. If working context is deleted too quickly, the organisation cannot explain decisions. If it is kept too long, the organisation accumulates sensitive material with no living purpose. If derived artefacts are not tracked, deletion becomes theatre. If final records lack provenance, preservation becomes a drawer of confident fragments.
The right retention design separates layers. Raw prompts may be short-lived or redacted. Source identifiers may be preserved longer than source text. Final decision records may be retained under statutory rules. Audit hashes may survive content deletion. Evaluation examples may be anonymised. Tool receipts may need transaction-level retention. The design depends on risk and purpose. The important point is that retention should be intentional, not whatever the logging system happened to do on launch day.
For AI, forgetting is technically awkward because facts can be copied into summaries, embeddings, caches, tickets, screenshots, exports, and training sets. Custody does not solve this by pretending deletion is easy. It solves it by knowing where derived artefacts are created, which ones carry personal or sensitive content, how they can be invalidated, and which records must show that invalidation occurred. The phrase delete the data is not a plan. It is an opening sentence.
There is also a learning tension. Organisations want to keep examples to improve the system. People have rights to correction, erasure, confidentiality, and fair treatment. Custody is how these interests are negotiated without hand-waving. Keep enough to learn and account. Strip or separate what is not needed. Preserve proof of correction. Retire stale examples. Do not train on material just because it was lying around looking educational. That last habit has caused more governance problems than many strategy documents will ever admit.
Custody makes humans more than rubber stamps
Human oversight is weak when humans receive an answer without custody context. A reviewer sees polished text and a green confidence indicator. She does not see source freshness, excluded documents, prompt version, retrieval conflict, tool authority, or previous corrections. She is asked to approve the answer, but not given the chain. That is not oversight. It is ceremony with a button.
Custody gives humans the materials needed for judgement. It shows what the system used, what it did not use, what it was allowed to do, what uncertainty remains, what action is proposed, and what will be recorded if the human approves. It lets the reviewer disagree in a way the system can learn from. It lets a supervisor inspect patterns. It lets an affected person challenge an outcome. It lets an auditor reconstruct behaviour without interviewing half the organisation and one retired consultant.
It also protects humans from being blamed for system ambiguity. If a reviewer approved an output without source access because the interface hid it, that is a design failure. If a team trusted a model because the system labelled a draft as ready, that is a custody failure. If an operator could not delete derived material because nobody tracked it, that is not an operator's moral weakness. Custody assigns responsibility to the chain, not only to the nearest person holding the result when something goes wrong.
Good custody therefore makes human authority more real. It does not bury people in logs. It packages evidence at the right level. A frontline user may need source names, freshness, and refusal reason. A specialist may need deeper trace. An auditor may need signed records. A data protection officer may need retention and access history. Custody is layered because responsibility is layered. Throwing all logs at everyone is not transparency. It is document confetti.
Custody is an operating loop
Custody is not a one-time architecture diagram. It is a loop. A new use case is classified. The data and artefacts it will handle are named. Rights and purposes are bound. The system runs inside those limits. Outputs and actions are attested. Exceptions are reviewed. Corrections update the chain. Artefacts are retained, redacted, or retired. The loop repeats when policy, models, suppliers, data, or work changes.
Cette boucle compte parce que les systèmes d'IA évoluent. Une version de modèle change. Un index de récupération est reconstruit. Une politique est mise à jour. Un fournisseur modifie les paramètres de conservation. Une nouvelle équipe copie un prompt. Un outil obtient une nouvelle permission. Un assistant à faible risque intègre un flux de décision. Sans boucle de garde, chaque changement devient une petite évasion non enregistrée. Après un an, l'organisation dispose d'un système qui fonctionne encore mais ne correspond plus au récit de gouvernance. C'est courant. Ce n'est pas non plus une fatalité.
Exploiter la garde exige des responsables. Quelqu'un possède l'autorité de la source. Quelqu'un possède les versions de prompts. Quelqu'un possède l'approbation des modèles. Quelqu'un possède les passerelles d'outils. Quelqu'un possède les enregistrements et la conservation. Quelqu'un possède les voies de correction. Ces responsables ne doivent pas nécessairement se trouver dans un même service, mais leurs responsabilités doivent se rejoindre. Sinon, la garde devient un organigramme mural avec des flèches pointant vers le brouillard, un genre déjà surreprésenté dans la transformation numérique.
La leçon
L'IA a besoin de moins de magie et de plus de garde, car les organisations ne gouvernent pas l'émerveillement. Elles gouvernent les enregistrements, les droits, les outils, les personnes, les finalités et les changements. Le modèle peut être remarquable, mais l'institution reste responsable de ce que le système a détenu, transformé, publié, stocké, corrigé et oublié. Traiter la réponse comme une performance ne suffit pas. La réponse a besoin d'une chaîne.
La garde ne signifie pas figer l'IA sous la bureaucratie. Elle signifie rendre possible un usage sérieux. Elle donne aux équipes la confiance que les données sont utilisées à la bonne fin, que les prompts sont versionnés, que les outils sont bornés, que les humains reçoivent des preuves, que les enregistrements survivent et que les artefacts se retirent lorsque leur finalité prend fin. Elle permet aux organisations d'automatiser sans prétendre que l'automatisation dissout la responsabilité. Elle leur permet d'apprendre sans thésauriser. Elle leur permet d'expliquer sans fouiller.
Le changement pratique est modeste et exigeant. Cessez de demander seulement si le modèle peut répondre. Demandez ce que le système détenait pour produire la réponse, qui était autorisé à la manipuler, ce qui a changé, ce qui a été enregistré, ce qui peut être contesté et quand les artefacts doivent quitter la garde. C'est moins magique. Tant mieux. La magie est un mauvais cadre de contrôle. La garde est plus discrète, plus lourde et beaucoup plus susceptible de fonctionner encore quand quelqu'un demande ce qui s'est passé.