À retenir
L’inférence locale n’est qu’un composant. La maîtrise dépend aussi des flux de données, des services externes et de l’autorité sur les changements.
Définir la frontière avant de choisir la technologie
La souveraineté commence par une frontière système explicite. L’institution doit connaître les données, identités, réseaux, modèles, journaux, opérateurs et services externes qui participent à la mission. Sans cette cartographie, l’hébergement local peut masquer des dépendances qui échappent encore à son contrôle.
- Cartographier les flux de données et les frontières de confiance
- Identifier les dépendances opérationnelles et de chaîne d’approvisionnement
- Distinguer les contrôles obligatoires des préférences de déploiement
Le contrôle couvre tout le cycle d’exploitation
Un système n’est pas contrôlé uniquement le jour de son déploiement. Les mises à jour des modèles, les changements d’accès, la réponse aux incidents, les données d’évaluation, les sauvegardes et le retrait influencent la capacité de l’institution à agir de façon autonome et responsable dans la durée.
- Gouverner les changements de modèles et de configuration
- Conserver des preuves d’audit utiles
- Prévoir une voie crédible de sortie et de reprise
Choisir l’architecture selon la mission et le risque
Sur site, cloud privé, cloud souverain et environnement isolé sont des choix de mise en œuvre, pas des garanties de souveraineté. La bonne topologie découle de la mission, de la sensibilité, de la latence, de la connectivité, des compétences et des exigences de continuité.
Vérifier la propriété par des preuves
La souveraineté doit pouvoir être testée. Les dossiers d’architecture, revues d’accès, inventaires de dépendances, exercices opérationnels et journaux de changements apportent des preuves plus solides que des affirmations générales sur le lieu d’exécution d’un modèle.
Une question à mettre à l’épreuve
Un modèle fonctionne sur site, mais l’authentification et les journaux d’activité utilisent des services externes. Quelles données franchissent le périmètre, qui administre ces services et que se passe-t-il s’ils deviennent indisponibles ?
Scénario illustratif, et non retour sur un déploiement réel.
Pour approfondir
Des sources primaires externes pour compléter la lecture. Ces notes expriment la perspective d’ingénierie de MX4 AI, sans impliquer l’approbation de leurs auteurs.
NIST · 2023
NIST AI Risk Management Framework 1.0Les volets GOVERN 6 et MAP 4 abordent les dépendances tierces et les risques liés aux composants du système.
Cette note expose une perspective d’ingénierie, et non une étude expérimentale. L’architecture et les contrôles doivent être évalués selon l’institution, l’usage et l’environnement.
Échanger sur un projet lié à ce sujet