La tesi in una frase: una policy che non si può eseguire non è una policy, è una dichiarazione di non responsabilità. Serve a mostrarla in un audit e non serve a cambiare quello che il sistema fa il martedì pomeriggio. La differenza tra le due cose non è il rigore con cui è scritta: è se qualcuno ha tradotto ogni frase in una condizione che una macchina può verificare prima di lasciar uscire un’azione.
Una policy aziendale sull’uso dell’IA che non si può eseguire non è una policy
Lo schema si ripete in tutte le aziende che hanno già superato la fase dell’entusiasmo. Qualcuno redige la policy aziendale sull’uso dell’IA — sei pagine, scritte bene, riviste dal legale —, la carica sulla intranet, la comunica via mail e considera chiusa la questione. Tre mesi dopo ci sono agenti che scrivono ai clienti, impegnano importi e pubblicano affermazioni sul prodotto, e nessuna di quelle azioni passa da qualcosa che assomigli a quello che dice il documento. Non perché qualcuno lo violi apposta: perché il documento non è mai stato collegato a niente.
Il genere letterario è saturo della parte facile. Ci sono template, checklist e guide su cosa documentare: ambito, ruoli, usi vietati, classificazione del rischio, responsabile. Tutto questo è necessario e nessuno di quei testi spiega la parte che costa, cioè questa: come quella frase scritta in italiano diventa una verifica che gira in produzione e che può fermare un’azione. Quel salto è il lavoro vero, ed è quello che quasi mai si fa.
Conviene dirlo senza giri di parole perché ci sono soldi di mezzo: una policy che esiste solo in PDF non ti protegge da niente salvo, con fortuna, da una parte della responsabilità. Non evita l’errore, non lo rileva e non lascia traccia del fatto che si è provato a evitarlo. Se vuoi che l’IA si comporti, il documento va portato giù di tre livelli: da principio a regola, da regola a condizione verificabile, e da condizione a evidenza.
Passo 1: scomporre l’obbligo in condizioni verificabili
Prendi ogni frase della policy e falle una sola domanda: cosa dovrebbe essere vero, in un’azione concreta, perché questa frase risulti rispettata? Se la risposta è lunga, ambigua o dipende dal criterio di chi guarda, la frase non è ancora una regola: è un’intenzione. Va spezzata finché ogni pezzo è verificabile con un sì o un no.
Un esempio tipico. «L’IA sarà usata in modo trasparente con i clienti» non è verificabile. Scomposta, diventa tre condizioni che invece lo sono: in ogni conversazione avviata da un sistema automatico, il primo messaggio dichiara che è un sistema automatico; in qualsiasi canale in cui il cliente possa chiedere una persona, esiste una via visibile per farlo; e nessun messaggio afferma o lascia intendere che lo scrive una persona precisa del team. Tre condizioni, tre verifiche possibili. Il principio originale è ancora lì, ma adesso si può cablare.
Due avvertenze su questo passo. La prima: la scomposizione è il punto in cui si prendono le decisioni difficili, non la stesura del principio. «Trasparente» suona come se fossimo tutti d’accordo; «il primo messaggio dichiara che è un sistema automatico» apre una discussione vera su marketing, conversione e tono. Quella discussione va fatta, e farla qui costa molto meno che farla dopo un incidente. La seconda: se un obbligo non si può scomporre in condizioni verificabili, scrivilo lo stesso. Ci sono obblighi che si rispettano solo con giudizio umano, e segnarli come tali è informazione utile, non un fallimento.
Passo 2: decidere con quale evidenza si verifica ogni condizione
Una condizione senza evidenza assegnata è una condizione che nessuno verifica. E qui compare il bias che rovina la maggior parte dei tentativi: se l’evidenza la sceglie chi deve implementarla, sceglierà quella facile da ottenere, non quella che dimostra davvero la conformità. È umano ed è prevedibile, quindi si corregge per progetto.
Per ogni condizione vanno fissate tre cose: quale dato la dimostra, in quale momento si guarda e chi risponde se manca. L’evidenza può essere semplicissima — il testo del primo messaggio inviato, l’importo del campo dell’operazione, l’elenco delle fonti che il sistema ha usato per scrivere —, e più è semplice, meglio è: una verifica che funziona solo se tutta la pipeline è sana non è una verifica, è una speranza.
Il momento conta quanto il dato. Non è lo stesso verificare prima di eseguire — il sistema si ferma e non succede niente — o verificare dopo — il sistema agisce e tu lo scopri —. Sono entrambe valide e non costano uguale. La regola pratica: tutto ciò che è irreversibile o visibile per il cliente si verifica prima; il resto può verificarsi dopo, purché ci sia qualcuno che guarda il registro e un termine scritto per guardarlo. I meccanismi che rendono possibile tutto questo — registro, permessi con ambito, freno a mano e audit — sono sviluppati in governance e controllo dell’automazione con IA; quello che qui aggiungiamo è il piano di sopra: cosa si verifica e perché, non con cosa si verifica.
Passo 3: definire cosa succede quando fallisce
Questo è il passo che quasi nessuno scrive ed è l’unico che decide se il controllo esiste davvero. Una verifica senza conseguenza definita finisce sempre nello stesso posto: un alert su un pannello che nessuno apre. Per ogni condizione bisogna decidere, in anticipo, una di quattro risposte: si blocca l’azione, si scala a una persona con il caso già montato, si registra e si lascia passare, oppure si degrada a una versione più conservativa della stessa azione.
Scegliere «bloccare» per tutto è un progetto sbagliato quanto scegliere «registrare» per tutto. Bloccare tutto rende il sistema inutile e l’organizzazione impara in fretta a scavalcarlo; registrare tutto produce un archivio perfetto di inadempienze che nessuno ha letto. La domanda che ordina la scelta è quella di sempre: quanto costa l’errore e quanto ci mette a vedersi. Errore caro e visibile, scalare. Errore caro e invisibile, bloccare. Errore economico e visibile, registrare. E una condizione extra che si dimentica: la risposta «scalare» è legittima solo se c’è capacità umana reale per gestire quel volume. Se scali più casi di quanti il tuo team può guardare, la coda viene approvata in blocco senza leggere, che è peggio di non avere controllo, perché in più genera un registro falso di revisione. È esattamente il problema che si affronta in supervisione umana dell’IA su scala.
Tre esempi concreti ed economici da cui partire
Non serve cablare l’intera policy perché l’esercizio valga la pena. Tre controlli ben scelti coprono la maggior parte del rischio reale di un’azienda che inizia, e tutti e tre si implementano in giorni, non in trimestri.
- Dichiarare che è IA. Condizione: ogni conversazione avviata o sostenuta da un sistema automatico dichiara di esserlo nel primo messaggio. Evidenza: il testo inviato. Momento: prima di inviare. Fallimento: si blocca l’invio. Oltre a essere la cosa giusta, dal 2 agosto 2026 c’è un obbligo di trasparenza europeo applicabile ai sistemi destinati a interagire direttamente con le persone, che devono essere progettati in modo che la persona sappia di stare interagendo con un’IA, salvo che risulti ovvio. Fonte: Commissione europea, Transparency obligations under Article 50 of the AI Act (regolamento (UE) 2024/1689), consultato il 14 settembre 2026. Conviene guardarlo con il tuo consulente: l’ambito e la figura che ti si applica — fornitore o deployer — dipendono dal tuo caso, e questa non è consulenza legale.
- Limite di importo che un agente può impegnare. Condizione: nessuna azione che impegna denaro supera la soglia fissata per operazione e per giorno. Evidenza: l’importo del campo, più un cumulato giornaliero. Momento: prima di eseguire. Fallimento: scala a una persona con il caso montato. È il controllo più economico di tutti e quello che più gente scopre tardi, di solito dopo il primo spavento.
- Affermazioni che richiedono una fonte approvata. Condizione: qualsiasi messaggio al cliente che contenga un dato di prodotto, prezzo, tempistica o condizione si appoggia a una fonte di un elenco approvato. Evidenza: le fonti che il sistema ha recuperato per scrivere. Momento: prima di inviare. Fallimento: degrada — il sistema manda una risposta senza quel dato e offre il passaggio a una persona — invece di bloccare, che qui sarebbe esagerato.
Nota cosa hanno in comune: tutti e tre si esprimono in una riga, tutti e tre hanno un’evidenza ovvia e tutti e tre hanno una conseguenza diversa. Quell’asimmetria è il segnale che l’esercizio è stato fatto bene. Se finissero tutti e tre in «bloccare», vuol dire che nessuno si è fermato a pensare al costo di ogni errore. L’ambito di ciò che l’agente può toccare per iniziare è un’altra decisione di questo stesso esercizio, e sta in quali permessi dare a un agente di IA.
L’errore caro: lasciare che la policy la scriva solo l’ingegneria
Quando la traduzione da policy a controllo viene delegata interamente al team tecnico, succede una cosa perfettamente ragionevole e perfettamente sbagliata: si finisce per verificare quello che è facile verificare, non quello che la policy obbliga. Il risultato ha un bell’aspetto — ci sono regole, ci sono registri, ci sono pannelli — e lascia fuori proprio quello che conta di più, perché quello che conta di più quasi mai è il più misurabile.
Si vede nei dettagli piccoli. Si verifica che il messaggio non superi una lunghezza, e non che non prometta una tempistica che non puoi rispettare. Si verifica che la risposta citi una fonte, e non che la fonte sia approvata. Si verifica che l’operazione abbia un importo, e non che quell’importo rispetti il limite deciso da qualcuno in un comitato. Ognuna di quelle verifiche è corretta e nessuna è quella che la policy chiedeva.
L’antidoto è di processo, non di tecnologia: la scomposizione del passo 1 la fa chi è proprietario dell’obbligo — business, legale, operations — e l’evidenza del passo 2 si concorda tra quella persona e chi la implementerà. L’ingegneria ha diritto di veto sull’impossibile e non sullo scomodo. E il documento finale si firma dai due lati, con data. Senza quella firma incrociata, quello che hai non è una policy eseguibile: è un elenco di ciò che è risultato comodo misurare.
C’è una sfumatura di ordine che conviene rispettare, e va contro quello che sembra ovvio: la policy non si scrive per prima. Si scrive quando sai già cosa stai regolando, e lo scopri guardando quello che la tua gente fa già con l’IA senza chiedere permesso — l’argomento completo sta in perché vietare lo shadow AI non funziona —. Una policy redatta prima di quell’inventario regola un’azienda immaginaria.
Come si vede una policy eseguibile quando è finita
Non assomiglia a un documento legale. Assomiglia a una tabella, e sta in una pagina per ogni area. Ogni riga ha sei colonne: l’obbligo da cui nasce, la condizione verificabile, l’evidenza, il momento in cui si guarda, cosa succede se fallisce, e chi risponde. Sotto, un elenco a parte con gli obblighi che hai deciso non essere automatizzabili e che quindi dipendono da una persona, con il suo nome e la sua cadenza di revisione.
Quella tabella ha una proprietà che il PDF non ha: si può auditare contro la realtà. Prendi una riga, prendi un caso della settimana scorsa e verifichi se la condizione è stata valutata, con quale evidenza e cosa è successo. O esce il registro, o la riga è una bugia. È una prova di cinque minuti ed è l’unico modo onesto di sapere se la tua policy aziendale sull’uso dell’IA è viva o è decorazione.
E ne ha un’altra: invecchia in modo visibile. Quando cambia un obbligo, cambia una riga e si vede quali controlli toccare. Quando cambia il PDF, non cambia niente, perché non era collegato a niente. Per questo il deliverable che lasciamo in Adozione IA per team non è il documento: è quella tabella, con owner e data di revisione, e i controlli del primo tratto già montati. Il documento serve ancora — bisogna poterlo mostrare —, ma è la conseguenza del lavoro, non il lavoro.