AI Act au 2 août 2026 : la feuille de route exacte pour les acteurs de l’assurance

Ce qu’il faut retenir

• Le 2 août 2026 n’est plus la date d’application des obligations relatives aux systèmes à haut risque de l’annexe III : l’AI Omnibus, entré en vigueur le 27 juillet 2026, les a reportées au 2 décembre 2027.
• Cette date reste pourtant opérationnelle : l’article 50 sur la transparence devient applicable et l’exécution des règles déjà applicables commence au niveau national et européen.
• En assurance, un système n’est pas classé en bloc parce qu’il contient de l’IA. Il faut qualifier chaque finalité, le rôle de l’organisation dans la chaîne et la population affectée.
• La tarification et l’évaluation du risque en assurance vie et santé pour des personnes physiques restent dans le périmètre haut risque de l’annexe III, mais leur échéance est désormais le 2 décembre 2027.
• Le bon livrable n’est pas une politique générale : c’est un registre versionné reliant chaque système à son rôle, ses obligations déjà applicables, ses prochaines échéances, ses preuves et son responsable.

Lire le calendrier avec trois horloges, pas une seule date

Une feuille de route exacte commence par corriger une ambiguïté devenue critique fin juillet 2026. Le règlement européen sur l’intelligence artificielle reste applicable par étapes, mais l’AI Omnibus a modifié certaines échéances quelques jours avant le 2 août. La frise officielle du service d’assistance AI Act distingue désormais trois horloges utiles aux acteurs de l’assurance.

Horloge	État au 12 août 2026	Conséquence pratique
Règles déjà applicables	Interdictions et dispositions générales depuis février 2025 ; gouvernance et obligations visant les fournisseurs de modèles d’IA à usage général depuis août 2025	Vérifier l’exposition actuelle et conserver les preuves, sans attendre un projet haut risque
Bascule du 2 août 2026	Transparence de l’article 50, mesures d’innovation et démarrage de l’exécution pour les règles applicables	Recetter les interfaces, marquages et canaux de contrôle qui sont en production aujourd’hui
Obligations haut risque différées	Annexe III le 2 décembre 2027 ; systèmes intégrés aux produits réglementés de l’annexe I le 2 août 2028	Utiliser le délai pour constituer données, documentation, surveillance et gouvernance, pas pour reporter l’inventaire

La Commission indique que l’AI Omnibus est entré en vigueur le 27 juillet 2026. Son calendrier reporte les règles applicables aux systèmes haut risque de l’annexe III au 2 décembre 2027 et celles concernant les produits de l’annexe I au 2 août 2028. Présenter encore le 2 août 2026 comme l’échéance générale de conformité haut risque serait donc inexact.

Ce qui change réellement le 2 août 2026

Le report ne crée pas une année blanche. Selon la communication de la Commission du 31 juillet 2026, l’Office de l’IA et les autorités nationales commencent à exécuter les règles applicables à compter du 2 août. Le même jour, les obligations de transparence de l’article 50 entrent en application.

Pour un assureur, une mutuelle, un courtier ou un délégataire, quatre contrôles méritent une recette séparée. Le terme « transparence » recouvre en effet des obligations différentes selon que l’organisation fournit le système ou le déploie.

Situation	Contrôle attendu	Preuve exploitable
Agent conversationnel en contact direct avec un client	La personne est informée qu’elle interagit avec un système d’IA, au bon moment et dans un format accessible	Capture versionnée du parcours, texte affiché, règle de déclenchement et test d’accessibilité
Système produisant ou modifiant un contenu synthétique	Le fournisseur rend la sortie détectable par un marquage lisible par machine, sous réserve des exceptions applicables	Spécification du marquage, échantillon généré et résultat d’un test de détection
Utilisation d’un système de reconnaissance des émotions ou de catégorisation biométrique	La personne exposée reçoit l’information prévue ; il faut aussi vérifier que l’usage n’entre pas dans une pratique interdite	Qualification juridique de la finalité, écran d’information et journal de version
Publication d’un hypertrucage ou de certains textes d’intérêt public	Le déployeur affiche la divulgation requise en tenant compte des exceptions, notamment celles liées au contrôle humain ou éditorial	Règle éditoriale, emplacement du label et validation d’un échantillon avant diffusion

Les lignes directrices de la Commission sur l’article 50, mises à jour le 6 août 2026, distinguent précisément obligations des fournisseurs et obligations des déployeurs. Elles rappellent aussi l’existence d’exceptions. Une mention ajoutée indistinctement à toutes les pages ne démontre donc pas la conformité : elle peut être trop tardive, viser le mauvais acteur ou ne pas couvrir le marquage technique.

Le sujet est approfondi dans l’analyse dédiée aux lignes directrices de transparence pour les IA en assurance. Dans la feuille de route globale, le point important est de transformer chaque exigence applicable en cas de test : qui voit l’information, à quel moment, dans quelle langue, après quelle mise à jour et avec quelle possibilité d’escalade humaine ?

