Legal AI DPA, GDPR, and EU vs US Data Hosting: Vendor Guide

A few months ago I watched a procurement lead at a mid-size litigation firm do something most buyers never do. She had three legal AI vendors on a shortlist, all of them with glossy trust pages, all of them promising "enterprise-grade security" and "we don't train on your data." She ignored every word of it.

She asked each vendor for one thing: the actual Data Processing Addendum, the signable document, before any contract talk. Two sent it within a day. One stalled for two weeks, then sent a "summary." She crossed that one off immediately.

Her reasoning was simple and worth repeating: a vendor that won't hand you the executable DPA up front is telling you something about how they handle the rest of the relationship.

If you are evaluating which legal AI vendors offer signed DPAs with real subprocessor controls and clear hosting commitments, that instinct is the whole game. The marketing copy across this category has converged to the point of uselessness. Harvey, Legora, CoCounsel, the dozen newer entrants, they all say the same three sentences.

The differentiation moved one layer down, into the DPA, where the clauses are specific, enforceable, and almost never read by the people signing.

The path a privileged document takes, and the guarantees worth checking in the contract.

Short answer: A legal AI DPA (Data Processing Agreement) is the contract that binds a vendor to GDPR Article 28 processor duties: act only on your instructions, name and gate subprocessors, secure the data, delete or return it on termination, and let you audit. Most serious legal AI vendors will sign one, including Harvey, Legora, and GC AI. The differences that matter are not whether they sign, but what the DPA says about EU vs US data hosting, residency, SCCs for transfers out of the EU, subprocessor notice windows, and retention. Read those clauses before you sign anything.

TL;DR

Part of our in-house counsel guide series.

• The "we don't train on your data" promise is the easiest claim in legal AI to make and the least meaningful to verify. It has stopped differentiating vendors.
• Real differentiation lives in the DPA: subprocessor notice and objection windows, deletion timelines, hosting and residency commitments, and audit rights.
• Two close peers can both say "no training" and still differ materially. Harvey's published DPA gives a 15-day subprocessor objection window; Legora's US agreement gives 30 days and an explicit bar on processing outside the EU/EEA or US without consent.
• Zero data retention (ZDR) and "no model training" are two separate contractual commitments. A vendor can offer one without the other. Require documentation of both.
• Under GDPR Article 28, the DPA is mandatory whenever a vendor processes personal data of EU or UK residents on your behalf. It must lock in eight processor duties, from documented instructions to audit rights. A vendor that cannot produce an Article 28 DPA is not a serious option for regulated work.
• EU vs US data hosting is the clause that trips up the most buyers. US hosting of EU personal data is a third-country transfer, so the DPA needs Standard Contractual Clauses (SCCs) and supplementary measures, and US ownership keeps CLOUD Act exposure even when the servers sit in Frankfurt. EU residency from an EU-incorporated vendor sidesteps both.
• SOC 2 Type II is now table stakes, not a differentiator. Treat it as a floor, then read the contract.
• An honest vendor posture, when shown in plain terms, looks like: ZDR and no-training with both model providers, US-only residency, full public subprocessor list, and any compliance gaps (such as SOC 2 Type II being on the roadmap rather than in hand) named up front.

The marketing layer is dead. Read the contract.

There was a moment, maybe two years ago, when "we don't train on your data" actually meant something. It signaled that a vendor had thought about confidentiality, had a ZDR arrangement with its model provider, had answered the obvious question before you asked it.

That moment is gone. Every serious vendor says it now, because it costs nothing to say and most buyers stop reading right there.

This matters more in law than in almost any other vertical, because the duty does not stop at your firm's perimeter. Under the GLBA Safeguards regime, 15 U.S.C. § 6801, financial institutions carry an "affirmative and continuing obligation" to protect customers' nonpublic personal information.

When your firm represents a bank, an insurer, or a lender, that obligation flows down to you and then to your vendors, and the vehicle it flows through is the DPA. The trust page does not bind anyone. The signed addendum does.

ABA Formal Opinion 512, issued in July 2024, made the competence angle explicit: lawyers using generative AI need to understand the tools well enough to protect client confidences. "Understand the tool" does not mean "read the headline on the security page." It means knowing where the data goes and what the contract obligates the vendor to do with it.

The companion to this piece, where your legal AI data actually goes, maps the physical layers: which model, which cloud, which subprocessors touch a privileged document. This post is the contract-document companion. That one answers "where does it physically go." This one answers "what does the contract actually bind them to."

