Data Controls for AI Systems

An insurer receives a claim packet after a storm. Inside are a claim form, photographs, a repair estimate, adjuster notes, and the customer’s contact details. An AI system can read the packet, pull out the facts, and hand back a clean summary in seconds.

The same company then asks a coding agent to improve the software behind that workflow. The agent reads the repository, studies the extraction logic, runs the tests, and proposes a patch.

The two tasks look different, but they create the same exposure. In each case, the system can help only if it is given material the company is bound to protect. In the claim workflow, that material belongs to a customer. In the coding workflow, it is the company’s own source code and operating knowledge.

Once either asset enters an AI system, most organizations ask a single question: does the vendor train on our data? That question settles only one issue. It tells you whether the vendor may use your material to improve its models. It does not tell you which copies the system keeps, how long they last, or who can read them. A more complete question asks what happens to the data at every step: while the model works, after it answers, and when someone turns the result into feedback. Framed this way, the review covers retention and access as well as learning. Retention and access are where most of the practical risk sits.

At e52, we design systems that connect AI to organizational data.^S1 This data is often sensitive. It is also what makes the system useful: a model that can read the live claim file can do more than a model restricted to redacted samples. Organizations hand over that kind of material only when the controls make it safe to do so. For that reason, we treat the controls as part of the system design, not an afterthought.

Three terms dominate the discussion of AI data handling: Training, No Training, and Zero Data Retention (ZDR). They are often read as weak, medium, and strong versions of a single protection, but they are not. The first two describe what a vendor may learn from your content. The third describes what a vendor may keep.

Term	What it means in practice
Training	The vendor uses your content, or feedback derived from it, to improve a model. That can shape how the model serves future users.
No Training	The vendor does not use your content to improve the model. It may still keep prompts, files, and outputs for product features, debugging, or abuse monitoring.
ZDR	The vendor does not store covered inputs and outputs after processing, subject to the exceptions in the agreement.

A vendor can promise no training and still keep a prompt for 30 days. It can offer ZDR on one API while storing data for another feature, such as a job queue or a cloud agent. No training is therefore not the same as no retention.^{S2 S3}

OpenAI’s API policy shows both promises at work in one product. API inputs and outputs are not used for training by default, but standard abuse-monitoring logs can hold customer content for up to 30 days. Approved ZDR configurations remove covered content from those logs.^S4

So every review needs to answer two questions:

1. Can the vendor use our content, or feedback derived from it, to improve a model?
2. What copies remain after the model returns its answer?

Training is not a single event. It is a sequence of processes, and each process can draw on customer content in a different way. A foundation model first learns broad patterns from a large body of data, then passes through a second stage where examples and feedback tune it for specific tasks.^S5

Learning from examples: one method uses examples with known answers. A page image is paired with the correct policy number, date, and damage category; a bug report is paired with a good patch.

Learning from preferences: another method turns preferences into a training signal. A reviewer picks the better of two summaries; a developer accepts, rejects, or edits a patch. The human never adjusts the model directly. The recorded ranking trains a separate reward system. That reward system then teaches the model what “better” looks like.

Not every reward comes from a person. A document model can be scored when its extracted fields match a reference, or when a generated format compiles. A coding model can be scored when the tests pass. Research on document Optical Character Recognition (OCR) uses such verifiable rewards to improve formula and table extraction.^S6

This mechanism is why ordinary product usage data matters. “The user accepted this diff” looks like a harmless usage event; it is also a high-quality training label. “The reviewer corrected this claim field” is operational data that can become a training example. Whether a vendor can make that move depends on the product setting and the contract.

The labels “training” and “not training” describe what a model learns from your data. Most enterprise risk comes from something those labels do not cover: the copies an AI product makes of your data while it works. A modern AI product is a system built around a model rather than the model alone. Its components index repositories, run jobs, queue requests, collect diagnostics, and screen traffic for abuse. Each of these functions can make a copy.

System action	Why the product does it	What can remain
Answering	The model reads context and generates an answer.	Nothing durable when ZDR applies.
Indexing	The product makes code or documents easier to search.	Search indexes, file names, and other metadata.
Cloud agent	The agent needs a working environment over time.	An encrypted repository copy and session state.
Queued work	The request waits until compute is available.	Input data in a queue until processing.
Abuse review	A classifier flags traffic for safety review.	The flagged input or output, sometimes for 30 days.
Training	The system learns from examples, rankings, or test results.	An effect in model weights or a reward model.

