Aller au contenu
NEURIXIS

Secteur

L’IA en assurance, sous contrainte de justification

L’assurance modélise depuis toujours. La question n’est donc pas de savoir modéliser, c’est de savoir défendre un modèle plus complexe que celui qu’il remplace, devant l’actuariat, le contrôle interne, un régulateur et un assuré.

Le contexte

Vos données ne décrivent pas le risque, elles décrivent votre processus. Un sinistre non déclaré n’existe pas dans la base. Un dossier requalifié à la main porte la trace du gestionnaire qui l’a requalifié. Un modèle entraîné sans précaution sur cet historique apprend vos décisions passées, pas le risque sous-jacent, et il reproduit fidèlement les biais du dispositif qu’on lui demande de remplacer.

Le problème est particulièrement net sur la fraude. La fraude avérée est rare, et elle n’est connue que là où elle a été cherchée. Un modèle entraîné sur la fraude détectée apprend le ciblage actuel et le confirme. Sans un échantillon de contrôle tiré aléatoirement, indépendant du ciblage, il est impossible d’estimer honnêtement un taux de base, et donc impossible d’affirmer qu’on fait mieux qu’avant.

La contrainte de justification est structurante, et elle est mal comprise quand on vient d’un autre secteur. À performance égale, un modèle explicable et un modèle opaque n’ont pas la même valeur, parce que le second coûte plus cher à défendre devant un contrôle, un assuré ou un juge. La bonne question n’est donc pas « quel modèle est le plus performant », mais « quel écart de performance justifie de payer ce coût de défense ». Cet écart se mesure, il ne se suppose pas.

Enfin, le portefeuille dérive. Une validation croisée aléatoire sur l’historique donne des chiffres flatteurs et faux. La seule évaluation qui prédit le comportement réel est une évaluation sur une période postérieure à l’entraînement, sur le portefeuille tel qu’il est, pas tel qu’il était.

Bureaux éclairés dans un immeuble de verre contemporain.

Contraintes réglementaires

Quatre cadres se superposent, et ils ne parlent pas des mêmes objets : le système d’IA, la décision, le modèle et le prestataire.

  • AI Act, annexe III

    Les systèmes d’IA destinés à l’évaluation des risques et à la tarification à l’égard des personnes physiques en assurance vie et en assurance santé sont classés à haut risque au titre de l’annexe III. Cela emporte système de gestion des risques, gouvernance des données d’entraînement, documentation technique, journalisation, transparence, contrôle humain et niveau démontré d’exactitude et de robustesse. Point à noter : les autres branches ne relèvent pas de cette entrée, ce qui n’exonère de rien d’autre, à commencer par le RGPD.

  • RGPD, article 22

    Une personne a le droit de ne pas faire l’objet d’une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques la concernant ou l’affectant de manière significative. Un refus de souscription, une résiliation ou une majoration significative entrent dans le champ. En conception, cela veut dire prévoir dès l’architecture l’intervention humaine, la possibilité pour la personne d’exprimer son point de vue et de contester, et donc une trace exploitable de ce qui a motivé la proposition du système.

  • Solvabilité II

    Le système de gouvernance, la fonction actuarielle et la fonction de gestion des risques encadrent les modèles qui alimentent la tarification, le provisionnement ou l’évaluation des risques. Un modèle d’apprentissage qui entre dans cette chaîne entre dans le périmètre de validation : documentation, revue indépendante, suivi dans le temps, proportionnés à son usage. Un modèle plus performant mais construit sans l’actuariat n’est pas un modèle en avance, c’est un modèle qui ne sera pas déployé.

  • DORA, règlement (UE) 2022/2554

    DORA encadre la résilience opérationnelle numérique du secteur financier : gestion du risque prestataires tiers TIC, registre des accords contractuels, tests, notification des incidents majeurs. La conséquence sur l’architecture est directe : un service d’inférence appelé chez un tiers est un prestataire tiers de services TIC, avec les exigences contractuelles et de suivi associées. Faire tourner le modèle chez vous n’est pas qu’un choix de souveraineté, c’est souvent le chemin le plus court.

  • Travaux de l’ACPR

    L’ACPR a publié des travaux sur la gouvernance des algorithmes d’intelligence artificielle dans le secteur financier, en particulier sur l’explicabilité, la validation et le contrôle interne des modèles. Il recoupe les exigences de documentation attendues par ailleurs. Ce corpus mérite d’être lu avant de choisir une famille de modèles, pas après : il décrit assez précisément ce qui sera demandé lors d’un contrôle, et donc ce qu’il faut avoir produit pendant le projet plutôt que reconstitué après.

Classement des systèmes d’IA du plus au moins encadré : risque inacceptable, haut risque, risque limité, risque minimal.Le plus encadréLe moins encadréRisque inacceptableInterdit dans l’UnionHaut risqueAnnexe III, obligations lourdesRisque limitéObligations de transparenceRisque minimalUsage libre

