OWASP Top 10 LLM 2026 : le guide côté conformité

L’OWASP Top 10 LLM a une nouvelle édition depuis le 3 août 2026, et jamais l’ordre de la liste n’avait autant bougé. Excessive Agency (autonomie excessive) grimpe à la troisième place, System Prompt Leakage devient Hidden Context Exposure, et le classement a été confronté pour la première fois à 7 714 incidents réels. La plupart des articles se contentent de réciter les dix entrées. Ce guide lit la liste comme le ferait un auditeur ou une autorité de surveillance du marché : ce qui a changé, comment le classement a été établi, quelles obligations européennes chaque entrée touche, quelles traces prouvent que vous l’avez traitée.

L’essentiel

• L’édition 2026 est parue le 3 août 2026. Huit entrées sur dix changent de rang ; seules Prompt Injection et Sensitive Information Disclosure restent en place.
• Le classement combine vote de praticiens (75 %) et relevé d’incidents (25 %) : le rang est un signal de consensus, pas un score de risque pour votre système.
• L’annexe A de l’OWASP Top 10 LLM renvoie à neuf référentiels de sécurité. Ni le règlement sur l’IA (AI Act) ni l’ISO/IEC 42001 n’y figurent.
• L’article 15(5) de l’AI Act cite empoisonnement des données, empoisonnement du modèle, exemples contradictoires, attaques de confidentialité et défauts du modèle : tous sont dans la liste.
• La liste est volontaire. La preuve ne l’est plus dès que l’AI Act, le règlement sur la cyberrésilience, le RGPD, NIS 2 ou DORA s’applique.

Qu’est-ce que l’OWASP Top 10 LLM ?

L’OWASP Top 10 LLM, de son titre officiel OWASP Top 10 for LLM Applications, est un document de sensibilisation communautaire qui nomme les dix risques de sécurité les plus critiques des applications bâties sur de grands modèles de langage (LLM). Il est tenu par l’OWASP GenAI Security Project, au sein de la fondation dont le Top 10 des applications web date de 2003. Voir aussi notre guide de la sécurité de l’IA. Quatre éditions de l’OWASP Top 10 LLM se sont succédé : la version 1.0 le 1er août 2023, la version 1.1 le 16 octobre 2023, l’édition 2025 le 18 novembre 2024, puis l’édition 2026 le 3 août 2026. Le document compte 122 pages, sous licence CC BY-SA 4.0. Chaque entrée suit le même plan : description, exemples, stratégies de prévention et d’atténuation, scénarios d’attaque. Selon notre décompte, les dix entrées totalisent 96 stratégies d’atténuation numérotées, de 3 pour Hidden Context Exposure à 19 pour Sensitive Information Disclosure. La lettre d’ouverture donne le ton : cessez de chercher un modèle qu’on ne peut pas tromper, bâtissez le système autour de lui de sorte qu’un modèle trompé ne casse rien d’important. Cette thèse d’architecture déplace le point de contrôle de l’éditeur du modèle vers l’équipe qui déploie l’application.

Un document de sensibilisation, pas un référentiel de contrôles

On ne se certifie pas sur l’OWASP Top 10 LLM : aucune exigence contraignante, aucun schéma de conformité, aucun auditeur accrédité. C’est un vocabulaire hiérarchisé : des noms communs pour ce qui tourne mal, assortis de défenses suggérées. Son intérêt pour la conformité : ingénieurs sécurité, testeurs d’intrusion, éditeurs et auditeurs emploient déjà ces noms. Un constat étiqueté LLM03 se lit de la même façon dans un rapport de red teaming, un questionnaire fournisseur et une note au comité des risques. Le périmètre est étroit : l’OWASP Top 10 LLM couvre le modèle en tant que composant de votre application. Quand il devient un acteur, avec des outils, une mémoire et des effets en aval, l’OWASP passe le relais à son Top 10 for Agentic Applications, annoncé le 9 décembre 2025.

La liste OWASP Top 10 LLM 2026 : ce qui a bougé

