Quand la perte de contrôle des modèles pousse Bruxelles à durcir la surveillance

La perte de contrôle des modèles d’IA n’est plus seulement un scénario de recherche : Bruxelles l’inscrit désormais parmi les risques systémiques susceptibles de justifier une intervention réglementaire. Depuis le 2 août 2026, la Commission européenne dispose de pouvoirs d’exécution pour demander des informations, évaluer certains modèles d’IA à usage général et exiger des mesures visant à réduire les risques identifiés.

Ce changement ne signifie pas que chaque modèle sera placé sous surveillance permanente ni qu’un incident entraînera automatiquement son retrait. Il marque plutôt le passage d’obligations inscrites dans le AI Act à un dispositif concret de contrôle, avec des rôles répartis entre la Commission, l’AI Office et les autorités nationales. Pour les équipes qui conçoivent ou déploient des systèmes avancés, la question devient pratique : comment démontrer que les capacités d’un modèle sont évaluées, suivies et corrigées lorsque les risques évoluent ?

Pourquoi la perte de contrôle des modèles d’IA entre dans le champ du AI Act

Dans le débat public, l’expression « perte de contrôle » peut désigner des scénarios très différents. Elle peut évoquer un comportement inattendu, une utilisation détournée ou la difficulté à limiter les effets d’un système avancé. Les faits communiqués par la Commission ne réduisent pas cette notion à un seul mécanisme technique. Ils la placent parmi les risques de grande ampleur que le cadre européen entend surveiller, aux côtés des offensives cyber, des manipulations nuisibles et d’autres menaces systémiques.

Cette approche est importante pour les entreprises : l’objet de l’examen n’est pas seulement la qualité d’une réponse ou la conformité d’une interface. Il concerne aussi les capacités du modèle, les conditions dans lesquelles elles peuvent être mobilisées et les moyens de prévenir ou de limiter des dommages à grande échelle. La Commission mentionne explicitement la « loss of control » dans sa présentation de l’exécution du AI Act.

En bref : Bruxelles peut examiner les modèles d’IA à usage général présentant un risque systémique, demander des éléments d’évaluation et imposer des mesures d’atténuation. En dernier ressort, les pouvoirs prévus comprennent des amendes et des restrictions pouvant aller jusqu’au retrait ou au rappel du modèle.

La logique réglementaire repose donc sur la capacité à identifier un risque, à l’évaluer et à agir avant qu’il ne produise des conséquences difficiles à contenir. Cela ne revient pas à affirmer qu’un modèle avancé va nécessairement perdre le contrôle. La réglementation vise plutôt à rendre les risques observables et à donner aux autorités des leviers pour intervenir si les éléments disponibles le justifient.

Un risque systémique, pas une étiquette appliquée à toutes les IA

Le AI Act distingue les modèles à usage général soumis à des obligations spécifiques, notamment lorsqu’ils présentent un risque systémique. Cette distinction évite de confondre la surveillance des modèles les plus avancés avec les règles applicables à tous les outils qui utilisent de l’IA. Une application intégrant un modèle n’est pas, du seul fait de cette intégration, équivalente au modèle lui-même ni automatiquement visée par les mêmes pouvoirs.

Pour les modèles considérés comme présentant un risque systémique, l’article 55 du AI Act, cité par la Commission, prévoit notamment l’évaluation des risques, la mise en œuvre de mesures d’atténuation, la cybersécurité et la déclaration des incidents graves. Ces obligations sont liées au niveau de risque et aux caractéristiques du modèle ; elles ne justifient pas de présenter chaque service d’IA comme soumis au même régime de contrôle.

Cette distinction a une conséquence opérationnelle : une entreprise doit d’abord comprendre son rôle dans la chaîne de valeur. Est-elle fournisseur d’un modèle, développeur d’une application qui s’appuie sur un modèle tiers, ou déployeur d’un système dans un contexte donné ? Les obligations et les interlocuteurs peuvent varier. Une équipe qui ignore cette cartographie risque de préparer des preuves adaptées à son produit sans traiter les responsabilités qui lui incombent réellement.

Quels pouvoirs de surveillance Bruxelles peut-elle exercer ?

À compter du 2 août 2026, la Commission dispose de pouvoirs d’exécution portant sur les modèles d’IA à usage général. Elle peut demander des informations, examiner un modèle et exiger des mesures destinées à atténuer les risques. Le contrôle n’est donc pas limité à la publication d’orientations ou à une appréciation générale des pratiques du secteur : l’exécutif européen peut demander des éléments concrets et intervenir dans la gestion d’un risque systémique.