What GDPR Article 28 requires a legal AI DPA to cover

If any of your matters touch personal data of people in the EU or UK, the DPA is not optional. GDPR Article 28 says a controller may only use a processor that gives "sufficient guarantees" of appropriate technical and organizational measures, and that the relationship must run on a binding written contract. That contract is the DPA. No DPA, no lawful processing.

Article 28(3) spells out eight duties the contract has to put on the vendor. When a vendor hands you a DPA, you are really checking that these eight are present and not watered down:

• Documented instructions (28(3)(a)). The vendor processes your data only on your written instructions, including for any transfer to a third country like the US.
• Confidentiality (28(3)(b)). Everyone with access is under a confidentiality duty.
• Security (28(3)(c)). The vendor applies Article 32 security measures (encryption, access control, resilience).
• Subprocessor control (28(3)(d) and 28(2)). No new subprocessor without your authorization, and notice of changes so you can object.
• Data subject rights (28(3)(e)). The vendor helps you answer access, deletion, and similar requests.
• Breach and DPIA support (28(3)(f)). Help with Articles 32 to 36, including breach notice and data protection impact assessments.
• Deletion or return (28(3)(g)). Delete or return the data when the service ends, unless law requires keeping it.
• Audit access (28(3)(h)). Make available the information needed to prove compliance, and allow audits.

There is one more that buyers forget: under Article 28(4), the vendor stays fully liable to you if one of its subprocessors drops the ball. That is why the subprocessor clause carries more weight than its length suggests. (Source: Article 28, EU GDPR, gdpr-info.eu, verified June 2026.)

The four clauses procurement actually checks

When a sophisticated legal team evaluates a DPA, they are not reading it for vibes. They are checking four specific things. If you take nothing else from this post, take these four.

1. Subprocessor notice and objection windows

Your data does not sit with one vendor. It passes through their subprocessors: the cloud (Azure, AWS), the model provider (OpenAI, Anthropic), logging and analytics tools, sometimes more. The DPA should name them, or commit to a maintained public list, and it should tell you two things: how much advance notice you get before a new subprocessor is added, and how long you have to object.

This is where two near-identical vendors diverge. Harvey's published Data Processing Addendum gives customers 30 days' advance notice before a new subprocessor is added and a 15-day window to object. Legora's US Data Processing Agreement gives a 30-day objection window running from when the change is posted.

Same category, same "no training" promise, materially different windows. If you run a regulated practice and need time to vet a new subprocessor with your own compliance team, that difference is not cosmetic. It is the gap between "we have time to review" and "the change happened before we noticed."

2. Deletion and return on termination

What happens to your data when the contract ends? A real DPA commits to delete or return it within a defined window. Harvey's addendum commits to delete or return within 30 days of termination. Legora's agreement commits to delete or return on termination, with a carve-out to block data instead where deletion is genuinely impractical (a standard and reasonable clause, as long as "blocked" is defined).

The thing to watch for is a vendor whose contract is silent here, or that reserves the right to retain "for legitimate business purposes" without a ceiling. Indefinite retention of privileged material is a problem you do not want to discover during a breach notification.

3. Hosting and residency: guaranteed or just "negotiable"

This is the clause most buyers misread, because the marketing and the contract often say different things. A vendor's website may proudly advertise "US data centers." The DPA may then default to US processing only "absent a separate written residency agreement," which means residency is negotiable, not guaranteed, unless you specifically paper it.

Harvey's published DPA defaults to US data transfer and leaves residency to a separate written agreement. Legora's US agreement takes the opposite approach and writes a floor directly into the contract: it bars processing outside the EU/EEA or the US without the subscriber's consent. One leaves residency to negotiation; the other puts a contractual guardrail in the document itself.

Neither approach is wrong. But if your client work requires a hard residency commitment, you need to know which posture you are buying, and the trust page will not tell you. The contract will.

EU vs US data hosting: SCCs, residency, and the CLOUD Act

For GDPR-touched work the residency clause is where most of the real risk sits, so it is worth its own pass. Three things to separate:

