There is an unspoken rule in the industry: even if a vendor promises ZDR, don’t trust it completely. The vendors aren’t lying; it’s just that the scope guaranteed by this phrase is far smaller than imagined. In many cases, you think you have a solid wall in front of you, but the vendor has only given you a door—one that can be opened under certain conditions.
ZDR stands for Zero Data Retention. In plain terms, it means that after the model finishes inference and returns the results to you, the service provider will not write the prompt you provided and its response to persistent storage. In OpenAI’s ZDR service announcement, the company specifies that this feature is only open to eligible API customers; once requests are processed, prompts and completions are not retained, content is not available for employee review, and enterprise customer data is not used to train models unless customers explicitly opt in.
There was a real incident in the summer of 2026. Anthropic offered enterprise ZDR arrangements. But in June of that year, they changed their policy for their most capable frontier models, mandating a 30-day data retention period. During the months that change was in effect, even if you had previously signed a ZDR agreement, calling these models meant your data was still temporarily stored in their systems for 30 days. Following customer pushback, CNBC’s report on Anthropic’s data retention controversy noted that in September, the company introduced Enterprise Frontier Safeguards, allowing enterprises to control how their data is reviewed and stored without Anthropic’s human review.
The ZDR clause in the contract was still there, but the protection you took for granted was gone. The vendor didn’t need to tear up the commercial contract; simply modifying the list of applicable frontier models rendered the original safeguards moot.
Some might ask: isn’t this the vendor playing tricks? As of now, no vendor has been publicly caught deliberately deceiving customers about ZDR, nor has any been penalized by regulators for secretly saving customer data while claiming ZDR support. The risk of data exposure does not stem from vendors breaking their promises. The mechanisms that may cause data to be retained, viewed, or extracted are often already spelled out in the exceptions of the ZDR agreement.
So the vendors’ ZDR promises are not fraudulent, but they amount to only a very brief statement: requests are not written to disk after processing. Beyond that, your data can still enter caches, undergo moderation, or be subpoenaed in legal proceedings. There are only two things you can actually verify yourself: sensitive data was never sent out, or the model runs on your own machines. If you care about security, look at the architecture, not just the promises.
When software engineers write business code, they often call APIs as casually as invoking regular functions. If you assume that flipping a security switch seals the entire network lifecycle like an airtight vault, you are likely mistaken about where your data goes.
The real path of a network request: the client initiates the request; data arrives at the cloud vendor’s ingress gateway; the gateway sends the text into the GPU memory of the compute cluster; the model performs inference; and the generated response text is transmitted back to the client over the network.
The scope covered by ZDR applies only after request processing is complete: the service provider guarantees that it will not statically retain the inputs and outputs of that request thereafter. Beyond this scope, several things must be made clear.
First, let’s clarify the most common confusion: not training on data does not equal ZDR. OpenAI does not train on enterprise customer data unless customers explicitly opt in, and Anthropic’s API data retention documentation also states that retained data is not used for training without explicit authorization. The promise of not training on data is more common and easier to fulfill; ZDR is stronger, guaranteeing that within its covered scope, inputs and outputs are not statically retained once the request is processed. If data is not retained, there is no question of it being used for training later. Conversely, retained data does not mean it can be used for training—it still requires explicit customer authorization.
Second is application state. Building agentic systems inevitably requires conversation history and memory. In OpenAI’s platform data usage guide, the company lists a set of non-ZDR endpoints, including conversations, assistants, threads, vector stores, and batch processing interfaces. Even if the primary account has ZDR enabled, invoking these endpoints means the system may still store application state. For objects created via the Assistants API, after you actively delete them, the backend purges them after 30 days; if you don’t delete them, they are kept indefinitely.
Third is security monitoring and human intervention channels. Enabling ZDR is not something you can simply check off in the console. OpenAI’s documentation makes it very clear that this type of security permission requires prior vendor approval and is only open to eligible API customers. By default, all API function invocations generate abuse monitoring logs.
Fourth is exception handling for advanced features. Anthropic explicitly states in its documentation that when developers enable advanced features not covered by ZDR, you have chosen to exempt those specific data from ZDR constraints.
After understanding the cross-section of the invocation lifecycle, engineering teams often ask: why is it still possible for sensitive code or credentials to remain on remote servers? Because ZDR has never been an airtight shield; across security defenses, system performance, and legal jurisdiction, it leaves fully compliant pathways for data.
The first crack comes from abuse monitoring. This is an automated screening system deployed by vendors to prevent cyberattacks and policy-violating content. OpenAI generates monitoring logs for all API function calls by default. According to OpenAI’s public disclosures, such logs are retained on servers for up to 30 days by default, unless otherwise required by law.
Once automated rules determine that an invocation might involve a violation, retention on the servers can become much longer. Anthropic’s policy on data storage also notes that if a conversation triggers their safety rules, the plaintext conversation may be retained for up to 2 years, while associated trust and safety classification scores may be kept for up to 7 years.
For the most cutting-edge, capable models, vendors may even eliminate the standard ZDR option under certain circumstances. Anthropic’s data retention policy for covered frontier models explicitly points out that frontier models like Fable and Mythos mandate 30-day data retention, and ZDR is not supported across the entire platform unless specifically authorized by Anthropic. In cloud distribution channels, the AWS Bedrock data retention configuration guide also states that invoking one of them requires enabling aws_review mode, where data is retained within the AWS boundary for up to 30 days and may be subject to AWS human review; in none/default mode, the model cannot be invoked at all.
Beyond the model vendor itself, the cloud infrastructure traversed by the request may also retain records. Taking the OpenAI private safety processing developer documentation as an example, this mechanism saves encrypted records in cloud storage within the customer’s own region and retains them for 30 days. Revoking key authorization later can prevent subsequent decryption, but this action will neither delete files that have already been saved nor undo processing that has already completed.
The second crack stems from performance optimization. To reduce latency and overhead, LLM services utilize prompt caching. Caching, put simply, means temporarily storing data in physical media. According to OpenAI’s documentation, prompt cache KV tensors are held in GPU local memory and expire after 24 hours, while asynchronous background processing modes write to disk for approximately 10 minutes. Within these windows, cached tensors or background processing data remain present on hardware media.
The third crack is the hard boundary of commercial agreements. Regardless of what commercial terms of service say, they must yield in the face of judicial regulation. OpenAI’s law enforcement policy statement clarifies that upon receiving a valid legal request, the service provider will preserve user data for up to 90 days, with an extension of another 90 days under certain conditions; obtaining user communications requires a search warrant. ZDR commitments do not exclude such legal preservation requirements.
When procuring LLM services, many teams treat third-party compliance certifications as technical safeguards. Mistaking an audit seal for a security wall often leads them to overlook the fundamental verification principles of software engineering.
In VGS’s data security analysis post, VGS highlighted a deeper paradox: you cannot audit what does not exist. Even the most diligent auditors, upon entering a data center or inspecting a system, can only confirm that the operational logs, access controls, and encryption workflows before them meet standard specifications. No audit tool can prove to you that code snippets or trade secrets from a specific request have been thoroughly erased across the memory of tens of thousands of vendor servers and all backup media.
Industry credentials also have clear limitations. PremAI’s discussion on the limits of SOC 2 certification points out that Service Organization Control reports—commonly known in the industry as SOC 2 Type II reports—cover only internal operational procedures and in-transit encryption mechanisms; ISO 42001 is a management system standard. Passing certification indicates that the provider has established relevant management processes, but it provides no real-time verification of the instantaneous erasure of physical data.
What you can verify yourself, what can only be contracted, and what relies solely on trust represent three entirely distinct tiers. The foundational architectural tier is the only physical reality you can technically verify. Only two situations offer certainty: either sensitive information is sanitized before leaving your controlled internal network so hazardous data is never sent in the first place, or the model image is fully deployed on private hardware under your control, where the system produces results normally even if you pull the network cable. The middle tier is commercial contracts, primarily relying on documents like Data Processing Agreements (commonly known as DPAs). The purpose of a contract is to delineate rights, duties, and breach liabilities, providing grounds for recourse and claims after an incident occurs. This enforceability is entirely retroactive; while data travels across the public internet, several sheets of paper cannot provide the defensive barrier of a single line of code. The top tier—certification endorsements—whether compliance badges on a vendor’s website or annual process reports issued by third-party auditors, is fundamentally subjective trust and cannot replace objective defenses.
The evolution of open-source runtimes confirms this tiering. In Ollama’s privacy policy, the project commits that when users run Ollama locally, the platform sees none of their prompts or data; cloud endpoints only process prompts and completions temporarily, never use them for model training, and do not sell data. This local security is guaranteed by the physical reality of code running under local control. The project also offers cloud access capabilities and assures users in Ollama’s pricing and service terms that prompt and completion data will not be logged or used for training, while requiring partner NVIDIA Cloud Providers to strictly adhere to no-logging, no-training, and ZDR policies.
Regarding virtually identical security phrasing, another security competitor offered a sober critique in ModelPiper’s commentary on Ollama’s cloud privacy mechanisms: this cloud privacy mechanism is protected by promises rather than by architecture. Once a compute request is sent to the cloud, it leaves the developer’s realm of control and reverts to a scenario dependent on external trust.
Understanding the limitations of ZDR promises doesn’t mean giving up on LLMs altogether, nor does it justify running completely exposed in production. Pragmatic engineering practice means establishing tiered architectural responses after recognizing technical boundaries.
Before deploying code that uses LLMs to production, consider the following five questions: First, is the invocation endpoint truly within the official scope of ZDR coverage? Check your business invocation chains to ensure you haven’t unintentionally used assistants endpoints, vector stores, or frontier models absent from the ZDR list. Second, is your business data prone to triggering abuse monitoring mechanisms, and how long is the prompt cache retention window? Understand the state of OpenAI’s prompt cache KV tensors being temporarily held in GPU local memory and expiring after 24 hours, and assess whether this conflicts with your compliance baseline. Third, are there unnoticed subprocessors throughout the entire invocation chain—namely third-party cloud providers supplying compute or storage on behalf of the LLM vendor? Find out whether data is backed up to other regions, and when physical data actually perishes after decryption keys are revoked. Fourth, does your system gateway layer possess the capability to sanitize data before it leaves the internal network? Intercept all internal user identifiers, database connection strings, and private communication keys locally, replacing real information with synthetic placeholders. Fifth, if a vendor suddenly alters its data retention rules, does your system architecture maintain an exit strategy to switch at any moment? Can the orchestration layer pivot smoothly to another vendor or fall back to a local model?
For different use cases, the watershed in technical decision-making lies in knowing when simply switching vendors suffices versus when architectural refactoring is imperative. If a system primarily handles routine public discussions, low-sensitivity drafts, or low-value text, choosing a reputable mainstream cloud vendor with ZDR enabled strikes a practical balance between engineering efficiency and commercial protection. In low-consequence scenarios, minor shifts in vendor security policies have limited impact. However, when handling high-consequence assets such as core system source code, unreleased patents, key commercial contracts, real employee identities, or medical and financial information, hopping from one cloud vendor to another is meaningless; no paper agreement can substitute for a technical firewall, and the only solution is to upgrade the system architecture directly. As noted in Fortune’s reporting on enterprises turning to open-source models and isolated access, enterprises, after weathering data retention turmoil with frontier models, have turned toward open-source models or isolated access via Amazon Bedrock.
What the industry often refers to as ZDR is ultimately just plain engineering common sense. An LLM’s ZDR policy is merely a commercial legal contract; it cannot serve as a technical firewall. What truly determines whether data can be retained is the system’s architectural design.