Chi controlla cosa producono gli agenti AI?
Una riflessione su come le organizzazioni strutturate devono ripensare i propri modelli di controllo quando la produzione supera la capacità di comprensione
C’è una domanda che mi gira in testa da settimane, una di quelle domande che ti vengono alle undici di sera quando stai ripensando a tutto quello che è stato prodotto durante la giornata. La domanda è semplice, quasi banale nella sua formulazione: come governiamo ciò che non riusciamo più a leggere?
Non parlo in astratto. Parlo di quello che succede ogni giorno nelle organizzazioni che usano agenti ai. Parlo di pull request che contengono modifiche generate automaticamente, di documenti di specifica co-scritti con Claude, di configurazioni suggerite da sistemi che comprendono l’infrastruttura meglio di quanto la comprenda chi deve approvarle. Parlo di quella sensazione sottile, quasi impercettibile, di star approvando cose che si capiscono solo in parte.
Il fatto che non esista una risposta pulita a questa domanda è già di per sé significativo. E il fatto che la stessa domanda venga posta sempre più spesso, nei consigli di amministrazione, negli uffici legali, nei team di compliance, suggerisce che stiamo attraversando un punto di non ritorno. Non un’evoluzione graduale. Un punto di non ritorno.
La governance tradizionale si regge su un presupposto così radicato da essere diventato invisibile: che ci sia tempo sufficiente per capire cosa è stato prodotto prima che venga messo in produzione. Revisione del codice. Audit dei documenti. Approvazione dei contratti. Validazione delle analisi. Firma sui deliverable. Tutto questo ha funzionato per decenni perché il collo di bottiglia era la produzione. Il tempo necessario per creare qualcosa era sufficientemente lungo da permettere al processo di validazione di stargli dietro.
Ma quando un sistema AI genera in minuti quello che prima richiedeva settimane, quel presupposto crolla. Non si piega, non si adatta: crolla. E questo non riguarda solo il codice. Riguarda tutto.
Penso ai documenti contrattuali. Un agente ai può oggi redigere bozze di contratti, clausole specifiche, risposte a contestazioni, pareri preliminari. La qualità è spesso sufficientemente plausibile da superare una lettura veloce. Ma sufficientemente plausibile in ambito legale può significare clausole che sembrano tutelanti ma non lo sono, riferimenti normativi obsoleti presentati con sicurezza, omissioni che emergono solo in caso di contenzioso. Il rischio non è l’errore macroscopico. È la sottigliezza dell’errore in un contesto dove la sottigliezza è tutto.
Penso alle analisi finanziarie. Dashboard, proiezioni, analisi di scenario, business case. Un CFO che riceve un’analisi generata o co-generata da AI sta approvando qualcosa che comprende? O sta validando la plausibilità superficiale di numeri che seguono una logica che nessuno ha realmente verificato? Il problema non è se i numeri tornano. Il problema è se le assunzioni sottostanti sono corrette, se i modelli applicati sono appropriati, se le fonti dati sono affidabili. Tutte cose che richiedono competenza di dominio per essere valutate, competenza che il processo di review presuppone ma che la velocità di produzione rende sempre più difficile applicare.
Penso alle comunicazioni esterne. Email a clienti, risposte a bandi, documentazione di prodotto, manuali d’uso, policy interne. Ogni organizzazione produce quotidianamente migliaia di artefatti testuali. Quando una parte significativa di questi viene generata o assistita da AI, chi garantisce la coerenza con il posizionamento aziendale? Chi verifica che una risposta a un cliente non crei aspettative che poi l’organizzazione non può soddisfare?
E poi c’è la compliance. Qui il paradosso è massimo. Siamo nel pieno dell’ondata regolatoria europea: AI Act, Cyber Resilience Act, Product Liability Directive, EAA, GDPR che continua a evolversi. Le organizzazioni devono produrre documentazione di compliance, valutazioni di rischio, registri, policy. La tentazione di usare AI per accelerare questa produzione è fortissima. Ma stiamo parlando di documenti che attestano la conformità a norme che, in alcuni casi, riguardano proprio l’uso dell’AI. C’è qualcosa di circolare e perturbante nell’usare un sistema AI per dichiarare che i propri sistemi AI sono conformi alle regole sull’AI.
Il problema non è solo la velocità. È il volume combinato con l’opacità. Un team che usa AI per generare codice, configurazioni, documenti, analisi, comunicazioni, decisioni architetturali produce una quantità di artefatti che nessun processo di review umano può realisticamente coprire al cento per cento. E forse nemmeno al cinquanta. E forse nemmeno al venti, se siamo onesti con noi stessi.
Ma il problema peggiore è un altro: molti di quegli artefatti sono sufficientemente plausibili da passare un controllo superficiale. Il che è quasi peggio che se fossero palesemente sbagliati. Un errore evidente viene intercettato. Un errore plausibile viene approvato, deployato, pubblicato, firmato, e scoperto solo quando produce conseguenze.
Mi rendo conto che stiamo affrontando quello che si potrebbe chiamare un problema epistemologico organizzativo: l’organizzazione sa meno di quello che produce. E il gap si allarga ogni giorno.
Non ho soluzioni definitive. Nessuno le ha, e chi dice di averle probabilmente sta sottovalutando il problema. Ma ci sono alcune direzioni che sembrano sensate, anche se nessuna è risolutiva.
La prima è quella che si potrebbe chiamare il passaggio dal controllo puntuale al controllo strutturale. Se non puoi controllare ogni output, devi controllare il sistema che produce gli output. Significa investire molto di più nella definizione di vincoli a monte, specifiche rigorose, guardrail automatizzati, policy as code, piuttosto che nella revisione a valle. È il senso dello spec-driven development: se la specifica è solida, il range di errore dell’output si restringe. Non si elimina, ma si contiene.
Per i documenti legali, significa template verificati con placeholder chiari, non generazione libera. Per le analisi finanziarie, significa modelli validati con input controllati, non fogli bianchi. Per le configurazioni, significa baseline certificate con variazioni esplicite e giustificate. Il principio sottostante è semplice: sposta l’intelligenza, e quindi la responsabilità, nella definizione del problema, non nella generazione della soluzione.
La seconda direzione riguarda cosa verifichiamo. Non puoi leggere tutto il codice generato. Non puoi rileggere ogni documento. Non puoi ricontrollare ogni analisi. Ma puoi definire invarianti che devono essere rispettati e testarli automaticamente. Per il codice: test automatizzati, type checking, analisi statica, verifiche di sicurezza. Per i documenti: checklist automatizzate, validazione di struttura, controlli di coerenza terminologica. Per le configurazioni: policy di compliance as code, drift detection, validazione pre-deploy.
È un cambio di paradigma: passi dal “ho letto e approvato questo artefatto” a “questo artefatto rispetta queste proprietà verificabili”. Che poi è quello che già facciamo con i test automatizzati nel software. Solo che ora diventa l’unica linea di difesa realistica per tutto.
Il limite è ovvio: le proprietà verificabili sono un sottoinsieme delle proprietà desiderabili. Puoi verificare che un contratto contenga certe clausole, non che sia strategicamente appropriato. Puoi verificare che un’analisi sia internamente coerente, non che le assunzioni siano corrette. Ma è comunque molto meglio di niente.
La terza direzione è forse la più scomoda da accettare: AI che controlla AI. Reviewer automatici. Validatori specializzati. Sistemi che verificano l’output di altri sistemi. Il problema ricorsivo è ovvio: chi controlla i controllori? Se non mi fido dell’output dell’AI che produce, perché dovrei fidarmi dell’output dell’AI che verifica?
Ma probabilmente è inevitabile. E la domanda diventa: come mantenere punti di intervento umano nei momenti che contano davvero?
La mia ipotesi, ancora da verificare sul campo, è che il ruolo umano si sposterà verso le decisioni architetturali, le scelte etiche, la gestione delle eccezioni, la calibrazione dei sistemi di controllo. È un ruolo diverso. Meno operativo, più strategico. Meno fare e più decidere le regole del fare.
Cosa mi preoccupa di più in tutto questo? Non è tanto il rischio tecnico. I bug si trovano. Gli errori nei documenti emergono. Le configurazioni sbagliate si manifestano. Quello che mi preoccupa è il rischio organizzativo: team che si abituano a fidarsi degli output senza capirli, che perdono gradualmente la capacità di valutare cosa stanno approvando.
Lo vedo già. Sviluppatori che accettano codice generato senza leggerlo. Manager che approvano analisi senza verificare le assunzioni. Responsabili compliance che firmano documenti che hanno solo scorso. È comprensibile, siamo tutti sotto pressione, tutti con più cose da fare di quante ne possiamo gestire. Ma è anche pericoloso.
La governance più importante forse non è quella sui sistemi, ma quella sulle competenze delle persone che dovrebbero governarli. Se perdiamo la capacità di capire cosa stiamo producendo, perdiamo la capacità di governarlo. Indipendentemente da quanti layer di controllo automatizzato mettiamo in mezzo.
C’è poi una questione che in Italia, e in Europa con l’ai Act, diventa particolarmente pressante: chi è responsabile? Quando un contratto generato da ai contiene un errore che causa un danno, chi risponde? L’operatore che l’ha usato? Il fornitore del sistema AI? Il manager che ha approvato? L’organizzazione nel suo complesso? Quando una configurazione suggerita da AI crea una vulnerabilità di sicurezza, la catena di responsabilità diventa improvvisamente molto importante.
Il framework normativo europeo sta cercando di dare risposte. L’AI Act definisce obblighi per fornitori e deployer. La Product Liability Directive estende la responsabilità per prodotti difettosi. Il Cyber Resilience Act introduce requisiti di sicurezza by design. Ma la verità è che la normativa corre dietro alla tecnologia, e nel frattempo le organizzazioni devono prendere decisioni. Decisioni che avranno conseguenze legali basate su regole che ancora non sono completamente chiare.
Quello che si può fare è costruire traceability. Sapere quali artefatti sono stati generati o influenzati da AI, con quali prompt, in quali condizioni. Non risolve il problema della responsabilità, ma almeno permette di ricostruire cosa è successo.
Scrivo tutto questo e mi rendo conto di quanto sia incerto il terreno su cui ci muoviamo tutti. Ci sono principi operativi che sembrano sensati: presunzione di controllo strutturale, invarianti espliciti, tracciabilità obbligatoria, intervento umano strategico, competenza come prerequisito, accettazione dell’incertezza. Ma sono principi in costruzione, imperfetti, in evoluzione, probabilmente destinati a essere superati rapidamente dalla velocità del cambiamento.
E c’è qualcosa di profondamente frustrante in questa situazione. Per anni chi lavora in questo campo ha avuto il compito di trovare soluzioni, dare risposte, avere un piano chiaro. Adesso ci troviamo a navigare un territorio dove le domande sono più chiare delle risposte, dove ogni soluzione apre nuovi problemi, dove la cosa più onesta che si può dire è “non lo so, ma sto cercando di capire”.
Forse è questo il nuovo ruolo di chi governa sistemi complessi: non avere tutte le risposte, ma fare le domande giuste e costruire strutture che permettano di adattarsi quando le risposte cambiano. È meno rassicurante di un framework definito con cinque best practice e tre pillar strategici. Ma è l’unica governance onesta possibile quando il mondo produce più velocemente di quanto riusciamo a capire.
Mi chiedo spesso dove sentono di più la tensione gli altri che sono in mezzo a questa trasformazione. Sulla velocità di produzione, sulla capacità di valutazione, o su qualcosa di completamente diverso che non sto ancora vedendo. Perché forse la cosa che mi preoccupa di più è proprio questa: non sapere cosa non sto vedendo.