Les leviers mentionnés par la Commission forment une progression. L’accès au modèle et aux informations utiles peut aider à comprendre ses capacités et ses risques ; les exigences d’atténuation visent à réduire ceux-ci ; les sanctions les plus lourdes constituent une option de dernier ressort. Selon le texte explicatif de la Commission, les mesures possibles incluent des amendes pouvant atteindre 3 % du chiffre d’affaires mondial, ainsi que la restriction, le retrait ou le rappel du modèle.

  • Demander des informations : l’entreprise peut être tenue de fournir des éléments permettant aux autorités d’examiner la sécurité, le fonctionnement ou les risques du modèle.
  • Évaluer le modèle : la Commission peut demander un accès permettant d’apprécier les capacités et les risques concernés.
  • Imposer une atténuation : lorsque des risques sont identifiés, des mesures peuvent être exigées pour les réduire.
  • Sanctionner ou restreindre : en dernier ressort, l’arsenal prévoit des amendes et des mesures allant jusqu’au retrait ou au rappel.

Cette échelle de pouvoirs ne permet pas de conclure qu’une sanction maximale sera appliquée à chaque manquement. Les informations communiquées établissent l’existence des leviers, non la manière dont chaque dossier sera tranché. Pour les acteurs concernés, l’enjeu est de pouvoir répondre à une demande de contrôle avec des preuves cohérentes et traçables, plutôt que de supposer qu’une documentation générale suffira.

La Commission a déjà engagé des démarches d’enforcement en 2026. Elle a adressé des demandes formelles d’information à plus de 30 entreprises d’IA, portant notamment sur la sécurité des modèles, le droit d’auteur et la transparence. Ces demandes marquent le début concret de l’application du AI Act ; elles ne signifient pas que toutes les entreprises sollicitées ont été reconnues en infraction ni que chacune fait l’objet d’une procédure identique.

Le passage de la règle à la preuve

Lorsqu’une autorité demande des informations, la difficulté n’est pas uniquement de retrouver un document. Il faut pouvoir relier les affirmations de sécurité aux versions du modèle, aux méthodes d’évaluation, aux incidents observés et aux décisions prises. Si une équipe indique qu’un risque est maîtrisé, elle doit être en mesure d’expliquer le périmètre de son analyse et les limites de ses tests.

Pour une organisation, cela rend utiles des pratiques telles que le suivi des versions, la conservation des résultats d’évaluation et la formalisation des décisions de mise en production. Ce sont des implications de gestion des risques, non une liste exhaustive de prescriptions supplémentaires attribuées à la Commission. Leur intérêt est concret : elles réduisent le décalage entre une affirmation de conformité et la capacité de la démontrer.

Comment l’Union européenne répartit-elle les responsabilités de supervision ?

La surveillance européenne n’est pas organisée autour d’un acteur unique pour tous les systèmes. En mars 2026, le Conseil a confirmé le partage des compétences entre la Commission et les autorités nationales. Certaines autorités nationales restent compétentes dans des cas sectoriels, tandis que l’AI Office supervise les systèmes fondés sur des modèles d’IA à usage général.

Cette répartition reflète deux niveaux complémentaires. La Commission et l’AI Office interviennent dans le cadre des modèles GPAI et des risques systémiques qui dépassent souvent un seul usage. Les autorités nationales peuvent, pour leur part, conserver des compétences dans les domaines sectoriels concernés. Une entreprise peut donc devoir examiner à la fois la nature du modèle utilisé et le secteur dans lequel son système est déployé.

  1. Identifier le modèle et son statut : déterminer si le système repose sur un modèle à usage général et si le sujet concerne un risque systémique.
  2. Cartographier le contexte d’utilisation : repérer les secteurs concernés et les éventuelles autorités nationales compétentes.
  3. Clarifier les responsabilités internes : distinguer ce qui relève du fournisseur du modèle, de l’intégrateur et du déployeur.
  4. Préparer les échanges : centraliser les informations sur les évaluations, les changements du modèle et les incidents pertinents.

Cette méthode n’élimine pas toutes les zones de coordination, mais elle aide à éviter une erreur fréquente : croire que le fait d’utiliser un fournisseur externe transfère automatiquement l’ensemble des responsabilités. Inversement, une entreprise qui intègre un modèle ne devient pas pour autant le superviseur du modèle de base. La qualification dépend des rôles et du contexte, qu’il convient d’établir avant de répondre à une demande réglementaire.

