AI Act pour les assureurs : qu'est-ce qui en relève et qu'est-ce qui n'en relève pas ?

Le 2 août 2026, l'essentiel de l'AI Act (règlement européen sur l'IA) deviendra pleinement applicable aux systèmes d'IA à haut risque. Une partie du règlement est d'ailleurs déjà entrée en vigueur : les chapitres I et II (les définitions et les pratiques d'IA interdites de l'article 5) depuis le 2 février 2025, et les dispositions relatives aux amendes, le chapitre sur la gouvernance et les règles pour les modèles d'IA à usage général depuis le 2 août 2025. Pour les assureurs, la question pertinente n'est pas de savoir si l'AI Act s'applique à eux (c'est le cas), mais quelle partie de leur portefeuille d'IA relève de quel régime. Pour certains cas d'usage, c'est clair. Pour d'autres, justement pas, et c'est précisément là que la charge de travail va se concentrer dans les mois à venir.

Le cadre : quatre niveaux de risque et l'annexe III

L'AI Act (règlement (UE) 2024/1689) répartit les systèmes d'IA en quatre niveaux de risque : inacceptable, haut, limité et minimal. Le haut risque est la catégorie qui comporte de loin le plus d'obligations. L'annexe III du règlement énumère huit domaines dans lesquels des systèmes d'IA peuvent relever du haut risque.

Pour les assureurs, la catégorie 5(c) de l'annexe III est la plus concrète. Le règlement désigne ce cas d'usage comme les systèmes d'IA destinés à 'l'évaluation des risques et la tarification concernant les personnes physiques dans le cas des assurances-vie et des assurances maladie'. Là, il n'y a pas matière à discussion. Ce sont des systèmes à haut risque. Le considérant 58 le justifie : cette IA peut avoir des conséquences profondes sur les moyens de subsistance, les droits fondamentaux et même la santé des personnes concernées.

Pour les dommages corporels, l'assurance dommages et l'IA générale de gestion des sinistres, c'est plus compliqué. Ces cas d'usage ne sont pas explicitement mentionnés dans l'annexe III. Qu'un système spécifique relève ou non du haut risque dépend de ce que fait le système, de l'ampleur de l'impact de son output pour le client et de la manière dont il est utilisé dans la prise de décision. L'IA en dommages corporels entre vite dans la zone de risque de conformité, mais n'en relève pas toujours sans discussion.

Deux exceptions pertinentes pour les assureurs. La catégorie 5(b) de l'annexe III classe l'IA d'évaluation de la solvabilité comme à haut risque, mais en exclut explicitement l'IA de détection de la fraude dans les services financiers. Le considérant 58 y ajoute que les systèmes d'IA prévus par le droit de l'Union à des fins de détection de la fraude dans les services financiers et à des fins prudentielles de calcul des exigences de fonds propres des établissements de crédit et des entreprises d'assurance ne sont pas considérés comme à haut risque au titre de ce règlement.

Le profilage : pas ce qu'il semble être

Une affirmation fréquente veut que le profilage par IA entraîne automatiquement une classification à haut risque. C'est inexact. L'article 6(3), premier alinéa, offre justement une exception pour certains systèmes de l'annexe III qui ne présentent pas de risque significatif pour la santé, la sécurité ou les droits fondamentaux. Le paragraphe 3, troisième alinéa, ajoute qu'un système qui effectue un profilage de personnes physiques est, nonobstant cette exception, toujours considéré comme à haut risque.

Autrement dit : le profilage ne rend pas un système à haut risque en soi. Il ferme seulement la voie de sortie pour les systèmes qui relèvent de toute façon déjà de l'annexe III. Pour l'IA en dommages corporels, vous devez donc d'abord établir si le cas d'usage relève de l'annexe III. Ce n'est qu'ensuite que le profilage devient juridiquement pertinent.

Fournisseur versus déployeur : d'autres obligations, une autre stack

L'AI Act distingue deux rôles. Le fournisseur ('provider') développe le système ou le met sur le marché. Le déployeur ('deployer') l'utilise dans son activité. Beaucoup d'assureurs sont déployeurs, parce qu'ils achètent l'IA via des solutions SaaS ou des fournisseurs de détection de la fraude.