ZDR narrows this surface, but it cannot make the whole product stateless. Several of these functions exist precisely to hold state. A coding editor may protect model requests while keeping a search index of your repository. An API may discard live requests while holding queued ones. A cloud agent cannot work for an hour without holding its workspace somewhere.

The goal organizations should strive for is not to demand that every system forget everything; it is to know which copy supports which feature, how long it remains, and who can read it.

ZDR is not the only responsible choice, and it is not sufficient for every sensitive workload. The right control depends on what the system reads and on what would happen if that content were retained, reviewed, or exposed.

Sensitivity	Example	Reasonable starting point
Low	Public material, synthetic test data, or a published code sample.	No-training can be enough. Bounded retention can support history, debugging, and abuse controls.
Confidential	Internal documents, private source code, or ordinary customer correspondence.	No-training by default, short retention, administrator controls, and a clear deletion period.
Sensitive	An insurance claim with personal details, unreleased product code, or data covered by a customer contract.	ZDR on every eligible endpoint, restricted features, and verified provider coverage.
Highly restricted	Regulated records, export-controlled data, secrets, or workloads with strict residency requirements.	Dedicated or self-hosted infrastructure, private networking, strong access controls, and minimal logging. ZDR alone may not answer where processing occurs or who can operate the system.

The same workflow can cross several of these tiers over its life. In development, a claim form with synthetic fields can run on standard retention. In production, a live packet can require ZDR. A packet with medical records can require a dedicated environment and extra contractual controls.

The goal is protection in proportion to the sensitivity of the data. Do not pay the product cost of ZDR when the data is public and history is useful. Do not accept a no-training promise when the use case requires that the vendor keep no copy.

The company you sign with is not always the company that runs the model.

When a company calls the OpenAI API, the relationship is direct: OpenAI develops the model, provides the API, runs the service, and sets the data controls. Other products add a layer. An application vendor can collect your context and call model providers behind the scenes. A hosting platform can run a third-party model without sending prompts back to the model’s creator. A cloud platform can offer models from several labs under one roof.

An assessment should therefore name three roles separately:

• Application provider: builds the app, agent, or interface you actually use.
• Hosting provider: runs the computers that process your request.
• Model lab: created the model and may set model-specific terms.

One company can fill all three roles, or three companies can share them. No-training and ZDR promises have to cover every company that receives your content. The roles also raise a question about hardware rather than contracts: on whose computers does the processing actually happen? Your content either stays on the machines of the company you signed with, or it travels to a second company’s machines. If it travels, a second company’s rules now apply to your data.

The three products below are examples. We chose them because each stands for a different relationship between an organization and a model: calling the model lab directly (OpenAI), running models on a cloud platform (AWS Bedrock), and working through an application built on model providers (Devin). Together they cover the range of boundaries an organization is likely to meet.

Each description draws on the vendor’s public policy pages, current as of 20 August 2026. A signed enterprise order can provide different or stronger terms.

7.1 OpenAI: direct access to the model lab

The OpenAI API is the simplest path of the three. You call the company that develops and serves the model; no application vendor sits in between.

OpenAI says it does not train on business-product or API inputs and outputs by default. An organization must explicitly opt in before OpenAI can use that content to improve its models.^{S10 S12} That is a no-training commitment straight from the model lab.

Retention is governed separately from training. Standard abuse-monitoring logs can keep prompts, responses, and classifier outputs for up to 30 days. Qualifying customers can request ZDR, but approval is required and coverage varies by feature.^{S4 S11} The core chat and response APIs qualify. Features that save state (stored conversations, uploaded files, fine-tuning jobs, evals, batch jobs) follow different rules, and several are not ZDR-eligible.^S11

The takeaway: dealing directly with the model lab makes the chain easier to inspect, but it does not make every OpenAI feature stateless. Organizations still have to separate no-training, abuse logs, and saved application state.

7.2 AWS Bedrock: the model maker and the host can differ

Bedrock shows why “who made the model?” and “who runs the model?” are different questions. AWS says it copies each model provider’s software into locked-down AWS accounts and runs it there. AWS also says the providers cannot enter those accounts, read Bedrock’s logs, or see customer prompts and completions.^S13

As of this snapshot, the catalog includes OpenAI’s GPT-5.4, GPT-5.5, the GPT-5.6 family, and open-weight GPT models, all served from Bedrock.^S16 AWS describes the whole catalog the same way: models built by the labs, run on AWS infrastructure. It does not describe ordinary Bedrock traffic as a pass-through to each provider’s own service.

