Tatouage numérique de texte par IA : quels fournisseurs d'API LLM marquent leurs sorties

Trois fournisseurs majeurs de modèles de langage ont modifié leur manière de marquer les textes générés en l'espace de cinq semaines. Le 5 octobre 2026, OpenAI a permis à ses clients API du monde entier d'activer son tatouage textGrain. Le 3 novembre, Anthropic a étendu le tatouage de Claude à quatre anciens modèles. Le 7 novembre, xAI a activé le tatouage par défaut pour sept modèles Grok. De son côté, Google a confirmé que les textes issus de l'API Gemini intègrent déjà un tatouage SynthID.

Ce changement est motivé par l'IA Act de l'Union européenne. Sa règle sur le marquage lisible par machine est en vigueur depuis le 2 août, et les systèmes d'IA générative déjà sur le marché avant cette date ont jusqu'au 2 décembre pour se mettre en conformité.

Pour les développeurs, la conséquence la moins évidente est la suivante : le nom du modèle ne suffit plus à savoir si une réponse est tatouée. La version du modèle, le fournisseur qui l'héberge, les paramètres du compte et les réglages de génération jouent tous un rôle. Lorsqu'un même modèle est accessible via plusieurs fournisseurs, comme c'est le cas derrière une passerelle d'IA, deux appels au même modèle peuvent aboutir à des résultats dont la provenance diffère.

Ce guide explique le fonctionnement des tatouages numériques de texte, quels modèles de langage les intègrent aujourd'hui, pourquoi le routage modifie la donne et comment tatouer les modèles qui ne le font pas eux-mêmes.

Qu'est-ce qu'un tatouage numérique de texte par IA ?

Un tatouage numérique de texte par IA est un signal statistique dissimulé dans le choix des mots d'un texte généré. Il ne s'agit ni d'une étiquette visible ni d'un champ de métadonnées, et aucun caractère invisible n'est ajouté : le texte se lit exactement comme s'il n'était pas tatoué.

À chaque étape, un modèle de langage dispose généralement de plusieurs jetons (tokens) plausibles pour la suite. Un algorithme de tatouage utilise une clé secrète pour orienter le choix parmi ces options. Sur quelques centaines de jetons, ces choix forment un motif qu'un détecteur possédant la même clé peut identifier. Sans cette clé, le motif est indiscernable d'une variation ordinaire.

Les implémentations diffèrent dans leurs détails. Le textGrain d'OpenAI combine un caractère aléatoire basé sur une clé avec ce qu'il appelle un échantillonnage calibré par entropie. Le système SynthID-Text de Google DeepMind ajuste les probabilités des jetons à l'aide d'une fonction pseudo-aléatoire, et Anthropic utilise une version de ce système pour Claude. L'option native dans vLLM utilise l'échantillonnage Gumbel-max. Le principe reste identique pour tous.

Deux conséquences pratiques en découlent. Premièrement, seul le détenteur de la clé peut effectuer une détection ; vérifier un tatouage nécessite donc généralement de passer par le fournisseur ou un programme d'accès approuvé. Deuxièmement, le signal se renforce avec la longueur du texte et la liberté dont dispose le modèle dans ses choix lexicaux. OpenAI rapporte détecter textGrain dans environ 80 % des passages de 200 jetons et 95 % des passages de 400 jetons sur des questions de psychologie, avec un taux de faux positifs de 1 %, et des taux nettement plus faibles pour les mathématiques.

Ce qu'un tatouage peut et ne peut pas prouver

Un tatouage détecté est la preuve que le texte a été généré ou traité par un modèle spécifique à un moment donné. Il ne dit rien sur l'identité de l'auteur de la requête, le propriétaire du contenu, l'exactitude des informations ou le degré de modification humaine ultérieure.

L'absence de filigrane ne prouve rien non plus. Le texte peut provenir d'un modèle non pris en charge, d'un compte où le filigrane était désactivé, ou d'un passage trop court ou trop modifié pour conserver le signal. Lors d'un test de robustesse distinct mené par OpenAI sur des passages de 400 jetons, le remplacement de 10 % des mots par des synonymes a fait chuter le taux de détection d'environ 92 % à 66 %, et le remplacement de 25 % l'a fait tomber à 17 %.

Un filigrane est un signal de provenance, pas un verdict sur la paternité d'un texte.

Qui est tenu de marquer les textes générés par IA ?