<table header-row= »true »> <tr> <td>ID 2026</td> <td>Entrée</td> <td>Rang 2025</td> <td>Ce qui change</td> </tr> <tr> <td>LLM01</td> <td>Prompt Injection (injection d’instructions)</td> <td>1</td> <td>Reste première. Ajoute les attaques multimodales (image, audio, vidéo) et les injections persistantes en mémoire ou dans un corpus RAG</td> </tr> <tr> <td>LLM02</td> <td>Sensitive Information Disclosure (divulgation d’informations sensibles)</td> <td>2</td> <td>Reste deuxième. Nouvelles surfaces : arguments d’appels d’outils, traces de raisonnement, journaux, embeddings, canaux auxiliaires temporels</td> </tr> <tr> <td>LLM03</td> <td>Excessive Agency (autonomie excessive)</td> <td>6</td> <td>Gagne trois places. Causes racines inchangées : fonctionnalités, permissions et autonomie excessives</td> </tr> <tr> <td>LLM04</td> <td>Supply Chain (chaîne d’approvisionnement)</td> <td>3</td> <td>Perd une place. Couvre aussi les modèles promus qui ne sont pas ce qu’ils prétendent être, les adaptateurs et les chaînes de conversion</td> </tr> <tr> <td>LLM05</td> <td>Data and Model Poisoning (empoisonnement des données et du modèle)</td> <td>4</td> <td>Perd une place. Absorbe le détournement du fine-tuning et l’empoisonnement par l’ingestion RAG</td> </tr> <tr> <td>LLM06</td> <td>Unbounded Consumption (consommation non bornée)</td> <td>10</td> <td>Gagne quatre places. Recentrée sur l’asymétrie des coûts : modèles de raisonnement, entrées multimodales, boucles d’agents</td> </tr> <tr> <td>LLM07</td> <td>Misinformation (informations erronées)</td> <td>9</td> <td>Gagne deux places, tirée par le relevé d’incidents</td> </tr> <tr> <td>LLM08</td> <td>Hidden Context Exposure (exposition du contexte caché)</td> <td>7</td> <td>Ex-System Prompt Leakage, élargie aux textes de politique récupérés, aux schémas d’outils et à tout contexte caché</td> </tr> <tr> <td>LLM09</td> <td>Vector and Embedding Weaknesses (faiblesses des vecteurs et embeddings)</td> <td>8</td> <td>Perd une place. Inclut la mémoire d’agent vectorielle et les caches sémantiques</td> </tr> <tr> <td>LLM10</td> <td>Improper Output Handling (traitement inadéquat des sorties)</td> <td>5</td> <td>Perd cinq places, la plus forte chute. Ajoute caractères de contrôle de terminal, moteurs de rendu à chargement automatique et code généré non sécurisé</td> </tr> </table> Trois enseignements se dégagent de l’OWASP Top 10 LLM 2026. Le dommage passe par la capacité d’agir. Pour l’OWASP, la montée d’Excessive Agency est le mouvement le plus lourd de conséquences de la liste : vote et relevé d’incidents concordent. Un assistant qui répond peut induire en erreur ; un assistant qui envoie des courriels ou émet un remboursement peut exécuter une instruction manipulée. Les trois causes racines font une grille de revue : l’application a-t-elle des outils dont elle n’a pas besoin, des permissions plus larges que la tâche, ou la faculté d’agir sans supervision humaine ? Les identifiants ont changé de sens. Les dix noms restent familiers, les numéros non. LLM03 désignait Supply Chain en 2025 et désigne Excessive Agency en 2026 ; LLM06 désignait Excessive Agency, c’est désormais Unbounded Consumption. Tout registre des risques, plan de test ou questionnaire fournisseur qui cite un identifiant nu est devenu ambigu. Écrivez l’année avec l’identifiant (LLM03:2026) et recodez les documents antérieurs. Le contexte caché est présumé découvrable. LLM08 demande de concevoir comme si le prompt système, les textes de politique récupérés et les schémas d’outils pouvaient être extraits : aucun identifiant de connexion dans le prompt, jamais d’instructions cachées comme unique contrôle d’autorisation. La question de test : si toute la fenêtre de contexte fuitait demain, qu’y gagnerait un attaquant ?

Comment le classement 2026 a été construit : un vote confronté aux incidents

Jusqu’ici, chaque édition de l’OWASP Top 10 LLM reposait sur le seul jugement des praticiens. Pour 2026, l’équipe du projet a réuni 7 714 incidents issus de bases publiques de vulnérabilités et d’une base de préjudices liés à l’IA, construit des classifieurs pour les lire, et en a classé 6 639. L’ordre final pèse le vote de la communauté pour trois quarts, les données d’incidents pour un quart. Les deux sources divergent à des endroits instructifs :

