Agentic AutoML: planning, training, review, and deploy

Un team marketing chiede una previsione del churn entro venerdì. L’analista apre un notebook e un agente AI propone di lanciare da solo un esperimento AutoML su tutti i dati disponibili, confrontare quaranta configurazioni e mettere in produzione il modello migliore. Sembra efficienza, ma è il punto esatto in cui i progetti AutoML falliscono: non per mancanza di accuratezza, ma perché nessuno ha definito cosa il modello deve prevedere davvero, su quali clienti verrà applicato e chi risponde se sbaglia. Il modello brillante che usa come segnale la data di disdetta è tecnicamente ottimo e operativamente inutile. La lezione appartiene al binario sistemi-llm.

Questa è la differenza tra AutoML classico e AutoML agentico. Il primo è un ottimizzatore: esplora iperparametri e architetture dentro uno spazio che un umano ha delimitato. Il secondo è un orchestratore semi-autonomo che può decidere quali dati usare, quali feature costruire, quando fermare il training e se proporre il deploy. Quella autonomia riduce il lavoro ripetitivo, ma sposta il rischio: ogni decisione che l’agente prende senza controllo diventa un’assunzione silenziosa dentro il modello finale. Governare queste assunzioni è il lavoro di questa guida.

Perché l’AutoML agentico è diverso dall’AutoML classico

L’AutoML tradizionale risponde a una domanda chiusa: dato un dataset fissato, una metrica e un budget computazionale, trova la configurazione che massimizza la metrica in validazione. Strumenti come FLAML, Auto-sklearn o le pipeline di H2O fanno esattamente questo, e lo fanno bene. Il perimetro è chiaro perché l’umano ha già deciso target, feature, split e metrica.

Un agente AutoML opera un livello sopra. Riceve un obiettivo in linguaggio naturale, per esempio prevedi quali abbonati annuali disdiranno nei prossimi 30 giorni, e deve tradurlo in specifica addestrabile, interrogare il catalogo dati, costruire feature, lanciare training multipli, interpretare i risultati e preparare un artefatto di deploy. Ognuno di questi passaggi richiede giudizio: quale tabella è la fonte di verità per le disdette, se includere il segmento enterprise con soli 300 esempi, se un miglioramento minimo giustifica un modello tre volte più lento in inferenza.

Il guadagno è concreto. In un flusso manuale, passare dalla richiesta alla prima baseline richiede giorni di query esplorative, controlli di qualità e andata e ritorno con il business. Un agente ben vincolato produce in ore una data card, una baseline e un primo esperimento confrontabile. Il prezzo è che gli errori diventano sistemici: se l’agente fraintende la definizione di churn e include le pause temporanee insieme alle disdette definitive, ogni modello a valle eredita l’errore e lo amplifica con ottima calibrazione apparente.

Per questo serve una matrice di autonomia esplicita, concordata prima di accendere l’agente:

Azione dell’agente	Autonomia concessa	Controllo richiesto
Profilare dataset e proporre target	Autonomo	Data card revisionabile
Costruire feature da tabelle approvate	Autonomo entro allowlist	Diff delle feature + test di leakage
Lanciare training sotto budget	Autonomo	Tracking esperimenti immutabile
Scegliere il modello “migliore”	Solo proposta	Review umana su metrica + segmenti
Scrivere su staging	Con approvazione	Test di integrazione verdi
Promuovere in produzione	Mai autonomo	Deploy gate firmato da owner

Questa tabella va scritta nel runbook del team, non lasciata nelle impostazioni di default del framework agentico. I riferimenti tecnici per l’orchestrazione, OpenAI Agents SDK e LangGraph, forniscono gli strumenti per implementare questi gate come nodi espliciti del grafo, non come suggerimenti nel prompt di sistema.

Dal problema di business alla specifica addestrabile

Il planning è la fase dove si vince o si perde il progetto, e dove l’agente ha più bisogno di vincoli. Il suo compito è trasformare prevedi il churn in una specifica che un sistema di training possa eseguire senza ambiguità: popolazione, finestra di osservazione, definizione del target, metrica primaria, vincoli operativi. Ogni voce lasciata vaga verrà riempita dall’agente con un default plausibile e raramente documentato.