En vertu de l'article 50(2) de l'IA Act européen, les fournisseurs de systèmes d'IA générative doivent marquer leurs résultats dans un format lisible par machine et détectable. Cette obligation incombe au fournisseur du système d'IA, c'est-à-dire l'entreprise qui commercialise le produit. Elle ne s'arrête pas à l'entreprise qui a entraîné le modèle.

Les lignes directrices de la Commission sur l'article 50 permettent à cette entreprise de s'appuyer sur le marquage appliqué par son fournisseur de modèle. Elle reste toutefois responsable du résultat et doit donc être en mesure de démontrer que le marquage est effectivement appliqué à ses sorties et qu'il peut être détecté. C'est pourquoi il est important de savoir quel fournisseur a traité chaque requête, comme l'explique la suite de ce guide.

Il existe des exceptions, notamment pour les systèmes qui se limitent à une aide à la rédaction standard ou qui ne modifient pas substantiellement l'entrée. C'est l'« exception prévue par la loi » que xAI demande aux administrateurs de confirmer avant toute désactivation.

La règle est en vigueur depuis le 2 août 2026. Les systèmes déjà présents sur le marché avant cette date ont jusqu'au 2 décembre 2026 pour se mettre en conformité. Les étiquettes visibles, qui constituent une obligation distincte pour les déployeurs, sont traitées dans notre guide sur les règles d'étiquetage de l'IA Act européen, et le calendrier complet est disponible dans IA Act : 30 jours avant la prochaine échéance.

Ce guide couvre les aspects techniques. La question de savoir si et comment l'article 50 s'applique à un produit spécifique relève de votre équipe juridique.

Quels fournisseurs de LLM intègrent un filigrane à leurs textes ?

Quatre fournisseurs majeurs ont désormais annoncé l'intégration de filigranes textuels, chacun avec des paramètres par défaut, des contrôles et un accès aux détecteurs différents. Le comparatif ci-dessous reflète la documentation publique au 4 novembre 2026 et ne concerne que le texte, à l'exclusion des images, de l'audio ou de la vidéo.

OpenAI : désactivé par défaut pour les clients API

OpenAI a annoncé son approche de la provenance des textes dans l'UE le 5 octobre. Les clients de l'API, où qu'ils se trouvent, peuvent activer textGrain pour certains modèles, au niveau du projet ou de l'organisation, mais la fonctionnalité reste désactivée tant qu'ils ne l'ont pas fait.

ChatGPT et Codex constituent un cas à part. OpenAI intègre par défaut un tatouage numérique au texte éligible généré par ces deux outils dans l'UE, un déploiement qui s'étalera sur plusieurs semaines. Ce paramètre par défaut pour les consommateurs ne s'applique pas aux requêtes API ; ainsi, une équipe utilisant l'API avec les paramètres standard obtient un texte sans tatouage. L'accès aux outils de détection est limité aux chercheurs agréés et aux organisations spécialisées.

Anthropic : activé par défaut, déploiement modèle par modèle

Le tatouage numérique de texte de Claude est activé sans possibilité de désactivation, et Anthropic l'ajoute modèle par modèle. Les modèles plus récents, comme Opus 5.5, en étaient dotés dès leur lancement. Le 4 novembre, Anthropic a commencé à tatouer le texte généré par quatre anciens modèles sur sa propre API : Mythos 5, Opus 4.7, Opus 4.6 et Sonnet 4.6. Son e-mail client, rapporté par Mashable, indique que le déploiement sur Amazon Bedrock pourrait prendre quelques jours de plus. Opus 4.5, Sonnet 4.5 et Haiku 4.5 ne figuraient pas sur cette liste.

La page du centre d'aide d'Anthropic intitulée « Comment Claude marque le contenu généré par l'IA » détaille la couverture par modèle et par interface : l'API et les applications d'Anthropic, AWS, Google Cloud et Microsoft Foundry. Elle mentionne également les Content Credentials pour les fichiers générés, un signal distinct du tatouage numérique de texte. La détection est actuellement en phase de prévisualisation privée pour les organisations approuvées.

xAI : activé par défaut pour sept modèles Grok

Selon la documentation de xAI sur le tatouage numérique des sorties, le texte généré par Grok 4.7, 4.6, 4.5 et 4.3, ainsi que par les trois variantes de Grok 4.20 (raisonnement, non-raisonnement et multi-agents), comporte un tatouage numérique depuis le 7 novembre 2026. Cela s'applique aux points de terminaison mondiaux et régionaux de xAI et couvre le texte brut, les sorties structurées et les arguments d'appel d'outils.

