Law-Firm AI Data Retention Policy by Model Surface and Feature

Retention matrix by surface and feature

One workflow needs multiple retention fields

1. Prompt and response training use.
2. Abuse or safety-monitoring logs.
3. Conversation or agent state.
4. Uploaded files and generated artifacts.
5. Explicit and implicit caches.
6. Grounding, search, maps and connector data.
7. Application, proxy, observability and support logs.
8. Backups, deletion exceptions and legal preservation.

Tie the matrix to matter classification

Define which public, internal, confidential, personal, privileged, regulated or restricted material may enter each workflow. The label alone is not the legal conclusion; it routes the request to the firm’s reviewer, client terms and jurisdiction-specific analysis.

Require deletion and configuration evidence

Keep the provider source, executed documents, project and account IDs, endpoint, model version, enabled features, retention values, exception basis, test trace, deletion result, owner and next review date. A statement in a sales email is evidence to investigate, not a substitute for the operative record.

Treat every model or feature change as a retention event

A new model can introduce a covered-model rule. A grounding feature can create a fixed storage period. A connector can add another processor. A product migration can change the agreement. Re-run the matrix before enabling the change for an approved data class.

Start with a data-flow inventory

For each approved workflow, draw the path from the user’s device to identity, application, model endpoint, tools, storage, tracing and final system of record. Name what crosses each boundary: prompt text, files, retrieved sources, metadata, outputs, tool arguments and logs. Then attach a retention field and owner to every copy. A provider’s ZDR configuration cannot delete an application log that the firm created upstream.

Shadow tools belong in the inventory as an observed control gap, not an assumption that every user has exposed confidential data. Collect approved-product telemetry and staff input through the firm’s reviewed process. The first goal is to identify routes and educate users, then decide which require restriction, migration or a safer approved path.

Distinguish expiry, deletion and proof

An automatic expiry period, a user-initiated delete action and a contractual deletion commitment are different controls. Record what starts the clock, whether deletion covers files and derived artifacts, which backups or safety records remain, and how the buyer can verify completion. If the provider does not expose evidence, note the contractual representation and the verification gap rather than treating it as a tested result.

Test with a canary project that contains no sensitive material. Upload a uniquely named file, generate an output, create any relevant cache or state, then follow the documented deletion sequence. Check the application, provider console, API and downstream system. Preserve screenshots or logs with the date and account identifier.

Route preservation conflicts to the matter owner

Deletion is not always the only requirement. A matter may have client instructions, records obligations, investigation needs or preservation directions that affect prompts, outputs and audit logs. The policy should not guess the result. It should identify the system of record, the person who decides whether an artifact must be retained, and the method used to place or release any applicable hold.

Avoid making the vendor conversation history the only record of substantive work. Preserve reviewed work product, sources and approvals in the firm’s designated repository according to the matter decision. That separates the operational need to retain a final record from unnecessary persistence in an AI interface.

Make the policy usable at the point of work

Attorneys and staff need a short answer before they paste or upload: which approved account, which data class, which features, which destination and which reviewer. Provide a one-page route card for each approved workflow. Link it to the full matrix for privacy and security owners, but do not expect every user to interpret provider terms during a live matter.

Configure the product to reinforce the policy. Restrict consumer accounts where appropriate, use managed identity, disable unnecessary tools, set project defaults, separate test and production projects, limit write permissions and give users a visible escalation path. Training without product controls makes the user carry every decision alone.

Use change triggers and a fixed review cadence

Review the matrix on a scheduled cadence and after a material event: new model, endpoint, account tier, region, connector, grounding feature, cache, logging option, subprocessor, terms update or security notice. Record the old value, new value, affected workflows, decision owner and any required regression or deletion test.

Monitoring should measure whether the operating policy works. Useful signals include use of unapproved accounts, workflows missing an owner, projects without a current source record, failed deletion tests, permission drift and overdue reviews. Those are control signals, not proof of confidentiality harm or legal noncompliance.

Connect retention to incident response

If an unexpected copy is discovered, preserve the facts needed for review: account, project, user, time, data class, provider route, feature, downstream systems and actions already taken. Follow the firm’s reviewed incident process and avoid expanding access while investigating. The correct notification and preservation steps depend on the facts and applicable duties.

Read provider documentation at the endpoint level

OpenAI’s technical data-controls page presents endpoint tables, default abuse-monitoring retention and eligibility or limitations for Zero Data Retention and Modified Abuse Monitoring. The correct row depends on the API used. A general statement about the OpenAI API should not replace that endpoint-level check, and third-party MCP or network services introduce their own terms and retention.

Anthropic’s Covered Models guidance creates a model-class exception to a generic ZDR assumption. The page says designated covered-model prompts and outputs are retained for 30 days across named platforms unless the organization qualifies for an exception. The firm should record the model, platform and eligibility evidence rather than extending one workspace’s status to every Claude route.

Google’s Gemini documentation separates paid-service product-improvement restrictions from abuse logging and feature storage. Search and Maps grounding carry documented 30-day storage; stateful APIs, file storage and explicit caches have separate controls. The project approval and the feature inventory must therefore sit in the same record.

Give every retention row an owner

Privacy or counsel may own the legal interpretation, security may own logs and incident evidence, platform engineering may own project configuration, legal ops may own the workflow and records team members may own the final repository. Assign the person or function responsible for verifying each row and the person who can approve an exception. Otherwise the matrix becomes a research document with no operating effect.

Ownership also reduces unnecessary central review. Once a bounded workflow, data class and configuration are approved, users can follow the route card. Changes that cross the documented boundary return to the appropriate owner instead of becoming informal exceptions.

Publish a route card for each approved workflow

Measure control performance, not only document completion

Track the percentage of approved workflows with a current source check, named owner, tested deletion path and complete feature inventory. Record permission drift, expired reviews, unexpected copies and attempts to use unapproved routes. When a change occurs, measure how long it takes to identify affected workflows, pause them if necessary, complete regression and approve or reject the new configuration.

These measures show whether the operating policy is maintained. They do not establish legal compliance, privilege preservation or the absence of harm. Preserve those distinctions in reports and executive dashboards.

Minimum operating policy

Permit only named workflows and data classes. Require approved accounts, least-privilege features, a human reviewer, a system of record, tested deletion and an incident owner. Review living documentation on a fixed cadence and after a material vendor notice. Do not promise zero retention unless the complete path has been tested and the remaining in-memory or exception boundaries are disclosed.

FAQ

How long do AI providers retain law-firm data?

There is no single answer. Retention varies by provider, account, endpoint, model, feature, configuration, agreement and customer-side system.

Is no training the same as zero retention?

No. Product-improvement use and retention for safety, state, files, caches, grounding or downstream logging are separate.

What should a retention policy preserve?

Keep the source, contract, exact configuration, data class, test evidence, deletion result, owner and review date for every approved workflow.

Sources checked

• Gemini API zero data retention, checked 2026-09-03.
• Covered Models retention practices, checked 2026-09-03.
• OpenAI platform data controls, checked 2026-09-03.

Operational information, not legal advice. Verify current terms, account configuration and applicable professional duties before use.