Ce que j'ai vraiment appris en évaluant des fournisseurs d'IA pour l'équipe conformité d'une banque

Ce qui a bloqué notre évaluation de l'IA pendant six semaines, ce n'était pas la résidence des données. Tout le monde au comité des risques pensait que la bataille serait là. Il s'est avéré que c'était l'explicabilité du modèle pour un outil d'aide à la décision en matière de crédit. Personne du côté des fournisseurs n'avait de réponse claire. Notre propre équipe de gestion des risques n'avait pas non plus pleinement résolu comment poser la question.

Je m'occupe de la révision de conformité des outils d'IA dans une banque canadienne de taille moyenne, sous réglementation fédérale, mais sans l'effectif de gouvernance de l'IA que les cinq grandes banques peuvent se permettre à l'interne. Les approvisionnements m'ont demandé de piloter l'évaluation d'une poignée de fournisseurs d'IA — trois américains, deux canadiens, une pile open source qu'on aurait hébergée nous-mêmes. Je m'attendais à ce que la conversation difficile porte sur l'emplacement des données. Ce n'est pas vraiment ce qui s'est passé. Voici à peu près comment ça s'est déroulé, ce qui a vraiment compté, et la chose dont j'étais certaine qu'elle serait un facteur éliminatoire — et qui ne l'a pas été.

Ce que le BSIF nous a demandé de démontrer

La ligne directrice du BSIF sur la gestion du risque lié aux modèles, E-23, était le document que notre comité des risques citait sans cesse sans l'avoir pleinement lu. Une fois qu'on s'est assis pour l'étudier sérieusement, la demande réelle était plus étroite que la version qui circulait dans notre bureau : une gouvernance des modèles documentée et proportionnée au risque du cas d'usage, pas une configuration technique précise. Cette distinction comptait. Un clavardage orienté client pour le triage de questions fréquentes et un modèle qui touche aux décisions de crédit n'allaient jamais passer la même barre, et essayer d'appliquer un seul gabarit aux deux, c'est ce qui nous faisait perdre notre temps.

La ligne directrice du BSIF demande d'appliquer la gestion du risque lié aux modèles d'une manière proportionnée à la complexité, à l'usage d'affaires et au risque du modèle en question. Cette seule phrase a fait plus de travail dans notre processus que tout ce qu'un fournisseur a pu nous dire. Elle nous a permis de trier : les outils à faible risque avançaient rapidement, tout ce qui touchait une décision de prêt ou de lutte contre le blanchiment d'argent recevait l'examen complet.

Pourquoi la question du CLOUD Act n'a compté qu'une seule fois

On a posé la même question à chaque fournisseur, américain comme canadien : si un tribunal américain vous ordonne de produire des données clients, quelle est votre exposition juridique réelle, et quelle juridiction contrôle la réponse. Pour les fournisseurs américains, la réponse honnête — quand on en obtenait une — c'était qu'une société mère américaine signifie que les tribunaux américains peuvent exiger la production en vertu du CLOUD Act, peu importe où les serveurs se trouvent physiquement. La réponse d'un fournisseur se résumait à « on n'a jamais reçu une telle demande », ce qui n'équivaut pas à être exempté d'en recevoir une, et nos avocats externes ont relevé cette distinction immédiatement.

C'est le seul endroit où le choix d'une plateforme d'IA canadienne a vraiment pesé dans le dossier. Augure n'a aucune société mère américaine ni investisseur américain, et les conversations et documents des clients ne sont jamais traités par des fournisseurs sous juridiction américaine — la portée du CLOUD Act sur les fournisseurs contrôlés par les États-Unis ne s'étend donc pas à ce contenu client précis. Nos avocats n'ont pas voulu bouger sur ce point pour le projet pilote lié aux décisions de crédit. Pour les outils internes à moindre risque, ça comptait moins, honnêtement, parce que les données en jeu se rapprochaient davantage de métadonnées opérationnelles que d'information financière client.

Je veux être prudente ici, parce que je pense que ça se vend souvent trop fort dans les présentations des fournisseurs en général. L'architecture d'Augure appuie une position de conformité, elle ne vous en donne pas une clé en main. On a quand même dû faire notre propre analyse Loi 25 et LPRPDE, peu importe le fournisseur choisi. Aucune plateforme ne fait ce travail à votre place.

Là où la Loi 25 a resserré la liste des finalistes

On a des clients au Québec. La portée extraterritoriale de la Loi 25 faisait en sorte que notre équipe vie privée devait mener une évaluation des facteurs relatifs à la vie privée en vertu de l'article 17, peu importe où se trouve notre siège social. C'est là que les choses sont devenues plus pointues que je ne m'y attendais. Savoir qu'une IA est « canadienne » plutôt qu'« américaine » ne suffit pas. Il faut savoir quels flux traversent une frontière, pour quelle étape de traitement, et si tout ça est documenté quelque part.

L'article 17 exige une évaluation avant que des renseignements personnels ne quittent le Québec, en soupesant la sensibilité des données par rapport aux protections juridiques offertes dans la juridiction de destination.