Ce qui est reporté pour l’assurance vie et santé — et ce qui ne l’est pas

L’annexe III vise les systèmes d’IA destinés à l’évaluation du risque et à la tarification concernant des personnes physiques en assurance vie et santé. L’EIOPA le rappelle dans sa communication du 6 août 2025. Depuis l’AI Omnibus, les règles propres à cette catégorie haut risque doivent être préparées pour le 2 décembre 2027, et non pour le 2 août 2026.

Trois erreurs de périmètre restent fréquentes :

• Étendre la qualification à toute l’assurance. Un outil de résumé de courriels ou d’aide à la recherche n’est pas automatiquement haut risque au seul motif qu’il est utilisé chez un assureur.
• Réduire la qualification au nom du produit. Une même brique peut être hors du périmètre dans un parcours documentaire et y entrer si sa finalité devient l’évaluation du risque d’une personne en vie ou santé.
• Confondre report et absence de contrôle. Le droit des données personnelles, les règles sectorielles, la sécurité et les engagements contractuels continuent de s’appliquer selon le système concerné.

L’Opinion de l’EIOPA sur la gouvernance et la gestion des risques liés à l’IA traite les systèmes couverts par la réglementation sectorielle et exclut de son propre périmètre les systèmes interdits ou haut risque afin d’éviter un chevauchement. Elle met néanmoins en avant des thèmes déjà familiers aux assureurs : gouvernance des données, tenue des registres, équité, cybersécurité, explicabilité et supervision humaine. La préparation AI Act peut donc réutiliser des contrôles existants, à condition de relier chaque preuve à l’exigence et au système exacts.

Qualifier le rôle avant de chercher l’obligation

Le même acteur peut être déployeur sur un service et fournisseur sur un autre. Acheter une solution standard, développer un composant en interne, commercialiser une offre en marque blanche ou modifier substantiellement une finalité ne produisent pas la même analyse. Le contrat commercial ne suffit pas à décider du rôle réglementaire.

Pour chaque système, la revue doit répondre dans cet ordre :

1. Quelle est la finalité prévue ? Décrire l’action réelle : informer, classer, recommander, évaluer un risque, fixer un prix, détecter une fraude ou préparer une décision.
2. Qui met le système sur le marché ou en service sous son nom ? Identifier le fournisseur et les changements opérés par les acteurs aval.
3. Qui l’utilise sous son autorité ? Nommer le déployeur, les utilisateurs professionnels et les personnes affectées.
4. Quelle catégorie peut s’appliquer ? Pratique interdite, transparence, modèle d’IA à usage général, haut risque de l’annexe III, produit de l’annexe I ou régime sans obligation spécifique AI Act.
5. Quelles autres règles restent pertinentes ? Ajouter les contrôles RGPD, assurance, distribution, sécurité et consommation sans les fusionner artificiellement avec l’AI Act.

Cette qualification doit être approuvée par les fonctions compétentes, pas générée automatiquement. Pour délimiter ce que le système peut proposer, calculer ou seulement préparer, la grille des trois niveaux de contrôle d’une décision automatisée en assurance fournit un complément opérationnel.

Construire le registre qui pilote réellement la conformité

Un inventaire de noms d’outils est insuffisant. La maille utile est le système dans une finalité et une version données. Un tableur peut amorcer le travail, mais son schéma doit permettre de répondre à une question d’audit sans reconstruire le dossier à partir des courriels.

Chaque ligne du registre devrait contenir au minimum :

• un identifiant stable, le propriétaire métier et le service technique ;
• la finalité prévue, les usages explicitement exclus et les populations concernées ;
• les rôles fournisseur, déployeur, importateur ou distributeur lorsqu’ils sont pertinents ;
• la qualification AI Act datée, son raisonnement, sa source et son valideur ;
• les modèles, composants, versions et contrats amont indispensables ;
• les obligations déjà applicables, la prochaine échéance et le responsable de chaque contrôle ;
• les preuves disponibles, leur emplacement, leur date de validité et le prochain test ;
• les incidents, changements substantiels, exceptions et décisions de suspension.

Un changement de finalité, de modèle, de jeu de données, de canal ou de population déclenche une nouvelle qualification. L’équipe ne modifie pas l’ancienne ligne : elle crée une version et conserve le lien avec la décision précédente. Cette chronologie évite d’appliquer en 2027 une analyse réalisée sur un système qui n’existe plus.

La feuille de route exacte en quatre horizons

Horizon 1 — maintenant : sécuriser le 2 août 2026

• Relire les systèmes en contact direct avec des personnes et les flux de contenus synthétiques au regard de l’article 50.
• Vérifier les règles déjà applicables, les canaux de plainte et la capacité à produire rapidement la documentation demandée par une autorité compétente.
• Réouvrir les calendriers haut risque antérieurs au 27 juillet 2026 et remplacer les anciennes dates par les échéances issues de l’AI Omnibus.
• Geler un export du registre, des versions déployées et des preuves de recette au jour du contrôle.

