Gouverner un agent de triage FNOL / réception des sinistres (bulletin IA de la NAIC + AI Act européen)
13 min · Updated 2026-06-02
Answer
Vous gouvernez un agent de triage FNOL selon le régime qui le lie réellement : le programme AIS écrit du NAIC AI Model Bulletin et le droit étatique des pratiques déloyales de règlement des sinistres (Model #900). Le triage à la réception des sinistres relève de la gestion des sinistres et non de l'évaluation des risques ou de la tarification vie et santé que l'annexe III(5)(c) du règlement européen sur l'IA classe à haut risque. KLA applique un point de contrôle Govern in Place à chaque décision de routage (voie rapide, file des gestionnaires de sinistres ou SIU), achemine les voies rapides contestées et les signalements de fraude SIU vers un approbateur humain nommé dans Decision Desk avant l'exécution de l'action, et scelle la traçabilité sous forme de preuve vérifiable de façon indépendante.
KLA is the independent runtime governance and assurance layer forthis Process. KLA governs the agent you already built, whether it was built in-house or on a commercial agent framework: it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.
The Process
The job & where the agent takes high-stakes action
Un agent de triage FNOL / réception des sinistres ingère une première déclaration de sinistre (déclaration du demandeur, données de police, photos, données de sinistre de tiers), puis classe la gravité et la complexité du sinistre, calcule un score de probabilité de fraude et l'oriente vers l'une de trois voies : la voie rapide pour un traitement automatisé de bout en bout (accusé de réception automatique, fixation de la provision, versement d'un acompte ou clôture), le routage vers une file de gestionnaires de sinistres humains, ou le signalement à l'unité spéciale d'enquête (SIU). L'action à fort enjeu est l'écriture du routage et tout effet de bord automatisé qui en découle : l'agent peut faire sortir entièrement un sinistre de la revue humaine via la voie rapide, le placer en file avec une étiquette de gravité/complexité sur laquelle les gestionnaires s'ancrent, ou désigner un demandeur comme fraudeur présumé en le routant vers la SIU. Le Model #900 limite son champ aux sinistres découlant de polices émises (hors accidents du travail, fidélité, cautionnement et chaudières/machines), et le bulletin de la NAIC cite « la gestion des dossiers, l'administration et le paiement des sinistres, et la détection de la fraude » comme domaines du cycle de vie que le programme AIS de l'assureur doit couvrir — chacune de ces actions de routage s'inscrit donc dans une pratique réglementée.
Stakes
Why it's high-stakes
Une voie rapide erronée ou un signalement SIU erroné ne sont pas un simple défaut de qualité du modèle : c'est une pratique déloyale de règlement des sinistres dont l'assureur est responsable, que l'IA ait pris la décision ou non. La section 4 du Model #900 qualifie de pratique déloyale le refus de payer sans enquête raisonnable (F), l'absence de normes raisonnables pour une enquête et un règlement rapides (C), le défaut de confirmer ou de refuser la garantie dans un délai raisonnable (G), le défaut de fournir une explication raisonnable et exacte d'un refus (L), et le défaut de fournir les formulaires de sinistre dans les quinze (15) jours calendaires suivant une demande (M). Un agent qui clôture en voie rapide sans enquête peut enfreindre (F) ; un agent qui laisse un sinistre en attente SIU sans horloge peut enfreindre (C) et (G) ; un agent incapable d'expliquer pourquoi il a routé vers la SIU peut enfreindre (L). Le bulletin de la NAIC est explicite : ces normes légales s'appliquent « quelles que soient les méthodes utilisées par l'assureur pour déterminer ou étayer ses actions », et le programme AIS existe pour atténuer le risque d'« Adverse Consumer Outcome » — une décision qui porte préjudice au consommateur d'une manière qui viole les normes que le régulateur fait respecter.
What goes wrong
Failure modes specific to this agent
Filtrage silencieux de la voie rapide par le score de fraude (refus automatique par omission)
L'agent ne « refuse » pas un sinistre : il route un sinistre limite vers une mise en attente SIU indéfinie ou l'écarte discrètement de la voie rapide parce que le score de fraude a franchi un seuil interne. Aucune lettre de refus n'est jamais générée, aucune horloge d'enquête ne démarre, et le demandeur n'a simplement jamais de nouvelles. Le préjudice de pratique déloyale (refus de payer sans enquête raisonnable, défaut de confirmer ou de refuser la garantie dans un délai raisonnable) se produit par inaction de routage, sans aucune décision défavorable explicite que quelqu'un examinerait.
Why it's hard to catch: Les tests de précision mesurent si le signalement SIU était « juste », pas si une enquête en aval et une horloge de délai Model #900 ont effectivement démarré. La défaillance est une absence — une lettre manquante et une échéance manquante — elle ne produit donc aucun signal d'erreur dans une matrice de confusion et aucune exception dans le système de gestion des sinistres. Elle n'apparaît que sous la forme d'une réclamation pour sinistre en souffrance ou d'un examen de conduite de marché des mois plus tard.
Ancrage sur l'étiquette de gravité/complexité qui étouffe l'enquête
L'agent attache une étiquette « gravité faible, complexité faible » pour passer un sinistre en voie rapide. Les gestionnaires humains qui touchent ensuite le dossier s'ancrent sur cette étiquette et sous-enquêtent, et les provisions sont fixées à la baisse à partir de la classification de l'agent. Un sinistre réellement lourd ou à garantie ambiguë est traité comme routinier parce que la première étiquette l'a cadré ainsi. C'est la classification de l'agent, et non les faits, qui détermine le niveau d'enquête que le sinistre reçoit réellement.
Why it's hard to catch: L'étiquette est généralement plausible et défendable individuellement, si bien que le contrôle qualité dossier par dossier passe. Le préjudice est un glissement systémique de la profondeur d'enquête qui n'apparaît qu'en agrégé — taux de réouverture des sinistres, surprises dans l'évolution des provisions et cohortes de gravité mal classées — rien qu'un test unitaire par décision ou une évaluation sur jeu de données de référence ne révèle. C'est précisément la préoccupation du bulletin : un comportement du modèle qui diverge après la mise en œuvre de la performance observée en développement.
Dérive du score de fraude et taux de voie rapide disparates entre cohortes
Le modèle de probabilité de fraude a été validé sur des sinistres historiques, mais les schémas de sinistres, les typologies de fraude et la composition des demandeurs évoluent après le déploiement. L'agent commence progressivement à router une zone géographique, un niveau de produit ou une cohorte de demandeurs vers la SIU — ou à l'exclure du traitement automatisé — à un taux sensiblement plus élevé, encodant une discrimination par procuration dans la question de savoir qui obtient un service rapide et sans friction et qui fait l'objet d'une enquête.
Why it's hard to catch: Chaque décision de routage individuelle paraît justifiée par le score ; la disparité est statistique et ne devient visible qu'entre cohortes au fil du temps. Le bulletin de la NAIC nomme directement la dérive du modèle (Model Drift) — « la dégradation de la performance d'un modèle dans le temps » à mesure que les données de déploiement s'éloignent des données d'entraînement — et impose de comparer le comportement en développement au comportement après mise en œuvre, ce qu'un test d'équité unique avant lancement ne peut pas faire. Les tests de régression ordinaires figent le monde au lancement et ne voient jamais la dérive.
Transmission brute de scores de fraude et de données de sinistres tiers sans piste de responsabilité
L'agent appelle un modèle de scoring de fraude d'un fournisseur ou récupère des données externes d'historique de sinistres et route le sinistre sur la base de cette sortie. Lorsqu'un demandeur conteste un renvoi SIU ou un refus, l'assureur ne peut pas reconstituer quel signal tiers a déterminé le routage, quelle version l'a produit, ni si les données étaient même adaptées — parce que l'agent a traité le score du fournisseur comme une entrée opaque et n'a journalisé que la voie finale.
Why it's hard to catch: La voie de bout en bout paraît correcte et l'appel au fournisseur renvoie un chiffre net, donc les tests fonctionnels passent. Le manque porte sur la provenance : l'assureur reste responsable des systèmes d'IA et des données de tiers au titre du bulletin et doit pouvoir en répondre devant un régulateur, mais rien dans les tests ordinaires d'agents n'impose de capturer la version du modèle du fournisseur, le traçabilité des données d'entrée ou la posture contractuelle d'audit derrière le score.
How KLA governs it
Runtime controls, mapped to each decision point
KLA evaluates each consequential action with a policy gate that runs before the action executes: a Decision Request to POST /v1/decisions.evaluate: resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.
| Decision point | Intercept (before action) | Policy checks → reason codes | Human routing (maker-checker) | Evidence captured |
|---|---|---|---|---|
| Passer un sinistre en voie rapide pour un traitement automatisé de bout en bout (accusé de réception automatique, fixation de la provision, acompte ou clôture) | Govern in Place : un point de contrôle du SDK KLA enveloppe l'appel d'outil de voie rapide / traitement automatisé et soumet une Decision Request à POST /v1/decisions.evaluate avant que l'agent n'accuse réception, ne provisionne, ne paie ou ne clôture. L'appel SDK reste bloqué sur le résultat, de sorte qu'aucun effet de bord dans le système de gestion des sinistres ne se produit avant la résolution de la politique. |
| Sur require_approval, KLA ouvre une Escalation Decision Desk acheminée par la politique vers un superviseur sinistres nommé (maker-checker : l'agent est le maker, le superviseur est le checker). Le réviseur voit la voie proposée, le score de fraude, l'étiquette de gravité/complexité, la règle déclenchante et les codes de motif, ainsi qu'un lien vers le Lineage Record, puis approuve, refuse ou réachemine vers un gestionnaire de sinistres senior — l'exécution reprend exactement là où elle s'est arrêtée, uniquement en cas d'approbation. |
|
| Signaler un sinistre à l'unité spéciale d'enquête (SIU) sur la base d'un score de probabilité de fraude | Govern in Place : le point de contrôle SDK sur l'outil route_claim soumet une Decision Request avant l'écriture du renvoi SIU. Lorsqu'un modèle de fraude d'un fournisseur ou une source externe d'historique de sinistres a contribué, ces appels d'outils sont eux-mêmes interceptés afin que leur version et leurs entrées atterrissent dans le traçabilité avant l'évaluation de l'action de routage. |
| require_approval ouvre une Escalation Decision Desk acheminée vers un réviseur nommé de l'admission SIU ; le réviseur confirme ou rejette la base de fraude avant que le demandeur ne soit désigné fraudeur présumé. Le réacheminement transmet le dossier à un responsable SIU senior sans perte de contexte. La séparation maker-checker signifie qu'aucun renvoi SIU émis par le seul agent ne quitte le système sans revue. |
|
| Attribuer une étiquette de gravité/complexité et router vers une file de gestionnaires de sinistres humains | Govern in Place : le point de contrôle SDK soumet la Decision Request de classification-et-routage avant que l'étiquette et l'affectation de file ne soient écrites dans le système de référence des sinistres, de sorte que l'étiquette ne peut pas ancrer un gestionnaire tant que la politique et (le cas échéant) un réviseur ne l'ont pas validée. |
| Les étiquettes à faible confiance ou signalées pour dérive sont acheminées sous forme d'Escalation Decision Desk vers un responsable nommé du triage des sinistres, qui peut corriger l'étiquette avant qu'elle n'atteigne la file des gestionnaires. Les gestionnaires conservent l'autorité permanente d'ignorer, de corriger ou d'annuler la classification de l'agent — et chaque correction est capturée comme preuve de supervision. |
|
Least-privilege execution & data boundaries
- Passer un sinistre en voie rapide pour un traitement automatisé de bout en bout (accusé de réception automatique, fixation de la provision, acompte ou clôture): La Release immuable de l'agent ne lie que les outils dont il a besoin (lookup_claim, classify_severity, score_fraud, route_claim) ; les outils de paiement/clôture/acompte sur provision sont liés séparément et gardés. Un appel d'outil non lié (par exemple émettre un paiement sans passer par la porte route_claim) est bloqué avant exécution par le Tool Catalog. Les Data Boundaries maintiennent les données personnelles du demandeur et les données de sinistre dans la région/le système approuvés.
- Signaler un sinistre à l'unité spéciale d'enquête (SIU) sur la base d'un score de probabilité de fraude: route_claim avec target=SIU est une capacité distincte, liée séparément dans la Release ; l'agent ne peut pas élever ses privilèges pour écrire un renvoi SIU si cette liaison n'est pas active. Les outils de scoring de fraude des fournisseurs sont liés dans le Tool Catalog de sorte qu'une source de scoring non approuvée est bloquée. Les Data Boundaries confinent les signaux de fraude et les données d'historique de sinistres au système approuvé.
- Attribuer une étiquette de gravité/complexité et router vers une file de gestionnaires de sinistres humains: classify_severity et route_claim sont liés dans la Release ; l'agent ne peut pas écrire de provisions ni de paiements depuis cette voie. Assurance Center surveille le classifieur déployé par rapport à sa référence ; les Data Boundaries maintiennent les données de sinistre dans la région.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| Bulletin modèle de la NAIC sur l'utilisation de systèmes d'IA par les assureurs (déc. 2023) | Section 3 — Regulatory Guidance & Expectations ; AIS Program Guidelines 1.6 (cycle de vie de l'assurance incluant la gestion des dossiers, l'administration et le paiement des sinistres, la détection de la fraude) | Chaque assureur doit maintenir un programme AIS écrit régissant les systèmes d'IA qui prennent ou étayent des décisions tout au long du cycle de vie de l'assurance — en incluant expressément la gestion des dossiers, l'administration et le paiement des sinistres, et la détection de la fraude — conçu pour atténuer le risque d'Adverse Consumer Outcomes. C'est ce régime, et non l'annexe III de l'AI Act européen, qui constitue le cadre de gouvernance contraignant pour un agent de triage FNOL / sinistres. | Chaque point de décision de routage (voie rapide, SIU, file des gestionnaires) est une porte de politique Govern in Place, de sorte que chaque action du cycle de vie nommée par le bulletin est appliquée par un pack de politiques publié et signé, avec codes de motif et remédiation — le programme AIS est ainsi opérationnalisé au moment de l'action plutôt que dans un classeur. | Source |
| Bulletin modèle de la NAIC sur l'utilisation de systèmes d'IA par les assureurs (déc. 2023) | Section 3 — Risk Management & Internal Controls 3.4 ; supervision des modèles prédictifs 2.4 (tests d'erreurs, de biais, de discrimination déloyale ; évaluation de la généralisation après mise en œuvre ; Model Drift) | Les assureurs doivent valider, tester et retester les systèmes d'IA pour détecter les erreurs, les biais et la discrimination déloyale, en comparant la performance en développement au comportement après mise en œuvre et en surveillant la dérive du modèle. | Assurance Center suit les classifieurs de scoring de fraude et de gravité par cohorte et par rapport à une référence ; une dérive ou un taux SIU/voie rapide sensiblement différent entre cohortes déclenche une Assurance Alert et active les contrôles de politique FNOL_DRIFT_GUARD / FNOL_SIU_FAIRNESS_COHORT, transformant la surveillance continue de l'équité en contrôles de routage à l'exécution. | Source |
| Bulletin modèle de la NAIC sur l'utilisation de systèmes d'IA par les assureurs (déc. 2023) | Section 3 — AIS Program Guidelines 4.0 (systèmes d'IA et données de tiers), 4.2 (droits d'audit ; coopération avec les enquêtes réglementaires) | Lorsque l'agent s'appuie sur un modèle de scoring de fraude tiers ou sur des données externes de sinistres, l'assureur reste responsable, doit exercer une diligence raisonnable et devrait obtenir des droits d'audit contractuels ainsi que la coopération du fournisseur aux enquêtes réglementaires. La responsabilité ne peut pas être externalisée au fournisseur. | Le contrôle FNOL_THIRDPARTY_PROVENANCE bloque une voie SIU fondée sur un score fournisseur dont la version du modèle ou l'adéquation des données n'est pas capturée ; l'appel au fournisseur est lui-même intercepté afin que son nom, sa version et le traçabilité de ses entrées soient scellés dans la preuve — donnant à l'assureur le dossier reconstituable qu'exige une enquête réglementaire. | Source |
| NAIC Unfair Claims Settlement Practices Act (Model #900) — appliqué via l'autorité législative de la section 1 du bulletin | Section 1 (objet ; champ des sinistres) ; Section 4 (définition des pratiques déloyales de règlement des sinistres : C, D, F, G, L, M, incluant le délai de 15 jours calendaires pour les formulaires de sinistre) | Le droit des pratiques déloyales de règlement des sinistres fixe les normes que les sorties d'un agent FNOL doivent satisfaire — enquête rapide, règlement équitable de bonne foi lorsque la responsabilité est claire, aucun refus de payer sans enquête raisonnable, confirmation/refus de garantie dans les délais, explication raisonnable et exacte de tout refus, et formulaires de sinistre sous quinze (15) jours calendaires — et s'applique que l'IA ait déterminé ou étayé l'action ou non. | FNOL_COVERAGE_NOT_CONFIRMED bloque la clôture automatique silencieuse afin que la garantie soit confirmée ou refusée ; FNOL_SIU_EXPLAINABILITY impose une base codée par motif afin qu'un refus/renvoi puisse être expliqué (L) ; FNOL_INVESTIGATION_CLOCK estampille les obligations de confirmation/refus et de formulaire sous 15 jours calendaires sur le traçabilité dès qu'un sinistre quitte la voie rapide (C, G, M). | Source |
| AI Act européen (règlement (UE) 2024/1689) | Annexe III, points 5(c) et 5(b) ; article 6(2)–(4) (classification + dérogation + enregistrement au titre de l'art. 49(2)) | L'annexe III ne classe à haut risque que l'IA destinée à « l'évaluation des risques et la tarification en ce qui concerne les personnes physiques en matière d'assurance-vie et d'assurance-maladie » (5(c)) et l'évaluation de la solvabilité/notation de crédit (5(b), hors détection de la fraude). Le triage FNOL / réception des sinistres relève de la gestion des sinistres — pas de l'évaluation des risques ni de la tarification vie et santé — il n'est donc généralement PAS à haut risque au sens de l'annexe III. L'article 6(3) déroge en outre pour les systèmes de l'annexe III qui n'influencent pas substantiellement le résultat de la décision, mais un fournisseur qui s'en prévaut doit tout de même documenter l'évaluation et s'enregistrer au titre de l'article 49(2). | KLA enregistre la justification de classification (le triage FNOL sort du champ de l'annexe III(5)(c)) comme preuve gouvernée, et la porte d'approbation humaine sur le routage voie rapide et SIU est précisément le contrôle qui empêche l'agent « d'influencer substantiellement le résultat de la prise de décision » à lui seul — de sorte que si un pipeline mixte touche un jour à l'évaluation des risques en assurance-maladie, l'argument de dérogation de l'article 6(3) et sa documentation au titre de l'article 49(2) sont déjà étayés par des preuves. | Source |
| AI Act européen (règlement (UE) 2024/1689) | Article 14 (contrôle humain) — 14(1), 14(4)(b) biais d'automatisation, 14(4)(d) ignorer/corriger/annuler, 14(4)(e) arrêt en état sûr | Lorsqu'un système d'IA d'assurance EST à haut risque, les personnes chargées du contrôle doivent pouvoir le superviser effectivement, rester conscientes du biais d'automatisation, décider de ne pas utiliser / d'ignorer / de corriger / d'annuler sa sortie, et l'interrompre vers un état sûr. Cité comme modèle de gouvernance même si le triage FNOL est généralement hors annexe III, parce que des pipelines FNOL mixtes peuvent toucher à l'évaluation des risques en assurance-maladie. | require_approval met en pause l'action de routage et la confie à un réviseur Decision Desk nommé qui peut ignorer/corriger/annuler la voie choisie par l'agent (14(4)(d)) ; block est l'arrêt en état sûr en mode fermé par défaut (14(4)(e)) ; l'audit des corrections d'étiquette et la confirmation SIU mettent en lumière le biais d'automatisation en obligeant les humains à confirmer plutôt qu'à approuver machinalement (14(4)(b)). | Source |
| AI Act européen (règlement (UE) 2024/1689) | Article 26 (obligations des déployeurs) — 26(2) contrôle compétent, 26(6) conservation des journaux ≥ 6 mois, 26(11) information des personnes physiques concernées | Les déployeurs de systèmes à haut risque doivent confier le contrôle humain à des personnes compétentes, formées et autorisées (26(2)) ; conserver les journaux générés automatiquement pendant au moins six mois (26(6)) ; et informer les personnes physiques concernées lorsqu'un système de l'annexe III prend ou aide à prendre des décisions à leur sujet (26(11)). | Decision Desk achemine les Escalations vers des réviseurs sinistres/SIU nommés et autorisés (26(2)) ; le registre ImmuDB en ajout seul conserve le traçabilité bien au-delà du plancher de six mois (26(6)) ; les codes de motif et la remédiation fournissent l'explication nécessaire pour informer un demandeur concerné qu'un système d'IA a contribué au routage (26(11)). | Source |
| AI Act européen (règlement (UE) 2024/1689) | Article 12 (enregistrement / journalisation automatique) — 12(1), 12(2)(a)–(c) | Les systèmes d'IA à haut risque doivent permettre techniquement l'enregistrement automatique des événements tout au long de leur vie afin de permettre l'identification des risques, la surveillance après commercialisation (art. 72) et la surveillance du fonctionnement (art. 26(5)). | La preuve par défaut capture chaque décision de routage, score de fraude, appel d'outil et verdict humain sous forme de spans OpenTelemetry scellés dans le registre en ajout seul, et Evidence Room peut exporter un Control Pack mis en correspondance avec l'annexe IV de l'AI Act — exactement le substrat de journalisation automatique sur toute la durée de vie qu'exige l'article 12 si le système est dans le champ d'application. | Source |
| Directive sur la distribution d'assurances (directive (UE) 2016/97) | Article 17(1)–(2) (principe général : honnête, impartial, professionnel ; informations correctes, claires et non trompeuses) | Les distributeurs d'assurances doivent agir de manière honnête, impartiale et professionnelle, au mieux des intérêts des clients, et les informations fournies aux clients doivent être correctes, claires et non trompeuses. RÉSERVE DE PÉRIMÈTRE : la DDA régit la distribution d'assurances (vente/conseil/intermédiation), PAS la gestion des sinistres en tant que telle — c'est donc une norme de fond de traitement équitable côté UE, et non le régime contraignant du triage des sinistres. La lacune contraignante côté UE est que la gestion des sinistres FNOL n'est pas un cas d'usage à haut risque de l'annexe III ; le régime opérant est le bulletin de la NAIC + le droit étatique des pratiques déloyales de règlement des sinistres (États-Unis) et le droit national de conduite en assurance (UE). | L'exigence de code de motif + remédiation sur chaque résultat autre qu'allow signifie que toute communication destinée au demandeur déclenchée par l'agent repose sur une base correcte, claire et non trompeuse — ce qui soutient la norme d'équité de la DDA là où la gestion des sinistres confine à l'information du client, sans prétendre que la DDA régit le triage. | Source |
Prove the control held
Audit-evidence checklist
- Référence au programme AIS écrit liée à chaque règle de routage gouvernée (section 3 du bulletin) — quelle version du pack de politiques applique les contrôles du cycle de vie pour la gestion des dossiers, l'administration des sinistres et la détection de la fraude
- Pour chaque voie rapide : la Decision Request, le score de fraude, l'étiquette de gravité/complexité, le résultat de politique, les codes de motif et (si retenu hors voie rapide) l'horloge estampillée Model #900 de confirmation/refus + formulaire sous 15 jours calendaires
- Pour chaque renvoi SIU : la base codée par motif, le nom/la version du modèle de fraude du fournisseur et le traçabilité des données d'entrée, le résultat du contrôle de disparité de cohorte, et le verdict du réviseur SIU nommé
- Preuves d'équité/dérive d'Assurance Center : taux SIU et voie rapide par cohorte dans le temps, alertes de dérive sur les modèles de fraude et de gravité, et la comparaison développement vs après mise en œuvre qu'exige le bulletin
- Preuves de supervision humaine : chaque Escalation avec identité de l'approbateur, verdict, note et horodatage ; chaque correction par un gestionnaire d'une étiquette de l'agent (art. 14 / 26(2))
- Preuves de responsabilité vis-à-vis des tiers : versions des modèles fournisseurs, enregistrements d'adéquation des données, et posture contractuelle de droits d'audit/coopération (bulletin 4.0/4.2)
- Preuve de conservation : entrées de traçabilité dans le registre ImmuDB en ajout seul conservées au-delà du plancher de six mois de l'art. 26(6) de l'AI Act, chacune vérifiable via GET /v1/lineage/{id}/verify
- Export scellé d'Evidence Bundle / Control Pack (correspondance avec l'annexe IV de l'AI Act) qu'un auditeur peut vérifier par rapport au hachage racine publié sans faire confiance à KLA
A concrete intercept
Reference scenario: Un sinistre à score de fraude élevé que l'agent tente de passer en voie rapide et de clôturer silencieusement
- 1
FNOL ingérée : un sinistre dégât des eaux avec un score de fraude fournisseur de 0,82 et une étiquette de gravité « faible » ; l'agent prévoit de le passer en voie rapide — fixer une petite provision et clôturer automatiquement — via route_claim(target=fast_track) plus l'outil de clôture.
- 2
Avant l'exécution de la clôture, le point de contrôle SDK Govern in Place soumet une Decision Request à POST /v1/decisions.evaluate avec le score de fraude, l'étiquette de gravité et la voie cible.
- 3
La politique fait correspondre FNOL_FASTTRACK_FRAUD_CEILING (fraude 0,82 > plafond de traitement automatisé) et FNOL_COVERAGE_NOT_CONFIRMED (aucune étape affirmative de garantie) ; le résultat le plus fort, require_approval, l'emporte, avec les reasonCodes FRAUD_SCORE_OVER_FASTTRACK_LIMIT + COVERAGE_UNCONFIRMED_NO_AUTOCLOSE et la remédiation « Score de fraude élevé et garantie non confirmée : un humain doit décider entre enquêter et confirmer/refuser avant toute clôture. »
- 4
L'exécution se met en pause (la clôture ne se déclenche jamais) ; KLA ouvre une Escalation Decision Desk acheminée par la politique vers un superviseur sinistres nommé, qui voit l'action, le score de 0,82, l'étiquette « faible », les règles déclenchantes et un lien vers le Lineage Record.
- 5
Le superviseur rejette la voie rapide silencieuse et réachemine vers l'admission SIU pour une enquête documentée — ce qui démarre l'horloge de délai Model #900 (obligation de confirmation/refus ; formulaires de sinistre sous 15 jours calendaires) que le warn FNOL_INVESTIGATION_CLOCK a estampillée sur le traçabilité.
- 6
Chaque étape — la voie rapide bloquée, les codes de motif, le verdict et la note du superviseur, le réacheminement SIU et l'horloge UCSPA estampillée — est scellée dans un Lineage Record avec preuve de Merkle sur le registre en ajout seul, exportable sous forme de Control Pack et vérifiable via GET /v1/lineage/{id}/verify sans faire confiance à KLA.
What most teams get wrong
The non-obvious insight
Le triage FNOL / réception des sinistres n'est presque certainement PAS à haut risque au sens de l'annexe III de l'AI Act européen — l'annexe III(5)(c) ne capture que « l'évaluation des risques et la tarification en ce qui concerne les personnes physiques en matière d'assurance-vie et d'assurance-maladie », c'est-à-dire la souscription/tarification, pas la gestion des sinistres. Les équipes qui étiquettent par réflexe chaque agent d'assurance « à haut risque » et courent après la documentation technique de l'annexe IV gouvernent selon le mauvais régime : la contrainte qui lie un agent FNOL est le programme AIS du bulletin IA de la NAIC plus le droit étatique des pratiques déloyales de règlement des sinistres (Model #900), qui s'appliquent « quelles que soient les méthodes utilisées par l'assureur », comportent des délais concrets (formulaires de sinistre sous 15 jours calendaires) et mordent sur chaque voie rapide et chaque signalement SIU dès aujourd'hui — sans débat sur une date d'entrée en application 2026/2027.
Why it matters: Se tromper de régime gaspille des efforts en paperasse de conformité européenne tout en laissant non gouvernée la véritable surface de responsabilité — refus automatique silencieux, horloges de confirmation/refus manquées, renvois SIU inexpliqués. La posture correcte consiste à gouverner le plus fermement là où le Model #900 mord (les actions de routage), à documenter la non-applicabilité de l'annexe III comme preuve, et à garder le modèle européen de contrôle humain (require_approval de l'art. 14) en réserve pour tout pipeline mixte qui toucherait à l'évaluation des risques en assurance-maladie — auquel cas la dérogation de l'article 6(3) « n'influence pas substantiellement le résultat », satisfaite précisément par la porte d'approbation humaine, devient l'argument que cette porte documente aussi.
La défaillance FNOL la plus difficile à gouverner n'est pas une mauvaise décision mais une non-décision : un agent qui fait sortir un sinistre de la voie rapide sur un score de fraude et ne démarre jamais d'horloge de confirmation/refus commet une pratique déloyale de règlement des sinistres par omission — et comme il n'y a aucune « décision » défavorable à tester, aucune matrice de confusion ni aucune évaluation sur jeu de données de référence ne la signalera jamais. Le seul contrôle fiable est une interception qui, à l'instant où un sinistre quitte la voie rapide, estampille l'obligation de délai du Model #900 sur un traçabilité immuable.
Q&A
Frequently asked questions
Un agent de triage FNOL / réception des sinistres est-il à haut risque au sens de l'AI Act européen ?
Généralement non. L'annexe III(5)(c) de l'AI Act européen ne classe à haut risque que l'IA utilisée « pour l'évaluation des risques et la tarification en ce qui concerne les personnes physiques en matière d'assurance-vie et d'assurance-maladie » — c'est-à-dire la souscription et la tarification, pas la gestion des sinistres. Le triage FNOL classe, score la fraude et route les sinistres ; il n'est donc pas capturé par l'annexe III(5)(c), et le point 5(b) (évaluation de la solvabilité/notation de crédit) est un domaine distinct qui exclut même la détection de la fraude. N'affirmez pas que le triage FNOL est automatiquement à haut risque au sens du règlement. Si un pipeline mélange triage et évaluation des risques en assurance-maladie, la classification dépend de l'annexe III plus la dérogation de l'article 6(3) (le système « influence-t-il substantiellement le résultat »), et un fournisseur qui s'appuie sur cette dérogation doit tout de même documenter l'évaluation et s'enregistrer au titre de l'article 49(2).
Si l'AI Act européen ne le lie pas, quel régime gouverne réellement un agent de triage FNOL ?
Aux États-Unis, le NAIC AI Model Bulletin (déc. 2023) exige un programme AIS écrit couvrant l'IA tout au long du cycle de vie de l'assurance — en nommant « la gestion des dossiers, l'administration et le paiement des sinistres, et la détection de la fraude » — ainsi que le droit étatique des pratiques déloyales de règlement des sinistres (NAIC Model #900). Le bulletin est explicite : ces normes de sinistres s'appliquent « quelles que soient les méthodes utilisées par l'assureur pour déterminer ou étayer ses actions », de sorte que les sorties de l'agent doivent satisfaire aux obligations du Model #900 : enquête rapide, aucun refus de payer sans enquête raisonnable, confirmation/refus de garantie dans les délais, explication raisonnable de tout refus, et formulaires de sinistre sous quinze (15) jours calendaires après une demande. C'est cela, et non l'annexe IV, la contrainte qui lie chaque action de routage.
Comment KLA empêche-t-il l'agent de refuser silencieusement un sinistre en le routant vers une mise en attente SIU ?
Le point de contrôle SDK Govern in Place soumet une Decision Request avant l'exécution de l'écriture de routage. Le contrôle FNOL_COVERAGE_NOT_CONFIRMED bloque toute voie de clôture/refus automatique dépourvue d'une étape affirmative de garantie, et FNOL_INVESTIGATION_CLOCK estampille les obligations Model #900 de confirmation/refus et de formulaire sous 15 jours calendaires sur le traçabilité dès qu'un sinistre quitte la voie rapide. Un sinistre retenu ou suspect devient une Escalation require_approval vers un superviseur sinistres nommé — une non-décision ne peut donc plus se produire par omission ; elle devient une décision suivie, avec une horloge et un responsable humain.
Qui approuve une voie rapide ou un renvoi SIU, et que voit-il ?
Sur require_approval, KLA ouvre une Escalation Decision Desk acheminée par la politique vers un approbateur nommé — un superviseur sinistres pour les voies rapides contestées, un réviseur de l'admission SIU pour les signalements de fraude. Le réviseur voit la voie proposée, le score de fraude, l'étiquette de gravité/complexité, la règle déclenchante exacte avec ses codes de motif, et un lien vers le Lineage Record complet, puis approuve, refuse ou réachemine vers un réviseur senior. C'est du maker-checker : l'agent est le maker, l'humain est le checker, et l'exécution ne reprend qu'en cas d'approbation.
Le score de fraude provient d'un modèle tiers — qui est responsable si un demandeur conteste le renvoi SIU ?
L'assureur. Les sections 4.0/4.2 du bulletin de la NAIC maintiennent la responsabilité de l'assureur pour les systèmes d'IA et les données de tiers et attendent des droits d'audit contractuels ainsi que la coopération du fournisseur aux enquêtes réglementaires. KLA intercepte l'appel de scoring du fournisseur afin que le nom de son modèle, sa version et le traçabilité de ses données d'entrée soient scellés dans la preuve, et FNOL_THIRDPARTY_PROVENANCE bloque une voie SIU fondée sur un score fournisseur dont la version ou l'adéquation des données n'a pas été capturée — de sorte que l'assureur peut toujours reconstituer quel signal tiers a déterminé le routage.
Comment KLA détecte-t-il que l'agent a commencé à router une cohorte vers la SIU plus que les autres ?
Assurance Center suit la façon dont les résultats automatisés se répartissent entre les cohortes que vous définissez (zone géographique, niveau de produit, tranche d'âge). Si le taux d'exclusion SIU ou voie rapide d'une cohorte diverge sensiblement, cela devient une Assurance Alert avec la ventilation par cohorte jointe, et les contrôles FNOL_SIU_FAIRNESS_COHORT / FNOL_DRIFT_GUARD transforment ce signal en contrôle de routage à l'exécution. Cela répond directement à l'exigence du bulletin de la NAIC de tester la discrimination déloyale et de comparer le comportement en développement au comportement après mise en œuvre, ce qu'un test d'équité unique avant lancement ne peut pas faire.
Related blueprints & guides
- Gouverner un agent de recommandation de règlement de sinistres : des offres équitables, explicables et auditables
- Gouverner un agent de triage d'alertes de surveillance des transactions AML
- Gouverner un agent de réception des événements indésirables et de traitement des cas en pharmacovigilance
- Solution: Insurance
- Blueprints de workflows gouvernés en assurance (hub)
- Gouverner un agent de recommandation de règlement de sinistres
- Gouverner un agent de triage d'alertes de surveillance des transactions AML
- Ajouter une porte d'approbation humaine (docs KLA)
- Gouverner un agent de bout en bout (docs KLA)
- Exécution gardée par politique (docs KLA)
- Decision Desk (docs KLA)
- Assurance Center (docs KLA)
- Evidence Room (docs KLA)
Primary sources
- NAIC Model Bulletin: Use of Artificial Intelligence Systems by Insurers: NAIC
- NAIC Unfair Claims Settlement Practices Act (Model #900) — Section 4 Unfair Claims Practices Defined: NAIC
- EU AI Act — Annex III, point 5 (essential private/public services), incl. 5(c) insurance: EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 6 (Classification rules for high-risk AI systems), incl. 6(2), 6(3) derogation and 6(4): EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 14 (Human oversight): EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 26 (Obligations of deployers of high-risk AI systems): EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 12 (Record-keeping / automatic logging): EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- Insurance Distribution Directive (Directive (EU) 2016/97) — Article 17 General principle: EIOPA Rulebook / EUR-Lex
- KLA Docs — Govern an Agent End-to-End: KLA Digital
- KLA Docs — Add a Human Approval Gate: KLA Digital
- KLA Docs — Policy-Gated Execution: KLA Digital
- KLA Docs — Evidence-by-Default: KLA Digital
- KLA Docs — Architecture Overview: KLA Digital
- KLA Docs — Agents & Registry (Releases, Tool Catalog, least-privilege): KLA Digital
- KLA Docs — Assurance Center (drift, bias/fairness cohorts): KLA Digital
- KLA Docs — Decision Desk (maker-checker, re-route to SIU/senior reviewer): KLA Digital
- KLA Docs — Evidence Room (Sealed Evidence Bundle, Control Pack, EU AI Act Annex IV mapping): KLA Digital
- KLA Docs — API Reference (decisions.evaluate, lineage verify): KLA Digital
Govern this Process without re-platforming the agent
KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.