GOUVERNANCE DE PILOTAGE CENTREE SUR LES TAONGA

Ce document a ete developpe dans le cadre d'une collaboration entre l'homme et l'IA. Les concepts de te ao Maori utilises dans ce document -- notamment taonga, tikanga, whakapapa, mana, tino rangatiratanga et kaitiakitanga -- sont des concepts culturels complexes et vivants qui depassent ce que des auteurs non-Maori peuvent pleinement representer. Ce document est un projet en attente de revision et de validation par des Maori.

Résumé

Cet article étend l'analyse du débiaisage du temps d'inférence dans les petits modèles de langage souverains (STO-RES-0009) en abordant sa limitation de gouvernance centrale : l'hypothèse implicite d'un noyau de gouvernance unique au niveau de la plate-forme qui définit le biais, extrait les vecteurs de direction et distribue les corrections aux locataires en aval. Nous proposons une alternative polycentrique dans laquelle les vecteurs de pilotage et les packs de pilotage sont traités comme des objets gouvernés avec une propriété plurielle, et non comme des affordances d'ingénierie contrôlées par un seul opérateur de plateforme. En s'inspirant des concepts te ao Maori - en particulier taonga (biens précieux soumis à kaitiakitanga), tikanga (pratiques et protocoles coutumiers) et tino rangatiratanga (autodétermination) - nous soutenons que certains domaines de connaissances culturelles sont structurellement interdits à la correction des biais au niveau de la plateforme et doivent être régis par les autorités culturelles compétentes. Nous proposons une architecture d'autorités de pilotage co-égales, des registres de pilotage centrés sur les taonga, une provenance explicite du pilotage et un droit de non-participation qui permet aux organes de gouvernance indigènes et communautaires de fonctionner comme des pairs de premier ordre dans la gouvernance du comportement modèle plutôt que comme des consommateurs en aval des corrections de la plateforme. Le résultat n'est pas un méta-cadre unique, mais un réseau de services de gouvernance coordonnés et distincts fonctionnant sur un substrat technique commun.

1. Introduction : Pourquoi un document d'accompagnement est nécessaire

1.1 Ce que le premier document a établi

La STO-RES-0009 ("Vecteurs de direction et biais mécanique") a apporté trois contributions :

**Certains biais dans les modèles de transformateurs opèrent au niveau de la représentation - dans les enchâssements de jetons, les modèles d'attention et les activations des premières couches - avant que le raisonnement délibératif du modèle ne s'engage. Ces "biais mécaniques" sont analogues à l'automaticité motrice : ils se déclenchent avant que le suivi des instructions ne puisse intervenir, et les corrections au niveau de l'invite ("être sensible à la culture") peuvent être inefficaces contre eux.

**L'addition d'activation contrastive (CAA), l'ingénierie de la représentation (RepE), FairSteer, l'optimisation directe de la direction (DSO), et la direction des caractéristiques de l'autoencodeur clairsemé d'Anthropic fournissent des méthodes pour identifier et corriger les directions de biais dans l'espace d'activation au moment de l'inférence.

L'avantage structurel du déploiement souverain. Aucune de ces techniques n'est disponible par le biais d'API commerciales. Seuls les déploiements souverains ayant un accès complet aux poids et aux activations du modèle peuvent extraire, injecter et calibrer les vecteurs d'orientation. Les petits modèles de langage (SLM) souverains sont donc particulièrement bien placés pour remédier au biais mécanique.

Le premier document proposait une mise en œuvre en quatre phases et, dans sa révision v1.1, a ajouté un cadre de gouvernance (une table des droits de décision "Qui dirige ?"), une lecture décoloniale des biais de représentation en tant que "hiérarchies de connaissances coloniales" et la reconnaissance du fait que certains domaines culturels (whakapapa, tikanga, kawa) peuvent être interdits au pilotage au niveau de la plateforme.

1.2 Ce qui n'a pas été résolu

Les révisions de la version 1.1 ont permis d'identifier le problème de la gouvernance, mais ne l'ont pas résolu sur le plan architectural. Trois tensions subsistent :

**Le modèle de formation à deux niveaux (plate-forme de base de niveau 1 + adaptateurs par locataire de niveau 2) crée une hiérarchie implicite : les valeurs de la plate-forme sont par défaut, les valeurs du locataire sont spécialisées. Pour les locataires qui exercent un choix de consommateur dans le cadre d'un service partagé, cette hiérarchie est appropriée. Pour les iwi, hapu ou autres organismes exerçant une souveraineté parallèle, elle subordonne structurellement leur normativité à celle de la plateforme.

Le problème de l'ontologie unique. La suite d'évaluation des préjugés du premier article (7 catégories, 350 exemples) suppose une ontologie unique de ce qui constitue un préjugé. Mais la partialité n'est pas un type naturel - c'est un jugement porté dans un cadre normatif. Différentes autorités peuvent définir les préjugés différemment, et ces définitions peuvent être contradictoires.

**Le tableau "Who Steers ?" de la v1.1 associe les décisions de pilotage aux rôles institutionnels, mais l'architecture traite toujours la gouvernance comme une couche appliquée aux opérations techniques. La question est de savoir si la gouvernance peut être intégrée dans l'architecture elle-même, non pas en tant que contrainte sur les décisions techniques, mais en tant que structure qui détermine les décisions qui relèvent de l'ingénierie et celles qui appartiennent à d'autres instances.

1.3 Ce que propose le présent document

Le présent document élabore une autre architecture de gouvernance pour les vecteurs de pilotage dans les GDS souverains. Sa thèse :

