There's a critical AI risk most CIOs are overlooking, and may not even know about – leakage of sensitive or proprietary data through use of frontier models.
Frontier labs offer Zero Data Retention (ZDR) policies to address their usage of customer data – but these policies are narrower than their name suggests. A frontier lab can honor its zero data retention agreement and still retain some of your company's most sensitive data. The agreement may cover the model call while a file store keeps an uploaded design, an agent saves its transcript, or a connected tool receives a copy. Those extra stores create paths for proprietary information to be accessed or leaked.
The data in question is no longer just a prompt typed by an employee. It can be unpublished research, source code, customer records, or an internal plan. A CIO needs to know where that material goes after someone presses Enter, and who can use it.
ZDR has a defined boundary
Zero data retention, or ZDR, is a meaningful control. Under an approved ZDR arrangement, OpenAI excludes content from abuse-monitoring logs and disables stored responses for eligible API calls. Anthropic says it does not store prompts or responses at rest after an eligible API response. Both say commercial API content is not used to train their models without the customer's permission. Sending a prompt to a model does not, by itself, update the model's weights.
But ZDR agreement coverage depends on the organization, project, endpoint, feature, and model, and that coverage is not universal. For example, a developer's personal chat account is not necessarily covered by the enterprise's API terms. An application feature is not covered simply because it calls an eligible endpoint somewhere along the way.
Consider files. A document sent inline with an eligible request can be handled differently from one placed in a provider's Files API for later use. OpenAI lists files, vector stores, conversations, agents, and batch jobs among its ZDR-ineligible endpoints. Some of that application state can remain until it is deleted. Anthropic excludes its Files API, batch processing, managed agents, code execution, and some connectors. Its documentation says a ZDR organization can use certain ineligible features without the API automatically blocking them.
Then there are the less obvious traces. Prompt caches may keep temporary representations on GPU hardware. Background jobs and audio features may hold data briefly so the service can finish a task. Safety systems can retain flagged material under stated exceptions; Anthropic says some flagged inputs and outputs may be kept for up to two years, and certain models require a 30-day retention arrangement. External tools and MCP connections may receive the content under their own terms. None of these facts means that the information has been used for training. They do mean that “we have ZDR” is an incomplete description of the data flow.
The valuable part may not have your name on it
It is easy to focus on whether a lab keeps a copy of a document. Sometimes the more valuable asset is the reasoning inside it: how a scientist narrowed a problem, how an engineer found a performance shortcut, or how a company worked through an acquisition strategy. Removing names and account details would not necessarily remove that insight.
Could a provider learn from such work? For consumer services and accounts that permit training, yes, that is a plausible route. OpenAI says individual ChatGPT content may be used for training unless the user opts out, and that giving feedback can make the associated conversation eligible even after an opt-out. Commercial API data follows different default terms. If a novel method is included in permitted training data, a later model might absorb some of the method without reproducing the original document or identifying its author. That is a technological possibility, not evidence that a lab has taken a particular customer's work.
There are other, narrower forms of internal visibility. A provider may retain safety signals, operational metadata, or material in features outside ZDR. Such information could conceivably show what kinds of problems customers are trying to solve, even without exposing the full answer. It could inform decisions about which capabilities to build next. The public documentation does not establish that labs use those signals to copy customer innovations. CIOs should nevertheless ask what may be derived from customer activity, who may inspect it, and whether contractual limits cover those derivatives as well as raw prompts.
Retained data creates a second risk
Information does not have to enter a model to get out of the customer's control. A stored agent transcript can be exposed through a software bug or a compromised account. A connector can send content to a third party with a different retention policy. A shared link, permissive logging setting, or poorly secured retrieval system can make sensitive material available farther from the original application than anyone intended.
OpenAI disclosed a 2023 bug that let some users see other users' chat titles and, possibly, the first message of a new chat. That incident did not establish a ZDR failure or model training on customer data. Separately, researchers have extracted memorized training text from production language models. That result shows why it matters if sensitive material is ever admitted to training; it does not show that protected ZDR data was.
The distinction is important for a risk decision. There is no public proof that an eligible ZDR prompt automatically becomes knowledge in a shared model. There are documented ways for customer content to be stored outside ZDR, and those stores have ordinary access and security risks.
Put the most sensitive inference under your control
For CIOs handling valuable IP, the first step is to map actual workflows. Check the employee account, API project, model, file path, search index, cache, tool calls, logs, and deletion rules. Get the no-training commitment in writing – even though that alone is not sufficient to protect you. Test whether the application can invoke features that fall outside the agreed boundary. That exercise will usually tell you more than the ZDR label on a contract.
For workloads where even limited provider access is too much, consider sovereign inference on dedicated hardware with open-weight models you can deploy and control. The hardware can sit in your data center or a private cloud environment with a boundary you control. In a Cogniware sovereign deployment, prompts, documents, retrieval indexes, model artifacts, logs, caches, backups, and telemetry remain inside that boundary. Support access is controlled there too. Your team sets retention and access policies and reviews model updates, tools, and network egress. Dedicated hardware still needs sound security operations; it does not secure a poorly configured application.
This need not be an all-or-nothing model policy. Frontier APIs may still earn their place for work that needs their particular capabilities and can tolerate their data terms. Sensitive, repeatable inference can run on infrastructure you control. At Cogniware, we call this owning your inference. The Cogniware Inference Platform is designed to manage open-weight models and optimize throughput and latency on the infrastructure you choose. You decide which workloads ever reach a frontier lab.