Bedrock also lets you choose what happens to your data after each request.^S14 At the strictest setting, AWS keeps nothing and shares nothing with the model provider. At the default setting, AWS may keep data for safety and abuse checks, but the model provider still does not receive it. A third setting exists because a few models require AWS to share request data with the provider. Those models work only if you allow the sharing.

Sharing data with the model provider does not mean the computing leaves AWS. It means a second organization receives your prompt or its answer, and that organization’s policies now matter too.

AWS says it does not use customer inputs and outputs to train foundation models.^S13 Administrators can lock the strictest setting for the whole organization; models that require sharing then become unavailable. Abuse-detection exceptions remain: some flagged traffic can be kept for up to 30 days.^{S14 S15}

The takeaway: Bedrock can keep both the computing and your content inside AWS, or it can share data with a model provider for specific models. Your retention setting, and what each model allows, decides which path applies.

7.3 Devin (by Cognition): an application layer over model providers

Devin, made by Cognition (devin.ai), is an autonomous coding agent, so it needs more than a one-time model call. It holds your repository and its working notes while it plans, edits, and tests. Cognition is the application provider and does not run the models itself; your prompts and code context travel to the model providers’ systems behind the scenes.

Cognition’s platform terms say Customer Data may be used for model training by default. Paid customers can opt out, and opting out also turns on ZDR with Cognition’s model providers. On the Teams plan, an administrator controls the opt-out.^{S7 S8} That ZDR promise covers the model providers’ systems; what Cognition itself keeps is a separate question. The Enterprise language is stronger: Cognition says it will not train on enterprise data without prior written consent, and dedicated deployments keep customer data in the customer’s own environment.^{S8 S9}

The boundary still has exceptions. Cognition’s definition of ZDR allows retention for flagged abuse, security review, and legal process. Its public security page also says feedback and product-usage data may be retained as needed.^{S7 S8}

The takeaway: a ZDR promise from the model providers covers one layer. Organizations also have to inspect the code, session, and feedback data held by the application provider.

The comparison becomes simpler when it starts from the relationship rather than from the model name. A direct model-lab API, a cloud model platform, and an agent application create three different data paths. The path determines which copies exist to inspect.

	OpenAI	AWS Bedrock	Devin
Relationship	Direct to model lab	AWS runs models from several labs	Application over model providers
Where your request is processed	OpenAI’s own systems	AWS’s own systems	Forwarded to the model providers’ systems
No-training path	Business and API default	Default for model traffic	Paid opt-out; stronger Enterprise terms
ZDR path	Approved, eligible endpoints	Strictest retention setting	With model providers after opt-out
Copies to inspect	Abuse logs and saved state	Model exceptions and provider sharing	Sessions, feedback, abuse holds

Vendors describe their plans with labels such as No Training and ZDR. These labels do not tell you what the system actually does with your data. So a good review starts from the data and follows it along the whole path: into the system, across the companies that handle it, and out into whatever copies remain. Five questions cover most of that ground:

1. What enters the system? Customer documents, source code, feedback, or all three?
2. Who receives it? Which companies are the application provider, the hosting provider, and the model lab?
3. Where does it physically go? Does your content stay with the company you signed with, or travel to a second company’s computers?
4. What remains after the answer? Which copies are kept, for how long, and who can read them?
5. What is learned? Can your content, or your team’s accepts, edits, and corrections, become training data?

The five questions also apply inward, to your own systems. Your application receives the data before any vendor does and handles the answer after the vendor returns it. Whatever it logs at those two moments is a copy like any other, and it deserves the same review.

The answers to these questions decide which controls fit. In choosing them, aim for balance rather than maximum restriction. Every control carries a cost as well as a benefit. ZDR on public data buys little and costs useful features. A no-training promise on sensitive data leaves every retained copy in place. Most mature postures mix the tiers: bounded retention where history helps, ZDR where sensitivity demands it, dedicated environments where regulation requires it.

No Training limits what a model can learn from your work. ZDR limits the copies that remain after the work is done. Neither one covers the system in between, and the system in between is where most of the risk lives.

Consider the claim packet and the codebase one more time. For the claim packet, a good outcome is easy to state: the document, and every correction a reviewer makes to it, should move only through systems the company has examined and approved. For the codebase, two things need protection: the source code itself, and the accept-or-reject decisions developers make, because those decisions can become training data. The customer whose storm damage fills that packet never chooses an AI vendor. The company chooses the vendor on the customer’s behalf. Deliberate data controls are how organizations honor that responsibility.