Le piège classique
Le considérant 128 pose une règle silencieuse mais redoutable : toute modification de votre système d'IA a haut risque (changement d'OS, refonte d'architecture, nouveau finalité metier) déclenche une nouvelle évaluation de conformité complète. En pratique, les équipes produit deploient des updates majeurs sans réaliser qu'elles viennent de créer juridiquement un nouveau système. L'EU AI Office et les futures autorités de surveillance du marché s'appuieront sur ce considérant pour requalifier des deploiements continus en mise sur le marché non conforme. La CNPD, cote données personnelles, sanctionnera en parallele tout traitement reposant sur un système dont la base de conformité n'est plus valide.
Ce qui déclenche (ou non) une nouvelle évaluation de conformité
Le considérant 128 distingue deux catégories de changements. Comprendre la frontière est la clé pour ne pas geler vos cycles de release ni, a l'inverse, deployer en violation du AI Act.
- Déclenche une nouvelle évaluation : changement de système d'exploitation, refonte de l'architecture logicielle, modification de la destination (passage d'un usage RH a un usage crédit scoring), ajout de nouvelles données d'entrainement non prévues, intégration d'un nouveau modèle de fondation sous-jacent.
- Ne déclenche PAS de nouvelle évaluation : apprentissage continu et adaptation automatique des fonctions, a la stricte condition que ces évolutions aient ete predeterminees et evaluees dans le dossier de conformité initial (article 43(4) et annexe IV).
- La zone grise dangereuse : un fine-tuning supplémentaire, un changement de hyperparametres significatif, une expansion du périmètre géographique d'usage. La doctrine penche vers la requalification en modification substantielle.
- L'erreur classique : ne rien documenter du change envelope initial, ce qui rend chaque mise à jour potentiellement requalifiable.
Comment Luxgap automatise ce risque
Notre Luxgap AI Change Sentinel rend impossible le deploiement silencieux d'une modification substantielle non declaree. L'outil se branche directement sur vos pipelines MLOps (MLflow, Azure ML, AWS SageMaker, Vertex AI, GitHub Actions, GitLab CI) et compare en continu chaque release candidate au dossier de conformité article 43 initial pour determiner, avant le merge en production, si le changement franchit le seuil du considérant 128.
- Detecte automatiquement chaque modification de l'OS hôte, de l'architecture conteneur, du modèle de fondation sous-jacent ou des hyperparametres critiques via hooks Git et scan d'image Docker.
- Compare le change envelope propose au périmètre predetermine declare dans votre dossier annexe IV et alerte sur Teams ou Slack des qu'un drift depasse les bornes evaluees.
- Classifie chaque changement selon la grille du considérant 128 (substantielle, pre-evaluee, zone grise) avec justification réglementaire opposable a l'EU AI Office.
- Bloque automatiquement le pipeline CI/CD si la modification est qualifiée de substantielle et qu'aucune nouvelle évaluation de conformité n'a ete lancee.
- Genere le dossier de re-evaluation pre-rempli, integrant les diffs techniques, l'impact sur la gestion des risques article 9 et les ajustements de transparence article 13.
- Produit un rapport PDF horodate, cryptographiquement scelle, demontrant que chaque release a fait l'objet d'une analyse de qualification, opposable lors d'un contrôle.
Disponible en complement d'un mandat DPO ou CISO Luxgap ou en brique SaaS dediee selon votre périmètre. Demandez un devis personnalise et nos équipes preparent une demonstration sur vos pipelines reels, avec un audit blanc gratuit sous 48h pour mesurer combien de vos dernières releases auraient du déclencher une nouvelle évaluation de conformité.
