Skip to main content
Zero data retention (ZDR) on Opper has two parts, and you can enforce both for your whole organization:
  • Opper stores no content. With an enabled 0-day Opper retention rule, Opper stores no prompts, outputs, or traces for any project. It keeps only a usage record with no prompts or responses in it.
  • The provider neither trains on nor logs your content. The Zero data retention provider data policy in Model access allows only model routes whose provider neither trains on nor logs request or response content. A call to any other route is refused with 403 before the request leaves Opper.
The two settings are independent: turning Opper tracing off does not restrict providers, and the provider policy does not turn tracing off. Set both.

​
What each plan includes

Rules, including retention and model access, are a Control Plane feature. On the Gateway plan you get ZDR by choosing the route in every call; see Choose a ZDR route per call.

​
Enforce ZDR for your organization

In the Opper platform, open Rules:
1

Turn Opper tracing off

In Opper retention, switch tracing Off and save. This leaves the organization with an enabled 0-day rule: new calls store no traces, and projects cannot turn tracing back on. If the toggle already shows Off because the organization rule is missing or disabled, turn it on and off again in the draft before saving, so that an enabled 0-day rule is saved.
2

Require zero data retention from providers

In Model access, set Provider data policy to Zero data retention. This selects No training and No logging. Check the match counter to see which models remain, then select Save changes.
3

Optional: require No provider moderation

Some providers run content moderation classifiers that can retain flagged content. No provider moderation excludes them, and needs a signed agreement with Opper first. See Arrange approval for No provider moderation.
Both rules apply from the next request. To manage them from code, use the Management API.

​
What ZDR means, term by term

Providers describe data handling in different words. This is how common terms map to what Opper records for each route and checks at request time: For example, in Opper’s catalog in September 2026: A few providers require a signed agreement before your organization can call their ZDR routes, such as azure-zdr and vertexai-zdr. See Routes that require an agreement.

​
What ZDR does not cover

  • Provider caching. Some routes cache prompts implicitly. The route’s caching is recorded separately and No logging does not exclude it.
  • Content kept for moderation. Routes that run provider moderation may retain flagged content. Require No provider moderation to exclude them.
  • Opper’s usage record. Opper keeps a record of each call’s cost, tokens, latency, status, provider, model, and any X-Opper-Tags for 5 years, for billing. It contains no prompts or responses, so keep personal data out of tags. See usage metadata.
  • Services outside Opper. Tools and services your application calls directly keep their own retention.
A 0-day Opper retention rule also changes what Opper does with files and caching in its scope: file uploads are rejected, existing files are deleted after you confirm, and response caching is skipped. See Files and response caching.

​
Fallbacks and pools under ZDR

Opper never falls back to a route that fails your policy. A bare model name such as claude-sonnet-5 runs only on the providers in its pool that pass, and a pinned route such as anthropic/claude-sonnet-5 that fails is refused with 403 rather than switched. Pools in dynamic routes and models fallback lists skip failing entries in the same way; a Model node in a dynamic route instead ends the route with 403. See What model access covers for each case and What a blocked call returns for the error bodies.

​
Find routes that qualify

  • Query the catalog. GET /v3/models needs no API key. training=no with logging=none is the same filter as the ZDR policy, so this returns the LLM routes the policy allows (limit=0 returns every match; total gives the count). Routes marked Agreement required still need the agreement:
    Each model’s compliance object records its training, logging, moderation, and caching.
  • Browse: opper.ai/models labels each route ZDR, monitored, or retained. The labels are close to the policy but not identical: the policy checks training and request logging, while the labels also count content a provider can hold for moderation. Some routes labelled monitored, such as Azure routes, meet the policy. Use the query above for the exact set the policy allows.
  • Check your own rules. With your API key, add include=policy to see whether each model is allowed for your organization and why not, or include=route for the evidence behind each route’s data-handling record.

​
Choose a ZDR route per call

Without rules, on any plan, you get provider-side ZDR on a call by naming a route that meets it, for example mistral/mistral-large-2512, which neither trains on nor logs your content and runs no provider moderation:
On the Gateway plan Opper stores no prompts or outputs either. On Control Plane, Opper still keeps the trace for your retention period (7 days after upgrading) unless you set it to 0 days. What per-call routing cannot do is stop a different call from naming a route that logs. For that, enforce the policy with a Model access rule.

Keep AI inference in the EU

Enforce EU-only inference and storage locations.

Model access

Every allowlist field and provider data requirement.

Opper retention

Turn trace storage on or off and set how long traces are kept.

Security

Certifications, hosting, DPA, and sub-processors.
Last modified on September 29, 2026