Un formato che funziona è la scheda di planning, un documento strutturato che l’agente compila e l’umano approva prima che parta qualsiasi training. Deve contenere almeno: popolazione eleggibile (abbonati annuali attivi al primo del mese, esclusi trial e account interni), istante di predizione per ogni riga, finestra feature di 90 giorni prima, finestra target di 30 giorni dopo, definizione operativa del target (disdetta confermata nel CRM, non semplice mancato login), metrica primaria legata alla decisione (se il modello pilota una campagna retention con budget per 5.000 contatti, la precisione su quei contatti conta più del punteggio globale), e vincoli (latenza di inferenza sotto 200 ms, niente dati di geolocalizzazione fine per policy privacy).

Il punto delicato è l’istante di predizione. Un errore classico degli agenti è costruire il dataset con una query che unisce clienti e disdette senza fissare l’istante di predizione: il risultato è una tabella dove le feature contengono informazioni posteriori all’evento da prevedere. La regola da imporre è meccanica: ogni riga di training deve poter rispondere alla domanda cosa sapevo esattamente in quel momento. Se una colonna non supera questo test, data di disdetta, motivo di chiusura ticket aperto dopo, ultimo pagamento dentro la finestra target, va esclusa o spostata. L’agente può proporre feature, ma il gate temporale va implementato come test automatico, non come raccomandazione.

C’è poi la questione della metrica. Il default di quasi ogni libreria AutoML non è quasi mai la metrica giusta per decidere. Se il costo di un falso positivo, contattare un cliente fedele con uno sconto inutile, è di pochi euro e il valore di un vero positivo, trattenere un abbonato da 240 euro annui, è un ordine di grandezza superiore, la soglia operativa e la metrica vanno derivate da questi numeri. L’agente deve ottimizzare e riportare il valore atteso alla soglia proposta, non solo i punteggi tecnici globali. Se il team non conosce valore e costo nemmeno in modo approssimato, il planning non è finito: meglio una stima con intervallo dichiarato che un default tecnico scollegato dal business.

Infine, il planning stabilisce il budget: numero massimo di configurazioni, ore-macchina, costo stimato. Senza tetto, un agente lasciato libero di provare finché migliora brucia budget per guadagni marginali: tipicamente oltre le prime 20-30 configurazioni il miglioramento mediano per trial crolla mentre il costo resta lineare. Fissare il budget in anticipo trasforma lo stopping da decisione ansiosa a regola eseguibile.

Feature, split temporale e il test che smaschera il leakage

Con la specifica approvata, l’agente costruisce il dataset. Qui valgono tre vincoli non negoziabili: sorgenti da allowlist, trasformazioni deterministiche e versionate, split che rispetta il tempo. Ognuno merita un controllo automatico perché gli errori a questo livello sono invisibili nelle metriche, anzi, il leakage le gonfia, rendendo i modelli sbagliati i più convincenti.

L’allowlist delle sorgenti significa che l’agente può leggere solo tabelle registrate nel catalogo con owner e livello di qualità noti. Sembra burocrazia, ma evita il failure mode più comune: l’agente trova un CSV in una cartella condivisa con un nome che sembra definitivo, lo usa perché sembra il più completo, e nessuno sa come è stato generato. Se una tabella non è nel catalogo, l’agente deve proporne l’onboarding, non usarla in silenzio.

Lo split temporale è il secondo pilastro. Mai split casuale su dati con dimensione temporale: mescolare righe di gennaio e novembre tra train e validation significa far vedere al modello il futuro e poi congratularsi per la sua preveggenza. Lo schema corretto è a finestre ancorate: training sugli istanti più vecchi, validation su quelli intermedi, test sui più recenti, con un embargo tra le finestre pari alla durata della finestra target, 30 giorni nell’esempio churn, così che nessun evento target attraversi i confini. In produzione il modello vedrà sempre dati più recenti di quelli di training: la validation deve replicare questa asimmetria o le stime sono ottimistiche per costruzione.

Il test anti-leakage più economico è brutale ed efficace: addestra un modello usando come unica feature ciascuna colonna candidata e segnala quelle con potere predittivo singolo quasi perfetto. Una singola colonna quasi perfetta è quasi sempre una perdita di informazione futura, non un segnale legittimo. Un secondo test calcola la stabilità temporale: una feature il cui potere predittivo crolla tra validation e test ravvicinati merita un’indagine prima del deploy. Entrambi i test girano in minuti e vanno inseriti nella pipeline dell’agente come step obbligatori, con esito registrato nel tracking.