• Prompt Injection. Première au vote, hors des dix premières au seul relevé brut d’incidents. L’OWASP y lit un effet de la défense : les équipes combattent l’injection, donc moins d’exploitations nettes atteignent une base publique. L’exposition reste réelle, comme l’a montré CVE-2025-32711, une faille « zéro clic » dans un assistant en production.
• Misinformation. Bas de liste au vote, haut de liste au relevé : l’écart le plus large. Elle atterrit septième.
• Sensitive Information Disclosure. Le seul endroit, en haut du classement, où conviction et faits concordent.

Pour un registre des risques, trois conséquences comptent plus que le classement.

1. Le rang n’est pas la gravité pour votre système. Un assistant client sans outils est peu exposé à LLM03, un agent interne doté de droits d’écriture l’est beaucoup. Cotez chaque entrée selon votre architecture.
2. Les décomptes publics sous-estiment les risques bien défendus. La note de recherche de la Cloud Security Alliance du 15 août 2026 le rappelle : l’absence d’incidents ne prouve pas l’absence de risque.
3. Misinformation devient une entrée de sécurité, plus seulement un sujet de qualité. Quand une réponse fausse déclenche un appel d’outil, l’erreur devient une action erronée. L’OWASP Top 10 LLM rejoint ici les obligations d’exactitude, sujet de notre article sur l’hallucination, risque majeur de l’IA générative.

Ce que l’OWASP Top 10 LLM ne cartographie pas : l’AI Act et l’ISO/IEC 42001

L’annexe A de l’OWASP Top 10 LLM 2026 regroupe les correspondances avec neuf référentiels, chacun figé à une version : l’OWASP Top 10 for Agentic Applications, l’OWASP GenAI Data Security 2026, MITRE ATLAS, MITRE ATT&CK, CWE, le NIST AI 600-1, le NIST AI RMF, la CSA AI Controls Matrix et l’OWASP AI Vulnerability Scoring System. Aucun n’est le règlement sur l’IA (AI Act) ni l’ISO/IEC 42001. L’AI Act n’est cité que trois fois en 122 pages, toujours autour de LLM02, et l’une de ces mentions date encore les obligations des systèmes à haut risque d’août 2026, échéance que l’omnibus numérique, règlement (UE) 2026/1744, a repoussée au 2 décembre 2027 pour les systèmes de l’annexe III. Ce n’est pas un défaut pour un document de sécurité, mais un vide pour qui doit montrer à un régulateur en quoi ce travail répond à une obligation légale. Le pont est court. L’article 15, paragraphe 5, de l’AI Act exige que les systèmes d’IA à haut risque résistent aux tentatives de tiers non autorisés de modifier leur utilisation, leurs sorties ou leur performance, et énumère les vulnérabilités propres à l’IA : empoisonnement des données, empoisonnement du modèle, exemples contradictoires ou évasion du modèle, attaques de confidentialité, défauts du modèle. Chacune a sa place dans l’OWASP Top 10 LLM. Le tableau ci-dessous est notre lecture, pas une correspondance établie par l’OWASP ou la Commission. <table header-row= »true »> <tr> <td>Entrée</td> <td>Ancrage dans l’AI Act</td> <td>Preuves qu’un auditeur demande</td> </tr> <tr> <td>LLM01 Prompt Injection</td> <td>Art. 15(5), entrées adverses ; art. 55(1)(a), essais contradictoires</td> <td>Rapport de test par version face à des attaquants informés de la défense ; inventaire des canaux d’entrée non fiables</td> </tr> <tr> <td>LLM02 Sensitive Information Disclosure</td> <td>Art. 15(5), attaques de confidentialité ; art. 10 ; RGPD, art. 32</td> <td>Classification des données par source de contexte ; tests de masquage ; procédure en cas de divulgation</td> </tr> <tr> <td>LLM03 Excessive Agency</td> <td>Art. 14, supervision humaine ; art. 26, obligations du déployeur</td> <td>Registre des outils et permissions par application ; règle d’approbation des actions à fort impact ; journaux des appels d’outils</td> </tr> <tr> <td>LLM04 Supply Chain</td> <td>Art. 25, chaîne de valeur ; art. 15(5), composants préentraînés</td> <td>Provenance des modèles et jeux de données ; inventaire de composants signés ; évaluations fournisseurs</td> </tr> <tr> <td>LLM05 Data and Model Poisoning</td> <td>Art. 10, gouvernance des données ; art. 15(5), empoisonnement</td> <td>Lignage des jeux de données ; validation du fine-tuning et de l’ingestion RAG ; approbation des réentraînements</td> </tr> <tr> <td>LLM06 Unbounded Consumption</td> <td>Art. 15(4), résilience aux erreurs et défaillances</td> <td>Plafonds de dépense ; limites de débit ; tests des disjoncteurs ; alertes de coût</td> </tr> <tr> <td>LLM07 Misinformation</td> <td>Art. 15(1) et (3), exactitude déclarée ; art. 14(4)(b), biais d’automatisation</td> <td>Métriques d’exactitude et d’ancrage dans les sources ; résultats d’évaluation ; consignes contre l’excès de confiance</td> </tr> <tr> <td>LLM08 Hidden Context Exposure</td> <td>Art. 15(5), attaques de confidentialité</td> <td>Recherche de secrets dans les prompts et schémas d’outils ; preuve que l’autorisation s’applique hors du modèle</td> </tr> <tr> <td>LLM09 Vector and Embedding Weaknesses</td> <td>Art. 10 ; art. 15(5) ; RGPD, art. 32</td> <td>Tests d’isolation entre clients à la récupération ; journal de provenance de l’ingestion ; procédure de suppression des embeddings</td> </tr> <tr> <td>LLM10 Improper Output Handling</td> <td>Art. 15(5), défauts du modèle ; annexe I du règlement sur la cyberrésilience</td> <td>Tests d’encodage des sorties ; inventaire des destinations en aval ; dossiers de développement sécurisé</td> </tr> </table> Côté ISO/IEC 42001, les mêmes pièces se rangent dans le système de management, sous les mesures de l’annexe A relatives au cycle de vie du système d’IA (vérification et validation, exploitation et surveillance, journaux d’événements), aux données (qualité, provenance), aux relations avec les tiers et les clients, et à l’utilisation des systèmes d’IA. Un auditeur de certification ne demandera pas si vous êtes « conforme OWASP ». Il demandera comment vous avez identifié les risques de sécurité de l’IA et ce que vous avez décidé pour chacun. Une fiche de décision par entrée y répond.

