Case Study: AI-Assisted End-to-End Workflow

Siamo nel binario dei sistemi LLM, e questo caso studio li mette al lavoro su un problema vero. La scena: il churn di un SaaS B2B sale di due punti in un trimestre e nessuno sa dire perché. Il marketing accusa il prodotto, il prodotto accusa il tracking, il data team apre l’ennesimo notebook che nessuno leggerà. È familiare a chiunque abbia lavorato su dati reali: non mancano i numeri, manca un processo che trasformi numeri sparsi in una decisione che regga una review. Questo caso studio ricostruisce esattamente quel percorso, dall’allarme iniziale alla raccomandazione operativa, mostrando dove un assistente AI accelera il lavoro e dove deve fermarsi a chiedere il permesso.

Il cuore del caso

Questo caso mostra un workflow di analisi assistita dall’AI governato da decisione scritta, fonti verificate e controlli con soglia, dove il modello prepara e un responsabile umano firma la raccomandazione.

Il metodo in sei passi

Ecco lo scheletro che governa tutto il caso.

1. Scrivi la decisione con verbo operativo, popolazione, scadenza e proprietario prima di toccare i dati.
2. Mappa le fonti con schema, chiavi, copertura e buchi noti, e verifica ogni riga interrogando il magazzino dati.
3. Elenca i modi in cui potresti ingannarti e scrivi per ciascuno il controllo con soglia prima di modellare.
4. Fissa la baseline onesta e la metrica decisionale legata al costo, poi modella con split temporale rigoroso.
5. Separa nel memo evidenza, ipotesi e raccomandazione, con condizione di stop e piano di monitoraggio.
6. Automatizza solo il reversibile con permessi minimi e traccia append-only; ogni scrittura resta approvata da un umano.

Dove l’AI aiuta davvero e dove deve fermarsi

Il primo errore nei progetti AI-assisted è trattare il modello come un analista autonomo. Gli si incolla un CSV e si chiede “perché il churn sale?”, ottenendo un paragrafo fluente che mescola cause vere, correlazioni spurie e dettagli inventati. Il secondo errore, opposto, è usarlo come semplice completamento di codice, sprecando la sua capacità più utile: tenere insieme contesto, checklist e documentazione mentre l’analista ragiona.

Nel caso del churn, la divisione dei compiti che funziona è netta. All’AI vanno compiti ad alta superficie e basso rischio: riformulare la domanda business in domande misurabili, proporre un piano di esplorazione dati, abbozzare query SQL e test di qualità, suggerire segmentazioni alternative, redigere la prima bozza del memo. All’umano restano tre responsabilità non delegabili: definire la metrica e la soglia decisionale, validare che i dati rappresentino davvero il fenomeno, firmare la raccomandazione che muove budget o roadmap.

Una regola operativa aiuta a non sbagliare confine: ogni azione dell’AI è classificata come lettura, proposta o scrittura. La lettura (esplorare schemi, profili, distribuzioni) è libera. La proposta (ipotesi, query, grafici) richiede una verifica umana rapida. La scrittura (modificare pipeline, tabelle di produzione, modelli deployati, comunicazioni al cliente) richiede approvazione esplicita e tracciata. Quando un team adotta questa matrice, le review smettono di discutere “cosa ha detto l’AI” e iniziano a discutere “cosa abbiamo verificato”.

Activities	Ruolo AI	Controllo umano
Chiarire domanda e metrica	Propone formulazioni alternative	Owner conferma definizione e soglia
Profilare dati e tracking	Genera checklist e query di controllo	Analista esegue e interpreta i test
Esplorare segmenti	Suggerisce tagli non ovvi	Verifica numerosità e stabilità
Modellare e validare	Prepara baseline e pipeline AutoML	Approva split temporale e guardrail
Comunicare risultati	Redige memo e grafici	Separa evidenza, ipotesi, raccomandazione

Anatomia di un workflow governato: decisione, contesto, verifica

Ogni workflow solido parte dalla fine: quale scelta deve migliorare e con quale criterio. “Ridurre il churn” non è una decisione, è un auspicio. “Decidere entro venerdì se offrire uno sconto di rinnovo al segmento onboarding con health score sotto 40” è una decisione: ha un owner, una scadenza, un’azione e un costo. L’AI è utile già qui, perché costringe a esplicitare verbo operativo, popolazione target e metrica di successo prima di toccare i dati.

