La terza competenza AI non è ottenere la risposta: è sapere quando è sbagliata
Serie "Alfabetizzazione AI per chi lavora", episodio 3 di 4 | Framework 4D: Discernment
Qualche settimana fa uno dei miei task automatici ha scritto, in un post pronto per la pubblicazione, che un sistema girava "in produzione da otto mesi". La durata reale era poco più di tre. Nessun errore di calcolo, nessun bug nel codice. Il modello aveva prodotto una frase plausibile, scritta bene, sicura di sé. E falsa.
Quella frase non è finita online perché un controllo a valle l'ha intercettata. Non un controllo umano: un altro pezzo di automazione che fa una cosa sola, confrontare ogni numero temporale con la data di nascita reale del sistema di cui si parla. Il modello aveva inventato. La verifica ha corretto. E niente, il post è uscito con il numero giusto.
Questo piccolo episodio dice quasi tutto sulla terza competenza dell'alfabetizzazione AI. Le prime due le ho già raccontate in questa serie: la delega, cioè decidere cosa affidare a una macchina e cosa no, e la descrizione, cioè comunicare con chiarezza quello che vuoi. La terza è il discernimento. Nel framework che uso come spina dorsale di questa serie si chiama Discernment.
Il punto è questo: il discernimento è la competenza che separa chi usa l'AI con un minimo di sicurezza da chi le crede sulla parola. E ti serve proprio perché l'AI è bravissima a sembrare convincente anche quando ha torto.
Una nota sulla fonte, prima di entrare nel merito. Sto seguendo il framework 4D di alfabetizzazione AI sviluppato dai professori Rick Dakan e Joseph Feller insieme ad Anthropic. Quattro competenze in tutto: Delegation, Description, Discernment, Diligence. Questo è l'episodio sul terzo. Il contenuto è mio, la cornice è loro.
Perché l'AI sbaglia con la faccia sicura
Parto da come funziona il modello, perché è lì che nasce tutto il problema. Un modello linguistico non recupera fatti da un archivio. Predice la parola più probabile dopo le precedenti, una alla volta. È un sistema che genera testo plausibile, non testo vero.
La maggior parte delle volte plausibile e vero coincidono, perché nei dati su cui il modello è stato addestrato le cose vere sono anche le più frequenti. Ma quando non coincidono, il modello non te lo segnala. Produce l'output sbagliato con lo stesso tono, la stessa fluidità, la stessa sicurezza con cui produce quello giusto.
Questo fenomeno ha un nome: allucinazione. Il modello allucina quando inventa un fatto, una citazione, un numero, una norma che non esiste, e te lo presenta come se fosse documentato. Non lo fa per ingannarti. Lo fa perché riempire il vuoto con qualcosa di plausibile è esattamente il suo mestiere.
La cosa è questa: la fluidità non è una prova. Anzi. Una risposta scritta benissimo, articolata, con i numeri al posto giusto, è quella di cui ti devi fidare di meno se non l'hai verificata. Perché il modello è ottimizzato per sembrare competente, non per essere accurato. Sono due cose diverse, e il collo di bottiglia di chi inizia a usare l'AI è proprio confonderle.
Pensa al modello così: è un collaboratore che non dice mai "non lo so". Se gli chiedi una cosa che non sa, non si ferma e non ti avvisa. Riempie il vuoto con qualcosa che suona giusto. Un collaboratore umano che facesse lo stesso, ogni giorno, lo manderesti via. Al modello invece glielo perdoniamo, perché scrive bene e va veloce. Il discernimento è smettere di perdonarglielo in automatico.
I tre modi in cui un output ti frega
Con 21+ automazioni in produzione che ogni giorno processano testo, numeri e decisioni, ho isolato tre modi ricorrenti in cui un output dell'AI può fregarti. Non sono tre errori qualunque. Sono i tre che passano più facilmente inosservati, perché in tutti e tre l'output sembra ragionevole a una lettura veloce.
1) L'allucinazione pura
Il modello inventa un dato che non esiste. Una statistica precisa al punto da sembrare vera ("il 73% delle PMI italiane"), una citazione attribuita a qualcuno che non l'ha mai pronunciata, un articolo di legge con un numero plausibile ma sbagliato, una funzione di una libreria software che ha un nome perfetto e non è mai stata scritta.
È il più pericoloso quando il dato è verificabile ma tu non lo verifichi, perché ti fidi del tono. La regola pratica: ogni numero, ogni data, ogni citazione, ogni riferimento normativo che il modello produce va trattato come non confermato finché non l'hai controllato alla fonte. Non "probabilmente giusto". Non confermato. La differenza tra le due etichette è tutto il discernimento.
2) Il contesto mancante
L'output è corretto in astratto e sbagliato per il tuo caso. Il modello ti dà la risposta media, quella che vale per il professionista generico, e tu la applichi al tuo contesto specifico, dove quella media non vale.
Questo lega direttamente alla seconda competenza, la descrizione: spesso un output "giusto ma non per te" è figlio di una richiesta a cui mancava il contesto. La differenza con l'allucinazione è sottile ma importante. Qui il modello non ha inventato niente. Ha risposto bene a una domanda leggermente diversa da quella che avevi in testa. L'errore è di mira, non di invenzione, e per questo è più difficile da vedere.
3) Il ragionamento plausibile ma fallace
Il più insidioso dei tre. Il modello costruisce una catena logica che sembra reggere, ogni passaggio suona corretto, ma da qualche parte c'è un salto. Una premessa data per buona senza dirlo, una conclusione che non segue davvero dalle premesse, una correlazione spacciata per causa.
Questo lo prendi solo se segui il ragionamento passo per passo invece di leggere la conclusione e annuire. La domanda vera non è "la risposta è giusta?". È: "se rifaccio il percorso che ha portato a questa risposta, regge ogni singolo passaggio?". Sono due domande diverse, e quasi nessuno si fa la seconda.
La checklist per verificare un output AI prima di fidarti
Il discernimento non è sfiducia generica. Diffidare di tutto non serve a niente, ti fa solo perdere il vantaggio di usare l'AI. Serve una verifica mirata, veloce, sui punti che contano davvero. Questa è la checklist che ho codificato, letteralmente, dentro le mie automazioni, e che uso anche a mano quando lavoro con il modello in diretta.
1) Numeri, date, quantità: verifica alla fonte
Ogni valore numerico è un punto di rottura potenziale. Nel mio sistema c'è un controllo che fa esattamente questo per i claim temporali, perché è lì che il modello sbagliava più spesso. "Otto mesi" invece di tre, come nell'episodio da cui sono partito. Se un numero pesa sulla decisione che stai prendendo, controllalo prima. Se non pesa, spesso non doveva nemmeno starci.
2) Citazioni e riferimenti: esistono davvero?
Quando il modello cita una legge, una sentenza, uno studio, un autore, la domanda è binaria: esiste? Le citazioni inventate sono frequentissime e particolarmente dannose, perché una fonte falsa dà al testo un'aria di autorevolezza che non si è guadagnato. Cerca la fonte. Se non la trovi in trenta secondi, trattala come inesistente finché non hai la prova del contrario.
3) Logica: segui il percorso, non solo la conclusione
Rileggi il ragionamento come se lo dovessi spiegare a voce a qualcun altro. I salti logici si vedono quando provi a giustificare ad alta voce ogni passaggio. Se a un certo punto ti tocca dire "e qui non so bene perché, ma andiamo avanti", hai trovato il punto debole. Non leggerlo passivamente: rifallo.
4) Contesto: vale per me o solo in astratto?
Chiediti se la risposta tiene conto dei tuoi vincoli specifici, quelli che il modello non poteva sapere a meno che tu non glieli abbia dati. Settore, normativa, pubblico, limitazioni operative. Un output ottimo in generale può essere inutilizzabile nel tuo caso particolare, e nessuno te lo segnala tranne te.
5) Plausibilità contro verità: separa i due giudizi
L'ultimo check è mentale ed è il più importante. Prima di accettare un output, fermati un secondo e distingui "questo suona giusto" da "questo è vero". Sono due giudizi diversi. Il primo è automatico e arriva da solo. Il secondo richiede uno sforzo e va fatto apposta. Il discernimento è fare anche il secondo, proprio quando il primo ti basterebbe per chiudere e passare oltre.
Una nota pratica, perché questa verifica non diventi un secondo lavoro: si tara sul rischio. Un'email interna che chiede un'informazione la verifichi poco. Un testo che va a un cliente, un numero che entra in una decisione, una citazione normativa in un documento ufficiale, quelli li verifichi sempre. Il discernimento maturo è anche sapere dove serve di più e dove puoi lasciar correre.
Come ho trasformato il discernimento in codice (e perché non basta)
C'è una parte di questo lavoro che ho automatizzato e una parte che non si può automatizzare. Vale la pena distinguerle, perché è facile illudersi di aver risolto il problema con un controllo in più.
La parte automatizzabile è quella meccanica. Nel mio sistema, prima che un contenuto esca, passa attraverso una serie di controlli che non hanno opinioni: un controllo verifica che i numeri temporali siano coerenti con le date reali dei sistemi citati, un altro verifica che ogni link interno punti a una pagina che esiste davvero, un altro ancora controlla che il testo rispetti le regole della mia voce. Sono gate. Se uno fallisce, il contenuto non si pubblica, resta in bozza. Quel post sugli "otto mesi" è rimasto fermo proprio così.
Questa è la lezione operativa: il discernimento ripetibile va spostato il più possibile dentro il sistema, perché un controllo automatico non si distrae, non ha fretta il venerdì sera, non si fida del tono. Fa la stessa verifica ogni volta, da zero.
La parte che non si automatizza è il giudizio. Un gate sa dirti che un numero non torna rispetto a una data nota. Non sa dirti se un ragionamento ha una premessa sbagliata, se una risposta è tecnicamente corretta ma fuori contesto, se una sfumatura cambia il senso. Quei tre modi di sbagliare che ho descritto sopra: il primo lo prende anche una macchina, il secondo e il terzo restano lavoro umano. Lì il modello non può controllare il modello. Servi tu.
Il punto è questo: automatizzare il discernimento dove è meccanico ti libera attenzione per il discernimento dove è giudizio. Non lo elimina. Lo concentra dove serve davvero.
Discernimento e Art. 4: la verifica non è solo buon senso, è anche un obbligo
C'è un livello in più, e riguarda la legge. Dal 2 febbraio 2025 l'AI Act europeo, all'Articolo 4, impone un obbligo di alfabetizzazione AI a chiunque usi questi sistemi in ambito professionale. Non è un suggerimento. È un requisito già in vigore.
Alfabetizzazione, nel testo, significa avere le competenze per usare l'AI in modo consapevole, capirne i limiti, valutarne gli output. Il discernimento è letteralmente questo. Quando verifichi un numero prima di mandarlo a un cliente, non stai solo facendo il tuo lavoro meglio: stai facendo la cosa che la normativa si aspetta da chi usa l'AI come strumento di lavoro.
E qui si apre il ponte verso la quarta competenza, la diligenza, che è il tema del prossimo episodio. Il principio di fondo è semplice: la responsabilità dell'output resta tua. Il modello non firma niente. Se mandi a un cliente un documento con un dato inventato dall'AI, il problema è tuo, non del modello. Il discernimento è la competenza che ti permette di prenderti quella responsabilità con cognizione, invece che alla cieca.
Per chi vuole la cronologia precisa, senza confonderla come capita spesso: dal 2 agosto 2026 scattano la piena applicabilità del quadro e gli obblighi di trasparenza dell'Articolo 50, quello che chiede di dichiarare quando un contenuto è generato dall'AI. Gli obblighi più pesanti per i sistemi ad alto rischio dell'Allegato III sono invece stati rinviati al 2 dicembre 2027. Ma l'alfabetizzazione, l'Art. 4, non aspetta nessuna di queste due date: è già adesso.
Il loop che non finisce mai
Torno all'inizio. Nel framework 4D, descrizione e discernimento sono due facce dello stesso processo. Lo avevo già accennato chiudendo l'episodio sulla descrizione: non descrivi una volta e basta. Descrivi, valuti il risultato, ridescrivi. Il discernimento è la parte "valuti", ed è quella che la maggior parte delle persone salta, perché è anche la meno gratificante. Leggere una risposta ben scritta e dire "perfetto" è piacevole. Smontarla pezzo per pezzo no.
Questo loop è il modo normale di lavorare con l'AI, non un segno che stai sbagliando qualcosa. È il segno che stai usando lo strumento come va usato: con una mano sul volante. Chi salta il discernimento non va più veloce. Va solo più sicuro verso il muro.
La competenza più sottovalutata nell'usare l'AI non è scrivere prompt migliori. È sapere quando non crederci. E quella, a differenza dei prompt e dei tool che cambiano ogni sei mesi, non invecchia.
Se ti interessa vedere come questo discernimento diventa un controllo automatico dentro un sistema reale, e non solo una buona intenzione che dura una settimana, è una delle cose di cui parlo più volentieri di persona. Si parte da una conversazione.
— Newsletter LinkedIn
Ogni settimana condivido workflow, errori e numeri reali
21 automazioni in produzione, zero dipendenti. Su LinkedIn documento il dietro le quinte: cosa funziona, cosa no, e i dati che nessuno mostra.