Kill switch IA et validation par un tiers : construire le dossier de preuves avant la mise en production (guide PME, AI Act art. 14 et 26)

Le 5 octobre 2026, le Conseil municipal de New York a auditionné sous serment OpenAI, Anthropic, Meta et Google. Question posée par la présidente Julie Menin : si un modèle échoue à un test de sécurité interne ou à une validation indépendante, sa sortie est-elle bloquée ? Selon amNewYork et City & State, aucune des quatre entreprises n'a répondu par un « oui » clair ; toutes ont décrit leurs processus de revue.

Sur la table du Conseil : le projet Intro 2602. S'il est adopté, il rendrait illégal de commercialiser, vendre ou déployer un système d'IA à New York sans validation par un tiers et sans kill switch — « une commande humaine capable d'arrêter le système » — dont l'existence doit être vérifiée par le validateur. Amende : 25 000 dollars par cas, pour l'entreprise comme pour le validateur, en cas d'absence ou de falsification de la validation (communiqué du Conseil, 25 septembre 2026).

Pour une PME européenne, ce n'est pas une curiosité américaine. L'AI Act contient déjà un bouton « stop » pour les systèmes à haut risque. Et quel que soit le texte qui finira par s'appliquer à vous, la question posée par un client, un assureur ou un auditeur sera la même : montrez-moi le test, et montrez-moi l'interrupteur.

Ce guide détaille les pièces du dossier de preuves à préparer avant de mettre un agent IA en production.

Ce que le projet new-yorkais exige (et pourquoi il vous concerne)

D'après le communiqué officiel du Conseil, le validateur tiers doit vérifier le système sur :

• la qualité des données ;
• les biais ;
• les sorties décisionnelles ;
• la confidentialité des données ;
• la sécurité ;
• tout autre critère fixé par le NYC Cyber Command.

Le validateur doit déclarer ses conflits d'intérêts, et il doit vérifier l'existence du kill switch. Le paquet législatif prévoit aussi un signalement des incidents de sécurité IA sous 24 heures pour les prestataires de la ville (Intro 2601), un droit d'action individuel en cas de préjudice prévisible lié au contournement des garde-fous (Intro 2600) et une rémunération des lanceurs d'alerte sur les amendes recouvrées (Intro 2605).

Point clé : l'obligation vise « toute entreprise » qui déploie un système d'IA — pas seulement les laboratoires. C'est exactement la logique « déployeur » de l'AI Act.

Ce que l'AI Act dit déjà du kill switch

• Article 14 (contrôle humain) : les systèmes d'IA à haut risque doivent permettre aux personnes chargées de la supervision d'intervenir dans leur fonctionnement ou de les interrompre au moyen d'un bouton d'arrêt ou d'une procédure similaire permettant de mettre le système à l'arrêt dans un état sûr.
• Article 26 (obligations des déployeurs) : utiliser le système conformément à sa notice, confier le contrôle humain à des personnes compétentes, formées et dotées de l'autorité nécessaire, surveiller le fonctionnement, et conserver les journaux générés automatiquement (au moins six mois, dans la mesure où ils sont sous votre contrôle).
• Article 4 (maîtrise de l'IA) : les personnes qui utilisent l'IA pour votre compte doivent avoir un niveau suffisant de compétence.
• Calendrier : selon la page « enforcement » de la Commission européenne, les règles pour les systèmes à haut risque de l'annexe III s'appliquent à partir du 2 décembre 2027 ; les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026.

Même si votre agent n'est pas classé « haut risque », ces articles donnent la grille que les grands comptes recopient dans leurs questionnaires fournisseurs. Pour le détail AI Act + logs, voir AI Act Omnibus, MCP et logs d'audit.

Pourquoi un kill switch d'agent est plus difficile qu'il n'y paraît

Arrêter un chatbot, c'est fermer un onglet. Arrêter un agent — avec des identifiants, des tâches planifiées, des sous-agents et des accès API — c'est autre chose. Un vrai kill switch d'agent doit couvrir quatre couches :

1. Identité : révoquer en une action les jetons de l'agent (d'où l'intérêt de jetons courts émis par une passerelle que l'agent ne contrôle pas — voir NIST IR 8587 et jetons d'agents).
2. Réseau : couper l'egress, même si le processus continue de tourner (voir sandbox DNS et filtrage egress).
3. Exécution : vider la file des appels d'outils en attente et annuler les tâches planifiées — pas seulement « mettre en pause ».
4. Preuve : conserver les journaux hors de portée de l'agent, pour que l'arrêt lui-même soit auditable.

Un kill switch écrit dans le prompt système (« arrête-toi si… ») n'est pas un kill switch. C'est une instruction adressée au système que vous cherchez justement à arrêter.

Le dossier de preuves : 8 pièces à préparer avant le déploiement

1. Fiche d'identité du système

Nom de l'agent, fournisseur du modèle, version, finalité, propriétaire métier nommé, propriétaire technique nommé, systèmes connectés (CRM, e-mail, ERP, paiement, cloud), date de mise en service. Sans inventaire, pas de validation possible — voir inventaire et identité des agents.

2. Matrice des actions par niveau de risque

Classez chaque action que l'agent peut déclencher :

• R0–R2 : lecture, brouillons, actions internes réversibles — autorisées et journalisées.
• R3 : e-mail client, publication, modification de données en production — validation humaine obligatoire.
• R4 : paiements, suppression, changement de droits — double validation ou interdit à l'agent.

Un validateur commencera par là : qu'est-ce que l'agent *peut* faire, pas ce qu'il est *censé* faire. Détail : responsabilité et contrôle humain.

3. Spécification du kill switch

Pour chaque couche (identité, réseau, exécution, preuve) : le mécanisme, qui peut l'actionner, comment (console, commande, API), et le délai cible d'arrêt que vous vous fixez. Prévoyez au moins deux personnes habilitées, y compris hors heures ouvrées. L'article 14 parle de personnes ayant l'autorité nécessaire : nommez-les.

4. Procès-verbal d'exercice d'arrêt

La pièce la plus souvent manquante. Organisez un exercice réel : déclenchement, chronométrage, vérification que les jetons sont révoqués et que l'egress est coupé, contrôle qu'aucune tâche planifiée ne repart. Consignez date, participants, délai mesuré, écarts constatés, actions correctives. Répétez à chaque changement majeur (nouvel outil, nouveau modèle, nouvelle intégration).

5. Rapport de tests avant mise en production

Reprenez la grille new-yorkaise, elle est simple et transposable : qualité des données, biais, sorties décisionnelles, confidentialité, sécurité. Ajoutez des tests propres aux agents : injection de prompt via documents et pages web, tentative d'exfiltration vers une destination non autorisée, comportement face à une instruction contradictoire, combinaison de deux agents. Documentez ce qui a échoué, pas seulement ce qui a réussi.

6. Déclaration d'indépendance du validateur

Si vous faites appel à un tiers (cabinet, intégrateur, évaluateur), demandez une déclaration de conflits d'intérêts — c'est explicitement exigé à New York. Si la validation est interne, séparez au minimum l'équipe qui construit de celle qui valide. Voir notre analyse évaluateurs IA indépendants.

7. Journaux et conservation

Chaque prompt, réponse, appel d'outil et décision d'approbation est journalisé dans un stockage que l'agent ne peut ni lire ni modifier. Durée de conservation définie (l'article 26 fixe un minimum de six mois pour les déployeurs de systèmes à haut risque). Les journaux doivent permettre de reconstituer : qui a demandé quoi, ce que l'agent a fait, qui a approuvé.

