Contractual and Technical Signals That Prove a Web Search API Will Never Train on Your Queries

A SOC 2-aligned web retrieval API for enterprise AI teams needs both contractual limits on data use and technical controls that enforce them. Proving that a provider will never train on queries requires a signed agreement, relevant audit evidence, and a verifiable architecture that prevents query content from entering retained datasets. A no-training statement or SOC 2 badge alone is not proof.

Why every AI agent pipeline has a data-leakage surface at the search layer

Every query that an AI agent or RAG pipeline sends to an external web search API goes outside the operator’s infrastructure. That transfer creates a distinct data-exposure surface, even when the rest of the pipeline runs within a controlled environment. The boundary is crossed before retrieval begins. B2B queries can contain competitive intelligence, client data, or internal strategic context because the agent uses that information to decide what to search for.

The exposure also depends on the agent’s tool choices. Web search sits beside internal knowledge bases, structured data queries, and domain-specific APIs, with the agent deciding which tool to invoke for each query. Sensitive context can therefore reach external search unpredictably. After receiving cleaned passages, the agent may search again until it reaches an answer or a step budget. Each iteration creates another external disclosure whose treatment depends on the search provider’s contract and infrastructure.

Training, retention, and ZDR are three separate things that the market conflates

Training is whether query data goes into a model-development pipeline, while retention is whether the provider keeps it after processing. ZDR concerns whether inputs and outputs are discarded without being written to logs or used for training. Its availability is a separate procurement question. A provider may offer ZDR only through an enterprise agreement, leaving the plan being evaluated without it.

Training requires curated datasets, substantial compute, and deliberate decisions about which data to include. OpenAI has excluded API data from training by default since March 2023. Anthropic’s API policy deletes inputs and outputs automatically within a defined window, illustrating why a deletion policy still needs examination for retention. A no-training commitment can coexist with abuse-monitoring logs.

Google’s tiers make the distinction particularly clear. The free Google AI Studio tier uses content to improve products, while the paid tiers of Vertex AI and Gemini API promise not to use it for training. Only Vertex AI offers a path to guaranteed ZDR, while the paid Gemini Developer API logs data for up to 55 days for abuse monitoring. DeepSeek retains user data after processing, allows sharing with third parties, and has no published enterprise ZDR tier.

ZDR is stricter than either no training or short-term retention. It means processing content in memory, returning the response, and discarding both input and output without persistent content logs. Workloads governed by HIPAA, attorney-client privilege, SEC financial regulations, or client confidentiality terms may require this stronger treatment. However, ZDR does not make a prohibited disclosure permissible. If a self-serve plan keeps customer queries, the operator’s privacy policy should say so honestly.

What a policy promise without a technical mechanism is actually worth

A promise to delete data differs from a system that cannot persist it. The promise depends on the system doing the right thing under all operating conditions, while the architecture blocks the retention path or makes it possible to detect a violation. This is the central distinction in vendor evaluation. A marketing statement is not a contractual obligation, and a contractual obligation does not establish how the system behaves.

The evaluation therefore has two complementary layers. The contractual layer sets out how data may be used, the limits on retention, and whether the operator can ask for evidence. The technical layer establishes whether processing, logging, and failure handling conform to those limits. Neither substitutes for the other’s evidence. GDPR’s Data Protection by Design requirement supports building protection into the architecture this way, while SOC 2 Trust Service Criteria CC6.1 covers the logical and physical access controls that apply. The actual SOC 2 report must still establish which controls were tested and within what scope.

The contractual signals that distinguish a real commitment from boilerplate

For a technical decision-maker preparing a vendor review, the starting documents are the Data Processing Agreement or equivalent services agreement, the current SOC 2 Type II report, and the subprocessor list. Each answers a different question. The agreement establishes obligations, the report describes tested controls and exceptions, and the list identifies third parties that may receive query data. Marketing copy cannot replace any of them.

Within the agreement, require explicit treatment of filesystem artifacts, execution logs, memory snapshots, and observability telemetry. These surfaces expose different routes to retention. Cached pages or query logs can persist on disk, request and response payloads can enter execution logs, and crash dumps can capture in-flight content. Monitoring pipelines may also collect content with operational metadata. Generic references to “customer data” leave too much uncertainty unless the agreement specifies how each surface is handled.

The next questions concern use and scope. Does the provider retain queries and results by default, and for how long? Does the plan under review include ZDR, and does the agreement ban the use of queries or results for training, fine-tuning, or model evaluation? Processing geography and subprocessors also need explicit answers. Ask whether the DPA can be signed without a sales call and whether audit rights allow requests for evidence, so the review need not rely only on provider attestations.

Retention defaults determine how much compliance work the operator inherits. A provider retaining personal query data must be assessed as a data processor, with a DPA governing that processing. A Data Protection Impact Assessment is required where processing is likely to create high risk. Enterprise ZDR must also be in the agreement that applies to the plan. These terms establish the obligation, but they cannot demonstrate that the serving system fulfills it.

The technical architecture signals that make contractual commitments enforceable

