How to Verify a Legal AI Vendor's "We Don't Train on Your Data" Claim

The three claims hidden inside "we don't train on your data"

"We don't train on your data" bundles three separate promises: no training, no retention, and scheduled deletion. They are logically independent, a vendor can keep one and break another, so each needs its own artifact before you treat the sentence as verified.

Read carefully and the phrase splits into three promises that get treated as interchangeable and are not. The first is a training promise: your prompts and documents are not used to fine-tune, improve, or otherwise adjust a model's weights. The second is a retention promise, often labeled zero data retention or ZDR: your inputs are not stored after the response comes back. The third is a deletion promise: your data is stored, then removed on a defined schedule. The trap is that these are logically independent. A vendor can truthfully say it never trains on your data while still retaining that data for thirty days of abuse monitoring. Another can retain nothing yet route your prompt through a sub-processor whose own terms are silent on training. The sentence sounds like a guarantee and is actually a question you have not finished asking.

Because the claims are independent, they need independent proof. Asking "do you train on our data" and accepting a yes-or-no answer collapses three questions into one and lets the strongest answer stand in for the weakest. The table below maps each claim to what it actually means and to the single artifact that would let you check it. Everything else in this guide is an expansion of that table: how to read each artifact, what a thin version looks like, and how to test the parts that are testable rather than taking them on faith.

"No training" is narrower than it sounds, and the verbs give it away

The training claim is the easiest to say and the easiest to hedge. Start by pinning down scope, because "we don't train" can quietly exclude fine-tuning on a separate endpoint, building evaluation sets from your prompts, or deriving aggregated models from content that has been labeled de-identified. In legal work the de-identified label deserves particular skepticism, because a fact pattern can identify a client even after names are stripped. The honest version of a no-training answer names all of these and rules them out. The evasive version uses a soft verb, "we may use customer content to improve our services," which in practice usually means some form of training, and leaves the derivatives unaddressed.

Verifying the claim means getting it out of the sentence and into a document. A no-training statement on a webpage can change without notice and binds no one. The same statement written into the Data Processing Addendum, covering training, fine-tuning, and derivative or aggregated models, is a term you can hold the vendor to. This is also where the training claim connects to a firm's confidentiality duty, which is distinct from evidentiary privilege and turns on how client information is handled rather than on whether it stays privileged in court. Our note on client confidentiality and AI covers that boundary in more depth. For verification, the rule is simple: if the no-training promise is not in the contract, it has not been made.

Watch the verbs. "Improve our services," "enhance model quality," and "learn from usage" are soft phrasings that often include training. Ask the vendor to confirm in writing that none of them apply to your inputs or to any derivative built from them.

Zero data retention is a different promise about storage, not learning

Zero data retention is about storage after the response, not about learning. A vendor can avoid training yet still retain your inputs for logging or monitoring. Verify ZDR separately, confirm it is not gated to a plan you are not on, and get the operative mode named in the contract.

Zero data retention answers a question training does not: after the model returns a response, is your input kept anywhere? A vendor can genuinely not train on your data and still retain it, for logging, for abuse monitoring, or simply because retention is the default and no one turned it off. So the ZDR claim has to be verified on its own terms. Ask whether inputs and outputs are stored at all after a response, and if the answer is that a retention window exists, ask who can access data during that window, whether it is human-reviewed, and whether a true zero-retention mode is available or reserved for a higher pricing tier.

The conditional yes is the pattern to watch for here. A vendor may confirm that zero retention exists, then reveal on follow-up that it applies only to an enterprise plan, a specific deployment mode, or a subset of endpoints. The capability is real, but it is not the capability you are buying unless the contract says so for the matters that need it. Record both the setting and its condition, then carry both into negotiation. Verifying ZDR is not about hearing the word, it is about confirming that the zero-retention configuration is the one your firm will actually run under.

A deletion policy stores your data first, then removes it on a schedule

The deletion claim is the one most often mistaken for the other two. "We delete your data" concedes that the data was stored in the first place, which is a materially different posture from zero retention. That is not automatically a problem, plenty of legitimate tools store data to function, but it changes what you need to verify. A deletion promise is only meaningful with three specifics attached: a defined retention window stated in days rather than words like "promptly," a deletion path you can actually exercise, and a stated timeline for purging backups, where deleted data most often lingers.

The deletion path is the testable part, and testing it is the difference between a policy and a capability. Ask whether deletion happens through a documented request process or an API, then, during any pilot, actually run it and confirm the data is gone from the surfaces you can observe. A vendor that cannot show you how deletion is initiated, or that describes it only in the passive voice, has given you a policy on paper without a mechanism behind it. Treat an untestable deletion promise the way you would treat an untestable backup: as an assumption, not a control.

