IA souveraine au Canada : contrôle, architecture et responsabilité d’exploitation

La résidence des données au Canada équivaut-elle à la souveraineté canadienne ?

Non. La résidence vous dit où l’on stocke et traite les données. La souveraineté vous dit qui détient le pouvoir sur le service : qui peut le contraindre, l’administrer, l’observer, le modifier, l’interrompre ou le rétablir. Un fournisseur sous contrôle étranger peut exploiter une région canadienne qui satisfait à une exigence de résidence. Il laisse alors en suspens la compétence juridique et l’accès des administrateurs. La garde des clés, la télémétrie des modèles et les droits de sortie restent ouverts eux aussi. Ce sont des questions distinctes, et chacune revient à une partie nommée. Lorsqu’une charge de travail canadienne est assortie d’une exigence de résidence, la résidence est nécessaire et presque jamais suffisante.

Ces huit contrôles se situent sous les douze domaines de contrôle plutôt qu’à côté d’eux. Les douze régissent le comportement de l’application ; les huit régissent l’endroit où elle s’exécute et les lois qui l’atteignent. Une charge de travail peut satisfaire à chacun des douze et rester la mauvaise conception si ces huit-là restent sans réponse.

Les huit sont notre propre structuration de la question, et non une norme publiée ; ils ne portent aucune accréditation externe. Ils existent parce que le mot « souverain » sert à désigner huit choses différentes dans une même conversation d’approvisionnement. Les séparer permet à un acheteur de dire lesquelles il exige. Ils sont faits pour accompagner votre évaluation de sécurité, votre évaluation de la protection des renseignements personnels et votre processus d’approvisionnement, et non pour en remplacer un seul.

01 · Lieu des données

Où stocke-t-on et traite-t-on les invites, les données sources, les plongements, les journaux, les copies de sauvegarde et les sorties ? Les conceptions fondées sur la résidence cèdent aux copies dérivées. Un plongement représente la source. Un journal d’invites consigne ce qu’un utilisateur nommé a demandé. Une copie de sauvegarde suit son propre cycle de vie.

02 · Compétence juridique

Quelles entités et quelles lois régissent l’exploitant, l’infrastructure, l’organisation de soutien et les données ? La partie contractante, la société mère et le lieu du soutien peuvent tous différer. La question n’est pas de savoir s’il s’agit d’une entreprise canadienne, mais quels ordres juridiques atteignent quelle partie du système.

03 · Contrôle de l’infrastructure

Qui possède, exploite et administre la puissance de calcul et le stockage, et qui peut y accéder physiquement ? Ce sont trois droits distincts, souvent détenus par trois parties, et l’accès physique englobe les fournisseurs de matériel et quiconque détient des privilèges au niveau de la trame d’infrastructure.

04 · Identités et accès du soutien

Qui peut atteindre le service, les clés, les consoles, les canaux de soutien et les artefacts d’incident ? Un chemin d’accès d’urgence qui n’est ni énuméré, ni approuvé, ni consigné est un administrateur non documenté, et le lieu des données n’y change rien.

05 · Chiffrement et clés

Qui contrôle les clés, où sont-elles conservées, comment sont-elles renouvelées et qui peut les récupérer ? Les clés gérées par le client changent sensiblement la réponse, mais seulement si le service de gestion des clés n’est pas administré par la partie que vous cherchez à exclure.

06 · Contrôle du modèle et du logiciel

Quelle est la provenance du modèle et de son logiciel, comment est-il mis à jour, sous quelle licence, quelle télémétrie émet-il, et pouvez-vous revenir en arrière ? Un modèle qui change de version en silence a invalidé vos résultats d’évaluation.

07 · Exploitation et télémétrie

Que conservent les fournisseurs, qu’exportent-ils, qu’observent-ils, sur quoi entraînent-ils leurs modèles ? Répondez couche par couche, dans le contrat. « Nous n’entraînons pas nos modèles sur les données des clients » est un engagement utile. Ce n’est pas « rien n’est conservé », et cela ne dit rien des journaux d’infrastructure.

08 · Continuité et réponse aux incidents

L’organisation peut-elle continuer à fonctionner, migrer, enquêter, se rétablir et sortir ? La continuité comprend le plan de fonctionnement en mode dégradé, pour les moments où le service est hors service et où le travail doit tout de même se faire. La sortie comprend le format, l’échéancier, l’attestation de suppression et le coût.

Il n’y a pas de note ici. Ce sont les questions qu’un examinateur posera, disposées de façon que rien ne soit oublié. Nous parcourons les huit dans le Sprint de cadrage et de gouvernance et nous remettons les réponses documentées, y compris celles qui restent indéterminées.

