Analytical prompting and question control

Lavoriamo nel binario dei sistemi LLM, quindi partiamo dal sintomo che conosciamo tutti: chiedere a un modello linguistico “perché il fatturato è sceso” produce quasi sempre una risposta leggibile e articolata, piena di cause plausibili. Il problema è che la plausibilità non è una prova. Senza domanda formalizzata, senza perimetro dei dati e senza controlli dichiarati, quella risposta non è revisionabile: non sai quali tabelle ha immaginato, quale periodo ha confrontato, quale metrica ha usato. Il prompting analitico nasce per chiudere esattamente questo scarto — trasformare la conversazione libera in una specifica di lavoro che un collega, un auditor o tu stesso tra un mese potete ricostruire, criticare e rifare.

L’idea in una frase

Il prompting analitico trasforma ogni domanda ai dati in una specifica scritta con contesto, compito, formato e vincoli, così l’output lascia tracce che un revisore può ricostruire e contestare.

Come passare dalla conversazione al protocollo

Ecco la sequenza operativa, passo dopo passo.

1. Riscrivi la domanda in tre righe: decisione con proprietario, evidenza osservabile, condizione di stop.
2. Fissa nel prompt metrica con numeratore e denominatore, popolazione con filtri espliciti e baseline scelta prima di vedere i numeri.
3. Struttura il prompt in quattro blocchi: contesto, compito, formato con tabelle che quadrano, vincoli che impongono di dichiarare celle deboli e assunzioni.
4. Chiedi artefatti revisionabili: query eseguibili, scomposizioni che sommano al totale, criteri di accettazione numerici.
5. Allega a ogni output il controllo che potrebbe smentirlo: coerenza dimensionale, stabilità alla segmentazione, confronto con baseline indipendente, audit di disponibilità dei campi.
6. Archivia prompt, snapshot dei dati e output con esito della verifica; consegna al decisore un memo firmato, mai il thread di chat.

Perché le risposte convincenti non bastano più

I modelli linguistici sono ottimizzati per produrre continuazioni coerenti, non per dire “non ho i dati per rispondere”. Davanti a una domanda analitica vaga colmano i vuoti: inventano un denominatore ragionevole, scelgono un confronto temporale comodo, ignorano un cambio di tracking avvenuto tre settimane fa. Il risultato suona professionale perché segue le convenzioni del linguaggio manageriale — “il calo è trainato dal segmento enterprise” — ma la frase potrebbe essere vera, falsa o parzialmente vera senza che la forma linguistica cambi di una virgola.

Nel lavoro sui dati questo è più pericoloso che in altri ambiti, perché l’errore si propaga. Una segmentazione sbagliata diventa una slide, la slide diventa una priorità di roadmap, la priorità diventa budget. Il controllo delle domande serve a invertire l’ordine: prima si fissa cosa conta come evidenza, poi si chiede all’AI di aiutare a produrla. La domanda analitica non è “cosa è successo”, ma “quale confronto, su quale popolazione, con quale metrica e con quale soglia decisionale”. Finché questi quattro elementi non sono scritti, il prompt è un auspicio, non una specifica.

C’è anche un costo organizzativo, spesso invisibile finché non esplode. Quando ogni analista conversa con il modello in privato, la logica decisionale si frammenta in thread non tracciati: due persone pongono la stessa domanda con parole diverse, ottengono risposte diverse, e portano in riunione due verità incompatibili. Il prompting analitico sposta la conversazione dal thread privato al documento condiviso: prompt versionato, contesto dichiarato, output salvato accanto al codice che lo ha generato.

Cosa significa davvero prompting analitico

Prompting analitico significa scrivere prompt come si scrive una specifica di esperimento: input, trasformazioni, output atteso e criterio di falsificazione. Il criterio di falsificazione dice in anticipo cosa ti farebbe scartare l’output: soglia mancata, quadratura fallita, baseline divergente. La differenza rispetto al prompting generico sta tutta nel vincolo. Un prompt generico dice all’AI cosa produrre; un prompt analitico dice anche cosa non deve fare, su cosa deve appoggiarsi e come deve mostrare il proprio lavoro.

