Vai al contenuto
Liguori
§ 04 | JOURNAL
Costruisco automazioni AI con Claude per PMI e freelancer italiani. 35+ automazioni in produzione, circa 70 job schedulati, zero dipendenti. Stack: Python, GCP.
ACCEPTING NEW CLIENTS
Cover Editorial Paper — La diligenza non finisce quando premi invio. Quando l'AI lavora da sola, diventa architettura
AI & Automazione

La diligenza non finisce quando premi invio: quando l'AI lavora da sola, diventa architettura

7 agosto 2026|13 min di lettura|Giovanni Liguori
Contenuto assistito da AI

C'è un momento preciso in cui l'uso dell'AI cambia natura, e quasi nessuno lo nota mentre accade. È il momento in cui smetti di leggere ogni risposta prima di usarla.

All'inizio la relazione con uno strumento AI è artigianale. Scrivi una richiesta, leggi l'output, decidi se va bene, lo correggi, lo mandi. Sei nel loop a ogni passaggio, e la responsabilità di quello che esce è ovvia: l'hai visto tu, prima di chiunque altro. Poi il sistema cresce. Aggiungi una skill, un task schedulato, un agente che gira mentre dormi. E a un certo punto la macchina produce qualcosa che porta il tuo nome senza che tu l'abbia guardato prima che uscisse.

Qui la quarta competenza dell'alfabetizzazione AI smette di essere un principio da manifesto e diventa un problema di ingegneria. Il discorso è che la responsabilità non sparisce quando l'AI lavora da sola. Cambia forma. E la forma nuova non è una frase da mettere a fine pagina, è come costruisci il sistema.

Le quattro D reggono finché resti nel loop

Chi lavora sull'alfabetizzazione AI conosce il framework delle quattro competenze, i cosiddetti 4D: Delegation, Description, Discernment, Diligence. È il modo più pulito che abbia trovato per parlare di come si lavora davvero con l'AI, e nasce dal lavoro di Rick Dakan e Joseph Feller in collaborazione con Anthropic. Decidere cosa delegare, saper descrivere il problema, valutare l'output, rispondere di quello che produci.

Le prime tre le ho già raccontate in questa serie. La quarta, la diligenza, è quella che tutti citano e quasi nessuno mette a terra, perché nella pratica quotidiana sembra la più facile: rispondi di quello che l'AI produce, controlli prima di usarlo, ci metti la faccia. Fine.

Il problema è che questa definizione presuppone una cosa che diamo per scontata senza dirla: che tu sia lì, a leggere l'output, prima che diventi pubblico. Presuppone il loop. Presuppone l'artigiano che guarda il pezzo prima di consegnarlo.

Ma il modo in cui l'AI entra nel lavoro sta cambiando in fretta. Non è più solo l'assistente a cui chiedi una bozza. Diventa un sistema che pubblica, che risponde, che sincronizza, che monitora. Automazione vera, non demo. E nel momento in cui l'AI agisce da sola, il presupposto salta. Non guardi più ogni output. Non puoi. Sono troppi, e girano quando non ci sei.

La domanda vera allora non è più "ho controllato la risposta?". La domanda è: "di cosa sono responsabile, se non ho visto quello che è uscito?".

Cosa cambia quando l'output non passa più dai tuoi occhi

Ci sono tre spostamenti che avvengono nel momento in cui deleghi non un compito ma un flusso intero. Vale la pena nominarli uno per uno, perché ognuno rompe un pezzo del modo in cui pensavi alla diligenza.

1) La responsabilità si sposta a monte. Finché leggi ogni output, il tuo controllo è a valle: intercetti l'errore appena prima che esca. Quando il sistema agisce da solo, quel punto di controllo non esiste più. L'unico momento in cui puoi ancora incidere è prima, quando progetti il sistema. La diligenza smette di essere un gesto finale e diventa una decisione di design.

2) L'errore diventa silenzioso. Un output che leggi e che è sbagliato lo vedi. Un output sbagliato che esce da un task schedulato alle sei del mattino non lo vede nessuno, finché non se ne accorge un cliente, un lettore, un motore di ricerca. Il collo di bottiglia non è più la qualità del singolo output, è il tempo che passa tra l'errore e il momento in cui qualcuno lo nota.

3) La scala rende inutile il controllo manuale. Puoi rileggere dieci output al giorno. Non puoi rileggere quello che produce un sistema che gira su più runtime, ogni ora, senza di te. E qui arriva la tentazione peggiore: dato che non riesci a controllare tutto, smetti di controllare del tutto e ti fidi. È l'automation bias, il momento in cui il rischio non è che l'AI sbagli, è che tu smetta di accorgertene.

