Quali API marcano i contenuti AI? 16 API, 10 normative
Indice
Sei giurisdizioni e quattro stati USA impongono ormai che i media generati dall’AI contengano un marcatore leggibile dalle macchine. Abbiamo quindi generato immagini, video e parlato tramite 16 SKU API, cioè varianti di modello con prezzi distinti, e analizzato i byte restituiti: 7 includono un manifest C2PA, 4 l’etichetta implicita cinese, nessuna entrambe, mentre gli SKU video e audio non includono nulla. Abbiamo poi sottoposto i file marcati alle normali operazioni di elaborazione delle immagini. In entrambe le librerie provate, ogni manifest C2PA è scomparso alla prima ricodifica, al primo ridimensionamento o al primo ritaglio. Questo articolo misura con precisione dove sono le lacune e quanto costa colmarle.
TL;DR
- 7 degli 11 SKU per immagini integrano C2PA (OpenAI, ByteDance); 4 integrano l’etichetta implicita cinese (Alibaba); nessuno integra entrambi.
- Lo SKU video e tutti e 4 gli SKU vocali hanno restituito file senza alcuna marcatura, anche se le norme UE e californiane coprono entrambi.
- La firma di OpenAI viene convalidata rispetto alla trust list C2PA ufficiale; quella di ByteDance è valida ma non attendibile, perché la catena termina in una root assente dalla lista.
- Nessun manifest C2PA è sopravvissuto alle trasformazioni; l’etichetta cinese resiste alle operazioni da PNG a PNG in ImageMagick, ma non in Pillow, e nessuna delle due sopravvive a un cambio di formato.
Quali norme richiedono davvero qualcosa dentro il file?
Sono molte meno di quanto faccia pensare la quantità di leggi sull’AI. La maggior parte richiede un’etichetta visibile alle persone oppure la rimozione dei contenuti sintetici quando causano danni. Le norme riportate sotto, invece, impongono informazioni all’interno del file, quindi devono essere soddisfatte dall’utente dell’API già in fase di generazione. Questa è una lettura tecnica dei testi citati, non un’analisi legale; per gli aspetti giuridici, i punti di partenza sono le linee guida della Commissione sull’articolo 50 e il tracker globale delle leggi sull’AI di IAPP.
| Regime | Cosa deve contenere il file | In vigore dal |
|---|---|---|
| AI Act UE, art. 50(2) | marcatura “in un formato leggibile dalle macchine”; non indica alcuna tecnica specifica e anche il Codice di buone pratiche è tecnologicamente neutrale | 2026-08-02 |
| Misure cinesi sull’etichettatura + GB 45438-2025 | un’etichetta implicita nei metadata con campi prescritti (codice del produttore, ID del contenuto, firma), oltre a un’etichetta visibile; è l’unico regime con uno schema proprio e l’unico per cui siano già in corso azioni esecutive | 2025-09-01 |
| India, IT Rules G.S.R. 120(E) | un’etichetta visibile e “metadata permanenti o altri meccanismi tecnici appropriati per la provenienza … incluso un identificatore univoco” | 2026-02-20 |
| Vietnam, legge sull’AI, art. 11(2) | audio, immagini e video “marcati in un formato leggibile dalle macchine”; la tecnica non è definita | 2026-03-01 |
| Kazakistan, legge sull’AI, art. 21(2) | marcatura leggibile dalle macchine e avviso visibile per i contenuti che simulano una persona o un evento | 2026-01-18 |
| Corea del Sud, AI Framework Act, art. 31 | leggibile dalle persone oppure dalle macchine, a scelta dell’operatore; periodo di tolleranza fino al 2027 | 2026-01-22 |
| USA: California, poi Connecticut, Utah, Washington | una “comunicazione latente” contenuta nel file: provider, nome e versione del sistema, ora e data, identificatore univoco; la California richiede anche uno strumento pubblico e gratuito di rilevamento. Si applica ai provider con oltre un milione di utenti mensili | dal 2026-08-02 al 2027 |
Tutti gli altri richiedono un’etichetta visibile alle persone, oppure non impongono nulla: più di trenta stati USA richiedono un’avvertenza sui deepfake elettorali, mentre non esiste alcun obbligo generale di marcatura nella legge federale statunitense, nel Regno Unito, in Giappone, Australia o Singapore. (Due casi possono trarre in inganno: la Norvegia non è ancora soggetta all’articolo 50, perché l’AI Act non fa parte dell’Accordo SEE, e la legge italiana del 2025 sull’AI non prevede obblighi di marcatura, nonostante molte fonti sostengano il contrario.)
Ne derivano tre dati tecnici. I regimi sono definiti in modi incompatibili: l’UE non indica un formato, la Cina prescrive uno schema proprio, India e Vietnam chiedono informazioni di provenienza senza specificarne il tipo. C2PA, il formato adottato dalla maggior parte dei vendor occidentali, non compare quasi mai nelle norme vincolanti: lo citano soltanto Connecticut e Washington, mentre nessun regime nazionale lo fa. Inoltre, cinque legislatori hanno inserito nell’obbligo il requisito della persistenza, chiedendo informazioni di provenienza “difficili da manomettere, rimuovere o dissociare” (Connecticut), “difficili da rimuovere o manomettere” (Washington), “metadata permanenti” (India), “con manomissioni rilevabili” (la legge dello Utah sulla pubblicità elettorale) oppure “permanenti o non facilmente rimovibili” (Colorado). I test di trasformazione riportati sotto misurano quanto la tecnologia disponibile riesca a soddisfare queste formulazioni.
Com’è fatto materialmente un marcatore C2PA?
È un blocco di JSON firmato aggiunto al file, invisibile nell’immagine. C2PA, definito dalla Coalition for Content Provenance and Authenticity, descrive nel proprio standard tecnico un “manifest”: un record firmato crittograficamente che indica chi ha creato una risorsa e come, così da rendere rilevabili eventuali manomissioni. In un PNG occupa un chunk dedicato accanto ai pixel. Analizzando i chunk di una delle immagini generate, si vede esattamente dove si trova e quanto spazio richiede:
IHDR 13 bytes image header
caBX 21,767 bytes C2PA manifest store <- the mark
IDAT 2,115,575 bytes the actual pixels
IEND 0 bytes
Circa 22 KB su un’immagine da 2 MB, quindi più o meno l’1%, e nessuna modifica ai pixel: sull’immagine non viene disegnato nulla, perciò appare identica in qualsiasi visualizzatore. Il badge “Content Credentials” compare soltanto nei software che lo cercano.
All’interno, il manifest letto da un verificatore su un’immagine OpenAI si presenta così, ridotto ai campi essenziali:
{
"claim_generator_info": [{ "name": "OpenAI Media Service API" }],
"signature_info": {
"issuer": "OpenAI OpCo, LLC",
"time": "2026-08-22T13:47:29Z"
},
"assertions": [{
"label": "c2pa.actions.v2",
"data": { "actions": [{
"action": "c2pa.created",
"when": "2026-08-22T00:00:00Z",
"softwareAgent": { "name": "gpt-image", "version": "pre-2.0" },
"digitalSourceType": ".../digitalsourcetype/trainedAlgorithmicMedia"
}]}
}]
}
Il meccanismo si basa su tre elementi. L’azione specifica che la risorsa è stata creata, non modificata, mentre digitalSourceType: trainedAlgorithmicMedia è il termine del vocabolario IPTC per indicare un contenuto “creato da un modello generativo”: è questo il campo che dichiara effettivamente “AI” in forma leggibile dalle macchine. Il software agent identifica il modello. La firma collega tutte queste informazioni a un certificato, permettendo al verificatore di stabilire se la dichiarazione è stata modificata e chi se ne assume la responsabilità.
L’etichetta implicita cinese, definita da GB 45438-2025, lo standard nazionale obbligatorio pubblicato insieme alle misure sull’etichettatura, risolve lo stesso problema senza alcuna autorità di firma. È un chunk di testo semplice contenente JSON:
{ "Label": "1",
"ContentProducer": "001191330106MA2CFLDG4R10001",
"ProduceID": "U-9TlH0PCIQomj9MzIc5VUuQ",
"ReservedCode1": "K-LBkc9peJ0Gox..." }
Label: 1 indica che il contenuto è generato dall’AI, ContentProducer è il codice societario registrato del provider, ProduceID è il numero del contenuto assegnato dal vendor e ReservedCode è un valore di firma. L’obiettivo è lo stesso, ma cambia il modello di fiducia: C2PA demanda a un’autorità di certificazione la garanzia sulla dichiarazione; l’etichetta cinese rimanda a un’azienda registrata e lascia la verifica a chi vuole effettuarla.
Cosa integrano davvero le API?
Sette degli undici SKU per immagini integrano C2PA, quattro l’etichetta cinese, con una separazione netta per vendor:
| SKU | Formato | C2PA | Etichetta implicita cinese | Timestamp di creazione |
|---|---|---|---|---|
| gpt-image-1, 1-mini, 1.5, 2 | PNG | sì | no | solo la data, 00:00:00Z |
| seedream-4.0, 4.5, 5.0 | JPEG | sì | no | preciso al secondo |
| qwen-image-2.0, 2.0-pro | PNG | no | sì | nessuno |
| wan2.7-image, 2.7-pro | PNG | no | sì | nessuno |
| seedance-1.5-pro (video) | MP4 | no | no | n/a |
| tts-1, qwen3-tts, google-tts-standard, chirp3-hd | MP3 / WAV | no | no | n/a |
Entrambi i gruppi C2PA dichiarano esattamente i campi mostrati sopra, c2pa.created insieme a trainedAlgorithmicMedia. Anche i due vendor che adottano l’etichetta cinese producono la stessa struttura GB 45438, con un’aggiunta: una seconda coppia di campi che identifica chi ridistribuisce il file. Tre aspetti contano più delle colonne sì/no.
Le firme non hanno lo stesso livello di attendibilità. La verifica avviene in due fasi: prima si legge il manifest, poi si controlla che il certificato di firma abbia una catena che termina in una root presente nella trust list C2PA. Un verificatore standard non considera attendibile nulla per impostazione predefinita e restituisce signingCredential.untrusted per ogni file, inclusi quelli validi. Chi effettua verifiche su larga scala deve quindi caricare per prima cosa la lista ufficiale. Con questa lista, le immagini OpenAI risultano attendibili, perché la loro CA emittente è una delle 17 entità presenti. Quelle di ByteDance no: i manifest sono firmati tramite un intermediario GlobalSign S/MIME, un tipo di certificato destinato alla posta elettronica, la cui root non compare nella lista. Secondo la terminologia dello standard, i manifest ByteDance sono validi perché la firma è corretta e l’immagine non è stata modificata dopo la firma, ma non sono attendibili. Un verificatore conforme, quindi, non può garantire l’identità di chi ha emesso la dichiarazione.
Il timestamp di OpenAI non contiene l’ora. Tutti i manifest OpenAI riportavano 2026-08-22T00:00:00Z, cioè la mezzanotte del giorno di generazione, mentre ByteDance registrava il secondo effettivo. Ridurre la precisione è una scelta difendibile per la privacy, ma la comunicazione latente richiesta dalla California deve includere “ora e data”. È un punto da sottoporre ai consulenti legali.
Audio e video sono vuoti. Sia l’AI Act sia la normativa californiana coprono audio e video sintetici. Non si tratta di un limite dei formati, perché lo standard C2PA supporta MP4, WAV e MP3 come contenitori. L’MP4 generato conteneva soltanto i normali campi del container QuickTime; i quattro file vocali avevano solo gli header dei codec. Le marcature erano inoltre identiche sia per le immagini restituite in base64 sia per quelle consegnate tramite URL, quindi il percorso di delivery non aggiunge né rimuove informazioni di provenienza.
Le marcature resistono alle normali elaborazioni?
Il manifest C2PA non resiste mai. L’etichetta cinese sopravvive soltanto se lo strumento di elaborazione conserva i chunk di testo. La differenza è emersa eseguendo le stesse cinque operazioni sia con Pillow per Python sia con ImageMagick, su tre file marcati: un’immagine OpenAI con C2PA, una ByteDance con C2PA e una Alibaba con etichetta cinese.
| Trasformazione | C2PA (OpenAI) | C2PA (ByteDance) | Etichetta cinese (Alibaba) |
|---|---|---|---|
| Copia byte per byte | sopravvive | sopravvive | sopravvive |
| Ricodifica in PNG | scompare | scompare | dipende dallo strumento |
| Ridimensionamento al 50% | scompare | scompare | dipende dallo strumento |
| Ritaglio del 10% | scompare | scompare | dipende dallo strumento |
| Conversione in JPEG q90 | scompare | scompare | scompare |
| Conversione in WebP q85 | scompare | scompare | scompare |
Pillow ha perso tutte le marcature in tutte le operazioni, 0 su 15. ImageMagick ne ha conservate 3 su 15, tutte relative all’etichetta cinese durante operazioni da PNG a PNG. La qualità dell’immagine non è la causa: una ricodifica in PNG lossless distrugge un manifest C2PA esattamente come un JPEG lossy.
La differenza ha una spiegazione semplice. L’etichetta cinese è un normale chunk di testo PNG (tEXt, lo spazio standard per le coppie chiave-valore), quindi uno strumento che copia i chunk di testo la conserva automaticamente. ImageMagick lo fa per impostazione predefinita; Pillow soltanto se glielo si chiede. Il manifest C2PA si trova invece in un chunk personalizzato che i comuni strumenti di elaborazione non conoscono, quindi viene eliminato anche quando si richiede di mantenere i metadata: ImageMagick lo ha scartato durante un semplice ridimensionamento e di nuovo quando abbiamo passato l’opzione che include esplicitamente tutti i chunk. Entrambe le marcature scompaiono passando da un formato all’altro, perché un chunk di testo PNG non ha una destinazione equivalente in JPEG o WebP.
La regola pratica è quindi più precisa di “i metadata sono fragili”. Se una trasformazione è necessaria, restando nello stesso formato e usando una libreria che conserva i chunk di testo si mantiene anche l’etichetta cinese. Per C2PA non esiste un percorso di conservazione con gli strumenti comuni: bisogna firmare nuovamente il file dopo la trasformazione. La procedura funziona, ma cambia la dichiarazione, perché il nuovo manifest indica la pipeline come firmatario anziché il vendor del modello e rimane non attendibile finché il certificato non viene inserito in una trust list.
Confrontiamo il risultato con le cinque formulazioni normative citate sopra. Un generatore di thumbnail, una trasformazione eseguita da una CDN, una procedura di rimozione degli EXIF per la privacy o uno screenshot dell’utente cancellano queste marcature. Da sola, quindi, la tecnologia indicata dalle leggi non garantisce la persistenza richiesta. Il livello che resiste è un watermark impercettibile integrato nei pixel. Il più diffuso, SynthID di Google, non offre però un rilevatore pubblico e il portale di verifica è accessibile solo tramite lista d’attesa, quindi un soggetto terzo non può confermarne la presenza. L’unico livello verificabile direttamente dal file è quello dei metadata e, tra due librerie e tre marcature, è sopravvissuto a una trasformazione in una sola combinazione: ImageMagick con l’etichetta cinese.
Se la marcatura scompare comunque, vale la pena includerla?
Sì, perché le piattaforme rilevanti la leggono nell’unico momento in cui esiste ancora: l’upload. Un manifest che non sopravvive al generatore di thumbnail viene comunque letto quando si consegna il file originale. L’etichetta associata dalla piattaforma al post continuerà a esistere anche dopo la scomparsa dei metadata.
| Piattaforma | Cosa legge durante l’upload | Cosa succede |
|---|---|---|
| TikTok | C2PA Content Credentials, da maggio 2024 | etichetta automaticamente i contenuti AI creati altrove; aggiunge inoltre le proprie credenziali ai contenuti TikTok, che “rimangono associate ai contenuti quando vengono scaricati” |
| YouTube | metadata C2PA, oltre alla dichiarazione del creator | i “contenuti che includono metadata C2PA” vengono etichettati automaticamente; i creator che omettono ripetutamente la dichiarazione rischiano l’applicazione forzata dell’etichetta, la rimozione o la sospensione dal Programma partner |
| Meta | indicatori C2PA e IPTC, oltre a classificatori e autodichiarazioni | applica l’etichetta “Informazioni AI” |
| solo manifest C2PA, senza un proprio rilevatore | mostra un badge Content Credentials | |
| X | nella policy sull’autenticità non è documentata alcuna lettura delle informazioni di provenienza | applicazione delle regole basata su classificatori e segnalazioni |
Questo cambia la conclusione tecnica. Il livello dei metadata non è una proprietà persistente del file: è un segnale inviabile una sola volta a chi riceve i byte originali. Se lo includete, TikTok e YouTube lo trasformano in un’etichetta memorizzata nel loro database invece che nel PNG. Se lo omettete, vi affidate ai loro classificatori. Restano due limiti: nessuna di queste piattaforme documenta se il file restituito agli utenti mantenga il manifest e non lo abbiamo verificato; X, inoltre, non documenta alcuna lettura delle informazioni di provenienza.
Cosa fare quando il file arriva senza marcature?
Bisogna aggiungerle, scegliendo quale livello inserire e in quale punto. Abbiamo misurato il percorso basato sui metadata: firmare offline un’immagine Alibaba priva di marcatura C2PA con un manifest proprietario ha richiesto 59 ms e aumentato il file di circa l’8%, da 1.18 MB a 1.28 MB. Il nuovo manifest dichiarava c2pa.created con trainedAlgorithmicMedia, indicava il modello upstream e coesisteva con l’etichetta cinese già presente nel file. Un file può quindi contenere entrambi i sistemi, anche se nessun vendor li fornisce insieme. Ci sono due limiti: il manifest autofirmato risulta non attendibile per lo stesso motivo di quello ByteDance, e la ricodifica del file firmato ha distrutto la nuova marcatura con la stessa facilità di quella del vendor.
| Intervento | Problema risolto | Costo | Fragilità |
|---|---|---|---|
| Firmare offline un manifest C2PA dopo la generazione | marcatura leggibile dalle macchine per l’UE; comunicazione latente californiana se si specificano provider, versione, ora e identificatore | 59 ms, +8% di dimensione, oltre a un certificato emesso da un’autorità riconosciuta | scompare a ogni ricodifica |
| Inserire il manifest al momento del delivery, nel percorso API | come sopra, ma applicato in modo uniforme | stessa operazione, eseguita prima | invariata |
| Incorporare un’etichetta visibile nei pixel | opzione di comunicazione a schermo prevista dalla California, che la legge chiama “manifest” disclosure senza alcun legame con un manifest C2PA; etichetta esplicita cinese | un’operazione di compositing | sopravvive a tutto, ma modifica l’immagine |
| Tenere un log delle generazioni indicizzato tramite hash del contenuto | prova di conformità, obbligo cinese di conservazione per sei mesi | storage, nessuna elaborazione per file | indipendente dal file |
| Watermark impercettibile | il livello che resiste alle trasformazioni | esistono encoder open source, ma non c’è uno standard interoperabile, quindi nessun altro può verificare il vostro | n/a |
La firma offline e quella nel percorso API sono la stessa operazione eseguita sugli stessi byte; cambia l’identità indicata dalla firma. Firmando nel gateway, è il gateway ad attestare l’origine del file. Firmando nell’applicazione, siete voi a farlo, con il vostro certificato e la vostra gestione delle chiavi. Se l’obbligo consiste nel dichiarare che il vostro prodotto ha generato qualcosa con l’AI, l’attestazione va collocata dove ricade quell’obbligo.
Un controllo non richiede alcuna modifica ai file, ed è quello che i team tendono a dimenticare: il log delle generazioni. La Cina impone ai provider che consegnano contenuti senza un’etichetta visibile, come fanno tutte le API, di conservare per almeno sei mesi i dati su chi li ha ricevuti. Il log permette inoltre di dimostrare la conformità dopo che il file ha attraversato una pipeline. Se registrate già request ID, modelli e timestamp, quasi sempre manca l’hash dei byte consegnati, necessario per associare una voce a un file che nel frattempo ha perso i metadata.
FAQ
I modelli cinesi per la generazione di immagini marcano l’output?
Sì, ma non con C2PA. Gli SKU qwen-image e wan2.7 di Alibaba integrano l’etichetta implicita definita da GB 45438-2025: un campo nei metadata che contiene il codice societario registrato del produttore, un ID del contenuto e un valore di firma. Gli SKU seedream di ByteDance fanno il contrario: integrano C2PA, ma non l’etichetta cinese. Nessuno degli 11 SKU per immagini includeva entrambi.
Una marcatura C2PA sopravvive se la pipeline ridimensiona l’immagine?
No, non con i comuni strumenti di elaborazione: il ridimensionamento in Pillow o ImageMagick elimina il manifest C2PA. Il manifest risiede in un chunk personalizzato che entrambe le librerie scartano, anche quando viene chiesto loro di includere tutti i chunk. L’unica procedura supportata consiste nel firmare nuovamente il file trasformato, facendo così risultare la pipeline come firmatario. L’etichetta cinese è invece un normale chunk di testo PNG, che ImageMagick conserva per impostazione predefinita e Pillow mantiene se viene copiato esplicitamente; entrambe le librerie lo perdono durante la conversione in JPEG o WebP.
Un output API senza marcature crea un problema di conformità per me?
Dipende dal fatto che, nel regime applicabile, siate considerati provider o deployer: è una questione da sottoporre ai consulenti legali. Le misurazioni chiariscono però il dato tecnico: se generate parlato o video tramite queste API, oppure immagini tramite gli SKU Alibaba per un pubblico dell’UE, il file non contiene nulla che un verificatore europeo possa riconoscere. Aggiungere una marcatura spetta a voi.
Misurazioni effettuate il 2026-08-22 tramite il gateway Synthorai: 11 SKU per immagini, generati due volte ciascuno e consegnati sia in base64 sia tramite URL, uno SKU video e quattro SKU text-to-speech. Ogni file è stato analizzato alla ricerca di manifest C2PA, campi IPTC e XMP e chunk di etichettatura GB 45438. Le firme C2PA sono state convalidate caricando la trust list ufficiale e confrontandole anche con la lista provvisoria usata dal verificatore pubblico Content Credentials. I test di persistenza hanno eseguito cinque operazioni (ricodifica PNG, ridimensionamento, ritaglio, conversione JPEG e WebP) su un file marcato per ciascuna famiglia, sia con Pillow sia con ImageMagick, incluse le opzioni di entrambe le librerie per conservare i metadata. I dati sugli interventi correttivi derivano dalla firma di un’immagine non marcata con un nostro manifest e dalla successiva analisi prima e dopo la trasformazione. Le righe sulle normative sono letture tecniche dei testi citati, non consulenza legale; i vendor possono modificare senza preavviso il comportamento delle marcature, quindi ripetete le misurazioni prima di fare affidamento su qualsiasi riga.
Articoli correlati della stessa serie: costi della generazione di immagini, misurazioni di Qwen-Image 3.0, prezzi della generazione video, costi degli agenti vocali.