Quel texte rend ces preuves exigibles

L’OWASP Top 10 LLM est volontaire. Ce qu’il décrit cesse de l’être dès que l’un de ces régimes vous concerne.

• AI Act, article 15. Il vise les systèmes d’IA à haut risque. Depuis l’omnibus numérique, ceux de l’annexe III doivent s’y conformer à partir du 2 décembre 2027, les produits de l’annexe I à partir du 2 août 2028.
• AI Act, article 55. Les fournisseurs de modèles d’IA à usage général présentant un risque systémique doivent réaliser et documenter des essais contradictoires, et assurer une protection de cybersécurité adéquate du modèle et de son infrastructure physique (article 55). Ces obligations s’appliquent depuis le 2 août 2025 ; les pouvoirs de contrôle de la Commission courent depuis le 2 août 2026.
• Règlement sur la cyberrésilience. Le règlement (UE) 2024/2847 vise les produits comportant des éléments numériques, donc la plupart des logiciels commerciaux qui embarquent un modèle de langage. Depuis le 11 septembre 2026, les fabricants signalent vulnérabilités activement exploitées et incidents graves, via la plateforme de signalement unique, au CSIRT coordinateur et à l’ENISA : alerte précoce sous 24 heures, notification sous 72 heures (synthèse de Jones Day). Les exigences essentielles s’appliquent en totalité à partir du 11 décembre 2027. Selon son article 12, un système d’IA à haut risque qui y satisfait est réputé conforme à l’exigence de cybersécurité de l’article 15 de l’AI Act.
• RGPD, article 32. La sécurité du traitement vaut pour toute application qui touche des données personnelles. LLM02 et LLM09 décrivent des violations de données avant qu’elles ne se produisent.
• NIS 2 et DORA. Entités essentielles et importantes (NIS 2) et entités financières (DORA) doivent déjà gérer les risques et notifier les incidents de leurs systèmes d’information, applications LLM comprises. DORA s’applique depuis le 17 janvier 2025.