Prendi una richiesta tipica: “analizza il calo della conversione”. La versione analitica la riscrive in quattro blocchi. Contesto: tabella orders e sessions dal 1 gennaio al 30 giugno, granularità giornaliera, segmento web vs app. Compito: scomponi il tasso di conversione in traffico, add-to-cart e checkout completion, e riporta variazioni assolute e relative contro la media delle quattro settimane precedenti. Formato: tabella con numeratore, denominatore e numerosità per ogni cella, seguita da tre ipotesi ordinate per impatto stimato. Vincoli: non usare dati oltre il 30 giugno, segnala celle con meno di 200 sessioni come non conclusive, elenca le assunzioni che non hai potuto verificare. La struttura a quattro blocchi — contesto, compito, formato, vincoli — è il mattone base. Il contesto fissa il perimetro dei fatti; il compito fissa l’operazione; il formato rende l’output confrontabile; i vincoli dichiarano i limiti. Senza il quarto blocco, i primi tre producono comunque testo sicuro di sé su basi fragili. Con il quarto, l’AI è costretta a dire “questa cella non regge”, che è spesso l’informazione più preziosa della tabella.

Un corollario pratico: chiedi sempre all’AI di separare osservato, calcolato e ipotizzato. Osservato è un conteggio diretto sulle tabelle indicate. Calcolato è una derivazione con formula esplicita. Ipotizzato è tutto il resto. Quando queste tre categorie si mescolano in un unico paragrafo, la revisione diventa impossibile; quando sono etichettate, un revisore sa esattamente dove colpire.

Dalla domanda vaga alla specifica revisionabile

La maggior parte delle domande che arrivano al data team non è analizzabile così com’è. “Come sta andando il prodotto?” “Il churn sta peggiorando?” “Questo test ha funzionato?” Il lavoro del prompting analitico comincia prima del prompt: riformulare la domanda finché non diventa misurabile, con un owner e una soglia.

Una tecnica che funziona è la riscrittura in tre righe. Riga uno, decisione: quale scelta concreta cambia a seconda della risposta — spegnere una campagna, correggere una pipeline, estendere un esperimento. Riga due, evidenza: quale confronto osservabile sostiene quella scelta — differenza di conversione tra due coorti, scostamento dal forecast oltre una banda. Riga tre, stop: cosa invalida tutto — cambio di definizione della metrica a metà periodo, copertura di tracking sotto una soglia, campione troppo piccolo. Se una di queste righe resta vuota, non è il momento di promptare: è il momento di chiarire con lo stakeholder.

Il secondo passaggio è fissare metrica, popolazione e baseline per iscritto nel prompt. La metrica va definita con numeratore, denominatore e gestione dei casi limite: il tasso di conversione è ordini / sessioni o ordini / utenti unici? Come tratti sessioni rimbalzate a zero secondi, ordini annullati, traffico interno? La popolazione va delimitata con filtri espliciti: solo traffico non bot, solo ordini fatturati, solo un paese. La baseline va scelta prima di vedere i numeri: media mobile delle quattro settimane precedenti, stesso periodo dell’anno scorso, gruppo di controllo dell’esperimento. Chi sceglie la baseline dopo aver visto il risultato sta facendo cherry-picking, con o senza AI.

Il terzo passaggio è imporre la granularità del controllo. Un numero aggregato non si verifica; una tabella sì. Chiedi scomposizioni che sommano al totale — per canale, per segmento, per settimana — così il revisore può ricontrollare le somme. Se le parti non sommano all’intero, c’è un filtro nascosto o un errore di join, e lo scopri in trenta secondi invece di scoprirlo in riunione.

Il ciclo decisione-contesto-supporto-verifica-handoff

Un prompt isolato, per quanto ben scritto, non regge un workflow. Serve un ciclo in cinque fasi che lega ogni richiesta AI a una decisione e a un passaggio di consegne. La sequenza è: decisione, contesto, supporto AI, verifica, handoff. Ogni fase produce un artefatto; se l’artefatto manca, la fase non è stata fatta.

Decisione: una frase con verbo operativo e owner. “Decidere se estendere l’esperimento di checkout al 100% entro venerdì, owner la PM checkout.” Non “capire il test”. Il verbo operativo — estendere, spegnere, correggere, finanziare — costringe a dire cosa cambia nel mondo. Senza owner, la decisione evapora: tutti leggono il memo, nessuno agisce.

