La seconda competenza AI non è saper programmare: è saper descrivere un problema

Serie "Alfabetizzazione AI per chi lavora", episodio 2 di 4 | Framework 4D: Description

Ogni settimana qualcuno mi scrive la stessa variante dello stesso messaggio: "Il modello non capisce quello che voglio".

A volte è vero. Ma più spesso, quando guardo la richiesta originale, il problema è più semplice: mancano informazioni che il mittente dava per scontate.

Questo è esattamente il secondo pilastro del framework AI Fluency che Prof. Rick Dakan e Prof. Joseph Feller hanno sviluppato in collaborazione con Anthropic: la Description. Non è una tecnica avanzata di prompting. È la capacità di comunicare con chiarezza con una macchina che non sa niente di te, del tuo contesto o del tuo settore, a meno che tu non glielo dica.

Nel primo episodio di questa serie, abbiamo visto la Delegation: sapere cosa delegare e cosa no, in quale modalità e con quale supervisione. Questo episodio riguarda il passo successivo: una volta che hai deciso di usare l'AI per un task, come comunichi in modo che il risultato sia utile al primo o secondo tentativo, non al quinto?

L'Art. 4 del Regolamento AI Act, entrato in vigore il 2 febbraio 2025, prevede che chi usa sistemi AI professionalmente disponga delle competenze necessarie per farlo in modo consapevole. I poteri di enforcement scattano dal 2 agosto 2026. La Description è una di quelle competenze che l'Art. 4 ha in mente quando parla di "livello sufficiente di alfabetizzazione".

Il malinteso più comune: i prompt non sono comandi

Quando si parla di "imparare a fare prompting", si crea subito un equivoco: l'idea che esista una sintassi speciale, un ordine preciso di parole, una formula che sblocca il modello.

Non è questo.

I modelli linguistici moderni rispondono bene al linguaggio naturale. Non richiedono notazioni particolari o strutture formali. Il problema vero è più banale e più subdolo allo stesso tempo: il modello non ha accesso a nessuna informazione su di te che non sia nel testo che gli hai inviato.

Pensa a questa situazione: prendi un consulente esperto fuori dal tuo settore, lo chiudi in una stanza, gli passi sotto la porta un bigliettino con scritto "fammi una proposta commerciale" e aspetti che esca qualcosa di utile. Non funzionerebbe. Non perché il consulente sia incompetente, ma perché gli mancano tutte le informazioni che tu consideri ovvie: il settore, il cliente, l'obiettivo, il budget, il tono.

L'AI è identica. La differenza è che il consulente ti chiederebbe quelle informazioni. Il modello, per default, le riempie con ipotesi generiche. E generica sarà la risposta.

Il punto di partenza corretto non è "come formatto meglio questo prompt" ma "quali informazioni mancano che il modello non può sapere senza che gliele dia?"

I tre strati di contesto che quasi sempre mancano

Con 21+ automazioni in produzione che processano ogni giorno testo e decisioni, ho isolato un pattern ricorrente: le richieste che producono output inutili mancano quasi sempre di uno di tre elementi. Li chiamo i tre strati del contesto.

1) Chi sei e il contesto operativo

Il modello non sa il tuo settore, il tuo ruolo, i tuoi clienti, le tue limitazioni normative. Non sa se sei un avvocato che scrive per un pubblico di imprenditori o un commercialista che scrive per i colleghi. Non sa se il tuo pubblico è italiano, se il tuo tono deve essere formale o diretto, se stai lavorando su un testo interno o destinato a un cliente finale.

Se non specifichi, il modello usa un profilo generico. L'output sarà "ragionevole" in astratto ma spesso non pertinente per il tuo contesto specifico.

La correzione è semplice: due frasi di contesto prima della richiesta. "Sono un avvocato tributarista che lavora con PMI italiane. Il mio tono scritto è diretto e tecnico, senza fronzoli. Il pubblico di questo testo è un imprenditore con partita IVA."

2) Il task specifico, non la categoria

"Aiutami con il marketing" è una categoria. "Scrivi tre varianti di oggetto email per una campagna di ri-engagement di clienti inattivi da sei mesi, obiettivo tasso di apertura, tono diretto, nessun sconto menzionato, massimo 9 parole per oggetto" è un task.

La distinzione conta perché le categorie ammettono decine di interpretazioni. I task specifici ne ammettono una sola. Più il task è specifico, più il risultato è usabile senza iterazioni.