Il secondo strato è il contesto: fonti, granularità, periodo, definizioni. In un SaaS tipico i segnali vivono in posti diversi — CRM per i contratti, eventi prodotto per l’uso, ticket di supporto per la frizione, pagamenti per i rinnovi — e ognuno ha il suo ritardo, la sua chiave di join, i suoi buchi. Un assistente AI ben istruito produce in pochi minuti una mappa delle fonti con schema, chiave, copertura temporale e problemi noti, ma sta all’analista confermare ogni riga interrogando davvero il warehouse. La mappa non verificata è letteratura, non documentazione.

Il terzo strato è la verifica: quale errore, se presente, ribalterebbe la raccomandazione. Prima di modellare, il team elenca i modi in cui potrebbe ingannarsi — leakage temporale, cambio nel tracking, stagionalità, segmento troppo piccolo, definizione di churn incoerente tra tabelle — e per ciascuno scrive il controllo corrispondente. Questo elenco diventa la checklist della review finale: nessun memo viene approvato se un controllo è rimasto rosso o non eseguito. L’esperienza insegna che i progetti falliscono raramente per il modello sbagliato e spesso per il controllo saltato.

Dal brief al dataset pronto: ingestion e profilazione assistita

Il brief del caso è volutamente stretto: churn logo mensile su contratti SMB, finestra di osservazione gennaio-giugno, decisione attesa entro due settimane. L’AI trasforma questo paragrafo in un contratto dati: tabella cliente-mese con una riga per ogni cliente attivo a inizio mese, colonna target ha_churnato, feature agganciate solo a informazioni disponibili prima dell’inizio del mese. Sembra burocrazia, ma è qui che si gioca la credibilità dell’intero progetto: se una feature “predittiva” contiene informazioni posteriori alla data di osservazione, ogni metrica successiva è finta.

La profilazione assistita segue uno script fisso che l’AI genera e l’analista esegue. Per ogni tabella sorgente: conteggio righe e chiavi duplicate, copertura temporale e buchi, distribuzione delle colonne critiche, tasso di null e valori impossibili, confronto tra definizioni alternative della stessa metrica. In casi reali, questo passaggio scopre quasi sempre qualcosa: un cambio di versione dell’SDK che dimezza gli eventi di login da un certo mese, una migrazione CRM che riassegna gli owner dei segmenti, una definizione di “cliente attivo” che include trial mai convertiti. Ognuna di queste scoperte vale più di qualsiasi iperparametro.

Il codice che segue è il tipico artefatto AI-assisted: bozza generata dal modello, rivista e firmata dall’analista. Costruisce la coorte cliente-mese con regola temporale esplicita, così la review può verificare che nessuna informazione futura filtri nel training set.

-- Costruisce la coorte cliente-mese: una riga per cliente attivo a inizio mese
-- Il target guarda solo i 30 giorni successivi (nessun dato futuro nelle feature)
WITH coorte AS (
  SELECT
    c.customer_id,
    DATE_TRUNC('month', d.mese) AS mese_osservazione,
    MAX(CASE WHEN s.data_chiusura BETWEEN d.mese AND d.mese + INTERVAL '30 days'
      THEN 1 ELSE 0 END) AS ha_churnato
  FROM clienti c
  JOIN calendario d ON d.mese BETWEEN '2025-01-01' AND '2025-06-01'
  LEFT JOIN chiusure s
    ON s.customer_id = c.customer_id
  WHERE c.data_attivazione < d.mese -- cliente già attivo a inizio mese
  GROUP BY 1, 2
)
SELECT * FROM coorte ORDER BY mese_osservazione, customer_id;

Il controllo gemello verifica la stabilità della metrica nel tempo: tasso di churn per mese e per segmento, numerosità minima per cella, confronto tra calcolo su popolazione intera e su gruppi di attivazione. Se il churn di un mese raddoppia solo in un segmento mentre gli altri restano piatti, la storia “il prodotto peggiora per tutti” crolla e il brief si restringe al segmento giusto. L’AI suggerisce i tagli, ma è il test di numerosità a decidere quali tagli meritano fiducia: sotto poche centinaia di unità per cella, le variazioni percentuali vanno lette come rumore finché non si accumulano più mesi.

Modellare senza farsi ingannare: AutoML, leakage e baseline oneste