Contesto: fonti, granularità, periodo, limiti noti. Quali tabelle, con quale freschezza, con quali buchi documentati. “Tabella events aggiornata a ieri ore 6, tracking app rotto dal 12 al 15 maggio, segmento enterprise escluso perché migrato su nuovo CRM.” Questo blocco si scrive una volta e si riusa: è il data contract leggero del workflow, e l’AI lo riceve in ogni prompt invece di indovinarlo.

Supporto AI: il prompt vero e proprio, più lo strumento. Qui vale la regola della delega selettiva: all’AI vanno bozze, enumerazioni e sintesi — bozza di query SQL, lista di segmenti da controllare, prima stesura del memo. Non vanno giudizi su dati che non ha visto né scelte con conseguenze economiche. Il prompt dichiara esplicitamente quale dei due sta chiedendo.

Verifica: il controllo che potrebbe ribaltare la lettura. Ogni output AI arriva con il suo test di falsificazione allegato: ricalcolo indipendente su un campione, confronto con una baseline esterna, controllo di coerenza dimensionale. Se il test non è superato, l’output non sale di livello: resta bozza.

Handoff: il passaggio a chi decide, nel formato che chi decide usa davvero. Un memo di mezza pagina con evidenza, ipotesi e raccomandazione separate; un ticket con criterio di accettazione; una dashboard con definizione della metrica accanto al grafico. L’errore classico è consegnare il thread della conversazione con il modello: nessuno lo leggerà, e comunque non è firmato da nessuno.

Phase	Artefatto minimo	Chi lo firma
Decision	frase con verbo + owner + scadenza	stakeholder
Context	fonti, periodo, filtri, limiti noti	analista
AI Support	prompt versionato + output grezzo salvato	analista
Verification	test superato o fallito, con numeri	revisore
Handoff	memo, ticket o dashboard con definizioni	owner decisione

Controlli che separano l’evidenza dalla narrazione

La verifica è dove il workflow guadagna o perde credibilità. Quattro famiglie di controlli coprono la maggior parte dei fallimenti che ho visto in produzione analitica assistita da AI.

Primo, coerenza dimensionale. Le parti devono sommare all’intero lungo ogni dimensione di scomposizione. Se il fatturato totale è 1,2 milioni ma la somma per canale fa 1,05, c’è un canale “altro” non etichettato, un filtro diverso o un join che perde righe. Chiedi all’AI di includere sempre riga totale e riga di quadratura, e di segnalare scostamenti oltre l’1%. È un controllo banale che intercetta una quota sorprendente di errori, inclusi quelli introdotti da query generate dal modello stesso con un WHERE di troppo.

Secondo, stabilità alla segmentazione. Una lettura che vale solo su un segmento cherry-picked non è una lettura. Fai ricalcolare la metrica togliendo il segmento più favorevole, cambiando finestra temporale di una settimana in entrambe le direzioni, escludendo outlier sopra il 99° percentile. Se il segno dell’effetto cambia, l’evidenza è fragile e il memo deve dirlo. Stai stimando la sensibilità della lettura al variare del sottoinsieme: se il segno non è stabile su partizioni ragionevoli, non hai un risultato, hai un’istantanea.

Terzo, confronto contro baseline indipendente. Ogni metrica AI-assisted va affiancata a un riferimento che l’AI non ha prodotto: il calcolo manuale precedente, il report del finance, lo stesso periodo dell’anno scorso. Uno scostamento oltre una banda predefinita — diciamo cinque punti su metriche di volume — fa scattare l’investigazione, non la celebrazione. La baseline va scelta prima, come detto, e scritta nel prompt.

Quarto, controllo di leakage e di freschezza. Nel reporting, leakage significa usare informazione disponibile solo dopo l’evento che stai misurando: ordini annullati il giorno dopo conteggiati come vendite del giorno prima, attribuzioni aggiornate retroattivamente. Nella generazione di feature per modelli, significa colonne che incorporano il target. Il controllo è una domanda esplicita nel prompt: “per ogni campo usato, indica il momento in cui diventa disponibile rispetto all’evento misurato”. Sul fronte freschezza, ogni output porta timestamp dei dati e lag noto della pipeline: numeri di martedì calcolati su dati fermi a domenica vanno etichettati come tali.

