Alberta’s Sovereign AI Test: Control, Not Residency

A server can sit in Calgary while the power to shut it down, patch it, or replace it sits with a company thousands of kilometres away. Alberta’s Sovereign Compute Environment procurement is an unusually explicit Canadian attempt to close that gap—and it deserves the attention of every public-sector executive who buys AI.

On July 31, 2026, Alberta’s Ministry of Technology and Innovation published Pre-Qualification Request (PQR) AB-2026-00655 on the Alberta Purchasing Connection portal, mirrored on the federal CanadaBuys service. It seeks suppliers across three categories—sovereign compute, AI solutions, and analytics and analysis—with pre-qualified suppliers becoming eligible to respond to Statements of Work issued under it. The solicitation closes August 31, 2026 and may be amended; its wording is reported here as of August 10, 2026.

The intended users signal the stakes: the posting names the Deputy Minister of Executive Council, the Senior Deputy Minister of Operations, the Corporate Operating Officer Committee, and the Continuous Improvement Cabinet Committee—infrastructure meant to support decisions at the centre of the provincial government.

Data residency is necessary in some contexts, but it is not sovereignty. On Maple Quanta’s control-based reading, meaningful operational sovereignty turns on who can control, administer, modify, interrupt, inspect, and ultimately replace the technology.

What Alberta has actually required

Two provisions in the posting matter most, and both go beyond a residency clause.

• Domestic control of the technology itself. The environment “must use domestically controlled software, AI models, and platforms”—measures the Province describes as necessary “to protect the privacy of individuals, safeguard the confidentiality of individual records, maintain public order and safety, and protect the essential security interests of Alberta.”
• Control over who touches the data. “Access to and interpretation of data will be restricted to Contractor resources physically residing in Canada and Alberta, as required, holding security clearances appropriate to the scope of each Statement of Work.” Contractors must also maintain security standards “consistent with the highest standards of business practice in the industry for data and information security.”

Our read: the first provision governs what the environment is built from—the software, model, and platform layer; the second, who may access and interpret the data once it is running. Together they replace a simple residency test with a layered control test.

The unresolved test: what counts as “domestically controlled”?

The posting’s most consequential phrase is also its least defined. The public language does not say how domestic control will be measured. Control could turn on beneficial ownership of the supplier; the location of privileged administrators; possession of model weights or source code; authority over updates, system prompts, safety policies, and licensing; control of encryption keys and identity systems; remote-access and shutdown authority; or contractual continuity and migration rights. A vendor can pass some of these tests while failing others. How Alberta operationalizes the phrase in the negotiated phase—through definitions, verification procedures, and contract terms—will determine whether “domestically controlled” becomes a substantive, verifiable requirement or remains primarily directional. That is an observation about drafting, not a legal conclusion.

Just as important is what Alberta’s broader strategies do and do not say. The AI Data Centre Strategy (December 2024) is an investment-attraction document built on power capacity, sustainable cooling, and economic growth; it sets no control requirements. The Technology and Innovation Strategy 2.0 names AI sovereignty among its themes but neither defines the term nor establishes the PQR’s operational-control requirements. The distinction is ours, and worth keeping in mind: a jurisdiction’s data-centre ambitions and its sovereignty requirements are not the same thing.

Why “where is the data stored?” is not enough

Data residency answers one narrow question: where data is physically stored. It does not, by itself, determine which laws may reach that data, who can access it, or who controls the system. The Government of Canada’s Guideline on Service and Digital reflects the same distinction: residency is one consideration in assessing data sovereignty and legal exposure, not a proxy for control.

Federal programs point the same way. Ottawa’s AI Sovereign Compute Infrastructure Program (SCIP)—a roughly $890 million program under the $2 billion Canadian Sovereign AI Compute Strategy—defines sovereign infrastructure as “a Canadian-located, Canadian-governed system that ensures data residency, operational control, and decision-making authority and agency remain in Canada.” Residency is one clause among three. Operational control and decision-making authority are named separately because they are separate problems.

Our conclusion: for procurement purposes, AI sovereignty is best treated as a problem of control and dependency management, not geography alone. Alberta’s PQR does not establish Canada’s official definition of sovereign AI—it is one provincial solicitation for one internal use case—but it is a concrete Canadian example of operational sovereignty translated into formal procurement language. The question is no longer “is the server in Canada?” It is “who actually controls the system?”

Eight questions that define control

The Maple Quanta Sovereign AI Framework extends the Practical Sovereignty Test from our earlier analysis of commercial sovereignty offerings into eight procurement-ready questions:

1. Legal control. Which jurisdictions, contracts, ownership structures, or foreign authorities can compel access, restrict use, or interrupt service?
2. Data control. Who can access, copy, transfer, or delete your data—and who holds the encryption keys?
3. Administrative control. Who holds root, cloud-administrator, and identity-system privileges, and where are those people located?
4. Model and software control. Who controls weights, updates, system prompts, APIs, and licensing—and can functionality be withdrawn without your approval?
5. Operational control. Who can shut the system down, suspend accounts, restrict capacity, or revoke licences?
6. Technical substitutability. Can the model, cloud provider, API, identity system, or database be replaced without rebuilding the application?
7. Continuity and resilience. How long could operations continue if a critical provider disappeared or became legally unavailable?
8. Domestic capability. Does the organization—or Canada—have the people and expertise to operate, maintain, or replace the critical components?

