AI Act : la conformité sans l'abstraction.

Classez le système avant toute autre chose

Toute décision liée à l'AI Act commence par une question : dans quel niveau ce système se range-t-il. Une classification erronée vous conduit soit à sur-concevoir un chatbot, soit à sous-protéger un outil de tri de CV qu'un régulateur traitera comme à haut risque. Les quatre niveaux ne forment pas un spectre sur lequel on se positionne ; ce sont des catégories distinctes aux conséquences juridiques différentes, et un même produit peut relever de plusieurs s'il regroupe plusieurs fonctions.

La classification dépend de la finalité prévue, pas de la sophistication technique. Une simple régression logistique qui décide de l'octroi d'un prêt est à haut risque. Un grand modèle multimodal qui recommande des recettes ne l'est pas. L'Act s'intéresse à l'usage du système et aux personnes qu'il affecte, de sorte que le travail de classification revient conjointement au produit et à la conformité, et non à la seule équipe de data science.

En salle d'audit, la plupart des litiges ne portent pas sur minimal contre élevé ; ils portent sur élevé contre limité, à la frontière. Si vous ne pouvez pas défendre la classification par écrit, traitez le système comme relevant du niveau supérieur jusqu'à ce que vous le puissiez. Le cours AI Risk Manager déroule la logique de classification et les preuves nécessaires pour tenir une décision.

Ce que « haut risque » signifie réellement sur le terrain

Le TL;DR énumère les sept domaines d'obligations. La réalité opérationnelle, c'est que chacun est un processus récurrent, et non un document que l'on rédige une fois. La conformité au haut risque est un système que vous faites tourner pendant toute la vie du produit, et l'Act attend de vous que vous démontriez que ce système est actif, pas qu'il existait le jour du lancement.

1. La gestion des risques est continue. Vous identifiez les mésusages et préjudices prévisibles, vous les atténuez, vous testez le risque résiduel, et vous recommencez à chaque modification substantielle. Un registre des risques figé au lancement est un constat d'écart, pas une mesure de maîtrise.
2. La gouvernance des données couvre les jeux d'entraînement, de validation et de test : représentativité, examen des biais, lacunes et provenance des données. Vous devez montrer ce que vous avez vérifié et ce que vous avez trouvé, et pas seulement affirmer que les données étaient « bonnes ».
3. La documentation technique est la colonne vertébrale du dossier. Elle décrit le système, sa finalité, ses choix de conception, ses indicateurs de performance et ses limites, avec un niveau de détail suffisant pour qu'un tiers puisse en évaluer la conformité.
4. La tenue de registres signifie une journalisation automatique sur toute la durée de vie du système, de sorte que les événements soient traçables. Si quelque chose tourne mal, vous devez pouvoir reconstituer ce que le système a fait.
5. La supervision humaine doit être pensée dès la conception, et non rajoutée après coup : les personnes qui supervisent le système doivent pouvoir comprendre, intervenir et passer outre, et l'interface doit rendre cela possible.
6. L'exactitude, la robustesse et la cybersécurité doivent être mesurées et déclarées, puis tenues dans des conditions réelles, y compris adverses. « Ça marche sur la démo » n'est pas une preuve de robustesse.

Ces obligations se cartographient proprement sur un système de management, ce qui explique pourquoi les équipes associent l'Act à ISO/IEC 42001. Le cours ISO 42001 Lead Implementer construit le modèle opérationnel qui transforme ces sept domaines en processus répétables, avec des responsables, des preuves et des cycles de revue.

Le déroulé de l'évaluation de conformité

L'évaluation de conformité est le verrou qu'un système à haut risque franchit avant sa mise sur le marché européen. Pour la plupart des catégories à haut risque, il s'agit d'une évaluation par contrôle interne, menée par le fournisseur au regard des exigences de l'Act ; certaines catégories, notamment une partie de la biométrie, passent par un organisme notifié. Dans les deux cas, la séquence est la même, et il vaut mieux la traiter comme un plan de projet que comme une simple liste à cocher.

1. Confirmez la classification et les exigences applicables à votre cas d'usage et à votre catégorie spécifiques.
2. Mettez en place les processus de gestion des risques et de gouvernance des données et faites-les tourner, en produisant de vraies preuves plutôt que des éléments factices.
3. Assemblez la documentation technique de sorte qu'elle soit complète et cohérente, en interne, avec les journaux, les résultats de tests et le registre des risques.
4. Menez l'évaluation de conformité (interne, ou via un organisme notifié lorsque c'est requis) et résolvez les écarts qu'elle fait apparaître.
5. Établissez la déclaration de conformité UE, apposez le marquage CE et enregistrez le système dans la base de données de l'UE avant la mise sur le marché.
6. Passez à la surveillance après commercialisation dès le premier jour, car l'obligation ne s'arrête pas au lancement.

