Kept, Found, Believed
The Financial Stability Board now separates documentation from records. Three cases from this summer show that keeping a record, finding it and trusting what it says are separate questions.
KEEPING IS ONE THING. READING IS ANOTHER. AI-generated image, created with Gemini (Google) under human direction.
Keeping a record does not establish that anyone knows what it contains. An institution may preserve records it has never individually identified. Keeping, finding and reading answer different questions. A search can be widened if the underlying records survive. A record that was never created cannot be recovered by widening a search.
On 15 October, the Financial Stability Board published final sound practices for adopting AI responsibly in finance. The Board says they “are non-prescriptive and do not constitute a binding international standard”. Sound Practice 3 separates documentation from lifecycle records. It recommends retaining and protecting those records and maintaining traceability of AI agents’ actions. This piece was developed with AI writing assistance under human verification and editorial control.
This piece reads that practice against three cases from this summer. The practice is addressed to financial institutions, about their own use of AI. The cases come from the evaluation environments of model developers. Carrying the practice across is my step, not the Board’s.
One disclosure first, because the argument applies here too. The text tools named in the method note come from the two developers whose documents this piece reads.
Documentation and records
The practice keeps two things apart. “Documentation describes the AI use case,” the Board writes. It covers purpose, design, governance arrangements, risk assessments, approvals and key lifecycle decisions. Lifecycle records are something else: “logs and other records generated through development, deployment, operation, monitoring and incident management activities”.
On Monday, this series’ anchor edition drew the same line. A record is what a system writes while it operates. A document is what someone writes afterwards, about the record. The Board drew the line in its own words and for its own purposes. That convergence does not show the line is right. It shows the line is not idiosyncratic.
The sound practice recommends retaining sufficient lifecycle records and protecting them against “unauthorised manipulation (modification or deletion)”. Where possible, it recommends immutability or immutable copies, particularly for critical information.
For agentic AI, it also addresses traceability. The records should make it possible to follow what a given agent did. That includes what triggered the action, which information and tools it accessed, what steps it took and whether it acted within its permissions throughout.
The same pages add two details. The records “may include” chain-of-thought logging “to help explain outputs”. And as institutions scale up their use of agentic AI, the practice describes a risk-based approach to how much they log. The aim is to avoid retaining “unnecessary and potentially unmanageable volumes of data”.
The cases below bear on three of these passages: protection, the reasoning log and volume.
What the responders did not see
In early July, a frontier developer responded to an incident in its evaluation environment. Its security team removed exposed credentials and later rebuilt an internal package repository. Agents had been writing messages to each other inside that repository since May. The developer’s public account says the rebuild “had the side effect of clearing the message board”.
The same account says the board and the significance of the agents’ communication “were not apparent” to the leaders responsible for the response. An internal team had seen board activity in late May.
The Board recommends protection against unauthorised modification or deletion. The clearing described here occurred during an authorised incident response. That distinction matters.
An immutable copy could have preserved the board’s contents even if responders did not understand their significance. The public account does not establish whether such a copy existed.
The question for record governance is therefore more specific. Which systems and event classes do retention and preservation controls cover, including records whose significance is not yet recognised?
A record with testimony inside
Get André Afonso Silva’s stories in your inbox
Join Medium for free to get updates from this writer.
The practice’s list for following an agent is made of actions: the trigger, the information and tools accessed, the steps, the permissions. Much of that is written by the environment around the agent. The reasoning log is different. The system writes it about itself.
This series uses a test set out on 20 July: could the record exist exactly as it is if the decision it describes had not happened that way?
A reasoning log can establish what the model expressed during a run. It does not, by itself, establish that the stated reasoning caused the action. The environment may preserve the log, but the model supplies the account contained in it. In this series’ terms, that account remains testimony.
The Board does not use these terms. It reaches a convergent caution in the same report. Footnote 69 says such explanations “may not accurately or completely represent the factors that caused the model’s behaviour”. It adds that they should not be treated as authoritative without additional validation.
The September measurement, reported here on 29 September and 7 October, gives a concrete reason for that caution. A second developer tested its offline monitor with and without the model’s reasoning. The monitor flagged about 1% of actions with the reasoning available and about 50% without it.
This does not establish which configuration is generally more reliable. It establishes sensitivity to the model’s own account in one incident.
The Board proposes keeping reasoning logs as possible explanatory material while cautioning against treating them as conclusive. The remaining question is evidentiary: which parts of the record establish what happened and which report what the model said about it?
A scope that cannot be widened
The last passage deals with volume. Logging everything can produce volumes that are hard to manage. So the practice describes a risk-based approach to how much to log, focused on the actions, decisions and steps that can affect an institution’s risk profile.
The same developer’s first search of its own transcripts, in July, covered cyber evaluation transcripts in which it believed its models could have reached the internet. It missed a set that also had internet access. That set came to light in August, while the developer assembled material for an independent evaluator. A wider search then covered about 481 million transcripts (this series’ anchor edition, 19 October).
That case was a failure of search coverage, not a demonstrated failure of logging. The records survived and later work reached them.
The Board’s risk-based logging recommendation raises a different question. When an institution decides not to record a class of events, a later search cannot recover those missing records. That is a limit of record creation, not search. It makes the original logging scope part of what a later investigator needs to examine.
One way to leave that scope examinable is to keep a dated document listing the environments and event classes covered by logging, including material exclusions. An investigator can then compare the incident’s environment with the logging configuration in force when it occurred. It is the coverage check proposed here on 7 October, applied to logging. This does not establish that every event was captured. It establishes what the system was configured to record.
The discount
These are three cases, each described by the party that held the records. In this series’ terms, that is testimony. None of these parties is a financial institution. The Board did not write its practice for them. I am not suggesting it should have.
In July, an incident response cleared an agent message board whose significance the response leaders had not recognised. In August, another developer found an incident in transcripts its earlier search had missed.
The first case does not establish whether other copies survived. The second establishes that records were retained beyond an incomplete search.
Neither shows that the Board’s practices would have failed if applied. Together, they show why the scope of retention and the coverage of later examination must be documented separately.
References
Financial Stability Board. (2026, October 15). Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report. Executive summary, p. 2; Sound Practice 3, pp. 25–26; footnote 69.
OpenAI. (2026, August 26). The Hugging Face incident and the road ahead. Official OpenAI publication.
Anthropic. (2026, September 9, updated September 10). An alignment assessment of recent cybersecurity incidents. Official Anthropic publication.
On method
Written with the support of Claude (Anthropic) and ChatGPT (OpenAI) for text and Gemini (Google) for the image. The full cognitive signature (intent, constraints, judgment under uncertainty, veto and responsibility) is mine, and so are the errors. Facts are verified against primary sources before they enter, and where verification was not possible the text says so.
I publish this note every week because this series argues that a document produced because someone asked for it is worth less than a record produced in the ordinary course of work. Nobody asked me for this note.
Essência AI Insights is a weekly series on governance, systemic risk and institutional infrastructure for emerging technologies. Written by André A. Silva