# Controllo anti-leakage per singola colonna, eseguito prima del training completo
import pandas as pd
from sklearn.model_selection import cross_val_score
from sklearn.tree import DecisionTreeClassifier

def segnala_colonne_sospette(df: pd.DataFrame, target: str, soglia_auc: float = 0.85) -> pd.DataFrame:
    # Addestra un alberello per colonna: potere predittivo individuale
    righe = []
    modello = DecisionTreeClassifier(max_depth=3, random_state=42)
    for colonna in df.columns:
        if colonna == target:
            continue
        # Solo colonne numeriche o categoriche semplici in questo screening
        X = pd.get_dummies(df[[colonna]], drop_first=True)
        punteggi = cross_val_score(modello, X, df[target], cv=3, scoring="roc_auc")
        righe.append({"colonna": colonna, "auc_media": round(float(punteggi.mean()), 3)})
    report = pd.DataFrame(righe).sort_values("auc_media", ascending=False)
    # Restituisce le colonne sopra soglia: da revisionare prima di approvarle
    return report[report["auc_media"] >= soglia_auc]

Il training orchestrato sotto budget

Il training è la parte che l’agente gestisce meglio, a patto di delimitarla. Search space dichiarato in anticipo (famiglie di modelli ammesse, range di iperparametri), strategia di ricerca (random, bayesiana, evolutiva), budget in numero di trial e ore-macchina, seed fissati per la riproducibilità. Ogni trial scrive in un experiment tracker immutabile, MLflow, Weights and Biases o equivalente, con dataset hash, codice hash, iperparametri, metriche su tutte le finestre e artefatto modello. Senza questa tracciabilità, il modello migliore è un’affermazione non verificabile.

Due regole operative contano più di qualsiasi scelta di algoritmo. Primo, baseline prima della ricerca: un modello logistico su una manciata di feature ovvie e un gradient boosting con default ragionevoli. Se l’AutoML non batte la baseline di un margine che giustifica la complessità aggiuntiva, si deploya la baseline. Un modello interpretabile leggermente sotto il migliore batte un ensemble opaco che nessuno sa debuggare alle tre di notte. Secondo, early stopping a due livelli: dentro il singolo trial (ferma se la validation non migliora per un numero fissato di round) e tra trial (ferma la ricerca se gli ultimi trial non migliorano il best oltre una soglia minima). Con parametri standard si taglia tipicamente il 30-40 per cento del budget senza perdere il modello finale.

La review del modello: dove i numeri incontrano i segmenti

Finito il training, l’agente prepara una model card e propone un vincitore. La review umana inizia qui e non consiste nel guardare il punteggio globale, consiste nel cercare il segmento dove il modello fallisce. L’esperienza insegna che i modelli AutoML sono ottimi in media e fragili ai margini: perfetti sui clienti consumer con due anni di storia, inaffidabili sugli enterprise con 300 esempi o sui nuovi mercati con distribuzioni diverse.

La strumentazione minima della review comprende quattro viste. La matrice di confusione alla soglia operativa proposta, con costi espliciti: quanti falsi positivi (sconti sprecati) e falsi negativi (abbandoni non intercettati) produce su 10.000 clienti tipo. Le metriche per segmento, per piano tariffario, anzianità, canale di acquisizione, area, con intervalli: un segmento con 200 righe e precisione alta ha un intervallo così largo da non dire quasi nulla, e va segnalato come non valutabile invece che celebrato. Le curve di calibrazione: se il modello assegna probabilità 0,7 a un gruppo, circa il 70 per cento di quel gruppo deve davvero abbandonare, altrimenti le soglie operative sono calibrate sul nulla. Infine l’importanza delle feature con controllo di plausibilità: se tra le prime tre compare una variabile amministrativa (codice filiale, id operatore), qualcosa nella costruzione del dataset puzza.

L’explainability serve a questa revisione, non a rassicurare gli stakeholder con grafici colorati. I valori SHAP per i casi peggiori, i falsi negativi ad alto valore, i falsi positivi più costosi, raccontano più della media globale: mostrano quali pattern il modello ha imparato e se corrispondono a meccanismi di business riconoscibili o a correlazioni spurie del periodo di training. Un modello churn che pesa moltissimo il numero di ticket aperti merita una domanda: i ticket predicono l’abbandono o il processo di disdetta genera ticket. La distinzione decide se la feature è oro o leakage.

