When a system moves from suggesting to executing, recording its actions ceases to be a good operating practice and becomes the only available defense against a complaining customer, an inquiring auditor, or a judging court. Without a record, there is no possible explanation, and the absence of an explanation is always interpreted against the party responsible for providing it.
This is also the only technical requirement that cannot be added afterwards. Security can be strengthened, permissions improved, or data quality corrected while the system is running. You can't record what has already happened.
The proof of sufficiency of a record is concrete: Choose a case from three months ago and explain exactly what happened.. To answer, six elements are needed:
Element | What is saved | What is it for? |
|---|---|---|
Entrance | Data and context received by the system | Replicate the case |
Sources | What documents or records did you consult? | Explain where the answer came from. |
Decision | Model output, version, and configuration | Distinguish drift error |
Action | What was executed, on which system, and when | Audit and reversal |
Identity | With what credentials did he act, and at whose request? | Attribute responsibility |
Validation | Who reviewed it, what changed, and when? | Demonstrate human supervision |
The line of the sources It is the most frequently omitted and the most valuable in the event of a claim: it allows one to demonstrate that the response was based on correct and current information, or to identify exactly which outdated document caused it.
The row of the model version It is what allows us to distinguish between two very different situations: a specific system error and a general degradation after an update. Without this information, the two cases are indistinguishable.
The three frameworks that govern this matter converge on the same requirement with different vocabularies.
He European AI regulation For certain categories of systems, it requires automatic event logging, technical documentation, and demonstrable human oversight. And since August 2, 2026, the transparency obligations of Article 50 and the sanctioning powers over providers of general-purpose models have been in effect.
He NIST AI Risk Management Framework, With its specific profile for generative AI, it structures all risk management around the ability to measure and monitor.
The ISO/IEC 42001:2023 It requires evidence of ongoing monitoring to certify an AI management system. Evidence means records, not policies.
None of them accept the response that the organization acted diligently. All three demand proof, and what is demonstrated is the data that was stored while the system was operating.
A customer claims his application was unfairly rejected four months ago. The decision was prepared by an automated system and confirmed by a person.
The questions that will come up, in this order: what information was used to decide, whether that information was correct and up-to-date, what criteria the system applied, whether the person who confirmed saw the complete proposal, and whether other similar cases received the same treatment.
An organization with full registration responds within an afternoon and, if it detects an error, corrects it and limits the damage. An organization without registration can only claim that its process is generally correct, which is precisely what it's not being asked about.
The difference between the two situations was decided months earlier, in a technical conversation about what was worth keeping.
Save only the result. Without the input or the sources, the result is neither reconstructible nor explainable.
Retention too short. Claims are arriving late. A thirty-day deadline excludes most of the cases that matter. The deadline should be set according to the actual claims cycle of the business and applicable regulations, not according to storage costs.
Scattered records. If each component writes to its own site and clock, reconstructing a case requires traversing five sources. A unique case identifier that spans the entire flow solves the problem and costs little.
mutable register. A record that can be altered without leaving a trace is not valid as evidence. Immutability is what gives it probative value.
Total integration is a poor goal. Sufficient integration for a specific process is achievable in weeks. Four steps:
Each iteration builds a reusable piece of the integration layer. After three or four processes, the company has infrastructure, not isolated solutions. This is the composable approach we describe in The bottleneck is once again architecture
The legitimate objection to all this is data protection: recording what a system does implies recording information about people, both customers and employees.
This is not an argument against registration, but rather in favor of designing it well. Three measures address most of the issues:
A well-designed record protects both the organization and the people involved, because it allows proof that a decision was made correctly.
If your organization has AI systems that perform actions, there's a one-hour check you should do this week: to request the complete reconstruction of a specific case from three months ago.
The result of that test reveals more about the company's actual exposure than any compliance report. And if the result is bad, it's still a good day to find out, because the records missing today can start being generated tomorrow. Those from three months ago cannot.
It's the record that allows us to reconstruct what the system did in a specific case: what data it received, what sources it consulted, what the model produced and with which version, what action it executed, with what identity, and who validated it. It's the only way to explain a decision months later.
Because it's irreversible: what wasn't saved doesn't exist. Security, permissions, or data quality can be improved while the system is running, but the history of what has already happened cannot be generated retroactively.
The European AI Regulation requires automatic event logging, technical documentation, and demonstrable human oversight for certain categories of systems. The NIST AI RMF structures risk management around the ability to measure and monitor, and ISO/IEC 42001 requires evidence of ongoing control for certification.
The retention period should be set according to the actual claims cycle of the business and applicable regulations, not according to storage costs. Thirty-day retention periods exclude most cases that ultimately become relevant, because claims typically arrive months later.
With three measures: minimizing the content by saving references to the consulted documents instead of full copies, restricting access to the record with its own permissions and specific auditing, and defining explicit retention and deletion periods aligned with the regulations.
Choosing a specific case from three months ago and requesting its complete reconstruction. If the team can explain what data was entered, what sources were used, what version of the model was involved, what was executed, and who validated it, the record is sufficient.
Could you reconstruct today an automated decision from three months ago? We review what your system records, what is missing, and what the regulations applicable to your case require. Request a review → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
