Introduction
Une assurance ne peut transférer un risque que si ce risque peut être décrit, borné et documenté. Beaucoup de systèmes d’IA en production échouent à ce test. Ils changent après la signature du contrat. Leurs défaillances sont souvent réparties entre un fournisseur de modèle, un intégrateur, une consigne, une base de connaissances et un flux humain. La perte peut être réelle sans être facile à qualifier.
L’assurabilité de l’IA n’est donc pas la même chose que l’existence d’un produit « d’assurance IA ». C’est l’ensemble des conditions dans lesquelles une perte liée à un système d’IA peut entrer dans un contrat d’assurance sans se réduire à un aléa commercial non alloué ou à une allégation impossible à établir.
Cet article définit l’assurabilité de l’IA, la distingue des notions voisines et la situe par rapport à la mesure comportementale. La mesure peut étayer l’assurabilité. Elle ne crée pas de garantie, ne fixe pas une prime et ne statue pas sur un sinistre.
Définir l’assurabilité de l’IA
L’assurabilité de l’IA est la capacité d’une perte associée au développement, au déploiement ou à l’usage d’un système d’IA à être :
- identifiée comme un dommage plutôt que comme un simple écart d’activité
- rattachée à une activité, un système, une période et un rôle contractuel définis
- documentée dans des conditions établies
- bornée en sévérité, en fréquence et au regard des causes exclues
- transférée, en tout ou partie, par un contrat d’assurance
Un risque d’IA peut être opérationnellement grave et demeurer peu assurable si ces conditions ne sont pas réunies.
Ce que l’assurabilité de l’IA n’est pas
L’assurabilité de l’IA ne doit pas être confondue avec les éléments suivants :
- la simple disponibilité commerciale d’une police dédiée à l’IA
- une garantie d’éviction ou une garantie de propriété intellectuelle consentie par un éditeur
- la conformité réglementaire au règlement européen sur l’IA ou à tout autre texte
- un score de fiabilité, un résultat de benchmark ou un audit ponctuel
- un signal de mesure produit au runtime
Un signal peut éclairer plus tard une souscription ou l’instruction d’un sinistre. Il ne constitue pas, par lui-même, un verdict assurantiel, une constatation de responsabilité ou une décision tarifaire.
Conditions qui rendent un risque d’IA assurable
En pratique, l’assurabilité dépend de plusieurs conditions conjointement nécessaires.
Un objet de risque défini
L’activité assurée, le système et le cas d’usage doivent être décrits avec assez de précision pour qu’un contrat puisse s’y attacher. « Nous utilisons l’IA » n’est pas un objet de risque.
Un dommage séparable
La perte doit pouvoir être distinguée d’une simple sous-performance commerciale : un objectif de vente manqué, un texte marketing faible ou un gain de process trop lent ne constituent généralement pas un événement assurable.
Un chemin de preuve
Après un incident, il doit être possible de reconstituer, au moins en partie, quel système était en usage, selon quel protocole, avec quel versioning et avec quels contrôles humains actifs. L’absence de preuve n’établit pas l’absence de dommage. Elle limite ce qu’un contrat peut indemniser.
Un cadre temporel
Les systèmes d’IA dérivent. Une garantie qui suppose un système figé à la souscription est structurellement fragile. L’assurabilité s’améliore lorsque le changement dans le temps peut être observé plutôt que seulement déclaré. Ce point est développé dans Audit statique vs preuve comportementale continue.
Des rôles alloués
Le fournisseur, le déployeur, l’intégrateur et l’utilisateur n’ont pas les mêmes devoirs. Un contrat qui ne localise pas le rôle de l’assuré aura du mal à localiser sa perte.
Ce que l’assurabilité de l’IA n’est pas conçue pour absorber
Les amendes administratives, l’usage délibéré hors cadre et les pertes hors du cas d’usage déclaré restent en principe hors du noyau assurable. Ces limites sont traitées dans les articles suivants de la série.
Pourquoi les hypothèses classiques de souscription cèdent
La souscription entreprise classique suppose souvent que :
- le risque déclaré à la souscription reste stable
- un questionnaire périodique actualise cette déclaration
- un audit technique à T0 suffit comme proxy du comportement ultérieur
Les systèmes génératifs et agentiques contredisent ces hypothèses. Les fournisseurs de modèles mettent à jour leurs systèmes à distance. Les sources de retrieval changent. Les consignes et les outils sont révisés. Le volume et l’exposition financière fluctuent. Un dossier exact au moment de la souscription peut devenir incomplet sans aucun changement formel d’activité.
Le Silent AI est l’expression de marché de cet écart : des pertes liées à l’IA absorbées par des contrats qui n’ont été ni conçus ni tarifés pour les porter. Ce mécanisme est défini dans Silent AI : quand le risque génératif se cache dans les polices existantes.
Rapport à la métrologie comportementale
La métrologie comportementale ne rend pas un système assurable par elle-même. Elle peut, dans des conditions documentées, rendre trois choses plus traitables :
- l’observation d’un changement comportemental dans le temps, selon un protocole documenté
- la comparaison à une baseline
- la reconstitution de la manière dont un signal a été produit
Ces fonctions relèvent du corpus de métrologie de gouvernance, en particulier Qu’est-ce que la métrologie de gouvernance des IA ? et Signal vs verdict : principe fondamental d’une évaluation responsable des IA.
La frontière reste stricte :
- la métrologie produit des observations
- l’assurance interprète ces observations à l’intérieur d’un contrat
- les décideurs humains conservent l’autorité sur la garantie, l’exclusion et le règlement
NeoMundi produit des signaux de mesure comportementale au runtime à partir des sorties observées du modèle, dans des conditions documentées. Elle ne souscrit pas, ne tarife pas et ne statue pas sur les sinistres.
Limites de cette définition
Cette définition ne :
- n’affirme pas que toutes les pertes liées à l’IA sont assurables
- ne traite pas les produits de marché actuels comme complets ou équivalents
- ne convertit pas un signal runtime en preuve de faute
- n’exige pas la conservation centrale permanente des consignes et des réponses
- ne présente aucun projet d’instrumentation non abouti comme un produit disponible
L’assurabilité est une propriété d’un risque à l’intérieur d’un contrat. Ce n’est pas une propriété d’un modèle isolé.
Conclusion
L’assurabilité de l’IA est le point à partir duquel une perte liée à l’IA devient contractuellement utilisable : identifiable, documentée, bornée et transférable. Beaucoup de systèmes en production sont utilisés à grande échelle avant que ce point soit atteint.
Le reste de cette série examine la forme de marché de ce problème (Silent AI), le problème de la preuve dans le temps, la matérialité financière, l’appui limité du règlement européen sur l’IA, la structure des couvertures existantes, et les conditions dans lesquelles un sinistre peut être instruit sans transformer la mesure en verdict.