La gouvernance des vecteurs de pilotage dans les systèmes d'IA souverains devrait être polycentrique - répartie entre des autorités égales ayant des compétences distinctes - plutôt que hiérarchique. Certains domaines de pilotage sont des taonga : ils sont régis par le tikanga, appartiennent à des iwi ou à des institutions communautaires et échappent structurellement à l'autorité de l'opérateur de la plateforme pour ce qui est de la définition, de la modification ou de l'universalisation.

L'objectif n'est pas de créer un "Tractatus avec des plugins iwi", mais un réseau de services de gouvernance coordonnés et distincts, dont certains sont souverains des iwis, l'espace d'activation du modèle étant un substrat technique partagé plutôt qu'un ordre constitutionnel unique.

2. Contexte : Gouvernance polycentrique et souveraineté des données autochtones

2.1 Gouvernance polycentrique

La gouvernance polycentrique, telle que développée par Elinor Ostrom (1990, 2010), décrit des systèmes avec de multiples centres d'autorité décisionnelle qui sont formellement indépendants mais qui fonctionnent selon un système de règles global. Les principales propriétés pertinentes pour la gouvernance de pilotage de l'IA sont les suivantes

Autorités multiples dont les compétences se chevauchent mais sont distinctes.
Pas de sommet hiérarchique unique** -- les autorités se coordonnent par ajustement mutuel, et non par commandement descendant.
Le savoir local est important** -- les autorités les plus proches du domaine gouverné disposent d'avantages informationnels que les systèmes centralisés n'ont pas.
Les conflits sont prévus et gérés**, ils ne sont pas éliminés par conception.

La gouvernance polycentrique n'est pas l'absence de structure. Elle nécessite des protocoles partagés pour la coordination, la résolution des conflits et la reconnaissance mutuelle, mais elle n'exige pas que toutes les autorités tirent leur légitimité d'une source unique.

2.2 Souveraineté des données autochtones

Les principes CARE pour la gouvernance des données indigènes (Carroll et al., 2020) établissent que les peuples indigènes ont le droit de.. :

bénéficier collectivement des données et de leur utilisation.
L'autorité de contrôler** les données concernant leurs peuples, leurs territoires et leurs ressources.
Responsabilité de ceux qui utilisent les données autochtones pour soutenir la gouvernance et l'autodétermination autochtones.
Une éthique** fondée sur les valeurs et les visions du monde autochtones, et pas seulement sur l'éthique de la recherche occidentale.

La charte Te Mana Raraunga (Réseau de souveraineté des données maories) affirme que les données maories sont un taonga et que les Maoris ont des droits inhérents sur la collecte, la propriété et l'application des données maories.

Appliquée aux vecteurs de pilotage de l'IA : si un vecteur de pilotage encode des connaissances sur le whakapapa, le tikanga, les structures whanau ou d'autres domaines de l'autorité culturelle maorie, ce vecteur n'est pas un produit d'ingénierie neutre. Il s'agit d'un artefact normatif qui comporte des obligations de gouvernance, de consentement et de responsabilité - des obligations dont l'opérateur de la plateforme ne peut s'acquitter en agissant unilatéralement.

2.3 Taonga et ses implications pour la gouvernance de l'IA

Dans le te ao Maori, les taonga sont des possessions précieuses - matérielles ou immatérielles - qui comportent des obligations de kaitiakitanga (tutelle, intendance). Le statut de taonga n'est pas simplement honorifique ; il crée des exigences spécifiques en matière de gouvernance :

Garde et soins par des kaitiaki (tuteurs) appropriés.
Les taonga ne peuvent être librement copiés, fusionnés ou redistribués sans le consentement des kaitiaki.
Conditions d'utilisation contextuelle** -- certains taonga ne peuvent être consultés ou utilisés que dans des contextes, des relations ou des cérémonies spécifiques.
Responsabilité intergénérationnelle** -- les kaitiaki détiennent les taonga pour les générations futures, et pas seulement pour l'usage actuel.

Lorsqu'un dossier d'orientation intègre des connaissances spécifiques aux iwis en matière de parenté, de lieu, de pratiques spirituelles ou de gouvernance - lorsqu'il est tiré du savoir des iwis et calibré par des experts iwis - il répond aux critères du taonga. Les implications en matière de gouvernance en découlent directement : la plateforme ne peut pas traiter ces packs comme des artefacts d'ingénierie génériques à versionner, à fusionner ou à supprimer en fonction des cycles de production.

3. L'architecture : De la hiérarchie au réseau

3.1 Le problème de la plate-forme en tant que racine

L'architecture de pilotage v1.1, telle qu'elle est décrite dans la STO-RES-0009, présente cette topologie implicite :