Spesso il vero lavoro cognitivo nella Description non è scrivere il prompt: è capire esattamente cosa si vuole come output. Se non riesci a descrivere con precisione il risultato che ti aspetti, è molto probabile che il modello non riesca a produrlo.

3) I vincoli impliciti

Ogni professionista lavora con vincoli che considera così ovvi da non pensare di doverli esplicitare. Un medico sa che certi consigli richiedono sempre un disclaimer. Un commercialista sa che le aliquote cambiano ogni anno. Un avvocato sa che la giurisdizione conta.

L'AI non li conosce, questi vincoli specifici. Li conosce in modo generico, ma non sa i tuoi vincoli di contesto. E spesso è proprio lì che un output "ragionevole in astratto" diventa problematico in pratica.

Regola pratica: dopo aver scritto la richiesta, chiediti "c'è qualcosa che un esperto esterno al mio settore potrebbe non sapere e che cambierebbe la risposta?" Se sì, aggiungilo.

Come scrivere una richiesta AI che produce risultati concreti

Questo non richiede di diventare esperti di prompt engineering. Richiede la stessa struttura che si userebbe per una brief professionale a qualsiasi collaboratore.

Una richiesta che funziona ha in genere questa struttura:

1. Contesto: chi sei e in quale situazione stai operando (2-3 frasi)
2. Task: cosa deve produrre esattamente (formato, lunghezza, tono)
3. Vincoli: cosa non deve fare, assumere o includere
4. Output atteso: come deve essere strutturato il risultato (elenco puntato, paragrafi, tabella, ecc.)

Esempio reale da un'automazione in produzione: un task che processa feedback di clienti e produce una sintesi operativa. La richiesta al modello non è "sintetizza questi feedback". È: "Sei un analista che lavora per un'agenzia di servizi B2B italiana. Leggi questi feedback di clienti e produci: 1) i tre temi ricorrenti ordinati per frequenza, 2) per ogni tema un'azione operativa concreta. Formato: testo piano, max 200 parole totali, nessun punto di elenco annidato. Non includere giudizi qualitativi generici tipo 'i clienti sembrano soddisfatti'."

Quella specificità non è pedanteria. È la differenza tra un output usabile direttamente e uno che richiede ancora 15 minuti di rielaborazione manuale.

Un altro modo di pensarci: immagina di dover delegare questo task a un collaboratore neo-assunto il suo primo giorno. Cosa dovresti spiegare per iscritto perché faccia la cosa giusta senza doverti chiedere altro? Quella spiegazione è il tuo prompt.

Il loop Description-Discernment

Nel framework 4D, Description e Discernment sono connessi. Non si descrive una volta sola: si descrive, si valuta il risultato, si ridescrive.

Questo è il processo normale. Non è un fallimento del modello né un errore di chi ha scritto la richiesta iniziale. È come funziona la comunicazione professionale: raramente il primo draft è il finale.

Il loop funziona così:

1. Scrivi la richiesta con i tre strati di contesto
2. Leggi l'output con occhio critico: è nel target? Ha riempito buchi in modo sbagliato? Ha ignorato vincoli che non avevi esplicitato?
3. Aggiungi alla richiesta quello che mancava: non riscrivere tutto, aggiungi il pezzo specifico che mancava
4. Reitera: di solito al secondo o terzo tentativo l'output è già al livello di un primo draft professionale

La velocità migliorerà con la pratica. Non perché si imparano "trucchi di prompting" ma perché si impara a identificare più velocemente quali informazioni mancano.

La Discernment, il terzo pilastro del framework, riguarda il secondo passo di questo loop: come si valuta l'output in modo critico. Ne parliamo nel prossimo episodio. Ma il punto importante da capire ora è che il loop non è un workaround: è la modalità di utilizzo corretta.

Description e GDPR: cosa non mettere nei prompt

Questo è l'aspetto della Description che più guide ignorano, ma che il GDPR già regola e che l'Art. 4 AI Act chiede di conoscere in modo esplicito.

Regola base: non inserire dati personali di terzi in prompt che transitano su infrastrutture cloud.

Questo include:

• Nomi e cognomi di clienti, dipendenti, fornitori
• Numeri di telefono, email, codici fiscali, partite IVA associate a persone fisiche identificabili
• Dati finanziari specifici (fatture, stipendi, estratti conto identificativi)
• Dati sensibili in senso GDPR: salute, orientamento politico, fede religiosa, origine etnica