Les administrateurs d'équipe peuvent désactiver cette option modèle par modèle dans la console SpaceXSI, mais uniquement après avoir confirmé qu'une exception légale s'applique et que leur équipe assume la responsabilité du marquage. Certains modèles peuvent être verrouillés sur « activé ».

Deux détails méritent d'être soulignés. Chaque réponse marquée comporte un en-tête x-watermark: true , qui fournit une preuve par requête lorsque vous appelez directement xAI. De plus, les anciens modèles tels que Grok 4.1 Fast, Grok 4, Grok 3 et Grok Code Fast ne figurent pas sur la liste ; leur sortie reste donc sans tatouage, même sur l'API de xAI.

Google : SynthID dans le texte de l'API Gemini

Google intègre un tatouage numérique au texte dans l'application Gemini avec SynthID depuis 2024. Pour l'API, la déclaration la plus claire provient du forum des développeurs de Google. Un membre de l'équipe a d'abord affirmé que le texte de l'API Gemini n'était pas tatoué, avant de se corriger deux semaines plus tardLe texte provenant de l'API Gemini et de Google AI Studio est marqué par le filigrane SynthID.

Deux questions restent en suspens. Le fil de discussion ne précise pas si Gemini sur Vertex AI se comporte de la même manière, et Google ne propose aucun détecteur public pour le texte. Une réponse sur un forum constitue également une base moins solide que la documentation produit ; les équipes qui s'y fient pour des questions de conformité devraient donc obtenir une confirmation écrite.

Mistral, Meta et autres modèles hébergés

Au 4 novembre, nous n'avons trouvé aucun filigrane textuel documenté pour Mistral, Meta ou la plupart des autres fournisseurs hébergés. Considérez cela comme une lacune à combler auprès du fournisseur, et non comme la preuve que le contenu n'est pas marqué.

Même modèle, fournisseur différent : pourquoi le canal compte

La plupart des modèles populaires sont vendus par plusieurs fournisseurs : l'API du créateur du modèle, des plateformes cloud comme Amazon Bedrock et Google Vertex AI, ainsi que des fournisseurs d'inférence indépendants. Un filigrane annoncé par le créateur du modèle ne s'applique pas automatiquement à chacun d'entre eux.

Claude Opus 4.7 l'illustre bien. Au 4 novembre, son texte est marqué par un filigrane sur l'API d'Anthropic, tandis que le déploiement sur Bedrock n'est prévu que dans quelques jours et que d'autres plateformes n'ont pas encore été listées. Deux requêtes pour le même modèle le même jour peuvent renvoyer un texte à la provenance différente.

Quatre facteurs déterminent si une réponse donnée comporte un filigrane.

1. La version du modèle. Le marquage par filigrane accompagne généralement les nouvelles versions et est appliqué aux anciennes ultérieurement, si tant est qu'il le soit. Grok 4.7 est couvert, contrairement à Grok 4.

2. Le fournisseur traitant la requête. La documentation de xAI couvre ses propres points de terminaison, mais Grok 4.7 est également vendu via Amazon Bedrock et Databricks. Anthropic liste la couverture cloud modèle par modèle. Un canal non mentionné par le créateur du modèle est un canal que vous devez vérifier.

3. Les paramètres du compte. Le filigrane de l'API d'OpenAI est activé par projet ou par organisation, et celui de xAI est géré par équipe. Lorsqu'un revendeur ou une passerelle appelle le fournisseur avec ses propres clés, ce sont ses paramètres de compte qui s'appliquent. Avec vos propres clés, ce sont les vôtres.

4. Les paramètres de génération. Dans les configurations auto-hébergées, certaines requêtes ne peuvent pas comporter de filigrane, comme le décodage déterministe dans vLLM (voir ci-dessous). Les fournisseurs hébergés n'ayant pas publié de limites similaires, ne présumez rien dans un sens ou dans l'autre.

La résidence des données constitue une vérification supplémentaire. Les canaux choisis pour maintenir le traitement en Europe sont souvent des plateformes cloud plutôt que l'API propre au créateur du modèle. La résidence et la couverture par filigrane sont deux questions distinctes, et chacune nécessite une réponse pour le canal que vous utilisez réellement.

Comment marquer les modèles qui ne le font pas eux-mêmes

Si vous hébergez vous-même un modèle à poids ouverts, personne ne marquera sa sortie à moins que vous ne le fassiez. La bonne nouvelle est qu'il n'est plus nécessaire de créer un filigrane à partir de zéro. Il existe deux options pratiques : le marquage natif dans vLLM et SynthID-Text de Google via Hugging Face Transformers.

