For government
Classification, the Directive on Automated Decision-Making, Algorithmic Impact Assessment applicability, Privacy Act records retention, and official languages.
Sovereignty
Sovereign AI in Canada: control, architecture, and operating responsibility
Sovereign AI is the ability to deploy and operate AI under defined control. That control covers data, legal jurisdiction, infrastructure, identities and encryption. It extends to the models, to who has support access, to how telemetry flows and updates land, and to incident response. Canadian data residency is one component; it does not by itself establish operational or legal sovereignty. The appropriate design depends on what the information is classified as, how the workload runs and what the decision affects. It also depends on procurement obligations and the responsibilities of every service provider.
The distinction that decides the design
Sovereignty versus residency
Residency is a storage and processing fact. Sovereignty is an operating capability. The two are often treated as the same thing, and the difference decides the design.
Is Canadian data residency the same as Canadian sovereignty?
No. Residency tells you where data is stored and processed. Sovereignty tells you who holds power over the service: who can compel it, administer it, observe it, change it, interrupt it or recover it. A Canadian region operated by a foreign-controlled provider can satisfy a residency requirement while leaving jurisdiction and administrator access unresolved. Key custody and exit rights stay open too, as does model telemetry. Those are separate questions, and each belongs to a named party. Where a Canadian workload carries a residency requirement, residency is necessary and almost never sufficient.
So “the data stays in Canada” answers one of the eight questions below and none of the other seven. An institution that can answer all eight, in writing and with a named responsible party for each, has a sovereign design. One that cannot has a hosting arrangement and an unexamined dependency. The gap appears during an incident: investigating one needs logs that may sit with a supplier, and migrating away needs an export path designed in advance.
The long-form argument is in Canadian data residency is not AI sovereignty; the claims discipline that follows from it is in the table below.
Note
Three questions residency does not answer
- If a foreign court order reaches your provider’s parent company, which entity is served and what can it technically produce?
- If a support engineer needs privileged access at 02:00 to clear a priority-one (P1) incident, who approves it, is it recorded, and where does that person sit?
- If you leave in eighteen months, what exactly comes back, in what format, and who holds the keys to decrypt it?
The framework
The eight control decisions
Each dimension is a question a buyer must be able to answer about their own system. We document all eight in the sprint with the institution, record a named owner for each, and attach the result to the statement of work.
A central governed workload surrounded by eight control domains: data location and residency; legal jurisdiction; infrastructure control and administration; identity and support access. The other four are encryption and key custody; model and software control; operations and telemetry; and continuity and incident response. Residency is one control among eight, not a synonym for sovereignty.
These eight sit underneath the twelve control domains rather than alongside them. The twelve govern how the application behaves; the eight govern where it runs and which laws reach it. A workload can satisfy every one of the twelve and still be the wrong design if these eight are unanswered.
The eight are our own structuring of the question, not a published standard, and they carry no external accreditation. They exist because "sovereign" is used to mean eight different things in the same procurement conversation, and separating them lets a buyer say which ones they require. They are meant to sit alongside your security assessment, privacy assessment and procurement process, not to replace any of them.
- 01 · Data location
- Where are prompts, source data, embeddings, logs, backups and outputs stored and processed? Derived copies are where residency designs break: an embedding represents the source, a prompt log records what a named user asked, a backup runs on its own lifecycle.
- 02 · Legal jurisdiction
- Which entities and laws govern the operator, the infrastructure, the support organization and the data? The contracting party can differ from the corporate parent, and both from the support location. Ask which legal orders reach which part of the system, whatever the company's nationality.
- 03 · Infrastructure control
- Who owns, operates and administers the compute and storage, and who can physically access it? Those are three separate rights, often held by three parties, and physical access includes hardware vendors and anyone with fabric-level privileges.
- 04 · Identity and support access
- Who can reach the service, the keys, the consoles, the support channels and the incident artifacts? A break-glass path that is not enumerated, approved and logged is an undocumented administrator, and data location does not change that.
- 05 · Encryption and keys
- Who controls the keys, where are they held, how are they rotated and who can recover them? Customer-managed keys change the answer materially, but only if the key service is not administered by the party you are trying to exclude.
- 06 · Model and software control
- What is the provenance of the model and its software, how is it updated, under what licence, what telemetry does it emit, and can you roll back? A model that silently changes version has invalidated your evaluation results.
- 07 · Operations and telemetry
- What does the supplier retain, export, monitor, train on and show its staff? Answer by layer, in the contract. “We do not train on customer data” is a useful commitment. It does not mean “nothing is retained,” and it says nothing about infrastructure logs.
- 08 · Continuity and incident response
- Can the organization continue operating? Can it migrate, investigate, recover and exit? Continuity includes the degraded-mode plan for when the service is down and the work still has to happen. Exit includes the data format, the timeline, the deletion attestation and the cost.
There is no score here. These are the questions a reviewer will ask, arranged so nothing is missed. We work through all eight in the Opportunity and Governance Sprint and hand back the documented answers, including the ones still undetermined.
Note
Which of the two to read
This page defines the eight controls and works through the architecture, the responsibility split and the cost. If what you need is the version to take into a supplier meeting, read the eight supplier questions. It applies these same eight controls as questions, with the answer that should prompt a follow-up and a note on where residency is enough.
Options
Architecture patterns and trade-offs
There are four common shapes for a Canadian AI workload. None of them is universally correct. Each buys certain controls and pays for them somewhere else, and the table below names what each one costs.
| Pattern | What it buys | What it costs | Considered for |
|---|---|---|---|
| Commercial application programming interface (API), Canadian region | Fast start, current frontier capability, low operating burden, mature availability. | Weakest position on jurisdiction, provider administrator access and telemetry. Model version changes are outside your control. | Unclassified and low-impact internal workloads where the value case is still being proven. |
| Canadian-operated managed platform | Contracting party and support organization can sit in Canada; clearer jurisdictional statement. | Capability may trail the frontier. You inherit the platform’s own supply chain, which must be examined rather than assumed. | Sensitive but not high-impact workloads where jurisdiction is the binding constraint. |
| Self-hosted open-weight models | Strongest position on model control, telemetry, version pinning and rollback. No inference leaves your boundary. | You own capacity planning, graphics processing unit (GPU) cost, model evaluation, patching and the operations team. Capability gap on the hardest reasoning tasks. | Higher-classification workloads, or where model telemetry is a hard prohibition. |
| Hybrid, split by classification | Lets each task run on the cheapest architecture that satisfies its own classification. | Two control regimes to operate, and a routing layer that must itself be evaluated. A misrouted request is a disclosure. | Mixed portfolios where a single pattern would over-control most tasks and under-control a few. |
The routing risk in the hybrid pattern deserves emphasis. The moment a system decides at runtime which model handles which request, that decision is a control. It needs a deterministic rule, a test suite, a logged outcome per request and a fail-closed default. We treat classification routing as an evaluated component. It has its own acceptance threshold. It is not configuration.
Pattern selection is an output of the sprint, not an input. Choosing before anyone has looked at the data can put public information on self-hosted infrastructure and case files on a commercial API.
Fit
Data classification and workload fit
Classification is the input that determines everything downstream. It is also the easiest step to skip, because it is slow and needs a decision more than one party must agree to.
Classification, entitlements and retention rules usually already exist for the underlying business process. The mistake is assuming the AI system inherits them. It does not: retrieval collapses distinctions the source systems maintained. An assistant indexed across a shared drive inherits the union of everything in it, not the intersection of what the requester may see. An agent that can read everything cannot safely serve users whose entitlements are narrower. Identity-aware retrieval turns that around by filtering against live entitlements at the retrieval layer rather than at the answer layer.
What must you settle before you choose an architecture?
Four things. The information classification of every source the agent will touch, including derived copies. The impact of the decision the output supports, which determines whether the Directive on Automated Decision-Making applies. The entitlement model that decides who may see which source. And the records-retention obligation attached to the outputs. Settle these and the architecture options narrow to two or three. Skip them and every architecture looks equally plausible.
For federally regulated financial institutions
Model inventory, validation, ongoing monitoring and third-party model risk under Office of the Superintendent of Financial Institutions (OSFI) Guideline E-23. The guideline explicitly includes AI and machine-learning models.
Source
Source: OSFI Guideline E-23, Model Risk Management, effective 1 May 2027, applying to all federally regulated financial institutions.
Models
Model options and evaluation
Model choice is a control decision before it is a capability decision. Ask first which models can be pinned, evaluated, monitored and rolled back inside your boundary, then ask which of those performs best on your own cases.
We have no preferred model vendor and resell none. What we hold is an evaluation method. It uses a golden dataset drawn from the institution’s own cases, thresholds agreed before testing rather than after, and a documented result per candidate. Where an open-weight model on controlled infrastructure meets the threshold, that is usually the stronger sovereignty position. Where it does not, the output is a written trade-off recorded for the sponsor to decide.
- Version pinning
- The evaluated version is the deployed version. Provider-side updates are changes requiring re-evaluation, not maintenance.
- Provenance and licence
- Recorded for every model in use, including whether the licence permits the intended deployment.
- Telemetry
- What the runtime emits, to whom, and whether it can be disabled. Taken from provider documentation, not inferred.
- Rollback
- A tested path back to the previous evaluated configuration, exercised before go-live rather than assumed.
- Bilingual behaviour
- Tested in both official languages where required, because an English-only evaluation says nothing about how the service behaves in French.
The method is set out in how to evaluate a knowledge agent, and built and run during the six-week pilot.
Retention
Logging, retention and telemetry
Retention covers six or seven different lifecycles operated by two or three different parties, and it has to be documented layer by layer.
| Layer | What it contains | Who sets retention | Why it is asked about |
|---|---|---|---|
| Application logs | Prompts, retrieved passages, responses, citations, user identity, approvals | Client policy, implemented by White Glove Labs (WGL) | Often the record with the highest privacy sensitivity |
| Evaluation and audit records | Test results, thresholds, exceptions, change approvals | Client policy, retained deliberately | This is the evidence a reviewer or regulator asks for |
| Infrastructure logs | Platform access, network, storage and admin activity | Provider defaults, sometimes configurable | Often outlives application retention |
| Model or service telemetry | Usage metering, abuse monitoring, diagnostics | Provider contract terms | The layer most likely to contradict a blanket retention claim |
| Backups and snapshots | Point-in-time copies of stores and indexes | Client and provider, on separate cycles | Deletion in the live system does not delete the backup |
| Support access artifacts | Tickets, attachments, screen captures, exported diagnostics | Provider support process | An unmanaged copy of production data outside the boundary |
| Documented exceptions | Legal hold, incident investigation, regulatory request | Client legal and records authority | Every retention design needs a stated exception path |
Completing this table is what allows an accurate statement about retention. It is also what makes a blanket claim impossible to defend. At least one of these seven layers is nearly always retaining something, held by a party who is not you. A retention statement that names each layer and its holder can be verified by a reviewer.
Running it
Operations, support and incident handling
Sovereignty is tested during an outage rather than during the architecture review. The controls to check are the ones that have to hold when something is broken and someone needs privileged access quickly.
Support access
Every path by which someone outside the user population can reach production: WGL engineers, provider support, break-glass accounts. Each has an approver, a time limit and a logged record.
Incident classification
AI-specific categories alongside the usual severity scale: incorrect grounded output, unauthorized retrieval, prompt injection, safety-threshold breach, cost anomaly. Each carries a defined first action.
Degraded mode
What the workflow does when the service is down, and how people fall back to the manual path without losing work in flight. Written before go-live, not during the outage.
Investigation capability is the control easiest to overlook, because normal operation never exercises it. Investigating an AI incident needs the prompt, the retrieved context, the model version, the tool calls, the requester and the approval trail. Those records have to be correlated and retained long enough to be useful. If any of those sit only with a supplier on best efforts, that capability is contractual rather than technical, and the risk assessment should say so.
Steady-state operation of all of this is the Managed AgentOps service. That covers regression testing against the golden dataset, change control, access review, incident classification and a monthly governance report with a named owner on both sides.
Cost
Cost-model assumptions
These are the assumptions we fix before we produce any cost figure for a workload. We publish them in full so you can read and challenge them.
Warning
These are modelling assumptions, not a price list and not a quote, and we claim no comparison and no saving here, against any provider or alternative. A cost model holds only against a specific workload at a specific volume. Below are the variables we fix before we produce any figure.
| Assumption | How it is fixed | Why it changes the answer |
|---|---|---|
| Workload profile | One named workflow, described as it runs today, with its current volume | A retrieval assistant and a document-extraction pipeline have different cost shapes |
| Tokens or documents per task | Measured from a representative sample of real cases, not estimated from a demonstration | Context length dominates inference cost; demonstrations use short, tidy inputs |
| Concurrency | Peak simultaneous requests and the acceptable queue behaviour at peak | Sets the floor on reserved capacity for self-hosted patterns |
| Utilization assumption | Stated as a percentage of provisioned capacity in use | Self-hosted cost per task is mostly a utilization question |
| Support scope | Coverage hours, response targets, who is on call, and what is in scope for that team | Support is often the largest excluded cost in vendor comparisons |
| Currency and tax treatment | Canadian dollars, exclusive of applicable taxes, with the foreign-exchange assumption stated where a cost is billed in another currency | Cross-currency billing moves a multi-year figure materially |
| Explicit exclusions | Client staff time, change management and training, source-system remediation, network changes, security assessment effort, and any third-party licences the institution already holds or must acquire | These are real costs; leaving them unstated is how a model becomes misleading |
Assumptions last reviewed: 15 August 2026.
We produce a running-cost figure against these variables during the Opportunity and Governance Sprint, and print the assumptions alongside it so you can challenge them. Each service page publishes the starting figures for its engagement. We publish no payback figure, saving or return-on-investment estimate, because we have no defensible basis for one before the workload has been measured.
Claims discipline
Partner and infrastructure evidence
Below is what we do not claim, and the statement we make in each case instead.
Our current position, stated plainly
White Glove Labs makes no certification or accreditation claim of its own, and no infrastructure-partner claim. We hold a Designated Organization Screening at Reliability Status and no more. We hold no Document Safeguarding Capability and no third-party security attestation. We display no partner badge we have not earned. The one qualification we hold in our own name is on the Public Services and Procurement Canada Artificial Intelligence Source List, in Bands 1, 2 and 3. We confirmed it on 24 August 2026 under solicitation EN578-180001/B. It qualifies us to compete for opportunities in those bands. It is not an award, and it is not a security screening. This site describes architecture options generically, by pattern and control, with their trade-offs, because we write the shared-responsibility evidence against a specific requirement rather than publish it in advance. Counsel for each engagement reviews any jurisdictional statement in a proposal against its contracting parties and data flows.
Every claim in the left column below has been made by suppliers in this market, and some of them appeared on earlier versions of this website.
| Claim we do not make | What we say instead |
|---|---|
| “Protected B certified” | Name the specific service that a named body certified or assessed. Then name the exact boundary the assessment covered, the date of issue, where to obtain the evidence, and the responsibilities that remain with the client. A certification belongs to a service within a boundary at a point in time. It does not belong to a company, and it never transfers to an application you build on top. |
| “ITSG-33 / Protected B, Medium Integrity, Medium Availability compliant” | Attribute each control to the party that operates it, and publish the applicable control set and the boundary statement. ITSG-33 describes a control catalogue and a tailoring process, not a badge. The useful artifact is a control-by-control statement showing which controls the provider inherits to you, which you operate, and which we implement in the application. |
| “Approved on a federal procurement framework” | Name the exact procurement framework, the qualification band, and the supplier who holds it, and do not imply that WGL holds it. Where we would deliver through a prime or a qualified supplier, we name that supplier and the basis in writing to your contracting authority. Partner identities are commercially confidential and are not published; the route, the vehicle class and the division of work are stated precisely on request. |
| “No U.S. CLOUD Act exposure” | A precise jurisdictional architecture statement, reviewed by counsel for the specific engagement. It sets out the contracting entities, the corporate control relationships, where support and administration sit, the assumptions it depends on, and its limits. Absolute exposure statements are a legal exposure in themselves. The defensible version names what reduces risk and what remains. |
| “Zero retention” | Retention documented layer by layer. The layers are application logs; evaluation and audit records; infrastructure logs; model and service telemetry; backups and snapshots; and support access artifacts. We document the exception path for legal hold and investigation too. See the retention table above. At least one layer nearly always retains something, and the retention design should say which. |
| “5–10x cheaper” | A dated cost model for an equivalent workload. It states volume, concurrency, the utilization assumption, the support scope included, the currency and tax treatment, and what is excluded. See the assumptions above. A comparative multiple that sets a fully loaded cost against an unloaded one does not survive procurement review. |
| “Only Canadian provider” | Attribute and link a dated primary source that supports the specific statement, and record the date the statement is next due for review. Market-position claims decay quickly. If the source cannot be named and linked, the claim is not made. If the review date passes, the claim comes down until it is re-checked. |
The rule underneath the table: a claim is publishable if a named person can point to a dated artifact supporting it, and unpublishable otherwise. What that leaves us able to say today is on what we have built; supplier evidence for a live procurement is sent in writing on request.
Buying it
Procurement
A sovereignty design has to survive the contract as well as the architecture review. Three things determine whether it does.
- Write the requirement as controls rather than as a label. “Must be sovereign” is unevaluable and lets the strongest marketing claim win. A documented answer to each of the eight dimensions, with a named responsible party, is evaluable and defensible.
- Put the shared-responsibility matrix in the contract itself, not in an appendix slide. Where a control is the provider’s, their commitment should trace to a dated document you can produce during an audit.
- Price and schedule exit at signature: format, timeline, deletion attestation and cost. Negotiated at the point of leaving, all four are set by the party you are leaving.
Source
Relevant public instruments buyers cite: the Public Services and Procurement Canada (PSPC) AI Source List and the Policy on Prioritizing Canadian Suppliers. The departmental page, last modified 1 October 2025, gives 145 qualified suppliers in three bands. The bands run up to CAD $37.5M. The list itself now carries more, so count it on the day you cite it. A further Invitation to Qualify is open; confirm the current solicitation number and closing date with the departmental AI procurement team. The policy applies to strategic federal procurements at CAD $5M and above from 15 June 2026. Canadian considerations are also available below the threshold.
Our entity status, ownership, security posture, official-languages position and standard statement-of-work shapes are in the supplier evidence pack, which is sent to a contracting authority on request. A prime contractor or contracting authority can assess us without an introductory call.
Answers
Questions buyers ask about sovereign AI
What is sovereign AI in Canada?
Sovereign AI is the ability to deploy and operate AI under defined control. That control covers data, legal jurisdiction, infrastructure, identities and encryption. It extends to the models, to who has support access, to how telemetry flows and updates land, and to incident response. In a Canadian context it usually also involves classification requirements and official-languages obligations, along with records retention. It is a set of documented control decisions with named owners. It is not a product category or a hosting location. The right design depends on the workload and its classification, and on the impact of the decisions it informs.
Is Canadian data residency the same as Canadian sovereignty?
No. Residency identifies where data is stored and processed. Sovereignty additionally covers legal jurisdiction; infrastructure ownership and administration; support and administrator access; and encryption key custody. It also covers model provenance and telemetry; updates and incident response; and the ability to continue operating or to investigate, migrate and exit. A Canadian region operated by a foreign-controlled provider may satisfy residency without satisfying every sovereignty objective. Residency is one of eight dimensions, and often the easiest.
Can an AI agent handle Protected B information?
That is a design and assessment question. It cannot be answered yes or no in the abstract. It depends on the specific service and its assessed boundary. It also depends on whether the department holds an authority to operate that covers the intended use. The other factors are how the workload handles the information, and what the residual risk assessment concludes. Derived data has to be in scope too: embeddings, logs and backups. We work this through in the sprint and document the answer with its conditions.
What does ITSG-33 mean for an AI application?
ITSG-33 provides a security control catalogue and a tailoring process, so the output is a tailored control profile for a defined boundary, not a compliance badge. For an AI application it means deciding which controls the infrastructure provider inherits to you and which the department operates. The rest are implemented in the application layer, including retrieval-time access enforcement, logging, and change control over models and prompts. The artifact a reviewer wants is that control-by-control attribution.
Who is responsible for what between the client, White Glove Labs, and the infrastructure provider?
The client owns classification and entitlements; approval authority; records obligations; and the institutional incident response. WGL designs and implements the controls. It builds and runs the evaluation suite, enforces access at the retrieval layer and reports. The provider operates the platform and its authentication, along with its key service and its own incident process. For each engagement we complete a shared-responsibility matrix. We attach it to the statement of work and re-issue it whenever a model, connector or hosting decision changes.
How much does a sovereign knowledge agent cost in Canada?
We publish engagement fees as starting figures. A single-workflow Governance Sprint starts at CAD $30,000. The six-week pilot starts at CAD $85,000. Managed AgentOps starts at CAD $12,000 per month on a minimum six-month term. We confirm final fees in writing before any engagement, and they vary with scope, access, security requirements and procurement route. We model running cost separately against the assumptions above, per workload.
Next step
Take one workflow through all eight dimensions
To find out whether a sovereign design is achievable for your workload, document it against the eight controls and see which answers do not yet exist.
- One named workflow, described as it runs today
- The information classification, if it has been determined
- The sources and systems involved, including derived copies
- The sponsor who can fund a decision and the officer who will review it
Related reading: Canadian data residency is not AI sovereignty, how we govern AI agents, and what we have built.