Horizon 2 — le prochain trimestre : obtenir une classification défendable

• Réconcilier achats, sécurité, architecture, data, juridique et métiers pour découvrir les usages non inscrits dans le catalogue officiel.
• Qualifier les rôles et les finalités, puis faire relire les cas incertains par les fonctions habilitées.
• Associer chaque exigence actuelle à un contrôle observable et chaque contrôle à une preuve conservée.
• Évaluer les fournisseurs sur les informations nécessaires en aval : versions, limites, changements, journaux, incidents et réversibilité.

Horizon 3 — avant le 2 décembre 2027 : préparer les systèmes de l’annexe III

Pour les systèmes de tarification ou d’évaluation du risque en vie et santé susceptibles d’être haut risque, le travail long commence avant la documentation finale : qualité et gouvernance des données, gestion des risques, journaux, information du déployeur, supervision humaine, exactitude, robustesse et cybersécurité. Un pilote peut fonctionner tout en étant incapable de produire ces éléments de manière répétable.

La préparation doit être pilotée par écarts et preuves. L’équipe fixe un propriétaire, une date et un critère de sortie pour chaque manque. La méthode des dix pièges qui font échouer un projet IA en production aide à tester la dépendance aux données, à l’intégration et à l’exploitation, au-delà du seul dossier réglementaire.

Horizon 4 — à chaque changement : requalifier

Une revue annuelle ne suffit pas lorsqu’un fournisseur change de modèle, lorsqu’un parcours ajoute une recommandation ou lorsqu’un système passe de l’assistance interne au contact client. Toute modification susceptible d’altérer la finalité, le rôle, la catégorie ou le contrôle produit une tâche de requalification avant mise en service.

Scénario pédagogique : un assistant de déclaration de sinistre

Illustration fictive, sans dossier ni déploiement client. Une mutuelle envisage un assistant qui aide l’adhérent à décrire un sinistre, reformule ses réponses et lui indique les pièces généralement utiles. Il ne statue ni sur la garantie ni sur l’indemnisation.

Au 2 août 2026, le premier contrôle ne consiste pas à déclarer l’outil « haut risque » par prudence. L’équipe documente sa finalité, vérifie que le parcours informe clairement l’adhérent de l’interaction avec une IA, distingue les réponses générées des règles déterministes de collecte et conserve la version du texte d’information. Elle teste aussi la reprise humaine lorsqu’une personne ne comprend pas la question ou signale une situation urgente.

Si une évolution future utilise les mêmes données pour recommander une décision de garantie, la qualification est réouverte. Le registre conserve la frontière entre la version d’assistance à la saisie et la version influençant une décision. Le contrôle ne repose donc pas sur le nom commercial « assistant sinistre », mais sur la fonction effectivement mise en service.

La recette peut reprendre la logique des sept indicateurs qui distinguent une démonstration IA d’un projet utile : référence humaine, cas d’échec, seuils d’arrêt et journal des corrections. Cette démarche ne remplace pas l’analyse juridique ; elle rend les affirmations de conformité et de maîtrise testables.

Le dossier de preuves à faire vivre

La conformité n’est pas démontrée par une présentation approuvée en comité. Le dossier doit relier les règles à ce qui fonctionne réellement. Pour un système donné, il rassemble notamment :

• la fiche de finalité et la qualification de rôle, datées et validées ;
• les versions du système, du modèle, du parcours et des textes d’information ;
• les résultats des tests de transparence, d’accessibilité et de reprise humaine ;
• les décisions sur les exceptions, avec leur raisonnement et la source utilisée ;
• les contrats et documents techniques nécessaires pour contrôler la chaîne amont ;
• le journal des incidents, plaintes, changements et mesures correctives ;
• la prochaine échéance réglementaire et le propriétaire du plan de préparation.

Le comité reçoit alors une vue utile : systèmes sans qualification récente, obligations applicables sans test, preuves périmées, dépendances fournisseur non couvertes et jalons 2027 en retard. Chaque alerte conduit à une décision — corriger, limiter, requalifier ou suspendre — plutôt qu’à un simple indicateur rouge.

Sources et références

Sources officielles consultées le 12 août 2026. Le calendrier a été vérifié après l’entrée en vigueur de l’AI Omnibus ; cette synthèse ne remplace pas une analyse juridique du système et du rôle concernés.

• Journal officiel de l’Union européenne — AI Omnibus, règlement publié en juillet 2026.
• AI Act Service Desk — calendrier de mise en œuvre tenant compte de l’AI Omnibus.
• Commission européenne — entrée en vigueur de l’AI Omnibus, 27 juillet 2026.
• Commission européenne — démarrage de l’exécution et nouvelles règles de transparence au 2 août 2026.
• Commission européenne — lignes directrices sur les obligations de transparence de l’article 50.
• EIOPA — Opinion on Artificial Intelligence governance and risk management, 6 août 2025.