Zero data retention (ZDR) means a provider keeps no copy of your prompts, completions or derived state after a request finishes. It is a configuration and procurement target, not a product tier you can buy. Achieving zero data retention on Google Cloud and Azure requires explicit configuration or contractual action, because default features retain prompt data on both platforms: grounding services, abuse monitoring, stateful APIs and caching tiers each hold copies for defined windows. This guide maps where the two providers actually keep prompt data, which retentions have no opt-out, and how to turn that audit into a deployment gate your team can enforce.
The distinction matters most for regulated workloads in the EU, where a thirty-day debug log of customer prompts is a very different object than a stateless inference call. Engineers who assume an API call is inherently stateless inherit retention they never signed up for, and the fix is rarely a support ticket — it is a settings change made before the first production request.
Where Prompt Data Actually Sits
Retention never lives in the model weights; it lives in the service layers wrapped around inference. Abuse monitoring, grounding services, caching tiers and stateful conversation APIs are the four places prompts persist. Azure processes prompts and completions to monitor for uses that violate its product terms, while Google Cloud’s prompt logging for abuse monitoring applies to customers under the standard platform terms. Both providers document this behavior — but in privacy annexes and service terms rather than API reference pages, which is exactly why ZDR assumptions survive design review unchallenged.
The model itself is usually not the problem. Microsoft documents that the models themselves are stateless and that no prompts or completions are stored inside the model, so the retention question is entirely about the service layer you switch on around it. That is good news for remediation: every retention window below is a decision you or your platform team made, and can unmake.
Defaults That Break Zero Retention
Google’s documentation for Gemini Enterprise Agent Platform is unusually explicit about which defaults defeat ZDR, and the two grounding integrations are the hardest constraints. Grounding with Google Search keeps queries derived from your prompts for up to three (3) days, and Google says there is no way to disable that storage — the documented recommendation for strict ZDR workloads is to avoid the integration and use the enterprise web-grounding alternative instead. Grounding with Google Maps holds prompts, contextual information and generated output for thirty (30) days with no opt-out, retained for reliability debugging of the grounding pipeline.
Stateful APIs are quieter offenders. On the Interactions API, user data storage is the default, and you must explicitly set store to false on every request to keep retention at zero; omitting the parameter stores prompts, responses and conversation state. Implicit caching adds a second tier: cached data is deleted no later than 24 hours after it is written, but durable caching writes derived data at rest. If your policy forbids at-rest copies of customer prompts, disable durable caching at the project level instead of trusting the default. Agent features add their own windows — Deep Research sessions keep prompts, search results and generated images for seven (7) days, and that feature cannot be disabled while using the agent.
On Azure, the stateless-model guarantee covers the model, not the monitoring store. Abuse monitoring keeps a data store of prompts and completions; managed customers may apply to modify abuse monitoring, and after approval you can verify the result in the Azure portal’s resource JSON view, where the ContentLogging capability reads false when logging is off. Deployment types widen the picture further: Global deployments may process prompts in any geography where the model is deployed, so a data-residency requirement and a latency optimization can silently conflict unless the deployment type is chosen deliberately.
A Retention Decision Table
Use this table as the starting point for your own review. Every row reflects provider-documented behavior, and the last column is the action that survives an audit.
| Feature | Default retention | Opt-out | ZDR action |
|---|---|---|---|
| Grounding with Google Search | up to three (3) days | No | Avoid; use enterprise web grounding |
| Grounding with Google Maps | thirty (30) days | No | Do not use for strict ZDR workloads |
| Interactions API storage | Stores by default | Yes | Set store to false on every call |
| Durable caching | At rest, no later than 24 hours | Yes, per project | Disable durable caching, keep in-memory |
| Azure abuse monitoring | Prompt data store | By application | Managed customers apply; verify ContentLogging false |
| Azure Global deployment | Processing in any geography | Choose deployment type | Use regional deployment for residency |
Provider Audit Checklist
- Inventory features before contracts. List every stateful feature in scope — grounding, threads, stored completions, caching, agent sessions — and mark which ones the product actually needs.
- Read the service terms, not the API docs. Retention rules live in privacy annexes and service-specific terms; the reference pages rarely mention them.
- Capture settings in infrastructure code. Store set to false, durable caching disabled, regional deployment selected — anything configured by hand will drift.
- Verify the monitoring state. On Azure, confirm the ContentLogging capability reads false after any abuse-monitoring modification is approved.
- Re-audit on provider changes. Google’s ZDR page carried a 2026-10-22 update stamp; pin the pages you rely on and diff them quarterly.
Make It a Deployment Gate
ZDR decisions have cost and latency consequences, so make them explicit rather than aspirational. Disabling caching trades latency and spend for privacy — a workload that tolerates deferred processing can recover much of the cost gap by routing bulk jobs to batch inference at half token price, while latency-sensitive traffic that loses caching may need capacity planned closer to provisioned throughput sizing than to pure on-demand. Write the trade-off down: which features are banned, which settings are mandatory, and who approved each exception.
Then enforce it where deployments already pass: a policy check that rejects configurations with conversation storage enabled, durable caching on, or a Global deployment type bound to a residency-labeled workload. An audit that lives in a spreadsheet is a finding waiting to happen; an audit that fails the pipeline is a control.
Sources
- Microsoft — Data, privacy, and security for Models sold by Azure in Microsoft Foundry (change log latest entry 2025-10-03)
- Google Cloud — Gemini Enterprise Agent Platform and zero data retention (page updated 2026-10-22)