Prompt, SQL e codice che un revisore può criticare

Il punto di contatto più delicato è quando l’AI scrive codice — SQL, Python di trasformazione, configurazioni di pipeline. Il codice generato va trattato come codice di un junior veloce e instancabile: utile, ma da revisionare riga per riga prima del merge. Il prompting analitico qui significa imporre convenzioni che rendono la review possibile.

Prima convenzione: ogni query generata deve dichiarare popolazione, filtri e gestione dei null in commenti leggibili. Niente SELECT * su tabelle di eventi, niente join senza condizione di deduplica esplicita, niente funzioni di data senza timezone. Il prompt lo impone: “commenta ogni CTE con popolazione in ingresso e in uscita, numero di righe attese e trattamento dei null”. Se l’AI non sa stimare le righe, il revisore le confronta con i conteggi reali — ed è già un test.

-- Scomposizione conversione per canale, settimana 20-23 vs baseline 16-19
-- Popolazione: sessioni web non-bot, ordini fatturati (stato = 'paid')
-- Baseline: media giornaliera delle 4 settimane precedenti al cambio tracking
WITH sessioni_valide AS (
  -- Una riga per sessione: escludo bot e traffico interno
  SELECT session_id, canale, data_sessione
  FROM sessions
  WHERE is_bot = FALSE
    AND is_interno = FALSE
    AND data_sessione BETWEEN DATE '2026-05-11' AND DATE '2026-06-07'
),
ordini_validi AS (
  -- Solo ordini fatturati; i rimborsati entro 24h restano ma marcati
  SELECT session_id, importo
  FROM orders
  WHERE stato = 'paid'
)
SELECT
  s.canale,
  COUNT(DISTINCT s.session_id) AS n_sessioni,      -- denominatore
  COUNT(DISTINCT o.session_id) AS n_ordini,        -- numeratore
  -- Tasso = ordini unici / sessioni uniche; celle sotto 200 sessioni da ignorare
  COUNT(DISTINCT o.session_id) * 1.0
    / NULLIF(COUNT(DISTINCT s.session_id), 0) AS tasso_conversione
FROM sessioni_valide s
LEFT JOIN ordini_validi o USING (session_id)
GROUP BY s.canale;

Seconda convenzione: mai una sola query per una decisione. Chiedi all’AI due query indipendenti che rispondono alla stessa domanda per strade diverse — per esempio una via sessions LEFT JOIN orders e una via conteggi separati con riconciliazione — e confronta i totali. Se divergono oltre la soglia, c’è un’assunzione nascosta in almeno una delle due. Costa qualche minuto di computazione in più e intercetta errori di join che altrimenti arrivano in produzione.

Terza convenzione: il prompt di generazione include sempre il test di accettazione. “La query è accettata se: il totale ordini differisce meno del 2% dal report finance del giorno; nessuna cella sopra il 5% del totale ha numerosità sotto 200; la somma per canale quadra con il totale entro l’1%.” Senza criterio di accettazione, la review è impressionistica; con il criterio, è meccanica e veloce.

Lo stesso vale per il Python di feature engineering o i suggerimenti AutoML: ogni colonna proposta arriva con definizione, momento di disponibilità e motivazione. Una feature senza timestamp di disponibilità è un potenziale leakage in attesa di esplodere al primo backtest onesto.

Quando non delegare: ownership, costi e rischi

Non tutto il workflow è delegabile, e la linea va tracciata prima di aprire il primo prompt. Tre categorie restano umane per definizione: la scelta della metrica che orienta gli incentivi, l’interpretazione di risultati ambigui con conseguenze economiche, e qualsiasi uso di dati personali oltre il perimetro autorizzato. Su questi punti l’AI propone, l’umano dispone — e la firma è umana.

I costi sono il secondo vincolo sottovalutato. Cicli agentici che iterano decine di volte su warehouse a pagamento trasformano una domanda da pochi centesimi in una fattura visibile, soprattutto se ogni iterazione scansiona tabelle di eventi non partizionate. Il prompt analitico maturo include un budget: numero massimo di iterazioni, tabelle consentite, divieto di full scan oltre una soglia. Una riga nel prompt — “massimo 5 query, solo tabelle aggregate giornaliere, stop se la scansione stimata supera 100 GB” — vale più di molti discorsi sulla FinOps.