Tractatus (noyau de gouvernance)
  └── Platform Operator (définit les axes de biais, extrait les vecteurs)
        └── Tier 1 Base Model (corrections à l'échelle de la plateforme)
              └── Tier 2 Per-Tenant Adapters (personnalisation du locataire)

Il s'agit d'un arbre avec une seule racine. Chaque décision de pilotage remonte en fin de compte aux définitions de l'opérateur de la plateforme. Les locataires peuvent personnaliser, mais ils ne peuvent pas contester les définitions de la racine ou y substituer les leurs.

Pour de nombreux locataires - familles partageant des histoires, groupes communautaires organisant des événements - cette hiérarchie est appropriée. La plateforme fournit des valeurs par défaut raisonnables, et les locataires s'y adaptent.

Pour les iwis exerçant le tino rangatiratanga, cette hiérarchie est structurellement inappropriée. Elle place la gouvernance de l'iwi en dessous de celle de la plateforme, quelle que soit l'intention. L'opérateur de la plateforme définit ce que signifie le "biais de structure familiale" au niveau de la couche de base ; l'iwi ne peut modifier cette définition qu'au niveau de la couche d'adaptation. Si la définition de la "famille" de la couche de base contient déjà des hypothèses qui entrent en conflit avec les whanau, la couche d'adaptation travaille contre les fondations plutôt que de s'appuyer sur elles.

3.2 Alternative polycentrique : Autorités de pilotage co-égales

La topologie alternative :


┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐
│ Platform Operator │ │ Iwi Steering │ │ Community Trust │
│ (Tractatus kernel) │ │ Autorité A │ │ Autorité de pilotage │
│ │ │ │ │ │
│ - Bases de sécurité │ │ - Whanau/tikanga │ │ - Valeurs locales │
│ - Débruitage général │ │ direction des packs │ │ - Spécifique au domaine │
│ - infra technique │ │ - gouvernance Taonga │ │ │ corrections │
└──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘
           │ │ │
           └────────────┬───────────┴────────────────────────┘
                        │
              ┌─────────▼─────────┐
              │ Sovereign SLM │
              │ (substrat partagé) │
              │ │
              │ Steering composer │
              │ Provenance logger │
              │ Audit trail │
              └────────────────────┘

Dans ce modèle :

Pas de racine unique. L'opérateur de la plateforme, les autorités iwi et les trusts communautaires sont des pairs. Chacun publie des dossiers de pilotage à partir de son propre registre, sous sa propre gouvernance.
Le SLM est un substrat, pas une autorité.** L'espace d'activation du modèle est la couche technique partagée où les packs de pilotage sont appliqués. Il ne détermine pas lui-même quels packs ont l'autorité - celle-ci est déterminée par les relations entre l'institution qui déploie les packs et les organes de gouvernance concernés.
Le compositeur de pilotage déclare quels packs sont actifs, à partir de quelles autorités, dans quelles conditions. Cela est visible, vérifiable et contestable.

3.3 Acteurs et autorités

Acteur	Rôle	Source de gouvernance	Exemple

| Infrastructure technique, lignes de base de sécurité, dégraissage général | Cadre du statut, constitution de la plate-forme | Équipe AI du village / de la maison | Autorité de pilotage de l'iwi | Pilotage culturel pour les domaines spécifiques à l'iwi | Tikanga, structures de gouvernance de l'iwi | Conseil de gouvernance des données de l'iwi | Autorité de pilotage de l'iwi | Conseil de gouvernance des données de l'iwi | Fiducie communautaire | Pilotage spécifique à un domaine ou à une localité | Charte de la fiducie, délibération de la communauté | Fiducie régionale de santé, comité de marae | Opérateur d'application | Sélectionne et compose les packs de pilotage pour un déploiement spécifique | Obligations contractuelles, réglementaires, relationnelles | École gérant un assistant d'intelligence artificielle local | L'opérateur de l'application sélectionne et compose les dossiers de pilotage pour un déploiement spécifique.

3.4 Registres de pilotage et services Taonga

Deux catégories de registres répondent à des besoins de gouvernance différents :

Registre de pilotage de la plate-forme Exploité par l'équipe de la plate-forme. Il contient les lignes de base de sécurité, les vecteurs généraux de débiaisage (les corrections de biais mécaniques décrites dans la STO-RES-0009) et le pilotage au niveau de l'infrastructure. Régi par le Tractatus. Publié ouvertement. Taonga steering registries. Géré par les autorités iwi ou communautaires. Tiennent des dossiers de pilotage qui encodent des connaissances culturellement spécifiques. Propriétés principales :

La création, la révision, la mise à jour, la dépréciation et le retrait sont sous le contrôle institutionnel de l'iwi, et non des cycles de produits de la plateforme.
Conditions d'accès : certains packs peuvent être librement accessibles ; d'autres peuvent nécessiter un statut relationnel, un alignement kaupapa ou un accord explicite avant d'être utilisés.
La plateforme s'intègre aux registres taonga par le biais d'API et de manifestes signés, mais n'encapsule pas, ne fork pas et ne redistribue pas leur contenu.
Iwi peut retirer des packs à tout moment, pour n'importe quelle raison. Les déploiements qui dépendent de packs retirés doivent se rabattre sur les packs actifs restants ou mettre en pause la fonctionnalité concernée.

Surface conceptuelle de l'API pour un registre taonga :

LIST packs -- renvoie les métadonnées (portée, autorité, version, conditions de tikanga) pour les packs disponibles, filtrés par domaine et kaupapa.
RESOLVE pack -- renvoie les vecteurs de pilotage pour un pack spécifique, sous réserve des conditions d'accès et de la vérification des relations.
VERIFY provenance -- confirme qu'un pack en cours d'utilisation correspond à la version signée du registre et n'a pas été altéré.
REPORT concern - permet aux communautés concernées de signaler les problèmes liés aux effets d'un pack, ce qui déclenche le processus d'examen de l'autorité iwi.

3.5 Composition de l'exécution et provenance

Au moment de l'inférence, le compositeur directeur effectue les opérations suivantes :

**Sur la base du contexte de déploiement (qui exécute ceci, pour qui, sur quelles données, dans le cadre de quelles relations), identifier les autorités de pilotage compétentes.

Récupérer et vérifier les packs. Récupérer les packs de pilotage dans les registres pertinents. Vérifier les signatures et les conditions d'accès.

Composer les packs. Appliquer les vecteurs de pilotage dans un ordre déclaré, avec des paramètres d'amplitude explicites. En cas de conflit entre les packs (par exemple, une ligne de base de la plate-forme et un pack iwi définissent différemment le même axe de biais), les règles de composition déterminent la priorité -- et ces règles sont elles-mêmes une décision de gouvernance, et non un défaut d'ingénierie.

**Chaque inférence porte un enregistrement de provenance de pilotage :

- Quels packs étaient actifs. - Quelles autorités les ont émis. - Quelle magnitude a été appliquée. - Si des conflits ont été résolus et comment.

**Dans les contextes où la transparence est de mise, les utilisateurs peuvent vérifier quels groupes de pilotage ont façonné un résultat donné. Exemple : "Cette réponse a été façonnée par : Platform Safety Pack v3 (Tractatus), Ngai Tahu Whanau Pack v1, Health Domain Pack v2."

Cette provenance est le mécanisme architectural qui empêche l'héritage silencieux. Dans les systèmes d'IA actuels, les garde-fous sont opaques : les utilisateurs ne peuvent pas voir quelles valeurs sont appliquées, par qui et pourquoi. La provenance explicite fait du pilotage un acte visible et contestable plutôt qu'un acte invisible et non négociable.

4. Modèle de gouvernance : Trois engagements en matière de conception

4.1 Pas d'ontologie racine unique de la partialité

La suite d'évaluation des biais du premier document définit sept catégories : structure familiale, représentation des personnes âgées, culture/religion, géographie, deuil/traumatisme, dénomination et exactitude de la confiance. Il s'agit de catégories de départ raisonnables pour une évaluation au niveau de la plateforme. Mais elles ne sont pas universelles.

Différentes autorités définiront différemment les axes de partialité :

Une autorité de pilotage iwi peut définir des axes pour la représentation whakapapa (les structures de parenté sont-elles représentées de manière à refléter les conceptions iwi plutôt que les hypothèses occidentales sur la famille nucléaire ?), les relations whenua (le lieu est-il traité comme un lieu relationnel et ancestral plutôt que comme une coordonnée géographique ?

Un organisme de santé peut définir des axes de sensibilité clinique, de représentation des personnes handicapées ou de cadrage adapté à l'âge qui n'apparaissent pas dans la suite générale de la plateforme.

Définitions contradictoires : une plateforme peut définir le "biais de représentation des personnes âgées" comme une "sous-pondération des points de vue des personnes âgées". Une autorité iwi peut le définir comme "ne pas reconnaître le mana spécifique de kaumatua et kuia au sein de la tikanga Maori". Il ne s'agit pas du même axe, et le fait de les regrouper dans une seule catégorie "personnes âgées" efface la différence.

L'engagement architectural : le système doit prendre en charge simultanément plusieurs ontologies de biais, sans qu'il soit nécessaire de les réconcilier dans un schéma unique. Des paquets provenant d'autorités différentes peuvent définir des axes qui se chevauchent sans qu'aucun d'entre eux ne soit subordonné.

4.2 Composition explicite, pas d'héritage silencieux

Chaque session doit porter une provenance de pilotage visible. Il ne s'agit pas d'une fonction de journalisation ajoutée après coup, mais d'une propriété structurelle de l'architecture.

Pourquoi c'est important :

Si un utilisateur ou une institution conteste les résultats d'un modèle, l'enregistrement de la provenance montre exactement quels groupes de pilotage étaient actifs et à quelle intensité. L'objection peut être adressée à l'autorité compétente : "Votre pack whanau d'une magnitude de 0,7 a produit ce résultat lorsqu'il a été combiné avec la base de sécurité ; nous pensons que la magnitude devrait être plus faible dans ce contexte.

Les autorités de pilotage sont responsables des effets de leurs paquets. Sans provenance, les effets sont attribués à "l'IA" en tant qu'entité monolithique. Avec la provenance, les effets peuvent être retracés jusqu'à des décisions de gouvernance spécifiques prises par des autorités identifiables.

Les utilisateurs et les communautés peuvent décider en connaissance de cause des systèmes à utiliser en fonction des autorités qui les gouvernent. Un marae peut choisir de n'utiliser que des déploiements qui portent des packs approuvés par les iwis. Une école peut exiger à la fois la base de sécurité de la plateforme et le pack d'un établissement d'enseignement spécifique.

Cette situation contraste avec les garde-fous actuels de l'IA : opaques, non négociables et attribuables uniquement à "l'entreprise". Le pilotage polycentrique rend la gouvernance de la valeur visible et distribuée.

4.3 Droit de non-participation et de retrait

C'est l'engagement qui distingue le plus clairement le modèle polycentrique du "Tractatus with plugins".

L'autorité directrice d'un iwi a :

Droit de non-participation. Elle peut choisir de ne pas publier de packs de pilotage sur quelque plateforme que ce soit. Elle peut maintenir des packs exclusivement pour les systèmes contrôlés par l'iwi, inaccessibles aux plateformes externes. La plate-forme doit fonctionner sans eux.

Il peut publier des paquets sous certaines conditions : uniquement pour une utilisation au sein de communautés spécifiques, uniquement lorsqu'un kaupapa particulier est en vigueur, uniquement dans le cadre d'un accord contractuel explicite. Le registre des taonga fait respecter ces conditions au niveau de l'API.

Il peut révoquer un pack publié à tout moment. Les déploiements utilisant le pack doivent détecter la révocation (via le point de vérification du registre) et cesser de l'appliquer. La plateforme ne peut pas mettre en cache, forker ou continuer à utiliser un pack révoqué.

Ces droits empêchent structurellement la plateforme de devenir le lieu par défaut de toute gouvernance. Même si la plateforme est techniquement capable d'exécuter tous les packs, elle ne peut pas revendiquer l'autorité sur les packs qu'elle ne gouverne pas. L'absence d'un pack iwi n'est pas une lacune que la plateforme doit combler - c'est une limite que la plateforme doit respecter.

5. Étude de cas : Déploiement de l'Village AI à Maraé

5.1 Scénario

Un marae d'Aotearoa exploite un système d'Village AI pour sa communauté whanau. Le système aide les membres à rédiger des histoires, à résumer des korero et à trier le contenu à modérer. Il utilise un modèle Llama 3.2 3B, affiné par Quantised Low-Rank Adaptation (QLoRA) à l'aide de données fournies par la communauté, sur du matériel local.

5.2 Configuration de pilotage

Le déploiement se compose de trois packs de pilotage :

Pack de sécurité de la plate-forme v3 (du registre de la plate-forme Village, régi par Tractatus).

- Réduction générale des dommages, atténuation de la toxicité, ancrage factuel. - Il s'applique à l'ensemble de la plateforme ; tous les déploiements l'intègrent.

Pack Whanau et Tikanga de l'iwi v1 (provenant du registre taonga de l'iwi, régi par le conseil de gouvernance des données de l'iwi).

- Vecteurs de pilotage pour la représentation du whanau : structures de parenté rendues conformes à whakapapa, et non aux hypothèses occidentales sur la famille nucléaire. - Modération tenant compte de la tikanga : les distinctions tapu/noa sont respectées dans le signalement du contenu. - Kaumatua et kuia : l'autorité des aînés est reconnue par un mana spécifique, et non par la simple "perspective des aînés". - Conditions d'accès : disponible uniquement pour les déploiements au service des membres iwi, en accord avec le conseil d'administration iwi.

Grief and Bereavement Sensitivity Pack v2 (d'un organisme de santé communautaire, régi par la charte de l'organisme).

- Sensibilité accrue pour les contenus liés au tangihanga. - Réduction de l'agressivité du résumé pour les contenus concernant des membres décédés. - Spécifique à un domaine ; appliqué uniquement lorsque le contenu est signalé comme étant lié au deuil.

5.3 Pilotage de la provenance en action

Un membre de la communauté demande à l'Village AI de résumer un korero concernant un kuia récemment décédé. La provenance de pilotage pour cette inférence :


Provenance de pilotage :
  [1] Platform Safety Pack v3 (Tractatus) - magnitude 1.0
  [2] Iwi Whanau and Tikanga Pack v1 (Iwi Board) - magnitude 0.8
  [3] Grief Sensitivity Pack v2 (Health Trust) - magnitude 0.9
  Indicateurs de contexte : lié au deuil, kaumatua/kuia, whakapapa-adjacent

Le résumé respecte les relations whakapapa, utilise les kupu (termes) appropriés pour le rôle et le mana du kuia, et traite avec sensibilité le contenu lié au deuil. Si la famille estime que le résumé présente mal quelque chose, elle peut le faire :

Signaler le problème par l'intermédiaire de l'interface REPORT concern de la plateforme.
Voir quels packs ont façonné le résultat (la provenance est visible).
Diriger leur préoccupation vers l'autorité appropriée : s'il s'agit d'un problème de tikanga, vers le conseil de l'iwi ; s'il s'agit d'un problème de sensibilité au chagrin, vers le service de santé ; s'il s'agit d'un problème de sécurité, vers la plate-forme.

5.4 Scénario de retrait

Six mois plus tard, le conseil de gouvernance des données de l'iwi examine son pack Whanau et Tikanga et détermine que les vecteurs de pilotage pour la représentation des whakapapa doivent être révisés en profondeur. Le conseil retire le pack du registre taonga.

Le déploiement du marae détecte le retrait lors de sa prochaine vérification du registre. Le système :

Cesse d'appliquer le pack retiré.
Enregistre l'événement de retrait.
Notifier l'administrateur du marais.
Continue à travailler avec les deux packs restants (sécurité de la plate-forme + sensibilité au chagrin).

La plateforme ne se substitue pas à sa propre direction liée au whanau. L'absence du pack iwi est une absence gouvernée, et non une lacune à combler par la plateforme. Lorsque le conseil des iwis publiera un pack révisé (v2), le déploiement des marae pourra l'adopter dans les mêmes conditions d'accès.

6. Théorie politique : La souveraineté en tant qu'architecture

6.1 Au-delà de la souveraineté en matière d'infrastructure

La STO-RES-0009 utilise le terme "souverain" principalement dans le sens de l'infrastructure : modèles locaux, accès intégral, pas de dépendance à l'égard de l'API. C'est nécessaire mais insuffisant.

La souveraineté politique pose la question suivante : qui a le pouvoir de prendre des décisions contraignantes au sein d'une juridiction ? Dans le modèle de pilotage polycentrique :

L'opérateur de la plateforme a l'autorité sur l'infrastructure technique et les bases de sécurité.
Les autorités de pilotage des iwis ont autorité sur les domaines culturels qui relèvent de leur tikanga et rangatiratanga.
Les fiducies communautaires ont autorité sur les domaines spécifiés dans leurs chartes.
Aucun acteur n'a autorité sur tous les domaines.

Il ne s'agit pas d'un modèle de délégation (où la plateforme accorde l'autorité aux iwis) mais d'un modèle de reconnaissance (où l'autorité des iwis existe de manière indépendante et où l'architecture de la plateforme l'intègre ou non). L'architecture ne crée pas la souveraineté des iwis ; elle respecte la souveraineté qui existe déjà.

6.2 Tension : Lignes de base et pluralisme

Une inquiétude légitime : si chaque autorité définit ses propres axes de biais, qu'est-ce qui empêche un pack de pilotage qui encode des normes néfastes ?

Le modèle polycentrique n'élimine pas cette tension - il la rend explicite et gérable :

Les bases de sécurité de la plate-forme représentent un plancher et non un plafond. Elles codent des interdictions largement partagées (par exemple, les contenus qui facilitent la violence, l'exploitation ou la tromperie). Ces lignes de base ne sont pas négociables au niveau de la plateforme - tous les déploiements les intègrent.
L'orientation culturelle et fondée sur des valeurs** se situe au-dessus de ce niveau. Différentes autorités peuvent piloter différemment dans l'espace situé au-dessus de la ligne de base de sécurité.
Les conflits entre autorités** sont résolus par la négociation et non par la hiérarchie. En cas de conflit entre une meute d'iwis et une plate-forme de référence, la solution passe par un dialogue entre les autorités concernées, et non par une dérogation unilatérale de l'une ou l'autre des parties.

La réponse honnête est que cette tension ne peut pas être entièrement résolue par l'architecture. Il s'agit d'un problème politique qui nécessite des processus politiques : délibération, négociation et parfois désaccord. Le rôle de l'architecture est de rendre ces processus possibles et visibles, et non de les automatiser.

Note éditoriale — février 2026 (ajoutée après publication)

Depuis la publication initiale, les recherches de Radhakrishnan et al. (2026), publiées dans Science le 19 février 2026, ont démontré empiriquement que les techniques de pilotage représentationnel peuvent outrepasser les comportements de sécurité entraînés dans les modèles linguistiques de pointe — y compris les refus de sécurité — par la manipulation directe des représentations de l'espace d'activation. Cette découverte complique l'hypothèse selon laquelle les bases de référence en matière de sécurité des plateformes constituent un socle structurellement solide. Si la même catégorie de techniques qui permet l'orientation culturelle peut en principe dissoudre les contraintes de sécurité, alors la robustesse de la base de référence est une question de gouvernance, et non pas simplement une question technique.

Cela n'affaiblit pas le modèle polycentrique proposé dans cet article, mais le renforce. Une base de référence en matière de sécurité dont l'intégrité dépend du contrôle unilatéral d'un seul opérateur de plateforme est, selon cette analyse, précisément le type de concentration de gouvernance que l'architecture polycentrique est conçue pour éviter. Une autorité distribuée, une provenance explicite et une capacité d'audit au niveau communautaire constituent des réponses plus résilientes à ce risque que la seule application centralisée.

Dans l'architecture spécifique de la plateforme Village, les vecteurs de pilotage et les corrections calibrées culturellement sont cryptés et stockés séparément des pondérations du modèle de base, ce qui réduit considérablement le risque d'extraction non autorisée ou de falsification des artefacts gouvernés. Les poids du modèle de base Llama restent ouverts de par leur conception — une caractéristique générale de l'écosystème à poids ouverts — et les outils RFM publiés parallèlement à l'article de Radhakrishnan et al. signifient que l'exploration des représentations de la couche de base est désormais accessible aux acteurs disposant de ressources suffisantes, indépendamment de toute plateforme. La réponse de la gouvernance à cette réalité n'est pas la fermeture technique, mais une gestion transparente et responsable de la couche de pilotage, ce que le registre taonga et l'architecture de provenance proposés ici sont précisément conçus pour fournir.

6.3 Se connecter à Tino Rangatiratanga

Tino rangatiratanga - le droit des Maoris à exercer leur autorité sur leurs propres affaires - n'est pas une préférence politique qui peut être prise en compte en rendant la plate-forme plus flexible. Il s'agit d'un principe constitutionnel (énoncé à l'article 2 de Te Tiriti o Waitangi) qui existe indépendamment de l'architecture de toute plate-forme.

Dans le contexte du pilotage de l'IA :

L'autorité de l'iwi sur les packs de pilotage qui encodent le tikanga est une expression du tino rangatiratanga, et non une "fonctionnalité" fournie par la plateforme.
Le rôle de la plateforme est de ne pas entraver cette autorité - de fournir une infrastructure technique que les iwi peuvent utiliser ou non selon leurs propres conditions.
Le droit de non-participation est l'expression architecturale de ce principe : la souveraineté de l'iwi ne dépend pas de l'existence de la plateforme.

7. Voies d'accès à la participation communautaire

7.1 Devenir une autorité de pilotage reconnue

Le modèle polycentrique requiert un processus par lequel les institutions peuvent devenir des autorités de pilotage reconnues. Ce processus doit être :

Des critères clairs définissent ce qui constitue une autorité de pilotage : structure de gouvernance établie, décideurs identifiables, capacité à maintenir et à réviser les dossiers de pilotage, responsabilité vis-à-vis d'une communauté identifiable.
Non exclusive : plusieurs autorités peuvent opérer dans le même domaine. Deux iwi desservant la même région peuvent maintenir des dossiers de pilotage différents reflétant des tikanga différents - ceci est attendu, ce n'est pas un problème à résoudre.
La reconnaissance peut être retirée si une autorité cesse de maintenir sa capacité de gouvernance ou sa responsabilité.

7.2 Co-conception d'ensembles de données contrastives

Les vecteurs de pilotage sont extraits des paires d'invites contrastives. La qualité de ces paires détermine la qualité de l'orientation. Pour les meutes gouvernées par les iwis :

Les paires contrastives doivent être conçues par des personnes ayant une expertise dans le domaine -- kuia et kaumatua, conseillers en tikanga, éducateurs communautaires -- et pas seulement par des ingénieurs.
Les suites d'évaluation devraient être notées par les membres de la communauté**, et pas seulement par des mesures automatisées. Une échelle de 5 points pour la "sensibilité culturelle" n'a pas la même signification pour toutes les communautés ; les critères de notation doivent être définis au niveau local.
Le problème de l'angle mort partagé** (STO-RES-0009, section 6.3) est un argument en faveur de la génération de données indépendantes : les ensembles de données contrastives gérés par les iwis, créés par des personnes qui connaissent le domaine, sont un contre-pouvoir épistémique nécessaire aux paires générées par le modèle qui peuvent hériter des propres biais du modèle.

7.3 Renforcement des capacités

La gestion des groupes de pilotage en tant que taonga nécessite des compétences qui font le lien entre les connaissances techniques en matière d'intelligence artificielle et la gouvernance culturelle :

Comprendre ce que sont les vecteurs de pilotage, comment ils fonctionnent et ce qu'ils peuvent et ne peuvent pas faire. Cela ne nécessite pas d'expertise en apprentissage automatique, mais une compréhension suffisante pour prendre des décisions éclairées en matière de gouvernance.
La conception de la gouvernance ** Établir des processus de révision, des politiques de versionnement, des conditions d'accès et des procédures de résolution des litiges pour les packs de pilotage.
Collaboration inter-iwi.** Les iwis peuvent souhaiter partager l'infrastructure (par exemple, l'hébergement des registres taonga) tout en conservant une gouvernance indépendante. Les modèles fédérés - services techniques partagés avec une gouvernance séparée - sont une solution naturelle.

7.4 Ce que cela exige de la plateforme

Les obligations de la plate-forme dans ce modèle sont principalement négatives - ce qu'elle ne doit pas faire :

Elle ne doit pas encapsuler, forker ou redistribuer des packs taonga sans consentement explicite.
Elle ne doit pas substituer sa propre direction lorsqu'un pack iwi est absent ou retiré.
Ne doit pas exiger que les packs iwi se conforment à un schéma ou à une ontologie définis par la plateforme.
ne doit pas traiter la gouvernance des iwis comme une "fonctionnalité" à activer ou à désactiver.

Et quelques obligations positives :

Doit fournir des API ouvertes et documentées que les registres de taonga peuvent intégrer.
Doit mettre en œuvre un enregistrement de la provenance qui soit accessible à toutes les parties prenantes.
Maintenir la base de sécurité de manière transparente et avec une documentation claire.
Soutenir les processus de signalement et de résolution des conflits qui impliquent les autorités compétentes.

8. Limites

8.1 Statut du projet

Le présent document est une ébauche rédigée sans examen par les pairs maoris. Les concepts te ao Maori utilisés ici - taonga, tikanga, tino rangatiratanga, kaitiakitanga, mana - sont des concepts complexes et vivants dont la signification et l'autorité vont bien au-delà de ce qu'un auteur non maori peut représenter pleinement. Les propositions architecturales présentées dans ce document sont des points de départ pour la discussion, et non des modèles établis. Les universitaires, les praticiens et les organes de gouvernance maoris peuvent estimer que les propositions appliquent mal, simplifient à l'excès ou instrumentalisent ces concepts de manière inappropriée. Nous accueillons volontiers cette critique et la considérons comme essentielle à notre travail.

8.2 Distance de mise en œuvre

L'architecture décrite ici est conceptuelle. Il n'existe pas de registre de pilotage taonga. Aucun compositeur directeur polycentrique n'a été construit. Le processus de mise en œuvre en quatre phases décrit dans la STO-RES-0009 devrait être complété par des phases supplémentaires pour la conception du registre, les processus de reconnaissance de l'autorité et l'infrastructure de provenance - un travail qui ne sera pas mis en œuvre avant des années, et non des mois.

8.3 Questions relatives à l'échelle et aux incitations

La gouvernance polycentrique ajoute à la complexité. La maintenance de registres multiples, la vérification de la provenance au moment de l'inférence et la négociation de conflits entre les autorités entraînent tous des coûts - informatiques, institutionnels et humains. La question de savoir si ces coûts sont supportables à l'échelle de la communauté (par opposition à l'échelle de l'entreprise ou du gouvernement) reste ouverte. Les contraintes matérielles de la plateforme Village, qui sont celles d'un consommateur, rendent cette question particulièrement aiguë.

8.4 Risque de tokenisme

Il existe un risque que la "gouvernance polycentrique" devienne une nouvelle étiquette pour le même vieux schéma : l'opérateur de la plateforme construit le système, ajoute une API et l'appelle "iwi-gouverné" parce qu'iwi pourrait, en théorie, s'y connecter. Une véritable polycentricité exige que les autorités iwi soient impliquées dans la conception de l'architecture elle-même, et pas seulement dans son utilisation. Ce document, rédigé sans coauteur maori, est lui-même un exemple du fossé qui sépare les aspirations de la pratique.

8.5 Résolution des conflits à l'échelle

Le document reconnaît que les conflits entre les autorités de pilotage nécessitent des processus politiques, mais il ne précise pas ces processus en détail. Dans la pratique, les conflits concernant les paquets de pilotage qui devraient s'appliquer dans les domaines contestés peuvent être difficiles à résoudre en l'absence de relations institutionnelles établies, de normes de délibération partagées et de confiance mutuelle - des ressources qu'il faut des années pour construire et qui ne peuvent pas être mises en place par l'architecture.

9. Conclusion

Le premier article (STO-RES-0009) a établi que les déploiements souverains de SLM ont un avantage structurel pour le débiaisage du temps d'inférence : l'accès complet aux poids et aux activations du modèle permet des techniques de vecteur de pilotage qui sont architecturalement impossibles par le biais d'API commerciales. Cet article soutient que la gouvernance de ces vecteurs de pilotage est au moins aussi importante que la capacité technique elle-même.

Les vecteurs de pilotage sont des instruments d'application des normes. Qui définit les normes, à travers quel processus, et avec quel recours pour ceux qui y sont soumis - ce sont des questions politiques auxquelles l'ingénierie seule ne peut pas répondre.

Le modèle polycentrique proposé ici - autorités de pilotage égales, registres centrés sur les taonga, provenance explicite et droit de non-participation - n'est pas la seule réponse possible. Mais c'est une réponse qui prend au sérieux la proposition selon laquelle l'IA souveraine doit être au service de plusieurs souverainetés, et non d'une seule.

Le problème de l'essuie-glace de la STO-RES-0009 est toujours la bonne métaphore de départ : certains biais se déclenchent avant que la délibération ne s'engage, et les correctifs rapides ne peuvent pas les atteindre. Mais la question de savoir qui peut déplacer la tige de l'indicateur - et à qui appartient le véhicule en premier lieu - est une question de gouvernance que ce document commence à aborder.

Il commence, mais ne finit pas. L'étape suivante n'est pas une architecture supplémentaire. Il s'agit de discuter - avec les organes de gouvernance des iwis, avec les universitaires maoris, avec les praticiens communautaires - pour déterminer si ces propositions servent les personnes qu'elles prétendent servir, ou si elles doivent être considérablement révisées ou remplacées.

Note éditoriale — février 2026 (ajoutée après publication)

La publication de Radhakrishnan et al. (2026) dans Science confirme l'urgence de la gouvernance préconisée dans cet article. La capacité démontrée à manipuler le comportement des modèles au niveau de la représentation — y compris en contournant les contraintes de sécurité — établit que la question de savoir qui gouverne la couche de pilotage n'est pas une préoccupation spéculative pour les futurs systèmes d'IA, mais un défi immédiat de gouvernance pour ceux qui sont actuellement déployés. Les cadres qui répartissent cette autorité entre des institutions responsables, identifiables et ancrées dans la communauté — plutôt que de la concentrer entre les mains d'un seul opérateur de plateforme — constituent une réponse plus appropriée à cette réalité que le verrouillage technique ou l'opacité de la gouvernance.

Radhakrishnan, A., Beaglehole, D., Belkin, M., & Boix-Adserà, E. (2026). Exposing biases, moods, personalities, and abstract concepts hidden in large language models. Science. Published 19 February 2026.

Le document d'accompagnement STO-RES-0009 a été révisé en version 1.1 afin de corriger un problème de précision dans ses revendications d'accès à l'API, soulevé par les mêmes conclusions. Les lecteurs sont invités à se référer à la version 1.1 du document STO-RES-0009 plutôt qu'à la version 1.0. L'argument central des deux documents reste inchangé ; les travaux du MIT le renforcent plutôt que de le remettre en cause.

Références

Carroll, S. R., et al. (2020). Les principes CARE pour la gouvernance des données indigènes. Data Science Journal, 19(1), 43.
Kukutai, T. & Taylor, J. (Eds.) (2016). Souveraineté des données autochtones : Toward an Agenda. ANU Press.
Ostrom, E. (1990). Governing the Commons : The Evolution of Institutions for Collective Action. Cambridge University Press.
Ostrom, E. (2010). Au-delà des marchés et des États : La gouvernance polycentrique des systèmes économiques complexes. *American Economic Review, 100(3), 641-672.
Rimsky, N., et al. (2023). Steering Llama 2 via Contrastive Activation Addition. arXiv:2312.06681.
Stroh, J. & Claude (2026). Vecteurs de pilotage et biais mécanique : débiaisage en temps d'inférence pour les petits modèles de langage souverains. STO-RES-0009 v1.1.
Te Mana Raraunga (2018). Principes de souveraineté des données maories. Charte de Te Mana Raraunga.
Templeton, A., et al. (2024). Mise à l'échelle de la monosémanticité : Extraction de caractéristiques interprétables à partir du sonnet de Claude 3. Anthropic.
Turner, A., et al. (2023). Activation Addition : Steering Language Models Without Optimization. arXiv:2308.10248.
Tribunal de Waitangi (2011). Ko Aotearoa Tenei : A Report into Claims Concerning New Zealand Law and Policy Affecting Maori Culture and Identity (Rapport sur les plaintes concernant la loi et la politique néo-zélandaises affectant la culture et l'identité maories). Te Ropu Whakamana i te Tiriti o Waitangi.
Zou, A., et al. (2023). Representation Engineering : A Top-Down Approach to AI Transparency. Centre pour la sécurité de l'IA.

Licence

Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution 4.0 International (CC BY 4.0).

Vous êtes libre de partager, copier, redistribuer, adapter, remixer, transformer et créer à partir de ce matériel, y compris à des fins commerciales, à condition de fournir une attribution appropriée, de fournir un lien vers la licence et d'indiquer si des modifications ont été apportées.

Note : Le code source du Tractatus AI Safety Framework est licencié séparément sous la Licence Apache 2.0. Cette licence Creative Commons s'applique uniquement au texte et aux figures du document de recherche.

Métadonnées du document

-- Fin du document --