Hosting your data in Montréal is not enough to make it sovereign. A server located in Canada but operated by an American company remains subject to the CLOUD Act (2018), which allows U.S. authorities to require a company under their jurisdiction to produce the data it holds, wherever that data is stored. Confusing data residency with sovereignty is the most widespread mistake, and artificial intelligence makes it more costly: every question sent to a model, every indexed document, every retained log is one more flow to control.
This article draws on the work of the Brigade IA Sovereign AI Architectures workstream, led by our founder. It summarizes its framework for leaders: five dimensions, a spectrum of options for each, and a way to decide what should be sovereign depending on the type of organization. For the strategic side (vendor dependency, in-house expertise), see also our article on technology sovereignty.
What does sovereignty mean in practice?
Being sovereign means being able to make your own technology choices and enforce them: to examine, modify, move or replace your data, models and infrastructure without a vendor or a foreign state being able to impose a decision, cut off access or demand your data. The Government of Canada's Digital Sovereignty Framework describes it as the ability to exercise autonomy over one's digital infrastructure, data and intellectual property.
Two nuances change everything. First, sovereignty is not absolute: it comes in degrees, and a low level is not a fault in itself; it depends on what you are protecting. Second, sovereignty and security do not always move together. Major cloud providers offer mature security out of the box (round-the-clock teams, certifications, fast patching) that is hard to replicate in-house. A more sovereign architecture lets you go further (complete isolation, encryption keys under exclusive control, logs kept in-house), but only if the organization invests in the skills to run it.
An analogy helps place the options: you can rent a turnkey apartment (a vendor's public API), buy a condo in a managed building (a dedicated or sovereign cloud), or build a house on your own land (infrastructure deployed on premises). No option is better in itself. The most common mistake is not choosing the wrong one, but choosing without having seen the full menu.
Five dimensions, five questions
A system can be sovereign on one dimension and dependent on another. An open model deployed with a provider subject to the CLOUD Act gives you control over the weights, not over the infrastructure. A proprietary model connected to a document base hosted in-house protects the corpus at rest, but the user's question and the retrieved excerpts go to the vendor with every request. These gaps are not a problem in themselves. They become one when they are invisible.
1. Data: who controls what feeds the system?
Four categories flow through an AI system: the model's training data, the organization's reference data (documents queried, fine-tuning sets), the requests and responses exchanged with each interaction, and usage traces (logs, caches). Requests are the most exposed; traces, the most neglected. From least to most sovereign, the spectrum runs as follows:
- external service with no specific agreement, where data may be used to train the vendor's model;
- external service with a business agreement (no training use, bounded retention);
- dedicated environment with a major cloud provider;
- dedicated environment encrypted with keys held only by the organization (HYOK);
- Canadian provider outside any foreign jurisdiction;
- full hosting on the organization's own servers.
A common trap: managing your own keys at the vendor (BYOK) improves control over their life cycle, but does nothing for jurisdictional exposure, since the keys remain in the vendor's infrastructure. Only keys out of its reach (HYOK) change that parameter.
2. The model: who controls its weights, behaviour and updates?
The fundamental criterion is access to the model's weights. Without it, the vendor can change the behaviour, raise prices or withdraw the service with no immediate alternative for the organization.
- proprietary API whose version changes without notice;
- proprietary API with a pinned version: stable, but with forced migrations;
- open model deployed with a major provider: sovereignty over the model, not the infrastructure;
- open model deployed on premises or with a sovereign provider;
- open model fine-tuned on the organization's data, in an environment it controls.
Be careful: entrusting fine-tuning to a vendor's platform hands it the fine-tuning data, and the specialized version may remain captive to that platform. Sovereignty then moves backward instead of forward.
3. Infrastructure: where does processing run, and under which law?
This is the hardest dimension to take all the way, because hardware is subject to global physical and geopolitical constraints. Three tiers emerge:
- legal and operational sovereignty: a cloud operated by a Canadian entity with no foreign parent company and open orchestration; the chips, however, still come from a small number of foreign manufacturers;
- physical sovereignty: owned servers in a disconnected environment with no outbound flows; the dependency shifts to spare parts and hardware renewal;
- full technological sovereignty: from chip design to manufacturing; out of reach for almost every organization when it comes to cutting-edge AI.
4. The application layer: who decides what the AI actually does?
This is the dimension where the organization keeps the most leverage, whatever the model. Four questions are enough to take stock. Is the logic around the model call readable, modifiable and portable? Would the guardrails survive a change of model? Could you justify a decision three months later from logs you control? Have you defined not only who uses the AI, but what the AI is allowed to do? At one end of the spectrum sits an opaque service; at the other, a layer the organization owns, examines and can redeploy elsewhere.
5. Operations: who can maintain and evolve the system?
An architecture that is sovereign on paper only becomes sovereign in practice if the organization can reproduce the system, examine its past behaviour, correct it without a vendor's approval and replace the model without rebuilding the application. That takes separate environments, a model registry, drift monitoring and logs kept under its own control. Without these practices, a system is in production, not in operation.
Public body or private company: what should be sovereign differs
In a public body, the central issue is citizens' trust: their personal information, the continuity of essential services and accountability. Before communicating personal information outside Québec, the Act respecting Access to documents held by public bodies requires a privacy impact assessment (s. 70.1), and Québec's digital sovereignty policy statement (in French) aims to reduce the State's technological dependency. For sensitive uses, the target becomes an open model on controlled infrastructure, an owned application layer and logs kept in-house. Supervised external services keep their place for exploration and public data.
In a private company, the issue shifts to intellectual property, trade secrets, customer and insurer requirements, and cost. The Act respecting the protection of personal information in the private sector also requires an assessment before any communication outside Québec (s. 17). Most companies benefit from a combined architecture: supervised external services for everyday uses, a sovereign document base for the knowledge that sets them apart, and an environment under their own control for trade secrets.
In both cases, data sensitivity sets the dial:
- public or promotional data: a public cloud service, governed by contract, is often enough;
- human resources, operational or personal data: a Canadian cloud outside any foreign jurisdiction;
- trade secrets, health, legal: an on-premises environment, possibly disconnected.
Getting there: a trajectory, not a leap
Three questions drive most decisions. What is the highest classification of the data that will flow through the system? What volume of use is expected, and how variable is it? What in-house operating capacity can be built within 12 to 18 months?
Organizations rarely jump straight to on-premises hosting. The usual trajectory goes from an assistant connected to an API, to a sovereign document base (RAG) whose index and access controls stay in-house, then to an open model deployed on controlled infrastructure for sensitive uses. Agents are then added as an orchestration layer, with least privilege and human approval for any irreversible action.
What makes this trajectory possible is decided from the very first project: an abstraction layer that lets you switch models, open formats, logging kept on your side and versioned regression tests. One simple question serves as a test: if your vendor doubled its prices tomorrow, how long would it take you to migrate?
The leader's role: making informed trade-offs
These choices are not primarily technical. They commit the budget, legal risk, service continuity and the ability to innovate. A leader does not need to configure an inference engine, but must be able to read the full menu, ask vendors the right questions and tell a deliberate trade-off from an imposed dependency.
That is the aim of our AI coaching program: one-on-one support, starting from your context, to map your dependencies dimension by dimension, place each of your use cases on its spectrum, decide what should be sovereign for you and build the path to get there. You are coached by Olivier Garand, who leads the Brigade IA Sovereign AI Architectures workstream. Our founder brings 25 years of experience in information technology, in both the public and private sectors, with hands-on experience integrating AI in business.
The right level of sovereignty is not the highest possible. It is the one you chose knowing the options, and that you can evolve.