AI come acceleratore del lavoro sui dati

Questa lezione apre il binario dei sistemi LLM e AI per il lavoro sui dati, e parte da una scena che chiunque lavori in questo campo conosce bene: una review settimanale in cui marketing, prodotto e data team devono decidere cosa correggere prima — funnel, tracking, campagna, modello o pipeline — mentre l’analista ha speso metà settimana in passaggi ripetitivi che non compaiono in nessun report. Pulire un export, riconciliare due definizioni di “utente attivo”, riscrivere la stessa query con un filtro diverso. L’intelligenza artificiale comprime davvero questo lavoro ripetitivo. Il rischio è che comprima anche la parte da non comprimere: il ragionamento che rende un numero difendibile quando qualcuno chiede “come sei arrivato a questo risultato?”.

La tesi in breve

Questa lezione colloca l’AI dove accelera il lavoro sui dati e la esclude da definizioni, scelte di modellazione e decisioni con conseguenze, con ogni output collegato a fonte, controllo e responsabile.

Il metodo in sei passi

Ecco come si imposta un workflow che accelera senza perdere il controllo.

1. Scrivi prima di partire decisione da migliorare, evidenza che la sosterrebbe e condizione che ferma tutto.
2. Usa l’AI per riformulare la domanda, generare bozze di query e checklist di controlli, mai per giudizi su dati non visti o scelte economiche.
3. Verifica ogni query su casi limite con denominatore esplicito e quadratura dei totali incorporata.
4. Profila ogni dataset con soglie dichiarate e leggi le anomalie su dominio, tempo e segmento.
5. Confronta ogni modello con la baseline banale sullo split temporale e valuta al costo reale dell’errore.
6. Concedi agli agenti sola lettura con budget e log completi, con soglie di ticket, stop e intervento umano.

Dove l’AI accelera davvero e dove invece rallenta

Il collo di bottiglia del lavoro sui dati raramente è la digitazione. È capire quale domanda meriti risposta, quali dati siano affidabili, quale metrica sposti la decisione e quale rischio resti dopo la raccomandazione. L’AI accelera quando rende questi passaggi più espliciti; rallenta — e danneggia — quando li nasconde dietro un testo ben scritto che nessuno verifica.

Nella pratica conviene ragionare per momenti del workflow. Prima dell’analisi, l’AI è forte nel chiarire domanda, vincoli e output atteso: riformula la richiesta vaga dello stakeholder in una specifica con metrica, periodo, granularità e baseline. Durante l’analisi suggerisce controlli, segmenti alternativi e spiegazioni rivali che un analista sotto pressione dimenticherebbe. Dopo l’analisi prepara memo, tabelle comparative e prossimi passi in una frazione del tempo. In tutti e tre i momenti, però, il controllo resta umano: confermare l’owner della metrica, verificare granularità e filtri sui dati reali, separare nel memo finale ciò che è evidenza da ciò che è ipotesi.

Momento	Uso dell’AI che rende	Controllo umano che resta
Prima dell’analisi	Riformulare la domanda, elencare vincoli e output atteso	Confermare owner, metrica ufficiale e baseline di confronto
Durante l’analisi	Proporre segmenti, controlli di qualità e spiegazioni alternative	Verificare su dati reali: filtri, granularità, casi limite
Dopo l’analisi	Bozza di memo, trade-off, ticket e dashboard	Separare evidenza, ipotesi e raccomandazione prima dell’invio

La regola empirica: se l’output dell’AI ti fa porre più domande precise di prima, sta accelerando. Se ti fa porre meno domande, ti sta addormentando.

Disegnare il confine tra automazione e giudizio umano

