Article 12 de la loi européenne sur l'IA
L'écart de preuve EU AI Act : ce que les vérificateurs exigeront réellement
Les organismes notifiés signalent déjà des attentes plus strictes
L'écosystème d'évaluation de la conformité s'est mobilisé autour de la date limite de désignation des organismes notifiés d'août 2025. TUV SUD a commencé à offrir des certificats volontaires de conformité AI Act en novembre 2025. Team-NB a mis en garde contre une pénurie potentielle d'organismes désignés avec une expertise AI. Ceux qui obtiennent une désignation appliqueront des normes rigoureuses.
L'Espagne AESIA regulatory sandbox a produit 16 guides d'exécution technique couvrant des méthodes de documentation spécifiques. Les participants reçoivent des « rapports de sortie » selon lesquels les évaluateurs de conformité doivent « tenir compte positivement », établissant un précédent précoce pour ce à quoi ressemble une documentation acceptable.
En vertu de Annex VII, les organismes notifiés disposeront de pouvoirs d'accès étendus : accès complet aux ensembles de données de formation via API, droits de test direct et, dans des cas exceptionnels, accès aux modèles formés eux-mêmes. Vos journaux d'accès aux ensembles de données deviendront des cibles d'audit.
Le modèle est clair : un texte vague devient une pratique stricte
Chaque régulation majeure suit la même trajectoire. Les exigences fondées sur les principes deviennent des attentes de vérification très précises d'ici 2 à 4 ans.
Ce que cela est devenu
- Divergence UTC 100 microsecondes (HFT)
- 1 milliseconde (trading algorithmique)
- Stockage WORM 5–7 ans
- Reconstruction des transactions en 72 h
Leçon clé
La précision temporelle est devenue 1 000 000x plus stricte
L’« enregistrement automatique des événements » de l’article 12 deviendra un logging à intégrité vérifiable, ancré cryptographiquement, dans les 2–4 ans suivant le début de l’application.
Comment d'autres règlements ont évolué de vague à prescriptive
Exigences initiales
"Contrôle interne adapté" (aucune définition)
Ce qu'il est devenu
Cadre du COSO: 17 principes, 87 points d'intérêt, 40 % des taux de déficience en matière d'audit
Le texte fondé sur des principes est devenu très normatif grâce à la pratique de la vérification
Exigences initiales
"Mesures techniques appropriées"
Ce qu'il est devenu
2FA maintenant attendu (Haga Hospital amende), procédures d'accès documentées nécessaires
Le principe de responsabilité fait de la documentation elle-même une exigence conformité
Exigences initiales
Prescriptions relatives à la documentation technique
Ce qu'il est devenu
CEI 62304 pistes d'audit, contrôle complet des versions, traçabilité des exigences aux essais
Les modèles d'instruments médicaux sont importés directement dans les attentes de la Loi sur l'IA
Ce que les vérificateurs se préparent à évaluer
Sur la base de prEN ISO/IEC 24970, prEN 18286 et de nouveaux grands 4 domaines de pratique, voici ce que l'évaluation de la conformité couvrira probablement.
- Événements opérationnels (entrées, sorties, décisions)
- Événements de surveillance automatisés (dérive, anomalies)
- Interventions de surveillance humaine (approbations, interventions)
Signaux techniques convergents dans les directives d'audit
Bien que ces modèles techniques ne soient pas explicitement mandatés, les vérificateurs poseront la question pratique suivante : comment prouver que ces registres n'ont pas été modifiés?
Chaînes cryptographiques
Chaque entrée de journal comprend un hachage de l'entrée précédente, créant des séquences falsifiées évidentes
Chaînes de hachage SHA-256 avec rouleaux d'arbres Merkle
Stockage WORM
Stockage Write-Once-Read-Many (WORM)
immudb, Amazon S3 Object Lock, Azure Immutable Blobs
Ancrages de l'horodatage
Des horodatages tiers indépendants prouvent qu'il existait des enregistrements à un moment précis
OpenTimestamps, RFC 3161 TSA, ancrage à chaîne de blocs
Architecture append-only
Les corrections deviennent des nouvelles versions liées plutôt que des écrasements
Approvisionnement en événements, registres immuables, bases de données de vérification-trail-native
Chaîne de données probantes : des opérations aux preuves prêtes à être vérifiées
Chaque étape produit des preuves qu'un vérificateur peut vérifier de manière indépendante et hors ligne.
Les auditeurs veulent prouver que votre QMS tourne (enregistrements) et que ces enregistrements sont fiables (preuves d’intégrité).
Où les équipes se trompent
- Attendre l'harmonisation des normes avant de mettre en œuvre les contrôles d'intégrité
- Traitement de la rétention de 6 mois comme suffisant lorsque les règles sectorielles exigent plus de temps
- L'journalisation existe mais l'intégrité n'est pas vérifiable (pas de hachage, pas de chaîne)
- Les journaux d'accès aux données sont manquants ou facilement modifiés
- Aucune preuve indépendante de l'existence de registres lorsqu'ils sont revendiqués
Intégrez des preuves à intégrité vérifiable dans vos opérations d'IA
KLA fournit pistes d'audit en ancrage cryptographique à partir du premier jour.
- registre adossé à immudb : stockage des preuves en ajout seul (append-only) ; chaque export est ancré au registre et l'enregistrement d'ancrage voyage dans le bundle
- ancrage OpenTimestamps : ancrage par lots sur Bitcoin chaque heure ; le bundle embarque le reçu OTS afin que l'horodatage puisse être confirmé sur la chaîne Bitcoin lorsque vous le décidez
- S3 Object Lock: conformité-mode stockage WORM pour la rétention de la charge utile brute
- Evidence Room exportations: paquets signés avec hashs par artefact et instructions de vérification
N'attendez pas des normes harmonisées. Bâtir les vérificateurs de l'architecture des preuves exigera.
Vérifier l'intégrité de la preuve avec le CLI :
# Verify evidence bundle integrity kla evidence verify --bundle ./evidence-export.zip # Export with full hash chain kla export evidence \ --tenant $KLA_TENANT_ID \ --days 30 \ --include-timestamps \ --format pdf
Ce que le vérificateur prouve
L'export Evidence Room inclut un vérificateur autonome qui contrôle un bundle sans accès réseau et sans infrastructure KLA. Hors ligne il prouve que le bundle est cohérent en interne : chaque entrée (données, preuves et clés publiques) provient du bundle lui-même.
Signature du manifeste
Le manifeste se canonicalise (RFC 8785 / JCS) et son digest se recalcule. Le JWS détaché porte des signatures ES256 SEK et TEK valides sur ce digest, vérifiées contre les clés publiques que le bundle intègre dans keys/jwks.json.
Inclusion Merkle
Chaque artefact se re-hache (SHA-256) vers le digest que déclare le manifeste, la preuve d'inclusion de chaque artefact atteint la racine scellée, et la racine Merkle recalculée égale la valeur du manifeste.
Signatures des reçus
Chaque chaîne de reçus de gouvernance se vérifie : la signature ed25519 de chaque reçu est validée contre une clé intégrée au bundle, et le prevReceiptHash de chaque étape relie l'étape précédente, de la genèse à la dernière.
Chaîne de hachage du registre
Chaque enregistrement de registre exporté se re-hache vers son hash déclaré, et les enregistrements consécutifs s'enchaînent via previousHash de bout en bout.
Ancrage OpenTimestamps
timestamp.ots s'analyse selon les règles strictes d'OpenTimestamps et s'engage sur le digest du manifeste recalculé. Quand le reçu est attesté sur Bitcoin, le vérificateur indique sa hauteur de bloc ; un reçu de calendrier en attente est accepté comme confirmation Bitcoin en attente.
Ce que la vérification hors ligne ne prouve pas
- L'authenticité exige une vérification de clés hors bande. Les signatures SEK, TEK et de reçus sont toutes vérifiées contre les clés que le bundle intègre dans keys/jwks.json, si bien que hors ligne le bundle prouve seulement sa cohérence interne. Pour prouver qu'il vient de KLA, épinglez ces clés contre un JWKS publié par KLA ou une empreinte de clé.
- L'ancrage Bitcoin d'OpenTimestamps est supposé fiable hors ligne. Confirmer sa hauteur de bloc compare la preuve à la chaîne Bitcoin en direct, et un reçu de calendrier en attente reste en attente jusqu'à une mise à jour du calendrier.
- La preuve de l'ancrage du registre immudb est présente et s'analyse hors ligne. Confirmer son inclusion contre l'état signé du registre exige une vérification en réseau.
FAQ
Article 12 exige-t-il explicitement une intégrité cryptographique?
Non, mais le modèle de MiFID II, SOX, GDPR et MDR est sans ambiguïté : le texte fondé sur des principes devient une pratique prescriptive dans les 2-4 ans. Les auditeurs et les organismes notifiés interpréteront l'"enregistrement automatique" comme signifiant l'enregistrement non conforme.
Quelles sont les périodes de conservation applicables aux registres d'IA?
Article 12 spécifie un minimum de 6 mois pour les registres automatisés, mais les exigences sectorielles l'emportent souvent. Les institutions financières devraient s'attendre à 5-7 ans. La documentation technique doit être conservée pendant 10 ans après la mise sur le marché du système.
Quand des normes harmonisées seront-elles publiées?
prEN ISO/IEC 24970 (norme d'inscription) figure dans le projet de bulletin de vote international standard. prEN 18286 (norme QMS) est entré en enquête publique en octobre 2025. Les normes finales s'attendaient au Q4 2026, mais les attentes des vérificateurs se forment maintenant.
Quel accès les organismes notifiés auront-ils?
En vertu de Annex VII, les organismes notifiés peuvent exiger un accès complet à la formation, à la validation et à l'essai des ensembles de données. Ils peuvent effectuer des tests directs s'ils ne sont pas satisfaits des preuves fournies par le fournisseur. Les journaux d'accès aux données deviendront eux-mêmes des cibles de vérification.
Comment devons-nous gérer l'auditabilité du modèle ML?
Les seuils pour l'enregistrement approfondi demeurent incertains, mais les vérificateurs s'attendent probablement à ce que les résultats soient suivis en version modèle, à ce que l'hyperparamètre change, à ce que la formation soit faite en métadonnées et à ce que les décisions soient traçables.
Ressources connexes
Continuez votre voyage EU AI Act conformité.
Le cadre d’audit d’entreprise place les tests d’intégrité dans la méthode d’audit complète ; l’évaluation de préparation identifie les lacunes de preuve et la page du logiciel d’audit des agents IA couvre l’évaluation de la plateforme.
Modèle Article 17 QMS
Modèle de système de gestion de la qualité pour l'IA à haut risque avec cartographie prEN 18286.
Aperçu de la sécurité
Architecture technique pour l'intégrité des preuves et la protection des données.
Démo d'exportation des preuves
Voyez comment des faisceaux de preuves vérifiables hors ligne sont générés.
N'attendez pas les normes pour rattraper
L'écart entre le texte de Article 12 et les attentes pratiques en matière d'audit se comblera rapidement. Les organisations qui prévoient des exigences plus strictes auront des avantages concurrentiels importants lorsque les évaluations de la conformité commenceront.