Where Legal AI Stores Client Data: A Residency Guide

We run a directory of AI legal software and we don't sell any of it, so we have no reason to flatter a vendor's hosting story. Most writing on this topic is either generic infrastructure content aimed at IT teams or a vendor explaining why its own setup is fine. This page is for the person who has to answer a client's outside-counsel guidelines questionnaire or a GC's procurement form and needs to know what to ask and where the answers live.

This is software evaluation, not legal advice. Whether your matter, your client or your jurisdiction requires data to stay in a particular country is a question for your own counsel and your own regulator. We explain how to find out what a tool does. We don't tell you what the law requires of you.

What does data residency mean for a legal AI tool?

Residency is where data physically sits. It is related to, but different from, two other terms that get used as if they were the same:

• Data residency: the geographic location where data is stored and processed.
• Data sovereignty: whose laws apply to that data, which can depend on the vendor's home country and not just where the servers are.
• Data localization: a legal requirement, imposed by a regulator or a contract, that data stay in a given place.

For a lawyer, the practical meaning is simple. Someone, such as a client, a regulator or your own policy, has said client information must stay in a region. You need to know whether the AI tool you are about to use lets you comply, and you need evidence rather than a reassurance.

Notice what is missing from that definition: a single yes or no. A vendor that answers "yes, we're GDPR compliant" has not answered a residency question. GDPR compliance describes how personal data is handled and how transfers outside the EU are justified. It does not mean the data never leaves the EU. Treat "compliant" and "resident" as different claims and ask for each one separately.

Storage, processing and sub-processors: what is the difference?

Follow one document through a typical legal AI product.

1. Storage. You upload a contract. The vendor's application keeps it, along with a search index built from it, in a cloud region. This is the layer most vendors mean when they say "hosted in."
2. Processing (inference). When you ask a question, the relevant text is sent to a large language model. That model may be run by the vendor, by a cloud platform, or by a separate model company. The region where it runs can differ from the storage region.
3. Sub-processors. Every other company that can touch the data: the cloud host, the model provider, monitoring and logging tools, email and support software, backup providers.

Two consequences follow. First, a "regional hosting" claim usually covers layer 1 only, unless the vendor says otherwise. Second, your exposure is the union of all three layers. If storage is in Switzerland, inference is in the US and logs go to a third region, your data touches three places.

The European Data Protection Board addressed the chain problem directly in Opinion 22/2024 on reliance on processors and sub-processors, adopted 9 October 2024. If you are a controller under GDPR, the point to take from it is that your responsibility does not stop at the vendor you signed with. It extends to the processors that vendor relies on, which is why the sub-processor list matters as much as the hosting region.

We cover the wider set of security questions (training on your data, retention, certifications) in Legal AI Data Security: What to Verify Before You Upload. This page is narrower: it is only about where the data lives.

Which vendors state regional hosting?

We read the public security or product pages of a set of vendors in our directory on 5 November 2026 and recorded only what each page states. A blank cell means the page did not say, not that the vendor does not do it. That distinction is the whole point of the exercise: a missing answer is a question to put in your questionnaire.

Vendor	Hosting or region stated publicly	Model-provider location or identity stated	Sub-processor list
Harvey	Cloud environment hosted in Microsoft Azure. Regional app endpoints for the US, EU and Australia. In-region processing offered for customers with localization needs in the EU and Switzerland, or Australia, and the page says this applies to Harvey's sub-processors as well	Model providers not named. Page says providers are contractually barred from training on customer data and must provide zero data retention	Not named on the security page
Spellbook	AWS is the primary cloud. Customer data stored and processed in data centers in Canada and the US. Customer-selectable residency not stated	Names OpenAI and Anthropic as model providers, each under a zero data retention agreement	Listed in its trust center, with locations, per the security page
Legalfly	SaaS regions not named on the security page. Single-tenant deployments can be placed "in your preferred Azure region"; private cloud, hybrid and on-premise are also offered	Not stated on the security page	Not on the security page; it points to a trust center
Whisperit	States hosting on Swiss servers and that data does not leave Switzerland. Its FAQ also mentions configurable processing regions without defining them	Not named; where AI processing occurs is not stated on the homepage	Links to a sub-processor page and a data-flow page
Legartis	States all servers are in Switzerland and Europe, with no country named	Not stated	Not stated on the homepage
Legora	No hosting regions named. Page mentions enterprise storage options and points to a trust center	Not named. Page says customer data is not used to train or fine-tune models	Not on the security page; points to a trust center
Robin AI	Says data stays in its AWS environment; no region named. Page says it is GDPR compliant but does not state a UK or EU storage location	Not stated	Not listed on the page it publishes

Three patterns stand out, and none of them is a criticism of any one vendor.

Region names are the exception. Only a few pages name a country or a cloud region. Several say "secure cloud" or "Europe" and stop. A continent is not a residency answer if your requirement is a country.

Storage is easier to state than processing. Spellbook and Harvey are unusually specific about where data sits or can sit. Even there, the model-provider layer is described through contract terms (zero data retention, no training) more than through geography. Zero data retention tells you the model provider does not keep the data. It does not tell you where the model ran while it held it.