Cas d’usage

  • Instruction assistée des dossiers de souscription

    Le problème
    Les pièces arrivent sous des formes hétérogènes : questionnaires, bulletins, relevés, courriers scannés. La ressaisie mobilise du temps de gestionnaire et introduit ses erreurs, sur des champs à conséquence tarifaire.
    L’approche
    OCR puis extraction contrainte par un schéma explicite, contrôles de cohérence entre les pièces d’un même dossier (dates, montants), et file d’exceptions pour tout ce qui passe sous le seuil de confiance. Le système prépare, le gestionnaire décide, y compris parce que l’article 22 le demande, et chaque champ garde un lien vers sa pièce.

    Critère de succès

    Part des dossiers instruits sans reprise humaine au seuil retenu, et taux d’erreur d’extraction mesuré séparément sur les champs à conséquence tarifaire. Une erreur sur une date de naissance et une erreur sur une ligne d’adresse ne valent pas la même chose : les agréger produirait un chiffre rassurant et inutile.

  • Ciblage des dossiers à contrôler

    Le problème
    Le ciblage repose sur des règles connues, donc contournées. Et sa performance apparente est mesurée sur la population que ces mêmes règles ont sélectionnée, ce qui rend toute comparaison douteuse.
    L’approche
    Gradient boosting sur variables métier, complété par de la détection d’anomalie sur les schémas relationnels entre acteurs d’un dossier. Attribution de contribution par variable, pour que le gestionnaire puisse motiver l’ouverture d’un contrôle. Et surtout, mise en place d’un échantillon de contrôle tiré aléatoirement, maintenu dans la durée.

    Critère de succès

    Précision en tête de file à charge de contrôle constante, estimée sur l’échantillon aléatoire et non sur les dossiers déjà ciblés par l’ancien dispositif. Avec un suivi des taux de sélection par segment, pour vérifier que le gain ne vient pas d’une concentration sur une population.

  • Tri et instruction des réclamations

    Le problème
    Le flux entrant est en texte libre, les délais de traitement sont encadrés, et le risque n’est pas de traiter lentement en moyenne : c’est de passer à côté d’un cas sensible qui appelle une réponse rapide.
    L’approche
    Classification multi-label, détection des cas à traitement prioritaire, réclamation formelle, situation de vulnérabilité, mise en demeure, et résumé structuré à destination du gestionnaire. Le compromis est assumé : on privilégie le rappel sur les catégories à enjeu et la précision sur le reste, ce qui n’est pas la même chose qu’optimiser une moyenne.

    Critère de succès

    Rappel sur les catégories à enjeu et précision sur le reste, à taux d’alerte acceptable pour l’équipe, mesuré sur un échantillon relu par les gestionnaires. Complété par le délai de première réponse avant et après, sur le même périmètre et la même saisonnalité, à volume comparable.

  • Modélisation du risque et provisionnement

    Le problème
    Les modèles en place sont stables, documentés et défendables devant l’actuariat, mais peu discriminants sur les segments récents ou les nouveaux produits, là où le portefeuille bouge le plus.
    L’approche
    Le modèle en place reste la référence, pas remplacé d’office. Un challenger à gradient boosting est construit sous contraintes explicites : monotonie où le métier l’exige, exclusion des variables interdites et test actif de leurs substituts, attribution des contributions. La comparaison se fait sur une période postérieure, jamais en validation croisée aléatoire.

    Critère de succès

    Pouvoir discriminant et calibration sur une période postérieure à l’entraînement, plus stabilité des contributions dans le temps. Et un test explicite des substituts : si retirer une variable interdite ne change rien parce qu’un proxy la remplace, le modèle n’est pas conforme, quelle que soit sa performance.

Matrice deux par deux croisant l’effort d’intégration et le gain annuel estimé, avec quatre quadrants nommés.Quick winGain fort, effort faibleChantier structurantGain fort, effort fortGadgetGain faible, effort faiblePiègeGain faible, effort fortGain annuel estiméfortfaibleEffort d’intégrationfaiblefort

Ce qui fait échouer les projets

Ces échecs se ressemblent d’un assureur à l’autre. Ils tiennent tous à une évaluation qui ne mesure pas ce qu’on croit.

  • Le modèle est validé par validation croisée aléatoire sur l’historique, alors que le portefeuille dérive. Il perd son avantage dès la première période réelle, et la confiance du métier avec.
  • Les variables interdites sont retirées, mais leurs substituts restent dans le jeu. Le résultat est inchangé, la conformité seulement apparente, et le problème se découvre au pire moment.
  • La performance en détection de fraude est mesurée sur les dossiers déjà ciblés, c’est-à-dire là où l’ancien dispositif savait chercher. Le gain annoncé ne se retrouve jamais dans les résultats de contrôle réels.
  • Le modèle est meilleur, mais la fonction actuarielle et le contrôle interne n’ont pas été associés à sa construction. Il n’est pas validé, donc il n’est pas déployé, et le projet est comptabilisé comme un échec technique alors que c’est un échec d’organisation.
  • Le service d’inférence est un prestataire externe qui n’a été inscrit ni au registre d’information ni au dispositif de gestion du risque tiers. Le sujet remonte au moment de la revue, et il bloque une mise en production prête par ailleurs.
  • Le gestionnaire reçoit un score sans explication utilisable. Il ne peut pas motiver sa décision auprès de l’assuré, donc il ignore le score et retourne à ses règles. Le modèle est bon et il ne sert à rien.
