Au 2 août 2026, l’AI Act marque une étape opérationnelle pour les organisations qui conçoivent, déploient ou utilisent des systèmes d’intelligence artificielle dans l’Union européenne. Le texte structure une approche par les risques, avec des exigences qui montent en intensité selon les usages, depuis les outils bureautiques jusqu’aux applications qui influencent une décision d’embauche, d’octroi de crédit ou de sécurité. Pour de nombreuses entreprises, le sujet n’est plus de « suivre la réglementation », mais d’identifier précisément leur rôle dans la chaîne de valeur, puis d’industrialiser des preuves de conformité.

Le règlement s’appuie sur une définition large d’un système d’IA, la Commission européenne le décrit comme un système machine capable de fonctionner avec des niveaux d’autonomie variables, pouvant s’adapter après déploiement, et produisant des résultats comme des contenus, recommandations ou décisions. Cette largeur place dans le périmètre un grand nombre de solutions, dont les assistants conversationnels, les systèmes de recommandation, ou certaines formes d’automatisation avancée en industrie. Les directions juridiques, RSSI et DSI se retrouvent, en résultat, à devoir cartographier des briques techniques parfois achetées « sur étagère » et déployées en cloud.

AI Act: les rôles « fournisseur » et « déployeur » clarifient la responsabilité

Le premier changement concret, au 2 août 2026, tient à la nécessité de qualifier le rôle de l’entreprise. Le règlement distingue notamment le fournisseur (qui développe ou met sur le marché un système) et le déployeur (qui l’utilise dans ses processus). Cette distinction n’est pas théorique, elle conditionne les obligations documentaires, les contrôles internes, et la charge de preuve en cas d’audit. Une entreprise qui intègre un composant d’IA dans un produit, même acheté à un tiers, peut se retrouver avec des obligations proches de celles d’un fournisseur si elle modifie substantiellement le système ou son usage.

Cette clarification oblige les groupes à revoir leurs contrats. Les clauses attendues portent sur l’accès à la documentation, les limites d’usage, les mises à jour, les mesures de sécurité, et les mécanismes d’escalade en cas d’incident. Dans les appels d’offres, les équipes achats et IT doivent demander des éléments vérifiables, par exemple la traçabilité des données d’entraînement lorsque cela est requis, ou la description des contrôles de performance. Dans les environnements multicloud, la difficulté est aussi organisationnelle, qui conserve les éléments probants lorsque le service est opéré par un fournisseur SaaS.

La logique de classification par risques impose aussi des arbitrages produit. Les cas d’usage considérés comme haut risque déclenchent des exigences fortes, ce qui peut conduire à repositionner un projet, ou à introduire des garde-fous pour éviter des décisions entièrement automatisées. Certaines entreprises font évoluer leurs processus pour maintenir une supervision humaine formelle et traçable, dans les fonctions RH, conformité, ou relation client. Cette supervision n’est pas une simple validation de façade, elle doit être conçue pour détecter des dérives et permettre une intervention effective.

Le texte pousse enfin à structurer la gouvernance IA en mode « ligne de défense ». De plus en plus d’organisations alignent le pilotage sur des schémas proches de ceux de la cybersécurité ou du contrôle interne, avec un référent conformité, une revue des modèles, et des procédures de gestion des incidents. Cette approche répond à une réalité, des erreurs d’IA, dont les « hallucinations » documentées dans plusieurs secteurs, peuvent se transformer en risques juridiques, réputationnels et financiers lorsque des décisions s’appuient sur des informations fausses ou invérifiables.

Les exigences de traçabilité et de contrôle montent pour les usages à risque

Pour les systèmes classés en haut risque, l’AI Act impose une discipline proche de celle des secteurs régulés. Les entreprises doivent démontrer une gestion des risques sur tout le cycle de vie, avec des tests, des indicateurs et des processus d’amélioration continue. Concrètement, cela se traduit par des dossiers techniques, des procédures de validation, et des journaux d’événements permettant d’expliquer ce qui s’est produit lors d’une décision ou d’un incident. Dans les grandes organisations, cette documentation doit être automatisée autant que possible, car les cycles de mise à jour des modèles et des données sont rapides.

