Zero Data Retention: What the Contract Says
Zero data retention (ZDR) is an enterprise-tier commitment from model providers that prompt and response data will not be logged, stored, or used after the API call completes. OpenAI, Anthropic, Google, and Microsoft Azure OpenAI all offer ZDR or equivalent terms under enterprise agreements, either as a default for API customers or as an explicit data processing addendum (DPA).
ZDR is a contractual commitment, not a technical architecture. The provider is attesting to a policy. You cannot independently verify it. Your audit trail ends at the API boundary.
Most providers maintain system-integrity logs for abuse monitoring and reliability even under ZDR: API call metadata, latency records, error codes, account identifiers. These logs typically don't contain prompt content. But they do exist, and they are potentially subpoenable. "Zero data retention" means the prompt content wasn't kept. It does not mean the call didn't happen, and it does not mean the provider's infrastructure left no trace.
In a legal hold scenario, knowing which scenario applies (no records, metadata only, or full content) requires knowing exactly what your enterprise agreement covers and what the provider's system-integrity logging actually retains. The DPA is the document that answers this. Not the marketing page.
Regional Endpoints and Data Residency
Data residency for AI is more complicated than for SaaS storage. When you write a file to an EU-region bucket, the data sits in a known geography. When you send a prompt to an EU-region AI endpoint, the data is processed there, but inference involves infrastructure that may span availability zones in ways providers don't fully disclose. Residency covers where data rests. Inference involves movement, and logging may not follow the same boundary.
The major providers now offer regional endpoints for EU, US Government, and in some cases sovereign cloud configurations. Azure OpenAI Service publishes EU Data Boundary commitments. AWS Bedrock offers GovCloud deployments. What "data residency" actually guarantees in each configuration varies by provider and by the specific DPA. Two agencies can both claim "EU data residency" for their AI deployments and have meaningfully different actual commitments, depending on which addendum version they signed and when.
For public sector accounts, the coherence question matters: a GovCloud endpoint for storage and a commercial endpoint for AI inference is not a coherent data residency posture, regardless of what the individual agreements say.
Prompt-Boundary DLP
Data loss prevention at the prompt layer works the same way email DLP works: pattern matching and content classification on outbound data before it reaches the destination. The control scans prompt content for defined patterns (Social Security numbers, clearance indicators, contract numbers, PII categories) and either blocks the call, redacts the sensitive content, or logs an alert for review.
It catches structured sensitive data matching known patterns. Context that's sensitive only in aggregate mostly slips through. A sequence of prompts that individually contain no PII but collectively describe an active investigation, a personnel action, or a source relationship won't trigger most DLP rules. Prompt-boundary DLP is a floor, not a ceiling, and the ceiling is where the interesting exposure lives.
Legal will eventually ask whether the DLP policy governing AI prompts is maintained by the same team that owns the enterprise DLP policy for email and file transfer, or whether AI has its own policy silo. The answer matters when someone asks for a unified data handling attestation.
The Providers-by-Regions-by-Retention-Policies Matrix
Legal teams maintaining AI governance posture need a working map: which providers the organization uses, which regional endpoints are configured, what the enterprise agreement says about training data opt-out, and what the DPA says about retention periods. This is the matrix, and it requires active maintenance because providers update their terms on their own schedule.
The matrix needs updating when a provider adds a regional endpoint, changes its default retention period, modifies training data opt-out terms, or releases a new model that falls under different data handling commitments than the previous version. That last one is the trap. An enterprise agreement scoped to a specific model version may not automatically extend to a successor model, depending on how the agreement is written.
Training data opt-out deserves precision here. Enterprise-tier agreements typically commit that customer data won't be used to train future models. The mechanism is usually a configuration flag or an explicit DPA clause. Opt-out means your prompts won't be used for fine-tuning or reinforcement learning. It doesn't govern every system your data touches during inference. The contractual/technical distinction applies here exactly as it does to ZDR.
When an agency receives a subpoena for AI-related records, the response depends entirely on what the matrix says and whether it's current. If the provider has ZDR and the agency has no local prompt logging, there may be nothing to produce beyond system-integrity metadata. If the matrix is stale and the configuration drifted, nobody knows. That's the failure mode.
Okta Concept Mapping: Session Termination
ZDR resembles a session that terminates cleanly and leaves no artifact: the call completes, the data is gone, similar to how Okta session termination clears a token and ends the record. The analogy holds for the bounded-transaction concept. Past that, it stops working. Okta session termination is a technical event you can verify from your side. The session log shows the end state. ZDR is a provider-side commitment you cannot independently verify. Your visibility ends at the API boundary, and the provider's compliance with their own policy is attested, not observable.