Audit IA : le report de l'AI Act à 2027 ne vous rend pas les seize mois que vous croyez

Audit IA : le report de l'AI Act à 2027 ne vous rend pas les seize mois que vous croyez

Le 29 juin 2026, le Conseil de l'Union européenne a donné son feu vert final au paquet de simplification numérique, deux semaines après le vote du Parlement du 16 juin. Le texte, issu de l'accord provisoire du 7 mai entre les colégislateurs, reporte les obligations des systèmes IA à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027, et celles des systèmes intégrés à des produits réglementés au 2 août 2028.

Dans beaucoup de comités de direction, la lecture a été immédiate : seize mois de répit, le chantier conformité redescend dans la pile des priorités. Cette lecture est une erreur de calcul, pour une raison que les équipes qui ont déjà vécu un audit connaissent bien. Un audit ne vérifie pas ce que vous savez faire le jour du contrôle. Il vérifie ce que vos systèmes ont enregistré pendant les mois qui précèdent. Et cette matière-là ne se fabrique pas rétroactivement.

C'est le réflexe contre-intuitif à corriger en premier : un report de date d'application se lit presque toujours comme un report de charge de travail, alors qu'il ne reporte que la date à laquelle le régulateur peut sanctionner. Sur le terrain, les équipes conformité qui ont déjà traversé un premier audit RGPD reconnaissent le pattern immédiatement : les organisations qui ont pris ce type de report au pied de la lettre se sont retrouvées, au moment du contrôle, à documenter dans l'urgence des mois d'historique qui n'existaient pas.

Cet article fait le tri entre ce qui est réellement reporté et ce qui reste dû en 2026, détaille ce que les auditeurs vérifient dans la pratique, et propose quatre chantiers pour être prêt sans sur-investir.

Loupe d'audit posée sur une pile de documents avec une ligne de temps décalée vers la droite
Un report de date d'application ne reporte pas l'accumulation de preuves : logs, registres et documentation se constituent en continu, pas la veille du contrôle.

Ce qui est reporté, ce qui ne l'est pas

Le report ne couvre que les obligations liées aux systèmes à haut risque. Trois échéances restent actives et deux d'entre elles tombent dans les six prochains mois.

Les obligations de transparence de l'article 50 s'appliquent toujours au 2 août 2026, dans trois semaines. Elles concernent tout système qui interagit directement avec des personnes, génère du contenu synthétique ou pratique la reconnaissance d'émotions : l'utilisateur doit être informé qu'il interagit avec une IA, et les contenus générés doivent être identifiables comme tels. Le cabinet Covington notait fin mai 2026 que cette date restait « proche et bien réelle » malgré le report du haut risque.

Les interdictions de l'article 5, en vigueur depuis février 2025, s'élargissent. Le paquet adopté en juin ajoute une prohibition des systèmes générant des contenus intimes non consentis, applicable dès décembre 2026 selon le texte endossé par le Parlement.

Les obligations des fournisseurs de modèles à usage général, en application depuis août 2025, ne bougent pas non plus. Et le paquet de juin étend le périmètre de supervision de l'AI Office de la Commission sur les systèmes construits au-dessus de ces modèles, selon l'analyse de Gibson Dunn publiée après l'accord.

Autrement dit, une entreprise qui déploie un chatbot client, un générateur de contenu ou un agent conversationnel interne a des obligations exécutoires cette année, indépendamment de toute classification haut risque.

Pourquoi la traçabilité ne se rattrape pas

La partie reportée elle-même se prépare mal dans l'urgence, pour une raison de structure : les articles 9 à 15 du règlement exigent des preuves qui s'accumulent dans le temps.

L'article 12 impose des logs générés automatiquement, couvrant la traçabilité des décisions du système, avec une rétention minimale de six mois. Un système mis en conformité en novembre 2027 n'aura rien à montrer sur son comportement de 2026 et 2027, précisément la période que le régulateur voudra comprendre en cas d'incident signalé.

Le monitoring post-commercialisation exige un historique de performance : dérive des modèles, incidents, corrections apportées. Là encore, la donnée n'existe que si la collecte a commencé tôt.

Enfin, les organisations qui choisissent de s'appuyer sur ISO/IEC 42001, le standard certifiable de management des systèmes IA souvent utilisé pour démontrer une conformité structurée aux exigences des articles 9 à 15, doivent compter six à douze mois entre le lancement du chantier et la certification, selon les retours de terrain compilés par Schellman et Deloitte en 2026. Démarrer mi-2027 pour une échéance en décembre 2027 ne passe pas.

Le report change donc la date à laquelle le régulateur peut sanctionner. Il ne change pas la date à laquelle il faut commencer.

Ce que les auditeurs vérifient dans la pratique

Les guides d'audit publiés en 2026, dont le référentiel technique de Raconteur consacré à l'échéance AI Act et les checklists sectorielles de Kognitos pour la finance et la santé, convergent sur quatre zones de contrôle.

