AI Act : classer ses systèmes IA (Annexe III) en pratique
Le règlement européen sur l’IA ne s’applique pas de la même façon à un assistant de rédaction et à un outil qui trie des candidatures. Tout commence par une question simple, que peu d’organisations ont traitée sérieusement : quels systèmes utilisez-vous, et dans quelle catégorie tombent-ils ?
Cet article est une méthode de travail, pas un avis juridique. Le texte de référence est le règlement (UE) 2024/1689. Pour toute décision engageante, faites valider la classification par un juriste, et vérifiez le calendrier officiel à la date où vous lisez.
Le principe : une approche par les risques
L’AI Act ne régule pas « l’IA » en bloc. Il classe les usages en plusieurs niveaux :
- Les pratiques interdites (article 5) : notation sociale, manipulation exploitant des vulnérabilités, reconnaissance des émotions au travail et à l’école sauf raisons médicales ou de sécurité, constitution de bases de reconnaissance faciale par moissonnage non ciblé, entre autres.
- Les systèmes à haut risque (article 6) : ceux qui sont des composants de sécurité de produits réglementés (Annexe I), et ceux utilisés dans les domaines listés à l’Annexe III.
- Les obligations de transparence (article 50) : par exemple, informer une personne qu’elle échange avec un système d’IA, ou signaler certains contenus générés.
- Le reste, qui n’est pas soumis à des obligations spécifiques, en dehors de l’obligation de prendre des mesures pour développer la maîtrise de l’IA (article 4).
Les modèles d’IA à usage général (les grands modèles sur lesquels reposent la plupart des assistants) ont leur propre régime, qui pèse surtout sur leurs fournisseurs.
Les huit domaines de l’Annexe III
Un système est présumé à haut risque s’il est destiné à être utilisé dans l’un de ces domaines, pour les usages précisés par l’annexe :
- Biométrie : identification biométrique à distance, catégorisation biométrique, reconnaissance des émotions, dans la mesure où ces usages sont autorisés.
- Infrastructures critiques : composants de sécurité dans la gestion d’infrastructures numériques critiques, du trafic routier, ou de la fourniture d’eau, de gaz, de chauffage et d’électricité.
- Éducation et formation professionnelle : admission, évaluation des acquis, orientation, surveillance des examens.
- Emploi et gestion des travailleurs : recrutement, tri de candidatures, évaluation de candidats, décisions de promotion ou de rupture, attribution de tâches, suivi des performances.
- Accès aux services essentiels : éligibilité aux prestations publiques, évaluation de solvabilité et score de crédit (hors détection de fraude), tarification en assurance vie et santé, tri des appels d’urgence.
- Répression : usages par ou pour les autorités répressives.
- Migration, asile et contrôle aux frontières.
- Administration de la justice et processus démocratiques : aide à la décision judiciaire, systèmes destinés à influencer un scrutin.
Pour une entreprise privée, les domaines qui reviennent le plus sont les RH (4), le crédit et l’assurance (5), et parfois la biométrie (1) ou les infrastructures (2).
L’exception de l’article 6, paragraphe 3
Un système listé à l’Annexe III n’est pas considéré à haut risque s’il ne présente pas de risque important pour la santé, la sécurité ou les droits fondamentaux, notamment quand il exécute une tâche procédurale étroite, améliore le résultat d’une activité humaine déjà réalisée, détecte des écarts sans remplacer l’évaluation humaine, ou effectue une tâche préparatoire.
Deux limites importantes : un système qui fait du profilage de personnes physiques reste toujours à haut risque, et le fournisseur qui invoque l’exception doit documenter son évaluation avant la mise sur le marché et enregistrer le système. L’exception se justifie par écrit, elle ne se présume pas.
Fournisseur ou déployeur : qui porte quoi
La deuxième question, aussi décisive que la première, est votre rôle.
| Rôle | Qui | Obligations principales (haut risque) |
|---|---|---|
| Fournisseur | Celui qui développe le système, ou le fait développer, et le met sur le marché ou en service sous son nom. | Système de gestion des risques, gouvernance des données, documentation technique, journalisation, notice d’utilisation, contrôle humain, exactitude et robustesse, système de gestion de la qualité, évaluation de conformité, marquage CE, enregistrement, surveillance après commercialisation, signalement des incidents graves. |
| Déployeur | Celui qui utilise le système sous son autorité dans un cadre professionnel. | Utilisation conforme à la notice, contrôle humain confié à des personnes compétentes, pertinence des données d’entrée qu’il maîtrise, surveillance du fonctionnement, conservation des journaux, information des représentants du personnel avant un usage au travail, information des personnes concernées. Analyse d’impact sur les droits fondamentaux pour certains déployeurs, dont les organismes publics et les usages de crédit et d’assurance. |
Attention au glissement de rôle : un déployeur qui met son nom ou sa marque sur un système déjà à haut risque, ou qui le modifie substantiellement tout en le laissant à haut risque, devient fournisseur. Il en va de même s’il modifie la destination d’un système qui n’était pas à haut risque, de sorte qu’il le devient. Il porte alors toutes les obligations du fournisseur. Le risque existe quand une équipe modifie un outil ou l’utilise pour une finalité de l’Annexe III non prévue par le fournisseur.
Le calendrier, échelonné
Le règlement est entré en vigueur le 1er août 2024, avec une application progressive :
- 2 février 2025 : interdictions de l’article 5 et obligation de prendre des mesures de maîtrise de l’IA.
- 2 août 2025 : obligations des fournisseurs de modèles à usage général, gouvernance et sanctions.
- 2 août 2026 : application générale du règlement, dont les obligations de transparence de l’article 50, applicables depuis cette date.
- 2 décembre 2027 : obligations pour les systèmes à haut risque de l’Annexe III.
- 2 août 2028 : systèmes à haut risque intégrés à des produits réglementés (Annexe I).
Ces dates sont celles du règlement tel que modifié par le règlement modificatif dit « omnibus numérique sur l’IA » (JO L 2026/1744), adopté et applicable depuis le 27 juillet 2026. Il a décalé les obligations haut risque, qui devaient initialement s’appliquer en août 2026 et août 2027. Vérifiez tout de même le texte consolidé pour votre cas. Dans tous les cas, l’inventaire et la classification ne dépendent pas de ces dates : ils sont le préalable à tout le reste.
La méthode, en cinq étapes
- Inventorier. Tous les systèmes, y compris les fonctions IA intégrées dans des logiciels achetés et les usages informels d’assistants. Le shadow AI est la première source de surprises.
- Décrire la destination. Pour chaque système : à quoi il sert, qui il concerne, quelle décision il influence. C’est la destination, pas la technologie, qui détermine la classe.
- Classer. Interdit, haut risque (Annexe I ou III), transparence, ou sans obligation spécifique. Pour les cas Annexe III, examiner et documenter l’exception de l’article 6.3.
- Qualifier votre rôle. Fournisseur, déployeur, ou les deux selon les systèmes, en surveillant les modifications qui font basculer.
- Planifier. Un plan de conformité par système à haut risque, avec un propriétaire, des échéances et des preuves attendues.
Le livrable utile n’est pas un rapport de cent pages. C’est un registre vivant, tenu par quelqu’un, et relié aux décisions produit. Une matrice de responsabilités de type RASCI aide à fixer qui tient ce registre, qui le valide et qui doit être consulté.
Et l’IA en production dans tout ça ?
La conformité n’est pas un frein à la mise en production, elle en fait partie. Les exigences de journalisation, de contrôle humain et de surveillance recoupent ce qu’un système sérieux doit faire de toute façon : tracer ses décisions, permettre la reprise humaine, mesurer sa qualité dans la durée.
Les projets qui bloquent sont ceux où le juridique découvre le système au moment du lancement. Ceux qui avancent intègrent la classification dès le cadrage, comme je l’explique dans du POC IA à la production. Côté équipes, l’obligation de prendre des mesures de maîtrise de l’IA s’applique déjà : une formation sur des cas réels est la façon la plus directe d’y répondre.