Data sovereignty: the questions every CTO should ask
A checklist of the 14 questions you should put to any AI vendor before signing — and why most cloud AI providers cannot answer all of them.
Why This Suddenly Matters
Until about two years ago, "data sovereignty" was a phrase that lived in the vocabulary of enterprise IT teams and privacy lawyers. Then AI arrived at scale, and suddenly every business of every size was being asked to route its most sensitive operational data — client records, contracts, internal processes, financial information — through infrastructure owned and operated by companies headquartered in San Francisco or Seattle.
For most businesses, the question of where data lives and who controls it had never really come up. Your accounting software lives in the cloud. Your CRM lives in the cloud. You didn't think too hard about it because those systems process data in defined, narrow ways, and because the risk of a breach was primarily financial and reputational.
AI changes the calculus in two ways. First, AI systems don't just store and retrieve data — they reason over it, synthesize it, and produce outputs that reflect the structure of what was input. Your proprietary business knowledge is more exposed, in a more meaningful sense, when it's used to generate AI outputs than when it's stored in a database. Second, many jurisdictions have updated their data handling requirements in response to AI specifically, and the legal risk landscape has shifted meaningfully in the last 24 months.
PIPEDA's accountability principle means you are responsible for data in the custody of third parties on your behalf — their breach is your breach. Quebec's Law 25 (Bill 64) imposes additional privacy impact assessment requirements that explicitly apply to AI use cases. The OPC has issued AI-specific guidance most businesses are not yet fully complying with. Regulated sectors (legal, healthcare, financial) face additional obligations that don't disappear because you've delegated to a vendor.
The 14 Questions
1. Where, physically, is my data processed?
Not where it's stored — where it's processed. These are often different answers. Many vendors store data in a local region but process queries through global infrastructure. The processing jurisdiction determines which laws apply to your data.
2. Is my data used to train or fine-tune any models?
This should be a binary answer: yes or no. "We may use anonymised data to improve our services" is a yes wrapped in qualifications. Get it in writing, not in a sales call.
3. Who are your sub-processors, and can I see the full list?
Most cloud AI vendors use sub-processors — third parties who handle parts of the data pipeline. Under PIPEDA and many other frameworks, your obligations as a data controller don't disappear when you delegate to a vendor; their sub-processors are your sub-processors. You're entitled to know who they are.
4. What happens to my data when I end the contract?
Specifically: is it deleted? When? How is deletion verified? Is there any retention in backups or audit logs? "We delete your data" is not the same as "we delete your data within 30 days, including from all backup systems, and can provide a certificate of deletion on request."
5. Can your employees access my data? Under what circumstances?
Support access, training access, quality review. "Access controls are in place" is not an answer. Who specifically can see what, and what logging exists for those access events?
6. What certifications do you hold? Can I see the audit reports?
SOC 2, ISO 27001, and similar certifications mean something — but only if you can see the actual audit report, not just the badge. A SOC 2 Type I report is a point-in-time snapshot. A SOC 2 Type II covers a period of operation. For sensitive data, you want Type II.
7. What is your breach notification process and timeline?
Under PIPEDA and most provincial frameworks, you may be obligated to notify affected individuals if your vendor experiences a breach involving your data. How quickly will they tell you? What information will they provide?
8. Can I conduct my own audit or security assessment?
Vendors who say no to this question are vendors who have something to protect. Reasonable restrictions exist — you're not walking into their data centre — but an outright refusal to permit independent assessment is a significant red flag.
9. What jurisdiction governs the contract and any disputes?
Many cloud contracts default to California or Delaware law. For Canadian businesses, this means that a dispute about your data is governed by a foreign legal system. Understand this before you sign.
10. How is my data isolated from other customers' data?
Logical isolation (separated by software controls) is standard; physical isolation is rarer and more expensive. Know which you're getting.
11. What model(s) are processing my data, and how often do they change?
If the model your queries run against changes, that change may have data handling implications. You should know when this happens and have the right to be notified.
12. Can I get the system deployed in my environment rather than yours?
For some vendors, this is possible. For others, it's not. Knowing the answer tells you something important about the architecture — and about your options if your requirements change.
13. What is your policy on government data requests?
US cloud providers are subject to US legal processes including national security orders that they may not be permitted to disclose. If your data is processed on US infrastructure, it is potentially subject to US government access regardless of where it's stored. This is not theoretical. It's happened repeatedly. Ask directly.
14. Where does your AI system send data for inference?
This question catches a specific and common issue: vendors who market local or private AI solutions but rely on external APIs for the actual inference step. The data goes local for storage, then out to a third-party provider for the intelligence step. This defeats the entire purpose of a private AI deployment. Get a specific technical answer, not a marketing answer.
Trust is not a data governance strategy. These questions exist precisely because "they said it was fine" is not sufficient for compliance, for professional obligations, or for protecting the business knowledge you've spent years building.
Reading the Answers
Most vendors will answer the first ten questions cleanly. Questions 11 through 14 are where the gaps emerge. A vendor who gives you vague, deferred, or evasive answers to questions 3, 5, 13, and 14 specifically is telling you something important.
Q2: Is my data used to train models? (Insist on a written answer.)
Q3: Who are your sub-processors? (Full list, not a category description.)
Q5: Can your employees access my data? (Who, how, with what logging?)
Q13: Government data request policy? (Especially for US-hosted systems.)
Q14: Where does inference happen? (The "private AI" that calls OpenAI is not private.)
What to Do With the Answers
If questions 2, 3, 5, 13, and 14 have clean, verifiable answers: cloud AI may be appropriate for your use case. If any of those five answers are vague, deferred, or unsatisfactory: the data you're routing through this system is less protected than you probably assumed. If your use case involves client-confidential or regulated data: the appropriate default is infrastructure you control, not infrastructure you trust.