Le risque d’aiguillage propre au schéma hybride mérite qu’on y insiste. Dès qu’un système décide à l’exécution quel modèle traite quelle demande, cette décision est un contrôle. Elle exige une règle déterministe, une suite de tests, un résultat consigné pour chaque demande et un comportement par défaut de fermeture en cas d’échec. Nous traitons l’aiguillage par classification comme un composant évalué, doté de son propre seuil d’acceptation, et non comme de la configuration.

Le choix du schéma est un extrant du sprint, non un intrant. Choisir avant que quiconque ait examiné les données peut placer de l’information publique sur une infrastructure hébergée par vous et des dossiers de cas sur une API commerciale.

Trois règles en régissent l’emploi. Chaque cellule nomme une partie, et « partagé » n’est pas une valeur acceptable, parce que partagé désigne un partage que nous n’avons pas fini de décrire. Toute ligne où les trois parties croient qu’une autre est responsable fait l’objet d’une escalade écrite avant le début de la construction. Et nous versionnons la matrice : lorsqu’une décision de connecteur, de modèle ou d’hébergement change, nous la rééditons plutôt que de la modifier en silence.

La colonne du fournisseur est la plus facile à accepter sur parole. Nous la remplissons à partir de la documentation publiée du fournisseur et des clauses contractuelles, et nous consignons le nom et la date du document. Lorsque nous ne pouvons pas rattacher un engagement à un document daté, nous marquons la cellule comme non vérifiée. Le modèle de contrôle qui sous-tend cette matrice se trouve dans sécurité et gouvernance.

La classification, les droits d’accès et les règles de conservation existent habituellement déjà pour le processus opérationnel sous-jacent. L’erreur consiste à présumer que le système d’IA en hérite. Il n’en hérite pas : la récupération efface des distinctions que les systèmes sources maintenaient. Un assistant indexé sur un lecteur partagé hérite de l’union de tout ce qui s’y trouve, et non de l’intersection de ce que le demandeur a le droit de voir. Un agent qui peut tout lire ne peut pas servir en toute sécurité des utilisateurs dont les droits d’accès sont plus étroits. La récupération tenant compte de l’identité renverse cela en filtrant selon les droits d’accès en vigueur à la couche de récupération plutôt qu’à la couche de réponse.

Que faut-il régler avant de pouvoir choisir une architecture ?

Quatre choses. La classification de l’information de chaque source que l’agent touchera, y compris les copies dérivées. L’incidence de la décision que la sortie appuie, qui détermine si la Directive sur la prise de décisions automatisée s’applique. Le modèle de droits d’accès qui décide qui peut voir quelle source. Et l’obligation de conservation des documents rattachée aux sorties. Réglez ces quatre points et les options d’architecture se réduisent à deux ou trois. Sautez-les et toutes les architectures paraissent également plausibles.

Nous n’avons aucun fournisseur de modèles privilégié et nous n’en revendons aucun. Ce que nous détenons, c’est une méthode d’évaluation. Elle repose sur un jeu de données de référence tiré des cas mêmes de l’institution et sur des seuils convenus avant les essais plutôt qu’après. Elle produit un résultat documenté pour chaque candidat. Lorsqu’un modèle à poids ouverts installé sur une infrastructure contrôlée atteint le seuil, c’est habituellement la position de souveraineté la plus forte. Lorsqu’il ne l’atteint pas, le résultat est un compromis écrit, consigné pour que le parrain du projet tranche.

Épinglage de version

La version évaluée est la version déployée. Les mises à jour du côté du fournisseur sont des changements qui exigent une réévaluation, et non de l’entretien.

Provenance et licence

Consignées pour chaque modèle en usage, y compris la question de savoir si la licence permet le déploiement prévu.

Télémétrie

Ce que l’environnement d’exécution émet, à qui, et si cela peut être désactivé. Tiré de la documentation du fournisseur, et non déduit.

Retour arrière

Un chemin testé vers la configuration évaluée précédente, exercé avant la mise en production plutôt que présumé.

Comportement bilingue

Testé dans les deux langues officielles lorsque c’est requis, parce qu’une évaluation faite uniquement en anglais ne dit rien du comportement du service en français.

Nous exposons la méthode dans comment évaluer un agent de connaissance, puis nous la construisons et l’exécutons pendant le projet pilote de six semaines.

