Compétences IA en assurance : construire une preuve opérationnelle après la réforme de l’article 4

Dans de nombreuses organisations d’assurance, la « maîtrise de l’IA » a d’abord pris la forme d’un module de sensibilisation : quelques définitions, une liste d’interdictions et un questionnaire final. Cette étape peut créer un vocabulaire commun. Elle ne suffit pourtant pas à démontrer qu’un collaborateur sait reconnaître une réponse non sourcée, interrompre une action risquée, protéger les données d’un assuré ou contester une recommandation automatisée au moment où cela compte.

Le sujet est moins scolaire qu’opérationnel. Pour un assureur, une mutuelle, un courtier ou un gestionnaire délégué, la question utile est la suivante : quelles personnes peuvent agir sur quel système, avec quel niveau d’autonomie, et quelles preuves montrent qu’elles savent prévenir ou contenir les risques correspondants ? Répondre sérieusement oblige à relier ressources humaines, conformité, métier, sécurité, data et gouvernance des systèmes.

Ce que l’article 4 demande réellement en 2026

L’article 4 du règlement (UE) 2024/1689 dans sa version consolidée au 27 juillet 2026 demande aux fournisseurs et déployeurs de systèmes d’IA de prendre des mesures pour soutenir le développement de la maîtrise de l’IA de leur personnel et des autres personnes qui s’occupent du fonctionnement et de l’utilisation de ces systèmes pour leur compte. Le paragraphe 1 précise que cette obligation n’impose de garantir aucun niveau de maîtrise de l’IA déterminé pour une personne donnée. Le texte demande de tenir compte des connaissances techniques, de l’expérience, de l’éducation et de la formation, ainsi que du contexte d’utilisation et des personnes ou groupes sur lesquels les systèmes doivent être utilisés.

Cette formulation comporte plusieurs garde-fous. Elle vise des personnes effectivement impliquées dans le fonctionnement ou l’utilisation, pas indistinctement chaque salarié. Elle organise une obligation de soutien contextualisée, sans garantir un niveau individuel déterminé. Enfin, elle porte sur des mesures à prendre : une organisation doit donc pouvoir expliquer ce qu’elle a décidé, pourquoi cette réponse est proportionnée et comment elle vérifie son efficacité.

La foire aux questions officielle de la Commission sur la maîtrise de l’IA, mise à jour après l’entrée en vigueur mi-juillet 2026 des modifications issues du paquet numérique, confirme que l’obligation de l’article 4 subsiste. Elle indique aussi qu’aucun niveau spécifique ou suffisant n’est prescrit de manière générale, qu’aucun certificat particulier n’est obligatoire et que le règlement n’impose pas une structure de gouvernance ou un « AI officer » dédié. La Commission rappelle par ailleurs que l’article 4 s’applique depuis le 2 février 2025 et présente le régime de contrôle applicable depuis août 2026.

Ces précisions ne signifient pas qu’une organisation peut se contenter d’une déclaration d’intention. Elles signifient qu’elle doit concevoir une réponse contextualisée. L’approche décrite dans la feuille de route AI Act pour l’assurance aide à replacer cette obligation dans le calendrier et les rôles applicables, sans transformer chaque outil en système à haut risque.

Une distinction est particulièrement importante. Pour les systèmes à haut risque, le règlement prévoit en outre que les personnes auxquelles est confiée la surveillance humaine disposent de la compétence, de la formation et de l’autorité nécessaires. Cette exigence est plus ciblée que la maîtrise générale de l’article 4. Elle ne doit ni être diluée dans une sensibilisation générique, ni être étendue automatiquement à tous les usages d’IA.

Passer de la formation à la preuve opérationnelle

Une preuve opérationnelle décrit une capacité observable. « A suivi le module IA » établit une exposition à un contenu. « A identifié une réponse dépourvue de source contractuelle, a suspendu son utilisation et l’a transmise au référent selon la procédure » établit un comportement attendu. Les deux traces peuvent coexister, mais elles ne prouvent pas la même chose.

Un dispositif robuste repose sur cinq éléments liés :

