Enterprise-Grade Security & Governance

37 — Zero-Data Retention (ZDR) Contracts

Translate retention commitments into enforceable endpoint selection, feature restrictions, logging controls, and evidence that the deployed data path matches the agreement.

Concept overview

Zero-data retention is a scoped service commitment about whether specified request or response content is retained by a provider. Its meaning depends on the agreement, product, endpoint, feature, account configuration, and exceptions. A no-training commitment is different from a no-retention commitment, and transient processing is different from durable storage.

Architects should map every data copy, including application logs, traces, caches, uploads, asynchronous jobs, and support exports. A provider's retention setting does not remove copies created by the application. Contract interpretation and legal obligations require the organization's responsible reviewers; the technical design must make the approved scope observable and enforceable.

Why it matters in production

Proof of concept

A prototype should use non-sensitive data until the selected service's handling is understood. Record which features store state or uploaded artifacts.

Production

Production maintains approved endpoint and feature profiles, configures retention controls, and disables incompatible capabilities. Current provider documentation and account-specific terms must be verified rather than inferred from a marketing label.

Enterprise scale

At scale, routing and failover must preserve the same retention constraints. Configuration drift, new model offerings, and SDK defaults can change behavior and therefore require review and automated checks.

Architecture components

Data-flow inventory

Records content movement and every application or provider storage surface.

Approved service profile

Captures verified endpoints, regions, features, retention settings, and applicable commitments.

Inference gateway

Enforces the approved profile and blocks incompatible routing or feature use.

Telemetry policy

Prevents prompts and outputs from being retained in unauthorized logs and traces.

Evidence monitor

Detects configuration drift and preserves review records and control-test results.

The architecture, mapped

Retention policy follows every inference route — Fallback and observability paths must satisfy the same approved handling constraints as primary inference.

flowchart LR
 D["Classified request"] --> G["Retention policy gateway"]
 P["Approved service profiles"] --> G
 G --> A["Compatible primary endpoint"]
 G --> B["Compatible fallback endpoint"]
 G --> X["Blocked incompatible feature"]
 G --> L["Metadata-only operational logs"]
 A --> V["Configuration and evidence review"]
 B --> V

Runtime flow

1
Classify content
Identify which data categories require the approved retention treatment.
2
Verify scope
Review current service documentation and applicable agreement for exact feature and endpoint coverage.
3
Configure controls
Apply account settings, request options, logging restrictions, and feature exclusions.
4
Enforce routing
Permit only compatible destinations, including retries, batch paths, and failover providers.
5
Test data copies
Inspect application telemetry, caches, uploads, and provider-visible settings for unintended persistence.
6
Revalidate changes
Review model, SDK, configuration, and contractual changes before expanding the approved path.

Summarizing confidential transaction documents

Legal operations · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A corporate legal team uses an assistant to summarize confidential transaction material under an approved external-processing arrangement.

The problem

The selected inference endpoint may meet the reviewed retention requirement, while a fallback endpoint or debug trace stores the same text.

Agent requirement

The assistant must keep all processing within the approved service and feature scope.

Architecture

An inference gateway routes classified requests only to reviewed profiles, and telemetry records operational metadata without document content.

Runtime

A summary request is checked for endpoint, region, feature, and retention configuration before dispatch.
If the primary service fails, only a fallback with equivalent approved handling is eligible; otherwise the task waits or returns a controlled failure.

Failure scenario

A newly enabled stateful feature is blocked until its storage behavior has been reviewed and added to the profile.

Operational impact

Measure unapproved-route attempts, configuration drift, content-bearing telemetry findings, and review freshness. This architecture supports an agreement; it does not determine legal sufficiency.

Architecture tradeoffs

Decision	Benefit	Cost
Strict approved profiles	Data handling remains consistent across execution paths.	Available models and features may be restricted.
Minimal telemetry	Fewer content copies reduce exposure.	Debugging may require synthetic reproduction or protected evidence workflows.
Equivalent failover	Availability can improve without relaxing constraints.	Maintaining multiple approved providers increases review effort.

Failure scenarios & recovery

SDK defaults enable stored responses

Detect: Configuration tests detect a stateful option outside the approved profile.

Recover: Block the request and pin explicit compatible settings.

Debug logging captures raw prompts

Detect: Telemetry scanning identifies content beyond the approved scope.

Recover: Disable capture and follow the organization's remediation process.

Common architecture mistakes

Equating no training with no retention

Verify the separate commitments explicitly.

Checking only the primary model endpoint

Include fallback, uploads, batch, and observability paths.

Assuming one provider setting covers application storage

Inventory and control application-created copies.

When to choose this pattern

Choose it when

Sensitive content has explicit retention constraints.
Service features differ in storage behavior.
Routing and failover must preserve approved data handling.

Avoid it when

A marketing phrase is the only available evidence.
Required features conflict with the approved retention scope.
The application cannot control its own content logging.

Architecture checklist

Document exact endpoint and feature scope.
Verify current account-specific settings and terms.
Disable incompatible stateful features.
Apply policy to fallback routes.
Inspect application logs and caches.
Revalidate material service and SDK changes.