Modifier l'IA dans le cadre de la loi européenne sur l'IA : Leçons tirées de la pratique en matière de classification et de conformité

Ce billet a été rédigé par des professionnels de la conformité juridique, Øystein Endal, Andrea Vcric, Sidsel Nag, Nick Malter et Daylan Araz (voir la section sur les auteurs à la fin), qui s'appuient sur leur expérience en matière de gestion ou de conseil d'entreprises intégrant l'IA. Pour toute question ou suggestion, veuillez contacter Nick Malter à l'adresse nick@trail-ml.com.

Avis de non-responsabilité: Veuillez noter que les informations fournies et discutées dans l'article ne constituent pas et ne sont pas destinées à constituer un avis juridique. Veuillez consulter un conseiller juridique professionnel si nécessaire. Le contenu de la loi européenne sur l'IA peut être interprété différemment.

À venir dans ce billet :

• Résumé
• Introduction
• Les problèmes liés aux modifications dans le cadre de la loi européenne sur l'IA
  • Problèmes courants liés à la modification des modèles et systèmes d'IA
• Quelles modifications peuvent vous qualifier en tant que prestataire ?
  • Modifications substantielles des systèmes d'intelligence artificielle
  • Modifications substantielles des modèles GPAI
  • Qu'est-ce que cela signifie en pratique ?
• GenAI en action : exemples de praticiens et défis ouverts
  • Cas 1 : Fournisseur de services informatiques d'entreprise
  • Cas 2 : Plateforme d'IA agentique de mise à l'échelle
• Aller de l'avant
  • Recommandations générales pour les organisations
  • Actions et ressources recommandées pour la préparation de la loi européenne sur l'IA
• A propos des auteurs

Introduction

La loi européenne sur l'IA réglemente principalement les fournisseurs de modèles d'IA à usage général (GPAI) et de systèmes d'IA, établissant un cadre global pour le développement et le déploiement de l'IA au sein de l'Union européenne. Si la loi européenne sur l'IA identifie clairement le développeur d'un système d'IA ou d'un modèle GPAI entièrement nouveau comme un fournisseur, la situation devient plus complexe lorsqu'une personne située plus en aval dans la chaîne de valeur modifie un système d'IA ou un modèle GPAI existant d'un tiers. Cela soulève des questions sur les responsabilités en matière de conformité, en particulier sur la question de savoir qui doit et peut remplir les obligations du fournisseur en vertu de la loi sur l'IA de l'UE.

La loi européenne sur l'IA tient compte des scénarios de modification en définissant les circonstances dans lesquelles un modificateur d'un système d'IA ou d'un modèle GPAI devient un fournisseur, ce qui a pour effet de transférer les obligations réglementaires du fournisseur initial au modificateur, que ce soit en partie ou en totalité.

Ce déplacement des responsabilités en matière de conformité, en particulier lorsqu'il s'agit de systèmes d'IA à haut risque ou de modèles GPAI, est un scénario que les entreprises cherchent généralement à éviter en raison des coûts et de la charge de travail supplémentaires liés à la conformité. Une classification erronée du rôle, de la catégorie de risque ou du modèle d'IA en vertu de la loi européenne sur l'IA représente un risque de conformité important pour les entreprises, car elle peut entraîner des amendes allant jusqu'à 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial en cas de non-respect des dispositions relatives aux systèmes d'IA à haut risque ou aux modèles de GPAI.

Les obligations du fournisseur de modèle GPAI entrant en vigueur le 2 août 2025, les discussions sur les modifications des modèles et systèmes d'IA et les implications de conformité qui en découlent sont devenues de plus en plus urgentes et pertinentes pour les entreprises.

Dans cet article, nous - un groupe de travail composé de membres du Pacte sur l'IA et d'utilisateurs précoces de la loi sur l'IA - examinons la classification résultant des modifications apportées à la loi européenne sur l'IA et discutons des défis en matière de conformité du point de vue des praticiens. Nous nous concentrons plus particulièrement sur les modèles et les applications du GPAI.