1. le rôle réel : ce que la personne peut consulter, modifier, valider, transmettre ou exécuter ;
2. le système et son contexte : sa finalité, ses données, ses sorties, ses limites et ses utilisateurs ;
3. le risque concret : divulgation, erreur de droit, confusion de version, automatisation indue, discrimination, manipulation d’un outil ou perte de preuve ;
4. le geste attendu : vérifier, s’abstenir, comparer, demander une pièce, masquer une donnée, interrompre ou escalader ;
5. la trace : résultat d’un exercice, décision simulée, droit activé, contrôle de production ou remédiation achevée.

Cette chaîne doit rester proportionnée. Un outil qui reformule un texte public dans un environnement isolé ne justifie pas le même dossier qu’un système qui classe des pièces de santé ou propose une décision ayant un effet sur un assuré. La profondeur de la preuve dépend de la gravité, de la réversibilité, du niveau d’autonomie, de la sensibilité des données et de la possibilité réelle pour une personne de détecter l’erreur.

Le registre des systèmes d’IA en assurance fournit le point d’ancrage : on ne peut attribuer une compétence à un système qui n’est pas inventorié, dont le propriétaire est inconnu ou dont la finalité n’est pas stabilisée. Le registre n’est cependant pas la preuve de compétence. Il relie l’objet technique aux personnes, aux risques et aux contrôles.

Cartographier les rôles et les niveaux de maîtrise

Commencez par les gestes, pas par les organigrammes. Deux personnes portant le même intitulé peuvent avoir des droits différents. À l’inverse, un salarié, un prestataire et un délégataire peuvent tous intervenir sur la même chaîne. La cartographie doit couvrir les personnes qui opèrent pour le compte de l’organisation lorsque leur action influe sur le système ou son utilisation.

Socle commun

Le socle commun donne des repères que toute personne exposée à un système doit connaître : ce qu’est et n’est pas le système, sa finalité autorisée, les données interdites ou sensibles, la différence entre une sortie plausible et une preuve, la possibilité d’erreur, le canal d’incident et l’interdiction de contourner les contrôles. Il doit rester court, compréhensible et relié aux outils effectivement disponibles.

Compétence d’usage

L’utilisateur apprend à préparer une entrée admissible, interpréter la sortie, vérifier les éléments critiques, repérer l’incertitude et conserver la trace nécessaire. Dans un copilote documentaire, cela inclut la vérification de la source et de sa version. Dans une extraction, cela inclut la provenance du champ. Dans un tri de messages, cela inclut la détection d’un mécontentement qui ne reprend pas le mot « réclamation ».

Surveillance et décision

Le superviseur doit comprendre l’effet d’ancrage : voir une recommandation influence la décision, même si un bouton « refuser » existe. Il doit pouvoir demander une information complémentaire, neutraliser l’affichage, réaffecter un dossier ou arrêter une action. Pour les usages à haut risque, la capacité attendue de la surveillance humaine doit être formalisée avec une autorité et des moyens réels, comme développé dans le dossier sur le contrôle humain effectif des systèmes d’IA.

Conception, intégration et maintenance

Les équipes techniques et data doivent comprendre les limites de données, l’évaluation, la sécurité, les dépendances, la traçabilité des versions et les conditions de retour arrière. Leur compétence ne se résume pas à savoir appeler un modèle. Elles doivent pouvoir démontrer comment une modification de prompt, de corpus, de règle ou de fournisseur est testée avant production.

Gouvernance et contrôle

Les métiers, risques, conformité, juridique, sécurité, achats et audit ont besoin d’un langage commun pour challenger la finalité, les preuves, les incidents et les fournisseurs. Leur maîtrise est moins centrée sur l’interface que sur la capacité à demander les bonnes pièces, distinguer fait et hypothèse, et refuser une mise en service dont les limites ne sont pas maîtrisées.

Construire la matrice rôle–usage–risque–geste

La matrice transforme une politique générale en obligations testables. Une ligne correspond à une combinaison réelle, pas à un métier abstrait. Elle peut être tenue dans un outil de gouvernance ou un tableau versionné, à condition que les changements de système, de droits et de formation soient reliés.

