Part of the DEPLOY Method — Yield phase
L'EU AI Act est désormais applicable, et les sanctions ne sont pas symboliques. Déployer un système IA interdit expose à des amendes pouvant atteindre 35 millions d'euros ou 7 % du chiffre d'affaires annuel mondial, le plus élevé des deux. La non-conformité sur les systèmes à haut risque atteint 15 millions d'euros ou 3 % du chiffre d'affaires. Le texte juridique compte 144 articles et 13 annexes, et chaque entreprise avec qui je parle a sous-estimé l'un de trois points — lesquels de ses systèmes sont réellement dans le périmètre, combien de documentation technique l'Annexe IV exige vraiment, ou combien de temps dure l'évaluation de conformité quand l'organisme notifié envoie sa première liste de demandes de clarification. Il s'agit de la phase GOVERN de la DEPLOY Method appliquée à la régulation IA la plus conséquente de notre décennie. Je suis Ambassadeur IA du Gouvernement Français pour la Transformation Numérique Finance et Entreprise, ce qui signifie que j'ai passé ces dernières années dans le volet politique de cette régulation précisément — pas en lisant les résumés, en lisant le texte, avec ceux qui l'ont écrit. C'est la perspective que cette mission apporte à votre programme de conformité.
Vous ne savez pas lesquels de vos systèmes sont dans le périmètre. L'AI Act définit des systèmes interdits, à haut risque, à risque limité et à risque minimal, et la classification dépend du cas d'usage — pas de la technologie. Un modèle de recommandation marketing est probablement à risque limité ; la même classe de modèle utilisée pour le scoring de crédit est à haut risque. Un système de catégorisation biométrique utilisé dans le retail peut être interdit purement et simplement. La plupart des organisations n'ont pas d'inventaire écrit de leurs systèmes IA indexé sur les classes de risque de l'AI Act, ce qui signifie que chaque question d'application commence par un travail de découverte qui aurait déjà dû être fait.
Votre planning d'évaluation de conformité est faux. Les équipes le cadrent comme un audit — quelques semaines de paperasse. En pratique, une évaluation de conformité Titre III pour un système à haut risque est une mission de plusieurs mois impliquant un organisme notifié, un système complet de gestion des risques, une documentation de gouvernance des données, une documentation technique selon l'Annexe IV, des plans de post-market monitoring, la conception de la supervision humaine et la remédiation de chaque écart relevé lors de la revue. La première soumission formelle est rarement la dernière. Des équipes qui avaient prévu huit semaines se retrouvent huit mois plus tard encore en train de négocier des remédiations.
La documentation technique Annexe IV est vraiment plus difficile qu'elle n'y paraît. Elle exige une description générale du système, une conception détaillée, la méthodologie d'entraînement, la gouvernance des données, les métriques d'évaluation, les limites connues, les mesures de gestion des risques, les mesures de supervision humaine, les spécifications de précision et le journal des changements. La plupart des documentations d'ingénierie internes ne survivent pas au contact de l'Annexe IV — elles répondent à d'autres questions, à un autre niveau de rigueur, pour un autre public. Réécrire au standard Annexe IV n'est pas un exercice de mise en forme. C'est un exercice de documentation d'ingénierie que votre équipe n'a jamais réalisé.
Le post-market monitoring est presque toujours l'écart. L'Act exige un plan de post-market monitoring écrit, un monitoring actif en production et la déclaration des incidents graves dans des délais serrés. La plupart des organisations ont une réponse aux incidents réactive, pas un programme de monitoring proactif spécifique à l'IA. Le premier incident grave après le début de l'application expose l'absence, et la réponse réglementaire est structurellement impitoyable envers les organisations qui n'ont pas planifié cela. Le post-market monitoring est la différence entre un programme conforme et un programme sur le papier.
Le périmètre de la mission dépend de la taille de votre empreinte IA et du nombre de systèmes à haut risque concernés. Douze semaines couvrent un seul système à haut risque ; vingt-quatre semaines couvrent un portefeuille de trois à cinq systèmes avec une infrastructure de gouvernance partagée. Je travaille embarqué avec vos équipes juridiques, conformité et ingénierie — vos équipes font le travail, j'apporte la lecture réglementaire et la reconnaissance de schémas côté politique.
Nous construisons un inventaire écrit de chaque système IA dans votre organisation — production, pilote, prototype — chacun étant classé contre les catégories de risque de l'AI Act. Interdit, à haut risque selon l'Annexe III, à risque limité avec obligations de transparence, ou à risque minimal. La classification est documentée avec le raisonnement et les références d'articles. Les systèmes déployés sans classification font l'objet d'une revue rétroactive. À la fin de la semaine quatre, vous disposez du document unique que toute décision de conformité ultérieure référencera.
Pour chaque système à haut risque, nous construisons les artefacts de conformité en parallèle : le système de gestion des risques, la documentation de gouvernance des données, la documentation technique Annexe IV, la conception de la supervision humaine, les spécifications de précision et de robustesse. C'est la phase la plus lourde et celle où la plupart des programmes sous-estiment l'effort. Je travaille avec vos équipes d'ingénierie pour réécrire la documentation interne au standard Annexe IV, pas pour l'inventer à partir de rien. Pour les systèmes nécessitant un organisme notifié, nous préparons le paquet de soumission et le playbook de réponse aux clarifications qui suivront.
Nous mettons en place le programme de post-market monitoring — le plan écrit, le monitoring actif en production, les critères de classification des incidents, les workflows de reporting avec la conformité de délais que la régulation exige. Le monitoring s'intègre à la stack d'observabilité que vous avez déjà, étendue pour capturer les signaux spécifiques à l'IA qui comptent : dérive de précision, dérive de performance démographique, monitoring d'impact défavorable, signaux de préjudice utilisateur. Les runbooks de réponse aux incidents sont écrits pour coller aux délais de notification de la régulation, pas improvisés quand le premier incident arrive.
Nous construisons l'infrastructure de gouvernance pour le long terme — la charte du comité de gouvernance IA, le processus d'entrée pour les nouveaux systèmes IA, le cycle de revue récurrent, le programme de formation pour le personnel interagissant avec les systèmes à haut risque, l'approche de gestion des fournisseurs pour les composants IA tiers. Le programme doit tourner sans moi une fois la mission terminée. Je produis les playbooks, les templates et le journal des décisions pour que votre prochain système à haut risque passe par un processus reproductible plutôt que de répéter le travail de découverte de la semaine un.
Entreprises opérant dans l'UE ou vers l'UE avec des systèmes IA à haut risque tels que définis par l'Annexe III — scoring de crédit, emploi, éducation, services essentiels, maintien de l'ordre, migration, administration de la justice et les autres catégories que la régulation nomme spécifiquement. Organisations avec une empreinte IA suffisamment large pour que la seule classification soit un exercice de découverte de plusieurs semaines. Acheteurs et déployeurs du secteur public qui seront scrutés par leurs propres organes de supervision en plus du régulateur. Ce n'est pas pour les organisations dont l'usage IA est entièrement hors du périmètre Annexe III — une obligation de transparence à risque limité est une mission bien plus petite qu'une évaluation de conformité complète. Ce n'est pas non plus un substitut au conseil juridique externe sur la stratégie réglementaire ; je fabrique le programme de conformité, et votre direction juridique ou votre cabinet externe gère le positionnement juridique.
Votre cabinet d'avocats vous dit ce que la régulation exige ; moi, je construis le programme qui la met en œuvre. Ce sont des rôles complémentaires, pas concurrents. La plupart des organisations constatent que le conseil juridique est clair et que l'écart d'implémentation est énorme — le cabinet d'avocats ne peut pas écrire votre documentation technique Annexe IV, concevoir vos contrôles de supervision humaine ou mettre en place votre pipeline de post-market monitoring. C'est de l'ingénierie et de la gestion de programme, ce que cette mission livre. Je travaille aux côtés du conseil externe ; il porte la stratégie juridique, je porte le programme opérationnel.
Le calendrier d'application échelonné est légiféré. Les interdictions sont applicables depuis février 2025, les règles sur l'IA à usage général depuis août 2025, et les obligations à haut risque arrivent en août 2026 avec les dispositions restantes qui suivent en 2027. Les guidances spécifiques des organismes notifiés et de l'European AI Office continuent d'évoluer, ce qui affecte les détails de la démonstration de conformité — pas son exigence. Tout programme cadré sur l'échéance 2026 à haut risque doit être en implémentation maintenant, pas en planification, car les délais d'évaluation de conformité eux-mêmes se comptent en mois dès qu'un organisme notifié est impliqué.
Documentez le raisonnement de classification au moment où la décision est prise, en vous appuyant sur les références d'articles, et soyez prêts à le défendre. Une classification à risque limité défendable avec un argumentaire écrit est une posture bien plus forte qu'un système classé informellement ou pas du tout. Là où la classification est vraiment ambiguë, nous classons de manière conservatrice — le coût de préparer un système à haut risque qui s'avère à risque limité est faible ; le coût de déployer une classification à risque limité sur un système qui est à haut risque est les sanctions citées dans le sous-titre. Je rends cet arbitrage explicite dans le document d'inventaire, pas caché dans un tableur.
Si le produit de votre système IA est utilisé dans l'UE, oui, la régulation s'applique à vous en tant que fournisseur ou déployeur quel que soit votre lieu d'incorporation. Cela attrape la plupart des entreprises SaaS américaines avec clients européens, ce qui est souvent une découverte malvenue. La réponse pratique est de cadrer le programme sur les systèmes ayant une exposition UE et de mener le travail de conformité contre ceux-ci — ce qui peut représenter une empreinte plus petite que votre portefeuille IA complet, ce qui réduit souvent considérablement le délai et le coût par rapport à un déploiement de programme complet.
Le RGPD couvre le traitement des données personnelles ; l'AI Act couvre la sûreté, la transparence et la gestion des risques des systèmes IA. Ils se chevauchent dans la section gouvernance des données — votre documentation de gouvernance des données AI Act référencera et étendra vos AIPD RGPD là où des données personnelles sont impliquées. En pratique, les deux programmes devraient partager le même inventaire de données et le même comité de gouvernance, car les mêmes systèmes d'ingénierie sont dans le périmètre des deux régulations. Un programme de conformité qui fait tourner RGPD et AI Act en silos parallèles duplique le travail et produit des incohérences que les auditeurs remarquent.
Decouvrez d'autres services qui completent cette offre
30 minutes. Je diagnostique votre situation, je vous dis honnêtement si ce service convient — et sinon, lequel conviendrait.