Sanctions de l’AI Act : ce qui devient exigible

Le régime de sanctions de l’AI Act fixe les mesures et plafonds permettant de traiter les manquements au règlement, en tenant compte des obligations effectivement applicables.

Les États membres doivent organiser leur mise en œuvre. Les plafonds ne constituent pas des amendes automatiques. Le texte tient compte des circonstances et prévoit une règle spécifique aux PME, y compris les jeunes entreprises.

L’exigibilité se lit disposition par disposition, sans transformer une échéance du chapitre des sanctions en application immédiate de toutes les exigences. La maîtrise de l’IA constitue un sujet distinct à documenter.

Depuis le 2 août 2025, certaines dispositions de gouvernance, les règles sur les modèles d’usage général et le chapitre des sanctions s’appliquent, avec une exception pour l’article 101.

L’article 113 distingue la date du régime de sanctions de celle des obligations sanctionnées. Il ne rend pas immédiatement exigibles toutes les exigences du haut risque. Les interdictions et l’article 4 sur la maîtrise de l’IA s’appliquent déjà depuis le 2 février 2025.

Les amendes de la Commission visant les fournisseurs de modèles d’usage général, prévues à l’article 101, attendent le 2 août 2026. Les modèles mis sur le marché avant le 2 août 2025 bénéficient par ailleurs d’une transition prévue à l’article 111. Il faut qualifier le rôle, le modèle et sa date avant de conclure.

Le budget du projet ne constitue pas le plafond d’une sanction. Les plafonds liés au chiffre d’affaires concernent celui de l’entreprise dans les conditions du règlement.

L’AI Act prévoit trois niveaux d’amendes, gradués selon la gravité du manquement, dont le plus élevé vise les pratiques d’IA interdites. Les plafonds figurent à l’article 99 du règlement.

Ce sont des plafonds, modulés selon les circonstances. Le dernier niveau vise la fourniture d’informations inexactes, incomplètes ou trompeuses en réponse à une demande, et non toute difficulté à retrouver un document. L’article 99 ne prévoit pas un plafond chiffré propre à tout manquement imaginable, notamment à l’article 4. La ligne la plus lourde concerne la courte liste détaillée dans pratiques interdites : ce qu’aucun garde-fou ne rattrape.

L’exposition la plus fréquente à l’AI Act n’est pas l’amende d’un régulateur, mais l’incapacité de répondre rapidement à un client, un assureur ou un investisseur qui demande la liste des systèmes d’IA exploités.

Depuis un an, je n’ai vu aucune de mes organisations clientes faire l’objet d’un contrôle. En revanche, j’en ai vu plusieurs perdre du temps, et parfois un marché, pour une raison beaucoup plus prosaïque.

Un grand compte, un assureur ou un investisseur demande, dans le cadre d’une revue, la liste des systèmes d’IA exploités, avec leur finalité et leur niveau de risque. Le délai de réponse est court. L’organisation qui n’a pas tenu de registre découvre alors qu’elle ne sait pas répondre : non par mauvaise volonté, mais parce que l’inventaire n’a jamais été fait.

C’est cette exposition-là qui se matérialise aujourd’hui, et elle ne passe par aucun régulateur.

Un premier registre doit identifier les systèmes d’IA, leurs usages et leurs responsables, avec les données traitées et les éléments qui fondent la qualification retenue.

• Un registre, même sommaire : un système par ligne, sa finalité, qui l’utilise, quelles données, fournisseur ou déployeur, niveau de risque retenu.
• La justification du niveau en deux phrases. C’est ce qui sera discuté, pas le niveau lui-même.
• La preuve de littératie : qui a été formé, quand, sur quoi.
• Le shadow IA repéré : les outils adoptés par une équipe sans validation, et les fonctions IA activées par défaut dans des logiciels déjà en place.

Une première réponse sur les systèmes exploités demande un inventaire, des fiches reliées aux preuves disponibles et un responsable chargé de résoudre les informations encore manquantes.

