Zero Data Retention is not enough: the real problem with governing enterprise AI

The conversation around AI governance often starts with the wrong object.

A company discovers that employees are using ChatGPT, Claude, Gemini, or agents connected to internal systems, and the immediate reaction is to build an AI-specific policy, a new committee, an approved-model catalog, and a long list of prohibitions.

But there is an earlier and more important question:

What data can each person or agent access, under which identity, for how long, and what actions can it perform on that data?

That is one of the central ideas in Platzi’s video El costoso error de gobernar AI en empresas: risk does not live only inside the model. It lives in the data, access controls, permissions, and integrations surrounding the model.

The analogy is useful: companies did not create an “Excel department” when spreadsheets became ubiquitous. Excel became a horizontal tool governed by the same identity, access, audit, and data-classification rules as the rest of the enterprise environment.

AI is likely to follow a similar path.

The difference is that AI — especially agents — can dramatically amplify the impact of a bad configuration.

Information verified on September 27, 2026. Vendor retention and security policies change quickly; always review current contractual and technical documentation before making a production decision.

The concept becoming increasingly important: Zero Data Retention

Zero Data Retention (ZDR) describes a mode in which a provider processes a request, produces a response, and does not retain the content of that interaction after processing is complete, within the exact scope defined by the service.

OpenAI, for example, currently describes ZDR for eligible API customers as a commitment under which prompts and model responses are not retained after the request is processed and customer content is not available to OpenAI personnel for review.

Source: OpenAI — Offering Zero Data Retention for frontier models

The idea is powerful because it changes the risk model:

without ZDR

enterprise
   │
   ▼
AI provider
   │
   ├── processes
   └── retains for a period

versus:

with ZDR

enterprise
   │
   ▼
AI provider
   │
   ├── processes
   └── does not retain the content
       after processing within the
       contracted ZDR scope

For sensitive workloads — private code, legal documents, customer data, internal research, or financial information — reducing persistent copies is a valuable security property.

But the first critical distinction appears here.

ZDR is not the same as “we do not train on your data”

These two policies are constantly confused.

No training means the provider does not use prompts and responses to train or improve its models.

Zero Data Retention says something stricter about persistence: the content is not stored after processing, within the ZDR scope.

A platform can perfectly well offer:

no training = yes
retention = 30 days

That is not ZDR.

OpenAI does not train on business data by default. API abuse-monitoring logs are generally retained for up to 30 days, with legal and safety exceptions. Application state has endpoint-specific lifetimes; some objects persist until deletion. ZDR requires approval and does not cover every capability or exception, so the current technical matrix must be checked.

Sources:

• OpenAI — Enterprise privacy
• OpenAI — Business data privacy, security, and compliance
• OpenAI — Data controls and endpoint retention

So:

NO TRAINING
does the provider use this data to improve models?
            │
            ▼
           no

ZDR
does the provider persist this content after
processing the request?
            │
            ▼
           no

They are different properties.

ZDR also does not mean “the data never leaves the company”

The model still needs to receive the prompt in order to process it.

So even with ZDR:

1. content is transmitted to the service;
2. the provider’s infrastructure processes it;
3. a response is generated;
4. the content stops being persisted according to the ZDR service terms.

ZDR reduces retention. It does not eliminate remote processing.

And it cannot automatically protect copies created outside that boundary.

For example:

user
  │
  ▼
internal application
  │
  ├── local logs
  ├── tracing
  ├── database
  └── analytics
  │
  ▼
ZDR API

If the internal application stores every prompt in logs for a year, enabling ZDR at the model provider does not remove that copy.

The same applies to external tools, connectors, observability systems, or plugins participating in the workflow.

That is why ZDR is one component of a privacy architecture, not a complete privacy architecture.

The more dangerous problem is still who can access what

Suppose an employee should only be able to read one specific folder.

If an AI assistant is connected to a much larger document repository with a credential capable of reading everything, we have created an inconsistency:

human
  │
  └── can read 20 documents

agent used by that human
  │
  └── can read 200,000 documents

Even perfect ZDR would not make that design safe.

The right question is not:

“Do we trust this model?”

It is:

“What is the maximum damage this identity can cause if something goes wrong?”

Microsoft frames this by treating every agent as a first-class principal: its own identity, explicit roles, minimal permissions, controlled tools, and end-to-end auditability.

Source: Microsoft Security — Least privilege for AI agents: Identity, access, and tool binding

The desired model looks more like:

person
  │
  ├── identity
  └── permissions
        │
        ▼
      agent
        │
        ├── dedicated identity
        ├── least privilege
        ├── approved tools
        └── audit trail

Not:

person
  │
  ▼
agent
  │
  └── enterprise-wide master credential

Agents change the scale of the problem

A traditional chatbot receives text and returns text.

An agent may:

• open files;
• query email;
• call APIs;
• modify tickets;
• execute code;
• create resources;
• send messages;
• delete data;
• deploy software;
• chain multiple tools without human intervention.

That changes the attack surface completely.

OWASP calls Excessive Agency the condition in which an LLM system is given too much functionality, too many permissions, or too much autonomy. A hallucination, ambiguous instruction, or prompt injection can then become a real action affecting confidentiality, integrity, or availability.

Source: OWASP — LLM06:2025 Excessive Agency

The security boundary is no longer only:

what can the model SAY?

It becomes:

what can the model DO?

Blast radius matters more than model intelligence

Organizations often evaluate agents by spending a lot of time measuring accuracy:

does it answer correctly?
does it reason well?
does it hallucinate?