Exit Time and Exit Cost, made measurable

Exit planning is not a Maple Quanta invention. OSFI’s Guideline B-10 expects federally regulated financial institutions to establish contingency and exit plans proportionate to the risk and criticality of their third-party arrangements, and the Canadian Centre for Cyber Security recommends that cloud contracts address portability, data extraction, reasonable exit costs, and vendor lock-in. B-10 binds only those institutions—we cite it as a Canadian benchmark for third-party risk, not a universal requirement. The distinctive step is applying these disciplines as sovereign-AI control measures.

Exit Time is the elapsed time from a formal exit decision—or a provider-loss event—until an alternative system meets a predefined minimum acceptable service level. Exit Cost is the total one-time cost, direct and indirect, of restoring that service through another provider or an internal solution. Where applicable, it includes termination costs, data egress, engineering and integration, model re-evaluation, security and compliance validation, parallel operation, staff retraining, and business interruption or lost functionality during migration.

To be decision-grade rather than rhetorical, each estimate should record its supporting evidence, confidence level, accountable owner, last-tested date, and assumed minimum service level. An untested Exit Time is a hypothesis, not a control.

Two systems can store every byte of their data in Canada and still have opposite sovereignty profiles. Picture a generative AI service with databases in Calgary that depends on a proprietary foreign foundation model, a foreign-controlled API, foreign administrators, and non-portable interfaces. If the model provider terminates service, the system stops working—and restoring it on another model could take a year of engineering. Calling that architecture “sovereign” because its database resides in Alberta would be misleading.

Now picture a second system with Canadian administrative control, customer-held encryption keys, portable data, open interfaces, several compatible models, local inference capability, and a tested migration plan. Its Exit Time is measured in days or weeks. It is meaningfully more sovereign, despite continuing to rely on international components.

Data residency tells you where your data is. Exit Time tells you how much control you actually have.

What procurement teams should do differently

Every high-impact AI procurement should include a Critical Dependency Register. For each critical dependency, record the provider and its ultimate ownership; the governing jurisdictions; who holds privileged access; whether the provider can reach your information; what stops working if it disappears; realistic substitutes; portability of workloads and data; Exit Time; Exit Cost; and the residual risk that cannot be removed. This gives a board a usable sovereignty picture—something a checkbox marked “Canadian data residency” cannot.

A short list of questions, answered in writing before signature, completes it:

• Who controls the encryption keys, and where are privileged administrators physically located?
• Who can modify the model, and which external APIs must stay reachable?
• Can we export all data, prompts, and configurations in usable formats?
• What migration rights and transition assistance does the contract guarantee?
• What are the evidenced Exit Time and Exit Cost—and when were they last tested?

Exit architecture should be designed during procurement, not during a crisis. Structured exercises such as an AI Governance Review, AI Readiness Assessment, or Data Science & AI Technical Audit can build the register and test the exit plan before a contract is signed.

What this signals for Canada

For CIOs, CISOs, boards, and procurement officers, Alberta’s PQR is a signal to watch, not a template to copy. A province has written control-oriented requirements into a live solicitation just as a federal program applies control-plus-residency language at national scale. Together they suggest Canadian sovereign-AI practice is maturing past a pure residency test—an observed pattern across two documents, not evidence of coordinated federal–provincial policy.

The bottom line

Modern computing runs on international dependencies—chips, operating systems, open-source libraries, cloud platforms, foundation models—and no Canadian organization will eliminate them all, nor should it try. Sovereignty requires that critical dependencies be visible, governed, understood, and substitutable where it matters.

Maple Quanta view: Sovereign AI should not mean technological isolation. It should mean operational freedom: knowing which dependencies matter, retaining control over them where necessary, and preserving the practical ability to leave when a supplier no longer serves your interests. The question is no longer only where your AI runs. It is who controls it—and whether you can leave.

Primary government sources: Government of Alberta, Sovereign Compute Environment Pre-Qualification Request, AB-2026-00655, July 31, 2026 (also on CanadaBuys) · Government of Alberta, AI Data Centre Strategy—Powering the Future of Artificial Intelligence, December 2024 · Government of Alberta, Technology and Innovation Strategy 2.0 · ISED, Canadian Sovereign AI Compute Strategy · ISED, Program Guide: AI Sovereign Compute Infrastructure Program · Treasury Board of Canada Secretariat, Guideline on Service and Digital · Canadian Centre for Cyber Security, ITSM.50.104: Recommended Cyber Security Contract Clauses for Cloud Services · OSFI, Guideline B-10: Third-Party Risk Management.

This Insight is for general informational purposes only. It does not constitute legal, procurement, cybersecurity, investment, or regulatory advice.