Le Conseil a aussi précisé le cadre institutionnel, tandis que la Commission a créé en juin 2026 un panel scientifique et un forum consultatif pour soutenir l’application du AI Act. Ces organes doivent contribuer aux travaux sur les modèles GPAI, les risques systémiques, la classification des modèles et les méthodologies d’évaluation. Leur existence souligne que l’enforcement exige des compétences techniques autant que juridiques.

Pourquoi les méthodologies comptent autant que les règles

Une obligation d’évaluer un risque n’a de valeur pratique que si l’évaluation permet de produire des résultats interprétables. Pour un modèle avancé, les questions portent notamment sur ce qui a été testé, sur les capacités observées et sur la façon dont ces résultats alimentent les décisions de mise sur le marché ou de mitigation. Le panel scientifique est appelé à contribuer à l’élaboration de méthodologies et à la surveillance du marché, plutôt qu’à remplacer les décisions de conformité des entreprises.

La présence d’un forum consultatif apporte également un espace de soutien à l’application. Elle ne garantit pas une interprétation uniforme de chaque cas ni ne supprime la nécessité d’un examen juridique adapté. Pour les équipes produit, le bénéfice attendu est surtout une meilleure structuration du dialogue entre expertise technique, gouvernance et autorités, au fur et à mesure que les pratiques se précisent.

Que révèlent les incidents de perte de contrôle et le travail scientifique ?

Le 9 octobre 2026, l’AI Office a convoqué un panel scientifique après des incidents qualifiés de « loss-of-control ». L’annonce officielle indique que le panel devait enquêter sur des incidents récents impliquant des modèles avancés et contribuer à établir des méthodologies d’évaluation et de surveillance du marché. Les informations disponibles ne détaillent pas la nature de ces incidents ; il serait donc imprudent d’en déduire un mécanisme technique particulier ou une conclusion générale sur l’ensemble des modèles.

La portée de cette convocation est néanmoins claire : Bruxelles traite la perte de contrôle comme un sujet à examiner à partir d’éléments et de méthodes, et pas seulement comme une hypothèse abstraite. L’enquête scientifique doit aider à mieux évaluer les capacités et les risques. Elle s’inscrit dans un dispositif où l’observation des incidents peut contribuer à améliorer les évaluations et à éclairer les mesures de surveillance.

Le Rapport international sur la sécurité de l’IA 2026 traite lui aussi des mécanismes de surveillance conçus pour identifier et contrôler les systèmes susceptibles de perdre le contrôle. Cette référence situe le débat européen dans une préoccupation plus large de sécurité de l’IA. Elle ne démontre pas que les approches d’évaluation sont déjà stabilisées : les travaux sur les méthodologies restent précisément une partie de la réponse institutionnelle.

Une évaluation utile doit couvrir plus qu’un test ponctuel

Pour les équipes techniques, la conséquence n’est pas de prétendre prédire tous les comportements possibles. Une évaluation doit plutôt établir un périmètre, documenter les capacités pertinentes et rendre visibles les limites des tests. Un résultat rassurant dans un protocole donné ne prouve pas que le système restera sûr dans toutes les conditions, surtout si le modèle, son accès ou son contexte d’utilisation évoluent.

Une démarche robuste peut organiser le travail autour de questions concrètes :

  • Quelles capacités du modèle sont pertinentes pour le risque étudié et comment ont-elles été testées ?
  • Quels changements de version ou de configuration peuvent invalider une évaluation antérieure ?
  • Comment les incidents ou signaux préoccupants sont-ils enregistrés, examinés et transmis aux personnes responsables ?
  • Quelles mesures peuvent réduire l’exposition lorsque le risque ne peut pas être éliminé ?
  • Quels éléments permettent de justifier une décision de déploiement, de restriction ou de réévaluation ?

Ces questions constituent un cadre de travail, pas une reproduction exhaustive de l’article 55. Elles aident à traduire les obligations d’évaluation, d’atténuation, de cybersécurité et de déclaration des incidents graves en processus internes vérifiables. L’objectif est de lier la sécurité du modèle à des décisions opérationnelles, au lieu de traiter les tests comme une étape isolée avant le lancement.

Pourquoi la surveillance de l’IA avancée devient aussi un enjeu cyber

