Le 2 août 2026, les obligations de l'AI Act pour les systèmes IA à haut risque (Annexe III) s'appliquent. Sept piliers à mettre en production. Voici la traduction technique des exigences pour un éditeur SaaS.
Êtes-vous concerné ?
L'Annexe III du règlement liste les systèmes IA à haut risque par domaine d'usage. Les principales catégories qui touchent les éditeurs :
- Recrutement et RH : systèmes qui filtrent CV, classent candidats, prennent des décisions sur la promotion ou le licenciement.
- Éducation : systèmes qui notent ou orientent des élèves, détectent la fraude.
- Crédit et services financiers : scoring crédit, évaluation d'éligibilité, détection de fraude qui impacte l'accès aux services.
- Forces de l'ordre : profilage, prévention crime — moins probable pour un SaaS B2B classique.
- Migration et frontières : usages spécifiques.
- Justice : assistance à la prise de décision juridictionnelle.
- Démocratie : influence sur le processus électoral.
- Infrastructure critique : eau, énergie, transport, santé.
- Biométrie : reconnaissance faciale, identification.
Si votre produit IA tombe dans une de ces catégories, vous êtes concerné. Si vous fournissez à des clients dont le produit final est à haut risque, vous êtes "fournisseur en amont" et avez des obligations partielles.
Les 7 piliers techniques
1. Système de gestion des risques
Un processus documenté, itératif, qui couvre l'ensemble du cycle de vie du système IA :
- Identification des risques pour la santé, la sécurité, les droits fondamentaux.
- Évaluation et classification.
- Mesures de mitigation, testées.
- Monitoring continu en production.
C'est le pilier le plus textuel mais aussi le plus important. Sans ce processus écrit, tout le reste ne tient pas. Recommandation : aligner sur NIST AI RMF qui fournit un cadre complet.
2. Qualité des données et gouvernance
Les datasets utilisés pour entraîner, valider et tester doivent :
- Être pertinents, représentatifs, complets pour le cas d'usage.
- Avoir des propriétés statistiques documentées (notamment biais).
- Avoir un processus de collecte, annotation, transformation tracé.
- Pour les données personnelles : conformité RGPD totale (légalité, minimisation, durée).
Concrètement : une datasheet par dataset (méthodo de Gebru et al. 2018), avec versioning et lineage.
3. Documentation technique
Document détaillé pour les autorités, qui couvre :
- Description du système, ses capacités, ses limites.
- Architecture, modèles utilisés, données.
- Performances mesurées, métriques, intervalles de confiance.
- Tests effectués, résultats.
- Mesures de cybersécurité (recoupement avec CRA).
À maintenir vivant : pas un PDF figé.
4. Logging et traçabilité
Le système doit logger automatiquement :
- Inputs et outputs significatifs.
- Versions de modèles utilisées.
- Décisions prises (avec leur justification dans la mesure du possible).
- Anomalies détectées.
Conservation : la durée nécessaire pour les obligations contractuelles et légales, généralement 6 mois à 5 ans selon les domaines.
5. Transparence et information utilisateur
Les utilisateurs (et les personnes affectées, qui ne sont pas toujours les utilisateurs) doivent être informés :
- Qu'ils interagissent avec un système IA.
- Quelles décisions sont prises automatiquement, quelles sont assistées humainement.
- Quels sont leurs droits (recours, explication, opposition).
Pour les chatbots, deepfakes, contenus générés : étiquetage clair obligatoire (article 50).
6. Surveillance humaine
Le système doit être conçu pour permettre une supervision humaine effective :
- Possibilité d'arrêter le système (kill-switch).
- Possibilité de passer en mode manuel.
- Compréhension des sorties par les opérateurs (interpretability adaptée).
- Formation des opérateurs aux limites du système.
7. Robustesse, exactitude et cybersécurité
- Performance constante dans les conditions d'usage prévues, y compris dans des cas dégradés.
- Tests de robustesse adversariale.
- Mesures de cybersécurité (interne et externe) : prévention prompt injection, data poisoning, model extraction.
- Plans de réponse aux incidents IA spécifiques.
Recoupement fort avec le Threat modeling LLM et le CRA.
La conformité opérationnelle, pas juste documentaire
L'erreur classique : produire 200 pages de documentation pour cocher les cases, sans avoir réellement les processus en production. Les autorités (au niveau national, en France ce sera la DGE et la CNIL principalement) auront le pouvoir de demander des audits.
Posture recommandée :
- Démarrer par un diagnostic d'écart : où en est-on sur chaque pilier ?
- Hiérarchiser les chantiers par risque résiduel, pas par facilité.
- Investir dans l'outillage (logging structuré, model registry, dataset versioning) — la documentation suit naturellement.
- Documenter en parallèle, en s'appuyant sur les artefacts techniques.
Articulation avec les autres normes
L'AI Act ne remplace pas, il s'ajoute :
- ISO 42001 (article dédié) : système de management de l'IA. Très complémentaire.
- NIST AI RMF (article dédié) : cadre opérationnel.
- RGPD : reste applicable pour toutes les données personnelles.
- CRA (article dédié) : pour la sécurité du produit logiciel.
Une démarche AI Act bien menée s'appuie sur ISO 42001 ou NIST AI RMF comme socle, l'AI Act apportant les exigences spécifiquement européennes (langue, autorités, marquage CE-AI).
Le calendrier réaliste
Pour un éditeur de taille moyenne (20-100 personnes) avec un système IA à haut risque déjà en production :
- 6 mois pour le diagnostic, la cartographie, l'outillage initial.
- 12 mois pour l'industrialisation des 7 piliers.
- 18 mois pour la documentation auditable et les premières revues.
Vous avez jusqu'au 2 août 2026 pour les premiers piliers, et certaines exigences continueront à se déployer en 2027. Si vous démarrez maintenant (mai 2026), vous êtes dans les temps. Si vous démarrez en juillet 2026, vous êtes en retard.
