Avertissement d’AXA XL sur la gouvernance de l’IA : l’adoption devance la supervision
AXA XL affirme que l’adoption de l’IA a franchi un seuil dangereux : les systèmes intègrent des flux de travail critiques alors que la gouvernance, la sécurité et la réponse aux incidents accusent encore plusieurs longueurs de retard.
L’avertissement d’AXA XL sur la gouvernance de l’IA a été publié le 23 septembre dans le cadre d’un rapport conjoint avec le cabinet de conseil en renseignement et cybersécurité S-RM. Il soutient que les organisations doivent cesser de traiter le risque lié à l’IA comme un simple projet de conformité circonscrit. L’IA touche désormais aux informations sensibles, à l’accès aux logiciels, aux décisions d’affaires et aux relations avec les fournisseurs externes.
Cette situation crée une tension entre la vitesse de déploiement et le contrôle opérationnel. Les entreprises veulent intégrer des agents et l’IA générative à leurs flux de travail quotidiens, mais nombre d’entre elles ne peuvent pas identifier de manière fiable chaque système, responsable, source de données ou dépendance en aval.
L’avertissement revêt un poids supplémentaire, car AXA XL aborde la question sous l’angle de l’assurance et du conseil en risques. Les assureurs doivent comprendre comment les défaillances surviennent, jusqu’où elles peuvent s’aggraver et si différentes pertes sont liées. L’IA complique ces trois questions.
Le problème central dépasse donc largement le cas d’un modèle qui produit occasionnellement une réponse incorrecte. Les entreprises accordent aux systèmes d’IA davantage d’accès et d’autorité avant d’avoir mis en place une supervision continue autour de ces accès.
L’avertissement d’AXA XL sur la gouvernance de l’IA étend le risque au-delà de la conformité
Le changement le plus important du rapport consiste à traiter la défaillance de l’IA comme un problème de résilience d’entreprise, et non simplement de qualité des modèles.
AXA XL est la division d’AXA dédiée aux risques de dommages, de responsabilité civile et spécialisés. S-RM conseille les organisations en matière de cybersécurité, de renseignement et de risque d’entreprise. Leur rapport sur une IA résiliente relie le déploiement de l’IA aux incidents cyber, à la fraude, à la responsabilité civile, aux interruptions d’activité et aux défaillances impliquant des tiers.
Le calendrier reflète la rapidité avec laquelle l’IA s’est imposée dans les opérations courantes. AXA XL cite une étude selon laquelle 88 % des organisations utilisent l’IA dans au moins une fonction métier. L’adoption s’étend désormais au-delà des expérimentations contrôlées et des chatbots isolés.
Les employés utilisent des systèmes génératifs pour résumer des dossiers, rédiger des communications, analyser des documents et étayer des décisions. Les éditeurs de logiciels intègrent également l’IA dans des produits déjà utilisés par leurs clients. Une organisation peut donc acquérir une nouvelle dépendance à l’IA sans valider un projet d’IA distinct.
Les systèmes agentiques rehaussent encore les enjeux. Un agent d’IA est un logiciel capable de poursuivre un objectif en plusieurs étapes, parfois en utilisant des outils externes ou en modifiant d’autres systèmes. Son risque dépend de ce qu’il peut lire, de ce qu’il peut modifier et de l’existence d’une revue humaine de ses actions.
AXA XL identifie cinq priorités pour les organisations confrontées à cette transition. Les dirigeants ont besoin d’une responsabilité clairement établie pour les systèmes approuvés, les fonctionnalités d’IA intégrées et le shadow AI. Ils doivent protéger les données sensibles tout en renforçant les contrôles d’identité et d’accès.
Les organisations ont également besoin d’une gouvernance couvrant tout le cycle de vie, de la collecte des données au développement, au déploiement, à la surveillance et à la réponse aux incidents. La diligence raisonnable envers les fournisseurs doit tenir compte des dépendances à l’IA au sein des services externes. Enfin, les entreprises devraient se préparer à des pertes qui traversent les catégories d’assurance traditionnelles.
Ce dernier point est important. Un même événement peut commencer par un modèle manipulé, exposer des informations confidentielles, interrompre les opérations et déclencher une réclamation en responsabilité. Le même incident peut concerner la cybersécurité, la confidentialité, les services professionnels et les décisions de gestion.
Jonathan Salter, responsable du conseil en risques chez AXA XL, a résumé directement cette tension. L’IA s’intègre aux systèmes dont dépendent les organisations, a-t-il déclaré, tandis que la gouvernance ne suit pas toujours le rythme.
Son approche déplace la question de « Ce modèle est-il précis ? » vers « Que se passe-t-il pour l’entreprise lorsque ce système échoue ? » Cette question exige des responsables désignés, des voies d’escalade, des contrôles testés et des plans de reprise.
Le rapport rejette également un raccourci courant. Un examen de sécurité avant le lancement ne garantit pas un contrôle continu après le déploiement. Les modèles évoluent, les fournisseurs mettent à jour leurs services, les employés découvrent de nouveaux usages et les autorisations d’accès s’étendent.
AXA XL indique que 64 % des organisations évaluent désormais la sécurité des outils d’IA avant leur déploiement, contre 37 % un an auparavant. Cette amélioration ne traite toutefois que du point d’entrée. Le risque persiste après qu’un outil a passé son premier examen.
Telle est la première implication majeure de l’avertissement d’AXA XL sur la gouvernance de l’IA : l’approbation ne peut pas tenir lieu de certificat permanent de sécurité. La supervision doit accompagner le système tout au long de sa vie opérationnelle.
L’adoption de l’IA provoque une crise d’inventaire et de responsabilité
Une entreprise ne peut pas gouverner les systèmes d’IA qu’elle ne peut ni trouver, ni classer, ni attribuer à un responsable identifiable.
Le problème d’inventaire commence par la fragmentation. Certaines applications d’IA arrivent par l’intermédiaire de programmes technologiques formels. D’autres apparaissent comme fonctionnalités au sein de plateformes de service client, de suites de productivité, de produits de sécurité ou d’outils pour développeurs.
Les employés peuvent également utiliser des services grand public sans autorisation. Cette pratique, souvent appelée shadow AI, peut exposer des informations professionnelles en dehors des contrôles approuvés. Le risque ne se limite pas aux violations délibérées des politiques internes.
Un collaborateur peut raisonnablement penser qu’une fonctionnalité logicielle ordinaire est couverte par l’approbation existante de l’entreprise. Pourtant, cette fonctionnalité peut transmettre des données à un autre fournisseur de modèles, conserver les prompts selon des conditions différentes ou générer du contenu via un service externe.
Un inventaire efficace exige donc davantage qu’une liste de noms de modèles. Il doit relier chaque cas d’usage à un responsable métier, un responsable technique, un objectif, des sources de données, des autorisations, un fournisseur, des utilisateurs concernés et un processus de reprise.
Il doit également indiquer si le système se contente de recommander des actions ou peut les exécuter. Un outil de synthèse doté d’un accès en lecture seule présente une exposition différente de celle d’un agent capable d’envoyer des messages, d’approuver des transactions ou de modifier des données de production.
Rebiah Bardot-Girard, responsable des services de conseil en risque cyber chez AXA XL, estime que les organisations doivent savoir où l’IA opère, à quelles informations elle peut accéder et où elle peut influencer l’action. Cet inventaire devient le point de départ de la résilience.
La recommandation correspond étroitement au cadre de gestion des risques liés à l’IA maintenu par le National Institute of Standards and Technology des États-Unis. Le NIST décrit la gouvernance comme une fonction continue tout au long de la durée de vie d’un système d’IA.
Son cadre appelle à mettre en place des mécanismes permettant d’inventorier les systèmes d’IA selon les priorités de risque de l’organisation. Il demande aussi aux organisations de documenter les responsabilités, de surveiller les contrôles, d’évaluer les composants tiers et de planifier un retrait sécurisé.
Ces activités peuvent sembler administratives, mais elles déterminent la capacité d’une entreprise à réagir lors d’un incident. Une équipe de sécurité ne peut pas révoquer rapidement un accès si elle ignore quels identifiants utilise un agent. Les équipes juridiques ne peuvent pas évaluer l’exposition sans savoir quels dossiers sont entrés dans le système.
Les responsables métier ont également besoin d’une documentation suffisante pour distinguer un comportement intentionnel d’une défaillance. Si un agent envoie une communication non autorisée, les enquêteurs doivent reconstituer les entrées, la version du modèle, les instructions, les appels d’outils, les approbations et les actions résultantes.
Ces éléments de preuve peuvent être dispersés entre des tableaux de bord de fournisseurs, des applications locales, des systèmes d’identité et des messages d’employés. Sans dossier défini, l’entreprise peut peiner à déterminer ce qui s’est produit ou si la même faiblesse subsiste ailleurs.
La tenue d’une base de connaissances consultable peut aider les équipes à organiser les politiques et les dossiers techniques. Toutefois, la documentation n’est utile que lorsque les responsables la maintiennent reliée aux systèmes en production.
La responsabilité constitue la seconde moitié du problème. L’IA franchit fréquemment les frontières organisationnelles, y compris entre la sécurité, la confidentialité, le juridique, les achats, le produit et les opérations. Chaque équipe peut posséder un contrôle, sans que personne ne soit responsable du résultat métier dans son ensemble.
Un développeur de modèles peut gérer les tests, mais pas les informations fournies par les employés. Les achats peuvent examiner les clauses contractuelles, mais pas les autorisations opérationnelles. La sécurité peut surveiller les événements techniques sans comprendre les conséquences d’une décision métier erronée.
Une responsabilité claire ne signifie pas qu’il faut attribuer chaque problème à un bureau central de l’IA. Elle consiste à désigner qui accepte le risque, qui maintient les contrôles, qui surveille le comportement et qui peut suspendre le système.
Cette dernière autorité est essentielle. Les équipes ont besoin de conditions prédéfinies pour ralentir, isoler ou désactiver un flux de travail d’IA. Dans le cas contraire, la pression commerciale peut maintenir en service un système douteux pendant que les services débattent de la responsabilité.
Le message d’AXA XL sur la gouvernance de l’IA n’est donc pas simplement « rédigez une politique ». Il est : « reliez chaque capacité déployée à une autorité, à des éléments de preuve et à une voie de réponse ».
Le véritable arbitrage oppose l’accès au contrôle
L’IA devient plus utile à mesure qu’elle gagne en contexte et en autorité, mais ces mêmes qualités accroissent les dommages qu’un système compromis ou peu fiable peut causer.
Un chatbot autonome peut produire un texte incorrect. Un agent intégré peut récupérer des dossiers privés, appeler des outils internes et agir sur le résultat. Le second système peut apporter davantage de valeur métier, mais il crée aussi un chemin plus large entre l’erreur et la perte.
AXA XL et S-RM identifient parmi les menaces pertinentes les fuites de données, l’injection de prompts, la manipulation de modèles, les résultats peu fiables, le shadow AI et l’autonomie excessive.
L’injection de prompts survient lorsqu’un contenu malveillant ou non fiable détourne un modèle de ses instructions prévues. L’attaque peut se cacher dans un document, une page web, un e-mail ou une source de données traitée par le système.
Le danger s’accroît lorsqu’un modèle peut appeler des outils. Une réponse manipulée peut ne plus rester un simple texte affiché à l’écran. Elle pourrait influencer une requête de base de données, un message sortant, une décision de flux de travail ou un transfert d’informations.
Les contrôles d’accès traditionnels restent importants dans cet environnement. Un système d’IA ne devrait pas recevoir d’autorisations étendues simplement parce que les utilisateurs trouvent cet accès plus pratique. Son identité ne devrait obtenir que les ressources requises pour le cas d’usage approuvé.
Les autorisations doivent également encadrer les actions. Un accès en lecture n’est pas équivalent à un accès en écriture. Rédiger une réponse diffère de son envoi, tout comme recommander une transaction diffère de son approbation.
La supervision humaine reste importante, mais cette expression peut masquer des contrôles faibles. Un réviseur nominal ne peut pas assurer une supervision significative si des centaines de résultats arrivent trop rapidement ou sans contexte pertinent.
Les organisations doivent définir quelles décisions nécessitent une approbation, quels éléments de preuve le réviseur reçoit et comment le système se comporte lorsque personne ne répond. Elles doivent aussi mesurer si les réviseurs acceptent régulièrement des résultats sans les examiner.
Cet arbitrage devient plus net à mesure que les entreprises connectent des agents à des processus métier sensibles. L’utilité du système peut dépendre des historiques clients, de la documentation technique, des dossiers financiers, des contrats ou des données des employés.
Ce contexte peut améliorer la pertinence. Il peut aussi exposer des informations précieuses par le biais d’intégrations non sécurisées, d’une conservation excessive, de comptes compromis ou de prompts imprudents.
Les cinq fondations de conception sécurisée d’AXA XL abordent cette question par la gouvernance des données, la sécurisation des modèles et des applications, des écosystèmes de fournisseurs résilients, les contrôles d’accès et la surveillance continue. Aucune ne procure, à elle seule, une protection complète.
La gouvernance des données définit les informations que le système peut utiliser. La conception sécurisée des applications encadre les entrées, les sorties et les connexions aux outils. Les contrôles d’identité limitent ce que le système peut atteindre.
La surveillance doit ensuite détecter les accès inattendus, l’utilisation inhabituelle d’outils, les changements dans les résultats et les tentatives de violation des politiques. Les plans de réponse aux incidents doivent couvrir à la fois le confinement technique et les conséquences pour l’entreprise.
L’organisation AXA au sens large illustre comment ces contrôles peuvent soutenir le déploiement plutôt que l’interdire. AXA décrit un programme de gouvernance de l’IA comprenant une bibliothèque des risques liés à l’IA, des outils d’équité, des revues d’experts et des orientations à l’échelle du groupe.
AXA développe également une infrastructure d’IA partagée dans l’ensemble de ses opérations mondiales. Insurance Business a indiqué que son Global AI Hub était opérationnel dans cinq entités en septembre 2026, y compris pour des travaux impliquant AXA XL.
Cela crée un contraste instructif. AXA ne met pas les entreprises en garde contre l’IA tout en restant à l’écart de cette technologie. Le groupe déploie l’IA tout en soutenant que l’accès, la gouvernance et la responsabilité opérationnelle doivent progresser conjointement.
Cela ne prouve pas que les propres contrôles d’AXA éliminent tous les risques. Ses descriptions publiques ne peuvent se substituer à des tests indépendants ou à des preuves tirées d’incidents réels. Elles montrent toutefois que le débat ne se situe plus entre adoption et non-adoption.
L’enjeu pratique oppose l’adoption maîtrisée à l’adoption insuffisamment surveillée. La première considère l’accès comme un privilège limité, lié à des preuves. La seconde traite la rapidité d’intégration comme un succès, puis tente d’ajouter des contrôles ultérieurement.
L’assurance révèle ce que les cadres de gouvernance ne peuvent pas encore mesurer
La perspective de l’assurance révèle une vérité difficile : les organisations peuvent décrire les contrôles de l’IA plus facilement que les assureurs ne peuvent quantifier l’exposition aux pertes qui en résulte.
L’assurance repose sur des informations concernant la fréquence des pertes, leur gravité et la possibilité que de nombreux assurés soient touchés simultanément. L’IA générative offre peu d’historique de sinistres suffisamment mature pour répondre à ces questions.
Un seul système défaillant peut également affecter de nombreuses entreprises. Beaucoup d’organisations dépendent des mêmes modèles fondamentaux, fournisseurs de cloud, services logiciels ou pipelines de données. Une faiblesse commune pourrait produire des pertes corrélées dans de nombreuses entreprises assurées.
Ces relations compliquent la mutualisation traditionnelle des risques. Un assureur peut penser avoir diversifié son exposition entre plusieurs secteurs alors que ces clients dépendent du même fournisseur d’IA sous-jacent.
Les catégories de défaillance peuvent également se chevaucher. Une réponse hallucinée peut entraîner une responsabilité professionnelle. Une exposition de données peut déclencher des réclamations liées à la vie privée et au cyberrisque. Une décision automatisée peut susciter une action réglementaire ou des allégations de discrimination.
Une interruption affectant un flux de travail dépendant de l’IA pourrait engendrer des pertes opérationnelles. Une fraude impliquant des médias synthétiques pourrait interagir avec la couverture criminalité, les contrôles d’identité et les procédures internes d’autorisation.
Cette complexité explique pourquoi AXA XL demande aux entreprises de se préparer à des scénarios couvrant le cyberrisque, la fraude, la responsabilité et l’interruption d’activité. L’organisation doit examiner l’ensemble de la chaîne des conséquences, et non seulement le premier événement technique.
Une récente analyse du marché de l’assurance du Center for Strategic and International Studies décrit des obstacles similaires. Elle soutient que des données de déploiement limitées et l’asymétrie d’information restreignent la capacité des assureurs à évaluer le risque lié à l’IA.
L’asymétrie d’information signifie que le client en sait davantage sur son exposition que l’assureur. Une entreprise sait quels modèles elle utilise, quelles informations ils traitent, comment les prompts sont gérés et si la revue humaine fonctionne réellement.
L’assureur peut ne recevoir que des questionnaires ou des descriptions générales des contrôles. Il ne peut pas facilement observer le comportement quotidien au sein de chaque déploiement.
Cela donne aux assureurs une raison solide d’exiger de meilleures preuves. Un inventaire de l’IA, des journaux d’accès, des registres d’incidents, des résultats de tests et une documentation fournisseur peuvent rendre le risque plus visible.
Cependant, les artefacts de gouvernance ne sont pas la même chose que la performance de la gouvernance. Une politique complète ne prouve pas que les employés la suivent. Un résultat de test ne garantit pas qu’une mise à jour du fournisseur préserve le comportement antérieur.
Une lecture sceptique des recommandations d’AXA XL commence ici. Les cinq priorités sont judicieuses, mais le rapport ne fournit pas de système de mesure universel permettant de prouver qu’une entreprise les a mises en œuvre efficacement.
Les organisations diffèrent fortement par leurs systèmes, leurs obligations réglementaires, leurs ressources et leurs cas d’utilisation. Un contrôle adapté à la rédaction de textes marketing peut être insuffisant pour la santé, le crédit, l’emploi ou les infrastructures critiques.
Le comportement de l’IA peut également varier selon le contexte. Un système peut réussir un test contrôlé, puis échouer lorsque les utilisateurs fournissent des entrées inhabituelles ou lorsque les outils connectés renvoient des données inattendues.
NIST a souligné l’importance des tests, de l’évaluation, de la vérification et de la validation tout au long du cycle de vie de l’IA. Ses travaux de 2026 comprennent un projet de cadre destiné à évaluer les résultats réels pour les modèles, les systèmes multimodaux et les agents.
Cette orientation est importante, car les revues statiques ne peuvent pas couvrir toutes les conditions opérationnelles. Les organisations ont besoin d’évaluations répétables, liées aux conséquences concrètes pour l’entreprise.
Elles doivent aussi décider quels risques résiduels accepter, réduire, éviter ou transférer. L’assurance peut absorber une partie d’une perte financière, mais elle ne peut pas restaurer des informations divulguées, annuler une décision préjudiciable ou réparer immédiatement une confiance endommagée.
La couverture peut aussi comporter des frontières entre les polices cyber, responsabilité professionnelle, criminalité et autres. Un incident lié à l’IA qui franchit ces frontières peut susciter des litiges sur la police qui doit intervenir.
Les entreprises devraient donc éviter de considérer l’assurance comme un substitut à la gouvernance. Les assureurs, quant à eux, ne peuvent pas supposer qu’un cadre de gouvernance rend automatiquement un risque mesurable.
L’interprétation la plus solide de la position d’AXA XL sur le risque lié à l’IA est conditionnelle. Une meilleure gouvernance produit de meilleures preuves, et de meilleures preuves peuvent soutenir une souscription plus éclairée. Aucune des deux ne garantit que chaque exposition à l’IA devienne assurable.
La réglementation augmente le coût de la dérive de gouvernance
L’écart entre le déploiement et la supervision devient plus coûteux lorsque les systèmes d’IA traversent les juridictions, les fonctions métier et les décisions réglementées.
Les règles relatives à l’IA ne se présentent pas sous la forme d’une norme universelle de conformité. Les organisations doivent tenir compte de la vie privée, de la cybersécurité, de la protection des consommateurs, de la propriété intellectuelle, de l’emploi, de la réglementation sectorielle et des obligations contractuelles.
L’AI Act de l’Union européenne ajoute des obligations fondées sur le risque pour les systèmes entrant dans son champ d’application. D’autres juridictions appliquent des lois existantes ou élaborent des règles spécifiques à l’IA différentes. Une entreprise multinationale peut faire face à plusieurs obligations autour d’un même flux de travail.
Cette fragmentation crée une pression opérationnelle. Un système approuvé pour un marché ou un objectif peut exiger ailleurs une documentation, des tests ou une supervision humaine différents.
Les relations avec les fournisseurs compliquent le problème. Un client peut ne pas concevoir le modèle, contrôler ses données d’entraînement ou décider du moment où le fournisseur le modifie. Pourtant, le client décide toujours de la manière dont le système affecte les personnes et les processus métier.
Les contrats doivent traiter les responsabilités en matière de sécurité, la notification des incidents, le traitement des données, les droits d’audit, les sous-traitants, les changements de modèle, la continuité du service et la résiliation. Les équipes achats ont également besoin d’un contexte technique suffisant pour évaluer ces dispositions.
Une revue générique de logiciels peut passer à côté de dépendances propres à l’IA. Le service peut s’appuyer sur plusieurs fournisseurs de modèles, systèmes de récupération, processeurs de données et outils de surveillance. Chaque composant ajoute un point supplémentaire où le comportement ou l’exposition peut évoluer.
La recommandation d’AXA XL en faveur d’une diligence raisonnable envers les fournisseurs va donc au-delà de la simple vérification de la publication par un prestataire de principes d’IA responsable. Les acheteurs ont besoin de preuves liées au service réel et au cas d’utilisation.
Ils doivent savoir quelle partie surveille le comportement du modèle, qui conserve les journaux et à quelle vitesse le fournisseur signale un incident. Ils doivent également comprendre ce qu’il advient des données client après la fin du contrat.
Cela ne signifie pas que chaque organisation peut inspecter le code source ou le corpus d’entraînement d’un fournisseur. Beaucoup de prestataires ne divulgueront pas ces informations. Cela signifie que les acheteurs doivent identifier l’incertitude qui en résulte et déterminer si le cas d’utilisation peut la tolérer.
Une organisation peut accepter une transparence limitée pour une assistance à la rédaction à faible risque. Elle devrait exiger des preuves plus solides avant de s’appuyer sur le même fournisseur pour des décisions importantes ou des actions autonomes.
Les constats sur les risques futurs d’AXA pour 2025 ont montré pourquoi cet écart de gouvernance attire déjà l’attention. Les experts ont classé le risque lié à l’IA et aux mégadonnées au quatrième rang mondial.
Parmi les répondants ayant sélectionné l’IA comme risque majeur, 43 % des experts ont cité les menaces pour les intérêts ou les droits humains comme leur principale préoccupation. Le manque de transparence et l’incohérence de la réglementation venaient ensuite.
Seuls 11 % de ces experts estimaient que les autorités publiques étaient bien préparées aux risques liés à l’IA et aux mégadonnées. Les répondants ont privilégié un renforcement de la réglementation et de meilleurs cadres de gouvernance des risques comme réponses publiques.
Ces chiffres ne mesurent pas la qualité de la gouvernance au sein des entreprises individuelles. Ils montrent toutefois une inquiétude répandue selon laquelle les institutions existantes n’ont pas suivi le rythme de la technologie.
La dérive de gouvernance se produit lorsque le système réel évolue plus vite que son environnement de contrôle documenté. Une nouvelle fonctionnalité apparaît, une version de modèle change, les utilisateurs étendent le flux de travail ou un fournisseur ajoute une intégration.
La revue initiale peut rester archivée alors que ses hypothèses deviennent obsolètes. Dans cette situation, la conformité formelle crée une fausse impression de confiance.
La supervision continue doit donc inclure la gestion des changements. Les équipes ont besoin de déclencheurs pour renouveler les tests lorsque les modèles, les données, les outils, les autorisations ou les usages prévus évoluent.
Elles ont également besoin de retours issus des incidents et des quasi-incidents. Un événement ne causant aucune perte peut néanmoins révéler des contrôles d’accès faibles, une responsabilité ambiguë ou un processus d’escalade peu fiable.
La question réglementaire n’est pas simplement de savoir si une entreprise dispose d’une politique d’IA. Elle est de savoir si cette politique décrit encore ce que font ses systèmes.
Trois signaux montreront si la supervision rattrape son retard
La prochaine étape de l’IA d’entreprise sera jugée sur des preuves opérationnelles, et non sur le nombre de principes de gouvernance qu’une entreprise publie.
Le premier signal sera de savoir si les entreprises construisent des inventaires fiables incluant l’IA intégrée et non autorisée. Cette mesure va au-delà du simple décompte des modèles approuvés.
Un inventaire crédible devrait relier les systèmes aux données, aux autorisations, aux fournisseurs, aux responsables et aux conséquences pour l’entreprise. Il devrait également identifier les agents capables d’agir, et pas seulement de générer du contenu.
Si les organisations commencent à divulguer la couverture de leurs inventaires, les résultats d’audit ou les réductions de l’utilisation inconnue de l’IA, le diagnostic d’AXA XL gagnera un soutien pratique. Cela montrerait que les entreprises reconnaissent la visibilité comme fondement du contrôle.
Si la plupart des entreprises continuent de s’appuyer sur des listes d’outils auto-déclarées et des approbations ponctuelles, l’écart de gouvernance persistera. L’IA fantôme et les fonctionnalités intégrées des fournisseurs continueront de se développer en dehors de toute revue formelle.
Le deuxième signal sera l’adoption de tests continus et d’exercices de simulation d’incidents. Les évaluations de sécurité avant déploiement se développent, mais AXA XL soutient que les revues de lancement sont insuffisantes.
Les organisations devraient tester l’injection de prompts, les fuites de données, les autorisations excessives, les résultats peu fiables et les pannes de fournisseurs. Les exercices devraient impliquer les équipes juridiques, de sécurité, des opérations, de communication et les responsables métier.
Les tests les plus utiles se concentreront sur les conséquences. L’entreprise peut-elle détecter l’utilisation non autorisée d’outils ? Peut-elle isoler les identifiants d’un agent ? Peut-elle reconstituer une décision et notifier les parties concernées ?
Un ensemble croissant de données réelles sur les incidents renforcerait à la fois la gouvernance et l’assurance. Il pourrait aider les organisations à comparer leurs contrôles tout en donnant aux assureurs de meilleures informations sur la fréquence et la gravité.
L’absence de preuves partagées sur les incidents affaiblirait la confiance. Des entreprises pourraient revendiquer une supervision plus solide tout en répétant des défaillances qui restent invisibles en dehors de leurs propres systèmes.
Le troisième signal concerne la question de savoir si les assureurs et les régulateurs demandent des preuves comparables. Surveillez les questions de souscription portant sur les inventaires d’IA, les contrôles d’accès, la supervision humaine, les dépendances vis-à-vis des fournisseurs et la surveillance.
Observez également comment les régulateurs traduisent de grands principes en attentes précises en matière de documentation et de tests. Des exigences de preuve plus claires peuvent réduire l’incertitude pour les acheteurs, les fournisseurs et les assureurs.
La mauvaise réponse serait une course à la documentation. Les entreprises peuvent produire des politiques détaillées sans contrôler leurs systèmes en production. Les preuves devraient refléter les autorisations réelles, les comportements, la surveillance et la capacité de réponse.
Une meilleure réponse consiste à relier la gouvernance aux décisions de déploiement. Les systèmes à risque plus élevé devraient être soumis à des contrôles renforcés, à des tests plus fréquents et à des règles de suspension plus claires. Les usages moins risqués devraient faire l’objet d’un traitement proportionné.
Pour les développeurs et les équipes produit, cela signifie concevoir l’observabilité et la revue dans le flux de travail avant le lancement. Des journaux ajoutés après un incident pourraient ne pas permettre de reconstituer le contexte manquant.
Les acheteurs en entreprise devraient demander à quoi un produit peut accéder, ce qu’il peut modifier et comment son fournisseur communique les mises à jour. Ils devraient également déterminer qui est responsable des défaillances après l’intégration.
Les travailleurs du savoir doivent comprendre que des fonctionnalités d’IA pratiques peuvent créer une exposition pour l’organisation. Les dossiers sensibles, les informations clients, la stratégie interne et les documents propriétaires exigent des circuits de traitement approuvés.
L’avertissement d’AXA XL sur la gouvernance de l’IA remet finalement en question un modèle de déploiement bien connu : lancer d’abord, établir les responsabilités plus tard et ajouter la surveillance après qu’un problème survient.
Les entreprises n’ont pas besoin d’éliminer tous les risques liés à l’IA avant d’utiliser cette technologie. Elles doivent toutefois savoir quels risques elles acceptent et qui peut agir lorsque les hypothèses se révèlent erronées.
Les un à trois prochains mois devraient montrer si les entreprises réagissent par des changements opérationnels ou par un langage politique supplémentaire. Recherchez des inventaires complets, des tests répétés tout au long du cycle de vie et des questions de souscription fondées sur des preuves.
Ces signaux compteront davantage qu’une nouvelle vague de principes sur l’IA. Votre organisation a-t-elle recensé chaque système d’IA pouvant accéder à des données sensibles ou influencer une action commerciale, et peut-elle prouver que cette cartographie reste à jour ?
