Zero Training Policy: What Your AI Vendor Owes You in Writing (July 2026)

Jul 7, 2026 by Ethan Pidgeon

At some point your legal or security team is going to ask whether your AI vendor trains on your data, and as the insights, brand, or analytics lead who championed the tool, you'll be the one who has to answer. A screenshot of a privacy page won't close the finding. The zero-training policy question has a specific answer, and it lives in the order form, not the FAQ. This is what that answer should look like, line by line.

TLDR:

• Training and inference are not the same thing; only training lets your data shape outputs for other users.
• Vague contract language like "improve the Services" is now being read as permission to route your inputs into training pipelines.
• A written zero-training clause only holds if it names subprocessors, covers every input type, and sits in the order form.
• Roughly two-thirds of AI vendors do not disclose third-party subprocessors (63.6%, per Kiteworks 2025), so a vendor-only clause leaves a gap you cannot see.
• Merciv publishes a written zero-training policy with architectural tenant isolation, SOC 2 Type II certification, and a full security FAQ at trust.merciv.io.

What "Training on Your Data" Actually Means

Vendors use "your data is safe" as a catch-all, which papers over a technical distinction that matters for procurement review.

Inference is what happens when you send a query. The model reads your prompt, retrieves context, and generates a response. Weights stay frozen. Nothing you sent shapes the system's future behavior for anyone else.

Training is different. Your data becomes fuel for adjusting model weights, and those weights then shape outputs for every user on that model. A snippet from your Q3 pricing deck can surface, paraphrased, inside a response generated for an account you have never heard of.

Why the Consumer Tier vs. Enterprise Tier Gap Matters

The same vendor logo can sit behind two opposite data policies. A free or individual paid tier often defaults users into training, with the opt-out toggle buried three menus deep. An enterprise agreement with the same vendor typically flips that default and adds contractual language backing it up.

That gap matters because teams paste licensed research, internal decks, and customer verbatims into whatever tab is already open, a pattern covered in depth in this ChatGPT vs enterprise consumer research tools comparison. If someone on your team is signed into a personal account, the protections your legal team negotiated do not follow them there. A 2026 review of AI privacy defaults found opt-in-by-default settings persist across consumer tiers, leaving enterprise contracts as the only reliable path to written no-training terms.

The Contract Language That Creates Silent Risk

Most SaaS agreements were drafted before AI training was a distinct contractual concept. The residue shows up in clauses your legal team signed off on years ago without a second read.

Watch for phrases like "improve the Services," "develop new features," or "use aggregated and de-identified data for any business purpose," the same loose language that undermines internal RAG for consumer insights builds. Originally scoped to product analytics and bug fixes, enterprise SaaS contracts treated as training licenses are now being reinterpreted by vendors as sufficient permission to route customer inputs into training pipelines, no separate consent required.

A sales rep's verbal assurance does not override the written grant. Request an explicit carve-out naming model training, fine-tuning, and reinforcement learning as excluded uses, and place it in the order form so it overrides the referenced master terms.

What "Zero Training" Should Actually Guarantee in Writing

A written zero-training clause is only as strong as what it names. Ask the vendor to commit to all five, in the order form, in these exact terms:

• No use of prompts, uploaded files, or outputs to train, fine-tune, or reinforce any model, first-party or otherwise.
• No fine-tuning on customer data, including "customer-specific" variants that persist beyond the session.
• Explicit coverage of third-party subprocessors (foundation model providers, embedding services, retrieval infrastructure — see the GraphRAG vs. vanilla RAG breakdown for how retrieval architecture differs), with a named, auditable list.
• Tenant isolation with no cross-customer retrieval, embedding pool sharing, or index commingling.
• Procurement-ready documentation, including a data flow diagram and subprocessor register, available before signature.

The subprocessor point is where most policies quietly fail: 63.6% of AI vendors do not disclose third-party subprocessors, so a clause covering the vendor's own infrastructure can still route your inputs through an upstream provider whose terms you never saw.