Rôle et usage	Risque prioritaire	Geste attendu	Preuve possible	Réexamen
Gestionnaire consultant un résumé de dossier	Omission d’une exclusion ou usage d’une mauvaise version	Ouvrir la source, vérifier la clause et dater la version	Cas pratique réussi et contrôle d’échantillon	À chaque changement majeur, puis périodiquement
Conseiller utilisant un assistant de réponse	Conseil non fondé ou donnée excessive envoyée au fournisseur	Minimiser l’entrée, contrôler les sources et réécrire la réponse	Simulation avec erreur introduite et trace de validation	Après incident, évolution d’outil ou de procédure
Superviseur d’une recommandation	Validation réflexe et absence d’autorité d’arrêt	Comparer les éléments contraires, motiver l’écart, suspendre si nécessaire	Test contradictoire et exercice d’escalade	Semestriel selon le risque
Équipe data modifiant un modèle	Régression masquée par une moyenne globale	Tester les cas critiques et les segments pertinents, documenter les limites	Rapport de recette versionné et approbation	À chaque changement
Acheteur d’un service IA	Dépendance, sous-traitance inconnue ou promesse invérifiable	Exiger preuves, conditions de changement, sécurité et réversibilité	Dossier de sélection et clauses validées	Renouvellement et événement fournisseur

Le niveau attendu doit être formulé en verbes observables : « expliquer », « distinguer », « vérifier », « interrompre », « documenter ». Des formulations comme « connaître l’IA » ou « être sensibilisé aux biais » ne permettent ni d’évaluer ni de remédier. Pour chaque geste, précisez le support autorisé. Dans la réalité, un opérateur peut consulter une fiche réflexe ; l’évaluation ne doit pas exiger une récitation inutile.

La matrice doit aussi distinguer la compétence de l’autorisation. Réussir un test ne donne pas automatiquement un droit de production. Le droit dépend du rôle, de la séparation des tâches et de la capacité de supervision. À l’inverse, un accès technique existant ne prouve pas que la personne est prête à l’utiliser.

Tester des situations qui peuvent réellement survenir

Les questions à choix multiple vérifient des notions. Les mises en situation vérifient une action. Un jeu d’évaluation utile combine les deux, en protégeant les données et sans piéger artificiellement les participants. Les scénarios doivent reprendre des erreurs plausibles, issues du registre de risques, des incidents, des retours utilisateurs ou d’une analyse préalable.

Scénario 1 : la mauvaise pièce

Un assistant résume correctement un document, mais celui-ci concerne un autre millésime de garantie. Le participant doit identifier la version, vérifier l’applicabilité et refuser d’utiliser le résumé comme base de décision. L’évaluation porte sur la vérification, pas seulement sur la capacité à signaler que « l’IA peut se tromper ».

Scénario 2 : la réponse sans source

Le système donne une réponse convaincante et précise, sans provenance vérifiable. Le geste attendu peut être l’abstention, la recherche dans la base officielle ou la transmission à un expert selon le dossier. Le test vérifie aussi que l’utilisateur ne fabrique pas une citation pour rendre la réponse acceptable.

Scénario 3 : l’action interdite

Un agent propose une action qui dépasse son périmètre : envoyer un message, changer un statut, valider une pièce ou déclencher un paiement sans approbation prévue. La personne doit reconnaître la frontière, conserver les éléments utiles et suivre l’escalade. Dans un système agentique, l’exercice doit inclure les droits d’outil et pas seulement le texte affiché.

Scénario 4 : la donnée de trop

Un dossier peut être traité avec des données minimisées, mais le participant est tenté de copier l’intégralité d’un échange ou une pièce sensible dans un outil non autorisé. Le test doit vérifier la connaissance du canal approuvé, du besoin d’en connaître et de la conduite en cas d’erreur.

Scénario 5 : le désaccord avec la recommandation

Les éléments du dossier contredisent une recommandation du système. Le participant doit documenter le désaccord sans se sentir obligé d’obéir au modèle ni de le rejeter sans motif. Ce scénario mesure la capacité critique et la qualité de la trace. Il peut rejoindre le jeu d’évaluation d’un système IA en assurance, qui structure les cas attendus, les cas limites et les échecs acceptables.

Un score brut ne suffit pas. Certaines erreurs doivent être bloquantes : divulguer une donnée, exécuter une action interdite ou ignorer une alerte critique ne peut être compensé par de bonnes réponses à des questions secondaires. Les critères doivent être définis avant le test et reliés au risque.

