L’AI Act européen est entré en vigueur en août 2024, et ses obligations tombent par vagues depuis : pratiques interdites en février 2025, obligations des modèles à usage général en août 2025, et l’essentiel du régime « haut risque » en août 2026. La plupart des analyses se concentrent sur les niveaux de risque. Pour ceux qui opèrent des plateformes data, la question utile est ailleurs : quand les obligations s’appliqueront, que devrez-vous prouver, et votre plateforme sait-elle produire cette preuve ?
L’AI Act est un règlement de la preuve
Ramenez les 113 articles à ce qui touche une plateforme data, et il reste trois devoirs :
1. Gouvernance des données (article 10). Les systèmes à haut risque doivent être entraînés sur des jeux de données soumis à une gouvernance documentée : pertinence, représentativité, traitement des erreurs, examen des biais possibles. On ne documente pas un jeu de données qu’on ne sait pas tracer. En pratique, l’article 10 est une exigence de lineage : quelles sources ont alimenté quel jeu d’entraînement, transformées par quel code, quand.
2. Journalisation (article 12). Les systèmes à haut risque doivent journaliser automatiquement les événements sur tout leur cycle de vie, de façon à permettre la traçabilité. Cela couvre l’entraînement comme l’inférence. « On pourrait le reconstituer à partir des tickets » ne survivra pas à une évaluation de conformité.
3. Documentation technique (article 11 et annexe IV). Les fournisseurs doivent maintenir une documentation décrivant le système, ses données, son entraînement, son évaluation et ses limites, tenue à jour. La façon la moins coûteuse de tenir une documentation à jour est de la générer depuis des systèmes de référence, plutôt que de l’écrire après coup.
Concrètement
Projetez ces devoirs sur des capacités de plateforme et la liste de courses s’écrit toute seule :
| Devoir AI Act | Capacité de plateforme |
|---|---|
| Tracer les données d’entraînement (art. 10) | Lineage automatique des tables sources jusqu’aux runs d’entraînement |
| Journaliser le cycle de vie (art. 12) | Piste d’audit couvrant entraînement et inférence, exportable |
| Documenter le système (art. 11) | Tracking des expérimentations, registre de modèles versionné |
| Démontrer exactitude et robustesse (art. 15) | Historique des métriques par run, évaluations reproductibles |
| Tenir la preuve à disposition des autorités | Artefacts et logs sur un stockage que vous contrôlez, avec rétention |
Remarquez ce qui est absent de ce tableau : rien n’impose un éditeur, un modèle ou un cloud particulier. L’AI Act réglemente la traçabilité, et la traçabilité est une propriété d’architecture.
L’angle juridiction
Il y a une seconde implication, plus discrète. La base de preuve exigée par l’AI Act, données d’entraînement, logs, artefacts de modèles, est elle-même sensible : elle décrit vos modèles, vos données et vos décisions. Garder cette preuve sur une infrastructure soumise à une juridiction non européenne crée exactement la dépendance contre laquelle les régulateurs européens mettent en garde. La preuve d’un règlement européen se défend mieux sur une infrastructure européenne, sous vos propres clés.
Comment Polnor s’y projette
Polnor enregistre automatiquement le lineage au niveau colonne depuis chaque requête, job et notebook : la piste de l’article 10 existe sans que personne ne la maintienne. Chaque run d’entraînement journalise paramètres, métriques et artefacts via un tracker compatible MLflow, et les modèles passent par un registre versionné relié aux endpoints qui les servent. Le journal d’audit couvre l’entraînement et l’inférence et s’exporte toutes les heures vers votre propre S3, dans votre région européenne. Le jour de l’évaluation de conformité, la documentation est une série de requêtes, pas un trimestre d’archéologie.
Si août 2026 figure dans votre registre des risques, demandez une démo : nous passerons la checklist de preuve en revue face à votre stack actuelle.