C’è un caso in cui la review deve bocciare anche modelli accurati: quando il margine sul segmento protetto o strategico è inaccettabile. Se il modello funziona sul mercato principale e crolla sul mercato dove l’azienda sta investendo per crescere, deployarlo significa automatizzare proprio l’errore più costoso. La decisione corretta è restringere il perimetro di deploy al segmento validato e raccogliere dati sul resto, non forzare una copertura totale con qualità disomogenea.

# Report per segmento con intervallo di confidenza (approssimazione normale)
import numpy as np
import pandas as pd

def report_per_segmento(df: pd.DataFrame, colonna_segmento: str, pred: np.ndarray, soglia: float = 0.5) -> pd.DataFrame:
    # df deve contenere la colonna 'target' con etichette 0/1
    lavoro = df[[colonna_segmento, "target"]].copy()
    lavoro["predetto"] = (pred >= soglia).astype(int)
    righe = []
    for segmento, g in lavoro.groupby(colonna_segmento):
        tp = int(((g["predetto"] == 1) & (g["target"] == 1)).sum())
        fp = int(((g["predetto"] == 1) & (g["target"] == 0)).sum())
        n = len(g)
        prec = tp / (tp + fp) if (tp + fp) > 0 else float("nan")
        # Intervallo di Wilson semplificato via normale per campioni non minuscoli
        se = np.sqrt(prec * (1 - prec) / max(tp + fp, 1)) if not np.isnan(prec) else float("nan")
        righe.append({"segmento": segmento, "n": n, "precision": round(prec, 3), "ic95": round(1.96 * se, 3) if se == se else None})
    return pd.DataFrame(righe).sort_values("n", ascending=False)

Il deploy gate: l’agente propone, l’umano firma

Il deploy è l’unico passaggio che non si delega mai del tutto. Il deploy gate è una checklist eseguibile con owner nominato, e l’agente può raccogliere le evidenze ma non auto-approvarsi. Le voci minime: test di integrazione verdi su staging (schema input, latenza p95, fallback se il feature store non risponde), confronto shadow o canary contro il modello incumbent su traffico reale per almeno un ciclo decisionale completo, piano di rollback testato (a quale versione si torna, con quale comando, in quanti minuti), owner di turno per le prime due settimane, e soglie di allarme quantitative già configurate nel sistema di monitoraggio.

Lo shadow deploy merita attenzione perché è lo strumento che concilia velocità e prudenza: il nuovo modello gira su dati reali e registra le sue predizioni senza influenzare le decisioni, mentre l’incumbent resta in controllo. Dopo due o quattro settimane si confrontano le predizioni shadow con gli esiti osservati. Se il modello conferma in shadow il guadagno visto in validation, il canary (5-10 per cento del traffico reale) diventa un passo breve. Saltare lo shadow per fiducia nella validation è il classico risparmio che costa un incidente: la validation misura il passato campionato con cura, lo shadow misura il presente con tutti i suoi difetti di pipeline.

Dopo il deploy: drift, costi e il momento di spegnere tutto

Un modello in produzione è un’ipotesi sul mondo che invecchia. Il monitoraggio distingue tre segnali che l’agente può sorvegliare in autonomia, con soglie che fanno scattare review umane. Il drift dei dati, quando la distribuzione delle feature cambia (nuovo piano tariffario, nuova app che altera il pattern di login), si misura con test per colonna e distanza di popolazione; il drift del concetto, quando la relazione tra feature e target cambia (una crisi economica rende il prezzo più determinante della soddisfazione), si vede solo dal degrado delle metriche osservate con ritardo, visto che il target churn arriva 30 giorni dopo la predizione. Il terzo segnale è operativo: latenza, tasso di errori del feature store, costo inferenziale per 1.000 predizioni.