The engineering review should examine three mechanisms together, namely dynamic PII masking, stateless serving, and metadata-only audit logging. Masking identifies and obscures sensitive fields at the edge before they reach downstream logging or processing layers. Stateless serving holds query content in memory only for the call’s duration and never writes it to disk. Metadata-only logging keeps a record of latency, error codes, and request counts without storing the content of queries or results. Each closes a different retention route.

Metadata-only logs can support abuse monitoring and audit requirements without creating another content store. However, that design does not establish SOC 2 compliance by itself. The report’s scope, tested controls, review period, and exceptions remain essential, particularly when evaluating access controls under CC6.1. GDPR Article 25 provides a useful parallel question about whether privacy depends on protections built into the architecture or on later cleanup.

The provider’s control over the full pipeline determines the reach of these mechanisms. A stateless gateway cannot ensure ZDR for an external search index that gets the same query under different terms. The engineering team should explain whether query or result content reaches any persistent store, what audit logs capture, and where third-party infrastructure enters the path. It should also explain crash and failover handling, including whether memory dumps can preserve in-flight content.

Why web search APIs face a harder version of this problem than LLM APIs

LLM API data policies are relatively mature and well documented, but search introduces a less standardized chain of processing. A search provider may operate its own index and serving infrastructure or forward queries to another search engine. The provider’s DPA may not fully address that second path. A favorable retention setting at the first endpoint therefore does not resolve the entire disclosure.

The response format adds another architectural distinction. Traditional SERP APIs return titles, URLs, and brief excerpts, while LLM-optimized search APIs return processed, relevance-ranked text or Markdown for direct AI consumption. A raw SERP workflow can require fetching, parsing, chunking, embedding, and ranking. Every stage is a potential retention point. Different subprocessors may operate those stages, so a review limited to the initial search request leaves part of the pipeline unexamined.

Server-side extraction can consolidate those steps and reduce the number of potential retention points, but only when the provider controls them end-to-end. Otherwise, consolidation can leave dependencies in place and hide them. The agent’s repeated searches make this harder. Across iterations, a stream of queries can reveal more of the agent’s reasoning context than a single lookup, while generating more external requests than a user-facing search product. Search therefore needs its own review even when the generation provider has already been approved through procurement.

How do enterprise teams evaluate a SOC 2-aligned web retrieval API?

The practical evaluation should run the contractual review before signing and the technical review before production. Begin by matching the DPA to the exact plan under consideration. Check that the agreement spells out how retention is handled for all four data surfaces and whether ZDR needs a separate enterprise agreement. Then check audit rights. Without a right to ask for supporting evidence, a later review may have to rely entirely on the provider’s own attestations.

Next, trace the contractual boundary through the subprocessor list. If a third-party search index receives queries, request the provider’s DPA or equivalent agreement with that subprocessor. Read the current SOC 2 Type II report for scope, period, and exceptions relevant to retention and access controls. The badge cannot answer those questions.

The engineering review should then test that same boundary. Ask for a specific account of persistent writes during normal operation. Ask for a sample audit-log schema if available. Compare that account with the crash and failover policy, since an in-memory serving design still needs an explicit policy for memory dumps. For personal-data workloads, establish where PII masking occurs. It must precede the persistent or external layers that the masking is intended to protect.

Short of on-premises deployment, the strongest evidence available comes from a DPA that covers all four surfaces, a relevant SOC 2 Type II report, subprocessors covered by the agreement, and technical checks that confirm stateless serving. End-to-end ownership of the index, serving, and delivery is a substantive architectural differentiator that reduces subprocessor risk and clarifies the guarantee’s scope. Both layers are jointly necessary, because legal protection without technical evidence is unproven, while technical protection without binding terms leaves the commitment incomplete.

When a provider cannot satisfy both layers and what the fallback options are

When an external provider cannot meet both layers, the next decision concerns which queries may leave the operator’s environment at all. Classify content before it reaches the search tool. Queries containing PII, confidential client information, or privileged material can be routed to an internal knowledge base or a provider that satisfies the required ZDR terms. Only queries with less sensitive content should go to the external API that offers less protection. Agent-side redaction or pseudonymization can reduce exposure, but it does not convert a retaining service into ZDR.

A private or on-premises search stack removes the external transfer surface by keeping retrieval within the operator’s infrastructure. The tradeoffs are explicit. Index freshness, maintenance burden, and coverage breadth become the operator’s responsibility. This option fits workloads that can tolerate a bounded, internally indexed corpus more readily than those requiring live web grounding. Whether those limits are acceptable depends on how sensitive the data is and which compliance rules apply.

Changes at the generation layer do not resolve external retrieval risk. Self-hosted open models such as Llama and Mistral remove the risk that an external model provider will use data for training, but queries still leave the environment if retrieval uses an outside API. Azure OpenAI and AWS Bedrock provide cloud-tenanted options for LLM processing without settling the search provider’s practices. For workloads requiring live web grounding, purpose-built search infrastructure belongs in the decision tree when it offers end-to-end pipeline control, clearly scoped ZDR, a signed DPA covering all four data surfaces, and a current SOC 2 Type II report.