Les obligations les plus lourdes pèsent sur le fournisseur. Les articles 9 à 15 régissent la gestion des risques, la gouvernance des données, la documentation technique, l'architecture de journalisation, la transparence et la conception du contrôle humain. Un assureur qui achète un système n'a pas à fournir lui-même cette stack, mais doit pouvoir démontrer que son fournisseur l'a fait.

Le déployeur a ses propres obligations au titre de l'article 26 : utilisation conforme aux instructions, contrôle humain par des personnes compétentes, vérification des données d'entrée pour autant qu'elles soient sous son contrôle, monitoring, conservation des logs (six mois minimum) et information des clients lorsque cela s'impose.

Pour les assureurs, il y a ici une nuance importante. L'article 26, paragraphes 5 et 6, contient un régime spécifique pour les établissements financiers soumis à des exigences de gouvernance au titre du droit de l'Union sur les services financiers. Pour ces déployeurs, les obligations de monitoring et de conservation des logs sont réputées remplies par le respect de cette législation sur les services financiers. Les assureurs relevant de Solvabilité II en font en principe partie. Cela n'épargne pas le travail, mais cela épargne une paperasserie AI Act distincte à côté de ce qui tourne déjà.

FRIA : pour qui oui et pour qui non

L'article 27 impose une analyse d'impact sur les droits fondamentaux (FRIA) aux déployeurs de certains systèmes à haut risque. L'obligation concerne les déployeurs qui sont des organismes de droit public ou des entités privées fournissant des services publics, plus les déployeurs de systèmes relevant de l'annexe III catégories 5(b) (solvabilité) et 5(c) (assurances-vie et maladie). Pour les autres cas d'usage en assurance, une FRIA n'est pas automatiquement obligatoire. Que cela change ou non dépend de la manière dont le système spécifique est classifié.

Conseil pratique : ne traitez pas la FRIA comme une étape de conformité générique, mais consignez par système si l'article 27 s'applique. Pour certains systèmes, il vaut la peine d'en réaliser une même sans obligation légale, parce qu'elle étaye votre propre évaluation des risques et s'articule avec l'obligation de DPIA de l'article 35 du RGPD.

Le régime transitoire de l'article 111

Une erreur fréquente dans les publications sur l'AI Act consiste à supposer que tous les systèmes d'IA existants devront d'un coup être conformes au régime à haut risque le 2 août 2026. C'est inexact. L'article 111(2) prévoit que les systèmes à haut risque déjà mis sur le marché ou mis en service avant cette date ne relèvent du régime qu'au moment où ils subissent des 'modifications importantes de leur conception' après le 2 août 2026.

Sur le papier, cela donne de l'air. En pratique, c'est une illusion. Pratiquement tout système d'IA activement maintenu subit en un à deux ans des modifications qui qualifient d''importantes' : nouvelles données d'entraînement, remplacements de modèles, fonctionnalités étendues. Celui qui a cartographié la situation peut planifier. Celui qui ne le fait pas se heurtera au régime au moment de la prochaine mise à niveau.

Pour les organismes publics, une échéance plus stricte s'applique d'ailleurs : leur IA à haut risque existante doit être conforme au plus tard le 2 août 2030, même sans modification de conception.

Les amendes

L'article 99 fixe trois paliers avec des maxima :

•      Jusqu'à 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial pour les pratiques d'IA interdites (article 5).

•      Jusqu'à 15 millions d'euros ou 3 % pour le non-respect des obligations des fournisseurs (article 16), des déployeurs (article 26), des obligations de transparence (article 50) et de quelques autres dispositions (article 99, paragraphe 4).

•      Jusqu'à 7,5 millions d'euros ou 1 % pour des informations inexactes ou trompeuses fournies à une autorité de surveillance (article 99, paragraphe 5).

