La provenance est désormais une spécification : l’EU AI Act et les données des robots
Sous l’EU AI Act, la provenance est une spécification d’ingénierie que vous intégrez au pipeline de capture, non des formalités greffées après coup. C’est la journalisation dès la capture qui l’emporte.
Une équipe de robotique veut acheter 500 heures de données de manipulation. Le contrat d’achat atterrit sur le bureau d’un ingénieur avec une clause qui n’existait pas il y a un an. Pour chaque clip, le vendeur doit fournir les enregistrements de consentement, la calibration des capteurs et une chaîne de possession ininterrompue, de la capture à la livraison. Le vendeur possède les images. Le vendeur n’a pas le journal. Le prix baisse.
C’est ce que l’EU AI Act fait aux données d’entraînement, et la plupart des équipes y voient encore un problème juridique alors qu’il s’agit d’un problème d’ingénierie. Le Règlement (UE) 2024/1689 ne vous demande pas de remplir des formalités après coup. Il vous demande de prouver d’où proviennent vos données. La preuve est quelque chose que vous avez consigné pendant que le capteur fonctionnait, ou que vous n’avez pas.
Cette distinction, c’est tout le propos de ce billet. La provenance ne survit pas à une reconstruction. Vous pouvez estimer une pose de la main à partir des pixels. Vous ne pouvez pas estimer si la personne dans le cadre a consenti, quelle était la calibration de la caméra de profondeur cet après-midi-là, ou quel annotateur a annoté quel clip selon quelle consigne. Ces faits n’existent que l’espace d’un instant, au moment de la capture, puis ils disparaissent, à moins que quelque chose ne les ait consignés.
La provenance que vous n’avez pas enregistrée est perdue
Les modèles de texte ont eu de la chance. Internet constitue sa propre piste d’audit : une page a une URL, un horodatage, un auteur et une licence sur laquelle vous pouvez au moins argumenter. Les données robotiques égocentriques n’ont aucun de ces résidus. Une personne enfile un rig de capture, exécute une tâche une fois, et l’instant passe. Si le rig n’a pas enregistré qui a consenti, à quel moment chaque image a été prise et comment les capteurs étaient réglés, ce contexte est irrécupérable. Personne ne peut le reconstituer à partir de la seule vidéo.
Le consentement en est l’exemple le plus tranchant. L’enregistrement des mains, du domicile et du visage d’une personne constitue une donnée personnelle, et l’European Data Protection Board le considère comme tel quoi que vous en fassiez ensuite à l’entraînement. Si vous n’avez pas capturé un enregistrement de consentement rattaché à cette personne et à cette session, vous ne pourrez pas en fabriquer un après coup. Une fois les visages floutés et les données brutes supprimées, vous avez aussi supprimé votre capacité à prouver que l’enregistrement était licite. Le jeu de données anonymisé, à l’apparence irréprochable, est celui que vous ne pouvez plus défendre.
La même logique parcourt chaque champ de provenance. La calibration dérive au cours d’une session, et elle est soit mesurée, soit devinée plus tard. Les canaux sont horodatés sur une horloge commune au moment de la capture, ou bien réalignés à la main avec des décalages que vous ne récupérerez jamais complètement. Chaque annotation porte l’annotateur, la version de la consigne et l’heure, ou bien c’est un fichier d’annotations plat, sans aucune mémoire de la façon dont il a été produit. Dans tous les cas, l’enregistrement honnête ne coûte presque rien au moment de la capture et ne peut s’acheter à aucun prix par la suite.
L’Article 10 transforme la qualité des données en un processus documenté
Lisez la formulation même du règlement à propos des systèmes à haut risque, et l’Article 10 cesse de sonner comme de la conformité pour se lire comme une spécification de pipeline de données. Il exige que les jeux de données d’entraînement, de validation et de test qui sous-tendent un tel système soient produits selon des pratiques de gouvernance des données couvrant le processus de collecte, l’origine des données, ainsi que les procédures d’annotation et d’étiquetage. En clair, il veut un compte rendu documenté de la façon dont les données ont été produites, pas seulement de ce qu’elles contiennent.
Pour un jeu de données robotique, cela se traduit en décisions de conception concrètes. L’origine des données, c’est une chaîne de possession. Le processus de collecte, ce sont des conditions de capture journalisées. Les procédures d’annotation, ce sont des consignes d’étiquetage versionnées et un relevé de qui les a appliquées. Rien de tout cela n’est exotique pour une équipe qui traite déjà les données comme un artefact d’ingénierie. Le règlement rend simplement cet artefact non optionnel et sa documentation inspectable.
Une provenance que vous pouvez reconstruire n’a jamais vraiment été de la provenance. C’est une histoire que vous racontez après coup. Le règlement réclame l’enregistrement que vous avez conservé pendant que le capteur fonctionnait encore.
L’explication en langage clair du Parlement européen est sans détour sur la direction prise : les systèmes à haut risque sont soumis à des obligations de documentation et de traçabilité, et l’application entre en vigueur par étapes sur 2026 et 2027 plutôt que d’un seul coup. Les dates d’application exactes ont bougé au cours de la mise en œuvre, aussi faut-il voir le calendrier comme une pente, non comme une falaise unique. La lecture pratique, elle, ne change pas : les données que vous capturez en 2026 sont des données que vous pourriez devoir documenter en 2027.
Capturé à la source ou greffé après coup
L’écart entre les deux façons d’obtenir la provenance n’est pas une question d’effort. C’est une question de ce qui reste connaissable. Le tableau ci-dessous prend six champs qu’un acheteur exigera et montre ce que chacun devient lorsque vous essayez de l’ajouter après la capture plutôt qu’au niveau du capteur.
| Champ | Capturé à la source | Greffé après coup |
|---|---|---|
| Consentement | Enregistré par sujet, relié à chaque clip où il apparaît | Impossible à obtenir une fois les sujets partis ou les visages anonymisés |
| Identité et anonymisation | Floutage et pseudonymisation appliqués selon une politique, avec une clé réversible conservée sous séquestre | Un floutage tardif perd la correspondance, si bien que les demandes de suppression ne peuvent être honorées |
| Calibration des capteurs | Paramètres intrinsèques et extrinsèques journalisés à chaque session | Estimée à partir des images, approximative, dérive non documentée |
| Synchronisation temporelle | Tous les canaux horodatés sur une même horloge au moment de la capture | Réalignés à la main, décalages inférieurs à l’image irrécupérables |
| Traçabilité des annotations | Chaque annotation porte l’annotateur, la version de la consigne et l’heure | Un fichier d’annotations plat, sans trace de qui, quand, ni selon quel barème |
| Licence et droits d’usage | Conditions fixées au moment de la capture, par sujet et par scène | Reconstituées de mémoire et à partir d’e-mails, avec des lacunes qui deviennent un risque juridique |
Lisez la colonne de droite comme la liste de ce qu’un processus de diligence mettra au jour. Chaque lacune est une décote, et certaines lacunes sont rédhibitoires. Un jeu de données incapable de prouver le consentement n’est pas bon marché, il est inutilisable pour un système destiné au marché de l’UE.
La provenance devient un poste dans les achats
Voici le tournant commercial que les ingénieurs sous-estiment. Lorsqu’un OEM de robots achète des données d’entraînement pour un système qu’il compte vendre en Europe, il hérite de votre provenance. Son propre dossier Article 10 ne vaut que ce que vaut le manifeste que vous lui remettez. Aussi le conseil juridique de l’acheteur se met-il à réclamer ce manifeste avant de signer, de la même façon qu’un acheteur de puces réclame une fiche technique.
Le manifeste est un livrable concret, pas une impression. Pour chaque clip, il répond : qui a consenti et selon quelles conditions, comment les données brutes ont été anonymisées et si elles peuvent être supprimées sur demande, comment les capteurs ont été calibrés, comment les canaux ont été synchronisés, qui a annoté quoi selon quelle consigne, et quelle licence régit l’usage en aval. Un jeu de données livré avec ce document se vend avec une prime. Un jeu de données qui en est dépourvu est un passif que l’acheteur doit intégrer au prix, ou bien passer son chemin.
La couverture sectorielle de médias comme The Robot Report suit déjà le passage des humanoïdes des démonstrations de laboratoire vers les pilotes commerciaux. À mesure que ces systèmes approchent du marché de l’UE, la diligence sur leurs données d’entraînement se resserre d’autant. Le jeu de données qui l’emporte n’est pas le plus grand. C’est celui dont un avocat peut valider la provenance en un après-midi.
Une spécification définie à la capture, comme la fréquence d’images
Aucune équipe sérieuse ne décide de la fréquence d’images après l’enregistrement. Vous la fixez avant d’appuyer sur enregistrer, parce que vous ne pouvez pas ajouter des images qui n’ont jamais été capturées. La provenance relève désormais de la même catégorie. La capture du consentement, la journalisation de la calibration, la synchronisation temporelle et la traçabilité des annotations sont des paramètres de la session de capture, fixés au moment de la conception, non des fonctionnalités que vous saupoudrez au moment du nettoyage.
Le GDPR renforce ce point de l’autre côté. Parce que les images égocentriques regorgent de données personnelles, la base légale et les limites de conservation s’appliquent dès la première image, et l’AI Act laisse explicitement ces obligations intactes. Un pipeline qui journalise le consentement et la provenance sous forme de métadonnées structurées a déjà parcouru l’essentiel du chemin pour satisfaire les deux régimes à la fois. Un pipeline qui les repousse accumule une dette qui se capitalise le jour où un auditeur ou un acheteur se présente.
Ainsi, la manière utile d’entendre l’EU AI Act n’est pas celle d’un règlement à endurer, mais celle d’une spécification à laquelle se conformer. Il dit, en substance, qu’un jeu de données ne vaut que ce que vaut l’enregistrement de la façon dont il a été produit. Cet enregistrement doit être écrit au seul moment où il peut l’être : pendant que le capteur fonctionne encore. La provenance n’est pas une formalité que vous joignez après coup. C’est une spécification définie à la capture, et les équipes qui la traitent ainsi seront celles à qui il restera des données à vendre.