Nel 2025 il messaggio proveniente da Shopify sembrava rappresentare perfettamente la nuova frontiera della produttività aziendale: Tobi Lütke, CEO e cofondatore dell’azienda, aveva dichiarato che l’utilizzo dell’intelligenza artificiale sarebbe diventato una baseline expectation e che, prima di richiedere nuove risorse, i team avrebbero dovuto dimostrare di non poter ottenere il risultato desiderato attraverso l’AI.
A settembre 2026 lo stesso Lütke ha raccontato, però, uno degli effetti collaterali di questa trasformazione: all’interno di Shopify hanno iniziato a chiamarle “slop grenades”: contenuti generati rapidamente dall’AI, controllati poco o nulla e poi trasferiti a qualcun altro, che dovrà leggerli, comprenderli, verificarli e magari correggerli.
Non si tratta di una retromarcia sull’intelligenza artificiale. Shopify continua a utilizzarla in modo estremamente esteso e Lütke rimane uno dei sostenitori più espliciti della sua integrazione nei processi aziendali. Quello che sta emergendo è qualcosa di diverso: dopo la fase dell’adozione stiamo entrando nella fase della governance dell’output.
Per anni una delle principali scarsità è stata la capacità di produrre. Scrivere codice richiedeva sviluppatori e tempo, preparare un documento richiedeva competenze e ore di lavoro, analizzare grandi quantità di dati imponeva risorse specializzate.
L’intelligenza artificiale generativa sta comprimendo violentemente questo costo. Un documento che richiedeva ore può essere prodotto in pochi minuti, centinaia di righe di codice possono comparire in pochi secondi e un report tecnico può essere strutturato quasi istantaneamente.
La tentazione è quindi misurare la produttività attraverso la quantità di output generato o il tempo necessario per produrlo. Proprio qui rischiamo di commettere un errore, perché il tempo risparmiato nella produzione non scompare necessariamente dal processo: spesso viene semplicemente trasferito più avanti.
Quando abbassi drasticamente il costo di produzione dell’informazione, puoi far esplodere il costo della sua verifica.
Un dipendente impiega trenta secondi per produrre una mail che prima avrebbe richiesto dieci minuti, mentre chi la riceve continua a doverla leggere e comprenderne il senso. Un developer genera una modifica software complessa in pochi minuti, ma qualcuno dovrà comunque eseguire la code review, testarla, comprenderne gli effetti e decidere se possa entrare in produzione.
Un analista può generare in pochi minuti un report di cinquanta pagine. Qualcuno dovrà comunque stabilire se quelle cinquanta pagine contengano informazioni corrette.
Il risparmio esiste soltanto quando consideriamo l’intero processo.
Potremmo definire questo fenomeno debito di verifica, con una dinamica non troppo distante dal technical debt che conosciamo nello sviluppo software: guadagno velocità oggi introducendo un costo che qualcuno dovrà sostenere domani.
L’AI rende questo meccanismo particolarmente insidioso perché il debito può essere quasi invisibile. Un output generato male non appare necessariamente scadente: può essere formalmente perfetto, grammaticalmente corretto, strutturato bene e assolutamente credibile.
Il problema nasce quando dentro cento informazioni plausibili ne troviamo tre sbagliate, una vulnerabilità difficile da individuare o un’interpretazione apparentemente coerente costruita su una premessa falsa.
Verificare un errore evidente è relativamente semplice. Verificare un errore plausibile richiede competenza.
Questa asimmetria diventa centrale quando l’organizzazione moltiplica la quantità di contenuti prodotti. Se una persona impiegava quattro ore per realizzare un documento e un collega trenta minuti per verificarlo, il costo complessivo era relativamente semplice da determinare. Se la stessa persona utilizza l’AI e produce dieci documenti nello stesso tempo, il suo indicatore individuale di produttività può apparire eccezionale, mentre a valle abbiamo creato ore di attività aggiuntiva.
Non abbiamo necessariamente aumentato la produttività. Potremmo avere semplicemente spostato il collo di bottiglia.
La cybersecurity rende questa dinamica ancora più evidente perché una parte importante del nostro lavoro è già basata sulla validazione. Un SOC raccoglie eventi e deve distinguere il segnale dal rumore, un vulnerability management process produce evidenze che devono essere contestualizzate, mentre penetration test, risk assessment e incident response richiedono continuamente di separare ciò che appare plausibile da ciò che è realmente accaduto.
L’intelligenza artificiale può migliorare enormemente questi processi, ma può anche aumentare la quantità di informazioni che necessitano di verifica. Generare una remediation, una configurazione, una query, uno script o una raccomandazione di sicurezza in pochi secondi non significa che quell’output possa essere utilizzato automaticamente.
OWASP affronta direttamente questo tema attraverso il concetto di Improper Output Handling, cioè l’insufficiente validazione degli output prodotti dai sistemi basati su LLM. Lo stesso approccio emerge nel rischio di Excessive Agency, quando ai sistemi vengono assegnate funzionalità, permessi o autonomia superiori a quanto realmente necessario.
Il passaggio dagli assistenti agli agenti AI rende il problema qualitativamente diverso. Un chatbot che produce una risposta sbagliata genera principalmente informazione errata; un agente collegato a sistemi aziendali può trasformare quella stessa informazione in un’azione.
Qui cambia il blast radius, il ragio d’azione
Una risposta inesatta può essere fastidiosa. Una configurazione modificata autonomamente, una credenziale utilizzata nel contesto sbagliato o un’azione eseguita su un sistema produttivo possono diventare un incidente.
Più riduciamo il costo dell’esecuzione, più dobbiamo aumentare il controllo su ciò che autorizziamo ad essere eseguito.
Definire tutto questo semplicemente come AI slop rischia però di portarci fuori strada, perché trasferisce la responsabilità sulla qualità dello strumento mentre una parte importante del problema riguarda il modo in cui decidiamo di utilizzarlo.
Una mail inutilmente lunga generata da un LLM non nasce perché il modello obbliga qualcuno a inviarla. Una pull request prodotta da un agente senza essere letta non viene approvata autonomamente se abbiamo progettato correttamente il processo. Una policy generata dall’AI non diventa automaticamente una policy aziendale.
Il problema nasce quando confondiamo generazione con completamento del lavoro.
La disponibilità di un output non significa che il processo sia concluso. In molti contesti l’output rappresenta soltanto l’inizio di una fase successiva fatta di validazione, controllo e assunzione di responsabilità.
Questo principio diventerà ancora più importante negli ambienti nei quali gli agenti AI saranno collegati a infrastrutture, repository, ERP, CRM, strumenti di sicurezza o piattaforme cloud. La domanda non sarà più soltanto quanto sia accurato il modello, ma quale livello di errore siamo disposti ad accettare quando quell’errore può trasformarsi automaticamente in un’azione.
Qui si trova probabilmente il punto centrale: stiamo automatizzando la produzione molto più velocemente di quanto stiamo automatizzando la verifica.
Non possiamo risolvere il problema mettendo semplicemente un secondo LLM a controllare il primo, perché rischiamo di costruire una catena nella quale un sistema genera, un altro verifica e un terzo sintetizza senza aver definito dove si trovi realmente il punto di responsabilità.
L’AI può certamente essere utilizzata anche per il controllo, il testing, il confronto tra fonti e l’individuazione delle anomalie, ma deve esistere un livello di assurance coerente con l’impatto che quell’output può produrre.
Il codice destinato alla produzione non può avere lo stesso livello di controllo di una bozza interna. Una modifica alle regole di accesso di un sistema critico non può essere trattata come la sintesi di una riunione, mentre un agente autorizzato a modificare configurazioni deve essere sottoposto a vincoli molto più stringenti rispetto a un sistema che produce soltanto suggerimenti.
La governance dell’AI non dovrebbe quindi limitarsi a stabilire quali strumenti possano essere utilizzati. Dovrebbe definire quanto possiamo delegare, cosa deve essere verificato, con quale livello di assurance e soprattutto chi rimane responsabile del risultato.
Dovremo probabilmente rivedere anche il modo nel quale misuriamo il successo dell’adozione dell’intelligenza artificiale nelle aziende. Numero di prompt, quantità di codice generato, documenti prodotti o ore apparentemente risparmiate sono metriche facili da raccogliere, ma descrivono soltanto una parte del processo.
La produttività reale dovrebbe considerare il costo complessivo dell’output, includendo generazione, verifica, correzione, manutenzione ed eventuale gestione degli errori.
Nel software significa arrivare fino al costo di mantenimento del codice generato. Nella cyber security significa considerare anche il rischio introdotto da una decisione errata. Nei processi aziendali significa misurare quanto lavoro viene effettivamente eliminato e quanto viene semplicemente trasferito ad altre persone.
L’intelligenza artificiale non elimina necessariamente il lavoro. Elimina soprattutto il costo necessario per produrre qualcosa che sembri lavoro.
Le organizzazioni capaci di governarla non saranno necessariamente quelle che produrranno più contenuti, più codice o più analisi, ma quelle che riusciranno a mantenere sotto controllo il rapporto tra velocità di generazione e costo della verifica.
Per decenni abbiamo considerato l’informazione una risorsa scarsa e costosa da produrre. L’intelligenza artificiale la sta trasformando in qualcosa di abbondante, velocissimo e progressivamente economico.
La vera scarsità potrebbe quindi spostarsi altrove: nella competenza necessaria per stabilire cosa sia corretto, cosa sia affidabile, cosa possa essere utilizzato e di cosa qualcuno sia disposto ad assumersi la responsabilità.
Quando produrre diventa quasi gratuito, verificare diventa il vero valore.