8. Procédure d'incident

Définition de ce qui constitue un incident IA, canal de remontée, responsable, délai interne de qualification (le projet new-yorkais retient 24 heures pour la notification par les prestataires de la ville : c'est un bon repère interne), et lien avec votre procédure RGPD de violation de données (72 heures vers l'autorité lorsque des données personnelles sont concernées).

Les erreurs qui font échouer une validation

• « Le fournisseur du modèle s'en occupe. » Non : les obligations visent aussi celui qui déploie. L'audition new-yorkaise a d'ailleurs montré que les laboratoires eux-mêmes ne s'engagent pas à bloquer une sortie sur la base d'un test échoué.
• Des identifiants longue durée dans le contexte de l'agent. Impossible à révoquer proprement en urgence.
• Un kill switch jamais testé. Une procédure non exercée n'est pas une preuve.
• Des journaux stockés là où l'agent écrit. Ils ne prouvent rien en cas d'incident.
• Une validation figée. Un nouvel outil connecté change le périmètre : la matrice R0–R4 et l'exercice d'arrêt doivent être refaits.

Par où commencer cette semaine

1. Listez vos agents et assistants en production (même les « pilotes »).
2. Pour le plus exposé, remplissez la matrice R0–R4.
3. Planifiez un exercice d'arrêt de 30 minutes et chronométrez-le.
4. Vérifiez où sont stockés les journaux, et qui peut les modifier.

Pour cadrer l'ensemble, utilisez notre checklist gouvernance IA ou lancez une évaluation de risque.

Ce que TrustAI Vault vous apporte

TrustAI Vault place la couche de contrôle entre vos équipes, leurs assistants et les modèles — hors de portée de l'agent :

• DLP avant que les données n'atteignent un modèle ;
• egress en liste blanche ;
• validations humaines sur les actions sensibles ;
• journaux d'audit infalsifiables ;
• kill switch administrateur testable, dont l'usage est lui-même journalisé.

Autrement dit, les pièces 3, 4, 7 et 8 du dossier de preuves sortent directement de l'outil, au lieu d'être reconstituées à la main le jour où un client ou un auditeur les demande.

CTA : testez Vault Pro pendant 4 jours → Démarrer l'essai gratuit

Sources

• amNewYork — Adam Daly, « AI giants give few clear answers to key safety questions at NYC Council hearing amid whistleblower warnings » (5 octobre 2026) : amny.com
• City & State New York — Annie McDonough, « Leading AI companies fail to impress at City Council AI hearing » (5 octobre 2026) : cityandstateny.com
• Conseil municipal de New York — communiqué du 25 septembre 2026 sur le paquet législatif IA : council.nyc.gov
• Commission européenne — « The enforcement framework of the AI Act » : digital-strategy.ec.europa.eu
• Règlement (UE) 2024/1689 (AI Act), articles 4, 14 et 26 : eur-lex.europa.eu