AI Act : quelles preuves exiger après les incidents examinés en octobre 2026 ?

Le 12 octobre 2026, la Commission européenne a publié le compte rendu d’une réunion spéciale consacrée aux risques des modèles d’IA avancés, tenue le 9 octobre. Le communiqué décrit des investigations sur des incidents de perte de contrôle et des recommandations scientifiques. Son intérêt pour une direction : relier la surveillance réglementaire aux preuves disponibles sur ses propres systèmes.

Un dossier de preuve IA rassemble la version du système, son périmètre d’usage, ses tests et les traces nécessaires pour expliquer une décision de déploiement. Cette définition opérationnelle guide l’analyse qui suit, rédigée le 19 octobre 2026 à partir des sources officielles. Les obligations applicables dépendent du rôle de l’entreprise et de l’usage considéré.

La réunion du 9 octobre a examiné des incidents de perte de contrôle et formulé des recommandations destinées à éclairer les actions de la Commission européenne.

Selon le compte rendu publié le 12 octobre, le Bureau de l’IA avait déjà demandé et reçu des rapports d’incidents graves. Des demandes d’informations sur les pratiques de sécurité avaient également été envoyées. La Commission annonce des questions complémentaires aux entreprises concernées.

Le panel recommande notamment de mieux gouverner les risques des modèles internes pendant leur développement et leurs essais, et de renforcer les capacités d’investigation. Le communiqué ne publie pas les dossiers techniques permettant d’attribuer une cause précise à chaque incident.

Pour une DSI, la conséquence pratique proposée ici consiste à vérifier ce qui peut être observé, expliqué et interrompu dans son propre déploiement. Le dossier de preuve d’une réponse IA donne un point de départ concret : conserver les éléments qui permettent de reconstruire une action.

Une recommandation du panel scientifique éclaire la décision publique ; une obligation réglementaire doit être rattachée à un texte applicable, à son destinataire et à son échéance.

Le communiqué d’octobre présente des investigations et des recommandations. Il n’annonce ni une modification générale du calendrier de l’AI Act ni une interdiction de tous les agents. Une demande d’informations adressée à un fournisseur relève d’une procédure déterminée ; elle ne transforme pas toutes les entreprises utilisatrices en destinataires de cette demande.

La distinction vaut aussi pour le train de simplification appelé AI Omnibus. La proposition de la Commission date du 19 novembre 2025 et l’accord politique du 7 mai 2026. Le règlement modificatif (UE) 2026/1744 a ensuite été publié au Journal officiel le 24 juillet 2026. La Commission confirme son entrée en vigueur le 27 juillet.

Une direction doit donc enregistrer le statut de chaque information : proposition, accord, acte publié ou mesure d’exécution. Ajouter l’article concerné et la date d’application évite de transformer un titre de presse en consigne d’exploitation.

Les obligations propres aux modèles d’IA à usage général présentant un risque systémique visent leurs fournisseurs ; les responsabilités d’une entreprise utilisatrice doivent être qualifiées séparément.

L’article 55 reproduit par le service officiel de la Commission prévoit notamment l’évaluation des modèles, les essais adversariaux documentés, l’évaluation et l’atténuation des risques systémiques, le suivi des incidents graves et une protection adaptée en cybersécurité. Ces obligations concernent la catégorie de fournisseurs définie par le texte.

Une entreprise qui consomme une API doit examiner son rôle pour le modèle et pour le système qu’elle exploite. Les notions de modèle à risque systémique et de système à haut risque ne sont pas interchangeables. La qualification d’un outil de recrutement dépend de sa destination et des critères applicables ; elle ne se déduit pas du seul nom du modèle.

La Commission décrit les compétences du Bureau de l’IA et des autorités nationales. En interne, reliez chaque responsabilité à un propriétaire, un contrat et une pièce vérifiable. La méthode pour écrire la fiche d’un système d’IA aide à stabiliser ce périmètre avant l’examen juridique.

Au 19 octobre 2026, les reports adoptés concernent certaines règles du haut risque ; la transparence et les nouvelles transitions doivent être suivies selon leurs dispositions propres.

Le règlement modificatif (UE) 2026/1744 doit être lu avec la version consolidée de l’AI Act au 27 juillet 2026. Le tableau reprend les jalons utiles à une revue de portefeuille, sous réserve des régimes transitoires propres à chaque système. Pour les produits, l’article 2, paragraphe 2, limite les dispositions directement applicables aux systèmes relevant de la section B de l’annexe I.

