IA souveraine et résidence des données suisses pour les institutions financières

La question que se pose le conseil d'administration d'une banque suisse à propos de l'intelligence artificielle est rarement "est-ce que ça marche". Il s'agit de "où vont les données". La réponse donnée par la plupart des fournisseurs est une clause contractuelle. La réponse qui satisfait un régulateur, un auditeur interne et un client dont le grand-père a choisi la banque est une architecture : une description de chaque endroit où un octet de données client peut se trouver physiquement, à chaque moment du traitement, avec le nom des personnes qui peuvent y accéder.

Commencez par la cartographie des données et le modèle envisagé. Localisez inférence, identité, journaux, support et sauvegardes ; évaluez règles et garanties ensemble. Le déploiement local doit être vérifié selon les capacités et la licence du modèle.

Ce que signifie la souveraineté quand le modèle n’est pas le vôtre

L’IA souveraine est une expression qui a dérivé. Dans un ministère, cela signifie des modèles formés, hébergés et régis par la législation nationale. Dans une banque, cela signifie quelque chose de plus restreint et de plus utile : l'institution décide et peut prouver quelles données parviennent à quel calcul, sur quel territoire juridique, sous le contrôle de qui.

Cette définition sépare trois choses qui sont généralement confondues.

Le poids du modèle sont l’artefact produit par la formation. Ils peuvent être ouverts, sous licence pour l'auto-hébergement ou accessibles uniquement via l'interface d'un fournisseur. L’endroit où se trouvent les poids détermine où l’inférence peut avoir lieu.

Le calcul d'inférence est l'acte d'exécuter une invite à travers le modèle. Cela se produit là où les poids sont chargés. Si les poids se trouvent sur les serveurs d'un fournisseur dans une autre juridiction, chaque invite l'est également.

Le pipeline de données c'est tout avant et après l'inférence : récupération à partir des propres documents de la banque, rédaction, journalisation, évaluation, examen humain. C'est là que circulent réellement la plupart des données des clients, et elles sont entièrement sous le contrôle de la banque, quel que soit le modèle qu'elle utilise.

Ce qu’exige réellement le LPD révisé

La loi fédérale révisée sur la protection des données est entrée en vigueur en septembre 2023. Elle est souvent décrite comme la réponse de la Suisse au RGPD, et elle l'est dans sa structure. Pour la question de l’IA, quatre de ses obligations font le véritable travail.

Elle exige que les données personnelles soient traitées uniquement aux fins pour lesquelles elles ont été collectées et que la personne concernée puisse raisonnablement s'attendre à ce traitement. Un client qui a fourni des documents pour ouvrir un compte ne s'attendait pas à ce qu'ils soient utilisés pour former un modèle, ou qu'ils soient envoyés à un tiers pour synthèse, à moins qu'il ne lui soit demandé.

Il restreint la divulgation de données personnelles à l'étranger. Le transfert vers un pays sans protection adéquate nécessite des garanties spécifiques, et le responsable du traitement reste responsable des données une fois celles-ci quittées. Les serveurs d'un fournisseur dans un pays tiers constituent une divulgation à l'étranger, quelle que soit l'apparence de l'interface.

Cela nécessite une analyse d’impact sur la protection des données lorsque le traitement est susceptible de présenter un risque élevé pour la personne concernée. Le traitement automatisé des dossiers financiers à grande échelle, avec un modèle dont le comportement ne peut pas être entièrement spécifié, est le type de traitement pour lequel la disposition a été rédigée.

Elle établit des obligations concernant les décisions individuelles automatisées : lorsqu'une décision ayant un effet juridique ou des conséquences importantes est prise uniquement par des moyens automatisés, la personne concernée doit être informée et peut demander un examen humain. Un modèle qui recommande d’intégrer ou non un client est à la limite de cette disposition. Un modèle qui décide est à l’intérieur.

Aucune de ces obligations n’interdit l’utilisation de grands modèles linguistiques. Tous limitent l’endroit où les données peuvent aller et ce qui doit être documenté avant d’y parvenir. C’est là l’essentiel : la loi est une spécification architecturale revêtue d’un vêtement légal.

La couche de contrôle

Au-dessus de la loi sur la protection des données se situent les attentes en matière de surveillance de l'Autorité fédérale de surveillance des marchés financiers. Sa circulaire sur l'externalisation considère le transfert de fonctions importantes à un tiers comme une responsabilité dont l'institution reste pleinement responsable. La banque doit pouvoir auditer le prestataire, lui donner des instructions, récupérer ses données et sortir. Un fournisseur modèle qui traite les données des clients est, à des fins de contrôle, un partenaire d'externalisation. La banque doit être en mesure de dire qui chez le vendeur peut voir quoi et de démontrer que l'accord peut être dénoué.

En vertu de la loi sur les banques, le secret bancaire vient s'ajouter à l'obligation la plus difficile à respecter pour les vendeurs. La confidentialité n'est pas une question de formulaires de consentement. Cela s'attache à la relation et relève du droit criminel. Une architecture dans laquelle le personnel d'un fournisseur étranger pourrait, en vertu de la procédure légale de son propre pays, être obligé de fournir rapidement l'historique d'un client suisse est une architecture que le conseiller juridique général n'approuvera pas. La manière la plus simple d’éviter cette question est de ne pas créer les données à l’étranger.

Trois architectures, et ce que chacune laisse exposé

Il existe trois manières réalistes pour une banque d’utiliser les modèles de classe frontière. Ils diffèrent par ce qui quitte le bâtiment.

La première architecture est celle où la plupart des pilotes commencent et où la plupart d’entre eux ne devraient pas y rester. La rédaction avant l'appel est utile, mais la rédaction des documents financiers non structurés n'est pas fiable et la piste d'audit appartient au fournisseur.