Ogni workflow maturo risponde a cinque domande prima di partire, e l’errore più costoso è saltarne una perché “tanto l’AI ci pensa”. Quale scelta concreta deve migliorare — con verbo operativo e owner nominato, non “capire i dati”. Cosa sappiamo delle fonti: granularità, periodo coperto, limiti noti. Quale parte accelera l’AI: un prompt, uno strumento, una checklist. Quale errore cambierebbe la conclusione: il controllo minimo che lo intercetta. Chi decide alla fine e con quale criterio: memo, ticket, deploy o dashboard.

Questo schema vale identico per analisi esplorativa, SQL, pipeline di ingestione, AutoML e workflow agentici. Cambiano gli strumenti, non il principio: nessun output diventa evidenza finché non è collegato a una fonte, a un controllo e a una decisione. Un team marketing che deve spiegare un calo di conversione entro venerdì può far generare all’AI dieci ipotesi e la bozza della sintesi, ma la proprietà di definizioni, segmenti e raccomandazione resta dell’analista. Se non sai indicare quale decisione cambia, quale dato osservare e quale errore evitare, non hai ancora un workflow — hai solo un testo convincente.

Tre righe scritte prima di iniziare valgono più di qualsiasi modello: la decisione da migliorare, l’evidenza che la sosterrebbe, la condizione che fermerebbe tutto e chiederebbe una review. Quando manca anche una sola riga, l’AI resta un supporto esplorativo utile ma non diventa parte stabile del processo.

Dal prompt vago alla specifica che un revisore può controllare

La differenza tra un analista che subisce l’AI e uno che la dirige sta quasi tutta nel primo messaggio. “Analizza le vendite del trimestre” produce un report generico che sembra completo e non è contestabile, perché non dichiara assunzioni. Una specifica utile contiene invece sei elementi: metrica con definizione esatta, periodo e granularità, segmenti da confrontare, baseline di riferimento, formato dell’output atteso e vincoli espliciti come privacy o soglie di significatività.

Un prompt efficace per il lavoro sui dati assomiglia più a un ticket ben scritto che a una conversazione. Dichiara lo schema delle tabelle disponibili, la definizione ufficiale della metrica — “conversione = ordini pagati diviso sessioni con consenso tracking, non pageview grezze” — e chiede all’AI non solo il risultato ma la lista di controlli che lo renderebbero falso: cosa succede escludendo un canale, cambiando finestra temporale, rimuovendo gli outlier. Questo rovesciamento è il punto: l’AI rende di più quando la usi per attaccare la tua stessa analisi che quando la usi per confermarla.

Il secondo accorgimento è chiedere artefatti revisionabili, mai solo testo. Query SQL che puoi eseguire, checklist di controlli con soglie numeriche, tabelle con numeratori e denominatori separati invece di percentuali opache. Un output che non puoi rieseguire o ricontrollare è intrattenimento, non lavoro. E ogni conversazione che produce una decisione va tracciata: prompt, versione dei dati, output e modifiche umane. Se la logica dipende da chiacchiere non registrate, nessun revisore potrà mai riprodurla.

SQL generata dall’AI: velocità utile solo con verifica sistematica

La generazione di query è il caso d’uso più maturo e anche il più insidioso, perché il SQL sbagliato spesso gira senza errori e restituisce numeri plausibili. L’esempio classico è la retention a 30 giorni calcolata come COUNT(DISTINCT user_id) su tutta la tabella eventi, senza filtrare per data di attivazione: include utenti che non hanno ancora avuto 30 giorni di anzianità e gonfia il risultato. Un revisore esperto lo intercetta in secondi; un report generato e mai riletto lo spedisce allo stakeholder.

Il flusso professionale è a tre passi: l’AI produce una bozza dichiarando le assunzioni, l’umano la interroga sui casi limite, poi la query finale gira con controlli di coerenza incorporati. Chiedi sempre quale denominatore usa la metrica, come tratta i NULL e i duplicati, se un cambio di filtro ribalta il risultato. Il sanity check più economico resta quello della somma delle parti: il totale deve quadrare con la somma dei segmenti, altrimenti c’è un buco di join o di filtro prima ancora di discutere il business.

