Two clocks run on every agent record
The moment an AI agent takes a consequential action, two clocks start against the record of that action, and they run in opposite directions.
The first clock says keep it. A refund can come back as a card dispute four months later. A claim decision can surface in a market conduct exam years after the claim closed. A regulator can ask for the records behind a class of automated decisions long after the team that shipped the agent has moved on. Every one of those moments is answered from the record that exists then, not from the confidence anyone had at execution time: when Air Canada's chatbot gave a customer wrong information about a bereavement fare, the tribunal worked from the customer's screenshot of the conversation. Delete too early and the organization faces its own dispute with nothing but the other side's evidence.
The second clock says let it go. Records of agent actions are full of personal data: names, account identifiers, amounts, health or financial details, the customer's own words. Privacy law limits how long identifiable data may be kept, every retained record widens the blast radius of a breach, and every terabyte of old payloads is something a future discovery request or subject access request has to be answered from. Keep everything forever and the archive itself becomes a liability.
Many teams running agents have not decided how to set either clock. The default in practice is then whatever the logging pipeline happened to be configured for, often a 30- or 90-day window chosen for storage cost and applied uniformly to debug noise and to the only record of a disputed payment alike. This guide is about replacing that accident with a decision: where the legal floors are, where the ceilings are, and how to size the window deliberately for each class of action.
The floors: what regulators already require
The clearest new floor is in the EU AI Act. Article 12 requires high-risk AI systems to be designed to automatically record logs over their lifetime, and Article 19 requires providers to keep the logs under their control for at least six months, unless Union or national law, including data protection law, provides otherwise. Article 26 places the mirror obligation on deployers: the organization running the system keeps the logs under its control, again for at least six months. The Digital Omnibus on AI (Regulation (EU) 2026/1744, in force since 27 July 2026) moved the application dates for high-risk obligations to 2 December 2027 for the stand-alone systems listed in Annex III and 2 August 2028 for high-risk systems embedded in regulated products; it did not soften the logging or retention requirements themselves.
Six months is a floor, not a recommendation. For any action that can still be disputed, audited, or litigated after six months, which describes most actions that move money, the operative retention period comes from the sectoral rules the workflow already lives under, and those run in years:
| Regime | Records | Retention |
|---|---|---|
| EU AI Act, Articles 19 and 26 | Automatically generated logs of high-risk AI systems | At least six months, longer where other law applies |
| SEC Rule 17a-4 (broker-dealers) | Blotters, ledgers, and core books and records; most other required records | Six years for the core set, three years for most others, the first two in an easily accessible place |
| FINRA Rule 4511 | Books and records with no specified period | Six years by default |
| HIPAA Security Rule, 45 CFR 164.316 | Required Security Rule documentation, such as policies and risk assessments; medical-record retention itself is set by state law | Six years from creation or from when last in effect, whichever is later |
| State insurance record rules | Claim files and related records | Varies by state; commonly measured in years from claim closure |
The specifics matter less than the pattern. When the SEC requires certain broker-dealer records kept six years with the first two easily accessible, when FINRA Rule 4511 defaults any unspecified record to six years, and when the HIPAA Security Rule keeps required documentation six years, none of them asks whether a person or a piece of software produced the record. A record produced by an agent working a regulated workflow inherits the workflow's retention rules, not the logging pipeline's defaults. The same holds in insurance, where claim files must stay reconstructable for as long as state record rules keep the file alive.
The ceiling: storage limitation is real law too
Pointing at record-keeping rules does not license keeping everything indefinitely. The GDPR's storage limitation principle requires that personal data be kept in identifiable form no longer than necessary for the purposes it was collected for, and the neighboring data minimization principle requires that what is collected be adequate, relevant, and limited to what the purpose needs. "It might be useful someday" is not a purpose. The UK Information Commissioner's storage limitation guidance says outright that data should not be kept indefinitely "just in case", and that once a possible claim could no longer arise, the data should go.
The two bodies of law are less opposed than they first look, because the GDPR itself recognizes defense as a purpose. The right to erasure in Article 17 does not apply where processing is necessary for the establishment, exercise, or defense of legal claims, and retention mandated by Union or member state law is likewise carved out. What the ceiling actually demands is that retention have a stated purpose, a defensible endpoint, and a record that carries no more personal data than the purpose needs. "We keep evidence of consequential agent actions for the period in which those actions can be disputed or examined, and then we delete it" is a defensible answer to both clocks, provided the record is minimized at capture and the deletion actually runs. "We keep logs" answers neither.
Separate the evidence from the exhaust
The reason retention conversations stall is that many teams are trying to set one period for two very different kinds of record. An agent's technical exhaust, meaning the observability traces, prompts, intermediate model outputs, and tool payloads captured for debugging, is bulky, saturated with personal data, and loses most of its value within weeks. The business evidence for a consequential action, meaning the record of what the agent decided and did, the policy in force at decision time, and the outcome confirmed in the system of record, is compact, deliberately structured, and is precisely the record the multi-year floors apply to.
The line between them runs by content and use, not by which pipeline captured the bytes. A model output that was shown to a customer is the record of that communication: for a broker-dealer, SEC Rule 17a-4(b)(4) keeps communications sent and received in the course of business for three years, and FINRA's Regulatory Notice 24-09 reminds firms that its rules are technologically neutral and that the content standards for communications with the public apply whether a communication was generated by a person or by a technology tool. A tool-call payload that carried the amount the agent approved is part of the evidence for that approval. Short retention is for debug material with no evidentiary use and no retention duty attached, and the fact that a record sits inside a trace does not exempt it from the rules that apply to its content. The practical consequence is that the evidence record has to be defined deliberately at capture time, naming which fields carry evidentiary weight, rather than reconstructed from the exhaust later.
Held to one policy, both records get the wrong one. Keep everything six years and the organization pays to store, secure, and answer discovery on years of raw payloads it never needed, in tension with minimization the whole time. Keep everything 90 days and the evidence for a disputed refund is gone before the card network's dispute window has closed. The workable design separates the classes: short retention for the exhaust, long retention for the evidence, and a deliberate decision about which record each captured field belongs to.
That separation is also what makes long retention tenable under the ceiling. A record built for six years of retention should be minimized at capture: evidence fields limited to an approved allowlist rather than whole API responses, identifiers and free text redacted at the boundary where data enters the record, and bulky context held by reference where the reference will still resolve. The less personal data the evidence record carries, the less the keep-it clock and the delete-it clock have to fight over.
Sizing the window per action class
With the classes separated, the retention window for evidence stops being a philosophical question and becomes an enumerable one: for this class of action, what is the longest horizon on which someone can dispute, audit, or examine it, and what margin belongs on top?
A refund is a concrete example. Visa's core rules give issuers 120 calendar days from the transaction processing date to raise most disputes. The condition that fits a refund the agent reported and the customer says never arrived is Credit Not Processed, and its clock starts later: 120 calendar days from the date on the credit transaction receipt, or from the date the cardholder cancelled or returned the goods if the receipt is undated, with an outer limit of 540 calendar days from the original transaction's processing date. Evidence for an agent-issued refund retained for 90 days is therefore guaranteed to be missing for a meaningful share of the disputes it exists to answer. A claim decision keys off the state claim-file rules for the line of business. A brokerage communication keys off SEC and FINRA periods. An ordinary commercial action with no sectoral rule still faces contract statutes of limitations that run for years and vary by jurisdiction.
The method is the same in every case: list the ways the action class can come back, take the longest window, add margin for the time it takes a dispute that starts near the deadline to actually resolve, and write the result down as the retention class for that action type. Retention attaches to what the action was, not to which database the record happens to sit in. And the floor from the EU AI Act's six months applies to the logs of the system regardless, so no class lands below it where the Act is in scope.
The schedule also has to yield to a hold. A dispute, an examination, or a lawsuit that is still running when the window closes suspends deletion for the records it touches, and in the United States the duty to preserve can attach before any case is filed: Federal Rule of Civil Procedure 37(e) lets a court impose measures when electronically stored information that should have been preserved "in the anticipation or conduct of litigation" is lost because a party failed to take reasonable steps to keep it. A legal hold therefore belongs in the retention design from the start: a way to mark the affected record-sets so that scheduled deletion skips them, and a recorded release when the hold ends, so that the eventual deletion is as explainable as any other.
Written down, one retention class looks like this. The periods are an illustration, not a recommendation; the card networks, jurisdictions, and contracts that actually apply set the real numbers.
| Element | Example: agent-issued card refund |
|---|---|
| Record class | Evidence record for the refund: decision, policy snapshot, executed action, and the outcome confirmed in the billing system |
| Governing horizons | Visa dispute time limits, with Credit Not Processed capped at 540 calendar days from the transaction; the EU AI Act six-month log floor where the Act is in scope |
| Trigger event | Transaction processing date of the original payment |
| Period | 540 days plus 90 days of margin for disputes opened near the deadline, about 21 months in total |
| Hold exceptions | Deletion suspended while a legal hold, an open dispute, or an open examination references the record; released with a recorded date and reason |
| Deletion owner | The team that owns the refund workflow approves the window; the scheduled cleanup job executes it, and its run log is retained |
Deletion must be executed, not declared
A retention schedule that exists only as a document is worse than none. If the policy says records are deleted after two years and litigation reveals five years of them, the organization has demonstrated that its own controls do not run, and every other representation about its records inherits the doubt. If an ad hoc cleanup script deletes too much, the organization has destroyed evidence it was obliged to keep. Both failures come from the same gap: a stated policy with no verified mechanism executing it.
Executed retention has a small number of load-bearing properties:
| Property | Why it matters |
|---|---|
| Explicit configuration | Deletion happens because someone decided the window, never as a silent default; an unconfigured window keeps everything, and that state is an open item with an owner and a deadline, not a policy |
| Fail-closed behavior | When the job is unsure whether a record is eligible, it keeps the record; the error mode is retaining too long, never deleting evidence |
| Whole-record deletion | A record-set leaves storage complete or not at all, so the store never holds a verification verdict without the evidence behind it, or evidence stripped of its outcome |
| Bounded, repeatable runs | The job deletes a bounded batch per run and can be interrupted and rerun without corrupting state, so cleanup is routine instead of a risky annual event |
| An accountable trace | The schedule and its runs are themselves recorded, so "why is this record gone" has an answer: the configured window, executed on this date |
The last property resolves an apparent conflict with tamper-evident evidence. Append-only ordering and integrity proofs exist to make silent alteration detectable, and governed retention is not silent alteration: it removes whole records under a configured schedule that is itself on the record. A gap explained by an executed retention policy is a normal fact about a record store. A gap nobody can explain is the thing tamper evidence exists to catch. The two disciplines are compatible exactly when deletion is governed, whole, and accounted for.
How Pruvz handles retention
Pruvz is a business evidence layer for production AI agents, and it treats both clocks as design inputs rather than afterthoughts. Minimization is applied where data enters the record: connectors redact at the edge, and the evidence a system-of-record read-back may carry is limited to an enforced allowlist of approved fields, so an evidence packet is built for years of retention instead of accumulating whole API responses. Retention itself is an opt-in window: nothing is ever deleted without explicit configuration, and the behavior is fail-closed, so setting the window is a deliberate step in setup rather than a default to inherit. Once a window is configured, it is executed, not merely available: a scheduled cleanup job deletes eligible record-sets whole, in bounded, repeatable runs, so a verification result never outlives the evidence behind it and a half-deleted packet is not a state the design allows. You can see what a packet contains, field by field, in a real evidence packet from the product demo, and how the record store is protected in the security and data architecture overview.
Pruvz is inviting founding design partners to shape the evidence layer around real production agent workflows. If your agents already take consequential actions and nobody can say how long the records behind those actions are kept, or whether the stated window is actually executed, that is exactly the gap a design-partner conversation is built to map. For the wider picture of what the retained record should contain, start with what business evidence for AI agents is.
This article is general technical and governance information, not legal advice. Your obligations depend on your jurisdiction, industry, and specific use case.