Si votre produit relève de l'article 50 de l'EU AI Act, un filigrane lisible par machine ne suffit pas. Les fournisseurs et les déployeurs ont des obligations différentes. Certaines obligations des déployeurs exigent encore un label clair qu'une personne puisse remarquer sans outils particuliers. La règle s'applique à partir du 2 août 2026. La période de grâce limitée jusqu'au 2 décembre 2026 couvre uniquement l'obligation de marquage prévue à l'article 50(2) pour les systèmes mis sur le marché avant le 2 août. La FAQ officielle de la Commission et les pages de recommandations le précisent désormais directement. FAQ de la Commission européenne Page des recommandations
Cet article est une checklist d'ingénierie, et non un avis juridique. L'objectif est plus restreint : transformer le champ d'application, les dates, les exceptions et les seuils de contrôle officiels en contrôles produit que vous pouvez réellement déployer. Cette checklist se concentre sur les articles 50(1), 50(2) et les obligations relatives aux contenus génératifs de l'article 50(4). Elle ne couvre pas les obligations distinctes de l'article 50(3) concernant les systèmes de reconnaissance des émotions et de catégorisation biométrique. Confirmez le rôle, le champ d'application et toute exception avec un conseil qualifié avant de vous appuyer sur ce workflow.
EU AI Act Article 50 : qui doit faire quoi ?
Les recommandations actuelles de la Commission répartissent le travail selon l'acteur concerné. Les fournisseurs gèrent les notifications d'interaction directe avec l'AI et le marquage lisible par machine des sorties synthétiques. Les déployeurs gèrent les labels relatifs aux deepfakes et certains labels pour les textes d'intérêt public. Page des recommandations Informations essentielles
| Acteur | Déclencheur | Ce que disent les recommandations officielles |
|---|---|---|
| --- | --- | --- |
| Fournisseur | Interaction directe avec une personne physique | Informer la personne dès la première interaction, sauf s'il est évident qu'elle interagit avec une AI. |
| Fournisseur | Sortie synthétique sous forme de texte, d'image, d'audio ou de vidéo | Ajouter un marquage lisible par machine et permettre la détectabilité, sous réserve des limites de champ d'application et des exceptions. |
| Déployeur | Exposition à un deepfake | Fournir une information claire et perceptible au plus tard lors de la première exposition. |
| Déployeur | Texte d'intérêt public sans contrôle humain ni contrôle éditorial | Étiqueter clairement le texte comme généré ou manipulé par AI. |
Cette distinction est importante, car elle élimine un raccourci courant : un marquage masqué du fournisseur ne satisfait pas automatiquement l'obligation d'information visible du déployeur. La Commission indique que les déployeurs ne peuvent pas se fier uniquement au marquage lisible par machine intégré par le fournisseur. FAQ de la Commission européenne
Les dates importantes
Les obligations principales de l'article 50 s'appliquent à partir du 2 août 2026. La FAQ de la Commission ajoute une période de grâce limitée pour l'obligation de marquage de l'article 50(2) jusqu'au 2 décembre 2026, mais uniquement pour les systèmes d'AI générative mis sur le marché avant le 2 août 2026. Les contenus générés avant le 2 août ne nécessitent pas d'étiquetage rétroactif, même si la Commission l'encourage lorsque cela est possible. FAQ de la Commission européenne Informations essentielles
La loi fixe deux dates pertinentes. Votre plan de déploiement peut en ajouter une troisième, correspondant à une politique interne :
Ce que les fournisseurs doivent construire
Pour les fournisseurs, la règle relative à l'interaction directe est la plus simple. Si le système constitue une véritable interaction bidirectionnelle avec une personne physique et que cette interaction n'est pas manifestement une interaction avec une AI, la personne doit être informée dès le début de la première interaction. La Commission indique que l'exception liée au caractère « évident » doit être interprétée de manière restrictive. FAQ de la Commission européenne
La partie la plus difficile concerne le marquage des sorties. Les fournisseurs de systèmes qui génèrent du texte, des images, de l'audio ou des vidéos synthétiques doivent appliquer des marquages lisibles par machine et permettre leur détectabilité. La même FAQ indique également que certaines sorties sont hors champ ou exemptées, notamment le code source, certaines sorties de machine à machine sans exposition humaine et certains usages industriels ou de développement de produits en boucle fermée. FAQ de la Commission européenne
C'est généralement à ce stade que les équipes simplifient excessivement le travail. Ce qui suit est une interprétation de mise en œuvre, et non une checklist reproduisant mot pour mot celle de la Commission. Une obligation du fournisseur ne consiste pas à « activer le filigranage ». Elle consiste à :
Si vous suivez déjà les fournisseurs, les runtimes et les routes de sortie dans un inventaire des composants AI→, étendez cet inventaire avec la couverture du marquage par sortie et les résultats de vérification. Si ce n'est pas le cas, il sera beaucoup plus difficile de démontrer votre conformité à l'article 50 par la suite.
Ce que les déployeurs doivent encore faire
Les déployeurs font face à un problème différent. Leurs obligations sont visibles, contextuelles et fondées sur l'exposition. Un marquage masqué dans un fichier ne suffit pas lorsqu'une personne regarde ou lit le résultat.
Pour les deepfakes, la Commission indique que l'information doit être fournie au plus tard lors de la première exposition et être compréhensible sans outils particuliers. Pour les textes d'intérêt public, le déployeur doit étiqueter le contenu, sauf s'il a fait l'objet d'un véritable contrôle humain ou éditorial. La Commission précise que la vérification orthographique et la correction grammaticale ne comptent pas. FAQ de la Commission européenne
C'est ici que la conception du workflow compte davantage que la technologie de détection :
La question du déployeur n'est pas « L'AI est-elle intervenue ? » La question est : « Qu'avons-nous exposé aux personnes, et de quelles preuves de contrôle disposons-nous pour cet actif précis ? »
*Légende : l'article 50 distingue les obligations des fournisseurs et des déployeurs. Le marquage lisible par machine et le label visible répondent à des problèmes différents.*
Pourquoi le filigranage seul ne suffit pas
La documentation actuelle des fournisseurs montre déjà pourquoi une solution à une seule couche est fragile.
OpenAI indique que les métadonnées C2PA aident les contenus à conserver des informations de provenance. OpenAI précise également que les métadonnées peuvent être supprimées, perdues lors du téléversement ou du téléchargement, ou détériorées par des transformations telles que le redimensionnement et les captures d'écran. Au 29 juillet 2026, la documentation d'OpenAI décrit une deuxième couche via SynthID pour les images prises en charge ainsi qu'un aperçu public de vérification. Provenance OpenAI Vérification OpenAI
La documentation publique de Google sur le texte SynthID souligne le même point sous un autre angle. Elle décrit le fonctionnement du filigranage du texte, mais indique également que la confiance du détecteur peut chuter fortement après une réécriture approfondie ou une traduction. Cette limite est importante pour l'article 50, car les obligations des déployeurs incluent les textes d'intérêt public, pour lesquels le texte édité est normal plutôt qu'exceptionnel. Documentation SynthID Text
ElevenLabs présente désormais SynthID et C2PA comme faisant partie de sa pile de transparence audio et indique avoir commencé par déployer le filigrane sur les générations text-to-speech gratuites avant d'étendre la couverture. Il s'agit d'un élément utile pour la mise en œuvre, mais cela reste un état de déploiement déclaré par le fournisseur, et non la preuve que chaque plateforme en aval préservera le signal. Article d'ElevenLabs sur SynthID
Les recherches récentes aboutissent à la même conclusion. L'article sur les lacunes structurelles de l'article 50 soutient que la conformité ne peut pas être réduite à un étiquetage a posteriori. L'article sur le framework de provenance soutient que les métadonnées de provenance et le filigranage répondent à des problèmes de preuve différents. L'article sur l'attribution à facettes soutient que les informations générales du type « l'AI a été utilisée » ne précisent pas où, comment et sous quel contrôle le système est intervenu. L'interprétation pratique pour l'ingénierie est plus restreinte : la conformité à l'article 50 nécessite des preuves de workflow en plus du marquage technique. Article sur les lacunes structurelles Framework de provenance Article sur l'attribution à facettes
Une checklist d'ingénierie pratique
1. Inventoriez chaque chemin de sortie public
Répertoriez chaque système capable de produire du texte, des images, de l'audio ou des vidéos destinés au public. Ne vous arrêtez pas au nom du modèle. Incluez la surface qui distribue la sortie, l'acteur qui contrôle la publication et indiquez si la sortie atteint une personne physique. La distinction entre fournisseur et déployeur établie par la Commission s'applique au niveau du système et de l'exposition, et non au niveau de la marque du modèle. FAQ de la Commission européenne
Champs minimaux :
2. Séparez les obligations du fournisseur de celles du déployeur dans le code
N'ajoutez pas un indicateur générique `ai_disclosure=true` à l'actif en considérant que le travail est terminé. Vous avez besoin de contrôles distincts :
Cette séparation vous permet de démontrer pourquoi un fichier marqué nécessitait encore un label visible, ou pourquoi un actif textuel d'intérêt public était exempté parce qu'un contrôleur qualifié avait effectué une validation substantielle.
3. Définissez un véritable seuil de contrôle humain
La Commission indique qu'un contrôle substantiel exige des connaissances pertinentes et un jugement professionnel, et que le contrôle éditorial signifie qu'une entité responsable peut approuver, modifier ou rejeter le fond du texte. La vérification orthographique est explicitement exclue. FAQ de la Commission européenne
Si votre étape de contrôle dans le CMS ne peut pas répondre aux questions suivantes :
alors les preuves justifiant le recours à l'exception de contrôle sont incomplètes.
4. Testez la résistance aux transformations, et pas seulement la réussite de la génération
Pour les marquages lisibles par machine, la question d'ingénierie n'est pas seulement « pouvons-nous l'intégrer ? » C'est aussi « survit-il au parcours réel de l'actif ? »
Testez au minimum :
OpenAI, Google et ElevenLabs décrivent tous la robustesse, mais aucun ne revendique un signal parfait après chaque transformation. Provenance OpenAI Présentation de SynthID Article d'ElevenLabs sur SynthID
5. Conservez un parcours de vérification que les opérateurs peuvent réellement exécuter
La pile open source C2PA est suffisamment active pour être utilisée dès aujourd'hui dans des workflows réels. Le programme de conformité et la liste de confiance de C2PA sont actifs, `c2patool` peut inspecter ou ajouter des manifests, et la série de versions de `c2pa-rs` continue d'évoluer en juillet 2026. Conformité C2PA Documentation de c2patool Versions de c2pa-rs
Cela vous fournit un parcours opérateur simple :
6. Traitez les exceptions comme une politique explicite, et non comme une mémoire collective
Les recommandations de la Commission décrivent plusieurs exclusions et exceptions dépendant des conditions. Elles mentionnent le code source, les sorties destinées exclusivement au traitement de machine à machine sans exposition humaine et certaines sorties industrielles ou de développement de produits en boucle fermée comme étant hors champ dans les circonstances décrites. Elles distinguent également l'édition standard d'assistance, le contrôle substantiel des textes d'intérêt public et certains deepfakes manifestement artistiques, créatifs, satiriques, fictifs ou analogues. Il ne s'agit pas d'exemptions générales ; documentez pourquoi un chemin de sortie précis satisfait aux conditions pertinentes. FAQ de la Commission européenne
Si ces exceptions ne vivent que dans la mémoire des personnes, elles dériveront. Inscrivez-les dans un arbre de décision, un tableau de politique ou une checklist de mise en production, et reliez chaque exception au chemin de contenu où elle est autorisée.
Où les outils actuels sont déjà utiles
OpenAI, Google et ElevenLabs fournissent désormais aux équipes de véritables briques de construction, mais chacune a ses limites.
OpenAI
Au 29 juillet 2026, OpenAI indique être un C2PA Conforming Generator Product, appliquer SynthID aux images prises en charge générées via ChatGPT, Codex et l'API, et proposer un vérificateur en aperçu de recherche pour les images générées par OpenAI. OpenAI précise également qu'aucune méthode de détection n'est infaillible et qu'un signal absent ne prouve pas que l'image n'a pas été générée par AI. Provenance OpenAI Vérification OpenAI
Google présente SynthID comme un système de filigranage multimédia pour les images, l'audio, le texte et la vidéo. Sa documentation textuelle est particulièrement concrète : le filigranage est implémenté comme un processeur de logits, mais la traduction et la réécriture approfondie peuvent affaiblir la détection. C'est utile, car cela indique ce qu'il ne faut pas promettre excessivement. Présentation de SynthID Documentation SynthID Text
ElevenLabs
Au 29 juillet 2026, ElevenLabs indique que son détecteur audio recherche d'abord un filigrane SynthID, puis utilise son AI Speech Classifier lorsqu'aucun filigrane n'est trouvé. Il s'agit conceptuellement du bon modèle : d'abord le signal de provenance, puis un signal d'inférence plus faible. Documentation d'ElevenLabs Audio Detector
C2PA et la vérification open source
C2PA reste le standard ouvert le plus pratique pour les métadonnées de provenance. La spécification officielle, le programme de conformité et les outils en ligne de commande suffisent pour prendre en charge des étapes de validation dans un pipeline de production. Accueil C2PA Spécification C2PA Documentation de c2patool
Ce qu'il ne faut pas supposer
Ne supposez pas les éléments suivants :
Ce sont les modes de défaillance qui créent une fausse confiance dans la conformité.
Conclusion
Une lecture d'ingénierie concise de l'article 50 de l'EU AI Act est la suivante : les fournisseurs doivent rendre les sorties synthétiques détectables, et les déployeurs peuvent encore devoir les rendre évidentes pour les personnes.
C'est pourquoi la bonne mise en œuvre est une chaîne, et non un badge :
Si vous le construisez de cette manière, l'article 50 devient une surface de contrôle d'ingénierie. Si vous le réduisez à « nous avons ajouté un filigrane », vous risquez de manquer une obligation distincte du déployeur. Cette architecture peut contribuer à fournir des preuves de conformité, mais elle ne détermine pas le champ d'application juridique et ne garantit pas la conformité.
FAQ
Le marquage lisible par machine d'un fournisseur satisfait-il l'obligation du déployeur d'étiqueter un deepfake ?
Non. La FAQ de la Commission indique que les déployeurs ne peuvent pas se fier uniquement au marquage lisible par machine du fournisseur. Les deepfakes nécessitent toujours une information claire et perceptible destinée à la personne exposée. FAQ de la Commission européenne
Quand le contrôle humain dispense-t-il un texte d'intérêt public d'un étiquetage ?
Uniquement lorsqu'une personne physique examine délibérément le fond du contenu avec les connaissances pertinentes, ou lorsqu'une entité éditoriale peut approuver, modifier ou rejeter le texte pour des motifs substantiels. Les contrôles formels tels que la vérification orthographique ou la correction grammaticale ne sont pas suffisants. FAQ de la Commission européenne
Le code source et les sorties de machine à machine relèvent-ils de l'article 50(2) ?
Pas toujours. La FAQ de la Commission mentionne le code source, certaines sorties de machine à machine sans exposition humaine et certains usages industriels en boucle fermée comme étant hors champ ou exemptés, sous certaines conditions. FAQ de la Commission européenne