Marquage natif dans vLLM

vLLM a ajouté le tatouage numérique natif de texte en septembre 2026. Il est désactivé par défaut et s'active au démarrage du serveur :

vllm serve YOUR_MODEL \
  --watermark-config '{"algorithm":"gumbel","key":42,"enforce":true}'

La clé 42 provient de la documentation de vLLM et n'est qu'un espace réservé. En production, utilisez une clé secrète et stockez-la comme n'importe quel autre identifiant.

LesLa documentation sur le tatouage numérique de vLLM mérite d'être lue en intégralité. Ces points sont les plus importants :

• Désactivation par requête : les clients peuvent envoyer watermarking: false pour ignorer le tatouage. Définir enforce permet de passer outre ces désactivations.
• Requêtes ne pouvant pas être tatouées : décodage glouton (temperature=0), top_k=1 et la recherche par faisceau s'exécutent sans filigrane, même avec imposer activé. vLLM enregistre un avertissement la première fois que cela se produit.
• Signal plus faible : les sorties structurées et les grammaires d'outils restreignent les choix de mots, ce qui laisse moins de place au signal.
• Exigence du moteur : le filigrane ne fonctionne actuellement qu'avec le Model Runner V2 de vLLM.
• Suivi de la couverture : un compteur Prometheus, vllm:watermark_requests_total, divise les requêtes terminées en avec_filigrane,ignoréetsans_filigrane. Cela vous donne un enregistrement mesurable de la couverture.

La détection est une étape distincte. Le détecteur fonctionne sur les identifiants de jetons et nécessite le même tokenizer, le même algorithme et la même clé que ceux utilisés pour la génération :

from transformers import AutoTokenizer
from vllm.v1.watermarking import GumbelWatermarkDetector

tokenizer = AutoTokenizer.from_pretrained("YOUR_MODEL")
token_ids = tokenizer.encode(text, add_special_tokens=False)

result = GumbelWatermarkDetector(key=YOUR_SECRET_KEY, prf="philox").detect(token_ids)
print(result.p_value, result.is_watermarked)

Avant de vous fier à is_watermarked, vLLM recommande de mesurer le taux de faux positifs sur votre propre trafic sans filigrane. Gardez également le détecteur en interne ou limitez son débit, car des requêtes répétées peuvent aider quelqu'un à apprendre comment supprimer ou imiter le signal. La prise en charge de SynthID-Text dans vLLM est prévue mais n'est pas encore implémentée.

SynthID-Text avec Hugging Face Transformers

Google a publié en open source SynthID-Text, et Hugging Face Transformers l'intègre sous forme de processeur de logits. Vous le configurez à l'aide de clés secrètes et d'une longueur de n-grammes, ce qui permet d'équilibrer la détectabilité et la robustesse face aux modifications. Il fonctionne avec n'importe quel modèle compatible sans nécessiter de réentraînement. La détection nécessite à nouveau l'utilisation des mêmes clés.

Transformers est adapté aux traitements par lots et aux déploiements de plus petite envergure. Pour un service à haut débit, l'option native de vLLM est aujourd'hui le choix le plus pratique. Si vous utilisez déjà un modèle tel que Kolibri d'Aleph Alpha avec vLLM, l'ajout d'un filigrane relève d'une simple modification de configuration plutôt que de la mise en place d'un nouveau système.

Ce qu'implique l'utilisation de votre propre filigrane

L'auto-hébergement vous donne le contrôle, mais s'accompagne des responsabilités qu'un fournisseur assumerait normalement :

• Clés : gardez-les secrètes, renouvelez-les et consignez quelle configuration a été utilisée pour quelle période. Le détecteur doit tester le texte par rapport à chaque configuration que vous avez utilisée.
• Détection : décidez qui peut vérifier le texte et comment, car le marquage doit également être détectable.
• Tests : vérifiez la détection sur des résultats réalistes, en couvrant différentes longueurs, langues et modifications.
• Documentation : enregistrez les limites, comme pour les requêtes gloutonnes (greedy) et les réponses courtes, afin que personne ne considère l'absence de filigrane comme une preuve de paternité humaine.

Garder le contrôle du routage avec Eden AI

Eden AI donne accès aux modèles de nombreux fournisseurs via une seule API compatible avec OpenAI. Lorsque vous nommez un modèle sans préciser de fournisseur, le routage des fournisseurs choisit qui le sert : par défaut, il privilégie les fournisseurs les moins chers et bascule vers un autre fournisseur si l'un d'eux est indisponible. C'est utile pour les coûts et la disponibilité. Pour les fonctionnalités qui dépendent d'un filigrane, cela signifie que le routage doit être défini explicitement.