-- Retention a 30 giorni: versione verificabile, commenti in italiano
WITH cohort AS (
    -- Passo 1: una riga per utente con la sua data di attivazione
    SELECT
        user_id,
        MIN(event_date) AS activation_date
    FROM events
    GROUP BY user_id
),
retention AS (
    -- Passo 2: solo utenti con almeno 30 giorni di anzianità (coorte matura),
    -- così il denominatore non include chi non poteva ancora essere ritenuto
    SELECT
        c.activation_date,
        COUNT(DISTINCT c.user_id) AS cohort_size,      -- denominatore esplicito
        COUNT(DISTINCT e.user_id) AS retained_users    -- chi ha eventi entro 30 giorni
    FROM cohort c
    LEFT JOIN events e
        ON c.user_id = e.user_id
        AND e.event_date > c.activation_date
        AND e.event_date BETWEEN c.activation_date + INTERVAL '1 day'
            AND c.activation_date + INTERVAL '30 days'
    WHERE DATEDIFF(CURRENT_DATE, c.activation_date) >= 30
    GROUP BY c.activation_date
)
SELECT
    activation_date,
    cohort_size,
    retained_users,
    -- Passo 3: percentuale con denominatore visibile + controllo di quadratura
    ROUND(100.0 * retained_users / NULLIF(cohort_size, 0), 2) AS retention_pct,
    SUM(cohort_size) OVER () AS totale_coorte  -- deve quadrare con il conteggio grezzo
FROM retention
ORDER BY activation_date;

Quando l’AI ti consegna una query, confrontala con questa struttura: coorte definita prima del calcolo, denominatore esplicito, protezione dai casi degeneri con NULLIF, un controllo di quadratura incorporato. Se mancano, fatteli aggiungere prima di fidarti del numero. Adatta la funzione di differenza tra date al dialetto del tuo warehouse (DATEDIFF qui; in Postgres sottrai le date e confronta con INTERVAL '30 days'): la struttura — coorte, denominatore, quadratura — non cambia.

Profilazione e qualità dei dati con assistenza AI

Il lavoro sporco — capire cosa contiene davvero un dataset prima di analizzarlo — è dove l’AI fa risparmiare più ore, a patto di trattarla come un assistente di ispezione e non come un oracolo. Distribuzioni, valori mancanti, duplicati, formati incoerenti, jump temporali nei log: farti generare lo script di profilazione è veloce, ma interpretare i risultati resta tuo. Una quota alta di NULL su una colonna può essere normale se il campo è opzionale da sempre, o un incidente di ingestione se è comparso di recente. Nessun modello lo sa senza il contesto del tuo dominio.

Il pattern solido è chiedere all’AI uno script di profilazione parametrizzato — soglie in testa al file, output in tabella leggibile — e poi leggere tu le anomalie con tre domande: questo valore è plausibile nel dominio, è stabile nel tempo, cambia per segmento? Il controllo temporale è quello che quasi tutti saltano: una metrica aggregata sul trimestre nasconde una rottura di tracking avvenuta a metà periodo, e solo il profilo per settimana la rivela.

# Profilazione rapida di un export: soglie e letture in italiano
import pandas as pd

# Soglie dichiarate in testa: si cambiano qui, non nel codice
SOGLIA_NULL = 0.05        # oltre il 5% di mancanti scatta la segnalazione
SOGLIA_DUPLICATI = 0.01   # oltre l'1% di righe duplicate va indagato
GIORNI_MINIMI = 200       # righe minime per considerare il campione serio

df = pd.read_csv("export_crm.csv", parse_dates=["event_date"])

