Which AI agent logs to keep after an incident

You must now be able to demonstrate, per AI agent system and per applicable law, which logs you retain after an incident and for how long. A universal retention period no longer suffices; the combination of UK incident-reporting proposals and EU AI Act requirements demands a retention matrix specific to each system's purpose and legal ground.

An analysis of 6 November 2026 of agent logs retained after an AI incident argues that UK proposals will soon require organisations to keep records of agent actions and operator control attempts when an incident is reported. The concrete case is the UK Department for Science, Innovation and Technology's proposed Agentic AI resilience measures, which name agent logs and control attempts as information to be preserved. In our assessment, this shifts log retention from operational good practice to a possible statutory evidence-preservation duty; anyone reporting an incident will need to reconstruct what the agent did and whether people intervened.

What does the UK proposal actually require?

The UK Department for Science, Innovation and Technology published its policy factsheet on 3 November 2026, proposing that regulated entities reporting an agentic AI incident must keep relevant information, including the actions of agents and the attempts by operators to control those agents. This is a proposal within a bill, not yet a general enforceable duty. However, the measure is concrete enough to shift your operational posture now. The proposal ties evidence preservation to a reported incident; once you report, you trigger a retention obligation for the logs that show what happened and who tried to intervene.

Which retention periods apply, and to which systems?

No single period covers all AI systems or all logs. The EU AI Act prescribes a minimum of six months for automatically generated logs of high-risk AI systems, but only those logs that fall under Article 19 and only to the extent the provider controls them. Data protection law, including the GDPR, may impose a different outcome. The UK Government Functional Standard GovS 005 describes a lifecycle approach: when decommissioning AI components, models, prompts, outputs, agent logs and derived data, an organisation must determine what is kept, archived, migrated or deleted in line with its own retention schedules, information management, security and applicable law. The misconception to correct is that six months applies universally; it does not. You must determine per system and per incident type what you keep.

What are the failure modes if you do not build a retention matrix now?

• Incident hold failure — logs are deleted before an incident is reported, destroying the evidence needed to show what the agent did and whether control attempts worked.
• Conflicting retention periods — one standard period applied across all systems risks keeping data too long under one law and too short under another.
• Unnecessary privacy exposure — full sensitive prompt content stored as evidence increases exposure when hashes, segmented storage or references would suffice.
• Loss of integrity evidence — agent logs altered after an incident cannot reconstruct what happened, rendering the logs worthless as evidence.
• Unclear legal ground — no documented retention ground per system leaves you unable to justify the period you chose to a regulator.

Which controls must you be able to demonstrate?

1. Set up an incident hold that suspends deletion on a reported or reasonably foreseeable incident — the moment an incident is reported, logs relevant to that incident must be protected from deletion.
2. Record the retention ground and period per system, not a universal rule — document which law applies to each system, what the retention period is, and why, rather than applying a single six-month period across all agents.
3. Limit log storage to minimal extracts and use hashes or references instead of full sensitive content — store only what is necessary to reconstruct the incident, not complete prompts or outputs.
4. Implement immutable storage or integrity evidence for incident-relevant logs before the first incident occurs — ensure logs cannot be altered after an incident, and record how you know they have not been altered.
5. Link technical logs to a decision record showing who decided what — pair each log entry with documentation of the human decision or control action it represents.

How should you sequence this work?

The UK measures are proposals, and the NCSC and GovS 005 documents are guidance and policy frameworks, not yet statutory standards. In our assessment the direction is clear enough to draw up a defensible matrix now rather than waiting for a possible future fixed period. Begin by identifying each AI agent system in your estate and the laws that apply to it: the EU AI Act if the system is high-risk, the GDPR if it processes personal data, and the UK proposals if you are a regulated entity. For each system, record the retention ground (incident investigation, compliance, audit) and the period it demands. Then configure your incident-response playbook to suspend deletion on a reported incident and to preserve logs with integrity controls. Finally, limit what you store to what you can justify as necessary, using references or hashes to reduce privacy exposure.

Automated tooling can enforce deletion schedules, flag incidents and lock logs against alteration. What tooling cannot do is determine which law applies to which system, which logs are necessary as evidence, or how long to keep them. That remains your professional judgement, and it must be documented before an incident occurs.