La Commission relie désormais la surveillance des modèles à la sécurité cyber européenne. Son plan UE sur l’IA avancée et la cybersécurité, lancé en juillet 2026, indique que les modèles avancés doivent être évalués et que leurs risques doivent être analysés avant leur mise sur le marché européen. Le principe est important pour les entreprises : l’examen de la sécurité ne se limite pas à une réaction postérieure à un incident.

Dans les faits fournis, les risques cyber sont également présents dans les échanges de la Commission avec OpenAI et Anthropic. Ces discussions ont porté sur la sécurité des modèles avancés et les risques cyber dans le contexte de l’entrée en application du AI Act. Elles témoignent d’un dialogue entre les institutions et des fournisseurs de modèles, sans permettre de conclure à l’existence d’un accord particulier ou d’une décision contre les entreprises concernées.

La dimension cyber change la manière d’aborder les capacités d’un modèle. L’enjeu n’est pas simplement de savoir si une fonctionnalité existe, mais de comprendre dans quelles conditions elle pourrait être détournée, quels contrôles réduisent les risques et quelles personnes peuvent intervenir en cas de problème. Pour une équipe produit, cette analyse doit rester connectée à l’architecture réelle du service : modèle utilisé, interfaces, accès, données et processus de supervision.

La Commission affirme vouloir garantir « un contrôle efficace des systèmes d’IA ainsi que des modèles d’IA à usage général », y compris ceux associés à des risques systémiques de cybersécurité.

La Commission prévoit aussi, avec l’ENISA, un blueprint pour organiser l’accès structuré aux capacités d’IA avancée afin de soutenir des acteurs publics et privés, en particulier dans les secteurs critiques. Ce projet ne doit pas être confondu avec un accès sans restriction aux modèles. L’idée annoncée est de structurer l’accès dans un objectif de soutien à la cybersécurité, avec une attention particulière aux secteurs où la sécurité des systèmes est déterminante.

Prévenir les usages dangereux sans bloquer l’innovation

Le cadre européen cherche à concilier deux objectifs qui peuvent entrer en tension : rendre les modèles avancés utiles et limiter les risques qu’ils peuvent amplifier. Des restrictions mal calibrées peuvent réduire des usages légitimes ; des contrôles trop faibles peuvent laisser des risques systémiques sans réponse. C’est pourquoi la logique annoncée associe évaluation, atténuation, supervision et, en dernier ressort, restriction.

Pour les entreprises, une réponse proportionnée commence par définir les usages autorisés et les limites opérationnelles, puis par vérifier que les contrôles restent adaptés à mesure que le modèle évolue. Il ne s’agit pas de présenter une mesure unique comme une garantie absolue. La mitigation peut nécessiter plusieurs couches de gouvernance, et les mesures pertinentes dépendent du modèle, de ses capacités et du contexte de déploiement.

Les secteurs critiques ont un intérêt particulier à clarifier les voies d’accès et les responsabilités avant de dépendre d’une capacité avancée. Le blueprint annoncé avec l’ENISA peut contribuer à structurer cette réflexion, mais les informations communiquées ne précisent pas encore tous les détails opérationnels. Les organisations doivent donc suivre les développements officiels plutôt que supposer que les modalités sont déjà entièrement définies.

Quelles obligations changent au 2 août 2026, et lesquelles suivent en 2027 ?

Le 2 août 2026 marque deux évolutions distinctes : l’entrée en vigueur de règles exécutoires sur la transparence et l’activation des pouvoirs d’exécution de la Commission pour les modèles à usage général concernés. Les règles de transparence deviennent applicables à cette date selon la Commission. Il faut cependant éviter de confondre ce jalon avec l’application de toutes les obligations du AI Act.

Des règles plus strictes concernant certains systèmes à haut risque ne doivent entrer en vigueur qu’en 2027, selon les éléments fournis. Le calendrier est donc progressif. Une entreprise ne devrait ni considérer que tout le régime est déjà applicable dans sa totalité, ni conclure que rien n’est exigible avant l’échéance ultérieure. La date pertinente dépend de l’obligation et du type de système concernés.

La distinction entre transparence, obligations propres aux modèles GPAI à risque systémique et règles sur certains systèmes à haut risque est particulièrement utile dans un audit interne. Si ces catégories sont mélangées, l’organisation risque d’allouer ses ressources au mauvais périmètre : par exemple, se concentrer sur la documentation de transparence tout en négligeant l’évaluation des risques systémiques, ou anticiper une obligation future comme si elle était déjà entrée en vigueur.

Une méthode pratique pour les équipes produit et conformité