Messi insieme, questi tre spostamenti dicono una cosa sola: la diligenza è la competenza che scala peggio. Delegation, Description e Discernment le puoi esercitare meglio con l'esperienza, quasi in automatico. La diligenza no. Più il sistema diventa autonomo, più la diligenza costa, perché il modo naturale di esercitarla, guardare l'output, è esattamente quello che l'autonomia ti toglie.

La responsabilità diventa architettura, non un disclaimer

La risposta non è tornare indietro e rileggere tutto a mano, perché rinunceresti al motivo per cui hai automatizzato. E non è nemmeno fidarti e sperare, perché è il modo più veloce per pubblicare a tuo nome qualcosa che non avresti mai firmato.

La risposta è spostare la diligenza dove ancora puoi metterla: nell'architettura del sistema. Se non puoi guardare ogni output, costruisci qualcosa che lo guardi al posto tuo, e tieni un punto umano esattamente dove serve.

Nel mio sistema questo si traduce in tre principi concreti, e li racconto non perché siano l'unico modo, ma perché sono in produzione da mesi e hanno retto.

Il primo principio è che i controlli sono deterministici, non gentili richieste. Prima che un contenuto con il mio nome esca, passa da gate scritti come codice: verifiche che o passano o bloccano. Un gate che controlla che ogni cifra abbia una fonte. Un gate che controlla che le date dette su prodotti e sistemi siano vere. Un gate che controlla lo stile. Non sono promesse in un documento, sono script che restituiscono un esito. Un gate che non puoi lanciare non è un gate, è un buon proposito.

Il secondo principio è che il passo irreversibile resta umano. Il sistema scrive la bozza, prepara tutto, fa girare i controlli. Ma la pubblicazione, il gesto che rende una cosa pubblica e difficile da ritirare, resta un gesto che compio io, dopo aver guardato. Non controllo ogni parola di ogni bozza. Presidio il punto esatto in cui l'output smette di essere reversibile. È lì che la mia responsabilità è reale, ed è lì che tengo la mano.

Il terzo principio è che la sorveglianza è continua, non un evento. Un controllo che gira una volta e poi non guarda più è una fotografia, non una difesa. Un layer del sistema esiste solo per controllare gli altri: verifica dopo la pubblicazione, cerca contraddizioni, segnala quando qualcosa è invecchiato. Metà del sistema, sostanzialmente, sorveglia l'altra metà. Non è spreco. È il prezzo onesto dell'autonomia.

Nessuno di questi tre principi elimina l'errore. Ne cambiano la fisica: riducono la probabilità che un errore esca, e accorciano sensibilmente il tempo tra l'errore e il momento in cui viene visto. La diligenza, a questa scala, è tutta qui. Non è la certezza di non sbagliare. È non aver costruito un sistema in cui gli sbagli restano invisibili.

Un gate che passa non è la stessa cosa della qualità

C'è una trappola dentro questo ragionamento, e va detta, perché è il modo più comune per illudersi di essere diligenti mentre non lo si è.

Un controllo automatico verifica quello che sa verificare. Un gate sulle fonti controlla che ogni cifra abbia un link, non che il contenuto dica qualcosa di vero e utile. Un gate sullo stile controlla che non ci siano certe parole, non che la frase abbia un senso. E chi conosce il gate, prima o poi, impara a scriverci intorno: produce output che passano il controllo senza avere la sostanza che il controllo doveva proteggere.

Il punto è questo: i controlli deterministici sono necessari, non sufficienti. Servono a togliere di mezzo gli errori meccanici, quelli che si possono descrivere con una regola. Ma la qualità vera, quella che un lettore sente e un cliente riconosce, la verifica solo qualcuno che il gate non lo conosce e che guarda la cosa per quello che è. Ecco perché il passaggio umano non è un residuo del vecchio modo di lavorare. È il livello che i gate non possono sostituire, esattamente perché i gate si possono ingannare.

La diligenza matura tiene le due cose insieme: le macchine che controllano quello che è controllabile in automatico, e una persona che presidia quello che non lo è. Chi si affida solo alle prime ha delegato anche il giudizio. E il giudizio è l'unica cosa che, per definizione, non puoi delegare a una macchina senza smettere di essere responsabile.

Diligenza e AI Act: l'Art. 50 è la punta, non l'iceberg

C'è un punto dove la diligenza smette di essere una scelta personale e diventa un obbligo scritto. L'AI Act europeo lo mette nero su bianco in due articoli che parlano proprio di questo.

L'Art. 4 dice che chi usa l'AI professionalmente deve avere un livello sufficiente di alfabetizzazione. Non è un consiglio, è un obbligo già in vigore. L'Art. 50 dice che certi contenuti generati o manipolati dall'AI vanno dichiarati come tali, in modo che chi li riceve sappia con cosa ha a che fare. La trasparenza sull'uso dell'AI, insomma, non è più solo buona educazione: è una regola.