Con il dataset pronto, la tentazione è lanciare subito AutoML e inseguire la metrica. Il workflow governato impone prima una baseline stupida ma onesta: “predici che churnerà chi ha fatto login meno di due volte negli ultimi 14 giorni”. Questa regola costa dieci righe di SQL, gira in secondi e fissa l’asticella: se un gradient boosting con quaranta feature guadagna solo un punto rispetto alla regola, forse il problema non è il modello ma i segnali disponibili.

Lo split temporale è il punto dove i progetti churn muoiono in silenzio. Mescolare righe di mesi diversi in un train-test casuale significa far vedere al modello il futuro: impara pattern di maggio per “predire” aprile e le metriche sembrano ottime finché il modello incontra davvero un mese mai visto. La configurazione corretta è walk-forward, cioè avanzamento della finestra nel tempo: si allena sui primi mesi, si valida sul successivo, si testa sugli ultimi, e ogni feature è ricalcolata con cutoff temporale rigoroso. L’AI serve a generare lo scheletro della pipeline e a ricordare i controlli, non a scegliere scorciatoie.

La metrica decisionale va fissata prima di modellare, non dopo. Se il team customer success può contattare solo cento account al mese, la metrica che conta è la precisione nel segmento a rischio contattabile, e tutto il resto è diagnostica. Un modello con metrica globale alta ma lift vicino a 1 nel segmento raggiungibile è inutile; uno con metrica globale modesta ma concentrazione tripla del churn nel primo segmento contattabile è prezioso. L’AI documenta la scelta in una model card di una pagina: popolazione, finestra, esclusioni, metriche, limiti noti, costo di inferenza.

Il caso churn: dal segnale grezzo alla raccomandazione difendibile

La storia del caso procede in tre atti. All’allarme iniziale — churn mensile in salita nel trimestre — l’AI propone tre ipotesi: degrado del prodotto, cambio nel mix di acquisizione, problema di tracking. L’analista le traduce in controlli: gruppi di attivazione contro churn, distribuzione del canale di acquisizione per mese, confronto tra eventi grezzi e tabelle aggregate.

Il secondo atto ribalta la prima impressione. Segmentando per gruppo di attivazione, i clienti storici restano stabili mentre le attivazioni recenti abbandonano a tassi molto più alti. Incrociando con il canale, emerge che da qualche mese la maggioranza delle nuove attivazioni arriva da una campagna a basso attrito con onboarding leggero e quasi senza login nei primi 14 giorni. Il “peggioramento del prodotto” era in realtà un cambio di mix: utenti con intento più debole che il prodotto attuale non trattiene. La baseline più semplice — pochi login nelle prime due settimane — cattura già gran parte dei churner con precisione utile nel segmento contattabile.

Il terzo atto trasforma la diagnosi in decisione. Il modello completo (uso delle prime due settimane, ticket di supporto, ritardi di pagamento, settore, dimensione account) alza la precisione nel segmento a rischio rispetto alla baseline, e il memo finale quantifica il valore atteso del contatto contro il suo costo: contattare il segmento a rischio con un playbook di onboarding assistito resta conveniente anche se il modello sovrastima, e la campagna di acquisizione va rivista perché porta utenti che il prodotto non trattiene. Evidenza, ipotesi e raccomandazione restano in paragrafi separati, così la review può bocciare la raccomandazione senza bocciare l’analisi.

Controlli che reggono una review: qualità, costo e guardrail operativi

Un memo convincente senza controlli è un editoriale. Il workflow del caso ne prevede cinque, ciascuno con owner e soglia scritti prima dell’esecuzione. Il controllo di granularità verifica che join e aggregazioni non duplichino righe: conteggio clienti per mese prima e dopo ogni join, con tolleranza zero sui duplicati di chiave. Il controllo di leakage elenca ogni feature con la sua data di disponibilità e fallisce se una sola usa informazioni posteriori al cutoff. Il controllo di stabilità confronta le distribuzioni delle feature tra train e test con PSI o semplice confronto di medie e code: uno spostamento improvviso segnala drift o rottura del tracking prima ancora di guardare le metriche.

# Controllo anti-leakage: ogni feature deve esistere prima del cutoff mensile
# Eseguire per ogni mese di osservazione; fallire se una feature "vede il futuro"
import pandas as pd

