Insurance AI | EIOPA, Solvency II, AI Act

Groupes d'algorithmes par type de données

Chaque élément provient d'une règle déposée, pas d'une supposition.

Demandez ce qui a fait bouger votre prix.

Les modèles linéaires généralisés et les modèles à boosting de gradient existants continuent de fonctionner. Dweve les enveloppe dans une couche de décision déterministe qui enregistre chaque facteur, chaque règle et chaque dérogation au moment où la décision est prise. Le paquet de relecture constitue la pièce d'audit.

Bundle fermé pour les travaux classifiés ou réglementaires.

Exécution sur des serveurs dans vos propres locaux.

Mesh public opéré par Dweve ; la frontière de traitement est documentée dans le contrat.

Intégration via REST ou gRPC sur une surface OpenAPI 3.1 typée. Géré via Fabric sur le Mesh public Dweve pour les pilotes. Licence pour une installation sur site. Air-gapped pour les travaux actuariels les plus sensibles. Même API, même format de trace, mêmes paquets de relecture sur les trois postures. Les erreurs sont typées selon RFC 7807 et des SDK sont fournis pour TypeScript, Python, Go et Rust, donc s'intégrer à une posture, c'est s'intégrer aux trois.

Le modèle de fraude continue de fonctionner comme avant. Dweve l'enveloppe dans une couche déterministe qui enregistre chaque caractéristique, chaque seuil et chaque validation du réviseur.

Le réviseur signe ; le paquet constitue la pièce d'audit.

Chaque score enregistre la version du modèle utilisée.

Champs de la réclamation, historique, graphe du réseau.

La détection de fraude aux réclamations est le flux d'assurance le plus affecté par l'écart de version des modèles. Dweve exécute le modèle de fraude sur une arithmétique entière, l'épingle à une version spécifique du modèle et produit la même décision de signalement à chaque fois. Le paquet constitue la pièce d'audit lorsqu'une réclamation est refusée pour fraude. Quatre étapes sous-tendent un indicateur : les caractéristiques sont extraites des champs de la réclamation, de l'historique des réclamations et du graphe du réseau ; le score enregistre la version du modèle qui l'a produit ; une règle de seuil versionnée décide de l'indicateur ; et un réviseur nommé le signe. Lorsqu'une réclamation est refusée pour fraude, ces quatre étapes constituent le contenu du dossier.

La couche de décision ne franchit jamais une frontière de confiance qui enfreint les règles d'externalisation de Solvabilité II. La même topologie est déployée sur les trois postures.

Aucun appel sortant. Point de terminaison réglementaire optionnel réservé à l'UE.

Paquets signés écrits une fois, lus plusieurs fois, réplique réservée à l'UE.

Moteur natif CPU, pas de ferme GPU, pas d'API ML cloud.

Terminaison TLS dans l'UE, mTLS vers la couche de décision.

Trois modèles d'exploitation, une architecture de preuve. Fabric géré s'exécute sur le Mesh public de Dweve. Une licence permet l'exploitation directe du produit sur votre matériel. Un déploiement sous licence physiquement isolé protège les travaux actuariels les plus sensibles. Le contrat précise la frontière de traitement et la responsabilité d'exploitation pour chaque modèle. Les mêmes quatre frontières sont tracées dans chacun : un ingress qui termine TLS dans l'UE, la frontière de confiance derrière laquelle se trouve la couche de décision, le stockage des paquets, et un egress qui n'effectue aucun appel sortant.

La déterminisme est affirmé dans la suite de tests, pas promis en prose. La même exécution de l'oracle sur votre matériel produit la même réponse que sur le nôtre.

Aucune erreur d'arrondi ne franchit le seuil de l'unité de la dernière place.

Les coins et les plages sont exercés automatiquement dans l'intégration continue.

Chaque résultat est comparé à une référence de haute précision.

Nombre d'itérations borné, sans unité à virgule flottante.

Chaque fonction transcendante du chemin de tarification et de provisionnement est calculée avec CORDIC en nombres entiers, puis vérifiée par rapport à MPFR à une précision de 256 bits. Le résultat publié est 0 ULP, arrondi correctement sur le domaine d'entrée documenté, avec des tests basés sur les propriétés qui couvrent les coins à chaque version. La borne est affirmée dans la suite de tests à chaque version plutôt que promise en prose, donc la même exécution de l'oracle sur votre matériel renvoie ce qu'elle renvoie sur le nôtre.

L'actuaire signe. Le paquet est l'artefact d'audit.

Le calcul déterministe exécute la projection.

Chain-ladder, BF ou attendu. Même moteur.

Tirez le dernier triangle de votre système de sinistres.

