Bruxelles n'a pas écrit de règle pour les fournisseurs d'IA. Elle a écrit leur prochain questionnaire.

Le comité mixte des autorités européennes de surveillance a publié le 31 juillet une déclaration sur les modèles d'IA de frontière dans le cadre de DORA, et celle-ci n'impose absolument aucune obligation juridique aux entreprises qui conçoivent ou fournissent ces modèles. C'est précisément pour cette raison que les fournisseurs devraient la lire.

La déclaration s'adresse aux entités financières réglementées : banques, entreprises d'investissement, gestionnaires d'actifs, assureurs. Elle reprend le plan d'action de la Commission européenne sur la cybersécurité et l'intelligence artificielle, publié le 7 juillet, et le traduit en attentes prudentielles quant à la manière dont ces entités doivent traiter le risque TIC lié aux modèles de frontière. Rien n'y crée d'obligation pour un développeur de modèle. Et pourtant, d'ici deux trimestres, ce texte changera ce que l'on demandera à ces développeurs, car DORA ne réglemente pas directement les fournisseurs. DORA réglemente leurs clients, puis impose à ces clients d'inscrire les obligations du fournisseur dans un contrat.

Quiconque a vécu la supervision de l'externalisation vers le cloud reconnaîtra le mécanisme. Un régulateur indique à une banque ce qu'elle doit être en mesure de démontrer. La banque ne peut pas le démontrer seule, si bien que l'exigence réapparaît quelques mois plus tard sous la forme d'une clause portant sur la notification des incidents, les droits d'audit et d'inspection, le consentement à la sous-traitance, la portabilité et la restitution des données, et la coopération avec les autorités. DORA codifie déjà cette liste. Lorsque l'entité financière estime qu'un service soutient une fonction critique ou importante, les obligations s'alourdissent, y compris la participation à des tests de pénétration fondés sur la menace. Les AES n'avaient pas besoin d'écrire une règle pour les fournisseurs d'IA. Elles en ont écrit une pour la contrepartie qui tient la plume sur le contrat.

Ce que demande la déclaration s'organise en trois volets, et le premier mérite une lecture attentive. Au titre de la prévention, les entités financières doivent tenir des inventaires complets et continuellement actualisés de l'ensemble de leurs actifs informatiques, et la déclaration précise que cela couvre les composants d'IA et d'apprentissage automatique au même titre que les infrastructures, les applications, les référentiels de données et les API. La détection couvre la montée en charge de la découverte de vulnérabilités face à la menace, une surveillance continue plutôt que périodique, et des exercices de red teaming renforcés par des outils d'IA. La gestion couvre les tests de résilience, la reprise après sinistre, et l'adaptation des cadres de risque et des structures de gouvernance existants afin que la responsabilité suive le rythme des attaques assistées par l'IA et des défaillances multisystèmes.

Observez le travail que fait l'expression « continuellement actualisés » dans ce premier volet. Un tableur trimestriel n'y suffit pas, pas plus qu'un inventaire qui recense les applications mais s'arrête avant les modèles qu'elles contiennent. Si le registre d'actifs d'une banque doit descendre au niveau du modèle, la diligence qu'elle exerce sur ses fournisseurs doit elle aussi descendre au niveau du modèle. L'alerte publiée par le cabinet Goodwin le 6 août détaille les points sur lesquels les questions vont se préciser : la gouvernance du développement et du déploiement des modèles, la résilience de l'infrastructure sous-jacente, la transparence sur les limites et les modes de défaillance des modèles, la gestion et la notification des incidents, la dépendance aux sous-traitants et aux infrastructures cloud avec répercussion des obligations, et les dispositifs de continuité d'activité. Ce n'est pas un questionnaire d'achat. C'est le dossier de diligence d'une fonction de risque TIC, et il arrive d'un autre service de la banque que celui qui signe le bon de commande.

Les numéros d'articles comptent ici, car c'est là que la pression s'exerce réellement. L'article 28 de DORA impose à l'entité financière de mener une diligence documentée avant de contracter et de tenir un registre d'information couvrant chaque accord TIC. L'article 29 y ajoute l'évaluation du risque de concentration. L'article 30 dicte le contenu du contrat lui-même, sur deux niveaux, le plus exigeant étant réservé aux services qui soutiennent une fonction critique ou importante. Les superviseurs ont déjà identifié les articles 28 à 30 comme la principale source d'écarts de conformité dans le secteur, avec en tête des registres incomplets, des classifications de criticité manquantes et des preuves précontractuelles trop minces. Une déclaration qui relève le niveau d'exigence sur l'IA de frontière tombe donc sur un domaine de contrôle que les AES jugent déjà fragile.