Quand on a demandé directement à l'équipe d'Augure où l'inférence s'exécute réellement, la réponse était plus précise que ce à quoi je m'attendais d'un appel avec un fournisseur. Certains paliers de modèles tournent sur une infrastructure canadienne, d'autres avec des partenaires européens validés, et le basculement en période de forte charge est assuré depuis l'Europe aussi — jamais les États-Unis pour l'inférence ou pour le contenu des conversations. Il y a aussi un traitement limité aux États-Unis pour le traitement des cartes de paiement et l'envoi de courriels, divulgué dans la politique de confidentialité plutôt qu'enfoui. J'ai apprécié que ce soit énoncé clairement plutôt qu'arrondi à « tout est au Canada », parce que cette affirmation-là n'aurait pas survécu à la première lecture de nos avocats. Un fournisseur qui enjolive la résidence des données une seule fois vous oblige à revérifier tout le reste de ce qu'il vous a dit.

Le problème d'explicabilité que personne n'a résolu

Voici la partie qui a vraiment englouti six semaines. Pour l'outil d'aide à la décision de crédit — pas un décideur final, juste quelque chose qui fait remonter l'historique de dossiers pertinents à un souscripteur — notre équipe de gestion des risques voulait savoir ce qui se passe quand un demandeur conteste une décision et exige le raisonnement derrière celle-ci. Chaque fournisseur, canadien ou américain, nous a servi une version ou une autre d'une esquive. Mon interprétation, c'est que ce n'est pas encore résolvable au niveau du fournisseur. C'est une limite de l'architecture des modèles à l'échelle de toute l'industrie, pas du tout une question de souveraineté.

On a fini par bâtir notre propre couche de documentation autour de l'outil plutôt que de compter sur les fonctions d'explicabilité natives du fournisseur. On journalise séparément les documents récupérés et la décision finale de dérogation du souscripteur. C'est un contournement, pas une solution, et je dirais honnêtement à une collègue qu'on n'a pas fini de régler ce problème.

Les questions qu'on a réellement posées à chaque fournisseur

La liste ci-dessous reprend presque mot pour mot notre document de prise en charge, épuré des numéros de référence internes.

• Où l'inférence s'exécute-t-elle physiquement, par palier de modèle, et est-ce que ça change en cas de forte charge ou de basculement?
• Qui est votre société mère, dans quelle juridiction, et est-ce que ça crée une exposition à une divulgation forcée pour le contenu client?
• Qu'advient-il des données clients utilisées dans un clavardage ou une révision de documents — est-ce que certaines sont utilisées pour l'entraînement du modèle?
• Pouvez-vous fournir une liste de sous-traitants, et inclut-elle des fournisseurs de paiement ou de courriel sous juridiction américaine?
• Quelle est la piste d'audit de votre modèle pour une décision qu'un souscripteur devra plus tard défendre devant un régulateur ou une ombudspersonne?
• Quel est votre modèle de tarification à notre volume d'utilisation prévu, et change-t-il si on dépasse le stade pilote?

Cette dernière question semble banale à côté des questions réglementaires. C'est pourtant celle qui a éliminé deux fournisseurs d'un coup sur la question des coûts, avant même qu'on arrive à la révision de conformité.

Ce qui, finalement, n'a pas compté

J'étais certaine, au départ, que l'hébergement d'un modèle open source à l'interne gagnerait sur le contrôle et perdrait sur le coût, et que cet arbitrage dominerait toute la décision. Ça n'est presque pas revenu sur la table après les deux premières semaines. Le fardeau d'hébergement interne et de MLOps pour une banque de notre taille était assez lourd pour que l'avantage du contrôle demeure surtout théorique. On n'avait pas l'équipe pour bien l'opérer, et un modèle auto-hébergé mal opéré représente sans doute une position de risque pire qu'un fournisseur validé avec une gouvernance documentée au dossier. On a mis cette option de côté rapidement. Je ne pense pas que qui que ce soit au comité se soit battu pour la garder vivante.

On a comparé le prix du palier Max d'Augure, à 80 $ CA par mois par poste avec les limites de téléversement de documents pertinentes pour notre cas d'usage, au coût par poste du fournisseur américain établi avec lequel on avait déjà des contrats. L'outil américain était moins cher en volume, mais venait avec l'exposition au CLOUD Act que nos avocats ne voulaient pas approuver pour le flux de travail lié aux décisions de crédit, spécifiquement. La plateforme canadienne a donc remporté ce pilote sur une base ajustée au risque, pas sur le prix affiché. Je ne pense pas que ça se généralise à tous les cas d'usage chez nous, et je mentirais si je disais qu'on a pleinement réglé quel outil l'emportera pour les cinq prochaines décisions d'approvisionnement à venir.

Si vous menez vous-même une version de cette évaluation, la politique de confidentialité et la documentation sur les sous-traitants d'Augure, sur augureai.ca, sont présentées avec assez de détails pour qu'on puisse réellement faire l'évaluation de l'article 17 sans avoir besoin d'un appel de suivi. Ça nous a fait gagner une semaine qu'on ne savait pas nécessaire.