Quando l'AI agisce, non basta etichettare l'output

Dal 2 agosto 2026 si applicano gli obblighi di trasparenza dell'articolo 50 dell'AI Act: i provider di sistemi generativi devono marcare i contenuti sintetici in formato leggibile dalle macchine, e i deployer devono segnalare deepfake e testi di interesse pubblico generati dall'AI, con eccezioni. Solo la marcatura dei sistemi già sul mercato prima del 2 agosto ha tempo fino al 2 dicembre 2026. È un obbligo preciso e verificabile sull'etichetta del contenuto: questo testo, questa immagine, questo audio ha un'origine artificiale. Ma un numero crescente di sistemi non si limita più a generare un output che una persona poi legge o guarda: agisce, attraverso strumenti, basi dati e applicazioni, per conto di un utente o di un'organizzazione. Quando questo accade, sapere che un contenuto è stato generato dall'AI non risponde più alla domanda che conta davvero: chi ha autorizzato quella specifica azione, e come lo si dimostra a distanza di tempo.

Le linee guida della Commissione europea sull'articolo 50, pubblicate il 20 luglio 2026, restano circoscritte alla trasparenza dei contenuti: informare che si sta interagendo con un sistema AI, marcare in formato leggibile dalle macchine i contenuti sintetici, segnalare deepfake e testi di interesse pubblico. Il Regolamento (UE) 2026/1744 — il Digital Omnibus on AI — ha esteso al 2 dicembre 2026 solo l'obbligo di marcatura dei contenuti per i sistemi già sul mercato prima del 2 agosto: non un rinvio generale dell'articolo, e non un obbligo che riguardi il comportamento di un agente. La norma disciplina cosa viene mostrato all'utente finale su un contenuto. Non disciplina — perché non è il suo oggetto — chi ha autorizzato un agente ad accedere a un sistema, eseguire una transazione o modificare un dato.

È qui che la distinzione fra norma e architettura enterprise diventa concreta — ed è una distinzione che va tracciata esplicitamente, perché nessun testo normativo la traccia al posto delle organizzazioni: quando un sistema AI agisce anziché limitarsi a generare, la verificabilità utile non riguarda più solo l'output, ma l'intera catena che porta a un'azione — chi ha delegato quella capacità di agire, con quale identità l'agente si presenta ai sistemi che usa, quali permessi gli sono stati concessi e per quanto tempo, quale traccia resta dell'azione compiuta. Questa è un'inferenza architetturale e manageriale, non un requisito letterale dell'articolo 50: nessuna clausola dell'AI Act obbliga a costruire questa catena. Ma un'organizzazione che dispiega agenti capaci di agire senza costruirla resta esposta a un rischio che la sola conformità all'articolo 50 non copre e non intende coprire.

Che la lacuna sia reale, e non solo un'ipotesi, lo conferma il lato tecnico del problema: il National Cybersecurity Center of Excellence del NIST ha pubblicato il 5 febbraio 2026 un concept paper — non uno standard, una bozza aperta a consultazione pubblica fino al 2 aprile 2026 — per esplorare come i principi di identità digitale già maturi (identificazione, autenticazione, autorizzazione) debbano essere adattati agli agenti software e AI. Il documento pone domande ancora aperte più che fornire risposte: come identificare in modo persistente o effimero un agente, come gestire deleghe «per conto di» fra un umano e un agente, come vincolare l'identità dell'agente a quella della persona che lo ha attivato per un'autorizzazione «human-in-the-loop», come garantire che le azioni restino registrate in modo verificabile e non ripudiabile. Un ente tecnico statunitense e un regolatore europeo dei contenuti stanno lavorando, nello stesso semestre, su facce diverse dello stesso problema: la generazione è già normata, l'azione no.

Tradurre questa distinzione in pratica organizzativa significa presidiare cinque elementi lungo la catena, non uno solo: identità dell'agente, distinta da quella del sistema che lo ospita e da quella dell'utente per conto di cui opera; autorizzazione, idealmente dinamica — i permessi di un agente cambiano se cambiano il suo contesto o gli strumenti a cui accede, non restano fissi come per un account di servizio tradizionale; delega, con un percorso tracciabile da chi ha concesso la capacità di agire a chi materialmente l'ha eseguita; esecuzione osservabile, cioè azioni la cui intenzione dichiarata sia verificabile prima che vengano compiute, non solo dopo; e infine audit non ripudiabile, un registro che resti leggibile anche quando l'agente stesso non esiste più nella sua configurazione originaria. Nessuno di questi cinque elementi è nuovo in assoluto — IAM, data governance e cybersecurity li presidiano da anni per utenti e sistemi tradizionali. Ciò che è nuovo è applicarli a un attore che decide autonomamente quali strumenti usare per raggiungere un obiettivo assegnato.

Il rischio più concreto non è normativo, è organizzativo: trattare questi cinque elementi come una checklist di sicurezza da spuntare invece che come una ridefinizione di chi, nell'organizzazione, risponde delle azioni di un agente. È la stessa domanda che il Decision Layer Framework pone per qualunque decisione che attraversa sistemi diversi — chi decide, chi esegue, chi ne risponde — applicata qui a un esecutore che non è più necessariamente umano. L'articolo 50 non chiede questa riprogettazione, e non la chiederà. Ma un'organizzazione che dispiega agenti capaci di agire deve comunque sapere dove si colloca la responsabilità quando ad agire non è più soltanto una persona.