Le provisionnement est la charge de travail actuarielle la plus endommagée par la dérive des flottants. Les méthodes chain-ladder, Bornhuetter-Ferguson et des sinistres attendus doivent toutes pouvoir être rejouées exactement quand le superviseur le demande. Dweve exécute le triangle en arithmétique entière et fournit les mêmes nombres à chaque fois. Le triangle est tiré de votre système de sinistres tel qu'il est, la méthode est choisie sans changer de moteur, la projection IBNR s'exécute sur un calcul déterministe, et l'actuaire signe la vue qui en résulte. Année d'accident contre période de développement, les mêmes quatre étapes renvoient les mêmes nombres un an plus tard.

Version tarifaire déposée appliquée au score.

Facteurs enregistrés avant l'exécution du modèle.

Le modèle de tarification lui-même, un modèle linéaire généralisé ou à boosting par gradient, continue de fonctionner comme avant. Dweve l'enveloppe dans une couche de décision déterministe qui enregistre chaque facteur, chaque règle et chaque dérogation au moment où la décision est prise. Le paquet de rejeu est l'artefact d'audit. Les facteurs sont épinglés avant l'exécution du modèle, le score brut revient, la version tarifaire déposée lui est appliquée, et l'actuaire signe la prime.

Votre modèle plus une couche déterministe,

Mesh géré, ou sur votre matériel, ou en environnement isolé.

Spécification OpenAPI 3.1, erreurs typées (RFC 7807).

Source, règle, version tarifaire, actuaire, signature.

Même entrée, même sortie, sur chaque machine, à chaque version.

Chaque décision de tarification, de sinistres et de réserves repose sur un moteur déterministe. Rejeu bit-exact sur toutes les machines et versions. Un paquet signé par décision, assez léger pour être joint à un dépôt réglementaire. Aucune dérive en virgule flottante, aucun arrondi dépendant de la puce. Le paquet contient la source, la règle, la version tarifaire, l'actuaire et la signature, et les quatre mêmes propriétés s'appliquent que le travail s'exécute sur le Mesh géré, sur votre propre matériel ou en mode isolé.

Vous n'avez pas besoin d'un avocat pour contester une prime. Le paquet est en langage clair et la règle, la version et le réviseur sont nommés sur la lettre.

Aucun frais initial pour le consommateur.

Chaque décision de la plateforme est contestable. Le même registre que l'actuaire a signé est celui que vous pouvez contester. Si vous n'êtes pas d'accord avec la règle, la version ou la pondération des facteurs, la voie de recours est indiquée sur la lettre. Il y a quatre voies : l'examen interne avec un réviseur nommé, le Klachteninstituut, les tribunaux et le registre lui-même, qui est le même paquet qu'un tribunal verrait.

Votre question reçoit une réponse écrite, pas un chatbot.

Le réviseur qui a validé est nommé, pas anonyme.

La règle qui a déclenché est jointe à la décision, pas séparée.

La réclamation est payée, refusée ou envoyée pour examen avec une raison.

Une réclamation n'est plus une boîte noire. La décision, la règle et le réviseur sont réunis dès que vous signalez le sinistre. Si vous demandez, l'assureur peut vous montrer pourquoi elle a été payée, refusée ou envoyée pour examen. Quatre choses sont consignées au fur et à mesure de la réclamation : le résultat et sa raison, la règle qui a déclenché, le réviseur qui l'a validée par son nom, et une réponse écrite à toute question que vous posez ensuite.

Construit et exploité sous les règles de l'UE.

Quand votre assureur utilise Dweve, votre prime n'est pas un nombre deviné par une machine. Elle est liée à une règle déposée, à un enregistrement et à un actuaire nommé. Si vous demandez, ils peuvent vous montrer la règle qui a fixé le prix, en langage clair. Quatre choses l'accompagnent : un langage clair au lieu du jargon, la règle qui a réellement fixé le prix, un actuaire nommé et des données conservées selon les règles de l'UE.

Chaque sinistre produit le même enregistrement rejouable que chaque prime. Le même format de paquet couvre à la fois la tarification et les sinistres, de sorte que le récit ORSA s'appuie sur une source unique de vérité.

Réserve fixée selon la règle, examinateur nommé.

Expert assigné, photos et déclaration enregistrées.

Première déclaration de sinistre enregistrée, police jointe.

La tarification n'est pas la seule décision qui survit à un examen. Le tri des sinistres, le signalement de fraude et la constitution de réserves laissent tous le même paquet signé. Le sinistre, la règle, l'expert et la réserve sont réunis dès le moment où le sinistre est déclaré. Le modèle de fraude continue de fonctionner comme avant, enveloppé dans une couche qui épingle sa version et enregistre chaque caractéristique, chaque seuil et chaque approbation d'examinateur, de sorte qu'un refus pour fraude s'appuie sur un artefact. La constitution de réserves se rejoue dans les mêmes conditions : les méthodes chain-ladder, Bornhuetter-Ferguson et des sinistres attendus renvoient les mêmes chiffres lorsque le superviseur les rouvre.