Dans le catalogue Eden AI, par exemple, Claude Opus 4.7 est disponible via Anthropic, Amazon Bedrock, Google Vertex AI, Databricks et DeepInfra. Grok 4.7 est disponible via xAI, Amazon Bedrock et Databricks. Comme l'a montré la section précédente, ces routes ne partagent pas la même couverture de tatouage numérique documentée.

Fixez le fournisseur. Indiquer un fournisseur/modèleconcret, tel que anthropic/claude-opus-4-7, désactive le routage pour cette requête. Elle est envoyée exactement là où vous l'avez dirigée.

Restreignez les fournisseurs. Lorsque vous souhaitez conserver le routage pour un nom de modèle générique, routing.allowed_providers le limite aux fournisseurs que vous avez sélectionnés. Tous les autres fournisseurs sont exclus, y compris pour le basculement, et la requête échoue avec une erreur explicite au lieu d'être redirigée ailleurs.

Contrôlez les solutions de repli. routing.allow_fallbacks: false empêche le basculement vers d'autres fournisseurs du même modèle. Les modèles que vous listez dans les solutions de secours sont toujours tentés ; ne listez donc que les routes que vous avez vérifiées. Vous pouvez enregistrer toute la configuration en tant que politique de routage et l'appliquer à chaque appel effectué avec une clé API.

Enregistrez la route. Envoyez le x-edenai-metadata: enabled en-tête et la réponse inclut un edenai_metadata bloc. Comme décrit dans la documentation sur les métadonnées de requête, il affiche tous les fournisseurs testés, celui qui a traité la requête, sa région et si votre propre clé a été utilisée. Enregistrez-le avec le contenu généré.

Voici l'ensemble dans une seule requête :

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.edenai.run/v3",
    api_key=os.environ["EDENAI_API_KEY"],
)

response = client.chat.completions.create(
    # Pinned: always served by Anthropic's own API
    model="anthropic/claude-opus-4-7",
    messages=[{"role": "user", "content": "Summarize the following technical report."}],
    extra_headers={"x-edenai-metadata": "enabled"},
    extra_body={
        # If Opus 4.7 fails, fall back to Sonnet 4.6, also pinned to Anthropic
        "fallbacks": ["anthropic/claude-sonnet-4-6"],
    },
)

# Store this record next to the generated text
meta = response.model_dump().get("edenai_metadata") or {}
print(meta.get("strategy"), meta.get("summary"))
for attempt in meta.get("attempts", []):
    print(attempt["provider"], attempt["model"], attempt["status"], attempt.get("region"))

Quelques points méritent d'être connus sur le fonctionnement actuel :

• Eden AI n'ajoute, ne supprime ni ne vérifie les filigranes. Le texte arrive tel que le fournisseur l'a généré.
• Les paramètres du compte dépendent des clés utilisées. Via les propres comptes de fournisseurs d'Eden AI, les paramètres de filigrane par défaut de chaque fournisseur s'appliquent. Avec BYOK, les paramètres de votre propre compte fournisseur s'appliquent, vous pouvez donc activer vous-même le filigrane d'OpenAI. Les fournisseurs BYOK peuvent être combinés avec les fournisseurs facturés par Eden AI dans le routage ; fixez ou restreignez donc le fournisseur si une requête doit rester sur votre compte. Le champ is_byok confirme quelle clé a été utilisée.
• Les routes UE diffèrent des routes directes.L'point de terminaison européen ne passe que par des fournisseurs autorisés pour le traitement européen. Pour Claude, cela signifie les régions UE de Bedrock, Vertex AI ou Databricks plutôt que l'API propre d'Anthropic ; consultez donc le tableau de couverture d'Anthropic pour ces routes.

Détection de filigrane versus détection de texte généré par IA

Les deux sont souvent confondus, mais ils répondent à des questions différentes.

Un détecteur de filigrane cherche à savoir si un texte porte le signal de la clé d'un fournisseur spécifique. Sur des passages longs et non modifiés, il est fiable, mais il ne reconnaît que les modèles pris en charge par ce fournisseur.

Un détecteur de texte IA évalue si un texte semble avoir été rédigé par une intelligence artificielle. Il fonctionne avec n'importe quel texte issu de n'importe quel modèle, mais sa réponse est une estimation de probabilité basée sur des modèles rédactionnels, et non une vérification de signal.