Les entreprises peuvent organiser leur préparation autour d’un processus simple, puis l’adapter à leur rôle et à leur exposition. Cette démarche ne remplace pas un conseil juridique, mais elle permet de faire émerger les questions techniques et organisationnelles qui doivent être traitées.

  1. Inventorier les modèles : consigner les modèles utilisés, leur fournisseur, leurs versions et les fonctions auxquelles ils contribuent.
  2. Qualifier les usages : décrire les contextes de déploiement et les secteurs concernés, sans assimiler tous les produits qui utilisent l’IA à un même régime.
  3. Identifier les risques : examiner notamment les risques systémiques pertinents, la cybersécurité et les scénarios de perte de contrôle qui s’appliquent au modèle considéré.
  4. Relier les tests aux décisions : conserver les méthodes et résultats d’évaluation, et expliquer comment ils influencent le lancement, les limites d’usage ou les mesures d’atténuation.
  5. Organiser la réponse aux incidents : définir qui collecte les informations, qui analyse les signaux et comment les incidents graves sont traités et, le cas échéant, déclarés.
  6. Suivre les échéances : distinguer les règles applicables depuis le 2 août 2026 de celles concernant certains systèmes à haut risque annoncées pour 2027.

Cette préparation gagne à associer les équipes de développement, de sécurité, de produit et de conformité. Une analyse réglementaire construite sans les personnes qui connaissent le comportement réel du modèle risque de rester trop générale. À l’inverse, une évaluation technique qui ne tient pas compte des obligations et du contexte de déploiement peut manquer les exigences de transparence ou de déclaration.

Il faut aussi prévoir la réévaluation. Un modèle peut changer de version, être relié à de nouveaux outils ou être utilisé dans un contexte différent. Une preuve produite pour une configuration n’est pas automatiquement valable pour toutes les configurations ultérieures. Le suivi des changements aide l’organisation à savoir quand reprendre une évaluation, revoir des contrôles ou mettre à jour sa documentation.

Ce que les entreprises doivent surveiller dans les prochains développements

La portée de l’enforcement se précisera à travers les méthodes d’évaluation, les demandes adressées aux entreprises et les décisions prises par les autorités. En août 2026, Axios a résumé le tournant en indiquant que la loi européenne sur l’IA était passée de l’idée à l’exécution. Cette formule décrit un changement de phase, mais ne fournit pas à elle seule une mesure de l’efficacité du dispositif ni un résultat uniforme pour tous les fournisseurs.

Les demandes d’information déjà adressées à plus de 30 entreprises illustrent ce passage. Elles couvrent la sécurité, le droit d’auteur et la transparence, ce qui rappelle que l’application du AI Act ne se limite pas à la perte de contrôle. Le sujet est intégré à un ensemble plus large d’obligations et de risques, allant des pratiques de transparence à la cybersécurité et aux incidents graves.

Un article d’Associated Press publié le 31 juillet 2026 a également résumé les risques visés par le AI Act, dont les incidents CBRN, la perte de contrôle, les offensives cyber et les menaces pour les droits fondamentaux. La diversité de ces sujets explique pourquoi les autorités s’appuient sur des compétences scientifiques et des mécanismes de coordination. Elle invite aussi les organisations à éviter une réponse « IA responsable » trop abstraite : les mesures doivent être reliées aux risques réellement pertinents pour leur système.

Les signaux à suivre pour adapter sa gouvernance

  • Les méthodes de l’AI Office : les travaux du panel scientifique peuvent préciser la manière d’évaluer les modèles et de surveiller le marché.
  • Les consignes sur les modèles systémiques : la classification et les obligations associées sont des sujets que le panel et le forum consultatif doivent soutenir.
  • La coordination des autorités : les entreprises opérant dans plusieurs secteurs doivent suivre la répartition des compétences entre Commission et autorités nationales.
  • Les exigences de cybersécurité : le plan de la Commission et le travail prévu avec l’ENISA rendent le lien entre IA avancée et sécurité cyber plus explicite.
  • Les échéances réglementaires : la transparence applicable depuis le 2 août 2026 ne doit pas être confondue avec les règles plus strictes prévues en 2027 pour certains systèmes à haut risque.

Ces éléments ne constituent pas une promesse de stabilité immédiate. Les incidents, les capacités des modèles et les méthodes d’évaluation évoluent, tandis que les pratiques d’application se construisent. Pour une entreprise, une veille utile doit donc suivre les publications officielles et les décisions pertinentes, mais aussi permettre de traduire chaque évolution en tâches concrètes : qui est concerné, quelle preuve manque et quelle mesure doit être revue.