La surveillance après commercialisation et le calendrier par phases

Mettre un système sur le marché est le point médian de l'obligation, pas son terme. Les fournisseurs doivent exécuter un plan de surveillance après commercialisation qui collecte activement des données de performance et d'incidents sur toute la vie déployée du système, et les incidents graves doivent être signalés aux autorités dans des délais définis. Des modifications substantielles peuvent réenclencher une évaluation de conformité, de sorte que votre processus de gestion du changement et votre processus AI Act doivent être reliés.

Le calendrier est par phases, ce qui piège les équipes qui lisent « août 2027 » et supposent qu'elles ont jusque-là pour tout. Les interdictions des pratiques inacceptables s'appliquent déjà. Les obligations GPAI et plusieurs dispositions de gouvernance interviennent plus tôt dans le calendrier, et les obligations relatives au haut risque entrent en vigueur progressivement jusqu'en août 2027 selon la catégorie. La bonne posture consiste à rattacher chacun de vos systèmes à sa propre date d'application, plutôt que de planifier autour d'une unique échéance couperet.

Faire tourner la boucle de surveillance et de gestion des incidents, c'est là que les rôles d'auditeur IA et de gestionnaire des risques prennent toute leur valeur. Le cours AI auditor (AAIA) explique comment auditer un système de management de l'IA au regard de ces preuves, et le cours advanced AI auditor (AAIR) approfondit le travail de test et d'assurance qui sous-tend un dossier après commercialisation défendable.

IA à usage général : une obligation distincte dont vous pouvez hériter

Les règles relatives aux modèles GPAI se placent à côté des niveaux de risque, et non à l'intérieur. Si vous construisez ou affinez un modèle à usage général, vous portez des obligations de fournisseur : documentation technique du modèle, informations destinées aux déployeurs en aval, politique de droit d'auteur, et résumé public du contenu d'entraînement. Les modèles jugés porteurs d'un risque systémique assument des devoirs renforcés, dont l'évaluation du modèle, les tests adverses et le signalement des incidents.

Le piège, pour la plupart des équipes, est l'autre versant de cette relation. Si vous intégrez un modèle de fondation tiers dans votre propre système à haut risque, vous n'échappez pas à l'Act en pointant le fournisseur du modèle. Vous héritez du risque d'intégration et restez responsable de la mise en conformité de votre système. Traitez la documentation du fournisseur du modèle comme une entrée de votre dossier, pas comme un substitut, et mettez en place les clauses contractuelles de répercussion avant de livrer.

Erreurs courantes et la décision qui vous attend

• Traiter la classification comme un acte unique. Une fonctionnalité qui démarrait comme moteur de recommandation devient à haut risque dès l'instant où elle conditionne une décision d'embauche ou de crédit. Reclassez à chaque changement matériel de finalité.
• Rédiger la documentation comme un artefact de lancement. Le dossier doit rester synchronisé avec le système en exploitation ; un dossier périmé est pire qu'un dossier incomplet, car il induit activement en erreur.
• Confondre le système de management et la réglementation. ISO 42001 organise votre preuve, mais ne rend pas, à lui seul, un système conforme à l'AI Act. Vous devez toujours classer, évaluer et enregistrer au regard de l'Act.
• Supposer que les obligations de fournisseur GPAI couvrent votre intégration. Ce n'est pas le cas. Votre système à haut risque a besoin de son propre récit de conformité.
• Planifier autour d'une seule échéance. Les dates par phases font que certaines obligations sont déjà en vigueur tandis que d'autres sont à plusieurs années ; planifiez par système, par catégorie.

La décision qui attend la plupart des équipes n'est pas de savoir s'il faut se conformer, mais comment bâtir la capacité à se conformer de façon répétée. Si vous partez de zéro, le cours ISO 42001 Foundation donne à l'équipe un vocabulaire commun, et le cours AI security management (AAISM) relie les obligations de cybersécurité et de robustesse de l'Act au programme de sécurité que vous faites déjà tourner. Choisissez le rôle le plus proche de votre lacune et construisez à partir de là.