Record-keeping and logging failure

What it is

Records are the organisation's memory of its system's behaviour: what input was received, which version of model and prompt was in force, what was output, what a human decided, and when. They serve investigation, explanation to affected people, monitoring, and proof to regulators. The risk is that the system was not built to produce them, or that they are kept by a supplier, incomplete, or deleted too soon. The agent-specific case is covered in untraceable agent actions.

How it happens

• Logging was designed for debugging and captures no decisions.
• The model version in force at the time is not recorded.
• Logs are held by the provider and expire.
• Retention was set by storage cost and not by need.

Why it matters

A decision that is challenged a year later has to be explained from records. Without them the organisation can neither correct its own errors nor show that it acted properly. The EU AI Act requires high-risk systems to record events automatically and requires providers and deployers to keep the logs.

Warning signs

• A past output cannot be traced to a model version.
• Logs exclude inputs or human overrides.
• Retention periods are shorter than complaint and limitation periods.
• Nobody has tested reconstructing a past decision.

Who owns it

The system owner is accountable for the record. Engineering implements logging. Records management sets retention. Internal audit tests reconstruction.

In practice

A customer complains that an automated valuation eighteen months ago cost them a remortgage. The firm holds the figure that was produced. It no longer holds the inputs, and the model has been replaced twice with no archive of the earlier version. The same pattern generalises to any system whose records were designed for operation and not for accountability.