Les banques utilisent l’IA pour l’évaluation de crédit. Les assurances pour l’examen des sinistres. Les études d’avocats pour la recherche juridique. Les fiduciaires pour le conseil fiscal. L’introduction de l’IA dans les secteurs réglementés n’est plus une tendance ; c’est le quotidien.
Mais l’introduction sous des cadres réglementaires (FINMA, LPD, EU AI Act, LLCA) obéit à d’autres règles que dans les secteurs non réglementés. Qui les ignore risque non seulement de l’argent, mais des licences professionnelles, des mesures prudentielles et des dommages de réputation.
Ces cinq erreurs reviennent en pratique sans cesse.
Erreur 1 : introduire l’IA sans savoir où l’IA est déjà utilisée
L’erreur la plus fréquente est aussi la plus fondamentale. Beaucoup d’entreprises commencent à évaluer un nouvel outil d’IA sans savoir quels systèmes d’IA sont déjà en service.
La réalité : les collaborateurs utilisent ChatGPT sur les appareils professionnels. Le CRM intègre un lead scoring. La gestion documentaire classe les fichiers automatiquement. Le chatbot du service client sur le site web est un système d’IA. L’équipe marketing utilise un outil de création de contenu.
Sans un inventaire complet des systèmes d’IA, la base de toute mesure ultérieure fait défaut. La Guidance FINMA 08/2024 exige cet inventaire explicitement. Le EU AI Act le présuppose. Et la LPD exige un registre des activités de traitement (art. 12) qui doit inclure les traitements assistés par l’IA.
Mieux : établissez un inventaire des systèmes d’IA avant d’évaluer un nouveau système. Interrogez chaque département : «Quels outils utilisez-vous qui génèrent des recommandations, évaluations ou décisions automatisées ?» Le résultat vous surprendra.
Erreur 2 : choisir le fournisseur avant de définir les exigences de conformité
L’évaluation technique avant l’analyse réglementaire est l’ordre naturel dans les secteurs non réglementés. Dans les secteurs réglementés, c’est le mauvais ordre.
Qui choisit d’abord l’outil puis vérifie la conformité se retrouve face à un problème si l’outil choisi ne satisfait pas les exigences. Le fournisseur est basé aux États-Unis, mais la FINMA exige la localisation des données. Le modèle est une boîte noire, mais le EU AI Act exige l’explicabilité. Les données transitent vers des tiers, mais le processus DPA n’est pas achevé.
Inversez l’ordre : définissez d’abord les exigences réglementaires. Pour un établissement financier suisse : circulaire FINMA sur l’externalisation, LPD (en particulier art. 16-17 sur la communication transfrontière), EU AI Act (si des clients européens sont concernés), politiques internes de sécurité IT. Puis évaluez les fournisseurs par rapport à ces exigences. Le meilleur algorithme est inutile s’il échoue à la conformité.
Erreur 3 : ne pas distinguer «assisté par l’IA» et «décidé par l’IA»
Tous les systèmes d’IA n’ont pas le même profil de risque. Une IA qui trie des documents est différente d’une IA qui évalue des demandes de crédit. Les deux sont des systèmes d’IA. Mais les exigences réglementaires sont fondamentalement différentes.
Le EU AI Act érige cette distinction en loi : les systèmes d’IA à haut risque (ceux qui influencent des décisions sur l’octroi de crédit, les primes d’assurance, les relations de travail ou les questions juridiques) doivent satisfaire des exigences étendues. Les systèmes à risque minimal (tri de documents, traduction, résumé) sont soumis à moins d’obligations, voire aucune.
En pratique : classifiez chaque système d’IA par risque. Posez la question : «Ce système influence-t-il une décision qui touche les droits ou intérêts d’une personne ?» Si oui : risque élevé. Si non : risque moindre. L’investissement en conformité doit être proportionnel au risque. Tout traiter de la même manière gaspille des ressources. Ne rien classifier est un constat d’audit.
Erreur 4 : ignorer les hallucinations parce que l’outil est «la plupart du temps correct»
Les modèles de langage hallucinent. Ils génèrent des contenus qui sonnent de manière plausible mais sont factuellement faux. Dans les secteurs non réglementés, c’est agaçant. Dans les secteurs réglementés, c’est dangereux.
Un avocat qui cite un arrêt inventé risque des mesures disciplinaires. Cela s’est déjà produit plusieurs fois aux États-Unis. Un compliance officer qui soumet un rapport réglementaire généré par l’IA avec de fausses références d’articles risque des mesures prudentielles de la FINMA. Un fiduciaire qui donne un renseignement fiscal erroné sur la base d’un résultat d’IA en est personnellement responsable.
«La plupart du temps correct» ne suffit pas dans les secteurs réglementés. Le standard est : «Vérifiable correct, à chaque fois.»
Standard minimal : exigez des références aux sources. Chaque réponse générée par l’IA doit être traçable jusqu’à une source vérifiable : un article de loi, un arrêt, une circulaire. Si l’outil ne cite pas de sources, il n’est pas adapté au travail professionnel dans les secteurs réglementés. Point.
En complément : établissez un processus de révision. Aucun résultat d’IA ne quitte l’entreprise sans qu’une personne qualifiée l’ait vérifié. Ce n’est pas une faiblesse de l’IA. C’est le standard professionnel.
Erreur 5 : traiter la protection des données comme un problème secondaire
«On réglera la protection des données plus tard.» Cette phrase revient dans presque chaque projet d’évaluation. Et elle conduit presque toujours à des problèmes.
La protection des données n’est pas une fonctionnalité qu’on ajoute après coup. C’est une condition fondamentale. La LPD exige la Protection de la vie privée dès la conception (art. 7) : le traitement doit être conçu dès le départ de manière à respecter les principes de protection des données. Pas «dès le départ, quand on en aura le temps». Dès le départ.
Concrètement : avant que les collaborateurs ne saisissent une première requête dans un outil d’IA, les questions suivantes doivent avoir trouvé réponse :
- Où transitent les données saisies ?
- Sont-elles utilisées pour l’entraînement du modèle ?
- Qui a accès aux entrées et aux résultats ?
- Où sont-ils stockés et pendant combien de temps ?
- Un contrat de sous-traitance (art. 9 LPD) a-t-il été conclu ?
- Y a-t-il une communication transfrontière de données (art. 16-17 LPD) ?
Dès le départ : intégrez l’examen de la protection des données dans le processus d’évaluation dès le premier jour. Non comme un obstacle, mais comme un critère de qualité. Un fournisseur qui ne peut pas répondre clairement à ces questions n’est pas prêt pour les secteurs réglementés.
Conclusion
L’introduction de l’IA dans les secteurs réglementés n’est pas un projet technologique. C’est un projet de gouvernance avec une composante technologique. La technologie est la partie facile. La conformité, les processus et les responsabilités sont la partie difficile.
Les entreprises qui évitent ces cinq erreurs économisent non seulement des coûts et des risques. Elles construisent aussi la confiance de leurs clients et de leurs autorités de surveillance qui, dans les secteurs réglementés, est la véritable monnaie d’échange.
Informations complémentaires : montvirtua.com
Cet article est publié à titre informatif et ne constitue pas un conseil juridique.