The Data Sovereignty Questions to Ask Any AI Vendor

If you already run a standard vendor evaluation process for new software, and a client contract or partner agreement has added its own requirement about where data can and cannot be processed, the usual due diligence checklist stops being enough. A general privacy policy or a marketing page promising secure, enterprise-grade infrastructure does not tell you what you actually need to know, which is the physical and legal location of your data and how confidently the vendor can prove it. This guide gives you the specific questions that get a real answer instead of a reassuring one, and how to read the answer you get back.

What Morgan's vendor call actually revealed

Morgan manages operations for a mid-size professional services firm that just won a contract with a European client. The client's own data processing agreement requires that certain records stay within a specific region. When Morgan asked the AI vendor's sales rep where the firm's data would actually be processed, the answer was that the platform uses secure, enterprise-grade cloud infrastructure protected to the highest industry standards. Neither phrase named a country, a facility, or a contract clause.

Morgan now needs a list of follow-up questions specific enough that a vague answer becomes obviously vague, rather than just a general sense that something might be wrong.

Why this is a narrower question than general vendor due diligence

Most vendor evaluation checklists already cover security certifications, uptime guarantees, and support responsiveness. Data sovereignty is a different, narrower question sitting inside that broader process, not whether the vendor is secure in general, but specifically where the data physically sits, which legal jurisdiction that location falls under, and what happens when a contract, a regulator, or a government agency in that jurisdiction wants access to it. A vendor can score well on every general security question and still fail this one, because the two questions usually get answered by different parts of the vendor's business, sales and legal, not sales and engineering.

The questions that force a real answer

The following questions are deliberately specific. A vendor with a real answer will give you a location, a name, or a document. A vendor without one will repeat back a version of the question in reassuring language.

1. Which country and facility is our data processed and stored in, by name?

Not the cloud, not a global network, a specific country and, ideally, a specific data centre region operated by a named provider. A vague answer sounds like best-in-class cloud infrastructure. A real answer sounds like production data is processed and stored in Frankfurt and Dublin, with backups kept in the same regions.

2. Can that location change without us being told?

Some platforms load balance across regions automatically for performance, which can move data outside a region your contract requires without anyone intending it. Ask directly whether processing location is fixed by your account configuration or can shift on its own. A vendor that has clearly never been asked this before is itself a signal.

3. Who are the subprocessors, and where are they based?

Almost no vendor processes data entirely in house. Ask for the current subprocessor list, including analytics, support, and backup providers, and where each one operates. A vendor who can produce this list quickly almost certainly reviews it themselves. One who cannot has probably never had to.

4. What legal mechanism covers data leaving our region?

If data crosses a border at any point, some contractual or legal basis has to cover that transfer, such as an adequacy decision, Standard Contractual Clauses, or an equivalent local mechanism. Ask the vendor to name the actual mechanism rather than describe itself as compliant in general terms.

5. Can processing be restricted to one region by contract, and is that a standard feature or a paid add-on?

Some vendors can guarantee in-region processing, but only on an enterprise tier priced well above what a smaller business would otherwise need. Find out whether this option exists at all, and at what tier, before you decide the vendor is workable for your contract.

6. What happens to our data, and its backups, if we cancel?

Ask for a deletion timeline in writing, and whether backups held in other regions are deleted on the same schedule as the primary copy. A vendor that only addresses the primary database and stays quiet on backups has left a real gap.

7. Who can access our data, from where, and under what process?

Support staff and engineers troubleshooting an account often need some level of access. Ask which countries those staff are based in, and what internal approval someone needs before opening a customer's data. Access is strictly controlled is not an answer on its own.

8. What third-party certification backs this up, and can we see the actual report?

ISO 27001 and SOC 2 are the two most commonly cited. Ask for the certificate or audit report itself, not a logo on a marketing page. A vendor with a genuine, current certification will usually produce the document within a day or two.

Why a vague answer here is worth walking away over

A vendor that cannot answer these questions specifically is not necessarily acting in bad faith. It may simply mean nobody in sales has ever needed to know, because most customers never ask. That is exactly the problem. If your business has taken on a contractual obligation to keep certain data in a certain place, a vendor's inability to confirm where data actually goes is a real risk to that contract, not a minor gap in a sales conversation.

Where this sits alongside your own contract and privacy obligations

If your own client contract specifies a data location requirement, that requirement exists independently of whatever the AI vendor's privacy policy happens to say. The vendor's terms describe what the vendor will do. Your contract with your client describes what you have promised to do. A gap between the two is your risk to manage, not the vendor's.

For businesses working with clients or data subjects in the European Union, the General Data Protection Regulation sets out requirements for how a data controller, meaning your business, engages a data processor, meaning the AI vendor, including a written processing agreement and a lawful basis for any transfer outside the EU, such as an adequacy decision or Standard Contractual Clauses. See the European Commission's overview of international data transfer rules under GDPR and the regulation's full text for the underlying requirements.

Outside the EU, the same due diligence still matters. The US Federal Trade Commission's business guidance on data security treats a company's representations about how it protects and handles customer data as enforceable claims, meaning a vendor's vague answer today can become your problem later if it turns out to be inaccurate. See the FTC's data security guidance for businesses.

What a good answer sounds like, once you get one

A vague answer names a feeling: secure, enterprise-grade, industry-leading. A good answer names a fact: a country, a facility operator, a named subprocessor, a specific clause in a data processing agreement, or a certificate you can actually open and read. If a vendor's answer to any of the questions above could apply equally to any competitor without changing a word, treat it as unanswered and put the question in writing instead.

What to do once you have the answers

Once a vendor has given specific answers, compare them line by line against your own contract's requirements, not against a general sense of reassurance. If a vendor can name the region, name the subprocessors, and produce the certification, that is a workable answer. If a vendor can only answer two or three of the eight questions above, use the gaps as your negotiation list before signing, rather than something to revisit after the contract is already in place. Where the gap cannot be closed and your contract genuinely requires in-region processing, that is a reason to shortlist a different vendor rather than accept the risk.

Related reading: our AI governance by region.

Try our free AI Privacy Risk Scorer to score your current AI tool setup against data-privacy best practice.

Is asking these questions realistic during a normal sales process?

Yes. A vendor selling to businesses with their own compliance obligations expects this level of question and usually has a security or legal contact who can answer in writing, even if the first-line sales rep cannot. If a vendor cannot connect you to that contact at all, treat that as an answer in itself.

What if the vendor says the information is confidential?

The specific list of subprocessors, the region of processing, and the transfer mechanism are standard disclosures in a data processing agreement, not trade secrets. A vendor refusing to disclose these in writing before signing is refusing a normal request, not protecting something legitimately confidential.

Do these questions apply to every AI tool, or just ones handling sensitive data?

They matter most for any tool processing client data, personal information, or anything covered by a client contract's own data location clause. For a tool used purely internally with no client or regulated data involved, the stakes are lower, though the same questions still cost nothing to ask.

How is this different from just reading the vendor's privacy policy?

A privacy policy is written to cover the vendor's entire customer base and is rarely specific about your account's actual processing location or your particular contract's requirements. These questions get a specific, current, written answer instead of a general policy document that may never resolve your specific contractual obligation.