1. Get the window in daysRequire a retention period stated as a specific number of days, including backups, not soft language like "promptly" or "as needed."
2. Find the deletion pathConfirm whether deletion runs through an API or a documented request process, and who at the firm is authorized to trigger it.
3. Test it in the pilotActually initiate a deletion during a controlled pilot and verify the data is gone from every surface you can observe.
4. Pin the backup purgeAsk how long deleted data survives in backups and get that timeline in writing, since backups are where deletion promises usually leak.

The Data Processing Addendum is where a promise becomes enforceable

Every claim above is just marketing until it lives in the Data Processing Addendum. The DPA is the contract exhibit that governs how a processor handles your data, and it is the instrument that converts a spoken assurance into a term you can enforce. When you verify a no-training or zero-retention claim, the concrete action is to open the DPA and find the clause that states it. If the clause is absent, the claim has not been made in any binding form, regardless of what the sales page says. If the clause is present but hedged, the hedge is the real promise.

Read the DPA for named terms rather than adjectives. A strong no-training clause names training, fine-tuning, and derivative or aggregated models explicitly. A strong retention clause states a period and a deletion mechanism. A strong sub-processor clause commits the vendor to bind every downstream provider to the same limits and to give you notice before adding new ones. This is the same discipline our legal AI vendor security questionnaire is built to extract, and the DPA is where those questionnaire answers either become enforceable or evaporate. A vendor comfortable with its own practices will put them in the addendum. Reluctance to do so tells you the assurance was softer than it sounded.

A no-training promise that appears on a website but not in the DPA is not a weaker version of the same promise. It is a different thing entirely: a statement that binds no one and can change without notice.

The sub-processor list reveals which model providers actually sit behind the tool

Most legal AI tools do not run their own foundation models. They send your prompt to a model provider, and that provider is a sub-processor with its own retention and training practices. This is the layer where a vendor's clean answer can hide a messy reality, because the vendor's own no-training promise is only as strong as the terms it signed with the providers behind it. Verifying the top-level claim therefore means verifying the layer beneath it. Ask for the full list of LLM sub-processors, then ask which of them the vendor has signed zero-retention agreements with, and request to see those terms.

Legal-tech vendor-security guidance now makes this a standard buyer question. GC AI's guidance for firms is explicit that you should ask every vendor which LLM providers they have signed zero-retention agreements with and request to see the contracts ^[2]. The reasoning is straightforward: a vendor can promise not to retain your data while routing it through a provider whose default is to retain it, and only the signed downstream terms resolve the contradiction. A vendor that can name its sub-processors and produce the zero-retention terms it holds with each one has given you something checkable. A vendor that treats its sub-processor list as confidential has told you where the unverified risk lives.

• Ask for the complete list of model providers and any other sub-processors that touch a prompt or document.
• Ask which providers the vendor holds signed zero-retention agreements with, and request the terms, not just a yes.
• Confirm the vendor is contractually bound to give advance notice before adding a new sub-processor or swapping a model.
• Check that the vendor's own no-training and retention limits are passed through to every downstream provider, not just asserted at the top.

A SOC 2 Type II report is an independent audit over time, not a self-attestation

When a claim needs third-party backing, the SOC 2 Type II report is the artifact to ask for, and it is worth understanding what it does and does not prove. SOC 2 is the AICPA's framework of System and Organization Controls for service organizations, evaluating controls against trust services criteria that include security, confidentiality, and privacy ^[1]. The distinction that matters for verification is Type I versus Type II. A Type I report describes controls at a single point in time. A Type II report tests whether those controls actually operated effectively over a review period, typically several months, and is performed by an independent licensed CPA firm ^[1]. That independence and that time dimension are what separate an audit from a self-attestation.

The limit is scope. A SOC 2 report defines a boundary of systems the auditor examined, and an AI product often sits partly outside it. The corporate email, the billing stack, and the customer portal may be in scope while the inference pipeline, the model host, and the prompt-logging path are not. The badge looks identical either way, so verifying it means reading the scope section rather than the summary and confirming the AI pipeline is actually covered. SOC 2 remains necessary, it screens out immature security programs, but it never claims to answer the question a no-training promise turns on: where does the client's data go, and who behind the tool can read it? Treat it as one layer of evidence, not the whole stack. Our overview of the RankShield Legal security posture describes where this kind of certification fits alongside verifiable records.

Where the data is processed decides whether it left your approved boundary

