Qui est autorisé à désactiver l’IA d’une banque ?
Contexte et enjeux
Dans le secteur bancaire, très peu d’établissements ont clairement défini la personne ou le groupe autorisé à couper le système d’IA défaillant. Sans un kill‑switch effectif, la simple existence d’un dispositif d’arrêt ne suffit pas ; il faut un propriétaire nommé capable d’agir rapidement et d’expliquer la défaillance aux régulateurs.
Problèmes de gouvernance actuels
De nombreuses banques ont déployé l’IA dans le crédit, la fraude ou le recouvrement sans disposer d’un inventaire complet des modèles en production. Cette lacune rend difficile l’identification du point de défaillance et, par conséquent, la mise en œuvre d’un arrêt contrôlé. Les enquêtes montrent que :
- ≈ 72 % des professionnels du secteur estiment ne pas disposer de protocoles adéquats pour les rapports de panne d’IA ou les kill‑switches.
- Les fonctions de recouvrement et de collections sont perçues comme les plus à risque, avec un écart d’environ 10 points par rapport au crédit et à la souscription.
Le rôle du propriétaire nommé
Un kill‑switch ne fonctionne que si :
- Un propriétaire clairement identifié peut mettre le modèle hors ligne.
- Des conditions déclencheuses sont préalablement définies.
- Un plan de continuité assure la poursuite des activités (traitement manuel, règles de secours, systèmes alternatifs).
Sans ces éléments, le dispositif reste théorique et expose la banque à une vulnérabilité opérationnelle.
Responsabilité contractuelle avec les fournisseurs
Lorsque l’IA est fournie par un tiers, le pouvoir d’arrêt peut appartenir au fournisseur. Les contrats doivent donc inclure :
- Une obligation de notification rapide en cas d’incident.
- Un droit d’accès aux modèles et aux données sous-jacentes.
- Une clause de signalement des plaintes liées à l’IA.
- Le droit d’être informé de toute modification du modèle par le fournisseur.
Recommandations pratiques
Pour instaurer une gouvernance robuste, chaque banque devrait :
- Établir un inventaire risk‑tiered de toutes les utilisations de l’IA.
- Attribuer à chaque usage à haut risque un propriétaire nommé.
- Définir les déclencheurs d’arrêt et le chemin de signalement avant tout incident, puis les tester régulièrement.
- Réviser les contrats fournisseurs afin d’inclure les clauses essentielles mentionnées ci‑dessus.
Perspectives réglementaires
Les récentes orientations du Federal Reserve, de l’OCC et de la FDIC excluent explicitement l’IA générative des exigences de gestion des modèles, mais insistent sur le principe que chaque banque doit assumer la responsabilité interne. Le cadre NIST et le modèle de la Cyber Risk Institute offrent des bases utiles pour structurer cette responsabilité.
Conclusion
La capacité de désactiver une IA bancaire ne repose pas uniquement sur la technologie du kill‑switch, mais sur la mise en place d’une structure de gouvernance claire, d’un propriétaire nommé et d’un plan de continuité. Sans ces éléments, les banques restent exposées à des risques opérationnels et réglementaires majeurs, même si elles disposent des outils techniques les plus avancés.