La qualité des données devient un sujet central. Même quand une entreprise ne forme pas elle-même de modèle, elle alimente souvent le système avec ses données internes, tickets de support, dossiers clients, historiques de production. L’AI Act oblige à mieux qualifier les sources, les biais potentiels, et les conditions d’usage. Cela pousse les DSI à relier gouvernance IA et gouvernance data, avec une attention particulière sur la minimisation, l’accès, et la conservation, afin de ne pas multiplier des jeux de données « fantômes » dans des espaces collaboratifs.

Autre conséquence, la sécurité et la robustesse sont traitées comme des obligations de conformité, pas comme des options. Cela recoupe des pratiques déjà connues en cybersécurité, durcissement des accès, segmentation, supervision, réponse à incident, mais adaptées à des risques spécifiques, empoisonnement de données, détournement de prompt, extraction de données sensibles. Dans une entreprise, ces risques touchent autant les équipes métiers qui utilisent des assistants que les équipes IT qui gèrent les connecteurs vers des applications internes.

Le règlement amène aussi un effort de transparence envers les utilisateurs et, selon les cas, envers des personnes concernées par la décision. Pour des outils de génération de contenu ou d’assistance, les entreprises doivent encadrer l’usage, former, et documenter, afin d’éviter que des employés prennent une réponse générée pour une information certaine. Cette mesure répond à une réalité opérationnelle, l’IA peut produire des recommandations plausibles mais erronées, ce qui nécessite des procédures de vérification, des règles de citation de sources, et des limites claires sur les tâches autorisées.

DSI, juristes et métiers réorganisent les achats IA et les procédures internes

Au 2 août 2026, la mise en conformité se traduit souvent par un chantier transversal. Les DSI doivent recenser les systèmes d’IA, y compris ceux adoptés de manière opportuniste par les équipes. Les juristes et la conformité demandent ensuite une qualification, système d’IA au sens du règlement ou non, niveau de risque, rôle de l’entreprise, obligations associées. Cette cartographie devient un document vivant, car les fonctionnalités des services cloud évoluent vite, et un outil de productivité peut intégrer des fonctions d’agent ou d’automatisation avancée en quelques semaines.

Les achats évoluent également. Là où l’on évaluait surtout le coût, la performance, et la sécurité informatique, il faut désormais intégrer des exigences de conformité, dont l’accès à la documentation, la capacité à fournir des preuves, et la gestion des sous-traitants. Les contrats incluent plus souvent des engagements sur la traçabilité, la localisation des traitements lorsque cela est nécessaire, et des mécanismes d’audit. Les grands comptes cherchent à éviter une dépendance à des « boîtes noires » incapables d’expliquer comment une décision a été produite.

Les métiers, de leur côté, doivent intégrer des procédures. Dans un centre de relation client, l’IA peut suggérer une réponse, mais l’entreprise doit définir ce qui est autorisé, ce qui doit être validé, et ce qui doit être interdit, par exemple des conseils à portée juridique ou médicale. Dans les RH, l’usage d’outils d’aide au recrutement peut relever d’un périmètre sensible, ce qui impose une documentation et des contrôles renforcés. Pour le marketing, la génération de contenu implique des garde-fous sur la propriété intellectuelle, la véracité des informations, et la validation éditoriale.

Les formations deviennent un levier de conformité. Beaucoup d’entreprises instaurent des modules pour expliquer les limites des modèles, les risques de divulgation de données, et les règles de traçabilité. Les équipes apprennent à documenter leurs prompts, à vérifier les sources, et à signaler les comportements anormaux. Cette montée en maturité se combine avec l’émergence d’outils d’observabilité IA, capables de mesurer les taux d’erreur, les dérives, et les points de rupture, afin de démontrer un contrôle effectif plutôt qu’un simple affichage de principes.