Deux dates tombent à neuf jours d’écart : le 2 décembre 2027 pour les systèmes à haut risque de l’annexe III, le 11 décembre 2027 pour l’application complète du règlement sur la cyberrésilience. Un seul dossier de sécurité, structuré par entrée de l’OWASP Top 10 LLM et renvoyant aux deux règlements, prépare les deux échéances. La norme harmonisée sur la cybersécurité de l’IA était encore en préparation au CEN-CENELEC à la mi-2026 : une taxonomie publique et reconnue reste, pour l’instant, la structure la plus défendable. En France, le repère est l’ANSSI, qui a publié le 29 avril 2024 ses 35 recommandations de sécurité pour un système d’IA générative. L’agence est aussi le CSIRT côté français pour les signalements du règlement sur la cyberrésilience, et la CNIL l’interlocuteur pour l’article 32 du RGPD.

De l’OWASP Top 10 LLM à la preuve : une méthode en six étapes

1. Inventoriez chaque application à base de modèle de langage. Consignez le modèle, les sources de contexte, les outils, les mémoires et les destinations en aval. Sans inventaire des systèmes d’IA, personne ne sait quelles entrées sont dans le périmètre. L’AI Registry d’AI Sigil tient cette fiche système par système.
2. Décidez de l’applicabilité, entrée par entrée. Écrivez « applicable », ou « non applicable » avec le motif. L’OWASP note qu’un système de recherche documentaire sans vecteurs n’offre aucune surface à LLM09. Un rejet consigné est une preuve, un silence est une lacune.
3. Choisissez les mesures et nommez un responsable. Puisez dans les 96 stratégies de l’OWASP Top 10 LLM, rattachez chacune à un contrôle existant, désignez la pièce qui en atteste.
4. Testez avant la mise en production et après chaque changement. Nouvelle version de modèle, prompt système, outil ou corpus documentaire : chacun rouvre LLM01, LLM03 et LLM08. L’OWASP demande des tests face à des attaquants adaptatifs, qui ont lu la défense déployée. Voir notre guide du red teaming de l’IA.
5. Inscrivez la chaîne d’approvisionnement dans le contrat. LLM04 et LLM05 ne se ferment pas par le test seul. Provenance, signature, notification des vulnérabilités et des changements relèvent de la due diligence des fournisseurs d’IA.
6. Fixez à l’avance les seuils d’incident et les délais. Décidez ce qui constitue un incident grave au sens de l’article 73 de l’AI Act (signalement des incidents d’IA), une vulnérabilité activement exploitée au sens du règlement sur la cyberrésilience, une violation de données au sens du RGPD, et qui déclare sous 24 ou 72 heures.

Chaque étape laisse une trace, et l’ensemble forme une déclaration d’applicabilité pour le risque lié aux modèles de langage : dix entrées, une décision, un contrôle, un responsable, un résultat de test. C’est ce dossier qui fait passer l’OWASP Top 10 LLM de l’affiche au mur à la preuve d’audit.

OWASP Top 10 LLM ou Top 10 agentique : quelle liste s’applique

L’OWASP trace la frontière selon le rôle. Modèle composant, qui renvoie du texte à votre code : l’OWASP Top 10 LLM s’applique. Modèle acteur, qui appelle des outils, garde une mémoire et déclenche des effets en aval : l’OWASP Top 10 for Agentic Applications s’applique aussi. L’annexe A relie chaque entrée LLM à ses équivalents agentiques ; Excessive Agency y réapparaît sous ASI02 Tool Misuse and Exploitation, ASI03 Identity and Privilege Abuse et ASI08 Cascading Failures. La plupart des déploiements en entreprise sont sur la frontière. Un assistant reçoit un connecteur, puis un deuxième, puis un accès en écriture, et personne ne reprend l’analyse de risques. Deux vérifications aident.

• Consignez trois attributs par application : outils, mémoire persistante, capacité d’agir sans approbation. Dès que l’un change, appliquez les deux listes.
• Posez avant tout déploiement la question du « trio fatal » (lethal trifecta), que l’OWASP reprend de Simon Willison : données privées, contenu non fiable et communication vers l’extérieur réunissent les conditions d’une exploitation à fort impact. Retirez une branche, et elles disparaissent.

L’approbation humaine est le contrôle auquel l’OWASP revient le plus, et celui auquel il se fie le moins à fort volume : la lassitude d’approbation émousse le jugement. C’est un problème de conception de la supervision humaine, pas une case à cocher. Voyez notre guide des agents IA autonomes et la comparaison IA agentique vs IA générative. L’ANSSI et le BSI allemand ont publié ensemble six principes de conception Zero Trust pour les systèmes fondés sur des LLM, de l’authentification au bac à sable.

