TL;DR: dal 2 agosto 2026 l’Articolo 50 dell’AI Act rende operative nuove regole di trasparenza per chatbot, contenuti sintetici e alcuni usi professionali dell’AI. Per una PMI il lavoro utile non è aggiungere un’etichetta generica a tutto. Serve distinguere il proprio ruolo, mappare i casi d’uso e inserire controlli verificabili nel workflow WordPress.

Il 2 agosto 2026 non scatta un obbligo indistinto di scrivere “generato con AI” su ogni pagina. Scattano regole diverse per provider e deployer, con eccezioni precise. Le linee guida della Commissione europea sull’Articolo 50, aggiornate il 29 luglio, separano quattro casi: interazione diretta con un sistema AI, marcatura machine-readable dei contenuti sintetici, riconoscimento delle emozioni o categorizzazione biometrica, deepfake e alcuni testi di interesse pubblico.

La distinzione conta perché una web agency che installa un chatbot per un cliente, un editore che usa un modello per preparare articoli e un’azienda che sviluppa un proprio assistente non hanno lo stesso ruolo. Applicare la stessa soluzione a tutti produce due errori opposti: etichette inutili dove non servono e buchi di trasparenza dove invece l’obbligo è concreto.

Questa è una guida operativa, non un parere legale. L’obiettivo è costruire un controllo tecnico ed editoriale che permetta a una PMI di capire dove intervenire, lasciare evidenze e coinvolgere un consulente legale solo sui casi realmente dubbi.

Cosa cambia davvero il 2 agosto 2026

L’AI Act è applicabile in via generale dal 2 agosto 2026, ma non tutte le scadenze coincidono. Il recente AI Omnibus, entrato in vigore il 27 luglio 2026, ha spostato al 2 dicembre 2027 le regole per i sistemi high-risk dell’Allegato III e al 2 agosto 2028 quelle per l’AI integrata in determinati prodotti. Le regole di trasparenza dell’Articolo 50 restano invece operative dal 2 agosto 2026.

Per chi gestisce siti e automazioni, i casi più frequenti sono questi:

  • un chatbot o agente che dialoga direttamente con visitatori, clienti o dipendenti;
  • un sistema proprietario che genera immagini, audio, video o testo;
  • la pubblicazione professionale di deepfake;
  • la pubblicazione di testo AI su questioni di interesse pubblico senza una revisione umana sostanziale.

Le linee guida chiariscono anche ciò che resta fuori. Un sistema che lavora solo in background, una comunicazione machine-to-machine e il codice sorgente non ricadono automaticamente nello stesso obbligo di marcatura. Anche l’editing standard ha un’esenzione quando l’AI assiste senza modificare in modo sostanziale i dati o il significato dell’input.

La mia lettura è semplice: il problema non è dimostrare di usare poco l’AI. È dimostrare di sapere quale passaggio è automatizzato, chi controlla il risultato e cosa vede la persona esposta.

Primo passo: capire se sei provider o deployer

Il Q&A ufficiale della Commissione definisce provider chi sviluppa un sistema AI, o lo fa sviluppare, e lo mette sul mercato o in servizio con il proprio nome o marchio. Il deployer è invece l’organizzazione che usa il sistema sotto la propria autorità per un’attività professionale.

Questa distinzione cambia il controllo da implementare. Il provider deve progettare il sistema interattivo affinché informi l’utente e, per i contenuti sintetici, deve predisporre marcature machine-readable quando richiesto. Il deployer deve soprattutto gestire la comunicazione visibile nei casi previsti: riconoscimento delle emozioni, categorizzazione biometrica, deepfake e testo AI di interesse pubblico privo di controllo editoriale.

Una PMI può trovarsi in entrambi i ruoli. Se usa ChatGPT o Gemini per preparare una bozza interna, normalmente agisce come deployer. Se vende un chatbot white-label con il proprio marchio, prompt, interfaccia e logica applicativa, deve verificare se il livello di controllo sul sistema la porta nel ruolo di provider. Non basta chiamarsi “integratore” nel contratto.