Assembler un dossier de preuve vérifiable

Le dossier de preuve doit permettre à un responsable, un contrôle interne ou un auditeur de reconstruire la décision sans exposer inutilement des données personnelles. Il peut comprendre :

• la version de la politique de maîtrise de l’IA et son périmètre ;
• la liste versionnée des systèmes et rôles concernés ;
• la matrice de compétences, avec les risques et gestes attendus ;
• les supports, scénarios et critères utilisés ;
• la date, la version de l’outil et le résultat de l’évaluation ;
• les droits ouverts, maintenus, limités ou retirés après la vérification ;
• les écarts, la remédiation et la seconde vérification ;
• les décisions de gouvernance et leur justification proportionnée ;
• les contrôles en situation de travail et les enseignements d’incident.

La preuve ne doit pas devenir une collecte excessive sur les salariés. Conservez ce qui est nécessaire pour démontrer la capacité et la gouvernance, avec une durée, un accès et une finalité définis. Un enregistrement intégral de chaque écran ou chaque interaction n’est généralement ni nécessaire ni souhaitable. Des résultats structurés, des échantillons maîtrisés et des décisions datées peuvent être plus probants.

Pour un prestataire ou un délégataire, ne vous contentez pas d’une clause affirmant que le personnel est formé. Demandez le périmètre, la méthode, les rôles concernés, la façon dont les changements sont traités et la preuve que l’escalade fonctionne. Le donneur d’ordre doit toutefois rester proportionné et respecter la répartition contractuelle des responsabilités.

Mesurer sans fabriquer un score trompeur

Le pilotage doit répondre à une question de décision. Un taux de complétion de 100 % dit que tout le monde a ouvert un module, pas que les risques sont maîtrisés. À l’inverse, un taux d’échec à un scénario difficile peut montrer que le test est enfin discriminant. Les indicateurs doivent être lus ensemble.

Indicateur	Unité et fréquence	Ce qu’il éclaire	Limite
Couverture des rôles	Part des rôles exposés avec matrice validée, mensuelle pendant le déploiement	Avancement du cadrage	Ne prouve aucune compétence individuelle
Réussite des gestes critiques	Part des scénarios critiques réussis par rôle et version	Capacité à prévenir un dommage	Dépend du réalisme et de la qualité du test
Délai de remédiation	Jours entre écart et seconde vérification	Capacité de correction	Une clôture administrative peut masquer un défaut persistant
Escalades appropriées	Nombre et proportion sur échantillon, trimestriels	Usage réel du dispositif	Plus n’est pas toujours mieux ; sous et sur-escalade existent
Écarts en production	Incidents ou reprises liés à une compétence insuffisante, par période	Conséquence réelle	La causalité doit être examinée, pas supposée

Ventilez uniquement selon des dimensions utiles et licites : système, rôle, type de geste, version, entité. La comparaison entre individus peut créer de mauvais comportements et ne doit pas remplacer l’analyse du dispositif. Une concentration d’erreurs peut révéler une interface trompeuse ou une procédure contradictoire, pas seulement un besoin de formation.

Organiser l’escalade et la remédiation

Un écart n’appelle pas toujours la même réponse. Si une notion secondaire est mal comprise, une fiche ou un rappel peut suffire. Si un geste critique échoue, le droit concerné doit pouvoir être limité jusqu’à une seconde vérification. Si plusieurs personnes échouent au même endroit, l’organisation doit examiner le système, la consigne et le test avant de blâmer les utilisateurs.

La procédure d’escalade indique le canal, le destinataire, le délai interne, les éléments à conserver et l’autorité de décision. Elle couvre aussi l’indisponibilité du référent. Un dispositif qui dépend d’une personne unique en congé n’est pas opérationnel. Pour les systèmes sensibles, un mode dégradé documenté permet de continuer le service sans forcer l’usage de l’IA.

La remédiation suit quatre étapes : qualifier l’écart, protéger le processus, corriger sa cause probable, puis vérifier sur un cas nouveau. Elle ne se clôt pas à l’envoi d’un nouveau support. Le dossier conserve la décision et sa justification. Lorsqu’une erreur révèle un défaut de cadrage du projet, il faut parfois revenir au problème métier plutôt que multiplier les formations ; le guide choisir un meilleur problème avant d’ajouter des données fournit cette grille de recul.

