AI Act : ce que les équipes techniques doivent anticiper dès maintenant

L’AI Act européen est entré en vigueur en août 2024. Les premières obligations s’appliquent depuis février 2025 (interdictions sur les systèmes IA à risque inacceptable). Les obligations pour les systèmes à risque élevé arrivent en août 2026. Ce n’est pas loin.

Pourtant, la majorité des équipes techniques n’ont pas encore fait le travail de cartographie de leurs systèmes et de leurs obligations. Ce qui se comprend : le texte est dense, les lignes directrices attendues tardent, et le périmètre exact de certaines catégories reste flou. Mais “le texte est complexe” n’est pas une stratégie de conformité.

Voici ce que les équipes techniques ont besoin de comprendre et d’anticiper maintenant.

La logique de classement par risque

L’AI Act classe les systèmes IA en quatre catégories selon leur niveau de risque. C’est ce classement qui détermine vos obligations.

Risque inacceptable, interdit

Les systèmes manipulant les comportements de façon subliminale, le scoring social généralisé par les autorités publiques, les systèmes d’identification biométrique en temps réel dans les espaces publics (avec exceptions étroites). Ces catégories sont interdites depuis février 2025. Si vous avez ce type de système, c’est une urgence juridique, pas technique.

Risque élevé, obligations lourdes

C’est là que se concentrent la plupart des obligations pour les entreprises privées. Un système IA est classé à risque élevé s’il est déployé dans des domaines listés en Annexe III : infrastructures critiques, éducation, emploi, accès à des services publics essentiels, application de la loi, gestion des migrations, administration de la justice.

Pour le secteur financier en particulier : les systèmes utilisés pour l’évaluation de la solvabilité des personnes physiques, le scoring crédit, et les décisions d’accès à des produits financiers sont explicitement listés.

Risque limité, obligations de transparence

Chatbots, systèmes de génération de contenus : obligation d’informer l’utilisateur qu’il interagit avec un système IA. C’est souvent ce que les entreprises ont déjà mis en place, mais le règlement le rend obligatoire.

Risque minimal

La grande majorité des applications IA : filtres spam, recommandation de contenu, jeux vidéo. Pas d’obligations spécifiques au-delà du droit commun.

Ce que “risque élevé” implique techniquement

Si votre système est classé à risque élevé, voici les obligations techniques principales :

Système de gestion des risques

Pas une évaluation ponctuelle, mais un système continu d’identification, d’analyse et de traitement des risques tout au long du cycle de vie. Cela inclut :

• Tests avant mise sur le marché et mise en service
• Plan de surveillance post-déploiement
• Processus de mise à jour quand de nouveaux risques sont identifiés

Gouvernance des données

Les données d’entraînement, de validation et de test doivent répondre à des pratiques de gouvernance documentées :

• Identification des biais potentiels et mesures de mitigation
• Traçabilité des datasets utilisés (provenance, preprocessing appliqué)
• Pour les données personnelles : conformité RGPD intégrée (pas séparée)

Journalisation automatique (logging)

Les systèmes à risque élevé doivent enregistrer automatiquement les événements pertinents pendant leur fonctionnement, “dans la mesure nécessaire pour permettre d’identifier les risques”.

En pratique : chaque décision significative du système doit être traçable avec ses inputs, ses outputs, le modèle utilisé, la version, l’horodatage. Ce n’est pas du monitoring opérationnel : c’est de l’auditabilité réglementaire. La durée de conservation dépend du cas d’usage (minimum : durée de vie du système + 10 ans pour certaines catégories).

Transparence et documentation

Une documentation technique (Technical File) doit accompagner chaque système à risque élevé. Elle comprend :

• Description générale du système et de son usage prévu
• Éléments de conception : architecture, logique de fonctionnement
• Description des données d’entraînement
• Évaluation des risques
• Métriques de performance et seuils acceptables
• Mesures de cybersécurité

Cette documentation doit être tenue à jour et mise à disposition des autorités de surveillance sur demande.

Supervision humaine

