LâAutoritĂ© australienne de supervision financiĂšre alerte les Ă©tablissements rĂ©gulĂ©s sur des lacunes dans la gouvernance et lâassurance des agents dâIA. Alors que banques et organismes de retraite dĂ©veloppent lâusage de lâIA, y compris dans des opĂ©rations destinĂ©es aux clients, le rĂ©gulateur estime que plusieurs risques restent insuffisamment cadrĂ©s, notamment autour du contrĂŽle, de la rĂ©silience opĂ©rationnelle et de la sĂ©curitĂ©.
Une revue ciblée qui met en évidence des écarts
LâAPRA a menĂ©, fin 2025, un examen ciblĂ© portant sur des entitĂ©s importantes afin dâĂ©valuer lâadoption de lâIA et les risques prudentiels associĂ©s. Le rĂ©gulateur indique que lâIA est dĂ©jĂ utilisĂ©e dans toutes les structures Ă©tudiĂ©es, mais que le niveau de maturitĂ© varie fortement sur la gestion des risques et la capacitĂ© Ă maintenir les opĂ©rations en cas de dysfonctionnement.
Selon lâautoritĂ©, les conseils dâadministration manifestent un intĂ©rĂȘt marquĂ© pour les gains de productivitĂ© et lâamĂ©lioration de lâexpĂ©rience client. En revanche, beaucoup dâentre eux seraient encore en phase de construction sur la maniĂšre dâencadrer les risques liĂ©s Ă lâIA, ce qui limite la qualitĂ© du pilotage et du contrĂŽle.
Des limites dans le contrÎle des risques liés aux modÚles
LâAPRA estime que certains conseils sâappuient trop largement sur des prĂ©sentations fournisseurs et sur des synthĂšses, sans toujours exercer une analyse approfondie des risques, par exemple le comportement imprĂ©visible des modĂšles ou lâimpact dâune dĂ©faillance de lâIA sur des opĂ©rations critiques.
Le rĂ©gulateur recommande de renforcer la comprĂ©hension de lâIA au sein des instances dirigeantes afin dâĂ©tablir une stratĂ©gie cohĂ©rente. Il appelle Ă©galement Ă aligner cette stratĂ©gie avec lâappĂ©tit pour le risque de lâinstitution, et Ă dĂ©finir des procĂ©dures de suivi et des actions Ă dĂ©clencher en cas dâerreur.
Concernant les usages, lâAPRA cite notamment des expĂ©rimentations dans lâingĂ©nierie logicielle, le tri des dossiers de rĂ©clamation ou encore le traitement des demandes de prĂȘt. Dâautres cas dâusage incluent la lutte contre les fraudes et les arnaques, ainsi que lâassistance aux interactions avec les clients.
Le rĂ©gulateur met en garde contre une approche qui traiterait le risque de lâIA comme un simple prolongement dâautres technologies. LâAPRA souligne que le fonctionnement des modĂšles, les biais possibles et la maniĂšre dont leurs sorties Ă©voluent ne se gĂšrent pas de la mĂȘme façon.
Surveillance du comportement, changements et désengagement
Parmi les points jugĂ©s insuffisants, lâautoritĂ© relĂšve des lacunes dans le suivi du comportement des modĂšles, la gestion des changements et le dĂ©sengagement (la sortie progressive) des solutions dâIA. Elle demande Ă©galement de tenir Ă jour des inventaires des outils dâIA et de clarifier la responsabilitĂ© nominative pour chaque instance dĂ©ployĂ©e.
LâAPRA insiste enfin sur la nĂ©cessitĂ© de maintenir une implication humaine pour les dĂ©cisions considĂ©rĂ©es comme Ă haut risque.
Des menaces qui Ă©voluent avec lâIA
La cybersĂ©curitĂ© figure aussi au cĆur des prĂ©occupations. Le rĂ©gulateur indique que lâadoption de lâIA peut modifier lâenvironnement des menaces en ajoutant de nouveaux vecteurs dâattaque, tels que lâinjection de prompts ou des intĂ©grations insuffisamment sĂ©curisĂ©es.
Dans certains cas, les pratiques dâidentitĂ© et de contrĂŽle des accĂšs ne tiendraient pas compte dâĂ©lĂ©ments non humains, comme les agents dâIA eux-mĂȘmes. Par ailleurs, lâimportance prise par lâingĂ©nierie logicielle assistĂ©e par lâIA augmente la pression sur les contrĂŽles de changement et de mise en production.
LâAPRA demande dâappliquer des mesures de sĂ©curitĂ© adaptĂ©es aux workflows dâagents autonomes ou agentic, incluant la gestion des accĂšs privilĂ©giĂ©s, les rĂšgles de configuration et la mise Ă jour logicielle. Le rĂ©gulateur recommande aussi de tester la sĂ©curitĂ© du code gĂ©nĂ©rĂ© par lâIA.
Autre sujet : la dĂ©pendance Ă un fournisseur unique pour plusieurs instances dâIA. LâAPRA note que seules quelques entitĂ©s seraient en mesure de prĂ©senter un plan de sortie ou une stratĂ©gie de remplacement en cas de changement de fournisseur.
LâautoritĂ© rappelle enfin quâune partie de lâIA peut se retrouver dans des dĂ©pendances amont, parfois sans que les institutions aient une visibilitĂ© complĂšte.
Gouvernance de lâaccĂšs : lâaccent mis sur les identitĂ©s non humaines
La question de lâidentitĂ© et des permissions fait Ă©cho Ă des travaux de standardisation, notamment au sein de lâAlliance FIDO. Un groupe de travail sur lâauthentification agentique prĂ©pare des spĂ©cifications pour des transactions dĂ©clenchĂ©es par des agents.
FIDO estime que plusieurs modĂšles existants dâauthentification et dâautorisation ont Ă©tĂ© conçus pour des interactions entre humains, et non pour des actions dĂ©lĂ©guĂ©es effectuĂ©es par des systĂšmes. Le point central est de pouvoir vĂ©rifier qui (ou quoi) autorise une action et dans quelles conditions.
Dans cet écosystÚme, certains fournisseurs présentent leurs approches. Des ressources de sécurité, conçues pour relier les contrÎles de sécurité à des environnements impliquant des modÚles de langage et des agents, sont également mises à disposition pour aider les organisations à cartographier les exigences de contrÎle.
Sur le terrain, la mise en Ćuvre de ces principes peut sâappuyer sur des solutions de gestion des accĂšs et des identitĂ©s. Ă titre indicatif, des organisations peuvent sâintĂ©resser Ă des plateformes de gestion des identitĂ©s comme des logiciels IAM/gestion des accĂšs, afin de mieux encadrer les privilĂšges et les droits applicables aux composants non humains. De mĂȘme, la journalisation et le suivi des modifications peuvent ĂȘtre renforcĂ©s via des outils de collecte et dâanalyse des journaux (SIEM/log management), utiles pour dĂ©tecter des anomalies liĂ©es Ă des intĂ©grations ou Ă des actions dâagents.