Cycle fermé du MLOps : entraîner, déployer, superviser, détecter la dérive, réentraîner.EntraînerDéployerSuperviserDétecter la dériveRéentraîner

Ce que nous faisons, et ce que nous ne faisons pas

Ce que nous faisons

  • Nous associons le métier, l’actuariat, le contrôle interne et le DPO au cadrage, avant d’écrire le protocole d’évaluation.
  • Nous évaluons systématiquement sur une période postérieure à l’entraînement, et nous conservons le modèle en place comme référence de comparaison.
  • Nous construisons explicable par défaut. Un modèle opaque n’est retenu que si son écart de performance est mesuré et jugé suffisant pour payer son coût de défense.
  • Nous testons activement les substituts des variables interdites, et nous documentons ce test.
  • Nous concevons des architectures compatibles avec vos exigences DORA, en privilégiant l’inférence sur votre infrastructure.
  • Nous produisons la documentation AI Act et les éléments techniques attendus par la validation de modèle.

Ce que nous ne faisons pas

  • Nous ne sommes ni actuaires certificateurs ni auditeurs. Nous préparons les éléments de validation, nous ne signons pas la validation d’un modèle.
  • Nous ne délivrons pas de conseil juridique ni de conseil en conformité prudentielle. Nous travaillons avec les vôtres.
  • Nous ne construisons pas de système qui décide seul du sort d’un assuré, sans intervention humaine réelle et traçable.
  • Nous n’achetons ni ne revendons de données externes d’enrichissement, et nous ne recommandons pas de variable dont vous ne pourriez pas justifier l’usage.
  • Nous sommes deux ingénieurs. Nous prenons un chantier à la fois, et nous préférons refuser une mission que la mener à moitié.

Les autres secteurs

Questions fréquentes

  • Un modèle plus complexe sera-t-il défendable devant un contrôle ?

    C’est la vraie question, et elle passe avant la performance. À performance égale, un modèle explicable et un modèle opaque n’ont pas la même valeur, parce que le second coûte plus cher à défendre devant un contrôle, un assuré ou un juge. Nous construisons explicable par défaut, et nous ne retenons un modèle opaque que si son écart de performance est mesuré et jugé suffisant pour payer ce coût de défense. Les travaux de l’ACPR sur la gouvernance des algorithmes décrivent assez précisément ce qui sera demandé : mieux vaut les lire avant de choisir une famille de modèles qu’après.

  • Un service d’IA appelé chez un tiers pose-t-il un problème au titre de DORA ?

    Oui, et il faut le traiter comme tel. Un service d’inférence appelé chez un tiers est un prestataire tiers de services informatiques au sens de DORA, avec les exigences contractuelles, de registre et de suivi qui vont avec. C’est l’une des raisons pour lesquelles nous privilégions l’inférence sur votre infrastructure : faire tourner le modèle chez vous n’est pas seulement un choix de souveraineté, c’est souvent le chemin le plus court vers la conformité.

  • Comment prouvez-vous qu’un modèle de fraude fait mieux que l’existant ?

    Avec un échantillon de contrôle tiré aléatoirement, indépendant du ciblage actuel et maintenu dans la durée. La fraude n’est connue que là où elle a été cherchée : un modèle entraîné sur la fraude détectée apprend le ciblage en place et le confirme. Sans échantillon aléatoire, il est impossible d’estimer honnêtement un taux de base, donc impossible d’affirmer qu’on fait mieux qu’avant. Nous mesurons la précision en tête de file sur cet échantillon, pas sur les dossiers déjà ciblés par l’ancien dispositif.

  • L’actuariat et le contrôle interne doivent-ils valider le modèle ?

    Oui, et nous les associons dès le cadrage, pas à la fin. Un modèle d’apprentissage qui alimente la tarification, le provisionnement ou l’évaluation des risques entre dans le périmètre de validation au titre de Solvabilité II : documentation, revue indépendante, suivi dans le temps. Un modèle plus performant mais construit sans la fonction actuarielle n’est pas un modèle en avance, c’est un modèle qui ne sera pas déployé. Nous produisons les éléments de validation, nous ne signons pas la validation à votre place.

Parlons de votre cas d’usage.

Une heure suffit pour savoir si votre sujet tient debout. Si ce n’est pas le cas, nous vous le dirons à ce moment-là, pas après trois mois de projet.

Nous contacterRéserver un Workshop Quick Wins IA