Not used for training
Does not mean not retained

OpenAI states that API data is not used to train or improve its models unless the customer explicitly opts in. Separately, default abuse-monitoring logs can contain prompts, responses and derived metadata and are retained for up to 30 days, with stated legal and harm-prevention exceptions. Modified Abuse Monitoring and Zero Data Retention require prior approval and additional requirements. Approved controls can be set at organization and project level; a project can inherit, select a control or disable it. Zero Data Retention forces store=false for /v1/responses and /v1/chat/completions, but does not make every endpoint or capability stateless. The page also describes customer-specific Private Retention with Private Safety Processing and Safety Retention arrangements, with advance written notification, that can change the apparent protection.

Google’s selected page says that training or fine-tuning requires prior permission or instruction for managed models on Gemini Enterprise Agent Platform. Its MaaS retention conditions are separate. Prompt logging for abuse monitoring depends on the customer’s governing terms; an exception can be requested where applicable. Additional logging for certain Advanced AI models or features may prevent zero data retention. Neither statement establishes this buyer’s contract or exception status. Do not transfer these Cloud platform terms to consumer Gemini or assume they govern a Gemini Developer API deployment.

For a proposed policy-document comparison, map the uploaded file, extracted passages, generated answer and saved conversation separately. OpenAI’s /v1/responses normally stores application state for at least 30 days under its documented default or store=true behavior; other features have their own lifecycles. Files require deletion or configured expiry. Background polling, audio, containers and prompt caching need separate checks. Image and file inputs also have a stated suspected-CSAM retention exception, including under restricted-retention controls. On Google’s selected platform, Interactions API store defaults to true; the page instructs customers seeking zero data retention to set it explicitly to false. Request-response logging is off by default but can write to a designated BigQuery table when enabled per model and project. Grounding with Google Search stores specified derived queries and context for up to three days, without a storage opt-out for that feature; Maps grounding retains its specified content for 30 days. Deep Research session storage cannot be disabled while using that agent. Live session resumption and implicit caching introduce further conditions. Supported implicit caches can include memory and durable storage for up to 24 hours; disabling durable caching alone leaves memory caching active. These periods describe different processing paths, not a provider league table.

An endpoint setting does not describe the entire assistant. OpenAI explicitly says that remote MCP servers and other third-party network destinations apply their own retention policies. Ask the implementation team whether document text reaches any such destination, and inventory application logs, exports, search indexes and backups separately. These are review questions, not claims that every deployment creates every copy. For each actual destination, record the data received, access owner, retention rule and deletion mechanism. For Google caching, also distinguish the selected regional or multi-regional endpoint from the global endpoint; the page describes different location behavior. Obtain configuration evidence without putting confidential payloads into the review packet. Missing evidence remains an open condition, not proof that a copy does not exist.

Build one acceptance record for the proposed document task: exact service and endpoint, applicable terms, confirmed retention-control eligibility, effective organization and project settings, enabled features, external destinations and deletion owners. Use non-confidential test material to inspect the intended request path and available deletion behavior; do not treat a successful request as proof of every backend retention property. Document what provider evidence establishes and what still needs written clarification. If a required feature conflicts with the organization’s storage policy, remove it, redesign the task or leave acceptance pending. An on-site alternative needs the same scrutiny of access, logs, backups and connections; location alone creates no immunity. Revisit the record when endpoints, features or terms change.