Il rischio, quando si parla di compliance, è ridurre tutto alla dichiarazione. Metti l'etichetta "contenuto generato con AI" e ti senti a posto. Ma la dichiarazione è la punta visibile della diligenza, non la diligenza. Dire che un contenuto è passato da un sistema AI mentre quel sistema non ha nessun controllo a monte è una trasparenza vuota: informi il lettore che stai correndo un rischio, senza aver fatto niente per ridurlo.

La diligenza vera è quello che c'è sotto l'etichetta. È il fatto che, prima di dichiarare che un contenuto è assistito dall'AI, tu abbia costruito i controlli che rendono quel contenuto difendibile. L'Art. 50 ti chiede di dirlo. La responsabilità professionale ti chiede di renderlo vero. Sono due cose diverse, e chi le confonde ha capito la forma della norma senza capirne la sostanza. Ho scritto altrove che dichiarare l'uso dell'AI è una scelta di fiducia, non un disclaimer difensivo: l'architettura di cui parlo qui è ciò che rende quella scelta onesta.

Come costruire un minimo di diligenza anche senza un sistema grande

Tutto questo può sembrare roba da chi ha decine di automazioni in produzione. Non lo è. Il principio scala verso il basso, e un freelancer che usa l'AI per scrivere proposte o rispondere ai clienti può metterlo in pratica domani, senza scrivere una riga di codice.

Il punto non è avere gate automatici. Il punto è decidere in anticipo, e non caso per caso, dove sta la tua responsabilità. Ecco un modo concreto di pensarci.

1) Separa i compiti reversibili da quelli irreversibili. Una bozza interna che rileggi con calma è reversibile: puoi delegarla in blocco. Una email a un cliente, un preventivo, un contenuto pubblico sono irreversibili: lì tieni sempre un passaggio umano prima dell'invio. Non è sfiducia nell'AI, è sapere dove un errore costa.

2) Scrivi la tua regola una volta, non ogni volta. "I numeri che cito li verifico alla fonte." "I nomi dei clienti non entrano mai nei prompt." "Prima di mandare, rileggo l'ultima frase e la prima." Tre regole scritte e sempre uguali valgono più di dieci buone intenzioni che dipendono da come stai quel giorno.

3) Metti un controllo tra il sistema e il mondo. Se hai automatizzato qualcosa che esce a tuo nome, aggiungi un punto in cui una persona guarda prima che sia pubblico, anche solo per gli output di un certo tipo. Un controllo che copre il dieci per cento più rischioso vale più di nessun controllo sul cento per cento.

4) Rendi visibile quello che il sistema fa. Un log, una cartella, una notifica: qualcosa che ti dica cosa è uscito mentre non guardavi. Non per controllarlo tutto, ma per accorgerti in fretta quando qualcosa è andato storto. L'errore silenzioso è pericoloso solo finché resta silenzioso.

Nessuno di questi passi richiede un sistema complesso. Richiedono una decisione: quella di trattare la responsabilità come una cosa che progetti prima, non come una cosa che eserciti dopo, quando ormai l'output è già uscito.

La D che conviene progettare per prima

Se dovessi dire quale delle quattro competenze un professionista dovrebbe presidiare per prima, quando l'AI diventa un sistema e non più uno strumento, non avrei dubbi. Non la Delegation, non la Description, non il Discernment. La Diligenza.

Non perché sia la più importante in assoluto, ma perché è la sola che non migliora da sola con l'uso. Le altre le impari facendo. La diligenza, in un sistema autonomo, o la costruisci apposta o non c'è. E il costo di non averla non si misura nel momento in cui salti il controllo. Si misura più tardi, quando un errore che nessuno ha visto è già arrivato dove non doveva, e a rispondere sei comunque tu.

L'alfabetizzazione AI, a questo livello, non è saper usare il modello giusto. È saper rispondere di una macchina che lavora anche quando tu non guardi. Le prime tre D ti insegnano a lavorare con l'AI. La quarta ti insegna a restare responsabile quando l'AI lavora senza di te.

Se vuoi capire da dove parte questa responsabilità nel tuo caso concreto, senza teoria, il self-check sull'AI Act è il modo più veloce per vedere quali obblighi ti riguardano davvero e da dove conviene cominciare.

La responsabilità non si delega. Si progetta.

Condividi

— Newsletter LinkedIn

Ogni settimana condivido workflow, errori e numeri reali

35 automazioni in produzione, zero dipendenti. Su LinkedIn documento il dietro le quinte: cosa funziona, cosa no, e i dati che nessuno mostra.