A quieter question sits underneath training and retention: where does the data physically go, and does it leave the boundary your firm approved in a form someone could later retrieve? Two tools can both promise no training and still differ sharply on this. One keeps processing inside a region and tenancy you control. Another routes prompts through infrastructure in a jurisdiction you never evaluated, where retrieval is governed by someone else's rules. For matters carrying heightened sensitivity, the location of processing can matter as much as the retention window, because data that has left your boundary in retrievable form is exposed regardless of what the retention policy says.

Verifying this means asking the vendor to name the regions and systems that touch a prompt, and asking whether a single-tenant or in-boundary deployment is available for restricted matters. It also connects to how privileged material is isolated before it ever reaches a model, which is a separate architectural question covered in our note on privilege isolation. One honesty caveat belongs here. Isolating privileged data and recording informed consent attests the architecture and the consent, it does not preserve evidentiary privilege, which remains a legal determination that stays with the lawyer. Verifying where data goes tells you the boundary was respected. It does not, on its own, resolve a privilege question in court.

The verification protocol you can run on any vendor

The steps below turn everything above into a repeatable test that any lawyer or committee at the firm can run the same way, on every tool, before client data goes in. It is deliberately vendor-neutral and works on a security vendor as well as a drafting tool. The goal is not to pass or fail a vendor on a single answer, it is to collect the specific artifacts that make each of the three claims checkable, and to notice where an artifact is missing. A missing artifact is not proof of bad faith. It is a signal of where the unverified risk sits, so you can decide whether to press for it, route around it, or keep restricted matters off the tool until it is produced.

1. Split the claimAsk the vendor which of the three it means: no training, no retention, or scheduled deletion. Do not accept one answer as covering all three.
2. Demand the DPA clauseFor each promise you rely on, find the Data Processing Addendum clause that states it. If the clause is absent, treat the promise as unmade.
3. Map the sub-processorsGet the full list of model providers, then ask which hold signed zero-retention terms and request to see them ^[2].
4. Read the SOC 2 scopeRequest the SOC 2 Type II report and confirm the AI pipeline is inside the audited boundary, not just the corporate perimeter ^[1].
5. Test the deletion pathDuring a controlled pilot, actually initiate deletion and confirm the data is gone from every surface you can observe, then pin the backup-purge timeline.
6. Locate the boundaryConfirm the regions and tenancy that process a prompt, and whether an in-boundary deployment exists for restricted matters.

A contract promise is a representation, a verifiable receipt is proof

A representation is a claim about behavior: a webpage line, a DPA clause, a SOC 2 badge. Proof is a signed, independently checkable record of what actually happened to the data. Verifying a vendor is the work of turning as many representations as possible into evidence you can test.

Everything in this guide narrows to one distinction. A questionnaire answer, a webpage sentence, a DPA clause, and a SOC 2 badge are all representations. They are claims about how a system behaves, and they are worth gathering, but they share a structural weakness: each is a point-in-time statement, and none tells you what actually happened to a specific document on a specific day. Vendors change sub-processors, swap underlying models, and revise retention settings between annual reviews, and a diligence file from January says nothing about a privileged document processed in June. The strongest contract in the world still leaves you asserting the answer rather than proving it.

RankShield Legal's own answer to this is to produce verifiable evidence rather than ask a firm to trust its word. The approach is to generate signed, independently checkable records of what happened to the data, so that when a client, regulator, or court asks where the information went, the firm can demonstrate the answer instead of asserting it. This is capability the platform is building toward rather than a claim that verification removes a lawyer's duty, it does not, and the confidentiality obligation stays with the firm. You can see the principle applied to this very site on our transparency page, where anyone can check the published content hashes rather than take our word for what the pages say. The point is not that receipts replace contracts. It is that a firm ends up in a stronger position when its vendor's claims can be checked against evidence, not just read off a page.

What this guide is, and what it is not

This is a security-engineering method for testing a vendor's claims, written from the perspective of building verifiable systems rather than from a law practice. It does not tell you whether a given tool is safe for a given matter, and it does not resolve questions of evidentiary privilege, which are legal determinations for a lawyer to make. The confidentiality duty under the applicable rules of professional conduct, and the informed-consent obligations that follow from a tool's data practices, remain with the firm and its lawyers. Nothing here is legal advice, and no artifact described above substitutes for a lawyer's own judgment about a client's information.

What the method does offer is a way to stop treating one sentence as one promise. Separate the three claims, demand the artifact that proves each, test the parts that are testable, and notice where the evidence runs out. Run that process the same way on every tool, including the ones that market themselves on security, and the firm moves from trusting its vendors toward being able to show, on the day it matters, how a client's confidential information was actually handled.