La première est l'inventaire. Avant toute vérification de fond, l'auditeur demande la liste des systèmes IA en production, leur classification de risque et la justification de cette classification. C'est le point de défaillance le plus fréquent : la plupart des organisations découvrent à cette étape des systèmes déployés hors de tout recensement, souvent introduits via des outils SaaS dont les fonctions IA ont été activées sans décision formelle.

La deuxième est la documentation technique. Pour chaque système classé à risque, l'auditeur attend une description des données d'entraînement et de leur provenance, des choix d'architecture, des métriques de performance et de leurs conditions de mesure. Pas un document marketing : une documentation qui permettrait à un tiers compétent de comprendre comment le système produit ses sorties.

La troisième est la traçabilité opérationnelle. L'auditeur ne se contente pas de lire la politique d'usage de l'IA, il teste si elle est techniquement appliquée. Les analyses de NeuralTrust sur les premiers audits de gouvernance IA relèvent que l'écart entre contrôles documentés et contrôles réellement en place est le premier motif de non-conformité : une politique qui interdit l'envoi de données clients vers des modèles externes, sans mécanisme qui bloque cet envoi, compte comme une absence de contrôle. C'est le même écart, entre permissions accordées sur le papier et permissions réellement exploitables, qui revient dans les incidents de sécurité agents documentés dans l'article sur le scoping d'accès des agents IA : un contrôle non vérifié techniquement n'existe pas, qu'il s'agisse d'un audit réglementaire ou d'un incident de sécurité.

La quatrième est la supervision humaine. Qui peut intervenir sur une décision du système, à quel moment, avec quelle information ? L'auditeur cherche des cas réels d'intervention, pas un schéma d'escalade théorique.

Les quatre zones de contrôle d'un audit IA avec la preuve attendue pour chacune
Les quatre zones de contrôle d'un audit IA et la preuve attendue pour chacune.

Quatre chantiers, dans cet ordre

La bonne réponse au report n'est ni l'arrêt du chantier ni le maintien d'un programme de conformité lourd calibré sur l'échéance d'août 2026. C'est un socle minimal qui accumule de la preuve en continu, dimensionné pour coûter peu tant que la classification finale des systèmes n'est pas arrêtée.

Le premier chantier est le registre des systèmes IA. Un inventaire unique, avec propriétaire identifié, finalité, données consommées, classification de risque provisoire et statut de déploiement. Il se construit en quelques semaines et conditionne tout le reste. Sans lui, impossible de savoir quels systèmes tomberont sous le régime haut risque en décembre 2027, ni lesquels sont déjà concernés par l'article 50 le mois prochain.

Le deuxième est la documentation produite au fil de l'eau. La documentation technique coûte cher quand elle est reconstituée a posteriori par des équipes qui n'ont pas construit le système. Elle coûte peu quand elle est un sous-produit du cycle de développement : fiche de données d'entraînement remplie au moment du choix du dataset, métriques d'évaluation archivées à chaque version, décisions d'architecture consignées quand elles sont prises.

Le troisième est le logging par conception. Chaque système en production devrait générer dès maintenant les traces que l'article 12 exigera : entrées, sorties, version du modèle, horodatage, intervention humaine éventuelle. Le coût marginal est faible sur un système instrumenté dès le départ, élevé sur un système à réinstrumenter. Et ces logs servent avant tout audit : ce sont les mêmes données qui alimentent la détection de dérive et l'analyse d'incidents.

Le quatrième est une gouvernance qui fonctionne à petite échelle. Un comité de revue qui examine réellement les nouveaux cas d'usage, un processus d'exception documenté, un registre de risques tenu à jour. Les organisations certifiées ISO 42001 en 2026 rapportent que la démonstration la plus difficile face à l'auditeur externe n'est pas l'existence du dispositif mais la preuve de son fonctionnement continu : des comptes rendus de décisions, des refus motivés, des risques suivis dans le temps.

À mettre en route cette semaine

Trois actions tiennent dans la semaine. Vérifier l'exposition à l'article 50 : lister les systèmes qui interagissent avec des personnes ou génèrent du contenu, et confirmer que l'information des utilisateurs et le marquage des contenus seront en place au 2 août. Lancer le registre des systèmes IA s'il n'existe pas, en commençant par un recensement déclaratif auprès des directions métier, quitte à l'affiner ensuite. Et arbitrer explicitement le calendrier de conformité haut risque en comité de direction, avec une position écrite : quels systèmes seront vraisemblablement classés haut risque, quand démarre la documentation, qui porte le budget.

Conclusion

Le report de décembre 2027 est une vraie détente de calendrier pour les sanctions. Il ne détend rien pour les systèmes eux-mêmes : chaque mois de production sans logs, sans documentation et sans registre est un mois de preuve qui n'existera jamais. Les entreprises qui l'ont compris utiliseront ces seize mois pour arriver au contrôle avec deux ans d'historique propre. Les autres arriveront en décembre 2027 exactement comme elles seraient arrivées en août 2026 : en reconstituant dans l'urgence ce qui aurait dû s'accumuler tout seul.


Sources : As of July 2026