The details live one click deeper. Most pages hand off to a trust center. That is where sub-processor lists and region detail usually are, and it is also where they change. Treat the trust center as the source and your contract as the commitment.

A note on Robin AI. Our Ivo vs Robin AI comparison covers the company's 2025 restructuring and why it is no longer a clean buying decision. We list it above only because the question of what happens to data when a vendor changes hands or winds down is itself a residency question. Ask any vendor, in writing, what its data return and deletion process is if the business is sold or closed.

Directory listings for European-focused vendors, including those above, are in the LegalizeAI tool directory. If you are a vendor and your regional hosting is missing from this table, you can say so in a free listing at /submit.

How do you verify a residency claim?

A claim on a marketing page is a starting point. Verification means getting the same answer from a document that binds the vendor. Work through these steps in order.

1. Ask for the three regions in one written answer. Storage region, model-processing region and the region of any logs or backups. If the vendor answers only the first, ask again for the other two by name.
2. Read the sub-processor list, not the summary. Find it in the trust center or the data processing addendum. Check each entry's location. Note how the vendor notifies you of changes, because a list that changes without notice can undo a residency promise after you sign.
3. Check what the claim covers. Does "EU hosting" apply to every product and feature, or only to the core workspace? Does it include features that call an outside search or research service? One vendor's own page, for example, separates its core flow from its external web research flow. Ask whether any feature sends data elsewhere.
4. Confirm the plan. Regional options are often an enterprise-tier feature or a separate deployment. The region you see in a demo may not be the region you get on the plan you buy.
5. Separate residency from retention. Ask what is deleted, how fast, and in which regions the backups sit. A copy in a backup region is still a copy.
6. Get an independent attestation where one exists. An ISO/IEC 27001 certificate or a SOC 2 Type 2 report is evidence of controls, not of location. It helps you trust the process; the order form and the sub-processor list tell you where.
7. Re-check on a schedule. Providers add regions and add sub-processors. Put the trust center URL in your vendor register and review it at renewal.

Our security questionnaire guide has a fuller set of questions you can paste into a vendor form, and the procurement checklist shows where residency fits in a full buying process.

What should the contract say?

The contract is where a residency answer becomes a commitment. If it does not appear in the agreement or the data processing addendum, it is a preference, not a promise. These are the terms worth asking for, expressed as questions for your counsel to review:

• Named regions for each layer. Storage, processing and backups, each with a named region, not "Europe" or "a secure cloud."
• Scope. Which products, workspaces and features the commitment covers, and any carve-outs.
• Sub-processor controls. An attached list, a notice period for additions, and a right to object or terminate if a new sub-processor sits outside the agreed regions.
• Support access. Whether staff in other regions can access your data for support, and under what conditions.
• Change and incident clauses. What the vendor must do if it moves regions, is acquired, or suffers an incident that involves data in another location.
• Return and deletion. How you get your data back at exit, and how deletion is confirmed across storage, backups and any provider holding a copy.
• Order of precedence. If the security page and the contract disagree, the contract should win, and the page should not be able to change under you.

If the vendor refuses to put a region in writing, you have learned what the claim was worth.

Governance and policy tools can help you keep track of these commitments across a stack of vendors; see AI governance platforms compared for the options in the directory. In-house teams buying across several workflows can start from AI for in-house legal teams.

Frequently asked questions

Where do legal AI tools store client data?

Usually in a public cloud region chosen by the vendor, most often on one of the large cloud platforms. In the vendors above, Harvey states Microsoft Azure, Spellbook and Robin AI state AWS, and Legalfly offers Azure for dedicated deployments. The specific region depends on the vendor, the plan and sometimes the customer's request. Ask for the region in writing instead of relying on the cloud provider's name.

Can I keep legal AI data in the EU?

Some vendors say yes. Harvey states an EU app endpoint and in-region processing for the EU and Switzerland for customers with localization requirements. Whisperit and Legartis state Swiss and European hosting. Whether a given setup satisfies your obligations is a question for your own counsel, and you should confirm that the commitment covers processing and sub-processors, not only storage, and that it applies to the plan you are buying.

Does the AI model run in the same region as the data?

Not automatically. Storage and model inference are separate layers, and a vendor can configure them differently. Some vendors, including Harvey on its security page, say in-region processing is available for customers who need it. Others describe model terms (no training, zero data retention) without a location. If the answer is not in the contract, ask for it.

What is a sub-processor list?

It is the vendor's list of outside companies that may store or handle your data on its behalf: the cloud host, the model provider, support and monitoring tools, and similar services. Under GDPR-style arrangements, the list and its changes matter because your vendor's suppliers are part of your own risk. A good list names each company, what it does, and where it operates. The EDPB opinion linked above explains why controllers cannot ignore this chain.

Where to go next

Browse every tool we track, with verified pricing and ownership details, in the directory. When you shortlist two or three vendors, send them the questions in the sections above, compare the written answers side by side, and weigh those against the table. Vendors that publish regional hosting plainly are easier to buy from, and the directory is where they can say so for free at /submit.