Modèles ouverts, usage interne et provenance : qui doit marquer les contenus générés ?

Depuis le 2 août 2026, l'article 50 de l'AI Act impose de rendre les contenus générés par une IA détectables comme artificiels. L'obligation suppose que quelqu'un contrôle la génération. Or c'est exactement ce contrôle qui change de mains dès que le modèle tourne sur les serveurs de celui qui l'utilise.

D'où la question que soulève cette architecture : un modèle exécuté localement échappe au contrôle technique de son fournisseur d'origine, mais ses productions échappent-elles aussi à l'obligation de marquage ?

Pas nécessairement. L'AI Act ne raisonne pas seulement en fonction du modèle utilisé ou de son lieu d'exécution. Il faut distinguer trois éléments : le rôle juridique de l'organisation, la nature du système qu'elle exploite et la destination réelle de ses sorties.

Le marquage se joue pendant la génération

Un watermark textuel comme celui présenté par Anthropic n'est pas ajouté au document une fois celui-ci terminé. Il intervient pendant la génération, au moment où le modèle choisit les tokens qui composeront sa réponse.

Cela suppose de contrôler la chaîne d'inférence.

Lorsque Claude est utilisé depuis l'infrastructure d'Anthropic, le fournisseur contrôle le modèle, le moteur d'inférence et les paramètres de génération. Il peut donc appliquer son mécanisme de marquage à chaque sortie.

Avec un modèle open weight exécuté localement, cette chaîne change de mains. L'organisation contrôle notamment :

• l'infrastructure ;
• le moteur d'inférence ;
• les paramètres d'échantillonnage ;
• le tokenizer ;
• les éventuelles modifications du modèle ;
• et les mécanismes de provenance appliqués aux sorties.

Le créateur des poids n'intervient alors plus nécessairement au moment où le contenu est produit. Le contrôle technique du marquage appartient à celui qui exploite effectivement le système.

Un modèle ouvert n'est pas automatiquement exempté

L'AI Act prévoit certaines exemptions pour les systèmes et modèles publiés sous licence libre. Mais celles-ci ne constituent pas une exemption générale.

L'article 2 précise même que l'exclusion accordée aux systèmes publiés sous licence libre ne s'applique pas lorsqu'ils relèvent notamment de l'article 50, consacré aux obligations de transparence. Le caractère ouvert du modèle ne suffit donc pas à écarter les règles relatives aux contenus synthétiques.

L'article 50 impose aux fournisseurs de systèmes générant du texte, des images, de l'audio ou de la vidéo de rendre leurs productions lisibles par machine et détectables comme artificiellement générées, dans la mesure où cela est techniquement possible.

Fournisseur ou simple utilisateur ?

Le règlement distingue le fournisseur du déployeur.

Le déployeur est l'organisation qui utilise un système d'IA sous sa responsabilité. Une entreprise qui donne à ses salariés accès à un modèle déjà disponible sur le marché est généralement dans cette position.

Le fournisseur est l'organisation qui développe ou fait développer un système d'IA, puis le commercialise ou le met en service sous son propre nom. La définition de la « mise en service » comprend également la première utilisation d'un système pour les besoins propres de l'organisation (article 3).

Installer un modèle ouvert ne transforme donc pas automatiquement une entreprise en fournisseur. En revanche, si elle intègre ces poids dans un système qu'elle conçoit et met en service sous son propre nom, elle peut devenir le fournisseur de ce nouveau système.

Cette distinction doit être examinée au cas par cas. Il ne suffit pas de constater que l'inférence est locale pour déterminer le rôle de l'organisation.

L'usage interne change-t-il la réponse ?

C'est ici que se trouve la principale nuance.

Une sortie produite localement et réservée à un usage interne n'est pas automatiquement exemptée. L'AI Act ne contient pas d'exception générale couvrant tout ce qui reste à l'intérieur d'une entreprise.

Les lignes directrices de la Commission excluent néanmoins certaines catégories de sorties du champ du marquage, notamment :

• le code source ;
• les courtes suites de chiffres, de lettres ou de symboles ;
• les sorties exclusivement transmises entre machines et traitées automatiquement, sans exposition à une personne ;
• certaines productions intermédiaires utilisées dans des environnements industriels ou de développement fonctionnant en circuit fermé, lorsqu'elles ne constituent pas le résultat final.

