AI governance conversations often begin with a false choice: retain everything for accountability or delete everything for privacy. Neither extreme works well in operations. If every prompt, copied customer record, intermediate draft, and model trace is kept indefinitely, temporary context becomes permanent exposure.
Deleting everything is not responsible either. An organisation may need to show who authorised an action, which policy applied, what the system produced, whether a human approved it, and what happened next. The better operating model is to separate durable evidence from temporary working context before an AI workflow goes live.
The difference between evidence and exhaust
AI systems produce data with very different purposes. A final decision record may support customer service, incident review, financial control, or regulatory obligations. A scratch prompt containing copied account details may have no value once the task ends.
Treating both records the same is convenient for storage architecture, but poor for governance. The NIST AI Risk Management Framework organises AI risk work around governing, mapping, measuring, and managing. Its emphasis on documented outcomes and clear accountability does not require every intermediate artefact to live forever.
Durable evidence should answer a defined accountability question. Who approved the workflow? What model or tool version was active? Which policy and data source were used? What material output, override, or downstream action occurred?
Working context serves a different purpose. It helps a person or system complete the present task: retrieved passages, temporary notes, intermediate prompts, tool responses, draft classifications, copied identifiers, and exception-handling details. Unless another purpose is explicitly established, that context should expire with the work.
Map six fields before choosing a retention period
Retention schedules are often inherited from the application, database, or vendor default. That reverses the decision. Teams should map each AI workflow first, then configure storage around the map.
For every workflow, record six fields:
- Purpose: What business outcome is this workflow authorised to produce?
- Data owner: Who is responsible for the source data and its permitted use?
- Accountable evidence: What minimum record proves that the process operated as intended?
- Temporary context: What data exists only to complete the current task?
- Expiry trigger: Does context expire after a session, decision, handoff, appeal window, or another defined event?
- Failure behaviour: What is retained, deleted, or escalated when the model, tool, or human reviewer fails?
This map forces useful specificity. “Keep logs for compliance” becomes “retain the approval, policy version, outcome, and exception code for the required period.” “Delete prompts” becomes “discard temporary retrieved passages after the appeal window unless an incident hold applies.”
The distinction also supports data minimisation. The UK Information Commissioner’s Office explains that personal data should be adequate, relevant, and limited to what is necessary, while storage limitation asks organisations not to keep it longer than needed. Its AI and data protection guidance connects those principles to the AI lifecycle.
Do not turn possible model improvement into a blanket purpose
“We may use it to improve the model” is often treated as permission to keep everything. It is not an operationally useful purpose because it does not say which improvement, who will evaluate it, which fields are necessary, or when the experiment ends. Service delivery, quality measurement, incident investigation, and model training are separate activities and should have separate data maps.
Where retained samples are justified, select the smallest representative set, remove fields that are not needed for the evaluation, control reviewer access, and establish an end date. Where the task can be measured with aggregate error rates, synthetic tests, or deliberately created evaluation cases, avoid retaining raw customer context merely because it might become useful later. A specific improvement plan can support a specific retention decision; an unspecified future possibility cannot.
Design expiry as a system behaviour
A retention policy in a document does not delete data. Expiry must be implemented across the complete workflow: application logs, model gateways, observability tools, vector stores, queues, exports, support systems, backups, and vendor platforms. A seven-day policy in one database is meaningless if the same prompt survives indefinitely in three downstream tools.
Each temporary data class needs an owner, a machine-enforced deadline, and a verifiable deletion path. Teams should test expiry the way they test access control: create a known record, trace every copy, wait for the trigger, and prove that the record is no longer retrievable through ordinary or administrative interfaces.
Exceptions must also be explicit. A security incident, legal hold, customer appeal, or model-quality investigation may justify preserving a bounded record. The exception should identify who authorised the hold, what data it covers, when it will be reviewed, and what ends it.
Keep humans accountable without storing their entire workspace
Human review does not automatically solve AI risk. A reviewer can approve an output without understanding its source, or become a ceremonial click between automated steps. Accountability requires a legible decision boundary.
The durable record should show what the human was asked to decide, what material evidence was presented, the decision made, and any override or escalation. It does not necessarily need every keystroke, abandoned draft, or copied customer detail from the reviewer’s workspace.
The NIST Privacy Framework treats privacy as an enterprise risk-management problem rather than a final compliance check. That is the right operational posture here. Data purpose, access, retention, and deletion should be designed alongside the workflow, not patched in after a pilot becomes production.
Measure whether the boundary works
Teams need more than a policy-completion metric. Useful measures include the percentage of workflows with all six fields mapped, temporary records without an expiry trigger, deletion tests passed, vendors with verified retention settings, open exception holds, and incidents where missing evidence prevented review.
The goal is not maximum deletion or maximum documentation. It is sufficient, reliable evidence with the smallest defensible amount of temporary context. When that boundary is visible and testable, accountability and privacy stop competing as slogans and start working together as operating controls.