La limite essentielle est de ne pas interpréter « surveillance » comme un contrôle omniscient. Les pouvoirs de la Commission fournissent des leviers d’examen et d’intervention ; ils ne garantissent pas qu’un risque sera détecté avant toute conséquence. De même, l’évaluation ne peut démontrer un comportement sûr dans toutes les situations imaginables. La valeur du dispositif dépend de la qualité des éléments recueillis, des méthodes utilisées, de la coopération des acteurs et de la capacité à agir lorsque les résultats révèlent un risque.

Comment transformer le durcissement de la surveillance en avantage de gouvernance

Le renforcement de la surveillance européenne peut être abordé comme une contrainte de conformité, mais aussi comme une occasion de rendre les décisions techniques plus lisibles. Des évaluations reliées aux risques, une traçabilité des versions et un processus de traitement des incidents aident à répondre aux autorités ; ils aident également les équipes à comprendre pourquoi un modèle est autorisé pour un usage et limité pour un autre.

Cette valeur dépend toutefois de la qualité de la mise en œuvre. Accumuler des documents sans lien avec les choix de conception ne suffit pas. Une documentation utile doit montrer le périmètre de l’évaluation, les incertitudes identifiées, les mesures retenues et les raisons pour lesquelles une équipe considère qu’un risque est suffisamment atténué pour poursuivre un déploiement donné. Lorsque les limites ne peuvent pas être levées, elles doivent éclairer les restrictions d’usage et les décisions de gouvernance.

Des pratiques concrètes à intégrer au cycle de développement

Pour les équipes qui développent des produits numériques ou des outils d’IA, le travail peut être intégré au cycle de vie du produit au lieu d’être repoussé à la fin. Une revue des risques lors de la conception aide à identifier les capacités sensibles avant qu’elles ne deviennent des dépendances. Des évaluations avant mise sur le marché permettent ensuite de documenter les risques connus, tandis que le suivi après déploiement aide à repérer des changements ou des incidents qui justifient un nouvel examen.

Cette intégration doit rester proportionnée. Un petit produit reposant sur un modèle tiers n’a pas nécessairement le même profil qu’un fournisseur de modèle avancé à risque systémique. Mais même lorsqu’une entreprise n’est pas elle-même soumise à toutes les obligations d’un fournisseur, elle a intérêt à clarifier ce qu’elle attend de son fournisseur, quelles informations sont disponibles et comment les incidents seront gérés dans la chaîne de service.

Une gouvernance claire permet aussi de mieux gérer les limites des contrôles. Si une équipe identifie un risque qu’elle ne peut pas atténuer de manière convaincante, elle peut revoir les accès, le périmètre d’usage ou les conditions de lancement. L’existence de pouvoirs de restriction et de retrait rend cette possibilité particulièrement concrète pour les modèles à risque systémique. La décision de limiter un produit peut alors être considérée comme une mesure de maîtrise, et non comme une simple réaction à une procédure réglementaire.

Enfin, une approche rigoureuse doit éviter deux excès. Le premier consiste à présenter chaque risque comme une catastrophe certaine et à bloquer toute innovation sans examen proportionné. Le second consiste à traiter les risques de perte de contrôle comme une spéculation sans conséquence opérationnelle. Le cadre décrit par la Commission invite plutôt à une démarche fondée sur l’évaluation, l’atténuation et la surveillance, en adaptant la réponse aux capacités et aux risques du modèle concerné.

En pratique, les entreprises peuvent dès maintenant vérifier leur inventaire de modèles, clarifier leurs rôles, relier leurs évaluations aux décisions de déploiement et préparer une réponse documentée aux demandes d’information. Elles doivent suivre séparément les règles exécutoires depuis le 2 août 2026 et les exigences prévues pour certains systèmes à haut risque en 2027. Cette discipline ne supprime pas l’incertitude, mais elle rend les choix de sécurité plus explicites et plus défendables.

Le durcissement de la surveillance à Bruxelles traduit ainsi une évolution précise : les modèles avancés ne sont plus abordés uniquement comme des produits à innover, mais aussi comme des systèmes dont les capacités, les risques et les mesures de contrôle doivent pouvoir être examinés. Pour les organisations qui les développent ou les intègrent, la meilleure réponse n’est ni la promesse d’un contrôle absolu ni une conformité de façade. C’est une gouvernance technique traçable, proportionnée et capable d’évoluer avec le modèle.