• Where the data physically rests. Many vendors offer EU regions now. Harvey publishes US, EU, Switzerland, and Australia hosting options (Harvey trust materials, 2026). Legora, a Swedish company, is built around EU data residency and runs on OpenAI's EU data residency for inference (OpenAI announced EU data residency in February 2025, openai.com; live but blocks bots, so named without a link). EU-at-rest is a starting point, and the next two items decide whether it holds up.
• The transfer mechanism. If a US-incorporated vendor processes EU personal data, that is a transfer to a third country. Since Schrems II struck down Privacy Shield, you need Standard Contractual Clauses (SCCs) plus supplementary measures in the DPA, or reliance on the EU-US Data Privacy Framework for a certified vendor. Check that the DPA actually attaches SCCs and names which transfer basis it uses. A residency promise with no SCC exhibit is half a clause.
• CLOUD Act exposure. Picking an EU region does not end the analysis. The US CLOUD Act lets US authorities compel a US-headquartered company to hand over data it controls, even when the bytes sit in Frankfurt. EU regulators treat this as a live sovereignty concern. The only clean way out is a vendor incorporated and operated outside US jurisdiction, which is the structural edge EU-native vendors like Legora lean on.

So "EU data hosting" can mean three different things depending on the vendor: an EU region on a US company's cloud (residency, still CLOUD Act exposed), an EU region with SCCs papered (lawful transfer), or an EU company with no US nexus (residency plus reduced compelled-access risk). The DPA and the SCC exhibit tell you which one you are actually buying.

Try Vaquill AI on your matterBook a demo

4. Audit rights

Can you verify any of this, or are you taking it on faith? Mature DPAs grant an audit right, usually capped at once per 12 months to keep it from being abused. Legora's US agreement grants exactly that: an audit right once per twelve-month period.

Audit rights are rarely exercised, but their presence signals a vendor that expects to be checked and has built for it. Their absence signals the opposite.

The distinction almost everyone misses: ZDR is not "no training"

Here is the single most-missed point in legal AI procurement, and it is worth slowing down for.

Zero data retention and "no model training" are two separate contractual commitments. A vendor can offer one without the other.

"No training" means your data is not used to improve the model's weights. ZDR means your data is not retained at all after the request is processed, not in logs, not in caches, not for abuse monitoring. You can have no-training with 30-day retention for "safety review." You can theoretically have retention with no training.

They are different promises, governed by different clauses, often involving different parties (the vendor versus the underlying model provider). As the team at GC AI put it in their data-security writeup, ZDR and "no model training" are two separate contractual commitments, and a provider can offer one without the other, so you should require documentation of both.

Most buyers conflate them. They hear "we don't train on your data," check the box, and never ask the retention question. Then a privileged memo sits in a 30-day abuse-monitoring buffer on someone else's infrastructure, fully consistent with the no-training promise, and nobody at the firm knows.

If you read our deeper treatment of the "we don't train on your data" claim, the through-line is the same: the headline promise is real but incomplete, and the incompleteness is where the risk hides.

So when you read a DPA, separate the two questions explicitly. Is there a no-training clause, and does it cover both the vendor and the underlying model provider? Is there a ZDR or defined-retention clause, and what is the actual window? Get both in writing, or assume the gap is filled with default retention.

SOC 2 is the floor, not the finish line

A quick word on certifications, because they get over-weighted. SOC 2 Type II has become table stakes in this category. As of mid-2026, it is reported that GC AI, Harvey, Spellbook, and ChatGPT Enterprise hold it, among others. That is good. It is also not a differentiator anymore, any more than HTTPS is a differentiator for a website.

The mistake is treating the SOC 2 badge as the end of diligence rather than the start. SOC 2 attests that a vendor follows its own stated controls. It does not tell you the subprocessor objection window, the deletion timeline, or the residency commitment.

Those live in the DPA. A vendor can hold a clean SOC 2 Type II and still have a contract that leaves residency entirely to negotiation. Use the certification as a gate to clear, then read the document that actually binds them.

The full procurement request set that sophisticated legal teams send, beyond the DPA itself, usually includes the Article 28 processing terms, a completed security questionnaire (a CAIQ or similar), and the current subprocessor list with geography. If a vendor can produce all of that without friction, you are dealing with someone who has done this before. If each item triggers a delay, that is data too.

A practical scoring rubric

You do not need a 40-page vendor assessment. You need to read four clauses across your shortlist and lay them side by side. Here is the comparison frame, using the two best-documented public examples in the category.

A quick word on the first row, because "which legal AI vendors sign a DPA" is the question buyers actually type. The answer in this category is most of the credible ones. Harvey and Legora both publish their DPAs (linked above), and GC AI describes its DPA and ZDR posture in its data-security writeup. Signing is the easy part. The contents of the five rows below are where vendors that "all sign a DPA" stop being interchangeable.

Both are credible vendors with genuine "no training" commitments. The point of the table is not that one wins. It is that two peers who sound identical in their marketing diverge the moment you read the contract, and the divergence is exactly on the axes a regulated practice cares about.