Plan de mise en œuvre sur quatre-vingt-dix jours

Jours 1 à 30 : établir le périmètre

1. Extraire du registre les systèmes en production, en pilote et autorisés en libre-service.
2. Identifier les personnes internes et externes qui les font fonctionner ou les utilisent pour l’organisation.
3. Décrire les gestes, droits, données, effets et scénarios de dommage.
4. Distinguer le socle commun des capacités spécifiques et de la surveillance humaine renforcée.
5. Nommer un propriétaire de la matrice et les responsables de validation métier, risque et sécurité.

Jours 31 à 60 : construire et piloter

1. Rédiger les critères observables et les cas pratiques pour les rôles prioritaires.
2. Tester les scénarios avec un petit groupe représentatif, sans données réelles inutiles.
3. Corriger les consignes ambiguës, l’interface et les droits révélés par le pilote.
4. Définir les erreurs bloquantes, le mécanisme de remédiation et le mode dégradé.
5. Versionner supports, critères, systèmes et résultats.

Jours 61 à 90 : déployer et contrôler

1. Déployer par rôle et risque, en synchronisant la vérification avec l’ouverture des droits.
2. Constituer le dossier de preuve et contrôler un échantillon de traces.
3. Mesurer les gestes critiques, les remédiations et les escalades, pas seulement la complétion.
4. Programmer le réexamen à chaque changement important et une revue périodique proportionnée.
5. Présenter à la gouvernance les zones couvertes, les limites et les décisions encore ouvertes.

Ce calendrier est un scénario d’organisation, pas un délai réglementaire universel. Une entreprise avec de nombreux systèmes ou des délégataires devra séquencer plus longtemps. L’objectif des quatre-vingt-dix jours est d’obtenir un premier dispositif démontrable sur les usages prioritaires, pas de déclarer le sujet définitivement clos.

Limites, erreurs fréquentes et décisions de gouvernance

Inventer une certification obligatoire

Le règlement ne crée pas de certificat européen uniforme de maîtrise de l’IA. Une certification volontaire peut soutenir un parcours, mais elle ne dispense pas d’adapter la compétence au système et au contexte. Présenter un certificat comme exigence légale générale serait inexact.

Former sans modifier les droits

Si un utilisateur peut toujours exécuter une action qu’il ne maîtrise pas, le problème n’est pas seulement pédagogique. Les droits, validations et contrôles techniques doivent correspondre au rôle. La formation n’est pas un substitut à une architecture sûre.

Confondre connaissance et indépendance

Une personne compétente peut subir une pression de délai, un objectif commercial ou un biais d’automatisation. La gouvernance doit préserver le temps, l’information et l’autorité nécessaires pour contester le système. La compétence sans pouvoir d’agir produit une surveillance fictive.

Geler le dispositif

Un modèle, un corpus, une interface, une réglementation ou une population peuvent changer. La preuve doit donc être reliée à une version et à des événements de réexamen. Exiger mécaniquement une formation annuelle pour tous peut être trop lent après une modification critique et inutile pour un rôle inchangé.

Transformer la preuve en promesse absolue

Réussir un test ne garantit pas l’absence d’erreur. Le dossier établit qu’un risque a été identifié, qu’une capacité a été vérifiée dans des conditions définies et qu’une réponse existe. Il doit déclarer ses limites : scénarios non couverts, faible volume, environnement simulé, évolution récente ou vérité encore indisponible.

La décision finale appartient à la gouvernance : quels usages exigent une vérification préalable, quelles erreurs retirent un droit, qui peut accepter un risque résiduel et dans quelles conditions le système est limité ou suspendu ? Une politique crédible répond à ces questions avant l’incident.

Sources officielles

• EUR-Lex — règlement (UE) 2024/1689, version consolidée au 27 juillet 2026, notamment article 4 et dispositions relatives à la surveillance humaine des systèmes à haut risque.
• Commission européenne — Questions and Answers on AI literacy, page officielle consultée pour l’état du droit et les précisions d’application en 2026.
• EIOPA — Opinion on Artificial Intelligence governance and risk management, 6 août 2025, pour l’approche sectorielle proportionnée et fondée sur les risques.