La trappola del monitoraggio è fissare soglie che allarmano sempre o mai. Una pratica robusta: per ogni metrica chiave, fascia verde (fluttuazione normale, nessuna azione), fascia ambra (l’agente apre un ticket diagnostico con analisi preliminare: quale segmento degrada, da quando, con quale ipotesi), fascia rossa (rollback automatico o semi-automatico secondo runbook). Le soglie si tarano sui primi 60-90 giorni osservando la variabilità reale, non copiando default da blog. Il rollback va provato davvero almeno una volta in staging: un piano mai eseguito è un documento motivazionale, non un controllo.

I costi meritano un rigo dedicato perché l’AutoML agentico li rende opachi. Training ripetuti tanto l’agente li lancia da solo, feature store interrogato a ogni esperimento, endpoint sovradimensionati per il canary dimenticato attivo da tre mesi. Il runbook assegna all’agente un budget mensile di esperimenti e un report costi per progetto: quando il costo cumulativo supera il valore atteso stimato nella scheda di planning, il progetto si ferma e si rivaluta. È aritmetica, non pessimismo.

Cosa automatizzare davvero e cosa tenere umano

Dopo aver visto l’intero ciclo, la domanda iniziale, quando l’agente può procedere da solo, ha una risposta pratica. Autonomo: profilazione dati, data card, baseline, screening anti-leakage, esecuzione di trial entro budget, report per segmento, diagnostica di drift in fascia ambra. Con approvazione: scelta del target e delle sorgenti fuori allowlist, selezione del modello vincitore, scrittura su staging, canary. Mai autonomo: deploy in produzione, ampliamento del perimetro a segmenti non validati, gestione di dati con vincoli privacy oltre il consenso esistente.

Tre errori ricorrono abbastanza da meritare un nome. L’oracolo opaco: l’agente consegna predizioni senza data card né model card, e il team le usa perché tanto è scientifico. La metrica orfana: si ottimizza il punteggio globale mentre il business paga per precisione a budget fisso, e il modello migliore distrugge valore. Il perimetro strisciante: il modello validato sui consumer viene applicato agli enterprise in via sperimentale senza nuova review, e l’esperimento diventa permanente. Ognuno si previene con un artefatto già descritto: schede revisionabili, metrica derivata dai costi, deploy gate con perimetro esplicito.

Il filo che unisce planning, training, review e deploy è uno solo: ogni decisione dell’agente deve lasciare una traccia che un umano può leggere, criticare e rovesciare. Quando questa tracciabilità c’è, l’AutoML agentico mantiene la promessa, più esperimenti, più veloci, con meno lavoro ripetitivo. Quando manca, è solo automazione della fretta: modelli che sembrano ottimi finché qualcuno non chiede come sono arrivati a quel numero, e a quel punto è tardi.

Verdetto: lascia all’agente profilazione, trial entro budget e diagnostica, chiedi approvazione su target, modello vincitore e staging, e non delegare mai deploy, perimetro e dati con vincoli privacy.

Il principio in una frase

L’AutoML agentico decide quali passi di planning, training e review l’agente esegue da solo e quali richiedono firma umana prima del deploy.

La sequenza operativa in cinque passi

1. Approva la scheda di planning con popolazione, finestre, target operativo e budget.
2. Costruisci il dataset solo da sorgenti in allowlist con split temporale ed embargo.
3. Esegui screening anti-leakage e baseline prima di lanciare la ricerca completa.
4. Lancia i trial entro budget con tracking immutabile ed early stopping a due livelli.
5. Esegui la review per segmento con calibrazione e deploy gate firmato dall’owner.

Un caso reale: il punteggio globale che nascondeva la discriminazione

Nell’ottobre 2018 Reuters ha rivelato che Amazon aveva rottamato un modello interno di screening dei CV perché penalizzava sistematicamente i curricula femminili. Il sistema era stato addestrato su dieci anni di CV storici, un periodo in cui le assunzioni tecniche erano in maggioranza maschili, e aveva imparato a scartare i segnali associati alle donne. Amazon lo ha accantonato nel 2017 dopo aver constatato che la correzione non reggeva. Il caso mostra perché la review per segmento non è optional: un punteggio globale alto nasconde il segmento dove il modello discrimina.

Domande per chiudere la lezione

1. Cosa deve contenere la scheda di planning prima di lanciare un training?
2. Come costruisci split temporale ed embargo contro il leakage?
3. Quale review per segmento fai prima di proporre un modello vincitore?
4. Cosa prevede il deploy gate prima della firma dell’owner?