La norma ha una portata extraterritoriale: l’Articolo 2 del Regolamento (UE) 2024/1689 include provider e deployer stabiliti fuori dall’Unione quando l’output del sistema è usato nell’UE. Per un’impresa svizzera che serve clienti o utenti nell’Unione, la sede in Svizzera non chiude quindi il tema.

Chatbot sul sito: la disclosure va nella prima interazione

Per un chatbot WordPress il requisito operativo è comprensibile: la persona deve sapere che sta interagendo con un sistema AI, salvo che sia già ovvio nel contesto. La Commissione chiede che l’informazione sia chiara e distinguibile fin dall’inizio della prima interazione e conforme ai requisiti di accessibilità.

Una dicitura utile può essere: “Assistente virtuale basato su AI. Le risposte possono contenere errori; per pratiche o decisioni vincolanti interviene una persona.” È più utile di un generico badge “AI” perché chiarisce natura e limite del canale. Va mostrata nel pannello prima del primo messaggio, non nascosta nella privacy policy o in un tooltip che nessuno apre.

Implementazione minima su WordPress

  • inserire la disclosure nel markup iniziale del widget, prima del campo di input;
  • renderla leggibile da tastiera e screen reader, senza affidarsi solo a colore o icona;
  • registrare versione del testo, data di rilascio e owner interno;
  • prevedere un’escalation umana per richieste commerciali, reclami o dati sensibili;
  • verificare dopo ogni aggiornamento del plugin che il messaggio non sia stato rimosso o spostato.

Se il chatbot è incorporato tramite script di un fornitore, la responsabilità tecnica non si esaurisce con il copia-incolla. Il contratto dovrebbe indicare chi gestisce disclosure, log, conservazione dei dati e modifiche al modello. Sul sito serve comunque una verifica reale del widget servito agli utenti.

Immagini e video AI: metadato tecnico e avviso visibile non sono la stessa cosa

L’Articolo 50 distingue due livelli. I provider di sistemi generativi devono rendere gli output identificabili con marcature machine-readable, per quanto tecnicamente fattibile. I deployer che pubblicano un deepfake devono invece informare le persone in modo visibile o percepibile al primo contatto con il contenuto.

La Commissione ha pubblicato icone facoltative per i contenuti generati o modificati con AI. Le icone aiutano, ma non provano da sole la conformità. Per un deepfake non basta neppure confidare nel metadato invisibile incorporato dal modello: la disclosure del deployer deve essere comprensibile senza strumenti tecnici.

In WordPress conviene separare tre dati:

  • provenienza del file, conservata nel media record o nel sistema documentale interno;
  • eventuale marcatura machine-readable già presente nell’asset originale;
  • disclosure visibile, quando il contenuto rientra nei casi previsti.

Non userei l’alt text per dichiarare l’origine AI. L’alt serve a descrivere il contenuto dell’immagine a chi non la vede. Mescolare accessibilità e compliance peggiora entrambe. Se serve una disclosure, meglio una didascalia, un’etichetta adiacente o un componente dedicato, coerente anche nella versione mobile e nei feed social.

Testi AI: la revisione umana deve incidere sul contenuto

Il punto più interessante per chi pubblica su WordPress riguarda i testi destinati a informare il pubblico su materie di interesse pubblico. La Commissione include, tra gli esempi, politica, servizi pubblici, salute, sicurezza, ambiente e sviluppi economici, finanziari, scientifici o culturali rilevanti per il dibattito pubblico.

Questi testi devono essere dichiarati come generati o manipolati con AI quando manca una vera revisione umana o un controllo editoriale. Esiste però un’esenzione quando il contenuto è stato esaminato nella sostanza e una persona fisica o giuridica assume la responsabilità editoriale. Correggere grammatica e refusi non basta. Il revisore deve poter approvare, modificare o respingere tesi, fonti e affermazioni.

Qui WordPress può diventare parte del controllo, non solo il posto dove incollare il testo. Un workflow robusto usa stati e gate separati:

  1. bozza generata o assistita da AI;
  2. fact-check dei claim, con fonti e data della verifica;
  3. reviewer identificato, con esito approvato o respinto;
  4. pubblicazione consentita solo dopo l’approvazione;
  5. log minimo del pacchetto editoriale conservato fuori dal contenuto pubblico.