La Commission mentionne également une exception étroite pour certains contextes industriels ou interentreprises, sous réserve du respect des conditions détaillées dans ses lignes directrices (FAQ sur l'article 50).

Le caractère interne compte donc, mais il ne suffit pas. Ce qui compte surtout est la fonction de la sortie et son exposition éventuelle à des personnes.

Quelques situations concrètes

Ces exemples ne dépendent pas principalement du fait que le modèle fonctionne sur un serveur local. Ils dépendent de la destination du contenu, de son exposition à des personnes et du rôle joué par l'organisation.

Marquage technique et signalement visible ne sont pas la même obligation

L'article 50 prévoit deux mécanismes distincts.

Le premier concerne le fournisseur du système : les sorties doivent être marquées dans un format lisible par machine et détectables comme artificiellement générées.

Le second concerne certains déployeurs : ils doivent signaler visiblement l'origine artificielle de contenus particuliers, notamment les deepfakes et les textes publiés pour informer le public sur des sujets d'intérêt général.

Pour ces derniers textes, l'obligation de signalement ne s'applique pas lorsqu'ils ont fait l'objet d'une véritable vérification humaine ou d'un contrôle éditorial et qu'une personne physique ou morale assume la responsabilité de leur publication. Une simple correction orthographique ne constitue toutefois pas nécessairement un contrôle éditorial suffisant.

Une sortie peut donc être soumise à un marquage technique sans devoir porter une mention visible. Inversement, le déployeur ne peut pas toujours considérer qu'un watermark invisible suffit à satisfaire son obligation d'information du public.

Droit applicable et contrôle technique restent distincts

Une organisation peut juridiquement devoir assurer la provenance de certaines sorties sans que le modèle téléchargé fournisse lui-même ce mécanisme.

C'est l'une des difficultés propres aux modèles ouverts. Le fournisseur d'un service hébergé contrôle la génération et peut imposer un watermark. Dans une installation locale, l'opérateur peut modifier le moteur d'inférence, désactiver un mécanisme existant ou ne jamais l'installer.

La règle juridique peut imposer un résultat, mais elle ne garantit pas techniquement que tout exemplaire modifiable d'un modèle continuera à le produire.

Pour une organisation de bonne foi, cela signifie que la provenance doit être traitée dès la conception du système. Il faut déterminer :

• si l'organisation est fournisseur ou seulement déployeur ;
• si les sorties sont exposées à des personnes ;
• si elles restent dans une chaîne automatisée ou industrielle fermée ;
• si elles constituent des résultats intermédiaires ou des contenus finaux ;
• si elles sont destinées à être publiées ;
• et quel mécanisme de marquage ou de signalement doit être ajouté.

Ce que cela change dans le choix d'architecture

L'inférence locale est souvent choisie pour empêcher les données de quitter l'infrastructure de l'organisation. La provenance ajoute une autre dimension à cette décision.

Avec un service hébergé, le fournisseur contrôle certaines propriétés des contenus produits, y compris leur marquage. Avec un modèle exécuté localement, ce contrôle passe à l'organisation, avec la responsabilité qui peut l'accompagner.

Conclusion

Un modèle local réservé à une organisation n'est pas automatiquement soumis au marquage de toutes ses sorties. Certaines productions purement techniques, transmises entre machines ou utilisées dans un environnement fermé peuvent être exclues.

Mais il n'existe pas d'exemption générale pour les modèles locaux, les modèles ouverts ou les contenus qualifiés d'« internes ». Un texte lu par des salariés, transmis à des clients ou publié à l'extérieur ne devient pas hors champ simplement parce qu'il a été généré sur les serveurs de l'entreprise.

L'analyse repose finalement sur trois questions : qui fournit le système, qui reçoit ses sorties et à quoi celles-ci servent. Le lieu d'exécution ne donne qu'une partie de la réponse. C'est l'un des arbitrages que nous documentons dans notre pratique open-weight.

Sources

• Règlement européen sur l'IA, article 2 : champ d'application
• Règlement européen sur l'IA, article 3 : définitions
• Règlement européen sur l'IA, article 50 : obligations de transparence
• Commission européenne, lignes directrices sur les obligations de transparence
• Commission européenne, questions et réponses sur l'article 50
• Anthropic, fonctionnement du watermark textuel de Claude