report = pd.DataFrame({
    "mancanti_pct": df.isna().mean().round(4),          # quota di NULL per colonna
    "unici": df.nunique(),                              # cardinalità: ID quasi unici?
    "esempio_strano": [str(df[c].dropna().iloc[-1]) for c in df.columns],
})
report["allarme"] = report["mancanti_pct"] > SOGLIA_NULL  # True = da indagare
print(report.sort_values("mancanti_pct", ascending=False))
print("Righe duplicate:", df.duplicated().mean().round(4))
print("Copertura temporale:", df["event_date"].min(), "->", df["event_date"].max())
# Lettura umana: un picco di NULL da una data in poi indica rottura di pipeline,
# non caratteristica del dato. Verificare con il profilo settimanale.

Il guadagno non è lo script in sé — lo scriveresti anche a mano — ma la checklist di letture che l’AI ti propone accanto: confronti con il periodo precedente, segmentazione per canale, verifica dei tipi. Il tuo compito è decidere quali contano e fissarli come controlli permanenti in pipeline, non eseguirli una volta e dimenticarli.

AutoML senza pensiero magico: quando ha senso e come valutarlo

Gli strumenti AutoML — dai servizi cloud ai framework open source — automatizzano selezione di feature, scelta del modello e tuning degli iperparametri. Usati bene, comprimono settimane di tentativi in ore e impongono per costruzione una disciplina che molti progetti artigianali saltano: validazione incrociata, confronto con baseline semplici, tracciamento degli esperimenti. Usati male, producono un modello con un buon punteggio offline che crolla in produzione per motivi che nessuno ha guardato.

La prima decisione è se ti serve davvero. Con poche migliaia di righe e una relazione semplice, una regressione logistica ben specificata batte quasi sempre una pipeline AutoML opaca: si spiega allo stakeholder, si debugga, costa poco. L’AutoML rende quando lo spazio di ricerca è ampio — molte feature candidate, interazioni ignote — e hai abbastanza dati da sostenere una validazione onesta con split temporale, non casuale. Lo split temporale ordina le righe per data e valida sul futuro; quello casuale mescola futuro e passato e gonfia le metriche. Su dati con dimensione tempo, lo split casuale è la bugia più comune.

La valutazione seria usa le metriche giuste per il problema, non l’accuratezza generica. Per classificazione sbilanciata come churn o frode, precisione e richiamo contano più dell’accuracy. La precisione è la quota di veri positivi tra i predetti positivi; il richiamo è la quota di veri positivi tra i positivi reali. La media armonica delle due serve quando vuoi un singolo numero. Ma nessuna metrica offline sostituisce la domanda di business: a quale soglia decisionale operiamo, quanto costa un falso positivo rispetto a un falso negativo, e il modello batte la regola semplice che usiamo oggi? Un AutoML che non migliora la baseline banale — “predici la classe più frequente” o “ripeti il valore della settimana scorsa” — non va in produzione, per quanto sofisticato.

Workflow agentici sui dati: poteri permessi e interruttori

Gli agenti — sistemi che concatenano chiamate a strumenti come query engine, warehouse e API — promettono il salto successivo: non più singole risposte ma interi sotto-processi eseguiti in autonomia. “Controlla ogni mattina la pipeline, confronta con ieri, apri un ticket se qualcosa devia oltre soglia.” Funziona, ma solo se disegni in anticipo tre liste: cosa l’agente può fare da solo, cosa richiede approvazione umana, cosa è vietato sempre. Senza queste liste, hai delegato a un sistema statistico il potere di interrogare dati sensibili e scrivere in produzione.

La pratica che distingue i progetti seri è il principio del minimo privilegio applicato agli strumenti. L’agente di monitoraggio legge tabelle aggregate e apre ticket: non ha credenziali di scrittura sul warehouse, non vede colonne con dati personali, non esegue query oltre un budget di costo. Ogni azione è loggata con input, output e versione dei dati letti, così un umano può ricostruire il percorso quando il ticket sembra strano. E ogni automazione ha una condizione di stop numerica: se la deviazione supera una seconda soglia più alta, l’agente non apre il ticket ma pagina un umano, perché potrebbe essere lui a leggere dati corrotti.

