A retention policy needs an implementation
A settings page can say that conversations expire after a fixed period while derived copies remain in traces, response caches, support tickets, or backups.
The first engineering task is to inventory those copies and their deletion mechanisms.
For each store, record its purpose, owner, location, access rules, ordinary retention, and hold behavior. Distinguish a user-facing delete action from removal from active storage, backup expiry, and any legal preservation requirement.
What the OpenAI example establishes
OpenAI's October 22, 2025 update says the earlier obligation to retain consumer ChatGPT and API content indefinitely ended on September 26, 2025. It also describes limited historical data still held for legal obligations.
Its account distinguishes affected offerings and excludes specified enterprise and zero-data-retention API arrangements.
Those details matter: the episode is not evidence that every customer, product, or later request was treated identically.
This is a dated account from a party to the litigation. It demonstrates that legal preservation can interact with ordinary deletion. It is not a statement of the current status of every order or dispute in that case.
Represent legal holds as explicit system state
For a proposed retention service, keep a record identifier, retention class, expiry, hold status, hold authority reference, and disposition history. Access to hold operations should be restricted and audited.
The ordinary expiry job should check for an applicable hold before deleting. Releasing a hold should trigger policy evaluation, not an automatic assumption that every retained object is immediately deletable.
Define how holds reach derived stores and backups. A flag in the main application database is insufficient if an independent job deletes the underlying object without consulting it.
Use synthetic records to test three paths: ordinary expiry, expiry blocked by an authorized hold, and disposition after release. Test failures and retries so an interrupted operation does not leave an unexplained partial result.
Ask vendors about the whole path
Ask which content and metadata are retained, which subprocessors receive them, and which endpoints or features differ. Request the scope of any zero-retention option rather than treating the label as a description of every service.
Ask how deletion reaches backups, what exceptions can suspend it, what notice is contractually available, and whether support access creates another copy. Record the answers with the contract version and configuration date.
If the workflow cannot tolerate an external retained copy, change the data flow or the service configuration. A generic privacy statement does not establish the behavior of a specific integration.
Self-hosting changes responsibility, not discoverability
Federal Rule 34 addresses discoverable material in a party's possession, custody, or control; Rule 45 addresses subpoenas, including to nonparties. Actual scope, objections, protections, and duties depend on the matter.
Running inference locally does not place records beyond those processes. It gives the operator more direct control over storage and deletion, while also making that operator responsible for implementing preservation correctly.
Notification and the route of a demand are not guaranteed solely by where a server sits. Have counsel define the applicable hold process, then implement and test that process without promising immunity or automatic notice.
Test deletion after a restore
Delete a synthetic record through the normal procedure, then restore an older backup into an isolated environment. Confirm how deletion records and holds are reconciled before the restored system can serve users.
Keep a disposition record that identifies the completed operation without unnecessarily retaining the deleted content.
The operational answer should explain what was removed, what remains, why it remains, and who can authorize the next step.
Frequently asked questions
Does on-premises AI make data immune from discovery?
No. Local records can still be subject to applicable preservation and production duties. Local operation changes who manages the storage and controls.
Is deleting the application record enough?
Not necessarily. Derived stores, logs, caches, backups, and any applicable hold need explicit handling and verification.