La seconde est celle où la plupart des institutions devraient atterrir pour la majorité des cas d’utilisation. Les régions suisses des grands fournisseurs de cloud proposent des modèles dans le cadre d'une location contrôlée par la banque, avec des clés de cryptage détenues par la banque et avec des garanties contractuelles et techniques selon lesquelles les invites ne sont pas conservées ou utilisées à des fins de formation. Les risques restants concernent l'accès au support, la télémétrie et la portée juridique de la juridiction mère du fournisseur. Chacune de ces questions est une question connue avec une réponse documentée, et les réponses appartiennent à l'analyse d'impact sur la protection des données.

La troisième est l’option souveraine au sens strict. Des modèles ouverts de qualité sérieuse existent désormais, et pour des tâches bien définies telles que la classification, l'extraction, la synthèse et la recherche interne de documents, ils sont plus que suffisants. Le coût est celui de l'ingénierie : quelqu'un doit exécuter le cluster d'inférence, le corriger, évaluer le modèle et le remplacer lorsqu'un meilleur arrive. Pour une banque privée, il s'agit généralement du travail d'une entreprise et non d'un recrutement.

Le traitement transfrontalier exige une analyse des règles de protection des données, de confidentialité et d’externalisation. Un hébergement suisse ne suffit pas à établir la conformité.

La décision d’architecture, prise correctement

La décision n’est pas un choix mais un ensemble de choix, et il est préférable de les prendre dans cet ordre.

Classez les données avant de choisir le modèle. Les données d'identification du client, les données dérivées du client qui ont été agrégées ou pseudonymisées et les données internes non client ont des obligations différentes. L'essentiel de la valeur du premier programme d'IA d'une banque réside dans les deuxième et troisième catégories : recherche de politiques, rédaction de procédures, assistance au code, reporting interne. Commencez par là, avec le plus large choix de modèles disponibles, et réservez l'architecture souveraine à la première catégorie.

Décidez explicitement de la limite de résidence. Notez les territoires légaux dans lesquels les données d'identification du client peuvent être traitées et stockées. Pour la plupart des institutions suisses, la réponse est la Suisse, l'Espace économique européen étant autorisé à effectuer des traitements spécifiques sous des garanties documentées. Cette phrase devient une contrainte sur chaque diagramme d'architecture ultérieur.

Choisissez le modèle qui s'adapte à la limite, et non l'inverse. Une fois la limite fixée, l’ensemble des modèles admissibles est court et le choix est facile. Les établissements qui choisissent le modèle passent d’abord un an à essayer de faire correspondre les limites autour de celui-ci.

Séparez le plan de contrôle du plan de données. L'orchestration, la gestion des invites, les harnais d'évaluation et la surveillance peuvent s'exécuter n'importe où tant qu'ils ne touchent jamais aux données client. L'inférence et la récupération sur les données client s'exécutent à l'intérieur de la limite. Cette séparation est ce qui permet d'utiliser les outils d'un fournisseur sans utiliser son territoire.

Concevez la sortie avant l’entrée. Les invites, les indices de récupération, les données de réglage fin, les ensembles d'évaluation et les journaux sont les atouts de la banque. Ils doivent être exportables dans un format documenté, et le modèle doit être remplaçable sans réécrire les applications situées au-dessus. Une abstraction fine sur l'interface du modèle coûte une semaine et permet d'économiser un an.

À quoi devrait ressembler la conversation avec le fournisseur

Un vendeur qui prend le marché suisse au sérieux répondra aux questions suivantes par écrit et sans hésitation.

• Sur quel territoire juridique l'inférence est-elle effectuée pour notre location, et cela peut-il être fixé contractuellement ?
• Lequel de vos collaborateurs, dans quels pays, peut accéder à nos invites, résultats ou données de récupération, selon quel processus, et cet accès est-il enregistré de manière à ce que nous puissions l'examiner ?
• Nos invites ou résultats sont-ils conservés après la réponse, pendant combien de temps, et sont-ils utilisés pour entraîner ou évaluer des modèles ?
• En vertu de quelles lois pourriez-vous être obligé de divulguer nos données, et que feriez-vous ?
• Pouvez-vous prendre en charge les clés de chiffrement gérées par le client, et qu'arrive-t-il à nos données si nous les révoquons ?
• Quelle est la procédure documentée de sortie et sous quel format recevons-nous nos données ?
• Quels sous-traitants touchent nos données et comment sommes-nous avertis lorsque la liste change ?

Un fournisseur qui répond avec un lien vers une page de confiance n'a pas répondu. Un vendeur qui dit qu’une question est inhabituelle ne vend pas aux banques.

Que faire lundi

1. Demandez que les pilotes d'IA actuels soient dessinés sous forme de cases et de flèches, colorées par territoire et par opérateur. La plupart des institutions découvrent une couleur qu'elles n'ont pas choisie.
2. Écrivez la limite de résidence en une seule phrase et faites-la circuler au CIO, au CRO et à l'avocat général pour signature. Cela devient la contrainte que tout diagramme ultérieur doit satisfaire.
3. Classez les trois premiers cas d’utilisation prévus par catégorie de données. Déplacez ceux qui touchent aux données d’identification du client derrière la frontière ; laissez les autres procéder avec l’ensemble de modèles le plus large.
4. Commandez dès maintenant l’évaluation d’impact sur la protection des données, en tant que document de conception plutôt que comme une réflexion de conformité après coup. Réalisée tôt, c'est la revue d'architecture.
5. Envoyez les sept questions ci-dessus à chaque fournisseur du pipeline actuel et raccourcissez le pipeline en fonction des réponses.