En juin 2026, le Conseil de l'Union européenne a approuvé définitivement le paquet de simplification « Digital Omnibus », qui repousse l'échéance de conformité des systèmes d'IA à haut risque autonomes de l'annexe III du 2 août 2026 au 2 décembre 2027. Les systèmes à haut risque intégrés dans des produits réglementés bénéficient d'une prolongation parallèle de douze mois, au 2 août 2028.
La réaction, dans bon nombre de fonctions de conformité, a été de refermer le dossier pour dix-huit mois. C'est une erreur, pour trois raisons distinctes — et la plus importante n'a rien à voir avec les échéances.
1. Ce qui a bougé, et ce qui n'a pas bougé
A bougé. Les obligations des systèmes à haut risque autonomes de l'annexe III — exigences pour les fournisseurs aux articles 9 à 17, et pour les déployeurs à l'article 26 — s'appliquent désormais à partir du 2 décembre 2027. Pour l'IA à haut risque intégrée dans des produits réglementés, la date passe au 2 août 2028.
N'a pas bougé. Les obligations de transparence de l'article 50, qui imposent d'informer une personne qu'elle interagit avec un système d'IA, restent au calendrier initial du 2 août 2026. Seule l'exigence plus étroite de marquage pour les systèmes déjà déployés a reçu un délai, au 2 décembre 2026.
C'est le premier point pratique. Un établissement qui a déployé un assistant en contact avec les clients — robot d'entrée en relation, agent de relance documentaire, interface de support — relève des obligations de transparence dès maintenant, indépendamment du report « haut risque ». Le report largement relayé n'est pas celui dont la plupart des établissements financiers avaient besoin.
2. L'IA utilisée en KYC/LBA est-elle à haut risque ?
C'est ici que la lecture attentive compte, car la réponse n'est ni un oui général ni un non général.
Les catégories à haut risque de l'annexe III les plus souvent invoquées dans la finance concernent l'évaluation de la solvabilité et la notation de crédit des personnes physiques, ainsi que l'évaluation des risques et la tarification en assurance vie et santé. Les systèmes utilisés pour la détection de la criminalité financière sont traités différemment de la notation de crédit, et les considérants du règlement abordent explicitement la détection de fraude liée à la LBA.
En pratique, un inventaire honnête d'un parc d'IA de conformité produit trois catégories :
Probablement à haut risque. Tout ce qui note des personnes physiques d'une manière qui détermine l'accès à un service financier. Si la sortie d'un modèle est ce qui décide qu'un particulier obtient ou non un compte ou un crédit, c'est l'analyse « notation de crédit » qu'il faut mener, quel que soit le nom interne du système.
Probablement hors haut risque, mais pas non régulé. Filtrage sanctions et PEP, analyse de presse défavorable, extraction documentaire, résolution de structures d'ayants droit. Ces systèmes soutiennent une appréciation rendue par une personne ; ils ne déterminent pas eux-mêmes l'accès. L'IA Act n'est pas ici la contrainte principale — la surveillance sectorielle, la protection des données et votre propre gouvernance des modèles le sont.
Dans le champ de la transparence, quoi qu'il arrive. Tout ce avec quoi un client interagit directement.
L'évaluation qui compte n'est pas la dénomination commerciale du produit. C'est ce que la sortie détermine, et si un humain décide réellement. Un système présenté comme une aide à la décision mais qui, en pratique, est toujours accepté sans examen n'est pas une aide à la décision.
3. La question suisse
La Suisse n'a pas adopté l'IA Act et les établissements suisses n'y sont pas directement soumis. Trois raisons pour lesquelles cela ne le rend pas sans objet.
La portée extraterritoriale. Le règlement s'applique aux fournisseurs mettant des systèmes sur le marché de l'Union et, dans des circonstances définies, lorsque la sortie est utilisée dans l'Union. Un établissement suisse servant des clients résidents de l'UE, ou un éditeur suisse vendant dans l'UE, devrait mener l'analyse plutôt que supposer que la géographie tranche.
L'effet de standard de fait. Comme pour le RGPD, le résultat pratique est que les éditeurs construisent un seul produit au standard le plus strict applicable. Les établissements suisses se verront proposer des systèmes conformes à l'IA Act et il leur sera demandé, par leurs contreparties et correspondants européens, comment ils gouvernent leurs modèles — bien avant qu'une règle suisse ne l'exige.
La surveillance suisse couvre déjà le fond. La FINMA a formulé des attentes en matière de gouvernance et de gestion des risques pour l'usage de l'IA par les établissements assujettis, et le Conseil fédéral a sa propre feuille de route. L'absence d'équivalent de l'IA Act ne signifie pas l'absence d'obligations : elle signifie que les obligations arrivent par les canaux ordinaires du risque opérationnel, de l'externalisation et de la gouvernance. Notre article sur le copilote de conformité agentique examine ce que cela implique au quotidien.
Et indépendamment de tout cela, la LPD s'applique. Le traitement automatisé de données personnelles dans un contexte de conformité fait naître des devoirs de protection des données quelle que soit la classification du système au regard de l'IA Act — voir la protection des données en KYC.
4. Ce que les obligations exigent réellement
Une fois la structure mise de côté, les exigences « haut risque » se ramènent à des pratiques qu'une bonne gouvernance des modèles implique déjà : un système de gestion des risques sur tout le cycle de vie ; une gouvernance des données d'entraînement, de validation et de test ; une documentation technique ; une journalisation automatique des événements ; la transparence envers les déployeurs ; une supervision humaine conçue dès l'origine ; et une exactitude, une robustesse et une cybersécurité appropriées.
Les déployeurs — ce qu'est généralement une banque utilisant un outil tiers — portent un ensemble plus restreint : utiliser le système conformément aux instructions, confier la supervision humaine à des personnes compétentes et dotées d'autorité, veiller à la pertinence des données d'entrée, surveiller le fonctionnement et conserver les journaux.
Deux points méritent l'insistance, car c'est là que les déploiements de conformité échouent réellement.
La supervision humaine doit être réelle. Désigner un relecteur n'est pas une supervision si ce relecteur traite deux cents alertes par jour et que l'interface n'offre qu'un bouton d'acceptation. Superviser suppose que la personne dispose de l'information, du temps et de l'autorité pour être en désaccord. Un établissement incapable de montrer des cas où l'humain a contredit le modèle n'a pas de supervision : il a une formalité.
La journalisation est ce qui rend le reste démontrable. Quelle version de modèle, quelles entrées, quelle sortie, quelle décision humaine, à quel moment. C'est la même exigence que la piste d'audit dont la revue périodique et la remédiation ont déjà besoin — d'où l'observation utile : si votre plateforme CLM journalise correctement les décisions, l'essentiel des preuves attendues d'un déployeur existe déjà.
5. Pourquoi attendre décembre 2027 est le mauvais choix
Les obligations de transparence sont déjà en vigueur. Si un client parle à une IA, c'est dans le champ dès maintenant.
Le délai de préparation est plus long que le report. Reconstituer la provenance des données d'entraînement, assembler une documentation technique et ajouter une journalisation à un système qui n'a pas été conçu pour journaliser sont des travaux de plusieurs trimestres. Un établissement qui commence mi-2027 découvrira que les preuves dont il a besoin n'ont jamais été collectées — et une preuve historique ne se crée pas rétroactivement.
Vos clients et correspondants demanderont avant. C'est ce qui détermine réellement le calendrier. Les questionnaires de gouvernance de l'IA sont déjà standards dans la diligence fournisseur et de plus en plus dans les revues de correspondance bancaire. L'échéance pratique n'est pas celle du règlement : c'est le prochain questionnaire de contrepartie — et il arrive bien avant décembre 2027.
6. Que faire maintenant
- Inventorier l'IA en service, y compris celle arrivée à l'intérieur d'outils achetés pour d'autres raisons, sans décision de déploiement. La plupart des établissements sous-estiment ce point de façon significative.
- Classer chaque système par ce qu'il détermine, non par son nom. La sortie décide-t-elle de l'accès à un service ? Un humain examine-t-il réellement ?
- Identifier les systèmes en contact avec les clients et vérifier la conformité à la transparence maintenant.
- Demander la documentation aux fournisseurs. Un éditeur incapable de produire une documentation technique et un énoncé clair de finalité est une information en soi — sur le produit, et sur votre position de déployeur.
- Rendre la supervision mesurable. Enregistrer les taux de contradiction. Un taux proche de zéro est un constat, pas une assurance.
- Vérifier la journalisation. Version de modèle, entrées, sorties, décision humaine, horodatage. Si un élément manque, l'ajouter maintenant pour que l'historique existe le jour où il servira.
- Écrire la politique une fois, pour tous les régimes. IA Act, attentes FINMA, LPD et cadre de risque opérationnel se recoupent bien plus qu'ils ne divergent. Écrire quatre politiques, c'est finir avec quatre politiques incohérentes.
7. Le fond du sujet
Les exigences « haut risque » de l'IA Act reviennent, en substance, à demander que vous puissiez expliquer ce que votre système a fait et pourquoi — avec documentation, journaux, et un humain qui aurait pu décider autrement. Ce n'est pas une idée neuve en conformité. C'est la même exigence que pour une notation de risque, le traitement d'une alerte ou une décision de sortie de relation : il faut pouvoir reconstituer le raisonnement, des années plus tard, à partir d'un enregistrement et non d'un souvenir.
Les établissements dont le cycle de vie client produit déjà cet enregistrement trouveront dans l'IA Act un exercice documentaire. Ceux qui s'appuient sur des outils produisant un score sans chemin traçable des entrées à la conclusion y trouveront une reconstruction — et le report de l'Omnibus leur offre un temps qui n'a de valeur que s'ils l'utilisent.
L'approche de Wecan sur l'IA en conformité part de cette contrainte au lieu de l'ajouter après coup : chaque contribution automatisée à un dossier client est enregistrée avec ses entrées, sa version de modèle et la décision humaine qui a suivi, sur le dossier même qui porte tout le reste. Le règlement change la paperasse autour de cela. Il ne change pas ce qui rend une décision de conformité défendable.
Cet article est fourni à titre d'information et ne constitue pas un avis juridique.