# Contratto minimale di un agente di monitoraggio: permessi espliciti in codice
PERMESSI = {
    "lettura": ["mart_vendite_giornaliere"],  # solo tabelle aggregate, mai raw con PII
    "scrittura": [],                          # nessuna scrittura su warehouse
    "azioni": ["apri_ticket"],                # unica azione esterna consentita
}
SOGLIA_TICKET = 0.15   # deviazione oltre il 15% rispetto alla mediana mobile
SOGLIA_STOP = 0.50     # oltre il 50%: dati sospetti, serve un umano subito
BUDGET_QUERY_EURO = 2.0  # costo stimato massimo per esecuzione

def valuta(deviazione: float) -> str:
    # Logica di decisione trasparente: tre esiti, nessun comportamento implicito
    if abs(deviazione) >= SOGLIA_STOP:
        return "stop: pagina un umano, possibile corruzione dati"  # non aprire ticket
    if abs(deviazione) >= SOGLIA_TICKET:
        return "apri_ticket: allega query, dati e finestra temporale"  # tracciabile
    return "ok: registra solo nel log giornaliero"  # silenzio sotto soglia

Parti sempre dall’agente in sola lettura con un umano che approva ogni azione per due settimane. Solo quando il log mostra che le sue segnalazioni erano corrette e ben calibrate promuovi qualche azione a esecuzione diretta — mai le scritture, mai gli accessi a dati sensibili.

I modi in cui si rompe: leakage, drift, costi e privacy

Quattro failure mode ricorrono nei progetti AI sui dati con regolarità quasi meccanica, e conoscerli in anticipo vale più di qualsiasi framework. Il leakage — informazioni del futuro che filtrano nelle feature di training — produce modelli brillanti offline e inutili in produzione: un campo “data di chiusura” usato per predire la chiusura, un aggregato calcolato sull’intero periodo invece che solo sul passato disponibile al momento della predizione. Il sintomo tipico è una metrica troppo bella per essere vera. La difesa è lo split temporale rigoroso e la regola che ogni feature deve essere ricostruibile con i soli dati noti all’istante della predizione.

Il drift è il gemello operativo: distribuzione dei dati che cambia dopo il deploy — stagionalità, nuovi canali, tracking modificato — e performance che decade in silenzio. Nessun modello è finito al deploy; ognuno nasce con un piano di monitoraggio su input e output, con soglie che fanno scattare retraining o rollback. Il terzo modo è economico: query generate senza consapevolezza dei costi su warehouse a consumo, embedding e chiamate API che si accumulano, job AutoML lasciati girare. Un budget per esecuzione e un alert di spesa sono controlli tecnici a pieno titolo, non burocrazia.

Failure mode	Sintomo	Difesa minima
Leakage	Metriche offline eccellenti, crollo in produzione	Split temporale; feature solo da dati noti al momento della predizione
Drift	Performance che decade senza errori espliciti	Monitoraggio input/output con soglie e piano di retraining
Costi fuori controllo	Bollette warehouse/API che crescono in silenzio	Budget per query e per job, alert di spesa, limiti di scansione
Privacy e compliance	PII in prompt, log o tabelle intermedie	Minimizzazione, mascheramento, lista di colonne vietate agli agenti

La privacy merita attenzione separata perché l’AI la rende facile da violare per distrazione: incollare un export con email in un prompt, lasciare PII nei log delle conversazioni, far leggere all’agente tabelle raw invece di viste anonimizzate. La regola è semplice da enunciare e faticosa da far rispettare: i dati personali non entrano mai nei prompt né negli strumenti AI salvo base giuridica e mascheramento documentato. Fissala come vincolo di sistema — viste senza PII, colonne vietate per policy — non come raccomandazione affidata alla memoria.

Rendere il lavoro osservabile: artefatti, metriche e monitoraggio