1. Collecter les traces objectives. Factures des fournisseurs d’IA, clés d’API émises, abonnements souscrits sur des cartes de service, extensions installées.
2. Interroger chaque équipe avec une seule question. « Quel outil utilisez-vous qui génère, résume, classe ou recommande ? »
3. Qualifier chaque système. Pour chacun : fournisseur ou déployeur, finalité, données traitées, décision servie, niveau de risque retenu et justification en deux phrases.
4. Rédiger la fiche d’une page. Par l’équipe qui exploite le système, sur un modèle commun.
5. Vérifier la journalisation. Ce qui est demandé, ce qui est répondu, qui a validé. Ce qui n’est pas tracé aujourd’hui ne pourra pas être reconstitué.
6. Consigner la formation. Qui a été formé, à quelle date, sur quel contenu. Un tableau suffit.

Cette séquence demande seulement un responsable et une date de revue. Pour un regard extérieur sur l’état de départ, c’est l’objet d’un audit IA.

Le shadow IA est le trou le plus courant de l’inventaire parce que les outils d’IA entrent dans l’organisation par des chemins que la DSI ne voit pas : mises à jour, cartes bancaires de service, extensions.

Quand je fais l’inventaire avec une organisation, la liste initiale fournie par la DSI est, dans les cas que j’ai vus, sensiblement incomplète.

Manquent : les assistants intégrés aux suites bureautiques, activés par une mise à jour ; les outils souscrits par une direction métier sur sa propre carte ; les extensions de navigateur ; et les automatisations montées par une personne compétente dans un coin, qui fonctionnent très bien et que personne n’a documentées.

Ce dernier cas est le plus délicat, parce que l’outil est souvent utile. Le traiter comme une faute décourage exactement les gens qu’il faudrait impliquer. Ces systèmes peuvent avoir été adoptés sans dissimulation. Leur découverte demande de consulter les équipes, avec une durée adaptée à l’organisation. La méthode complète figure dans préparer un contrôle de conformité en deux semaines.

Une gouvernance proportionnée commence par connaître les usages et leurs conséquences, puis choisit les contrôles nécessaires sans supposer que tous les systèmes demandent le même dossier.

Monter une gouvernance lourde pour trois usages internes à faible enjeu est disproportionné. Ne pas savoir dire quels systèmes d’IA on exploite ne l’est pas : c’est une question à laquelle toute organisation devrait pouvoir répondre en une journée, indépendamment de toute réglementation.

Les erreurs les plus fréquentes face au régime de sanctions de l’AI Act consistent à surréagir sur la forme et à sous-réagir sur le fond : beaucoup de documents, peu de connaissance réelle des systèmes.

• Confondre gravité théorique et probabilité. Les plafonds à 7 % attirent l’attention, alors que la plupart des systèmes d’une organisation relèvent d’obligations légères.
• Écrire une politique avant d’avoir un inventaire. Une charte qui ne cite aucun système réel ne répond à aucune question posée par un client ou un contrôleur.
• Laisser la qualification au fournisseur. Le niveau de risque dépend de l’usage, et c’est l’organisation qui décide de l’usage. Le fournisseur ne peut pas répondre à sa place.
• Traiter le shadow IA comme une faute. Les personnes qui ont monté ces outils sont celles qui savent le mieux ce qu’ils font. Les sanctionner, c’est perdre l’information.
• Oublier la formation. L’article 4 s’applique depuis février 2025. Un relevé des mesures prises est utile, sans démontrer à lui seul leur adéquation. Un programme comme ceux décrits sur la page formation IA laisse cette trace.

Tenir le registre au fil de l’exploitation évite de devoir reconstruire les finalités, les responsables et les preuves disponibles lorsqu’un tiers pose une question sur les usages.

Le coût d’une réponse improvisée dépend de l’organisation et de la demande. Je ne lui attribue pas un ratio ni un délai universel. Un registre facilite la collecte ; il ne garantit ni l’absence de contrôle ni un niveau de sanction.

Au 5 août 2025, il faut préparer les exigences à venir en séparant les obligations déjà applicables des échéances du haut risque prévues par le texte d’origine.

L’échéance générale du 2 août 2026 et celle du 2 août 2027 pour les systèmes de l’article 6, paragraphe 1, ne rendent pas inutile le travail actuel. Elles imposent de lire les exceptions et les dispositions transitoires. Les propriétés techniques se préparent avant leur exigibilité.

La distinction entre préparation et conformité juridique rejoint les livrables d’ingénierie. Un registre sert à orienter ce travail ; il ne certifie pas un système.

Lectures complémentaires : l’omnibus ne solde rien, préparer un contrôle de conformité en deux semaines, ce qui doit exister avant l’échéance, écrire la fiche d’un système d’IA.