Keep the evidence needed to explain an AI decision without giving every sensitive prompt the same lifetime. Classify artifacts, separate restricted payloads from release manifests, and treat expiry, hold release, deletion request and verified deletion as different states. A timer expiring is permission to evaluate deletion—not proof that bytes disappeared.
This is an engineering design and an executed synthetic policy exercise, not legal advice, a retention schedule or a compliance certification. Qualified legal and privacy reviewers must determine applicable law, actor roles, purposes, retention duties and exceptions before any production duration or irreversible storage lock is configured.
The failure: one bucket, incompatible purposes
Consider a hypothetical maintenance assistant. Its operational event identifies a model release and approval decision; its raw prompt contains an employee's complaint; its evaluation report supports a release review. Placing all three in one locked container makes their retention depend on the same storage boundary. Deleting them together can destroy useful evidence. Keeping them together can unnecessarily preserve sensitive content.
The logging and documentation architecture establishes what evidence to collect. This article handles a different decision: when each artifact may leave storage, which hold still applies, and what proves completion. The incident-preservation drill explains collection and integrity; preservation must subsequently feed a governed lifecycle rather than become an indefinite exception.
Use law as a reviewed input, not a hard-coded timer
The AI Act consolidation linked by EUR-Lex was retrieved for this article on 25 October 2026. Article 12 addresses logging capability for high-risk systems. Articles 19 and 26 address provider and deployer log retention within their respective scope and control. Those provisions are not a general instruction to keep every chatbot prompt forever. Logging capability over a system's lifetime and retention of every individual payload are different questions.
Do not turn a duration quoted from one provision into a global default. Ask counsel which provision applies to the specific actor, system, artifact and purpose, and how other law changes the answer. Consolidations are documentation aids; authentic Official Journal instruments and qualified review govern interpretation. This article makes no application-date determination.
The GDPR text, particularly Article 5, supplies data-minimisation and storage-limitation principles. Article 17 also contains conditions and exceptions relevant to erasure. These require a scoped assessment, not an automatic claim that audit evidence must always win or always be deleted. A digest, pseudonymous identifier or restricted manifest can still be personal data when it remains linkable to a person.
Build an artifact-class retention ledger
Record purpose, accountable owner, artifact class, exact object/version scope, clock origin, approved duration, approval reference, policy revision, hold authority, deletion workflow and verification state. Keep the approved rationale alongside the configuration. Missing duration or unresolved clock origin means review required, not zero-day deletion or infinite storage.
Use explicit clock semantics. An event timestamp, collection timestamp and release-retirement timestamp are not interchangeable. Record timezone and the authoritative clock. If a policy uses a non-creation event, an object-store retention timer may not directly implement it. Calculate the effective boundary in the policy layer and verify the storage configuration separately. Test the exact boundary, not just one day before and after it.
| Artifact class | Purpose and clock to approve | Completion evidence |
|---|---|---|
| Operational event | Explain execution; event-time policy | Scoped event/version deletion receipt |
| Restricted prompt or response | Necessary investigation; reviewed collection/use clock | Payload deletion plus unresolved-copy register |
| Release manifest and test report | Support assessed release; reviewed release lifecycle | Approved disposal or reviewed carry-forward |
| Incident evidence under hold | Preserve scoped case evidence; separate hold review | Authorised hold release, then normal policy evaluation |
The classes above are proposed engineering categories, not statutory categories. Minimise payload capture at the source. Give restricted content a separate access and storage boundary so a release manifest can remain available without preserving the original complaint text by accident. Do not move the sensitive sentence into a filename, object tag or deletion receipt and call that minimisation.
Two lifecycles, one controlled lineage
The diagram is a proposed application workflow. The restricted payload and minimal proof record receive separate reviewed policies. Their relationship is an access-controlled lineage reference, not an instruction to duplicate content. The manifest records what was evaluated, which version was used, relevant decisions and known gaps. A digest can later demonstrate a match against available bytes; after payload deletion, it cannot reconstruct those bytes or prove that the original observation was true.
When a payload is deleted, preserve only the authorised completion evidence: scoped object/version reference, policy revision, deletion job, result, verifier and unresolved-copy status. Give that receipt its own purpose and retention decision. The evidence-reconciliation workflow can check whether retained reports support a release, but structural consistency does not make their content or lifetime legally sufficient.
Holds are scoped decisions, not a global Boolean
Represent each hold separately with its authority, case reference, object scope, start, review owner and release decision. Releasing case A must not clear case B. A hold release also does not cancel an unexpired time-based retention policy. Re-evaluate the whole policy set before issuing deletion work.
If an approved retain-until bound exceeds an approved delete-by bound, return POLICY_CONFLICT. Likewise, escalate a hold that prevents meeting a reviewed deletion deadline. Neither silently choosing the longer period nor deleting through a hold is a safe legal decision for a script. Temporarily withholding automatic destructive action is an engineering safeguard; it does not resolve the conflict or authorise indefinite retention. Route it promptly to named legal/privacy and evidence owners.
Azure WORM: verify the actual protection boundary
Microsoft's immutable-storage documentation distinguishes time-based retention from legal holds. Time-based expiry permits deletion; it does not perform deletion. A legal hold continues until explicitly cleared. An active independent protection can still prevent deletion after another protection ends.
| Azure mode | Protection scope | Deletion boundary |
|---|---|---|
| Container-level time policy | All blobs in the container | Expiry plus absence of other protection |
| Version-level time policy | Individual version; account/container defaults may be inherited | Check effective policy on each version |
| Container legal hold | All blobs in the held container | Explicit hold clearance; time protection may remain |
| Version legal hold | Individual blob version | Explicit clearance for that version; check remaining protections |
Both locked and unlocked time-based policies protect against deletion while active. Microsoft documents that an unlocked policy can be shortened or removed, whereas a locked policy cannot be deleted or shortened; extension remains possible subject to the documented scope constraints. Use a disposable test environment and approved change procedure. No real cloud locks were created for this article.
Versioning, soft deletion and older versions complicate completion. Removing the current object reference is not proof that every retained version, backup, export or provider copy has gone. Inventory these boundaries explicitly. Vendor feature compatibility also varies by account configuration; verify the deployed settings rather than treating this matrix as a universal cloud contract.
Executed synthetic evaluator: expiry is not completion
A local Python fixture executed 14 asserted cases using invented integer clocks and in-memory decisions. It tested pre-expiry and exact expiry, hold continuation, release before and after expiry, one remaining hold, conflicting bounds, hold/deletion conflict, requested-but-unverified deletion, scoped verification, stale policy revision, missing clock approval, storage protection and a receipt without a request. All 14 matched their expected states. These are model tests, not Azure integration, legal analysis or production deletion evidence.
| Injected state | Observed model result | What must happen next |
|---|---|---|
| Now equals retain-until; no hold | ELIGIBLE_NOT_DELETED | Issue scoped request after current-policy check |
| Expiry passed; one hold remains | PROTECTED | Resolve remaining hold through its authority |
| Retain-until exceeds delete-by | POLICY_CONFLICT | Escalate; do not select a duration automatically |
| Delete requested; verification absent | DELETION_PENDING | Verify scope and unresolved copies |
| Policy revision changed | REVIEW_REQUIRED | Re-read policy and invalidate old admission |
| Request and trusted verification supplied | DELETION_VERIFIED_IN_SCOPE | Do not extrapolate beyond verified scope |
The algorithm first rejects missing policy inputs or a stale revision. It detects incompatible bounds and due deletion obligations blocked by protection. It then checks active holds/storage protection, followed by unexpired retention. Only an expired, unprotected, non-conflicting artifact becomes ELIGIBLE_NOT_DELETED. A deletion request advances it to DELETION_PENDING. Verification evidence may advance it to DELETION_VERIFIED_IN_SCOPE; a receipt without a request is invalid in this teaching model.
The fixture's verification Boolean is deliberately trusted. A real verifier must collect independent evidence rather than accept a worker's assertion. Bind requests and receipts to exact versions and policy revisions; reject stale approvals immediately before the destructive operation. A check followed by a separate delete is not atomic. Serialize hold changes and deletion admission through a controlled coordinator or an enforceable storage protocol, and test the race. The fixture does not solve that distributed-systems problem.
Deletion acceptance checklist
1. Resolve the current policy revision and all active holds for the exact artifact versions. Confirm the reviewed clock and authority; escalate unresolved conflicts.
2. Enumerate copies: primary object, older versions, derivatives, indexes, exports, backups and supplier-held records. Assign an owner and verification method to each boundary.
3. Issue an idempotent, scoped deletion request only after protection checks. Record denied operations and retries separately from successful work.
4. Verify the promised outcome through the appropriate storage interface or provider evidence. Distinguish absence from an active namespace, soft-deleted recoverability and completion of the approved erasure scope. A 404 alone is not proof of physical destruction.
5. Record unresolved copies and their governed expiry or exception. Test restoration and re-ingestion separately; never collapse partial completion into a global deleted flag.
6. Retain a minimal completion receipt under its own reviewed policy. Restrict access and verify that the receipt does not recreate the sensitive payload.
Costs, legal handoff and the first implementation
Separate stores and a policy ledger add operational state, permission management and reconciliation work. Fine-grained object policies improve isolation but increase inventory and verification cost. Long immutable periods can make a mistaken classification expensive to correct. Minimising payloads also reduces replay fidelity: document what investigations will no longer be possible rather than claiming full reproducibility.
For legal review, supply the artifact-class map, purposes, actor roles, applicable legal-version references, proposed clock origins, minimum/maximum bounds, hold authorities, cross-border/provider copies and conflict examples. Ask reviewers to approve explicit rules and exceptions. Engineering then tests those approved rules; it does not infer them from storage features.
Start with one workflow and one sensitive artifact class. Run expiry, overlapping-hold, stale-policy and partial-deletion tests before expanding the scope. For a technical evidence-lifecycle review, bring your current log schema, storage protection settings and one deletion ticket. I can help turn them into a scoped retention ledger and failure-injection acceptance suite, with legal and privacy decisions remaining with qualified reviewers.