The Compliance Dimension: Why Procurement Now Requires Written Proof

Procurement teams are catching up to what security officers already knew. In 2025, 57% of compliance officers named AI usage their top compliance concern, and that pressure now shows up as line items on RFP checklists that did not exist in early 2025.

The regulatory hook is GDPR's data minimization principle: data may only be processed for the purpose it was collected for. A vendor quietly routing customer inputs into training corpora is repurposing that data, which turns an opaque training policy into a documented compliance exposure. Written proof of a no-training stance is the artifact procurement needs to close an audit finding before it opens one — and the foundation for board-ready consumer insights without black-box AI.

Red Flags in Vendor Responses to Watch For

Four patterns show up often enough to serve as a reliable filter when reading a vendor's written response.

• The buried opt-out. If the answer points to a settings toggle rather than a policy clause, the default is training. Toggles get flipped by admins or reset in product updates. Written policy survives both.
• Vendor-only scope. Watch for "we do not train on your data" that never names foundation model providers, embedding services, or retrieval infrastructure. The upstream provider may still ingest prompts under a separate agreement you never signed.
• "Our models" sleight of hand. A commitment scoped to "our models" leaves third-party providers untouched. Ask the vendor to restate the clause covering any model that touches customer inputs.
• Selective data-type coverage. Some policies protect uploaded files but stay silent on prompts, query logs, embeddings, and metadata. Query logs alone can reconstruct sensitive strategy work — a key reason teams seeking a ChatGPT alternative for consumer research prioritize vendors with explicit enumeration. Insist the clause enumerate every input category, including derived artifacts.

The Questions to Ask Before You Sign

Print these, paste them into the RFP, and require written answers before the security review closes.

• Are prompts, uploaded files, and generated outputs used to train, fine-tune, or reinforce any model, first-party or third-party? Answer yes or no per input type.
• How long is query data retained by default, and is retention configurable to zero-day for prompts and logs?
• Which foundation model providers receive our data, and what are their enterprise API training and retention terms as of the contract date?
• Does the DPA name every subprocessor touching customer data, with a change-notification clause requiring advance notice? (The hidden subprocessor exposure is one reason the cost of building a consumer insights copilot in-house is often underestimated.)
• What is the deletion process at contract end, on what timeline, and will you provide written certification of destruction covering backups and embeddings?

Why "Policy" Without Architecture Is Not Enough

A policy is a promise. Architecture is what makes the promise checkable.

A vendor can write "we do not train on your data" into every contract and still route inputs through an environment where a misconfigured retrieval index or shared embedding pool quietly commingles tenants. If the technical layer permits what the policy forbids, the clause is a legal artifact, not a control.

Three components turn the policy into something a security reviewer can verify:

• Tenant isolation, where each customer's data lives in a separately scoped environment with no shared indices or cross-tenant retrieval paths. Isolation should be a deployment property, not a runtime toggle — a distinction relevant for teams evaluating a Claude alternative for consumer intelligence with stronger architectural guarantees.
• Audit logs covering every query, retrieval, and output, retained long enough for a compliance review to reconstruct what a specific user saw on a specific day.
• SOC 2 Type II attestation, which confirms the stated controls operated effectively across an audit window of six to twelve months. Type I says controls exist on paper; Type II says an auditor watched them run.

Ask which of the three the vendor has implemented, and request the SOC 2 report and a tenant isolation diagram before signature. Policy without the underlying architecture is a document no one can verify from the outside.

How Enterprise AI Buyers Are Raising the Bar

Enterprise procurement has quietly professionalized around AI. What used to be a two-page infosec addendum is now a dedicated AI questionnaire, often forty to sixty questions, that security will not sign off on until every field has a written answer.

The categories have settled into a de facto standard:

• Model provenance: which foundation models sit behind the product, and who owns their training corpora.
• Data flow: every hop a prompt takes from input to output, with storage location at each step.
• Training and retention policy: written, with retention windows named in days.
• Subprocessor disclosure: a full register with change-notification terms.
• Incident response: notification SLAs, forensic capability, and breach history.