La manière dont ces maxima seront appliqués en pratique (par infraction, par système ou de manière cumulative) relève de l'autorité de surveillance nationale. Aux Pays-Bas, l'Autoriteit Persoonsgegevens (l'autorité néerlandaise de protection des données) jouera un rôle central, en concertation avec la DNB et l'AFM pour ce qui concerne les assureurs. La pratique de surveillance n'est pas encore cristallisée à ce jour. Bon à savoir : le chapitre sur les sanctions lui-même est déjà en vigueur depuis le 2 août 2025.

Ce que cela fait au marché des fournisseurs

Fin 2025, presque tout le monde participait à des pilotes IA. Construire vite, voir ce que cela rapporte, penser à la gouvernance ensuite. Cette phase est terminée.

À partir de l'été, la question posée à chaque appel d'offres devient invariablement la même : pouvez-vous justifier aujourd'hui la classification de ce système ? La documentation de l'article 11 existe-t-elle ? Les biais sont-ils mesurés et continueront-ils de l'être ? La répartition fournisseur-déployeur que vous proposez correspond-elle à ce que la loi exige ? Un fournisseur qui ne peut pas répondre à ces questions en une journée sort de la shortlist. Les équipes conformité s'en occupent déjà. Les achats suivront peu après.

Où en est DCSolutions

DCSolutions construit des plateformes pour assureurs avec l'explicabilité et la décision humaine comme principes fondateurs. Concrètement :

•      Chaque étape automatisée a un objectif documenté, des données d'entrée et des limites.

•      Les décisions sont journalisées à un niveau conforme à ce que demande l'article 12 côté fournisseur, de sorte que l'assureur, en tant que déployeur, puisse aussi faire tourner son propre monitoring au titre de l'article 26 (ou, pour les assureurs relevant de Solvabilité II, continuer à utiliser la stack de gouvernance existante).

•      Les gestionnaires voient ce que le modèle a fait et sur quelle justification, et peuvent intervenir ou passer outre à tout moment.

•      Les tests de biais et le monitoring tournent en continu, pas comme un audit annuel.

C'est construit ainsi à dessein. Non parce que la loi l'impose, mais parce que c'est la seule manière d'exercer ce métier de façon responsable. Cela rend en tout cas les conversations avec les équipes conformité nettement plus simples en ce moment.

Ce que vous pouvez faire dès maintenant

Trois étapes, dans cet ordre.

Un. Établissez un registre de tous les systèmes d'IA qui tournent dans votre chaîne d'assurance, y compris les modèles embarqués dans des solutions SaaS de tiers. Par système : cas d'usage, première mise en service, fournisseur, rôle de déployeur et statut au titre de l'article 111.

Deux. Déterminez la classification de risque par système. Pas 'haut risque par précaution' (cela entraîne des obligations inutiles), pas 'minimal parce que c'est flou' (cela entraîne un risque). Justifiez le choix, explicitement, par écrit.

Trois. Pour les systèmes qui sont ou deviendront probablement à haut risque : demandez la documentation de l'article 11 à votre fournisseur, planifiez vos propres obligations au titre de l'article 26 (en tenant compte de la voie Solvabilité II des paragraphes 5 et 6) et vérifiez si l'article 27 s'applique.

Nous échangeons volontiers avec les assureurs qui s'y attellent en ce moment. Un intake, une démonstration technique de la manière dont nous classifions et justifions nos plateformes. Ensuite, vous savez où vous en êtes. Planifiez un entretien via notre page contact ci-dessus.

Sources

•      Règlement (UE) 2024/1689 (l'AI Act), en particulier l'annexe III, les articles 6, 9-15, 26, 27, 50, 99, 111 et 113. Consultable via eur-lex.europa.eu/eli/reg/2024/1689/oj ou dans le PDF en français sur data.europa.eu (ELI : data.europa.eu/eli/reg/2024/1689/oj)

•      Considérant 58 (considération sur la classification à haut risque des assurances) et considérant 96 (sur la FRIA)

•      AI Act Service Desk de la Commission européenne : ai-act-service-desk.ec.europa.eu

•      EIOPA, Statement on the use of governance arrangements and risk management in the use of artificial intelligence

•      artificialintelligenceact.eu (explication article par article)

‍