C’est le fait de remplir ce tableau qui permet un énoncé exact sur la conservation, et c’est aussi ce qui rend une affirmation générale impossible à défendre. Au moins une de ces sept couches conserve presque toujours quelque chose, et une partie autre que vous la détient. Un examinateur peut vérifier un énoncé de conservation qui nomme chaque couche et son détenteur.

La capacité d’enquête est le contrôle le plus facile à négliger, parce que l’exploitation normale ne la met jamais à l’épreuve. Enquêter sur un incident d’IA exige l’invite, le contexte récupéré, la version du modèle, les appels d’outils, le demandeur et la trace des approbations. Ces dossiers doivent être corrélés et conservés assez longtemps pour être utiles. Si l’un d’eux ne se trouve que chez un fournisseur, au mieux de ses efforts, cette capacité est contractuelle plutôt que technique, et l’évaluation des risques devrait le dire.

L’exploitation en régime permanent de tout cela relève du service d’exploitation gérée des agents (AgentOps). Ce service couvre les tests de non-régression au regard du jeu de données de référence, le contrôle des changements et la revue des accès. Il couvre aussi la classification des incidents et un rapport de gouvernance mensuel avec un responsable nommé de chaque côté.

Hypothèses revues pour la dernière fois le 15 août 2026.

Nous produisons un chiffre de coût d’exploitation au regard de ces variables pendant le Sprint de cadrage et de gouvernance. Nous imprimons les hypothèses à côté du chiffre pour que vous puissiez les contester, et les chiffres de départ de chaque mandat figurent sur sa page de service. Nous ne publions aucun chiffre de délai de récupération, aucune économie ni aucune estimation de rendement du capital investi, faute de base défendable avant la mesure.

Notre position actuelle, en toutes lettres

White Glove Labs ne revendique aucune certification, aucune accréditation ni aucun partenariat d’infrastructure qui lui soit propre. Nous détenons une vérification d’organisation désignée (VOD) au niveau de la cote de fiabilité, et rien de plus. Nous ne détenons aucune autorisation de détenir des renseignements (ADR) ni aucune attestation de sécurité délivrée par un tiers. Nous n’affichons aucun insigne de partenaire que nous n’avons pas mérité. La seule qualification que nous détenions en notre propre nom figure sur la Liste des fournisseurs pour de l’intelligence artificielle de Services publics et Approvisionnement Canada. Elle vise les bandes 1, 2 et 3. Sa confirmation date du 24 août 2026, au titre de la demande de soumissions EN578-180001/B. Elle nous rend admissibles à concourir pour des occasions dans ces bandes. Ce n’est pas une attribution de contrat, et ce n’est pas une vérification de sécurité. Ce site décrit les options d’architecture de façon générique, par schéma et par contrôle, avec leurs compromis. Nous rédigeons les preuves de partage des responsabilités au regard d’un besoin précis plutôt que de les publier à l’avance. Un conseiller juridique révise, pour chaque mandat, tout énoncé de compétence juridique figurant dans une proposition. La révision porte sur ses parties contractantes et ses flux de données.

Chacune des affirmations de la colonne de gauche ci-dessous a été faite par des fournisseurs de ce marché, et certaines figuraient sur des versions antérieures du présent site.

La règle qui sous-tend le tableau : une affirmation est publiable si une personne nommée peut pointer une pièce justificative datée qui l’appuie, et elle ne l’est pas autrement. Ce que cela nous laisse dire aujourd’hui se trouve dans ce que nous avons construit ; les preuves fournisseur pour un approvisionnement en cours sont transmises par écrit sur demande.

1. Rédigez le besoin sous forme de contrôles plutôt que d’étiquette. « Doit être souverain » est inévaluable et laisse gagner l’affirmation marketing la plus forte. Une réponse documentée à chacune des huit dimensions, avec une partie responsable nommée, est évaluable et défendable.
2. Mettez la matrice des responsabilités partagées dans le contrat lui-même, et non dans une diapositive en annexe. Lorsqu’un contrôle relève du fournisseur, son engagement devrait se rattacher à un document daté que vous pouvez produire lors d’une vérification.
3. Chiffrez et planifiez la sortie dès la signature : format, échéancier, attestation de suppression et coût. Négociés au moment du départ, ces quatre éléments sont fixés par la partie que vous quittez.

Le dossier de preuves du fournisseur contient notre statut d’entité, notre actionnariat et notre posture de sécurité. Il contient aussi notre position en matière de langues officielles et nos formes normalisées d’énoncé des travaux. Nous le transmettons à une autorité contractante sur demande, de sorte qu’un entrepreneur principal ou une autorité contractante peut nous évaluer sans appel de présentation.