La privacy è il terzo vincolo. Mai incollare nel prompt dati grezzi identificativi quando basta uno schema con statistiche aggregate: nomi, email, note libere dei clienti non appartengono a un thread di conversazione. La regola operativa è minimizzare: schema, definizioni, distribuzioni e un campione sintetico o anonimizzato. Se il team lavora su dati sanitari o finanziari, il perimetro va concordato con chi governa la compliance prima, non dopo il primo incolla.

Infine il rischio di automazione non governata: pipeline schedulate che eseguono prompt, generano insight e li pubblicano su Slack senza review. Finché l’output è una bozza in un documento, il danno massimo è tempo perso; quando l’output muove budget o comunicazioni esterne, serve un gate umano esplicito. La matrice è semplice: a basso impatto e alta reversibilità, l’AI può operare con controlli automatici; ad alto impatto o bassa reversibilità — report al board, comunicazioni ai clienti, deploy di modelli — ogni output passa da un owner prima di uscire.

Mettere il metodo in produzione senza perdere rigore

Rendere il metodo stabile significa archiviare tre cose per ogni analisi: il prompt esatto usato, il contesto dati con timestamp e versioni delle tabelle, l’output grezzo più il test di verifica con esito. Con questi tre elementi, chiunque può ricostruire cosa è stato chiesto, su cosa, e perché ci si è fidati. Senza, resta un racconto. Un repository di prompt versionati accanto al codice delle pipeline costa poco e composto mese dopo mese diventa la memoria operativa del team: quali formulazioni producono output verificabili, quali generano solo testo elegante.

Il monitoraggio chiude il cerchio. Ogni metrica nata da un workflow AI-assisted porta con sé definizione, baseline e banda di guardia; quando esce dalla banda, scatta la revisione della pipeline prima della revisione del business. Vale anche per i prompt stessi: se un template che funzionava comincia a produrre output incoerenti — perché è cambiato lo schema, il tracking o il modello sottostante — il tasso di fallimento dei test di quadratura lo segnala prima che i numeri sbagliati raggiungano una slide. Misura quindi due cose: la qualità dei dati in uscita e la qualità dei prompt in ingresso, con la stessa disciplina.

Un ultimo trade-off va detto con onestà. Questo metodo rallenta la prima bozza: scrivere contesto, vincoli e test costa più tempo che buttare una domanda in chat. Il guadagno arriva dopo — meno riunioni per chiarire numeri incompatibili, meno retromarce su decisioni prese su basi fragili, meno audit dolorosi. Se il tuo contesto richiede solo una risposta usa-e-getta senza conseguenze, la cerimonia completa è spreco; applicala in proporzione al costo dell’errore. La maturità sta nel dosare il controllo, non nell’applicarlo sempre al massimo: bozza leggera per esplorare, specifica completa per decidere, gate umano per pubblicare. Il filo conduttore non cambia mai — domanda scritta, evidenza tracciata, controllo dichiarato — e chi lo tiene in mano può usare l’AI come acceleratore senza cederle il volante.

Verdetto: un prompt senza decisione, perimetro e criterio di falsificazione non è lavoro analitico ma conversazione; la struttura in quattro blocchi con artefatti eseguibili batte qualsiasi scorciatoia di stile.

L’esempio dei due economisti e del foglio di calcolo

Nel 2010 due economisti di Harvard sostennero che oltre il 90 percento di debito sul PIL frenava la crescita, una tesi che pesò nel dibattito sull’austerità in Europa e in America. Nel 2013 tre ricercatori dell’Università del Massachusetts scoprirono che il foglio di calcolo escludeva righe, pesava i paesi nel modo sbagliato e conteneva errori di formula. La conclusione non resse alla replica indipendente. È la dimostrazione che senza dati, codice e controlli allegati anche l’analisi più influente resta un’affermazione ben formattata.

Domande per chiudere la lezione

1. Quali quattro elementi rendono una domanda analitica misurabile prima di aprire il prompt?
2. Perché la baseline va scelta prima di vedere i numeri e cosa rischi se la scegli dopo?
3. Quale controllo smaschera una scomposizione con filtri incoerenti in trenta secondi?
4. Cosa consegni al decisore e perché il thread di chat non basta mai?