def verifica_cutoff(df: pd.DataFrame, col_data: str, cutoff: pd.Timestamp) -> list:
    # Raccoglie le colonne con timestamp massimo oltre il cutoff (sospette)
    sospette = []
    for col in df.columns:
        if "data_" in col or "timestamp" in col:  # convenzione nomi temporali
            if pd.to_datetime(df[col]).max() > cutoff:
                sospette.append(col)  # da escludere o ricalcolare
    return sospette  # lista vuota = controllo superato

Il quarto controllo è economico e spesso dimenticato: quanto costa far girare tutto questo ogni mese. Profilazione, retraining AutoML, inferenza batch e reportistica hanno un costo in compute, storage e ore umane che va confrontato con il valore atteso dei salvataggi. La decisione documentata è retraining trimestrale con monitoraggio intermedio leggero, e retraining straordinario solo se il PSI supera 0,25 o la precisione nel segmento a rischio scende sotto soglia per due mesi consecutivi. Il quinto controllo è privacy e accessi: quali colonne identificative servono davvero, chi può vedere i punteggi di rischio, dove vengono loggati gli accessi. I punteggi di churn sono dati sensibili quando guidano offerte differenziate: il memo specifica retention, mascheramento e divieto di uso per pricing punitivo.

Automazione prudente: agenti, permessi e monitoraggio continuo

Fin qui il workflow è AI-assisted: l’AI propone, l’umano esegue e firma. Il passo successivo — agenti che eseguono davvero query, aprono ticket, aggiornano dashboard — è dove i team si fanno male. L’approccio del caso è gradualista: si automatizza prima ciò che è reversibile e ben testato, si tiene umano tutto ciò che tocca soldi, clienti o produzione. La profilazione mensile e il report di drift girano in automatico perché un falso allarme costa una notifica, non un danno. Il retraining e l’invio di offerte restano semi-automatici: l’agente prepara tutto, l’owner approva con un clic dopo aver visto metriche e diff.

I permessi sono il vero design del sistema agentico, non il prompt. Ogni agente ha un’identità con scope minimo: lettura su schemi documentati, scrittura solo su tabelle sandbox, mai credenziali di produzione, mai invio diretto al cliente. Le azioni sono divise in tre fasce: libere (leggere metadati, generare bozze), approvate (scrivere in staging, aprire MR, schedulare job di test), vietate (modificare pipeline di produzione, cancellare dati, contattare clienti, cambiare soglie decisionali). Ogni esecuzione lascia una traccia append-only — input, tool chiamati, query eseguite, output prodotti — così un incidente si ricostruisce riga per riga invece di restare “l’agente ha fatto qualcosa”.

Il monitoraggio chiude il cerchio e ha due facce: tecnica e di business. Quella tecnica osserva volumi di input, tasso di null, distribuzioni delle feature, latenza e costo per run, deriva delle predizioni. Quella di business osserva ciò che conta davvero: precisione nel segmento a rischio sui mesi nuovi, tasso di contatto andato a buon fine, rinnovi salvati al netto del gruppo di confronto. Quando la precisione scende per due mesi o il mix di acquisizione cambia di nuovo, il sistema non “si adatta da solo”: alza un flag, congela le azioni automatiche e chiede una review. L’automazione matura non è quella che non sbaglia mai, è quella che sbaglia in modo visibile e reversibile.

Il cancello economico dell’intero workflow è una disequazione semplice: finché il valore atteso del contatto — probabilità di salvataggio per valore del rinnovo meno costo del contatto — resta positivo con margine, il processo merita di girare; quando il margine si assottiglia, la decisione onesta è fermarsi o ridisegnare, non aggiungere complessità. L’AI può ricalcolare il margine ogni mese, ma la soglia di stop la firma l’owner a inizio progetto, quando è ancora lucido.

Portare il metodo nel lavoro quotidiano

Il valore del caso non è il modello churn, che ogni azienda sostituirà con il proprio problema — forecast della domanda, scoring dei lead, triage dei ticket, controllo qualità delle pipeline. Il valore è lo scheletro riutilizzabile: brief con decisione e soglia, mappa delle fonti verificata, checklist anti-leakage, baseline onesta, metrica decisionale fissata prima di modellare, memo che separa evidenza da raccomandazione, piano di monitoraggio con condizione di stop. Chi adotta lo scheletro scopre che i progetti successivi costano la metà, perché metà del lavoro — definizioni, controlli, template — è già pronta.

