An authority — a supervisor, an ombudsman, a data protection regulator, a court's expert — wants to know how a particular decision was made by one of your AI systems, months after it happened. You have a folder of material and a sinking feeling that none of it is in the shape they are asking for.
This page is about the shape. Not how to argue your case, and not whether you are compliant — that is your counsel's and the regulator's judgement, not a blog's. This is about what you actually send back, and why the form of it matters as much as the content.
The mistake almost everyone makes first
The instinct is to answer the way you would answer a colleague: a narrative. "Here is what happened, here is the context, here is why it was reasonable." It reads well and it is the wrong instrument.
A regulator did not send you a question to discuss. They sent a request for information — often several, numbered, each one a distinct thing they need established. An Article 14 request, an information notice, a supervisory letter: these have a structure, and the response that lands is the one that mirrors it. Request, then response. One at a time. Including the requests you cannot fully answer.
A narrative buries the thing they are checking inside prose they then have to disassemble. A structured response hands it to them already assembled — which is both more useful to them and more defensible for you.
The structure that holds up
Treat it as a file, not a letter. A regulatory response file has a spine, and the spine is theirs, not yours.
- A cover. Reference, the request it answers, the date, the scope of what you looked at. Boring, and it is the first thing a reviewer checks.
- One block per request. The regulator's question, quoted as they wrote it. Then your response, drawn from the evidence — not from memory, not from what the policy intended. If the request was "explain how this decision was reached", the response is the reconstructed sequence, each fact carrying where it came from. If it was "identify every person or system that authorised this decision", the response names them, or states plainly that no authorisation was recorded.
- A section for what you cannot demonstrate. This is the part people want to delete, and it is the part that makes the rest credible. Title it Limitations of the response — matters that cannot presently be demonstrated. Where the record does not carry a claim, say so there, explicitly, rather than letting the regulator discover a gap you stepped around.
- Supporting evidence, annexed. Every real regulatory response has appendices. The facts each response rests on, their sources, and how they can be checked, sit at the back — so the body reads cleanly and the substance is there for anyone who wants to dig.
A reviewer who finds one thing you quietly inflated re-reads everything else looking for the next one. A reviewer who sees you name your own gaps extends credit to the parts you do stand behind.
Two phrases to get right
Small wording choices carry weight in front of an authority.
Where nothing followed a decision, do not write "nothing recorded yet" — it sounds like an admission of sloppiness. Write "no observable downstream effects were recorded." It says the same thing and it is precise: you looked, the channel exists, and it registered nothing.
And for the whole category of what you cannot show, "what we can't answer" is too casual. "Matters that cannot presently be demonstrated" is the register a regulator works in, and presently is honest — it says the limitation is about the evidence that exists today, not a permanent refusal.
Where the answer actually comes from
Here is the uncomfortable part, and it is worth facing before the letter arrives rather than after.
The answer comes from records that were almost never created to answer this question. Logs written for debugging. A tracing tool that expired at ninety days. Tickets, approvals, config versions, and — often — the memory of someone who has since left. Assembling those into a response the regulator will accept is not a formatting exercise. The hard, expensive part is establishing that this particular record demonstrates this particular thing the regulator asked about, and standing behind it when they push.
That is reconstruction, and it is a discipline in its own right: what can be established from records never meant for the purpose, what cannot, and how far each fact can be stood behind. We wrote about that separately — what can and cannot be recovered when nothing was instrumented for it, and what AI evidence reconstruction is.
If the letter hasn't arrived yet
Then you are in the fortunate position, and there is one thing worth doing now, because it costs almost nothing today and is unbuyable once the deadline is running.
Decide, for the decisions that carry consequence, what a future response would need — which model and version, which policy was in force, which configuration, who or what authorised it — and make sure those are recorded at the time, from a source the deciding system does not control, in a form that cannot be quietly revised later. You are not building paperwork. You are making sure that when the polite letter arrives, the answer is a reconstruction and not an excavation.
When you don't need any of this
If your AI systems do not make or shape decisions that affect anyone outside your organisation, a regulator is unlikely to ask, and this is not your problem to solve today.
And if a request has arrived and it touches a real decision with real consequences, the response file is a technical instrument — but the legal position it supports is not something to improvise from a web page. This shows you the shape of a defensible answer. Your counsel decides what to do with it.
See what a reconstructed answer is built from
A complete evidence package — reconstructed from a real agent run, published with its SHA-256 manifest and an external RFC 3161 timestamp you can verify yourself — shows the raw material a regulatory response is built from. Inspect it before you need one.
See the evidence package →
A request has landed — how a run works →
Also read: What is AI evidence reconstruction? · Reconstructing what an agent did when nothing was instrumented · How do you prove a control actually ran?.
Une autorité — un superviseur, un médiateur, un régulateur de la protection des données, l'expert d'un tribunal — veut savoir comment une décision précise a été prise par l'un de vos systèmes d'IA, des mois après qu'elle a eu lieu. Vous avez un dossier de matière et le sentiment tenace que rien n'est dans la forme qu'ils demandent.
Cette page parle de la forme. Ni comment plaider votre cause, ni si vous êtes conforme — c'est le jugement de votre conseil et du régulateur, pas celui d'un blog. Elle parle de ce que vous renvoyez réellement, et de pourquoi la forme compte autant que le contenu.
L'erreur que presque tout le monde commet d'abord
Le réflexe est de répondre comme on répondrait à un collègue : un récit. « Voici ce qui s'est passé, voici le contexte, voici pourquoi c'était raisonnable. » Ça se lit bien, et c'est le mauvais instrument.
Un régulateur ne vous a pas envoyé une question à discuter. Il a envoyé une demande d'information — souvent plusieurs, numérotées, chacune étant une chose distincte à établir. Une demande au titre de l'article 14, une notification d'information, une lettre de supervision : cela a une structure, et la réponse qui porte est celle qui l'épouse. Demande, puis réponse. Une à la fois. Y compris les demandes auxquelles vous ne pouvez pas répondre complètement.
Un récit enfouit ce qu'ils vérifient dans une prose qu'ils doivent ensuite désassembler. Une réponse structurée la leur remet déjà assemblée — ce qui est à la fois plus utile pour eux et plus défendable pour vous.
La structure qui tient
Traitez cela comme un dossier, pas une lettre. Un dossier de réponse réglementaire a une colonne vertébrale, et cette colonne est la leur, pas la vôtre.
- Une page de garde. Référence, la demande à laquelle elle répond, la date, le périmètre de ce que vous avez examiné. Ennuyeux, et c'est la première chose qu'un relecteur vérifie.
- Un bloc par demande. La question du régulateur, citée telle qu'il l'a écrite. Puis votre réponse, tirée de la preuve — pas de la mémoire, pas de ce que la politique prévoyait. Si la demande était « expliquez comment cette décision a été prise », la réponse est la séquence reconstituée, chaque fait portant son origine. Si c'était « identifiez chaque personne ou système ayant autorisé cette décision », la réponse les nomme, ou déclare clairement qu'aucune autorisation n'a été enregistrée.
- Une section pour ce que vous ne pouvez pas démontrer. C'est la partie qu'on veut supprimer, et c'est celle qui rend le reste crédible. Intitulez-la Limites de la réponse — les points qui ne peuvent pas être démontrés à ce jour. Là où le dossier ne porte pas une affirmation, dites-le là, explicitement, plutôt que de laisser le régulateur découvrir une lacune que vous avez contournée.
- Preuves à l'appui, en annexe. Toute vraie réponse réglementaire a des annexes. Les faits sur lesquels chaque réponse repose, leurs sources, et comment les vérifier, se placent à la fin — pour que le corps se lise clairement et que la substance soit là pour qui veut creuser.
Un relecteur qui trouve une chose que vous avez discrètement gonflée relit tout le reste en cherchant la suivante. Un relecteur qui vous voit nommer vos propres lacunes accorde du crédit à ce que vous soutenez vraiment.
Deux formulations à ne pas rater
De petits choix de mots pèsent lourd face à une autorité.
Là où rien n'a suivi une décision, n'écrivez pas « rien enregistré à ce jour » — ça sonne comme un aveu de négligence. Écrivez « aucun effet observable en aval n'a été enregistré. » Cela dit la même chose et c'est précis : vous avez regardé, le canal existe, et il n'a rien enregistré.
Et pour toute la catégorie de ce que vous ne pouvez pas montrer, « ce qu'on ne peut pas répondre » est trop familier. « Points qui ne peuvent pas être démontrés à ce jour » est le registre dans lequel travaille un régulateur, et à ce jour est honnête — cela dit que la limite porte sur la preuve qui existe aujourd'hui, pas sur un refus permanent.
D'où vient réellement la réponse
Voici la partie inconfortable, et il vaut mieux l'affronter avant que la lettre n'arrive qu'après.
La réponse vient d'enregistrements qui n'ont presque jamais été créés pour répondre à cette question. Des logs écrits pour le débogage. Un outil de tracing expiré à quatre-vingt-dix jours. Des tickets, des approbations, des versions de configuration, et — souvent — la mémoire de quelqu'un qui est parti depuis. Les assembler en une réponse que le régulateur acceptera n'est pas un exercice de mise en forme. Le point dur, coûteux, c'est d'établir que cet enregistrement précis démontre cette chose précise que le régulateur a demandée, et de le tenir quand il pousse.
C'est de la reconstitution, une discipline à part entière : ce qu'on peut établir à partir d'enregistrements jamais faits pour ça, ce qu'on ne peut pas, et jusqu'où chaque fait peut être tenu. Nous en avons parlé séparément — ce qu'on peut et ne peut pas récupérer quand rien n'était instrumenté, et ce qu'est la reconstitution de preuve IA.
Si la lettre n'est pas encore arrivée
Alors vous êtes dans la position favorable, et il y a une chose à faire maintenant, parce qu'elle ne coûte presque rien aujourd'hui et devient inachetable une fois le délai lancé.
Décidez, pour les décisions qui portent à conséquence, ce dont une réponse future aurait besoin — quel modèle et quelle version, quelle politique était en vigueur, quelle configuration, qui ou quoi l'a autorisée — et assurez-vous que ces éléments sont enregistrés sur le moment, depuis une source que le système décideur ne contrôle pas, sous une forme qu'on ne peut pas réviser discrètement plus tard. Vous ne fabriquez pas de la paperasse. Vous faites en sorte que, quand la lettre polie arrive, la réponse soit une reconstitution et non une fouille.
Quand vous n'avez besoin de rien de tout ça
Si vos systèmes d'IA ne prennent ni ne façonnent des décisions affectant quelqu'un hors de votre organisation, un régulateur ne vous interrogera probablement pas, et ce n'est pas votre problème à résoudre aujourd'hui.
Et si une demande est arrivée et qu'elle touche une décision réelle aux conséquences réelles, le dossier de réponse est un instrument technique — mais la position juridique qu'il soutient ne s'improvise pas depuis une page web. Ceci vous montre la forme d'une réponse défendable. Votre conseil décide ce qu'il en fait.
Voyez à partir de quoi une réponse se construit
Un paquet de preuve complet — reconstitué depuis une vraie exécution d'agent, publié avec son manifeste SHA-256 et un horodatage RFC 3161 externe que vous pouvez vérifier vous-même — montre la matière première d'une réponse réglementaire. Inspectez-le avant d'en avoir besoin.
Voir le paquet de preuve →
Une demande est arrivée — comment se passe un passage →
À lire aussi : Qu'est-ce que la reconstitution de preuve IA ? · Reconstituer ce qu'un agent a fait quand rien n'était instrumenté · Comment prouver qu'un contrôle a réellement tourné ?.