Les systèmes à risque élevé doivent être conçus pour permettre une supervision humaine effective. Ce qui implique :

• Des interfaces permettant aux opérateurs humains de surveiller le comportement du système
• La capacité d’intervenir, de corriger ou d’arrêter le système
• Des alertes quand le système fonctionne hors de ses paramètres normaux
• La possibilité de désactiver le système en toute sécurité

Ce n’est pas qu’une case à cocher : c’est une exigence de conception. Un système qui prend des décisions de façon entièrement autonome sans point de contrôle humain identifiable sera difficilement conforme.

Les obligations pour les fournisseurs de modèles à usage général (GPAI)

Si vous utilisez un LLM en tant qu’élément d’un système que vous fournissez (et non uniquement en interne), vous êtes concerné par les obligations sur les modèles à usage général.

Pour les modèles à “impact systémique” (> 10^25 FLOPs d’entraînement, typiquement les grands modèles de fondation), les obligations incluent des évaluations adversariales et des obligations de notification des incidents.

Pour la plupart des usages, les obligations portent sur :

• La documentation de l’architecture et des capacités du modèle
• La politique d’utilisation acceptable
• Les informations sur les données d’entraînement (dans les limites du secret commercial)

Si vous utilisez un modèle de fondation tiers (OpenAI, Anthropic, Mistral, Google) comme brique de votre système, le fournisseur du modèle a ses propres obligations, mais vous restez responsable de l’usage que vous en faites dans votre système.

La conformité par design : pourquoi c’est différent du RGPD

Le RGPD a introduit la notion de “Privacy by Design”, intégrer la protection des données dès la conception. L’AI Act fait de même avec la conformité IA.

Pourquoi c’est plus difficile que le RGPD :

Le RGPD porte principalement sur des processus et des règles organisationnelles. Un DPO compétent peut souvent auditer et corriger des pratiques sans toucher au code.

L’AI Act porte sur des propriétés du système lui-même : exactitude, robustesse, traçabilité, supervision. Ces propriétés ne s’ajoutent pas en rattrapage : elles doivent être architecturées.

Concrètement : un système de scoring crédit déployé sans logging des décisions ne peut pas devenir conforme sans refonte du système de logging. Un système qui ne permet pas de supervision humaine ne peut pas en permettre sans refonte de son architecture de contrôle.

C’est pourquoi “on verra à l’échéance” est une stratégie perdante. Le temps de refonte n’est pas négligeable.

Le calendrier des obligations à retenir

Août 2026 pour les systèmes à risque élevé, c’est 14 mois. Le cycle de mise en conformité d’un système existant (cartographie, analyse de gap, refonte, tests, documentation) prend facilement 12 à 18 mois.

Par où commencer : 3 actions prioritaires

1. Cartographier vos systèmes IA Inventaire de tous les systèmes qui utilisent de l’IA (y compris les briques achetées à des tiers). Pour chacun : usage prévu, domaine d’application, population impactée. Croisé avec l’Annexe III : lequel est potentiellement à risque élevé ?

2. Documenter ce qui existe Pour chaque système identifié à risque élevé potentiel : récupérer la documentation technique disponible. Identifier les lacunes (logging insuffisant, absence de métriques de performance documentées, pas de procédure de supervision humaine définie).

3. Prioriser les chantiers techniques Les lacunes de documentation se comblent vite. Les lacunes architecturales (logging, supervision, traçabilité) prennent du temps. C’est sur ces dernières que l’analyse de gap doit produire un plan d’action dès maintenant.

Conclusion

L’AI Act n’est pas un règlement comme les autres. Il porte directement sur les propriétés de vos systèmes : exactitude, robustesse, traçabilité. Pas juste sur des process. Pour les équipes qui développent des systèmes IA dans des domaines sensibles, la conformité doit être un critère de conception, pas une vérification finale.

Les 14 mois qui restent avant les obligations sur les systèmes à risque élevé sont suffisants, à condition de commencer maintenant.

Vous avez des systèmes IA en production ou en développement dans un secteur réglementé ? On peut auditer votre exposition en quelques jours. Parlons-en.