Les problèmes liés aux modifications dans le cadre de la loi européenne sur l'IA

En raison des définitions générales de la loi sur l'IA de l'UE, il peut être difficile pour les entreprises de déterminer quand une modification entraîne des obligations pour le fournisseur du modèle utilisé. La définition décisive d'une "modification substantielle" (voir l' article 3, paragraphe 23) reste vague dans la loi sur l'IA de l'UE. Cette situation est source d'incertitude pour les organisations.

Le défi d'une classification correcte est particulièrement pertinent lorsque l'on considère les scénarios dans lesquels les entreprises construisent des systèmes ou des applications sur la base de modèles GPAI, tels que le GPT-4.5 d'OpenAI ou le Sonnet 4 d'Anthropic. Ces modèles sont délibérément conçus pour être adaptables à un large éventail de cas d'utilisation et pour être personnalisés par les opérateurs en aval de la chaîne de valeur. Dans ces scénarios, il peut être difficile de répondre à la question de savoir qui doit remplir quelles obligations.

Des initiatives (en cours) de la Commission européenne visent à clarifier les concepts de la loi sur l'IA. En ce qui concerne les systèmes d'IA à haut risque, l'élaboration de normes CEN/CENELEC est en cours et leur publication est prévue au plus tôt en 2026. Ces normes devraient fournir des orientations concrètes sur la manière d'obtenir la présomption de conformité avec les dispositions de la loi sur l'IA de l'UE relatives aux systèmes d'IA à haut risque, mais ne se concentrent pas sur les modèles GPAI. En ce qui concerne les modèles GPAI, le code de pratique GPAI de l'Office AI de la Commission européenne est axé sur le respect des obligations des fournisseurs de modèles GPAI ainsi que sur les modèles GPAI présentant un risque systémique. Le code de pratique a été récemment complété par des lignes directrices officielles à l'intention des fournisseurs de GPAI (lignes directrices GPAI). Bien qu'il s'agisse d'une première étape positive, des incertitudes subsistent quant au moment où un modificateur devient un fournisseur dans la pratique. 

Les lignes directrices GPAI introduisent un seuil d'un tiers de la puissance de calcul initiale nécessaire pour entraîner le modèle GPAI d'origine (mesurée en FLOP) afin de faire la distinction entre les modifications substantielles et non substantielles. Ce seuil vise à clarifier le moment où les obligations de conformité incombent au modificateur. Toutefois, ce seuil informatique, bien que potentiellement utile pour certaines modifications telles que la mise au point, peut rester insuffisant pour d'autres types de modifications qui changent sensiblement le comportement du modèle et les risques sans nécessiter d'importantes ressources informatiques. Les lignes directrices précisent que ce seuil n'est qu'un critère indicatif. Conformément au paragraphe 62 des lignes directrices de l'AMPI, la règle générale permettant de déterminer si une modification est substantielle se résume à la question de savoir si les modifications entraînent potentiellement une modification substantielle de la généralité, des capacités ou du risque systémique du modèle.

Dans ces conditions, les organisations sont confrontées à des difficultés pour mettre en œuvre les mesures appropriées afin de se conformer à la loi européenne sur l'IA et pour déterminer si leurs cas d'utilisation et leurs modifications leur permettent de devenir un fournisseur (modèle GPAI) en premier lieu.

Quelles modifications peuvent vous qualifier en tant que prestataire ?

Avant de déterminer s'il existe une modification permettant de qualifier une personne de prestataire, il est conseillé de vérifier si le système ou le modèle en question entre effectivement dans le champ d'application des définitions d'un système d'IA ou d'un modèle GPAI figurant dans la loi sur l'IA de l'UE. Cela peut sembler trivial, mais cela s'est parfois avéré difficile lors de la classification du rôle d'opérateur.

