Le regole esistono già.
L’organizzazione ha deciso che cosa considera accettabile, quali usi richiedono attenzione, dove serve una verifica umana e quali limiti non devono essere superati.
È un risultato importante. Una policy serve proprio a questo: rendere esplicite aspettative, confini e responsabilità che altrimenti resterebbero affidate alle abitudini individuali.
Eppure può rimanere un problema molto concreto.
Il documento dice che un risultato generato dall’AI deve essere controllato da una persona prima di essere usato verso l’esterno.
Ma nel processo reale, dove avviene questo controllo?
Chi lo fa?
Che cosa significa, in pratica, «controllare»?
Il flusso può andare avanti anche se nessuno lo fa?
E, dopo il fatto, esiste qualcosa che permetta di distinguere un controllo reale da un semplice presupposto?
È qui che una regola smette di essere soltanto testo e incontra il lavoro.
Una regola deve incontrare una situazione concreta
Sul sito esiste già una pagina dedicata al problema più ampio: L’AI entra nel lavoro. Chi decide come si usa?.
Lì la domanda riguarda ruoli, autorizzazioni, controlli, eccezioni e responsabilità.
Qui vorrei restringere il campo.
Non partire da tutta la governance dell’AI.
Prendere una regola già esistente e seguirla dentro un solo uso reale.
Per esempio:
«Il risultato dell’AI deve essere verificato da una persona prima dell’utilizzo esterno.»
Sulla carta la frase è comprensibile.
Nel lavoro, però, apre subito altre domande.
Quali risultati rientrano nella regola?
Chi è la persona autorizzata a verificare?
Che cosa deve controllare?
In quale momento?
Può approvare con modifiche? Può fermare il processo?
Che cosa accade nei casi urgenti o non standard?
E come facciamo a sapere che la verifica è avvenuta prima dell’uso esterno?
Non è un esercizio di interpretazione giuridica.
È un passaggio operativo: capire quale cambiamento concreto deve produrre una regola nel modo in cui il lavoro viene svolto.
Prima di applicare la policy bisogna sapere dove l’AI viene usata davvero
Una regola può essere scritta molto bene e riferirsi a una realtà che nel frattempo è cambiata.
Un team inizia a usare un nuovo strumento. Una funzione viene aggiunta a un prodotto esistente. Una persona usa un servizio consumer invece di quello aziendale. Un’automazione acquisisce un’azione che prima non esisteva. Una limitazione viene tolta per risolvere un problema temporaneo e poi nessuno la ripristina.
Per questo, prima ancora di chiedere se le regole sono rispettate, serve una fotografia abbastanza concreta degli usi reali.
Non necessariamente un inventario perfetto dell’intera organizzazione.
Basta, per iniziare, rispondere a domande semplici:
- dove viene usata l’AI;
- da chi;
- per quale compito;
- con quali dati o materiali;
- quale risultato viene prodotto;
- chi lo usa dopo;
- quali azioni il sistema può compiere da solo.
Se questa mappa è sbagliata o incompleta, anche una policy corretta può restare appesa a processi che non esistono più.
Riscrivere il documento, in quel caso, non risolve lo scarto.
Prima bisogna ritrovare la realtà a cui la regola dovrebbe applicarsi.
«C’è controllo umano» non dice ancora quando il controllo può funzionare
Molte policy contengono formule ragionevoli:
la persona controlla il risultato;
una decisione finale resta umana;
certe azioni non possono avvenire senza approvazione;
il sistema non deve agire in autonomia in determinati casi.
Ma la presenza di questa frase non crea automaticamente la possibilità di intervenire.
Torniamo all’esempio del documento.
Se il sistema può generare e inviare automaticamente il documento, ma la policy richiede una verifica prima dell’invio, occorre individuare un punto in cui il flusso si ferma davvero.
Se invece il documento viene sempre consegnato a una persona e l’invio è manuale, il meccanismo può essere più semplice.
Anche lì, però, resta una domanda: il controllo è un passaggio necessario oppure si presume soltanto che la persona «dia un’occhiata»?
La distinzione che conta è questa:
scrivere che una persona deve poter intervenire e costruire un processo in cui può davvero intervenire sono due cose diverse.
Se l’intervento deve avvenire prima di un’azione irreversibile, deve esistere un momento in cui quell’azione non è ancora avvenuta.
Se serve un’approvazione, bisogna capire se il sistema può comunque procedere senza approvazione.
Se esistono eccezioni, bisogna sapere che cosa accade quando si entra in una di esse.
A quel punto la domanda non è più «la policy è scritta bene?».
Diventa:
che cosa deve cambiare, concretamente, nel processo grazie a questa regola?
Verificare la regola non significa verificare la qualità del risultato
Immaginiamo che il documento finale sia ottimo.
È corretto, chiaro e viene usato senza problemi.
Questo dimostra che il controllo umano previsto dalla policy è avvenuto?
No.
Possiamo ottenere un buon risultato anche se il controllo richiesto non è mai avvenuto.
E possiamo avere una traccia perfetta dell’approvazione e, nonostante questo, ottenere un risultato mediocre.
Sono due verifiche diverse.
La prima riguarda il risultato.
La seconda riguarda il funzionamento della regola.
Per una regola che richiede una verifica umana, quindi, serve qualche elemento osservabile che permetta di capire se quella persona è intervenuta nel momento previsto.
Non significa raccogliere log su tutto o costruire un apparato di controllo sproporzionato.
Significa soltanto poter rispondere a una domanda:
che cosa distingue il caso in cui questa regola ha funzionato dal caso in cui il processo è andato avanti senza di essa?
In un sistema può essere uno stato del documento.
In un altro una conferma nel flusso di lavoro.
In un altro ancora un passaggio manuale obbligatorio.
La forma dipende dal rischio, dal processo e dalla tecnologia.
Il principio no: se una regola è importante, deve esistere un modo ragionevole per riconoscerne l’effetto nel lavoro reale.
Anche una limitazione tecnica ha uno stato, non soltanto un nome
C’è un altro motivo per cui policy e pratica possono separarsi senza che nessuno decida esplicitamente di ignorare la regola.
Le configurazioni cambiano.
Una limitazione può essere rimossa temporaneamente. Un permesso viene allargato. Una nuova integrazione sostituisce quella precedente. Un modello o una funzione acquisiscono capacità diverse. Un passaggio che prima si fermava viene automatizzato.
Nella mia esperienza pratica ho notato una cosa molto semplice: togliere un limite per far funzionare una singola attività può essere veloce. Ricordarsi di ripristinarlo dopo è un altro lavoro.
Non è una legge generale sulle organizzazioni.
È però un buon esempio del motivo per cui una frase come «il sistema non ha accesso a X» non andrebbe trattata come una proprietà eterna.
Può descrivere una configurazione presente in un certo momento.
Se la policy conta su quella configurazione, bisogna sapere che esiste ancora.
Qui compaiono tre livelli distinti:
sappiamo che un limite è richiesto;
sappiamo con quale meccanismo viene applicato;
verifichiamo che quel meccanismo sia ancora nello stato atteso.
Il documento stabilisce la norma.
Il sistema, invece, ha uno stato che può cambiare.
Tra i due serve un modo per mantenere il collegamento.
Se la pratica non coincide con la policy, non sappiamo ancora perché
Davanti a uno scarto è facile arrivare subito a una conclusione: le regole esistono, quindi qualcuno non le sta rispettando.
Può essere vero.
Ma lo scarto, da solo, non lo dimostra.
La regola potrebbe non essere stata collegata a nessun passaggio concreto.
Potrebbe essere cambiato l’uso dell’AI.
Il controllo umano potrebbe esistere soltanto come aspettativa, senza un punto del processo che ne dipenda.
Una configurazione potrebbe essere stata modificata.
Oppure la regola potrebbe essere applicata correttamente, ma senza alcun modo di mostrarlo dopo.
Sono problemi diversi e richiedono interventi diversi.
Se è cambiata la mappa degli usi, riscrivere la policy non ricostruisce da sola ciò che accade.
Se la regola è chiara ma non compare in nessun passaggio operativo, altra formazione non crea automaticamente quel passaggio.
Se il meccanismo esiste ma non è osservabile, il problema non è uguale né a una regola sbagliata né alla sua violazione.
E se il requisito non è più chiaro o non corrisponde al contesto, allora sì, può essere necessario rivedere il documento con le competenze appropriate.
Prima di decidere il rimedio, quindi, cercherei di capire dove si sono separati tre elementi: la regola scritta, il meccanismo di lavoro e la possibilità di vedere che quel meccanismo ha funzionato.
Non ogni regola deve diventare un blocco tecnico
Da questo ragionamento si potrebbe ricavare una conclusione troppo forte: se una policy è seria, ogni regola deve essere «codificata» nel sistema e impedire tecnicamente qualsiasi comportamento diverso.
Non è ciò che intendo.
Ci sono regole che richiedono una barriera tecnica.
Altre funzionano bene attraverso responsabilità e procedure chiare.
Alcune dipendono, per definizione, da una valutazione professionale che non può essere ridotta a un controllo automatico.
E ci sono contesti in cui costruire un meccanismo complesso sarebbe sproporzionato rispetto al rischio e alla scala dell’uso.
L’obiettivo non è massimizzare i controlli.
È un obiettivo più semplice:
se una regola è importante, ha una forma reale nel lavoro a cui si riferisce?
Possiamo partire dalla frase scritta, arrivare a uno scenario concreto, trovare il punto di decisione o di limite e dire che cosa deve accadere lì?
A volte basta questo per scoprire un piccolo buco.
A volte emerge che la parte operativa non è mai stata progettata.
A volte scopriamo che tutto funziona già in modo ragionevole, ma nessuno aveva mai collegato esplicitamente il processo alla regola scritta.
In nessuno di questi casi una policy più lunga è automaticamente la risposta.
Dove finisce il lavoro operativo
Questo tipo di analisi non risponde alla domanda giuridica: l’organizzazione è conforme all’AI Act? Un determinato obbligo si applica? Le misure scelte sono sufficienti dal punto di vista legale, privacy o sicurezza?
Sono verifiche diverse e richiedono competenze specifiche.
Per orientare le domande iniziali sull’AI Act esiste una risorsa separata: Checklist AI Act 2026.
Qui il problema è un altro e viene dopo, o accanto, a un requisito già definito:
come facciamo a collegarlo al modo in cui l’AI viene realmente usata?
La pagina Come usare l’AI in azienda descrive questo territorio in modo più ampio: ruoli, autorizzazioni, controlli, eccezioni e responsabilità.
Per lavorare su un caso concreto, però, non partirei da tutta la lista.
Prenderei una sola regola esistente e la attraverserei da capo a fondo.
Dove deve funzionare?
A quali usi si applica?
Chi deve fare che cosa?
Il processo può andare avanti senza quel passaggio?
Che cosa succede in un caso non standard?
E che cosa ci permette, dopo, di capire che la regola ha avuto davvero un effetto?
È a quel livello che diventa visibile ciò che manca: testo, processo, collegamento con un uso concreto oppure una forma di evidenza ragionevole.
La policy è già scritta. La domanda successiva è: dove vive?
Le regole sull’uso dell’AI servono.
Danno forma all’intenzione dell’organizzazione e stabiliscono confini che, senza un documento, rischierebbero di restare impliciti.
Ma una frase non si trasferisce da sola in ogni punto del lavoro.
Dopo «che cosa abbiamo scritto?» arriva quindi una domanda più concreta:
dove vive questa regola nel lavoro reale?
Non genericamente «nella cultura aziendale».
In uno specifico utilizzo dell’AI.
In un’azione.
In un momento in cui qualcosa deve fermarsi, richiedere una persona, cambiare stato oppure non poter succedere senza conferma.
E poi una seconda domanda:
che cosa ci permette di distinguere una regola che ha funzionato da una regola che esiste soltanto nel documento?
Se la policy c’è già ma questo passaggio non è ancora chiaro, non è necessario partire da un audit completo o da un grande progetto di governance.
Si può iniziare da un’unica regola e da un unico processo reale.
È spesso abbastanza per capire se il problema è nel testo, nel meccanismo, nel collegamento fra i due — oppure in un requisito che deve essere chiarito da un’altra competenza.
Continua / nel sistema