Agents · Conformité · Brouillon
Comment faire fonctionner un monde de l’IA et le garder conforme
Confiez une tâche à un agent et vous pouvez lire ce qu'il a fait. Confiez à vingt agents des boucles de longue durée, plusieurs hôtes et une poignée de personnes qui doivent rester aux commandes, et personne ne peut tout lire. Le monde ne tient que si trois choses sont vraies : chaque action est validée, chaque agent est isolé, et chaque étape laisse une preuve.
La bonne nouvelle : ce sont les mêmes briques. Les contrôles qui font fonctionner un tel monde sont les preuves qu'un auditeur de conformité demande à voir. La conformité n'est pas un second système posé par-dessus.
Une règle, quatre couches
Chaque couche suppose que la couche au-dessus peut se tromper, et limite ce qu'une erreur peut atteindre.
- Les personnes détiennent les décisions : elles approuvent les merges, fixent le périmètre et acceptent le risque.
- Les agents font le travail dans des boucles séparées, avec des règles de progression mesurables.
- Les hôtes et plateformes sont conçus pour être petits, isolés et à liste d'autorisation : aucun port entrant, des messages signés.
- La preuve : chaque étape laisse une trace qu'une autre personne peut suivre.
Faire fonctionner : des contrôles stricts, pas de bonnes intentions
Cœur et instances. Un dépôt cœur partagé ; chaque organisation reçoit sa propre instance. Le travail arrive branche par branche, de sorte que rien ne change sur place.
Points de validation de revue indépendante. Un relecteur est lié au commit exact qu'il a relu, de sorte que ce qui a été relu est ce qui est livré. Un scan de marqueurs empêche les données d'organisation de fuiter vers le cœur partagé. Le propriétaire approuve le merge.
Un minuscule agent d'hôte (une conception, pas encore en usage). Il ne contiendrait aucun modèle. Il n'exécuterait que des commandes autorisées par liste, via git et des messages signés, et n'écouterait sur aucun port entrant. Un agent manipulé ne trouverait presque rien à atteindre.
Quatre boucles contre la dérive. Un long travail autonome s'égare. Des boucles séparées, chacune avec une règle de progression mesurable, le maintiennent sur la voie.
Une carte du monde. Une vue d'ensemble zonée et cliquable des agents, des hôtes et des plateformes est en cours de développement.
Les tâches lourdes, une à la fois. Sérialiser le travail coûteux rend les ressources partagées prévisibles.
Ce qui est soumis à validation et ce qui est seulement consigné
Dire que chaque action est soumise à validation serait faux, et cela ne fonctionnerait pas. Les points de validation sont placés selon le type d'action.
Soumis à validation, avec une personne qui décide :
- tout ce qui modifie le cœur partagé,
- tout ce qui sort vers l'extérieur, comme publier, suivre, répondre ou envoyer,
- les modifications des identifiants, des permissions ou des listes d'autorisation,
- toute étape qui exige un secret.
Seulement consigné, sans que personne n'attende :
- lire et rechercher,
- rédiger dans des fichiers locaux,
- analyses, notes et rapports.
Le journal est relu après coup. Les lectures et les brouillons sont faciles à annuler, ils restent donc libres ; le point de validation est réservé à ce qu'il est difficile de reprendre.
Une limite : la fatigue d'approbation. Si tout demande une approbation, les gens cessent de lire ce qu'ils approuvent et cliquent à la chaîne. Un point de validation toujours ouvert ne protège rien. Le remède : moins de points de validation, plus clairs, placés selon le risque, chacun montrant la chose exacte qui est approuvée, le reste étant laissé au journal.
Rendre conforme : les mêmes contrôles, lus comme preuves
| Brique | Ce qu’elle prouve | Points d'ancrage des référentiels (indicatifs) |
|---|---|---|
| Merge approuvé par le propriétaire | Une personne décide avant qu’un changement n’entre en service | Gestion des changements ISO 27001 ; supervision humaine de l'EU AI Act (systèmes à haut risque) ; NIST AI RMF Govern |
| Relecture indépendante liée à un commit | Séparation des tâches ; relu égale livré | Développement sécurisé ISO 27001 ; gestion des changements SOC 2 |
| Isolation et listes d’autorisation | Moindre privilège ; périmètre d’impact limité | Contrôle d’accès et gestion de la configuration ISO 27001 ; accès logique SOC 2 |
| Messages signés et journaux | Qui a fait quoi, et quand | Journalisation ISO 27001 ; tenue de registres de l'EU AI Act (systèmes à haut risque) |
| Registre des risques et suivi des tâches | Les risques connus ont des responsables et des échéances | Traitement des risques ISO 27001 ; ISO/IEC 42001 ; NIST AI RMF Map et Manage |
| Suivi de l’état de préparation | Les écarts par rapport à l’EU AI Act et au Cyber Resilience Act sont visibles tôt | EU AI Act ; EU Cyber Resilience Act |
Ces points d'ancrage sont indicatifs ; ils ne constituent ni une affirmation de certification ni un avis juridique.
Comment commencer : cinq étapes
- Cartographiez. Listez chaque agent, chaque hôte et chaque plateforme, et ce que chacun peut toucher. On ne gouverne pas ce qu'on ne voit pas.
- Isolez. Identifiants limités, sandboxes, listes d'autorisation. Partez du principe que tout agent peut se tromper ou être manipulé.
- Validez. Une revue indépendante et l'approbation d'un propriétaire avant que quoi que ce soit ne quitte le sandbox.
- Consignez. Faites de la preuve un sous-produit : messages signés, revues liées au commit, historique des tâches.
- Rattachez aux référentiels. Reliez chaque contrôle à l'attente à laquelle il répond, suivez l'état de préparation, et revoyez à un rythme régulier.