Objet et portée du document. Ce document est un article de position architecturale qui avance la proposition que les architectures d’IA axées sur l’autorisation sont structurellement mieux positionnées pour satisfaire les exigences de gouvernance des environnements institutionnels réglementés que les architectures conventionnelles axées sur la génération. Il s’agit délibérément d’un argument, non d’une étude neutre. Il ne constitue pas un avis juridique, une évaluation de conformité formelle ou une certification réglementaire d’aucune sorte. Les établissements doivent consulter des juristes qualifiés pour les déterminations formelles de conformité. Les scores d’alignement numériques sont des évaluations architecturales fondées sur le jugement d’experts, non des mesures produites par un instrument de notation validé. Lorsque le document indique que COMPAiSS est « conçu pour soutenir » ou « architecturé pour faciliter » un principe réglementaire, cela reflète une évaluation architecturale; le contexte de déploiement, la gouvernance institutionnelle et la détermination réglementaire régissent la conformité effective.
Thèse centrale - une méthodologie d’évaluation différente
L’évaluation conventionnelle de l’IA et l’évaluation de COMPAiSS ne répondent pas à la même question.
Évaluation conventionnelle de l’IA
« La réponse est-elle exacte? »
Le succès se définit par la correction factuelle. La source de l’information est secondaire par rapport à son exactitude. Une hallucination bien évaluée est considérée comme un meilleur résultat qu’une réponse correcte sans attribution de source.
Évaluation COMPAiSS
« La réponse a-t-elle été produite exclusivement à partir de sources institutionnelles autorisées - et est-elle exacte par rapport à ces sources? »
Le succès exige d’abord l’autorisation, puis l’exactitude au sein du corpus autorisé. Une réponse factuellement correcte tirée d’une source non autorisée constitue une défaillance de gouvernance, indépendamment de son exactitude.
Cette distinction n’est pas une différence de fonctionnalité. C’est une différence méthodologique. Les systèmes d’IA conventionnels optimisent pour la première question. COMPAiSS est architecturé autour de la seconde. Pour les institutions publiques réglementées - services gouvernementaux, universités, hôpitaux, organismes de réglementation professionnelle - la seconde question est celle qui compte. Une vérité non autorisée comporte le même risque de gouvernance qu’une hallucination, car l’établissement ne peut pas être tenu responsable d’informations qu’il n’a pas autorisées.
Cette différence explique pourquoi la comparaison d’alignement réglementaire qui suit favorise systématiquement une architecture axée sur l’autorisation. La Loi européenne sur l’IA, la Directive du Conseil du Trésor canadien, la LPRPDE et la Loi 25 du Québec ont toutes été élaborées en réponse aux défaillances de gouvernance des systèmes de génération en premier. Leurs exigences en matière de traçabilité, de transparence, de responsabilisation et de supervision humaine s’appliquent directement et naturellement à une architecture qui impose l’autorisation avant la génération.
Métriques traditionnelles d’évaluation de l’IA
Les cadres conventionnels d’évaluation de l’IA privilégient des métriques de performance applicables aux cas d’utilisation généraux :
- Exactitude factuelle
- Précision et rappel de la récupération
- Latence des réponses
- Robustesse aux entrées adversariales
- Taux d’hallucination
- Satisfaction des utilisateurs
- Fidélité au contexte
Ces métriques sont nécessaires et bien établies. Ce document ne propose pas de les remplacer.
Dimensions supplémentaires proposées pour l’IA institutionnelle
Ce document propose que les systèmes d’IA opérant dans des environnements institutionnels réglementés requièrent des dimensions d’évaluation supplémentaires axées sur la gouvernance :
- Fidélité à l’autorisation - le degré auquel un système reste dans les limites du savoir autorisé par l’établissement
- Taux de préservation de la gouvernance - la proportion de réponses qui évitent les affirmations institutionnelles non autorisées
- Fidélité aux preuves - le degré auquel chaque affirmation peut être tracée jusqu’à une source analysée spécifique
- Traçabilité d’audit - l’exhaustivité et le déterminisme du dossier de gouvernance par réponse
- Responsabilité institutionnelle - le degré auquel l’autorité humaine gouverne la portée du système avant l’inférence
- Taux de refus sécurisé - la proportion de requêtes hors portée qui produisent des refus appropriés plutôt que des réponses non autorisées
Modèle conceptuel
L’inversion architecturale : gouvernance avant ou après la génération
La distinction architecturale centrale illustrée sous forme de modèle de processus. La gouvernance passe de l’après-génération à l’avant-génération, changeant non seulement le moment où les contrôles sont appliqués, mais aussi le type de contrôles structurellement possibles.
Architecture de génération en premier (RAG conventionnel)
1 Question reçue
↓
2 Intégration de la requête et récupération
↓
3 Classement et reclassement des candidats
↓
4 Assemblage du contexte
↓
5 Génération - l’inférence du modèle s’exécute
↓
6 Réponse livrée à l’utilisateur
↓
7 Examen de gouvernance, surveillance, journalisation
Architecture axée sur l’autorisation (COMPAiSS)
1 Question reçue
↓
PORTAIL Vérification d’autorisation contre la liste verte
↓
PORTAIL Validation des sources - les preuves existent-elles?
↓
4 Analyse en direct des sources autorisées
↓
5 Génération - uniquement si les portails sont valides
↓
REÇU Reçu de conformité généré en temps réel
↓
7 Réponse livrée avec piste d’audit
Dans le modèle de génération en premier, la gouvernance est appliquée aux sorties que le modèle a déjà produites. Dans le modèle axé sur l’autorisation, la gouvernance détermine si le modèle est autorisé à produire une sortie. Cette distinction n’est pas une question de degré - c’est une différence dans la position structurelle du contrôle de gouvernance par rapport à l’étape d’inférence. Toutes les propriétés en aval des deux architectures - traçabilité, responsabilisation, exhaustivité de la piste d’audit, robustesse adversariale, défensibilité en matière d’approvisionnement - découlent de cette unique différence architecturale.
Cadre proposé
Un cadre d’évaluation élargi pour l’IA institutionnelle axée sur l’autorisation
Ce cadre ne remplace pas l’évaluation traditionnelle de l’IA. Il propose des dimensions supplémentaires axées sur la gouvernance, appropriées aux systèmes d’IA opérant dans des environnements institutionnels réglementés.
Les cadres d’évaluation traditionnels de l’IA ont été développés pour des systèmes d’IA généralistes opérant dans de vastes domaines. Ils optimisent l’exactitude, l’efficacité et la satisfaction des utilisateurs. Cependant, ils n’ont pas été conçus pour une catégorie de systèmes d’IA dont l’obligation principale est de garantir que chaque réponse fournie s’inscrit dans les limites de gouvernance d’un établissement réglementé spécifique.
Ensemble de dimensions A - Performance traditionnelle
Conservé de l’évaluation conventionnelle de l’IA
Exactitude factuelle dans la portée autorisée. Précision de la récupération pour les sources autorisées. Latence et débit des réponses. Robustesse aux entrées adversariales. Compréhension et satisfaction des utilisateurs. Exactitude et cohérence multilingues. Ces dimensions restent essentielles et doivent être évaluées conjointement avec les dimensions de gouvernance ci-dessous.
Ensemble de dimensions B - Performance de gouvernance
Proposé pour les systèmes axés sur l’autorisation
Fidélité à l’autorisation selon les types de requêtes. Taux de préservation de la gouvernance sous test adversarial. Fidélité aux preuves - traçabilité affirmation-source. Exhaustivité et déterminisme de la piste d’audit. Taux de refus sécurisé pour les requêtes hors portée. Profondeur d’intégration de la supervision humaine. Exhaustivité de la documentation pour l’approvisionnement.
La proposition méthodologique clé est que pour l’IA institutionnelle réglementée, un système obtenant des scores élevés sur l’ensemble de dimensions A mais de faibles scores sur l’ensemble B n’est pas un système performant - c’est un système performant avec un profil de gouvernance inacceptable. Inversement, un système obtenant des scores élevés sur les deux ensembles est génuinement adapté au déploiement institutionnel réglementé.
Paysage réglementaire - juin 2026
Ce que les cadres exigent réellement
L’état actuel des deux cadres avant d’effectuer des comparaisons architecturales.
Union européenne
Loi européenne sur l’IA (Règlement 2024/1689)
Entrée en vigueur en août 2024. Pratiques interdites en application depuis février 2025. Exigences de transparence des GPAI en vigueur depuis août 2025. Exigences complètes pour les systèmes à haut risque applicables en août 2026. Pénalités jusqu’à 35 millions d’euros ou 7 % du chiffre d’affaires mondial. L’éducation, l’emploi, les services essentiels et l’IA du secteur public sont classés dans les catégories à haut risque de l’Annexe III, avec des évaluations obligatoires de conformité, une documentation technique, une supervision humaine, une traçabilité et un enregistrement dans la base de données européenne de l’IA.
Canada
Cadre fédéral de gouvernance de l’IA (2026)
La Loi sur l’intelligence artificielle et les données (LIAD, projet de loi C-27) est morte au Parlement en janvier 2025 et n’a pas été réintroduite. Les instruments contraignants en 2026 sont la Directive du Conseil du Trésor sur la prise de décision automatisée (en vigueur depuis 2019 pour les institutions fédérales), la LPRPDE, la Loi 25 du Québec (l’exigence provinciale la plus rigoureuse, incluant le droit à la révision humaine des décisions automatisées), les lignes directrices du BSIF pour les institutions financières, et le protocole d’entente Canada-UE sur l’IA signé en décembre 2025.
Pourquoi l’absence de la LIAD renforce l’argumentation
L’échec de la LIAD ne crée pas un vide réglementaire. Il crée un patchwork de conformité qui est en pratique plus exigeant qu’une loi unique, car les établissements doivent satisfaire simultanément de multiples instruments qui se chevauchent : droit fédéral à la vie privée, régimes provinciaux de confidentialité, directives du Conseil du Trésor, lignes directrices sectorielles et normes d’approvisionnement. Une architecture conçue pour faciliter la conformité aux principes sous-jacents de traçabilité, d’autorisation et de supervision humaine est bien positionnée pour satisfaire l’ensemble de ces instruments simultanément.
Partie 1 - Loi européenne sur l’IA
COMPAiSS vs. mises en oeuvre RAG conventionnelles : principes européens
Huit obligations fondamentales. La comparaison porte sur les mises en oeuvre RAG conventionnelles typiques. Les déploiements RAG d’entreprise sophistiqués peuvent réduire certains écarts par des contrôles de gouvernance supplémentaires, mais pas par équivalence architecturale.
COMPAiSS
Le portail d’exécution de COMPAiSS est conçu pour limiter structurellement les sorties aux sources institutionnelles autorisées, ce qui semble susceptible de réduire le profil de risque du système lors des évaluations d’impact. Dans une évaluation d’impact algorithmique réalisée pour un déploiement à Service Canada, le système a été évalué au niveau d’impact 1 - le niveau le plus bas - reflétant que son architecture fournit des informations dans une portée définie et autorisée plutôt que de prendre des décisions autonomes.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles pour les contextes institutionnels relèvent généralement des catégories à haut risque de la Loi européenne sur l’IA en vertu de l’Annexe III. Chaque étape du pipeline introduit une incertitude probabiliste difficile à circonscrire à l’avance. Des contrôles de gouvernance supplémentaires sont généralement nécessaires pour atteindre des limites de risque comparables.
COMPAiSS
COMPAiSS est conçu pour soutenir la transparence au niveau architectural : chaque réponse est traçable jusqu’à une URL source spécifique, nommée, autorisée, qui a été réellement récupérée et analysée pour cette requête. Le reçu de conformité généré par interaction documente la décision du portail, les sources récupérées, les pages analysées, les actifs injectés et l’utilisation des jetons, fournissant aux déployeurs un dossier opérationnel détaillé sans outillage supplémentaire.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles fournissent généralement des citations, mais l’étape de génération peut mélanger, résumer ou inférer à partir du contexte récupéré de façon à rendre l’origine spécifique des affirmations individuelles peu claire. Satisfaire aux exigences de transparence de l’article 13 nécessite généralement une infrastructure d’observabilité supplémentaire.
COMPAiSS
COMPAiSS est conçu pour intégrer la gouvernance humaine à deux points structurellement imposés. Premièrement, la liste verte est une liste d’autorisation gérée par des humains : les administrateurs des établissements contrôlent les sources autorisées, peuvent ajouter ou supprimer des URL et effectuent des audits réguliers. Deuxièmement, le portail d’exécution est un point de contrôle structurel qui reflète la portée institutionnelle définie par l’humain avant toute inférence. Les modifications requièrent une action humaine explicite.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles requièrent que la supervision humaine soit implémentée comme une couche de gouvernance supplémentaire : tableaux de bord de surveillance, files d’attente de révision, flux d’escalade ou contrôles de qualité post-génération. Il s’agit d’une supervision humaine comme mesure corrective plutôt que comme contrainte structurelle pré-inférence.
COMPAiSS
COMPAiSS est conçu pour générer un reçu de conformité pour chaque interaction dans le cadre du pipeline de réponse. Chaque reçu enregistre la décision du portail et la règle appliquée, les sources récupérées et leurs scores de pertinence, les pages réellement analysées, les actifs faisant autorité injectés, si l’inférence a été permise ou bloquée, et l’utilisation des jetons. C’est un artefact de gouvernance produit en temps réel, non un journal secondaire.
Mises en oeuvre RAG conventionnelles
Les déploiements RAG conventionnels peuvent être instrumentés pour produire des journaux, mais la journalisation n’est généralement pas architecturalement native au pipeline de génération. Lorsqu’une hallucination survient, l’analyse post-hoc des journaux ne peut souvent pas établir de façon définitive quel contenu récupéré a contribué à une affirmation générée spécifique, car l’étape de génération mélange le contexte de façon probabiliste.
COMPAiSS
L’architecture de COMPAiSS est conçue pour réduire certaines classes de risques adversariaux : la décision du portail étant basée sur une consultation déterministe de la liste verte plutôt que sur l’inférence du modèle, le langage adversarial dans la requête est moins susceptible de rediriger le système vers des sources non autorisées. Cependant, l’architecture n’élimine pas tous les risques de sécurité : les pipelines d’analyse peuvent être attaqués, les sources autorisées peuvent contenir du contenu compromis, les couches de traduction introduisent leurs propres vulnérabilités, et le comportement du grand modèle de langage dans la portée autorisée reste probabiliste.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles sont soumises à un éventail plus large de vulnérabilités adversariales : injection de prompts par les documents récupérés, jailbreaking, empoisonnement de la récupération et exploitation du modèle. La robustesse requiert des programmes de tests adversariaux dédiés, des modèles de garde-fous et des classificateurs de sécurité des prompts, chacun pouvant lui-même échouer ou être contourné.
COMPAiSS
L’architecture de COMPAiSS est conçue pour limiter le fardeau de la gouvernance des données pour les réponses institutionnelles : l’environnement épistémique fourni au modèle au moment de l’inférence se compose exclusivement de contenu provenant de sources institutionnelles autorisées par la liste verte et analysées en temps réel. Il n’existe pas de corpus de données opaque ou non auditable contribuant aux réponses institutionnelles au-delà de ce que l’établissement lui-même a autorisé.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles héritent des obligations de gouvernance des données tant du corpus d’entraînement du grand modèle de langage de base que du corpus de récupération sur lequel elles opèrent. La conformité à l’article 10 exige généralement un programme formel de gouvernance des données couvrant les deux corpus, avec une documentation séparée pour chacun.
COMPAiSS
L’architecture déterministe et délimitée de COMPAiSS rend la documentation technique plus accessible que pour les systèmes probabilistes. Le Cadre de validation de preuve de concept version 8 de COMPAiSS fournit une méthodologie d’évaluation formelle avec des métriques de performance structurées, une norme de fiabilité inter-évaluateurs (kappa de Cohen supérieur ou égal à 0,70) et une taxonomie typée des défaillances, directement mappables aux exigences de documentation de l’article 11.
Mises en oeuvre RAG conventionnelles
La production d’une documentation technique conforme à l’article 11 pour un déploiement RAG conventionnel est substantiellement plus complexe, car le comportement du système n’est pas entièrement déterministe et peut changer avec les mises à jour du modèle ou les modifications du corpus de récupération. Le fardeau de documentation est continu et non ponctuel.
COMPAiSS
L’architecture de COMPAiSS est conçue pour rendre les deux exigences plus accessibles. Le système de gestion de la qualité est substantiellement intégré à l’architecture : le cycle d’audit de la liste verte, la piste du reçu de conformité, la décision passe/échec du portail d’exécution et la taxonomie typée des défaillances (refus de type A, violations de gouvernance de type B, défauts de pipeline de type C) fournissent un cadre de qualité intégré avec des métriques mesurables et auditables.
Mises en oeuvre RAG conventionnelles
La construction d’un système de gestion de la qualité pour un déploiement RAG conventionnel requiert des contrôles de qualité à chaque étape du pipeline probabiliste : surveillance de la qualité de la récupération, notation de la fidélité de génération, révision des sorties, flux de reporting des incidents et surveillance continue des performances. Chaque élément exige un investissement organisationnel que l’architecture de COMPAiSS est conçue pour réduire.
Partie 2 - Cadre réglementaire canadien
COMPAiSS vs. mises en oeuvre RAG conventionnelles : principes canadiens
Sept principes tirés de la Directive du Conseil du Trésor sur la prise de décision automatisée, de la LPRPDE, de la Loi 25 du Québec et du protocole d’entente Canada-UE sur l’IA (décembre 2025). Les déploiements RAG d’entreprise sophistiqués avec des couches de gouvernance supplémentaires peuvent combler certains de ces écarts; la comparaison reflète les mises en oeuvre typiques sans une telle supplémentation.
COMPAiSS
Une évaluation d’impact algorithmique réalisée pour un déploiement à Service Canada a évalué la mise en oeuvre de COMPAiSS au niveau d’impact 1 - le niveau le plus bas - parce que l’architecture fournit des informations plutôt que de prendre des décisions administratives, et que le portail d’exécution est conçu pour empêcher les sorties au-delà de la portée institutionnelle autorisée. L’achèvement de l’ÉIA constitue un historique d’approvisionnement documenté avec une institution fédérale.
Mises en oeuvre RAG conventionnelles
Un déploiement RAG conventionnel pour des services gouvernementaux destinés au public est plus susceptible d’attirer un niveau d’impact plus élevé en vertu de la Directive du Conseil du Trésor, notamment lorsque les informations fournies affectent la compréhension par les citoyens de leurs prestations, de leur admissibilité ou de leurs obligations. Les mises en oeuvre RAG d’entreprise sophistiquées avec restrictions de sources peuvent réduire cet écart, mais ne peuvent généralement pas atteindre le même profil de risque délimité qu’une architecture axée sur l’autorisation.
COMPAiSS
COMPAiSS est conçu pour soutenir la transparence de façon structurelle : les utilisateurs reçoivent des réponses provenant d’URL institutionnelles nommées et accessibles au public, avec la possibilité de vérifier toute affirmation à sa source. Lorsque le système ne peut pas répondre - parce qu’aucune source autorisée n’appuie la requête - il le communique explicitement et redirige vers les ressources institutionnelles plutôt que de générer une réponse plausible mais non étayée.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles citent des sources, mais la relation entre une source citée et une affirmation générée spécifique est souvent difficile à établir à des fins d’explication. Pour les exigences du droit à l’explication de la Loi 25 et les obligations de transparence de la LPRPDE, cette provenance mélangée est difficile à satisfaire sans outillage supplémentaire.
COMPAiSS
La structure de gouvernance de la liste verte de COMPAiSS est conçue pour rendre cette exigence native : les administrateurs des établissements contrôlent activement ce à quoi le système peut répondre, peuvent supprimer ou mettre à jour les sources autorisées en temps réel et effectuent des audits réguliers. L’autorité humaine sur la portée institutionnelle est une condition préalable à l’inférence, non une intervention post-génération.
Mises en oeuvre RAG conventionnelles
L’intervention humaine significative dans les déploiements RAG conventionnels pour les services publics réglementés requiert généralement des files d’attente de révision, des mécanismes d’escalade et une surveillance continue des sorties. Il s’agit d’une intervention humaine comme filet de sécurité réactif plutôt que comme contrainte structurelle pré-inférence. Les mises en oeuvre d’entreprise avec flux d’approbation peuvent partiellement combler cet écart.
COMPAiSS
L’architecture de liste verte de COMPAiSS est conçue pour fournir une atténuation structurelle des biais pour les cas d’utilisation institutionnels en contraignant les sorties aux sources institutionnelles autorisées. La capacité multilingue est gouvernée avant l’inférence : la traduction normalise la question avant l’autorisation, et la réponse autorisée est ensuite retraduite, conçue pour garantir que les utilisateurs dans différentes langues reçoivent le même contenu institutionnellement autorisé. Des tests de biais indépendants par langues et groupes démographiques renforcerait cette évaluation.
Mises en oeuvre RAG conventionnelles
Les mises en oeuvre RAG conventionnelles peuvent introduire des biais par de multiples canaux : biais du corpus d’entraînement du modèle de base, biais de classement de la récupération et biais de génération dans la façon dont les informations récupérées sont synthétisées. Dans les contextes multilingues, différentes langues peuvent récupérer différents documents ou générer des réponses avec des pondérations différentes, introduisant potentiellement des résultats différenciés selon les populations d’utilisateurs.
COMPAiSS
COMPAiSS est conçu pour générer un reçu de conformité par interaction traçant la décision du portail, les sources consultées, les pages analysées et le statut d’autorisation de l’inférence. Le protocole d’entente Canada-UE sur l’IA, signé en décembre 2025, engage le Canada à s’aligner sur les principes européens incluant la traçabilité tout au long du cycle de vie du modèle. Les auditeurs institutionnels peuvent retracer toute sortie générée jusqu’au contenu source spécifique analysé, ou confirmer qu’une requête a été appropriément refusée et pourquoi.
Mises en oeuvre RAG conventionnelles
La production de pistes d’audit satisfaisant à la fois la Directive du Conseil du Trésor et les principes de traçabilité européens du PE de décembre 2025 nécessite une infrastructure d’observabilité qui n’est pas standard dans les déploiements RAG typiques. Lorsqu’un audit exige d’établir quel contenu récupéré a produit quelle affirmation spécifique, l’étape de génération probabiliste signifie que ce traçage est souvent approximatif plutôt que définitif.
COMPAiSS
COMPAiSS est conçu pour traiter les requêtes des utilisateurs par rapport à une liste verte définie, contrôlée par l’établissement, sans créer de profils d’utilisateurs, conserver des données personnelles pour l’entraînement du modèle ou transmettre des informations à des réservoirs de données externes. La liste verte contient uniquement des URL institutionnelles autorisées publiquement, non des renseignements personnels. La minimisation des données de l’architecture est structurelle. Le contexte de déploiement et la mise en oeuvre spécifique peuvent affecter ces propriétés et doivent être confirmés pour chaque déploiement institutionnel.
Mises en oeuvre RAG conventionnelles
Les déploiements RAG conventionnels dans les contextes du secteur public ou institutionnel doivent gérer soigneusement les données de requête, l’historique des conversations, le contexte utilisateur et les journaux de récupération en vertu de la LPRPDE et de la Loi 25. Les plateformes RAG d’entreprise peuvent maintenir un historique des conversations, utiliser les requêtes pour améliorer les systèmes de récupération ou partager des données de télémétrie avec les fournisseurs de modèles, chacun déclenchant des obligations en matière de confidentialité. Les exigences de résidentialité des données en vertu de la Loi 25 imposent des contraintes supplémentaires sur le lieu de traitement des données.
COMPAiSS
COMPAiSS fournit une réponse architecturalement défensible à cette exigence : le portail d’exécution est un mécanisme documenté et testable conçu pour empêcher l’inférence non autorisée. Le reçu de conformité fournit une piste d’audit par interaction directement compatible avec les exigences de documentation du Conseil du Trésor. L’achèvement d’une évaluation d’impact algorithmique pour un déploiement à Service Canada démontre que le parcours formel d’évaluation fédérale de l’approvisionnement a été complété avec succès. Il s’agit d’un historique d’approvisionnement institutionnel vérifié plutôt que d’une affirmation théorique de conformité.
Mises en oeuvre RAG conventionnelles
Les fournisseurs RAG conventionnels ne peuvent généralement pas démontrer la prévention structurelle des sorties non autorisées lors de l’approvisionnement. La réponse à la question « comment le système empêche-t-il structurellement les réponses non autorisées? » ne peut pas être structurelle pour une architecture de génération en premier, car la génération elle-même est la première étape. La réponse doit être « nous gérons les réponses non autorisées après leur production ». Cette vulnérabilité d’approvisionnement devient un passif croissant à mesure que les exigences d’approvisionnement se renforcent autour de la gouvernance de l’IA.
Sommaire
Scores d’alignement illustratifs : tous les principes
Méthodologie de notation et limites
Il s’agit d’évaluations d’alignement architectural illustratives, et non de scores réglementaires officiels, de certifications de conformité ou de déterminations juridiques. Aucune grille de notation numérique officielle n’existe. Les scores reflètent l’évaluation des auteurs quant à la façon dont chaque architecture est conçue pour soutenir chaque principe réglementaire. Ces évaluations sont fondées sur des textes réglementaires publiés, de la documentation architecturale et une revue inter-modèles par GPT-4, Gemini et Copilot. Les établissements doivent consulter des juristes qualifiés pour les déterminations formelles de conformité. La comparaison porte sur des mises en oeuvre RAG conventionnelles typiques; les déploiements RAG d’entreprise sophistiqués avec contrôles déterministes des sources, suivi de provenance et infrastructure d’observabilité peuvent combler certains écarts par des couches de gouvernance supplémentaires.
| # |
Principe |
Cadre |
COMPAiSS |
RAG conventionnel |
Écart |
| UE-01 | Classification des risques et évaluation d’impact | Loi IA arts. 9, 27 | 9,0 | 4,0 | +5,0 |
| UE-02 | Transparence et information aux déployeurs | Loi IA art. 13 | 9,0 | 4,0 | +5,0 |
| UE-03 | Supervision humaine | Loi IA art. 14 | 9,5 | 5,0 | +4,5 |
| UE-04 | Conservation des enregistrements et journaux | Loi IA arts. 12, 18, 19 | 9,5 | 3,5 | +6,0 |
| UE-05 | Exactitude, robustesse et cybersécurité | Loi IA art. 15 | 8,0 | 4,5 | +3,5 |
| UE-06 | Gouvernance des données | Loi IA art. 10 | 8,5 | 4,0 | +4,5 |
| UE-07 | Documentation technique | Loi IA art. 11 | 9,0 | 4,0 | +5,0 |
| UE-08 | Responsabilité et gestion de la qualité | Loi IA arts. 17, 27 | 9,0 | 4,0 | +5,0 |
| CAN-01 | Évaluation d’impact algorithmique et classification | Directive Conseil du Trésor | 9,0 | 4,5 | +4,5 |
| CAN-02 | Transparence et explicabilité | Conseil du Trésor ; LPRPDE ; Loi 25 | 9,0 | 4,0 | +5,0 |
| CAN-03 | Intervention humaine significative | Conseil du Trésor ; Loi 25 art. 12 | 9,5 | 4,5 | +5,0 |
| CAN-04 | Atténuation des biais et équité d’accès | Conseil du Trésor ; Droits de la personne | 8,0 | 4,5 | +3,5 |
| CAN-05 | Auditabilité et responsabilisation | Conseil du Trésor ; LPRPDE ; PE Canada-UE | 9,5 | 3,5 | +6,0 |
| CAN-06 | Protection de la vie privée et minimisation | LPRPDE ; Loi 25 du Québec | 8,5 | 5,0 | +3,5 |
| CAN-07 | Défensibilité de l’approvisionnement | Approv. fédéral ; Conseil du Trésor | 9,5 | 3,5 | +6,0 |
| Alignement architectural illustratif global (15 principes, moyenne) | 8,9 / 10 | 4,2 / 10 | +4,7 |
Implications de coût
Le coût de conformité de l’architecture de génération en premier
La différence de coût structurelle entre atteindre l’alignement réglementaire par l’architecture et l’atteindre par des contrôles de gouvernance supplémentaires.
Les évaluations d’alignement ci-dessus révèlent une asymétrie de coûts structurelle avec des implications directes pour l’approvisionnement. L’alignement de COMPAiSS sur ces principes est une conséquence de son architecture. Un déploiement RAG conventionnel visant à atteindre un alignement comparable doit investir dans des systèmes supplémentaires à chaque point d’écart - et chacun de ces investissements se répète.
RAG conventionnel : supplémentation de conformité requise
Infrastructure d’observabilité et de journalisation d’auditCouche supplémentaire
Flux de supervision humaine et dotationCoût récurrent
Modèles de garde-fous et modération du contenuCouche supplémentaire
Programmes de tests adversariauxCoût récurrent
Maintenance de la documentation techniqueCoût récurrent
Tests de biais par langues et groupesCoût récurrent
Architecture de confidentialité et résidentialité des donnéesCouche supplémentaire
Coût annuel illustratif (100 000 requêtes)90 000 $ - 200 000 $
COMPAiSS : conformité par architecture
Journaux d’auditIntégré
Supervision humaineListe verte (intégrée)
Contrainte de sortiePortail d’exécution (intégré)
Contrôle adversarial de la portéeStructurel (intégré)
Documentation techniqueDéterministe (tractable)
Équité multilinguePré-inférence (intégrée)
Minimisation des donnéesArchitectural (intégré)
Coût annuel illustratif (100 000 requêtes)15 000 $ - 30 000 $
Les estimations de coût sont des scénarios de déploiement illustratifs basés sur des déploiements institutionnels typiques à environ 100 000 requêtes annuelles. Les chiffres pour le RAG conventionnel reflètent les coûts d’inférence, l’hébergement de bases de données vectorielles, les outils d’observabilité, la dotation en personnel de révision humaine et les frais généraux du programme de conformité. Les chiffres COMPAiSS reflètent les coûts d’inférence pour les requêtes autorisées uniquement (environ 60 % du total), la maintenance de la liste verte et le stockage des reçus de conformité. Les coûts réels varient considérablement selon la taille de l’établissement, le volume de requêtes, l’environnement d’hébergement et les exigences de gouvernance. Ces chiffres doivent être traités comme des indicateurs directionnels, non comme des estimations prêts pour l’approvisionnement.
Conclusion
Thèmes transversaux de l’analyse comparative
Cinq observations structurelles qui émergent systématiquement dans les cadres réglementaires européen et canadien.
L’autorisation avant l’exactitude
Les cadres réglementaires pour les institutions publiques ne visent pas principalement à déterminer si les réponses de l’IA sont correctes. Ils visent à déterminer si elles sont autorisées. Une réponse factuellement correcte tirée d’une source non autorisée constitue une défaillance de gouvernance. Il s’agit de la distinction méthodologique centrale entre l’évaluation conventionnelle de l’IA et le cadre d’évaluation approprié pour l’IA institutionnelle réglementée.
Déterminisme et probabilité
Les deux cadres réglementaires exigent la traçabilité, la responsabilisation et un comportement prévisible. Une architecture à portail d’exécution est conçue pour satisfaire ces exigences de façon structurelle. Une architecture probabiliste de génération en premier y répond par des contrôles supplémentaires. Les régulateurs font de plus en plus la distinction entre ces deux approches dans les contextes institutionnels à haut risque.
Gouvernance avant et après la génération
Chaque principe réglementaire majeur peut être abordé avant l’inférence ou après la génération. Les cadres réglementaires n’exigent pas explicitement la gouvernance pré-inférence, mais ils semblent avantager les architectures qui la fournissent de façon structurelle plutôt que réactive, car les contrôles structurels sont plus traçables et moins dépendants du bon fonctionnement des systèmes secondaires.
L’inversion de l’approvisionnement
À mesure que les exigences réglementaires se renforcent, la charge de la preuve dans l’approvisionnement passe de « prouvez que ce système est sûr » vers « démontrez comment les réponses non autorisées sont structurellement empêchées ». Il s’agit d’une question à laquelle une architecture de génération en premier ne peut pas pleinement répondre, car la génération elle-même précède toute contrainte structurelle.
La taxe de conformité
Les déploiements RAG conventionnels dans les contextes institutionnels réglementés comportent une taxe de conformité : le coût récurrent de l’infrastructure de gouvernance requise pour satisfaire des exigences réglementaires qu’une architecture axée sur l’autorisation est conçue pour satisfaire structurellement. Cette taxe se manifeste par des coûts d’infrastructure, de dotation, de surveillance et de frais généraux organisationnels.
La conclusion architecturale
La Loi européenne sur l’IA et le cadre canadien ont tous deux été élaborés en réponse aux défaillances de gouvernance observées dans les déploiements d’IA de génération en premier dans des contextes réglementés. Leurs exigences fondamentales - traçabilité, supervision humaine, transparence, conservation des enregistrements, responsabilisation, gouvernance des données, défensibilité de l’approvisionnement - s’appliquent plus naturellement à une architecture où l’autorisation précède la génération qu’à une architecture où la gouvernance est appliquée après coup.
Cette analyse avance la proposition que cet alignement n’est pas fortuit. Une architecture conçue autour de la question « Cette réponse a-t-elle été produite exclusivement à partir de sources institutionnelles autorisées? » est structurellement mieux positionnée pour satisfaire les cadres réglementaires qui posent la même question.
Limites et validation future
Ce que ce document affirme - et ce qu’il n’affirme pas
Les articles de position savants distinguent la portée et les limites. Cette section aborde les deux explicitement.
Ce document avance une hypothèse architecturale testable : que les architectures d’IA axées sur l’autorisation sont structurellement mieux positionnées pour satisfaire les exigences de gouvernance des environnements institutionnels réglementés que les architectures conventionnelles de génération en premier. Il soutient cette hypothèse par une analyse architecturale, une cartographie des textes réglementaires et une évaluation d’alignement illustrative. Il ne la prouve pas par une mesure empirique indépendante.
Évaluation architecturale, non avis juridique
Ce document évalue comment une architecture est conçue pour soutenir des principes réglementaires. Il ne constitue pas un avis juridique, une certification de conformité ou une détermination réglementaire. La conformité effective est déterminée par les régulateurs évaluant les organisations, les systèmes de gouvernance, les processus et les contextes de déploiement.
Les scores d’alignement sont illustratifs
Les scores d’alignement numériques sont des jugements d’experts basés sur une analyse architecturale, non des mesures produites par un instrument de notation validé. Aucune grille de notation réglementaire officielle n’existe. Ces scores doivent être compris comme des évaluations raisonnées, non des mesures objectives.
La comparaison RAG porte sur les mises en oeuvre typiques
Les mises en oeuvre RAG d’entreprise sophistiquées avec contrôles déterministes des sources, suivi de provenance, piles d’observabilité complètes et flux de révision humaine peuvent réduire certains écarts de gouvernance par des contrôles supplémentaires. La comparaison ne représente pas un plafond de ce que les architectures RAG peuvent atteindre avec un investissement supplémentaire significatif.
Les estimations de coût sont des scénarios illustratifs
Les chiffres de coût de déploiement sont des scénarios illustratifs basés sur des déploiements institutionnels typiques. Ils ne sont pas des rapports de coût audités. Les coûts réels varient considérablement selon la taille de l’établissement, le volume de requêtes, l’environnement d’hébergement et les exigences de gouvernance.
Les affirmations de sécurité sont directionnelles
Le document décrit comment l’architecture de COMPAiSS est conçue pour réduire certaines surfaces d’attaque adversariales. Il n’affirme pas éliminer tous les risques de sécurité. Les pipelines d’analyse peuvent être attaqués, les sources autorisées peuvent contenir du contenu compromis, et le comportement du grand modèle de langage dans la portée autorisée reste probabiliste.
Une validation indépendante est nécessaire
Le construit de fidélité à l’autorisation, le taux de préservation de la gouvernance et le cadre d’évaluation élargi proposés ici sont préliminaires. Ils n’ont pas encore été validés indépendamment, normalisés ou soumis à une évaluation par les pairs au-delà du processus de revue inter-modèles décrit dans ce document.
L’hypothèse testable
L’affirmation centrale de ce document peut être énoncée comme une hypothèse testable : Les systèmes d’IA dont l’architecture impose l’autorisation comme condition préalable à la génération démontreront, dans des contextes de déploiement institutionnel réglementés, des taux de préservation de la gouvernance mesurables plus élevés, des pistes d’audit plus complètes et des coûts de supplémentation de conformité plus faibles que les systèmes dont l’architecture génère en premier et applique des contrôles de gouvernance après coup. Cette hypothèse est empiriquement réfutable. Les auteurs invitent les chercheurs indépendants, les régulateurs et les responsables des achats à la tester.
Programme de recherche future
Questions pour le domaine
Ce document propose un cadre. Il ne le complète pas. Les questions suivantes identifient les domaines où l’investigation empirique, la validation indépendante et la collaboration à l’échelle du domaine sont nécessaires.
- 01Comment la fidélité à l’autorisation devrait-elle être mesurée? Le construit proposé ici nécessite un instrument de mesure validé. Quels types de requêtes, conditions adversariales et contextes institutionnels sont nécessaires pour produire un score de fidélité à l’autorisation fiable?
- 02La notation de l’alignement architectural peut-elle être normalisée? Les scores illustratifs de ce document sont des jugements d’experts. Est-il possible de développer un instrument de notation reproductible et méthodologiquement rigoureux qui pourrait être appliqué de façon cohérente par des évaluateurs indépendants à travers les systèmes d’IA et les cadres réglementaires?
- 03Comment les systèmes axés sur l’autorisation se comparent-ils aux RAG d’entreprise avancés sous des référentiels communs? Une comparaison rigoureuse face à des déploiements RAG d’entreprise sophistiqués avec supplémentation complète de gouvernance renforcerait ou remettrait en question substantiellement l’hypothèse architecturale.
- 04Quelles méthodologies de test indépendantes sont appropriées pour l’évaluation de l’IA axée sur la gouvernance? Les référentiels conventionnels de l’IA ne sont pas conçus pour évaluer la fidélité à l’autorisation ou la préservation de la gouvernance. Quels protocoles d’évaluation et régimes de tests adversariaux sont appropriés pour évaluer les métriques de l’ensemble B dans des déploiements institutionnels en production?
- 05Les architectures à portail d’exécution peuvent-elles mesurablemente réduire le risque réglementaire en pratique? L’hypothèse architecturale prédit que les déploiements axés sur l’autorisation produiront moins de violations de gouvernance, des coûts de supplémentation de conformité plus faibles et des pistes d’audit plus complètes que les déploiements de génération en premier dans des contextes institutionnels comparables.
- 06Comment les cadres d’approvisionnement devraient-ils évaluer l’IA axée sur l’autorisation? Quelles modifications aux critères d’évaluation sont nécessaires pour évaluer adéquatement les architectures axées sur l’autorisation et pour empêcher les fournisseurs de génération en premier de revendiquer des propriétés de gouvernance équivalentes par des contrôles supplémentaires?
- 07Comment le cadre d’évaluation élargi devrait-il évoluer à mesure que les architectures d’IA se développent? À mesure que des architectures hybrides émergent, comment le cadre d’évaluation devrait-il s’adapter? Y a-t-il des propriétés axées sur l’autorisation qui peuvent être intégrées dans les déploiements RAG d’entreprise existants, et si oui, à quel coût de gouvernance?
Ces questions définissent un programme de recherche plutôt qu’une conclusion. La proposition que l’IA axée sur l’autorisation représente une catégorie architecturale distincte méritant sa propre méthodologie d’évaluation est offerte ici comme point de départ pour une conversation plus large à l’échelle du domaine.