Verbal assurance from a sales rep no longer clears review. Security teams reviewing the best consumer insights platforms for enterprise teams have watched too many "we don't train on your data" answers get walked back once the DPA arrived, so the bar is now a signed document that maps to the questionnaire line by line.

How Merciv Answers the Training Question

Everything above collapses into a short checklist when you map it against Merciv. Our zero-training policy is written, not toggled: customer inputs are never used to train our models, and no third-party model training occurs on uploaded content — part of why Merciv beats ChatGPT and Claude. Tenant isolation is architectural, with no commingling or cross-customer exposure. We are SOC 2 Type II certified, encrypt at AES-256 at rest and TLS in transit, and publish the full security documentation at trust.merciv.io, including a 31-question FAQ procurement can pull down as a standalone artifact before the first call.

Final Thoughts on Zero-Training Guarantees and What AI Vendors Owe You in Writing

Vendor trust is fine. Vendor trust backed by a signed order form with named exclusions and a subprocessor register is better. The questions and red flags above exist because procurement teams have already learned that lesson the hard way, and your next vendor review doesn't need to be the one that teaches it again. If you want to see what the written answers look like in practice, Merciv's enterprise page has the full security documentation ready to pull down.

FAQ

Does Merciv train on your data?

No. Merciv's zero-training policy is written into contract terms, not buried in a settings toggle: customer inputs, uploaded files, and generated outputs are never used to train any model, first-party or third-party. Tenant isolation is architectural, meaning each customer's data lives in a separately scoped environment with no shared indices or cross-customer retrieval paths. Full security documentation, including a 31-question procurement FAQ, is published at trust.merciv.io.

What contract language should I watch for before signing an AI vendor that claims it won't train on my data?

Look for phrases like "improve the Services," "develop new features," or "use aggregated and de-identified data for any business purpose," provisions originally scoped to product analytics that vendors now reinterpret as training permission. Request an explicit carve-out naming model training, fine-tuning, and reinforcement learning as excluded uses, and place it in the order form so it overrides the referenced master terms. A verbal assurance from a sales rep does not override the written grant.

How do I verify whether an AI vendor's no-training policy actually holds at the infrastructure level?

A policy is only as strong as the architecture behind it. Ask for three things before signing: tenant isolation documentation showing each customer's data lives in a separately scoped environment with no shared embedding pools, audit logs covering every query and output retained long enough for a compliance review, and a SOC 2 Type II report confirming those controls ran effectively across an audit window of six to twelve months. Type I confirms controls exist on paper; Type II confirms an auditor watched them run.

ChatGPT vs. a purpose-built consumer intelligence tool for brand research — which should insights teams use?

ChatGPT is a genuinely useful drafting and synthesis tool, and most insights teams are already using it. The ceiling appears when a finding needs to survive a leadership review: no source attribution, no confidence scoring, no audit trail, and no guarantee your inputs stay out of model training on consumer-tier accounts. For research that gets cited in a QBR deck or capital request, an untraced output creates an institutional liability regardless of how polished it reads on the surface. For defensible brand research, a purpose-built tool with written zero-training terms is the safer institutional choice.

What questions should I require written answers to before an AI vendor clears security review?

Five questions carry the most weight: (1) Are prompts, uploaded files, and outputs used to train, fine-tune, or reinforce any model, first-party or third-party — yes or no per input type? (2) Which foundation model providers receive your data, and what are their enterprise API training and retention terms as of the contract date? (3) Does the DPA name every subprocessor touching customer data, with a change-notification clause? (4) How long is query data retained by default, and is retention configurable to zero-day for prompts and logs? (5) What is the deletion process at contract end, and will you provide written certification of destruction covering backups and embeddings? Roughly two-thirds of AI vendors do not disclose third-party subprocessors, per industry compliance research, so the subprocessor question is where most policies quietly fall apart.