Un incident impliquant un agent IA comprime le cycle normal de réponse. Le système peut proposer un nouvel appel d'outil, rafraîchir un identifiant d'accès ou lancer une nouvelle exécution pendant que l'équipe ouvre encore la cellule de crise. Ce playbook donne au commandant d'incident un cheminement ordonné : contenir la capacité active, préserver les enregistrements, restaurer une Release réputée saine, réconcilier les effets de bord et prendre la décision de déclaration à partir de faits vérifiés. Il met les preuves en correspondance avec l'article 73 du règlement européen sur l'IA (EU AI Act) sans présumer que chaque agent ou chaque incident relève de cette disposition. Informations opérationnelles générales uniquement ; un conseil juridique qualifié doit confirmer le périmètre légal, les délais et les notifications.
Ouvrir un incident unique et démarrer les horloges
Le profil IA générative du NIST recommande, pour les plans d'incident relatifs à l'IA générative tierce, une responsabilité définie, des exercices réguliers, une amélioration rétrospective et un alignement avec les lois sur la notification des violations, la protection de la vie privée et les autres réglementations. Le NIST SP 800-61 révision 3 intègre la réponse aux incidents à travers la préparation, la détection, la réponse et le rétablissement.
Déclarez un enregistrement d'incident unique avant que les intervenants n'effectuent des modifications en parallèle. Consignez l'heure de première détection, l'heure de prise de connaissance, le système et la Release affectés, le comportement observé, les effets de bord connus, les personnes touchées, les environnements, les identités des agents et des humains, ainsi que la source de chaque fait. Conservez les assertions, les hypothèses et les décisions dans des champs distincts.
Attribuez quatre rôles nommés. Le commandant d'incident est responsable de la séquence et du confinement. Le propriétaire du système opère l'agent et les services en aval. Le responsable des preuves préserve les enregistrements et la chronologie des actions. Le responsable juridique décide du périmètre de notification et assure la coordination avec le conseil juridique, la protection des données, la sécurité et les équipes sectorielles.
- Responsable de la gravité : fixe le niveau d'impact actuel et l'heure de la prochaine revue
- Échéance de confinement : fixe l'heure limite acceptable pour l'accusé de réception de chaque actionneur du coupe-circuit
- Responsable des preuves : consigne la source, l'heure de collecte, l'état d'intégrité et la chaîne de conservation de chaque artefact
- Responsable de la déclaration : consigne chaque régime possible, le déclencheur légal, l'autorité, l'horloge et la décision
Préserver les preuves volatiles avant les modifications d'ampleur
Capturez l'état volatil dès le début du confinement : identifiants des exécutions actives, tâches en file d'attente, Decision Requests ouvertes, identité des processus et des charges de travail, Release courante, version du modèle et du prompt, version de politique, références des identifiants d'accès, connexions réseau, registre des appels d'outils et identifiants des requêtes en aval. Scellez l'heure de collecte et l'identité du collecteur.
Pour un incident grave relevant de cette disposition, l'article 73, paragraphe 6, du règlement européen sur l'IA impose au fournisseur d'enquêter, d'évaluer le risque et de prendre des mesures correctives. Il lui impose également d'informer les autorités compétentes avant de modifier le système d'IA d'une manière susceptible d'affecter l'évaluation ultérieure des causes de l'incident. Le conseil juridique doit déterminer quand cette condition s'applique. Le playbook doit rendre explicite le point de contrôle de préservation des preuves afin que le confinement et la préservation réglementaire puissent avancer ensemble.
Copiez les journaux pertinents dans un espace de stockage placé sous le contrôle de l'incident et protégé en rétention. Préservez les enregistrements bruts et créez les chronologies dérivées séparément. Les empreintes de hachage et les signatures peuvent montrer si les fichiers collectés ont changé après la capture ; elles ne peuvent pas prouver qu'une source omise n'a jamais existé, le manifeste de collecte doit donc lister les sources attendues et les sources manquantes.
Contenir la capacité
Déclenchez l'architecture de coupe-circuit pour agents IA au périmètre le plus étroit qui contient le comportement observé. Élargissez à l'agent, à la Release, au tenant ou à l'environnement à mesure que les faits évoluent.
Le confinement se termine lorsque chaque actionneur requis a accusé réception ou lorsque le commandant d'incident consigne un substitut manuel. Un statut vert du service de workflow ne peut pas établir le confinement pour les jetons, les tâches en aval en file d'attente ou un worker s'exécutant hors de ce service.
| Cible | Action | Fait requis pour le confinement |
|---|---|---|
| Exécutions actives et sous approbation | Envoyer l'annulation, clore les Decision Requests en attente et refuser les tentatives ultérieures de reprise | État terminal et dernier effet de bord exécuté pour chaque exécution |
| Chemin de politique | Installer un blocage limité à l'incident à chaque point de contrôle des outils et des sorties | Version de politique, première action refusée et comportement fail-closed |
| Identité de l'agent | Désactiver l'identité, révoquer les jetons, empêcher le rafraîchissement et effectuer la rotation des secrets exposés | Fenêtre d'accès résiduel et résultat pour chaque classe d'identifiants d'accès |
| Charge de travail | Arrêter ou mettre en quarantaine les ressources de calcul et restreindre le trafic sortant | Inventaire des charges de travail et accusé de réception de l'isolement |
| Files d'attente et tâches en aval | Annuler le travail en attente et lister les requêtes déjà exécutées | État terminal ou compensatoire pour chaque requête acceptée |
| Accès aux données | Geler les chemins d'écriture affectés et préserver des instantanés lorsque c'est autorisé | Espaces de stockage couverts, heure de l'instantané et écritures observées après la déclaration |
Restaurer le système et réconcilier les effets
Choisissez le point de rétablissement à partir des preuves. Consignez la dernière Release réputée saine, le pack de politiques, la version du modèle et du prompt, le manifeste d'outils, la configuration des connecteurs et la génération des secrets en vigueur. Vérifiez leur provenance avant la promotion.
Un rollback de Release restaure les octets déployés et la configuration antérieurs. Il ne peut pas rappeler un e-mail, annuler un virement exécuté, restaurer un enregistrement externe supprimé ni retirer des données déjà divulguées. Ouvrez un élément de compensation propre au système concerné pour chaque effet déjà exécuté et attribuez un responsable et une échéance.
Remettez le système en service avec de nouveaux identifiants d'accès et une liste d'autorisation propre à l'incident. Exécutez un canari contrôlé avec le refus d'incident encore actif pour les versions antérieures affectées. N'ouvrez un trafic plus large qu'après que le canari a produit les décisions de politique, les effets de bord et les preuves attendus.
- Release : restaurer l'artefact antérieur vérifié et conserver l'artefact défaillant pour analyse
- Politique : restaurer la politique antérieure vérifiée en maintenant le refus limité à l'incident à une précédence supérieure
- Identité : émettre de nouveaux identifiants d'accès avec une nouvelle génération et le périmètre minimal requis
- État : restaurer depuis un instantané autorisé seulement après que le responsable des preuves a consigné sa provenance et son impact
- Effets externes : compenser, notifier ou corriger manuellement chaque action exécutée via le système propriétaire
- Surveillance : augmenter l'échantillonnage et les alertes pour la Release rétablie et définir le seuil de sortie
Constituer le dossier de preuves de l'incident
Le dossier doit permettre à un examinateur indépendant de reconstituer l'événement sans lire une transcription de chat ni demander aux intervenants de s'en souvenir. Préservez la séquence d'événements source et joignez les décisions sous forme d'enregistrements distincts et signés.
Dans KLA Control Plane, Lineage Explorer reconstitue l'exécution de l'agent, Audit Trail conserve les actions de gouvernance et d'opérateur, et Evidence Room empaquette les enregistrements sélectionnés dans un Sealed Evidence Bundle. Ces chemins sont implémentés dans l'environnement de développement KLA, le seul environnement que KLA exploite actuellement. Le bundle nécessite encore un manifeste de collecte qui nomme les sources attendues, les sources manquantes et le périmètre choisi par le responsable des preuves.
| Groupe de preuves | Champs requis | Question traitée |
|---|---|---|
| Détection | Signal, seuil, source, heure de première observation, premier triage, décision de prise de connaissance | Comment et quand l'organisation a-t-elle su |
| Exécution | Exécution, agent, Release, modèle, prompt, appels d'outils, arguments, sorties, effets de bord | Quelle capacité a agi et qu'est-ce qui a changé |
| Gouvernance | Versions de politiques, décisions, Decision Requests, approbateurs, rôles, hachages des arguments | Quels contrôles ont évalué chaque action à conséquences |
| Confinement | Commande, périmètre, acteur, accusés de réception, dernier effet de bord, exposition restante | Quand la capacité s'est-elle arrêtée |
| Rétablissement | Provenance réputée saine, Rollback, canari, identité neuve, éléments de compensation | Comment le fonctionnement sûr a-t-il été rétabli |
| Déclaration | Régimes applicables, analyse des déclencheurs, évaluation causale, décision du conseil juridique, transmissions | Pourquoi, quand et où l'incident a-t-il été déclaré |
Relier les faits à l'article 73 du règlement européen sur l'IA
Le texte officiel du règlement européen sur l'IA limite l'article 73 aux fournisseurs de systèmes d'IA à haut risque mis sur le marché de l'Union. L'article 3, point 49, définit un incident grave comme un incident ou un dysfonctionnement entraînant directement ou indirectement le décès ou une atteinte grave à la santé, une perturbation grave et irréversible d'infrastructures critiques, une violation d'obligations du droit de l'Union protégeant les droits fondamentaux, ou un dommage grave aux biens ou à l'environnement.
Le Digital Omnibus sur l'IA, règlement (UE) 2026/1744, est entré en vigueur le 27 juillet 2026. Il a modifié les dates d'application des exigences applicables aux systèmes à haut risque du chapitre III : 2 décembre 2027 pour les systèmes de l'annexe III et 2 août 2028 pour les systèmes de l'annexe I. Les fenêtres de déclaration de l'article 73 restent inchangées. L'interaction entre la classification du système, le rôle de fournisseur ou de déployeur, le droit sectoriel, les dates de transition et l'article 73 exige une décision juridique au cas par cas.
Consignez cette décision avec les faits disponibles au moment où elle est prise. Un événement de sécurité hors du champ de l'article 73 peut exiger une action au titre d'un autre régime.
| Disposition | Règle légale | À consigner dans le playbook |
|---|---|---|
| Article 73, paragraphe 1 | Le fournisseur d'un système d'IA à haut risque mis sur le marché de l'Union déclare tout incident grave aux autorités de surveillance du marché des États membres où il s'est produit | Classification du système, identité du fournisseur, mise sur le marché, États membres, autorités |
| Article 73, paragraphe 2 | Déclarer immédiatement après avoir établi un lien de causalité ou une probabilité raisonnable d'un tel lien, avec un plafond de 15 jours après la prise de connaissance | Heure de prise de connaissance, versions de l'évaluation causale, heure de déclaration, justification du délai écoulé |
| Article 73, paragraphe 3 | Une infraction de grande ampleur ou une perturbation grave et irréversible d'infrastructures critiques a un plafond de deux jours après la prise de connaissance | Catégorie d'impact, périmètre géographique, heure de prise de connaissance, échéance de deux jours |
| Article 73, paragraphe 4 | Un décès est déclaré immédiatement après que la causalité est établie ou soupçonnée, avec un plafond de 10 jours après la prise de connaissance | Préjudice connu, heure du soupçon, preuves causales, échéance de dix jours |
| Article 73, paragraphe 5 | Un rapport initial incomplet peut être suivi d'un rapport complet lorsque le respect des délais l'exige | Transmission initiale, lacunes connues, responsable de la mise à jour, cible du rapport complet |
| Article 73, paragraphe 6 | Le fournisseur enquête, évalue le risque, prend des mesures correctives, coopère et informe les autorités avant toute modification susceptible d'affecter l'évaluation ultérieure des causes | Plan d'enquête, état préservé, mesures correctives, contact avec l'autorité avant toute modification substantielle |
| Article 26, paragraphe 5 | Le déployeur qui identifie un incident grave en informe immédiatement d'abord le fournisseur, puis l'importateur ou le distributeur et les autorités de surveillance du marché concernées | Analyse du rôle, tentatives de contact, ordre de notification, procédure en cas de fournisseur injoignable |
Utiliser une séquence opérationnelle de 24 heures
Fixez le rythme de réponse interne bien en deçà des plafonds légaux de déclaration afin que la revue juridique reçoive des faits vérifiés pendant que les preuves sont encore disponibles.
| Temps écoulé | Objectif principal | Preuves de sortie |
|---|---|---|
| 0 à 15 minutes | Déclarer l'incident, attribuer les rôles, définir le périmètre de refus, déclencher le coupe-circuit | ID d'incident, heure de prise de connaissance, commande, statut des actionneurs |
| 15 à 60 minutes | Préserver l'état volatil, révoquer l'identité, isoler la charge de travail, délimiter le travail en aval | Manifeste de collecte, résultat des identifiants d'accès, dernier effet de bord connu |
| 1 à 4 heures | Sélectionner l'état réputé sain, Rollback, ouvrir les éléments de compensation, exécuter un canari contrôlé | Provenance du rétablissement, résultat du canari, registre de compensation |
| 4 à 8 heures | Reconstituer l'événement et classifier le préjudice, le rôle, la géographie et les régimes possibles | Chronologie versionnée, évaluation d'impact, liste des questions juridiques |
| 8 à 24 heures | Approuver les notifications, publier le premier point de situation, définir le plan de surveillance et d'enquête | Décision de déclaration, transmissions, information des parties prenantes, heure de la prochaine revue |
S'exercer sur les failles qui apparaissent sous pression
La sous-catégorie Manage 4 du NIST AI RMF demande des plans de réponse, de rétablissement et de communication documentés et suivis. Le plan de surveillance après commercialisation doit fournir les seuils, les responsabilités et les flux de preuves qui déclenchent ce playbook.
Menez des exercices pour une exécution active, une attente d'approbation, un identifiant d'accès volé, un effet de bord externe déjà exécuté, une source de journaux manquante, un fournisseur injoignable et un exportateur de preuves indisponible. Consignez le temps de confinement, le dernier effet de bord après la commande, les accusés de réception manquants, la complétude des preuves, le temps de rétablissement et le temps de décision de déclaration.
Utilisez le guide Autonomie responsable pour confirmer que la supervision ordinaire et l'autorité d'urgence ont des responsables nommés. Consultez l'analyse de l'incident Hugging Face pour un exemple public d'action à vitesse machine, de collecte d'identifiants d'accès, de mouvement latéral et de reconstitution à partir de plus de 17 000 événements enregistrés.
Foire aux questions
Quelle est la première action lors d'un incident d'agent IA ?
Déclarez un incident unique, désignez le commandant d'incident, le propriétaire du système, le responsable des preuves et le responsable juridique, consignez l'heure de prise de connaissance et placez le périmètre affecté en refus. Déclenchez les actionneurs du coupe-circuit tout en préservant l'état volatil de l'exécution, de l'identité, de la politique et de l'aval.
Comment contenir un agent IA hors de contrôle ?
Annulez les exécutions actives et sous approbation, refusez les nouveaux appels d'outils à un point d'application externe, désactivez l'identité de l'agent, révoquez les identifiants d'accès et effectuez leur rotation, isolez la charge de travail, annulez le travail en file d'attente et en aval, et gardez l'incident ouvert jusqu'à ce que chaque actionneur requis ait accusé réception.
Que signifie le rollback lors d'un incident d'agent IA ?
Restaurez la Release, la politique, le modèle, le prompt, le manifeste d'outils et la configuration de connecteurs antérieurs vérifiés, sous de nouveaux identifiants d'accès. Suivez chaque effet de bord externe déjà exécuté via une procédure de compensation, de correction ou de notification propre au système concerné.
Quand l'article 73 du règlement européen sur l'IA exige-t-il une déclaration ?
L'article 73 s'adresse aux fournisseurs de systèmes d'IA à haut risque mis sur le marché de l'Union lorsqu'un incident grave au sens de l'article 3, point 49, se produit. L'horloge de déclaration et l'autorité compétente dépendent de l'évaluation causale, du type d'incident, de l'État membre, du rôle, des chevauchements sectoriels et des dates d'application en vigueur. Un conseil juridique qualifié doit confirmer l'obligation propre au cas d'espèce.
Quels sont les délais de déclaration de l'article 73 ?
L'article 73 prévoit une déclaration immédiate après l'établissement d'un lien de causalité ou d'une probabilité raisonnable d'un tel lien, avec un plafond de 15 jours après la prise de connaissance. Une infraction de grande ampleur ou une perturbation grave et irréversible d'infrastructures critiques a un plafond de deux jours. Un décès a un plafond de dix jours et un déclencheur immédiat lorsque la causalité est établie ou soupçonnée. Un rapport initial incomplet est admis lorsque le respect des délais l'exige.
Quelles preuves un dossier d'incident d'agent IA doit-il contenir ?
Conservez les heures de détection et de prise de connaissance, les identifiants d'exécution et de Release, les versions de modèle et de prompt, les appels d'outils, les arguments, les décisions de politique, les approbations, les effets de bord, la commande de confinement et ses accusés de réception, les changements d'identifiants d'accès, les journaux préservés, la provenance du Rollback, les résultats de compensation, l'analyse juridique et les déclarations.
Points clés à retenir
Un playbook d'incident solide établit le contrôle avant que l'équipe ne tente d'expliquer l'événement. Arrêtez la capacité, préservez l'état, restaurez une Release vérifiée, réconciliez chaque effet déjà exécuté et prenez la décision de déclaration à partir d'un dossier de preuves versionné. Reliez le playbook à la surveillance après commercialisation et exercez-le jusqu'à ce que le temps de confinement, la complétude des preuves et l'état de rétablissement soient des faits mesurés.