1. Système de gestion des risques (art. 9)
Un processus continu et itératif sur tout le cycle de vie du système : identifier et analyser les risques connus et prévisibles pour la santé, la sécurité et les droits fondamentaux ; estimer ceux qui peuvent survenir en usage normal comme en cas de mauvais usage raisonnablement prévisible ; adopter des mesures de gestion appropriées ; et tester. Ce n'est pas un document figé mais une démarche vivante, réévaluée régulièrement.
2. Gouvernance des données (art. 10)
Les jeux de données d'entraînement, de validation et de test doivent répondre à des critères de qualité : pratiques de gouvernance appropriées, examen des biais possibles, pertinence et représentativité statistique au regard des personnes concernées, et prise en compte des spécificités du contexte d'utilisation. La qualité des données conditionne directement celle des décisions — et le risque de discrimination.
3. Documentation technique (art. 11)
Une documentation conforme à l'annexe IV, établie avant la mise sur le marché et tenue à jour. Elle démontre la conformité du système et permet aux autorités d'en évaluer les caractéristiques : description générale, éléments de conception, capacités et limites, mesures de gestion des risques, etc. Les PME peuvent utiliser un format simplifié.
4. Journalisation (art. 12)
Le système doit permettre l'enregistrement automatique des événements pertinents tout au long de sa vie, afin d'assurer un niveau de traçabilité adapté à sa finalité — utile pour la surveillance post-commercialisation, la détection d'anomalies et l'analyse d'incidents.
5. Transparence et information du déployeur (art. 13)
Le fonctionnement doit être suffisamment transparent pour que le déployeur interprète correctement les résultats et les utilise à bon escient. Cela passe par une [notice d'utilisation](/ressources/transparence-notice-article-13) claire et complète : caractéristiques, capacités et limites de performance, niveau de précision attendu, mesures de contrôle humain prévues.
6. Contrôle humain (art. 14)
Le système doit être conçu pour pouvoir être effectivement supervisé par des personnes physiques pendant son utilisation : comprendre ses capacités et ses limites, rester vigilant au risque de « biais d'automatisation » (la tendance à faire confiance sans esprit critique), pouvoir interpréter correctement les résultats, décider de ne pas l'utiliser, ou interrompre son fonctionnement. Le contrôle humain doit être réel, pas seulement théorique.
7. Exactitude, robustesse et cybersécurité (art. 15)
Un niveau approprié et constant d'exactitude (avec des métriques déclarées dans la notice), de résilience face aux erreurs, défaillances et incohérences, et de sécurité face aux tentatives de manipulation — y compris l'empoisonnement des données d'entraînement (« data poisoning ») et les attaques adverses.
| Exigence | Article | Idée-force |
|---|---|---|
| Gestion des risques | Art. 9 | Processus continu, pas un document figé |
| Gouvernance des données | Art. 10 | Qualité, représentativité, examen des biais |
| Documentation technique | Art. 11 | Annexe IV, tenue à jour |
| Journalisation | Art. 12 | Traçabilité automatique |
| Transparence déployeur | Art. 13 | Notice d'utilisation claire |
| Contrôle humain | Art. 14 | Supervision effective, anti-biais d'automatisation |
| Robustesse & sécurité | Art. 15 | Exactitude constante, résilience, cybersécurité |
Questions fréquentes
Ces exigences concernent-elles le déployeur ou le fournisseur ?
Principalement le fournisseur, qui conçoit et met sur le marché le système. Le déployeur en dépend : il doit utiliser le système conformément à la notice et mettre en œuvre le contrôle humain prévu (article 26). Un déployeur qui modifie substantiellement le système peut toutefois devenir fournisseur (article 25).
Faut-il refaire la gestion des risques à chaque évolution ?
Oui, dans son principe. Le système de gestion des risques de l'article 9 est explicitement continu et itératif : il doit être réexaminé et mis à jour tout au long du cycle de vie du système, notamment après des modifications significatives ou la détection de nouveaux risques.
Comment satisfaire l'exigence de contrôle humain ?
En désignant des personnes compétentes, formées et dotées de l'autorité nécessaire pour superviser le système, comprendre ses limites et pouvoir écarter ou interrompre une décision. Le contrôle doit être effectif : une simple validation formelle « pour la forme » ne suffit pas.
Quand ces exigences deviennent-elles obligatoires ?
Pour les systèmes à haut risque de l'annexe III, elles sont applicables au 2 décembre 2027. Pour les systèmes intégrés à des produits réglementés de l'annexe I, l'échéance est le 2 août 2028. Ces deux dates résultent du report opéré par le règlement (UE) 2026/1744. Mieux vaut engager la démarche bien avant ces dates.