È lo stesso principio che ho descritto nella guida sulle bozze AI in WordPress: lo status draft è un confine tecnico. Se il gate fallisce, il contenuto non diventa pubblico. Per le automazioni conviene anche validare gli output strutturati prima di inviarli al CMS, come nella procedura per controllare il JSON generato dall’AI.

Un registro minimo che una PMI può mantenere davvero

Un registro utile non deve diventare un foglio da cinquanta colonne che nessuno aggiorna. Deve rispondere a domande operative durante un audit o un incidente.

  • Sistema: nome del servizio, fornitore, versione o piano usato.
  • Ruolo: provider, deployer o punto da verificare.
  • Uso: chatbot, generazione testi, immagini, video, analisi interna.
  • Pubblico esposto: clienti, dipendenti, visitatori o nessuna esposizione diretta.
  • Controllo: disclosure, revisione umana, marcatura, escalation.
  • Evidenza: URL, screenshot, versione del componente, log dell’approvazione.
  • Owner: la persona che deve intervenire quando cambia il sistema.

Partirei dai cinque sistemi con maggiore esposizione, non da ogni funzione AI presente in un software. Chatbot pubblico, generatore di contenuti, automazione che pubblica, strumento HR e sistema che produce immagini commerciali vengono prima del completamento automatico delle email interne.

Il registro va rivisto quando cambia il modello, il fornitore, il canale di pubblicazione o il pubblico. Una revisione annuale non basta se il plugin del chatbot viene aggiornato ogni mese e può modificare interfaccia o comportamento.

Gli errori che vedo più probabili

Il primo è etichettare tutto. Una disclosure onnipresente diventa rumore e non risolve la classificazione del caso d’uso. Il secondo è affidarsi al fornitore senza controllare il frontend reale. Il terzo è chiamare “human in the loop” una correzione ortografica fatta cinque secondi prima del publish.

C’è poi un errore tipico dei progetti WordPress: inserire la compliance in un documento separato e lasciare invariato il flusso tecnico. Se l’editor può saltare il controllo, se il chatbot parte prima di mostrare l’avviso o se il media perde la didascalia nel template mobile, il processo scritto non descrive ciò che succede.

Le sanzioni per violazioni diverse da pratiche vietate e obblighi sui modelli GPAI possono arrivare fino a 15 milioni di euro o al 3% del fatturato mondiale annuo precedente; la Commissione precisa che per PMI e small mid-cap va considerata la proporzionalità. Non è il numero che deve guidare il progetto. È un motivo in più per rendere verificabili controlli che servono comunque a ridurre errori, contestazioni e pubblicazioni opache.

La take: costruire il gate, non il bollino

La conformità più economica è quella che usa controlli già utili al lavoro. Una disclosure iniziale migliora l’aspettativa dell’utente sul chatbot. Una revisione sostanziale riduce allucinazioni e claim sbagliati. Un registro leggero evita di scoprire durante un incidente che nessuno sa quale modello ha prodotto un contenuto.

Per questo non partirei dall’icona da mettere sulla pagina. Partirei dal percorso completo: input, sistema, output, revisore, pubblicazione. L’etichetta viene alla fine, solo quando il caso la richiede. Se il percorso non è documentato, il bollino è decorazione.

Cosa fare questa settimana

  1. elenca i sistemi AI che toccano utenti o contenuti pubblici;
  2. assegna a ciascuno un ruolo e un owner;
  3. aggiungi la disclosure ai chatbot nella prima interazione;
  4. separa provenienza tecnica, alt text e disclosure visibile per i media;
  5. trasforma la revisione editoriale in un gate che può fermare il publish;
  6. conserva un’evidenza minima di versione, controllo ed esito;
  7. porta al legale solo i casi con ruolo, ambito o eccezione ancora incerti.

Il 2 agosto non richiede una corsa a riempire il sito di avvisi. Richiede una mappa affidabile dei punti in cui l’AI parla, genera o pubblica per conto dell’azienda. Quella mappa è il vero lavoro. E resta utile anche quando cambieranno modelli, plugin e linee guida.

Fonti