Tutto ciò che precede converge su un’idea sola: il lavoro accelera in modo durevole solo se resta osservabile da qualcun altro. L’artefatto finale di un’analisi assistita dall’AI non è il memo ben scritto ma il pacchetto che permette a un revisore di rifare il percorso: domanda iniziale, definizioni delle metriche, versione dei dati, query eseguite, controlli effettuati con esiti numerici, assunzioni dichiarate, raccomandazione separata dall’evidenza. Se un collega competente non può ricostruire il numero partendo dal tuo pacchetto, il workflow è ancora immaturo per quanto veloce.

Misurare il guadagno richiede la stessa disciplina che applichi alle metriche di business. Confronta il ciclo assistito con la baseline manuale sullo stesso tipo di compito: tempo di ciclo, errori intercettati dai controlli, tasso di rilavorazione chiesta dagli stakeholder, fiducia dichiarata nelle review. Un miglioramento reale mostra tempi più brevi a parità di rilavorazioni o, meglio ancora, più controlli eseguiti nello stesso tempo. Se la velocità cresce ma crescono anche le correzioni post-consegna, l’AI sta spostando il lavoro a valle, non eliminandolo — e il costo totale è salito travestito da produttività.

Il monitoraggio chiude il cerchio e vale per analisi ricorrenti, pipeline e modelli. Ogni output che si ripete nel tempo nasce con tre elementi: la metrica sorvegliata con la sua soglia, il responsabile avvisato al superamento, l’azione prestabilita tra cui l’arresto. Un forecast settimanale senza controllo di deriva è una scommessa che rinnovi ogni lunedì senza saperlo. La maturità di un team non si misura dai modelli che usa ma dalla frazione di output automatici coperti da un guardrail con owner: punta a coprirli tutti, partendo da quelli che muovono budget o comunicazioni esterne, e tratta ogni incidente — leakage sfuggito, drift non rilevato, costo imprevisto — come materiale per un nuovo controllo permanente invece che come sfortuna.

Chi applica questo metodo scopre un effetto collaterale: le domande poste all’AI migliorano le domande poste agli umani. Specifiche più precise, assunzioni dichiarate, controlli espliciti — la disciplina richiesta per dirigere un modello è la stessa che rende un team di dati affidabile. L’AI come acceleratore, alla fine, accelera soprattutto questo: la chiarezza su cosa sai, cosa ipotizzi e cosa devi ancora verificare.

Riferimenti tecnici essenziali

• OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
• Vertex AI AutoML forecasting: https://docs.cloud.google.com/gemini-enterprise-agent-platform/machine-learning/tabular-data/forecasting/overview
• Azure AutoML: https://learn.microsoft.com/en-us/azure/machine-learning/concept-automated-ml?view=azureml-api-2
• SageMaker Autopilot: https://docs.aws.amazon.com/sagemaker/latest/dg/autopilot-automate-model-development.html
• Databricks AutoML: https://docs.databricks.com/aws/en/machine-learning/automl/

Verdetto: se l’output ti fa porre più domande precise accelera, se te le toglie ti sta addormentando e va spento.

Il dato GitHub Copilot

Nel 2022 GitHub misurò che gli sviluppatori con l’assistente di completamento portavano a termine i compiti il 55 percento più in fretta in uno studio controllato. Il guadagno stava nella bozza veloce con revisione umana, non nella delega cieca. È la tesi di questa lezione applicata al codice: l’AI sposta il collo di bottiglia dalla scrittura alla verifica, e vince chi sa scartare in fretta.

Domande per chiudere la lezione

1. Quali tre righe scritte prima di iniziare decidono se l’AI entra nel processo o resta un supporto?
2. Cosa rende una query generata verificabile prima ancora di eseguirla?
3. Quando la ricerca automatica non serve e cosa la batte con poche righe?
4. Quali tre liste disegnano un agente sui dati che non può fare danni?