Security needs an additional metric:

blast radius.

Meaning:

if this agent fails, is manipulated, or misunderstands an instruction, how far can the damage spread?

Two agents running the exact same model can have radically different risk profiles.

Agent A
- read only
- one document collection
- no secrets
- no external actions

Agent B
- email
- repositories
- cloud
- database
- write permissions
- command execution

The model may be identical.

The blast radius is not.

Microsoft recommends a defense-in-depth strategy in which agents are designed as bounded components and permissions begin at zero, then are enabled explicitly.

Source: Microsoft Security — Defense in depth for autonomous AI agents

Shadow AI: banning everything can make the problem worse

Another important idea from the Platzi discussion is shadow AI.

When an organization simply bans AI tools while employees still need their capabilities, the likely path can become:

corporate policy
      │
      └── "do not use AI"
              │
              ▼
employee still needs to solve the task
              │
              ▼
personal account / external tool
              │
              ▼
copy and paste corporate information

The organization loses exactly what it wanted to gain:

• visibility;
• logging;
• identity controls;
• enterprise contracts;
• defined retention;
• centralized configuration;
• revocation.

The alternative is not to allow every tool.

It is to provide approved paths that are useful enough that the secure path is also the easy path.

Useful governance starts with the data

A mature strategy can reverse the usual order.

Instead of asking:

“Which AI do we allow?”

start with:

“What classes of data do we have, and what may be done with each class?”

For example:

Data class	AI usage
Public	approved models
Internal	enterprise services, no training
Confidential	restricted access + controlled retention
Highly sensitive	ZDR where applicable + isolation + additional controls
Secrets / credentials	never send unless explicitly designed and justified

Then apply identity and authorization:

data
  │
classification
  │
identity
  │
authorization
  │
tools
  │
model

The model is at the end of the chain, not the beginning.

A practical pattern for enterprise agents

A defensive architecture has several independent barriers.

1. One identity per agent

Do not use one credential shared across all agents.

Each agent should have a traceable identity, an owner, a purpose, and a defined lifecycle.

2. Least privilege

The agent receives only the operations required.

If its job is to summarize documents:

read

it should not automatically receive:

write
delete
share
export
admin

3. Separate reading from writing

A particularly useful pattern is to split the workflow:

reader agent
    │
    ▼
proposal
    │
    ▼
validation
    │
    ▼
higher-privilege action

This prevents the same identity that discovers information from automatically gaining the power to modify the entire system.

4. Allowlisted tools

An agent does not need to know every API available.

It should only see the tools required for its job.

Microsoft explicitly recommends binding agents to preconfigured and approved tool sets.

Source: Microsoft Security — Least privilege for AI agents

5. Approvals for high-impact operations

Sending money, deleting data, deploying production, changing permissions, or publishing externally are good candidates for an additional confirmation.

Autonomy does not have to be binary.

read        → automatic
analyze     → automatic
propose     → automatic
delete      → approval
publish     → approval
privilege escalation → approval

6. Complete auditability

You should be able to answer:

• which agent acted;
• who initiated the run;
• under which identity;
• which tools it called;
• which resources it touched;
• what changed;
• under which approval.

Without that, investigating an agent incident can become extremely difficult.

Where ZDR fits

ZDR reduces one specific dimension of risk:

TOTAL RISK
│
├── provider retention ← ZDR helps here
├── excessive permissions
├── credentials
├── prompt injection
├── unsafe tools
├── shadow AI
├── internal logging
├── external connectors
└── autonomous actions

That is why ZDR matters, but it does not replace Zero Trust.

A system can have ZDR and still be extremely dangerous if an agent holds an administrative credential.

And a system can have excellent permission boundaries while still violating privacy requirements if sensitive prompts are retained indefinitely.

Both dimensions need to be solved together.

Checklist before approving an AI platform

A useful review should ask at least:

1. Is customer data used for training?
2. What is the default retention period?
3. Is ZDR available, and for exactly which products or endpoints?
4. What exceptions exist?
5. Who can access retained content?
6. What happens to logs and telemetry?
7. What do third-party connectors or tools do with the data?
8. Does the agent inherit the user’s permissions or use a more powerful identity?
9. Can read and write access be separated?
10. Are there approvals for irreversible actions?
11. Are audit logs sufficient?
12. Can a compromised identity or tool be revoked quickly?

Those questions usually reveal much more than a generic “enterprise-grade AI” label.

We do not need an Excel Department 2.0

AI is rapidly moving from an isolated product to a capability embedded across applications.

That makes it hard to justify a parallel bureaucracy for every new model.

The alternative is more boring, but probably more robust:

identity
+
data classification
+
least privilege
+
retention
+
auditability
+
approvals
+
tool security

and applying those properties to AI as well.

Mature governance is not about blindly trusting models or banning them.

It is about ensuring that a model can never cross the boundaries the organization already decided an identity, a data class, or an action should have.

Conclusion

Zero Data Retention is one of the most valuable properties for sensitive AI workloads because it reduces the amount of content that remains stored after processing.

But ZDR does not answer the more important question:

What can the system do while it is processing that data?

That depends on identity, permissions, tools, isolation, approvals, and auditability.

With chatbots, a bad response could be a quality problem.

With agents, a bad decision can become an API call, a modification, a publication, or a deletion.

That is why the security architecture of the next generation of enterprise AI probably will not look like a giant “model firewall.”

It will look much more like principles we already know:

Zero Trust, least privilege, separate identities, classified data, auditable actions, and minimal retention.

AI does not invalidate those rules.

It makes them far more important.