Third-Party Verification Standards for AI No-Training Guarantees

AI without data collection or monetization needs more than a no-training promise, which does not show that an assistant neither stores nor sells personal data. Third-party verification standards for AI no-training guarantees must bring together contracts that can be enforced, independent assurance, and technical evidence. The strongest design reduces what must be trusted by separating customer data from training infrastructure.

Why "we don't train on your data" cannot be taken at face value

Westlaw, Harvey, and Lexis repeat a claim that has become a sales fixture across AI products. Yet the promise is rarely checked against the contract, much less against the system itself. The asymmetry is stark. Vendors can freely make the promise, while customers have no direct evidence of whether their data goes into training. What would turn that statement into something a customer could reasonably rely on?

Choi, Shavit & Duvenaud identify the underlying weakness in Tools for Verifying Neural Models’ Training Data. Training-data claims rest on trust and reputation, and a developer’s self-reported account could be falsified. That establishes the need for evidence beyond a provider’s account. A privacy page can change after signing, whereas a signed Data Processing Agreement provides a contractual commitment.

The claim is not one promise but four, and each layer is its own failure point

The first gap is retention, because excluding data from training does not require deleting it after processing. A 30-day retention window creates a continuously replenished pool of stored prompt-response pairs in a system the customer does not control. How long the data is kept changes the risk even when the no-training statement is true. How long does the provider keep the conversation, and what agreement governs that period?

The second gap concerns derived data. AI platforms create embeddings, search indexes, caches, and summaries from customer content, and these artifacts may retain proprietary information. Transformation is not the same as removal. Such artifacts may not be isolated per customer or deleted when a contract ends. A promise limited to the original content consequently leaves a separate question about the representations made from it.

The third gap appears in permissions to “improve the Services,” “develop new features,” or “use aggregated and de-identified data for any business purpose.” Language originally scoped to product analytics can be read as permission for training-related reuse. The distinction can become narrower than customers expect. A vendor might maintain its no-training claim while fine-tuning a retrieval reranker on customer queries, depending on what the claim covers.

The fourth gap lies upstream, with subprocessors. A legal AI vendor may use a foundation model hosted by another party, whose retention behavior is governed by a separate agreement. The visible vendor’s promise may be true of what it does without covering what the underlying provider stores. These four gaps explain how a narrow training exclusion can coexist with substantial data exposure.

How contract language either closes or quietly reopens these gaps

For procurement and legal teams, the practical starting point is the executed agreement. An opt-out toggle can be changed by an administrator or reset during a product update. Written commitments survive those interface changes. The agreement needs to spell out the banned uses broadly enough to cover the actual system, beyond what its sales language says.

The recommended contractual floor covers fine-tuning, reinforcement learning, retrieval augmentation, evaluation, the vendor’s own model, and any upstream provider. Language restricted to “general models” leaves other uses exposed. Scope does the work that the slogan cannot. A zero-retention DPA must also bind subprocessors and include audit and attestation rights, together with contractual penalties for breach. Those provisions establish consequences and access to evidence, though they do not themselves create a technical barrier.

Does a broad permission elsewhere in the agreement quietly reopen a use that the no-training clause appears to forbid? HubSpot’s July 2026 commitment illustrates a corrective direction. After collective customer pushback, the company said new enrichment capabilities using customer data would be “fully and transparently opt-in.” Explicit permission makes the boundary clearer than a protective slogan paired with an expansive reuse clause.

What a five-point pre-signature verification checklist actually covers

The first check passes only when the exact no-training commitment appears in the signed DPA or services agreement. A webpage or help-center article fails this test. Writing down the result before signing lets those who govern the company and those who review it from outside see the difference.

The second check passes when a published subprocessor list names foundation model providers, embedding services, and retrieval infrastructure, with terms for notice of changes. A vendor disclosing no subprocessors fails this check. The failure mode is an incomplete account of the parties handling customer content. Without that account, the customer cannot assess whether the visible commitment reaches the underlying services.

The third check requires a written retention and deletion timeline. Zero retention after processing is the strongest posture. Unstated or indefinite retention is a material finding, because a training prohibition does not resolve how long stored content remains available. The retention window also bounds what retained material a later subpoena can reach.

The fourth check needs confirmation of zero-data-retention for the underlying foundation model. The application vendor’s promise alone is insufficient evidence. This check fails when the upstream API provider can retain prompts under a separate policy that the customer has not reviewed.

The fifth check examines the boundary between training exclusions and product-improvement permissions. Customer data must be explicitly excluded from broad improvement clauses, or those clauses must be explicitly prevented from overriding the no-training protection. Together, the five checks produce a documented pass/fail record, with verification of the implementation still outstanding.

Why contractual assurance alone is structurally insufficient and what independent audit adds

A contract establishes an obligation. Customers can read its terms, but reading cannot reveal whether the provider’s processes enforce them. Independent assurance addresses that evidentiary gap. Its purpose is to assess the relationship between the documented commitment and the system’s operation.