L'API de détection d'IA d' Eden AI appartient au second groupe ; elle ne peut donc pas confirmer la présence d'un filigrane Grain, Claude, SynthID ou Grok. Les deux outils sont complémentaires : le filigrane sert de signal de provenance lorsqu'il existe, tandis que la détection d'IA agit comme un signal de filtrage dans tous les autres cas. Aucun des deux ne prouve qui a rédigé un texte.

Une liste de contrôle avant le 2 décembre

1. Listez vos fonctionnalités textuelles. Notez chaque fonctionnalité générant du texte pour les utilisateurs, et précisez si elle a été lancée avant ou après le 2 août.
2. Cartographiez le parcours exact. Pour chaque fonctionnalité, enregistrez la version du modèle, le fournisseur, la région et chaque solution de secours.
3. Vérifiez la couverture par parcours. Confirmez dans la documentation du fournisseur que ce modèle sur ce parcours est bien filigrané, et notez la date de votre vérification.
4. Vérifiez les paramètres du compte. Déterminez si le filigrane est activé, optionnel ou géré par projet ou par équipe, et identifiez le compte sur lequel la requête est exécutée.
5. Verrouillez la route. Épinglez ou restreignez les fournisseurs pour les fonctionnalités nécessitant un filigrane, et ne conservez que les solutions de secours vérifiées.
6. Enregistrez la route. Stockez le fournisseur ayant traité chaque requête avec le contenu associé.
7. Comblez les lacunes. Pour les modèles auto-hébergés ou les routes non marquées, ajoutez votre propre filigrane et un moyen de le détecter.
8. Testez et documentez. Vérifiez la détection sur des résultats réalistes, notez les limites et examinez la configuration avec votre équipe juridique.

Conclusion

Le tatouage numérique de texte est passé de la recherche à la production en quelques semaines, mais de manière inégale. Le filigrane de l'API d'OpenAI est optionnel, ceux d'Anthropic et de xAI sont activés par défaut, Google en a confirmé un pour l'API Gemini, et la plupart des autres fournisseurs n'ont encore rien documenté. Les équipes qui déploient des modèles à poids ouverts peuvent désormais ajouter le leur avec vLLM ou SynthID-Text.

La leçon pratique est qu'un filigrane appartient à une route, et non à un nom de modèle. Les applications qui utilisent plusieurs fournisseurs, directement ou via une passerelle, doivent rendre explicites leurs exigences en matière de provenance. En pratique, cela signifie épingler ou restreindre les fournisseurs, maintenir des solutions de secours vérifiées et enregistrer quel fournisseur a traité chaque requête.

Savoir quel modèle a rédigé un texte ne suffit plus. Vous devez savoir quelle route l'a généré, comment elle était configurée et qui peut vérifier le résultat.

FAQ

Pour aller plus loin

Recherche originale

• Un filigrane pour les grands modèles de langage (Kirchenbauer et al., 2023) : la méthode de la « liste verte » sur laquelle reposent la plupart des systèmes ultérieurs.
• Tatouage numérique évolutif pour l'identification des sorties de grands modèles de langage (Dathathri et al., Nature, 2024) : l'article sur SynthID-Text, qui est également la base du filigrane de Claude.
• Conférence de Scott Aaronson sur le tatouage numérique Gumbel-max: l'idée derrière l'algorithme par défaut de vLLM.
• Filigranes sans vérification : le tatouage numérique de texte par IA après l'IA Act de l'UE (2026) : évaluation du tatouage numérique de texte selon les nouvelles règles.

Documentation des fournisseurs

• OpenAI : Notre approche des règles européennes sur la provenance des textes
• Anthropic : Comment fonctionne le tatouage numérique de texte de Claude
• xAI : Tatouage numérique des sorties
• Google DeepMind : SynthID
• vLLM : Tatouage numérique dans vLLM et la documentation sur le tatouage numérique de texte

Réglementation

• Commission européenne : Obligations de transparence au titre de l'article 50
• Lignes directrices de la Commission sur l'article 50 (PDF)

Sur le blog et la documentation d'Eden AI

• Loi sur l'IA : 30 jours avant la prochaine échéance
• Règles d'étiquetage de la loi européenne sur l'IA pour les contenus générés par IA
• Qu'est-ce que le routage LLM ?
• Meilleurs LLM à poids ouverts
• Docs : Routage de fournisseur,Politiques de routage,Métadonnées de requête,BYOKetPoint de terminaison UE