Qu’est-ce que l’AI Act change pour un ingénieur dès son entrée en vigueur ?
L’AI Act, règlement (UE) 2024/1689 entré en vigueur le 1er août 2024, transforme des principes de conformité en livrables techniques : registre des systèmes, documentation, journalisation et supervision humaine. Pour l’ingénieur, ce n’est pas un sujet juridique à déléguer, c’est une liste de propriétés d’architecture.
La réaction « on a le temps, ça ne s’applique pas tout de suite » confond le délai juridique et la préparation d’une architecture.
C’est exact sur le calendrier et faux sur la conséquence pratique. Les obligations s’échelonnent, mais les propriétés qu’elles exigent sont des propriétés d’architecture. Les ajouter à un système existant peut demander une reprise des accès, des traces et des interfaces de supervision.
Le texte final reprend l’architecture annoncée lors de l’accord politique de décembre 2023 : une approche par niveaux de risque, des pratiques interdites, des obligations renforcées pour les systèmes à haut risque et un régime propre aux modèles d’usage général.
Quel est le calendrier d’application de l’AI Act ?
Le calendrier d’application de l’AI Act s’échelonne sur trois ans à partir de l’entrée en vigueur du 1er août 2024, avec des obligations qui deviennent applicables par vagues successives. Le règlement fixe lui-même ces dates.
| Date d’application | Ce qui s’applique | Conséquence pour l’ingénieur |
|---|---|---|
| 2 février 2025 | Pratiques interdites, obligation de maîtrise de l’IA par le personnel | Vérifier qu’aucun usage interdit n’existe, former les équipes |
| 2 août 2025 | Modèles d’usage général, gouvernance et chapitre des sanctions, sauf article 101 | Obtenir et archiver la documentation des fournisseurs de modèles |
| 2 août 2026 | Majorité des dispositions, dont les systèmes à haut risque de l’annexe III | Documentation, journalisation et supervision en place |
| 2 août 2027 | Systèmes à haut risque intégrés à des produits réglementés | Même dossier, articulé avec la réglementation produit |
Ce tableau présente le calendrier prévu par le texte d’origine, à la date du 6 août 2024. L’article 4 prévoit que fournisseurs et déployeurs prennent des mesures pour assurer, dans toute la mesure du possible, une maîtrise suffisante de l’IA par les personnes concernées, en tenant compte de leurs compétences et du contexte d’usage. Une formation IA adaptée peut contribuer à cette préparation ; aucune certification universelle n’est prescrite ici.
Fournisseur ou déployeur : quelle qualification retenir pour chaque système ?
La distinction entre fournisseur et déployeur commande toutes les obligations de l’AI Act : le fournisseur met un système sur le marché ou en service, le déployeur l’utilise sous sa propre autorité. Les obligations ne sont pas les mêmes, et une même organisation est très souvent les deux à la fois selon le système considéré.
Utiliser un système sous sa propre autorité correspond au rôle de déployeur, hors usage personnel non professionnel. Développer ou faire développer un système et le mettre en service sous son nom peut correspondre au rôle de fournisseur, même sans vente. Cette qualification se tranche système par système, et elle décide de la liste des livrables : d’où l’importance du registre, qui est le premier document à produire.
| Obligation | Fournisseur d’un système à haut risque | Déployeur d’un système à haut risque |
|---|---|---|
| Documentation technique | La rédige et la tient à jour | Dispose des instructions et informations nécessaires à son utilisation |
| Journalisation | Conçoit la capacité de journaliser | Conserve les journaux sous son contrôle, au moins six mois |
| Supervision humaine | Rend le système supervisable | Désigne des personnes compétentes et leur en donne les moyens |
| Notice d’utilisation | La fournit | La suit |
Un exemple générique : une banque qui achète un outil de tri de candidatures est déployeur ; si elle le modifie substantiellement ou le commercialise sous son nom, elle peut basculer dans le rôle de fournisseur.
Quels livrables préparer pour un système pouvant relever du haut risque ?
Je prépare un inventaire justifié, une documentation évolutive, des traces utiles et une supervision opérante pour les systèmes concernés, en proportionnant chaque livrable à leur qualification.
- Le registre : un système par ligne, avec sa finalité, son rôle, ses données, son niveau de risque et la justification de ce niveau. C’est le document que l’on présente en premier à un tiers.
- La documentation technique : architecture, provenance des données, limites connues, décisions écartées et pourquoi. Écrite au fil de l’eau, elle conserve les décisions ; reconstituée après, elle dépend de traces parfois manquantes.
- Le dispositif de journalisation : ce qui a été demandé, quels documents ont été retrouvés, ce qui a été répondu, ce que l’humain a validé ou corrigé.
- Le dispositif de supervision : le point d’arrêt, le contexte fourni à celui qui valide, et la mesure du temps réellement disponible pour le faire.
Comment produire ces livrables dans le bon ordre ?
Les livrables techniques de l’AI Act se produisent en cinq étapes, de l’inventaire des systèmes à la revue périodique, et chaque étape s’appuie sur la précédente. L’ordre compte plus que l’exhaustivité.
- Inventorier les systèmes existants et en projet, y compris les outils du commerce utilisés par les équipes.
- Qualifier chacun : rôle (fournisseur ou déployeur), niveau de risque, justification écrite.
- Activer la journalisation sur tout système qui pourrait relever du haut risque, sans attendre la qualification définitive.
- Rédiger la fiche de chaque système et la documentation au fil des décisions d’architecture.
- Instaurer une revue trimestrielle qui met à jour le registre, les fiches et les pièces des fournisseurs.
Les systèmes qui agissent, et pas seulement qui répondent, demandent un soin particulier sur la supervision, comme le montre la question du périmètre des agents IA.
Comment rendre la supervision humaine effective et non déclarative ?
La supervision humaine d’un système à haut risque doit permettre aux personnes désignées de comprendre ses limites, de contester ses sorties et d’intervenir réellement dans son fonctionnement. Une validation affichée à l’écran ne suffit pas.
Dimensionnez le débit selon la capacité de contrôle, en évitant les validations mécaniques. Une personne doit disposer des informations nécessaires et du pouvoir d’arrêter ou de corriger. Le temps de relecture peut renseigner sur la charge ; il ne prouve pas seul l’effectivité de la supervision.
La Commission explique dès le 1er août 2024 que les systèmes à haut risque doivent notamment satisfaire des exigences de qualité des données, d’information et de contrôle humain. Ces exigences dépendent de la qualification du système et de la date d’application.
Pourquoi documenter les décisions d’architecture pendant le projet ?
Documenter les décisions d’architecture au moment où elles sont prises conserve leurs raisons, leurs alternatives et leurs limites, ce qui facilite la recette et les reprises ultérieures.
Écrire la documentation technique pendant, jamais après. Une décision d’architecture s’explique en trois lignes le jour où on la prend. Six mois plus tard, il faut d’abord la retrouver, puis reconstituer les raisons, et celui qui l’a prise est souvent parti.
Que faut-il réclamer au fournisseur du modèle ?
Le fournisseur d’un modèle d’IA à usage général doit prévoir des informations utiles aux intégrateurs, une politique de respect du droit d’auteur et un résumé public de l’entraînement selon le texte d’origine. Ces obligations suivent leur calendrier d’application.
L’article 53 distingue la documentation destinée aux autorités, les informations destinées aux fournisseurs de systèmes qui intègrent le modèle et le résumé public du contenu d’entraînement. Les pièces ne sont donc pas toutes publiques ; la transmission doit tenir compte des exceptions et de la confidentialité.
Au contrat, demandez les capacités, limites et conditions d’utilisation nécessaires au système concerné. Archivez les versions obtenues et identifiez les pièces encore indisponibles. Un résumé public ne remplace pas la documentation utile à votre intégration.
Par quoi commencer quand le temps manque ?
Quand le temps manque, la journalisation passe toujours en premier, parce que c’est la seule pièce du dossier AI Act dont le report a un coût irréversible. Une politique se rédige à n’importe quel moment ; des traces ne se reconstituent pas.
Un système qui n’a rien journalisé pendant dix-huit mois ne peut pas produire ces traces, quelle que soit la bonne volonté de l’équipe. Et il ne faut en aucun cas en fabriquer : une fausse pièce coûte plus cher que le manquement qu’elle prétend couvrir.
Question, références des extraits, réponse, décision humaine et horodatage constituent un point de départ à adapter au risque. Protégez ces traces, limitez les données enregistrées et définissez leur durée de conservation. L’ordre complet des priorités est détaillé dans ce qui doit exister avant l’échéance.
Comment tenir le dossier sans mobiliser un service entier ?
Une personne par système, une fiche d’une page, un rendez-vous trimestriel : la lourdeur de la conformité AI Act vient de l’organisation choisie, pas de l’obligation elle-même. Un schéma centralisé peut perdre les détails si les équipes techniques ne contribuent pas.
Confier le dossier à un service unique qui doit interroger toutes les équipes et documenter des systèmes qu’il ne connaît pas produit un chantier sans fin.
Le schéma qui fonctionne répartit : chaque équipe rédige la fiche du système qu’elle a construit, sur un modèle commun. Un rôle central consolide et relit, sans rédiger. Le format de la fiche est décrit dans écrire la fiche d’un système d’IA. Pour un premier inventaire avec qualification de chaque système, un audit IA produit directement le registre.
Identifier les métiers concernés par l’IA aide à associer chaque usage à son détenteur métier, à son responsable technique et à la personne qui tranche ses limites.
Lectures complémentaires : l’omnibus ne solde pas le sujet ; ce qui doit descendre la chaîne ; ce qui doit exister avant l’échéance ; écrire la fiche d’un système d’IA. Ces liens complètent la navigation du site.
Quelles questions distinguent entrée en vigueur et obligations applicables ?
L’analyse de l’AI Act doit distinguer son calendrier, les rôles de l’organisation et la qualification de chaque système avant d’attribuer des obligations techniques à une équipe.
Questions fréquentes
Fournisseur ou déployeur : pourquoi cette distinction commande-t-elle tout ?
La qualification décide des obligations applicables. Intégrer un modèle tiers dans son propre système peut faire de l’organisation un fournisseur de système ; utiliser un système sous son autorité peut en faire un déployeur.
Quelle pièce du dossier AI Act traiter en priorité ?
La journalisation. C’est la seule dont le report a un coût irréversible : ce qui n’est pas tracé aujourd’hui ne sera jamais reconstituable, et fabriquer des traces après coup est hors de question.
Que faut-il obtenir du fournisseur du modèle ?
Les informations nécessaires à l’intégration, les capacités et limites, les conditions d’usage et les pièces prévues par le texte selon leur calendrier. Seul le résumé d’entraînement est expressément destiné au public ; toutes les pièces ne le sont pas.
Faut-il un service dédié à la conformité AI Act ?
Non. Une personne par système, une fiche d’une page rédigée par l’équipe qui l’a construit, et un rendez-vous trimestriel. Les équipes techniques doivent contribuer même lorsqu’un service central coordonne le dossier.
L’AI Act s’applique-t-il dès son entrée en vigueur ?
Il est en vigueur depuis le 1er août 2024, mais ses obligations s’appliquent par étapes : pratiques interdites et maîtrise de l’IA au 2 février 2025, modèles d’usage général au 2 août 2025, la majorité des dispositions au 2 août 2026. Les propriétés d’architecture qu’il exige doivent cependant être prévues dès maintenant.
Qu’est-ce que le registre des systèmes d’IA ?
C’est un inventaire interne, un système par ligne, qui indique la finalité, le rôle de l’organisation, les données traitées, le niveau de risque et sa justification. C’est le premier document à produire, parce qu’il détermine la liste des autres livrables.