Rachel M. Kim and colleagues at Carnegie Mellon University distinguish assurance from audits in their FAccT’26 framework, Toward Third-Party Assurance of AI Systems. Their model examines both system outcomes and the processes that produce them. Outputs alone do not show every failure in the process. The framework provides a systematic blueprint, with a prototype and early testing, rather than evidence that a mature certification system already covers the market.

SOC 2 Type II is a practical baseline, but its scope determines its value here. To help with this check, a report must cover prompt data lifecycle and data isolation as well as general security controls. CSA STAR for AI and agent-specific certification programs add new layers of assurance, but the means to check the certifiers themselves are less developed than the ways contracts are used.

Italy’s €15 million fine of OpenAI concerned GDPR violations involving training-data processing, transparency, age verification, and breach notification. The Court of Rome subsequently annulled it in March 2026 on jurisdictional grounds. That qualification belongs with any account of the case. The regulatory dispute illustrates the demand for documented controls, technical safeguards, and compliance evidence, but the annulled penalty is not a standing legal endorsement of a particular verification framework.

The technical verification frontier and what cryptographic and hardware-level methods can and cannot prove

What, exactly, does the evidence prove? Proof about a model’s execution, its training data, and its public documentation addresses different propositions. Combining those mechanisms can strengthen an assessment, but treating them as interchangeable produces an assurance none actually supplies.

Choi and colleagues define Proof-of-Training-Data, or PoTD, as a protocol through which a verifier can assess which data produced a model’s weights. Their procedures can add as little as 1.3% of the original training run’s compute. The obstacle is not only computational cost. Verification requires access to training data, model weights, training code, and intermediate checkpoints, creating a substantial intellectual-property disclosure burden. Those requirements limit how businesses can use it even when the verification overhead seems small.

Trusted Execution Environments, or TEEs, deal with how a model runs. Hardware enclaves can produce cryptographic attestation that a specific model ran on a specific GPU in an isolated environment. This runtime mechanism is production-ready, with modest inference overhead. It does not establish what trained the model. An attested model binary and a verified training history are different forms of evidence.

CROVIA, published in February 2026, observes training-data disclosure practices and anchors its observations to a cryptographic Merkle chain. Its Temporal Proof of Absence asserts that particular disclosure elements were absent from public documentation at a particular time. That is a precise but bounded claim. Pedersen commitments on secp256k1 and Ed25519 signatures support the artifact, but absence from documentation does not prove absence from a training set.

An AI Bill of Materials, or AIBOM, aims to document model origins and characteristics in a reference cryptographically bound to model weights. AICert lacks third-party auditing, and its robustness has not yet been tested. Regulators currently expect audit-trail provability rather than cryptographic correctness, while cryptographic proof of large-model training trajectories remains open research.

Architecture offers a different way to narrow the problem. If customer data cannot reach training infrastructure by design, verification can focus on that separation rather than only on whether employees and processes followed a policy. The burden changes, but it does not disappear. The architecture itself still needs evidence, and runtime attestation must not be stretched into a claim about every possible use of data.

The shared opt-out standard announced October 30, 2026, and why it still leaves verification gaps

OpenAI, Google, Microsoft, and Anthropic announced on October 30, 2026 that they would back a shared robots.txt instruction for publishers opting out of AI training. A site can add a single entry that participating companies read as a refusal of generative-model training use. That is meaningful coordination across major providers. It simplifies the expression of a publisher’s preference, but expression and enforcement remain separate questions.

The commitment states no duty for smaller developers, open-weight model builders, or overseas labs to follow it. Data can also reach training through third-party datasets and scraped archives. The instruction works against companies choosing to honor it. Nor does the standard address deletion of existing training sets or compensation for material already used. Those limits distinguish a shared permission signal from an account of what has actually entered a model.

For enterprise buyers, the distinction is especially important because publisher opt-outs and private customer-data guarantees cover different settings. A public instruction does not show how long prompts are kept, what subprocessors do, or whether data is reused for product-improvement. The announcement advances coordination without supplying the independent or architectural evidence needed to establish an enterprise no-training guarantee.

What a complete verification framework looks like when all three layers work together

The three layers work together only when they address the same defined promise. The contract specifies prohibited uses and the data and parties covered. Independent assurance then assesses the processes and outcomes against those terms, with SOC 2 Type II scoped to the AI data lifecycle and the certifier’s accreditation treated as an input to review. Technical controls give evidence for specific claims in that assessment. A runtime attestation cannot fill a contractual omission, just as a comprehensive contract cannot demonstrate technical isolation.

Does the contract cover the subprocessors and the derived data? Can the provider supply a report scoped to prompt data lifecycle, and does it use TEEs or equivalent hardware isolation? Those questions connect the commercial commitment to its implementation. They do not justify ranking a chatbot as the best private option without product-specific evidence.

The final question concerns the boundary around training infrastructure. Is customer data architecturally separated from it, or only excluded by policy? A design that prevents the data from reaching training systems makes each assurance layer more tractable. The contract describes a narrower exposure, assurance examines the separation, and technical evidence can support the architectural claim. Privacy by design is not another slogan when the boundary itself can be tested.