Build the same five-row table for every vendor on your list, leave a cell blank wherever the contract is silent, and your decision usually makes itself. Blank cells are answers.

FAQ

What is a legal AI DPA?

A DPA (Data Processing Agreement) is the contract that binds a legal AI vendor to handle your data as a GDPR Article 28 processor. It sets the vendor's duties on instructions, security, subprocessors, deletion, and audits, and it is the document that actually obligates the vendor, not the trust page. For a clause-by-clause walkthrough, see our DPA review field guide.

Do legal AI vendors sign a DPA?

Most credible ones do. Harvey and Legora publish signable DPAs, and GC AI documents its DPA and zero-data-retention posture publicly. The harder question is what the DPA says about hosting, subprocessor notice, and retention, since those vary widely between vendors that all "sign a DPA."

What does GDPR require for legal AI tools?

If a tool processes personal data of people in the EU or UK, GDPR makes you the controller and the vendor a processor, and Article 28 requires a written DPA covering eight processor duties. You also need a valid transfer mechanism (usually SCCs) if the data leaves the EU, plus security under Article 32. Certifications like SOC 2 do not satisfy GDPR on their own.

Is US data hosting GDPR compliant for legal AI?

It can be, but it takes more than a US server. Hosting EU personal data in the US is a third-country transfer, so the DPA needs Standard Contractual Clauses and supplementary measures, or reliance on the EU-US Data Privacy Framework. US-headquartered vendors also carry CLOUD Act exposure even when data sits in an EU region, which is why some firms require an EU-incorporated vendor.

What is the difference between data residency and data sovereignty?

Residency is where the data physically sits. Sovereignty is whose laws can reach it. A US vendor can give you EU residency and still be compellable under the US CLOUD Act, so residency alone does not deliver sovereignty. If a client demands sovereignty, ask where the vendor is incorporated as well as where the servers sit.

Is ZDR the same as "no training on my data"?

No. Zero data retention means your data is not kept after the request runs. No-training means it is not used to improve the model. A vendor can offer one without the other, so you should require documentation of both, for the vendor and the underlying model provider. Our guide on verifying the no-training claim goes deeper.

What should I ask a legal AI vendor before signing?

Ask for the executable DPA, the current subprocessor list with geography, the Article 28 processing terms, and a completed security questionnaire. Then read the subprocessor notice window, the deletion timeline, the residency clause, and the SCC exhibit. The DPA negotiation playbook covers where vendors will and will not move.

What an honest disclosure looks like

A comparison roundup that exempts the author is not worth reading, so name the gaps the way you want vendors to name theirs.

Vaquill AI's posture in this category looks like: zero data retention and no-training arrangements with both model providers (Anthropic and OpenAI); US-only residency (no separate EU plane, so EU-residency requirements are a disqualifier rather than a maybe); a public subprocessor list, a DPA available before signing, and the broader security posture documented in one place. PII is anonymized before it reaches a model, and a built-in compliance check flags where a draft or data flow runs against a policy you have set.

Honest gaps belong in the same breath: SOC 2 Type II not yet in hand is a real disqualifier for an AmLaw-200 firm with a hard SOC 2 gate, and pretending otherwise wastes everyone's time.

That is the same standard worth applying to any vendor on your shortlist: not "do they say the right things," but "will they show me the contract, and does the contract match the pitch." If you want the infrastructure-layer view of the same question, the data-flow map is the place to start, and the cost side of the procurement equation is worth reading alongside it.

The one habit that changes everything

Go back to the procurement lead who crossed a vendor off her list for stalling on the DPA. She was not being difficult. She was applying the only test that survives the marketing convergence: ask for the executable document first, read the four clauses, and watch how the vendor behaves while you do it.

The trust page is written by marketing. The DPA is written by lawyers and signed by both of you. Only one of them is enforceable, and it is not the one with the nice gradient background.

For related operational playbooks, see Where Your Legal AI Data Actually Goes, the DPA Review Field Guide for In-House Counsel, and how an AI compliance check covers CCPA, GDPR, and SOX. For more on the procurement-side controls a credible legal AI vendor exposes, see /security.

If you want to read the contract before you commit to anything else, Vaquill AI's DPA and subprocessor list are public and you can start a 7-day trial without talking to a sales rep.

Vaquill AI

Product & Content

Legal AI suite for US working lawyers: research, drafting, document comparison, document matrix, matters, and citation-verified answers, in one tool.