Les fournisseurs disposent d'un véritable levier, et c'est la proportionnalité. L'article 4 de DORA impose aux entités financières de calibrer leurs mesures en fonction de leur taille, de leur profil de risque et de la nature, de l'ampleur et de la complexité de leurs activités. Les AES le rappellent explicitement. Un fournisseur confronté à des conditions conçues pour une infrastructure de paiement d'importance systémique, imposées par un gestionnaire de taille moyenne sur un service peu critique, dispose d'un argument défendable. Mais la proportionnalité joue dans les deux sens. Si le service soutient effectivement une fonction critique ou importante, l'argument du calibrage s'évanouit et les obligations lourdes sont tout simplement les bonnes.

La question du périmètre mérite d'être tranchée tôt, car la définition ne se stabilisera pas d'elle-même. La déclaration reprend la formulation du plan d'action : les modèles d'IA de frontière sont les modèles les plus avancés disponibles ou en cours de développement, capables d'accomplir un large éventail de tâches qui approchent, atteignent ou dépassent l'état de l'art. C'est par construction une cible mouvante, si bien que la discussion avec un client financier sur votre appartenance au périmètre est une discussion que vous aurez de façon répétée plutôt qu'une seule fois. Fonder une stratégie commerciale sur l'argument que votre modèle n'est pas un modèle de frontière me paraît une position fragile.

Ce qui me frappe le plus, c'est à quel point cela fait écho à ce qui s'est produit aux États-Unis cet été. Fannie Mae, qui n'est pas un régulateur, s'est octroyé le droit d'exiger sans préavis un inventaire complet de l'IA auprès des gestionnaires de prêts, et l'effet sur les fournisseurs a été immédiat. Ici l'instrument est une déclaration prudentielle plutôt qu'une lettre de prêteur, et la pression passe toujours par le contrat plutôt que par la sanction. Deux systèmes juridiques très différents, la même conclusion : l'institution qui déploie le modèle en répond, et elle fera répondre ses fournisseurs en premier.

Reste une question opérationnelle étroite et à laquelle on peut répondre. Lorsque l'équipe risque TIC d'une banque demande quels modèles se trouvent derrière le service qu'elle vous achète, de quoi ces modèles dépendent, qui sont vos sous-traitants et comment un incident lui parviendrait, d'où vient la réponse ? S'il faut la reconstituer à partir de trois équipes et d'un disque partagé, le registre est reconstruit à la demande au lieu d'être tenu, et la prochaine sollicitation coûtera exactement autant. La plateforme insAIght d'Anove est conçue pour maintenir ce registre debout entre deux sollicitations, chaque système étant rattaché aux obligations qui l'atteignent réellement, de sorte qu'un dossier de diligence se tire au lieu de se construire.

Rien de tout cela n'est une sanction, et cela ne le deviendra peut-être jamais. Ce n'est pas nécessaire. La déclaration produira ses effets discrètement, dans les révisions des contrats de service signés au cours des deux prochains trimestres, et les fournisseurs qui attendent qu'un régulateur s'adresse directement à eux découvriront que les termes ont été fixés sans eux.

Sources

• Comité mixte des autorités européennes de surveillance, déclaration sur les modèles d'IA de frontière (JC 2026 25), 31 juillet 2026.
• Commission européenne, plan d'action de l'UE sur la cybersécurité et l'intelligence artificielle, 7 juillet 2026.
• Règlement (UE) 2022/2554 (DORA), en particulier l'article 4 sur la proportionnalité et les articles 28 à 30 sur le risque lié aux prestataires tiers de services TIC, le risque de concentration et les clauses contractuelles essentielles.
• Goodwin, Frontier AI and DORA: AI Service Providers to European Financial Entities Take Note, 6 août 2026.
• Fannie Mae, Lender Letter LL-2026-04, traitée dans notre analyse du basculement de responsabilité vers les fournisseurs aux États-Unis, août 2026.

Pour aller plus loin

• insAIght, la plateforme de gouvernance et de risque IA d'Anove, pour tenir à jour un registre IA et ses preuves entre deux demandes de diligence.
• The Toughest AI Governance Demand of 2026 Did Not Come From a Regulator, sur la même dynamique à l'oeuvre du côté des contreparties contractuelles américaines.
• ExplAIn, notre outil gratuit pour vérifier ce qu'un système d'IA déclare réellement sur lui-même.

Si l'IA de frontière intervient quelque part dans ce que vous fournissez à une entité financière européenne, ou dans ce que vous achetez à vos propres fournisseurs, réservez une démonstration et nous verrons ensemble comment insAIght réunit l'inventaire, les correspondances et les preuves en un seul endroit.