Questions fréquentes

Qu’est-ce que l’OWASP Top 10 LLM, en termes simples ? L’OWASP Top 10 LLM est la liste classée des dix risques de sécurité les plus critiques des applications fondées sur de grands modèles de langage, rédigée par l’OWASP GenAI Security Project. Chaque entrée explique la défaillance, donne des exemples et propose des défenses. Les équipes sécurité s’en servent pour cadrer leurs tests, les éditeurs pour décrire leur couverture, les auditeurs comme vocabulaire de référence. Qu’est-ce qui change dans l’OWASP Top 10 LLM en 2026 ? Huit entrées sur dix changent de rang. Excessive Agency passe de la sixième à la troisième place, Unbounded Consumption de la dixième à la sixième, Misinformation de la neuvième à la septième ; Improper Output Handling recule de la cinquième à la dixième. System Prompt Leakage est rebaptisée Hidden Context Exposure. La méthode change aussi : le vote des praticiens pèse 75 %, un relevé de 7 714 incidents 25 %. L’OWASP Top 10 LLM est-il obligatoire ? Non. C’est un document de sensibilisation volontaire. Les risques qu’il nomme relèvent en revanche de règles contraignantes : article 15 de l’AI Act pour les systèmes à haut risque, article 55 pour les modèles à usage général présentant un risque systémique, règlement sur la cyberrésilience pour les produits comportant des éléments numériques, article 32 du RGPD pour les données personnelles. Structurer vos preuves selon l’OWASP Top 10 LLM est un choix. Les détenir n’en est pas un. Quel lien entre l’OWASP Top 10 LLM et l’AI Act ? L’OWASP Top 10 LLM ne contient aucune correspondance avec l’AI Act. L’ancrage le plus proche est l’article 15, paragraphe 5 : empoisonnement des données, empoisonnement du modèle, exemples contradictoires, attaques de confidentialité, défauts du modèle. Soit, dans l’ordre, LLM05, LLM04, LLM01, LLM02 avec LLM08 et LLM09, et LLM10. Excessive Agency se rattache à la supervision humaine de l’article 14, Misinformation aux niveaux d’exactitude que l’article 15 impose aux fournisseurs de déclarer. L’injection de prompt est-elle toujours le risque numéro un ? Oui, au vote. Dans l’OWASP Top 10 LLM 2026, Prompt Injection garde la première place grâce aux praticiens. D’après les seules données publiques d’incidents, elle sortirait des dix premières : selon l’OWASP, les équipes contiennent les tentatives avant qu’elles ne deviennent déclarables. Le NCSC britannique l’explique dans sa note l’injection de prompt n’est pas une injection SQL : les modèles ne séparent pas les instructions des données. La surface ne peut pas être fermée, seulement contenue. Quelle différence entre l’OWASP Top 10 LLM et le Top 10 agentique ? L’OWASP Top 10 LLM traite le modèle comme un composant d’une application. La liste agentique, annoncée le 9 décembre 2025, le traite comme un acteur autonome, doté d’outils, d’une mémoire et d’effets en aval. Les deux sont conçues pour être utilisées ensemble. Si votre application peut appeler des outils ou agir sans qu’un humain valide chaque étape, lisez les deux, et reprenez l’analyse à chaque nouvel outil.

Conclusion

L’OWASP Top 10 LLM est le vocabulaire le plus partagé pour la sécurité des modèles de langage, et l’édition 2026 l’a rendu plus honnête en confrontant les convictions à un relevé d’incidents. Il reste un document de sécurité : il ne dit pas quel texte s’applique, à quelle date, ni ce qu’un régulateur demandera à voir. Cette part vous revient : un inventaire, une décision par entrée, un contrôle et un responsable nommés, un résultat de test après chaque changement, des délais d’incident convenus à l’avance. Les signalements du règlement sur la cyberrésilience sont déjà en vigueur, et décembre 2027 apporte à la fois les obligations des systèmes à haut risque et les exigences produit complètes. AI Sigil relie chaque application à base de modèle de langage du registre à ses entrées applicables, aux contrôles retenus, aux résultats de test et aux décisions d’incident : la réponse à un auditeur est un rapport, pas une reconstitution.