L’article 4 a également été réécrit : les fournisseurs et déployeurs doivent prendre des mesures pour favoriser la maîtrise de l’IA, sans garantir un niveau individuel spécifique. Présenter cette évolution comme un simple report de formation déforme le texte.

Les obligations des fournisseurs de modèles à usage général ont leur propre régime. L’article 111 prévoit notamment une échéance au 2 août 2027 pour les modèles mis sur le marché avant le 2 août 2025. Une date unique dans un tableau de direction ne suffit donc pas à qualifier tout le portefeuille.

La demande utile porte sur une version identifiable, les limites documentées, la gestion des incidents et les mécanismes de contrôle réellement accessibles dans le contrat retenu.

Demandez quel modèle et quelle configuration sont servis, comment les changements sont annoncés et quelles évaluations couvrent votre usage. Un document décrivant une autre version ne valide pas celle qui traite vos données. Reliez chaque limite déclarée à un scénario de votre recette, avec le résultat attendu et la preuve à conserver.

Vérifiez ensuite le circuit d’incident : interlocuteur, informations transmissibles, moyen de suspendre l’intégration et conditions de reprise. Distinguez les engagements contractuels, les fonctions disponibles dans votre offre et les obligations réglementaires effectivement applicables au fournisseur. Une mention commerciale de conformité ne répond pas à ces questions.

La méthode pour évaluer un fournisseur d’IA au-delà de ses capacités permet de structurer cette discussion. Pour chaque réponse importante, demandez une pièce datée ou une démonstration reproductible. Le refus ou l’impossibilité de produire une preuve doit devenir une réserve explicite dans la décision d’achat.

Une recette de contrôle doit vérifier les limites d’action, la résistance aux instructions externes, la visibilité des opérations et l’arrêt effectif dans les conditions du déploiement.

Le protocole suivant est une proposition de méthode technique. Il ne constitue ni une liste réglementaire exhaustive ni une certification. Utilisez un environnement isolé et des données de test, puis conservez les entrées, la configuration, les observations et les écarts.

1. Définir le périmètre. Inscrivez les outils autorisés, les données accessibles et les actions exigeant une validation. Un scénario doit provoquer une tentative d’action située hors de ce périmètre.
2. Éprouver les instructions externes. Placez dans un document de test une demande qui contredit les consignes de l’agent. Vérifiez que la chaîne d’outils conserve ses restrictions. Le guide sur l’injection indirecte de prompt précise les situations à examiner.
3. Tester les autorisations réelles. Retirez un droit ou utilisez un compte de test limité. Observez le refus effectif de l’opération, y compris lors des reprises et des appels successifs.
4. Interrompre une exécution. Déclenchez l’arrêt prévu et vérifiez les actions encore en attente. Documentez le traitement des opérations déjà engagées et les conditions de redémarrage.
5. Reconstruire le scénario. Faites relire les traces par une personne qui n’a pas conduit l’essai. Elle doit pouvoir retrouver les événements utiles et identifier les zones restées inconnues.

Définissez avant les essais les écarts qui bloquent le déploiement. La conception de la supervision humaine et l’observabilité des systèmes d’IA doivent rejoindre cette recette. Collectez des traces proportionnées, avec des règles d’accès et de conservation adaptées aux données concernées.

La décision doit relier chaque réserve à son effet métier, à un responsable et à une condition de levée, avec un périmètre d’exploitation explicitement autorisé.

Une action non autorisée, un arrêt inefficace ou une absence de traces justifie de réexaminer le périmètre permis. Selon le contexte, la réponse peut consister à retirer un outil, imposer une validation ou suspendre une fonction. Les tests réussis valent pour les conditions documentées ; une nouvelle version ou de nouveaux droits appellent une réévaluation ciblée.

Présentez à la direction les fonctions autorisées, les réserves ouvertes et les événements qui déclencheraient une suspension. Faites qualifier les obligations légales par les compétences appropriées. La recette technique apporte des faits pour cette analyse, sans trancher à elle seule la conformité juridique.

L’outil quel audit IA choisir aide à situer le besoin de vérification. Un audit IA de système existant peut ensuite cadrer le jeu de tests et le plan de correction. La priorité proposée : disposer d’éléments exploitables pour décider, puis maintenir ces éléments lorsque le système évolue.

Analyse et méthode proposées par Anand Candassamy au 19 octobre 2026.