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 does not train on, log or keep your content. The Zero data retention provider data policy in Model access allows only model routes whose provider does not train on request or response content, log it, or keep it after moderation. 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, No logging and No stored moderation. Check the match counter to see which models remain, then select Save changes.
3

Optional: require No provider moderation

No stored moderation already excludes providers whose moderation may keep flagged content. To also exclude providers that run moderation classifiers at all, select No provider moderation. It 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 October 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.
  • Moderation that keeps nothing. A route that passes may still run a moderation classifier that reads each request. 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, and Logs to browse the records call by call.
  • Services outside Opper. Tools and services your application calls directly keep their own retention.
Response caching depends on cache rules only: a 0-day Opper retention rule does not turn it off. Files you store yourself, with an upload or store: true, are not affected either: they stay until you delete them. 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 returns the routes that meet No training and No logging (limit=0 returns every match). Of those, the ZDR policy allows the ones whose compliance.zdr.moderation is false. 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. A route labelled ZDR meets the policy when its moderation practice is recorded; routes labelled monitored, such as the standard Azure routes, do not. 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:
Opper stores no prompts or outputs either, unless you have turned tracing on (Control Plane). 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 October 22, 2026