Tre abitudini fanno la differenza nei team che funzionano. La prima è la scheda di una pagina per ogni analisi: decisione, input, output, controllo minimo, rischio principale. Se non sta in una pagina, il pensiero non è ancora chiaro. La seconda è la tabella dei tre scenari — manuale, assistito, spinto — con tempo, qualità, rischio e owner per ciascuno: impedisce di automatizzare per moda e costringe a prezzare il rischio. La terza è il memo revisionabile con sezione “cosa ci farebbe cambiare idea”: elenca in anticipo quali nuovi dati ribalterebbero la raccomandazione, così la review futura ha un criterio invece di un’opinione.

Quando questo metodo non basta e come accorgersene

Nessun workflow governato salva un problema mal posto. Se la decisione reale è politica — tagliare un segmento per motivi di budget indipendentemente dai dati — l’analisi più rigorosa diventa teatro. Se i dati di base mancano — tracking rotto da mesi, definizioni incoerenti tra team, nessun log degli interventi passati — la profilazione assistita lo rivela in giorni invece di settimane, e l’esito onesto è “fermarsi e sistemare le fondamenta” invece di modellare sul rumore. Se il fenomeno è troppo raro o troppo veloce — frodi nuove ogni settimana, churn di pochi grandi account dove ogni caso è una storia a sé — il modello statistico aggiunge poco e conviene investire in interviste e analisi caso per caso.

I segnali di allarme sono riconoscibili: metriche che migliorano solo in validazione casuale ma crollano in walk-forward, feature importance dominata da una colonna che “sa troppo”, stakeholder che chiedono di rimuovere i controlli perché rallentano, memo dove evidenza e raccomandazione si mescolano nello stesso paragrafo. Ognuno di questi è un ordine di stop, non un dettaglio. Il team maturo preferisce un “non lo sappiamo ancora” documentato a una risposta fluente non verificata, perché la prima frase costa una settimana e la seconda può costare un trimestre di decisioni sbagliate.

Strumenti e letture per andare oltre

Sul lato pratico, gli strumenti cambiano in fretta ma le funzioni restano: un SDK per orchestrare agenti con permessi e tracciamento, una piattaforma AutoML per baseline rapide su dati tabulari, un registry per versionare dataset e modelli, un sistema di monitoraggio per drift e metriche di business. La documentazione di riferimento resta quella ufficiale — OpenAI Agents SDK per i pattern agentici, Vertex AI e Azure AutoML e SageMaker Autopilot e Databricks AutoML per il tabular modeling gestito — da leggere come specifiche di comportamento e limiti, non come ricette da copiare. Prima di adottare qualsiasi componente, la domanda è sempre la stessa: cosa logga, cosa permette di vietare, come si fa rollback.

Il filo che unisce tutto il caso sta in tre righe scritte prima di partire: quale scelta vogliamo migliorare, quale dato può sostenerla, quale rischio ci fermerebbe. Quando queste righe esistono e restano visibili fino al memo finale, l’AI diventa davvero un moltiplicatore: più ipotesi esplorate, più controlli eseguiti, più alternative documentate, a parità di ore umane. Quando mancano, l’AI moltiplica solo la velocità con cui si producono output non verificabili.

Verdetto: lettura libera, proposta verificata, scrittura approvata; fuori da questa matrice l’agente non opera.

Il caso Target raccontato dal New York Times

Nel 2012 il New York Times raccontò come la catena Target prevedesse le gravidanze delle clienti dai cambiamenti nelle abitudini di acquisto, fino a inviare coupon per neonati a una teenager prima che la famiglia sapesse. Il modello funzionava e i dati c’erano: mancava il governo del workflow, con controlli sull’uso consentito, proprietario della decisione e revisione dell’impatto. È il promemoria di questa lezione: un’analisi corretta nei numeri può fallire nel processo, e il processo va disegnato prima del modello.

Domande per chiudere la lezione

1. Quali tre responsabilità non deleghi mai al modello in un workflow sui dati?
2. Perché la metrica decisionale va fissata prima di modellare e a cosa serve la baseline onesta?
3. Quale controllo rivela una feature che usa informazioni posteriori al momento della predizione?
4. Cosa distingue un permesso di lettura da un’azione vietata per un agente sui dati?