Il motivo non è astratto. Quando invii un prompt a un modello cloud, quei dati entrano nell'infrastruttura del provider. Se non hai un accordo DPA (Data Processing Agreement) che regola esplicitamente il trattamento e garantisce che i dati non vengano usati per training, si configura un potenziale problema GDPR.

La soluzione pratica è anonimizzare prima di descrivere. "Il mio cliente Mario Rossi, partita IVA..." diventa "Un cliente nel settore manifatturiero con sede in Lombardia...". Il modello non ha bisogno del nome per aiutarti nel 95% dei task.

In tutte le automazioni in produzione che elaborano informazioni su clienti, questo layer di anonimizzazione è strutturale nel workflow, non una decisione manuale. Si applica prima che il dato raggiunga il modello.

C'è poi un secondo livello: i dati aziendali confidenziali (strategie, prezzi riservati, informazioni su acquisizioni). Anche questi andrebbero gestiti con cautela, soprattutto in assenza di accordi contrattuali specifici con il provider.

Description nei sistemi automatizzati

Quando si lavora in modo manuale, la Description si può correggere in tempo reale: si vede che l'output non è quello giusto e si riformula immediatamente. Nei sistemi automatizzati, non c'è questa possibilità.

Come ho descritto nell'analisi sul context engineering e la gestione del consumo di token, nei workflow automatizzati il contesto iniziale condiziona ogni singolo output successivo. Un errore di Description in un'automazione che gira 30 volte al giorno si moltiplica per 30.

Per questo, nelle automazioni in produzione, il blocco di contesto iniziale (chi è questo sistema, cosa deve produrre, per chi, con quali vincoli, cosa non deve mai fare) viene trattato con la stessa cura del codice. Non è testo di configurazione che si scrive in fretta e si dimentica. È la fondazione su cui poggia ogni output successivo.

Succede anche che quella Description debba essere aggiornata nel tempo. Cambiano i clienti, cambiano le normative, cambia il prodotto. Ogni modifica al contesto iniziale è, di fatto, una manutenzione del sistema. E come tutta la manutenzione, richiede attenzione: una variazione non intenzionale nella Description può cambiare il comportamento dell'automazione in modo sottile e difficile da rilevare.

La Description, in questo senso, è un'abilità che scala: impararla in modo manuale, su richieste singole, è il punto di partenza. Il suo impatto reale emerge però quando si portano queste competenze nei sistemi che operano su scala.

Cosa succede quando la Description è buona

Vale la pena fermarsi un momento su cosa si guadagna concretamente.

Una richiesta ben descritta riduce le iterazioni: meno avanti e indietro, meno tempo perso. Produce output che si possono usare direttamente o con modifiche minime, invece di richiedere rielaborazione. Rende il workflow prevedibile: stessa qualità di input, stessa qualità di output attesa.

Ma c'è anche un effetto meno ovvio: una buona Description ti obbliga a pensare prima di agire. Formulare con chiarezza il contesto, il task specifico e i vincoli richiede di avere le idee chiare su cosa si vuole. Spesso è proprio questo chiarimento interno che aggiunge valore, indipendentemente dal modello.

È lo stesso effetto di scrivere una specifica tecnica o una brief: il processo di scrittura forza la chiarezza del pensiero. Con l'AI, quel processo avviene prima di ogni richiesta, anche quelle rapide. E con la pratica, diventa naturale.

Il prossimo passo: imparare a valutare

Sapere come descrivere un problema bene risolve metà della questione. L'altra metà è sapere cosa fare con la risposta: valutarla, identificare dove il modello ha riempito buchi in modo sbagliato, distinguere un output preciso da uno plausibile ma impreciso.

Questo è il lavoro del terzo pilastro del framework 4D: la Discernment. Nel prossimo episodio della serie vediamo come sviluppare quell'occhio critico, come riconoscere le allucinazioni nel testo pratico (non solo i casi eclatanti), e perché questa competenza è probabilmente la più sottovalutata delle quattro.

Nel frattempo, se vuoi capire dove il tuo setup AI attuale ha gap di alfabetizzazione rispetto agli obblighi Art. 4 e cosa fare prima della finestra di enforcement di agosto 2026, puoi prenotare una chiamata di discovery.

Attribuzione del framework

Framework AI Fluency (Delegation / Description / Discernment / Diligence): sviluppato da Prof. Rick Dakan (Ringling College of Art and Design) e Prof. Joseph Feller (University College Cork), in collaborazione con Anthropic PBC. Licenza CC BY-NC-SA 4.0. Questo articolo usa la struttura concettuale del framework con contenuto, esempi e analisi originali.