Il existe plusieurs façons de devenir un fournisseur au sens de la loi européenne sur l'IA, tant au niveau du système d'IA que du modèle d'IA. En particulier, la loi sur l'IA de l'UE décrit plusieurs scénarios dans lesquels une entreprise modifiant ou déployant un système d'IA peut potentiellement hériter du rôle et des responsabilités d'un fournisseur :

• Intégration d' un modèle d'IA existant dans un système d'IA nouveau ou existant (voir article 3, paragraphe 68)
• Redorer le blason d' un système d'IA à haut risque pour en faire son propre produit (voir article 25)
• Réutilisation d' un système ou d'un modèle d'IA de manière à ce qu'il devienne à haut risque (voir article 25)
• Modifications (substantielles) d'un système d'IA à haut risque existant ou d'un modèle GPAI (voir l 'article 25 et le considérant 109)

Le premier cas fait référence à la définition d'un "fournisseur en aval" donnée par la loi européenne sur l'IA (voir l' article 3, paragraphe 68), qui décrit probablement le mieux la situation actuelle de nombreuses organisations. Par exemple, le fait d'apporter son propre modèle ("BYOM") dans un système d'IA peut être considéré comme une intégration. Toutefois, le fait d'être un fournisseur en aval n'entraîne pas nécessairement une modification des responsabilités en matière de conformité pour les fournisseurs de modèles GPAI, car cela décrit plutôt le rôle d'un fournisseur de système d'IA. Dans ce cas, une organisation doit vérifier si le système d'IA à haut risque ou les obligations de transparence s'appliquent et si le fournisseur en amont du modèle GPAI a clairement exclu la distribution et l'utilisation du modèle au sein de l'UE.

Alors que les deuxième et troisième cas - le changement de marque et la réaffectation - sont généralement des seuils assez simples pour un changement de responsabilité en matière de conformité, les cas impliquant des modifications substantielles sont plus ambigus et posent d'importants problèmes d'interprétation pour les organisations, comme décrit ci-dessus.

Modifications substantielles des systèmes d'intelligence artificielle

Selon la loi sur l'IA, une modification substantielle est un changement d'un système d'IA qui n'a pas été prévu par l'évaluation de conformité du fournisseur d'origine et qui affecte la conformité avec les exigences relatives aux systèmes d'IA à haut risque ou qui affecte la destination du système d'IA (voir l' article 3, paragraphe 23, et le considérant 128). Il convient de noter qu'une évaluation officielle de la conformité d'un système d'IA à haut risque ne peut être réalisée que lorsqu'il existe des organismes notifiés qui effectuent un audit externe ou lorsque les normes harmonisées (par le CEN/CENELEC) peuvent être appliquées. Au moment de la rédaction de ce document, il ne s'agit donc pas encore d'une orientation utile.

La loi sur l'IA traite explicitement des modifications à l' article 25, qui stipule que les modifications substantielles apportées à un système d'IA à haut risque font passer le rôle du prestataire à celui du modificateur, mais uniquement si le système reste à haut risque. Cette disposition établit un lien entre le concept de modification substantielle et l'impact de la modification sur le niveau de risque.

Modifications substantielles des modèles GPAI

Toutefois, en ce qui concerne les modifications des modèles GPAI, la loi sur l'IA de l'UE est moins bien définie. Le considérant 109 et la FAQ de la Commission européenne précisent que les obligations du prestataire pour les modèles GPAI sont limitées au champ d'application de la modification, mais la loi sur l'IA de l'UE ne lie pas directement les modifications des modèles GPAI à des niveaux de risque spécifiques (uniquement au risque systémique ou non systémique). En outre, la loi sur l'IA de l'UE ne parle pas explicitement de modifications substantielles dans le contexte des modèles GPAI - mais elle considère explicitement le réglage fin des modèles GPAI comme une modification, ce qui suggère que la modification doit également avoir un effet assez substantiel sur le modèle. L'Office AI confirme ce dernier point dans les lignes directrices GPAI, puisqu'il déclare que, selon lui, les modifications impliquent généralement l'entraînement d'un modèle à l'aide de données supplémentaires. Les lignes directrices mettent également l'accent sur l'affinement et le réentraînement d'un modèle GPAI.

Pour renforcer cette distinction, les lignes directrices GPAI introduisent un seuil informatique : si une modification utilise au moins un tiers des ressources informatiques initialement requises pour former le modèle, le modificateur est présumé être devenu un fournisseur de modèles GPAI. Bien que ce seuil apporte une certaine clarté, ses limites ont été soulignées lors de la consultation publique sur les lignes directrices et reconnues par l'Office AI. Il se peut que le seuil ne tienne pas compte des modifications à faible calcul qui affectent néanmoins considérablement le profil de risque d'un modèle, et il peut être difficile pour les modificateurs d'estimer de manière fiable le calcul requis - en particulier sans accès aux informations provenant des fournisseurs en amont. La Commission européenne a choisi de fixer des seuils relativement élevés et s'attend actuellement à ce que peu de modificateurs deviennent des fournisseurs de modèles GPAI.

Là encore, le seuil est un critère indicatif, et d'autres modifications de modèles pourraient également être considérées comme des modifications substantielles. La question de savoir si la logique de l' article 25, axée sur le risque (l'article réglementant les modifications dans les cas de systèmes d'IA à haut risque), s'applique également aux modifications des modèles GPAI, comme le suggèrent certains, reste ouverte.

La modification d'un modèle d'IA peut prendre de nombreuses formes. Comme le soulignent Philipp Hacker et Matthias Holweg (2025), les types les plus pertinents de modifications d'un modèle d'IA peuvent être regroupés dans les catégories suivantes :

• Pas de changement: Utilisation d'un modèle d'IA pré-entraîné sans aucune modification.
• Modification des hyperparamètres: Ajuster des paramètres tels que la température.
• Génération améliorée par récupération (RAG): Création d'applications qui améliorent les résultats d'un modèle en se référant à une base de connaissances externe ou à des données exclusives.
• GPT personnalisés: Création de variantes des modèles de base avec des instructions, des outils et des personnalités spécifiques.
• Ajustement précis: Entraînement du modèle de base sur des ensembles de données propriétaires ou spécifiques à un domaine afin d'adapter ses performances.

Distillation de modèles ou de connaissances: Formation d'un modèle "étudiant" plus petit basé sur les résultats d'un modèle "enseignant" plus grand, souvent pour réduire les besoins de calcul.

Comme l'affirment Hacker et Holweg (2025), les modifications substantielles, c'est-à-dire les profils de risque ou le comportement du modèle substantiellement modifiés, existent dans les cas de réglage fin, de distillation du modèle, de déverrouillage par manipulation des paramètres ou de changement de l'architecture de base d'un modèle. D'autres modifications, en particulier lorsqu'elles ne modifient pas le profil de risque, l'architecture, la généralité ou la finalité d'un modèle d'IA, sont probablement non substantielles, c'est-à-dire qu'elles n'entraînent pas de changement dans les obligations du fournisseur de modèles GPAI.

Qu'est-ce que cela signifie en pratique ?

Conformément à la logique plus large de la loi européenne sur l'IA, il est utile d'ancrer l'évaluation de la modification des responsabilités en matière de conformité, tant en ce qui concerne les systèmes d'IA que les modèles GPAI, dans une évaluation du caractère substantiel ou non substantiel de la modification, ce qui nécessite d'examiner l'effet de la modification sur les risques.

Pour les systèmes d'IA, l'exercice est relativement clair : les entreprises qui modifient des systèmes d'IA doivent vérifier si les changements affectent la classification des risques du système, par exemple en précisant s'il devient à haut risque ou s'il le reste.

Pour les modèles GPAI, l'exercice est un peu plus complexe. Jusqu'à ce que de nouvelles orientations soient disponibles et que des normes soient en place, les entreprises qui modifient les modèles GPAI peuvent envisager deux approches :

1. Une approche plus conservatrice, considérant toute adaptation comme un déclencheur potentiel d'un changement dans les obligations du fournisseur du modèle GPAI par défaut. Il s'agit essentiellement de conserver la documentation et les résumés des modifications effectuées, même si cela n'est pas obligatoire.
2. Une approche plus pragmatique, selon laquelle les obligations des fournisseurs de modèles GPAI ne sont censées s'appliquer que si la modification altère clairement le comportement, la généralité ou le profil de risque du modèle, ou si les seuils de calcul sont atteints. Cette approche limite les charges de gouvernance, mais peut nécessiter des justifications plus solides en cas de contestation.

En tout état de cause, les entreprises devraient procéder à des évaluations des risques et des incidences lorsqu'elles apportent des modifications aux modèles GPAI ou aux systèmes d'IA (à haut risque).

GenAI en action : exemples de praticiens et défis ouverts

Pour donner une idée des défis actuels auxquels sont confrontés les praticiens lorsqu'il s'agit de la bonne catégorisation, nous avons rassemblé quelques exemples réels (partiellement anonymisés). Nous soulignons également d'autres problèmes de conformité à la loi sur l'IA liés aux cas de GenAI, qui n'ont pas encore été résolus, ainsi que d'autres bonnes pratiques.

Cas 1 : Fournisseur de services informatiques d'entreprise

Un fournisseur de services informatiques d'entreprise utilise le modèle GPT-4 d'OpenAI pour fournir et vendre une plateforme qui orchestre différents chatbots dans une solution centralisée. Les utilisateurs finaux peuvent alors discuter avec les bots pour accéder à des connaissances générales, mais aussi aux connaissances internes de leur entreprise, dans un environnement sécurisé. Il s'agit d'un cas très courant de "Custom GPT", dans lequel le fournisseur de services limite ses modifications à des changements dans les messages-guides et à l'ajout de techniques RAG, tout en distribuant le système sous un nouveau nom.

Les considérations suivantes étaient particulièrement pertinentes pour le fournisseur de services informatiques lors de l'évaluation de la conformité :

1. Tout d'abord, il n'était pas clair si le fait de construire des robots personnalisés autour du modèle GPT-4 et de fournir des services sous leur propre nom de marque les qualifiait en tant que fournisseur du modèle GPAI.
2. Deuxièmement, la question de savoir si la date limite du 2 août 2025 fixée par la GPAI s'applique à leur activité de vente de solutions basées sur le TPG sans modification substantielle du modèle de base a suscité une certaine confusion.
3. Troisièmement, ils ont du mal à s'assurer que l'OpenAI fournit la documentation requise.

Bien que le fournisseur de services informatiques soit considéré comme un fournisseur en aval, en raison de l'intégration du modèle de l'OpenAI, il ne s'est pas qualifié comme fournisseur d'un système d'IA à haut risque (exclu dans la politique d'utilisation et limité par des moyens techniques) ni comme fournisseur du modèle GPAI en raison de la portée très limitée de la modification qui ne modifie pas de manière significative le risque du modèle. Dans ce cas, et au moins à des fins de conformité, ils n'ont pas besoin de s'appuyer sur la documentation de l'OpenAI et n'ont pas d'obligations supplémentaires en vertu des dispositions relatives au modèle GPAI. Le fournisseur de services informatiques a consulté la société de conformité de l'un des auteurs, Trail, et a décidé de suivre une approche conservatrice, c'est-à-dire de conserver une documentation technique suffisante sur l'architecture et la fonctionnalité du système GPAI, qui devrait de toute façon être disponible à des fins de développement.

Cas 2 : Plateforme d'IA agentique de mise à l'échelle

Unique AI, une scale-up suisse, propose une plateforme pour construire des solutions d'IA agentique qui aident les banques, les compagnies d'assurance et les sociétés de capital-investissement à améliorer leurs opérations financières. Il s'agit notamment de flux de travail, tels que la recherche d'investissements, la diligence raisonnable et les processus KYC. Le principal défi consistait à garantir la conformité et la sécurité des agents d'IA capables d'effectuer des actions de manière indépendante. Toutefois, le rôle prévu par la loi européenne sur l'IA n'était pas clair au départ.

Unique AI a mené des recherches approfondies sur la loi européenne sur l'IA, à la fois en interne et avec le soutien d'un cabinet d'avocats, WalderWyss, qui a obtenu un avis juridique sur le positionnement d'Unique AI par rapport à la loi européenne sur l'IA. En fonction de la configuration du client et du modèle de déploiement, Unique AI peut jouer différents rôles dans le cadre de la loi européenne sur l'IA.

La plupart des clients ont choisi un modèle de déploiement à locataire unique dans lequel Unique AI héberge et fait fonctionner le logiciel. Sur la base de l'interprétation juridique de la loi européenne sur l'IA, l'approche opérationnelle de Unique AI la positionne comme un distributeur plutôt que comme un fournisseur, tout en mettant à disposition les systèmes et modèles d'IA. En effet, Unique AI exploite des produits d'IA commerciaux existants, tels que les modèles Microsoft Azure et OpenAI, et les enrichit de fonctionnalités spécifiques au contexte par le biais de techniques de chaînage d'invites, de RAG et d'invites vers SQL, sans modifier le modèle de langage étendu (LLM) d'origine. Unique AI n'utilise pas les données des clients à des fins d'apprentissage des modèles et exclut toute utilisation à des fins à haut risque, ce qui confirme cette classification. Par conséquent, l'entreprise ne se considère pas comme un modificateur du modèle GPAI et les obligations du fournisseur du modèle GPAI restent du côté des fournisseurs en amont.

Elle a adopté un cadre de gouvernance de l'IA, qui sert de base au développement de l'IA agentique, en intégrant la confiance, la sécurité, la responsabilité, la fiabilité et la transparence dans l'architecture de base de chaque agent intelligent et de chaque flux de travail, tandis que des analyses comparatives internes régulières empêchent la dérive des modèles et maintiennent une qualité cohérente dans tous les cas d'utilisation.

Pour travailler de manière proactive à la conformité à la loi sur l'IA, Unique AI a mené une évaluation de conformité interne selon la méthodologie de David Rosenthal en juin 2024, sous la direction du responsable de la sécurité des informations et du responsable des données de l'entreprise.

Alors que le paysage réglementaire continue d'évoluer, l'entreprise maintient une approche prospective grâce à des mises à jour continues de son cadre public de gouvernance de l'IA, à une participation active aux consultations réglementaires et à une collaboration ouverte et transparente avec les pairs du secteur par le biais d'initiatives telles que les tables rondes sur la gouvernance de l'IA organisées chaque année.

Aller de l'avant

Alors que la loi européenne sur l'IA progresse dans sa phase de mise en œuvre, il reste des questions ouvertes et des défis de conformité, en particulier pour les entreprises qui intègrent et modifient des modèles et des systèmes d'IA.

En tout état de cause, les obligations globales des fournisseurs de modèles GPAI sont gérables, puisqu'elles se limitent essentiellement à maintenir la documentation technique et les résumés dans le champ d'application des modifications. Bien entendu, les fournisseurs de modèles GPAI présentant un risque systémique sont confrontés à des exigences de conformité plus complexes. L'office AI suppose qu'à l'heure actuelle, seules quelques modifications en aval atteindraient les seuils de calcul respectifs qui déclencheraient un changement des responsabilités en matière de conformité. Des orientations appropriées sont en cours, et il existe suffisamment d'indices et d'approximations pour permettre aux intégrateurs et aux modificateurs de travailler à la mise en conformité avec la loi européenne sur l'IA dans l'intervalle.

L'Office AI a également indiqué dans les lignes directrices GPAI que les fournisseurs de modèles GPAI, y compris ceux qui effectuent des modifications, qui anticipent des difficultés de mise en conformité par rapport à l'échéance d'août 2025 devraient prendre contact de manière proactive avec l'Office AI par l'intermédiaire de son service d'assistance AI Act récemment mis en place. Les bureaux d'assistance de la loi sur l'IA mis en place par les différents États membres de l'UE, tels que ceux de l' Allemagne et de l'Autriche, peuvent constituer une autre option pour contacter de manière proactive les autorités dans les cas complexes.

En outre, de nombreux grands fournisseurs de modèles GPAI se sont engagés à respecter le code de pratique GPAI, notamment OpenAI, Anthropic, Google et Mistral, ce qui indique qu'il existe également une intention de soutenir les opérateurs en aval avec une documentation appropriée sur les modèles d'IA. Cela peut contribuer à atténuer le manque de transparence des fournisseurs, comme nous l'avons souligné plus haut, dans les mois à venir.

Recommandations générales pour les organisations

Si vous êtes préoccupé par les modifications des modèles et systèmes GPAI en vertu de la loi européenne sur l'IA, consultez les lignes directrices officielles GPAI de l'Office de l'IA et commencez à évaluer les cas d'utilisation selon les interprétations de l'Office de l'IA. Les lignes directrices contiennent d'autres exemples de cas où une organisation doit être considérée comme un fournisseur de modèles GPAI.

Les organisations qui ont commencé à réfléchir plus en détail à leur conformité à la loi européenne sur l'IA devraient profiter de leur élan et lancer de manière proactive des initiatives de gouvernance de l'IA, en respectant le fait que la gouvernance de l'IA est beaucoup plus large que la conformité réglementaire. Pacte sur l'IA de la Commission européenne offrent des possibilités d'échange entre pairs autour de la loi européenne sur l'IA et peuvent contribuer à obtenir l'adhésion interne et à sensibiliser à la gouvernance de l'IA. Les auteurs de cet article, par exemple, ont créé de manière proactive une petite communauté informelle de membres du Pacte sur l'IA ("AIPEX") au début de l'année pour discuter des défis actuels et des solutions à y apporter lors de réunions directes, et les membres du Bureau de l'IA ont pris le temps de se joindre à l'une de leurs réunions.

A propos des auteurs

Du groupe informel d'échange sur le pacte de l'IA ("AIPEX") :

• Øystein EndalLe directeur général de l'Agence européenne pour la sécurité et la santé au travail (ASA), responsable du risque et de la conformité dans le secteur des services financiers et de l'assurance.
• Andrea VrcicAndrea Vrcic, conseillère juridique en matière de réglementation de l'IA dans le secteur des services financiers et de l'assurance.
• Sidsel Nagresponsable de l'éthique, de la réglementation et de la gouvernance de l'IA dans le secteur du conseil, et membre du comité danois de normalisation.
• Nick MalterNick Malter, responsable de la politique et de la gouvernance de l'IA chez trail GmbH, une société de logiciels de gouvernance de l'IA. Initiateur du groupe AIPEX.

De Unique AI:

Daylan Araz est responsable de la conformité des données chez Unique AI à Zurich. Il a joué un rôle déterminant dans l'élaboration du cadre global de gouvernance de Unique AI. Il a joué un rôle de premier plan dans l'obtention de la certification ISO 42001 et a contribué aux certifications ISO 27001, ISO 9001 et SOC 2. Pour plus d'informations, veuillez contacter : aigovernance@unique.ai.