Pubblicato il 30 Giugno 2026 · Aggiornato il 16 Settembre 2026 · di Ismail Nasry

In breve: Checklist operativa per implementare l’AI in azienda: ownership, eval, costi, failure mode, rollback, privacy, AI Act e criteri di go/no-go.

Implementare l’AI in azienda non significa scegliere il modello più potente. Significa decidere quali problemi vale la pena affidare a un sistema probabilistico, con quali dati, sotto quale responsabilità e con quali condizioni di arresto. Una checklist utile deve quindi portare a una decisione: partire, correggere il progetto o fermarlo.

1. Parti dal problema, non dal modello

Prima di parlare di provider o architettura, descrivi il processo che vuoi cambiare: attività attuale, persone coinvolte, output, tempi, errori e colli di bottiglia. Se non riesci a definire il problema senza citare un modello AI, il progetto è probabilmente ancora troppo vago.

Deve esistere anche un baseline non-AI. Può essere il tempo medio per completare un task, il tasso di errore, il costo per pratica o un indicatore di qualità già usato dal team. Senza baseline, una demo può sembrare convincente senza dimostrare un miglioramento reale.

Esempio ipotetico: per classificare ticket con un LLM, prima misura tempo medio di classificazione, errori di instradamento e categorie ambigue. Solo dopo puoi stabilire se il sistema migliora davvero il processo.

2. Assegna un owner prima del prototipo

Ogni sistema AI ha bisogno di un responsabile del risultato, non solo di un responsabile tecnico. L’owner deve poter definire i criteri di accettazione, decidere quando cambiare modello, sospendere il sistema o modificare il processo. Accanto all’owner di processo serve un owner tecnico, ma le due responsabilità non sono intercambiabili.

Prima di partire deve essere chiaro chi approva il rilascio, chi interviene in caso di errore e chi può autorizzare nuovi dati, casi d’uso o integrazioni. Se la responsabilità resta distribuita genericamente tra IT, innovazione e business, il progetto diventa difficile da governare proprio quando entra in produzione.

3. Classifica dati e vincoli prima di scegliere il provider

La scelta del provider viene dopo la classificazione dei dati. Identifica che cosa entra nel sistema e cosa può restare nei log: dati personali, dati particolari, segreti industriali, codice sorgente, documenti interni, dati clienti o informazioni pubbliche.

Documenta almeno il flusso dei dati, i ruoli che possono accedervi, le aree geografiche ammesse, i tempi di retention accettabili e le eventuali valutazioni privacy necessarie. Le policy di training, retention e data residency non vanno date per scontate: cambiano per provider, prodotto, endpoint e configurazione. OpenAI, per esempio, dichiara che i dati dei prodotti business e API non vengono usati per addestrare i modelli per impostazione predefinita salvo opt-in; la verifica va comunque fatta sul servizio effettivamente adottato.

4. Valuta build, buy e integrazione come decisioni separate

“Costruire o comprare” è spesso una semplificazione. Un progetto può usare un prodotto SaaS per l’interfaccia, un’API esterna per il modello e componenti interni per retrieval, logging e policy enforcement.

La domanda utile è: quali componenti devono restare sotto il nostro controllo e quali possiamo esternalizzare? Valuta separatamente modello, orchestrazione, interfaccia, retrieval, guardrail, logging, identità, permessi e integrazioni. Questo evita di legare l’intera architettura a una singola scelta di provider.

5. Definisci gli eval prima del go-live

Una demo convincente non è una validazione. Prima del rilascio serve un set di casi rappresentativi e versionati con cui misurare il sistema in modo ripetibile. Il set dovrebbe includere casi normali, casi limite, input incompleti o ambigui e situazioni che il sistema deve rifiutare o escalare.

Le metriche dipendono dal caso d’uso. Per una classificazione possono essere precision, recall e tasso di escalation. Per una generazione documentale possono servire correttezza fattuale, completezza, rispetto del formato e presenza di elementi obbligatori. Per un assistente interno possono contare tasso di risoluzione, correttezza delle citazioni e numero di risposte che richiedono intervento umano.

Ogni modifica a modello, prompt, retrieval o policy dovrebbe poter essere sottoposta allo stesso set di eval per rilevare regressioni.

6. Scrivi i criteri di accettazione in anticipo

Un progetto AI è più semplice da governare quando il team sa cosa deve essere vero per poterlo mettere in produzione. I criteri devono essere verificabili, non impressionistici.

Un esempio ipotetico può includere: nessun dato non autorizzato nei log, accuratezza sopra una soglia definita, escalation obbligatoria per categorie ad alto rischio, costo medio per task sotto un limite stabilito, tempo di risposta compatibile con il processo e rollback disponibile senza interrompere il servizio. “La qualità sembra buona” non è un criterio di accettazione.

7. Modella i costi per unità di lavoro

Il costo mensile totale è utile, ma non basta. Per capire se il progetto scala, misura il costo per task completato o per risultato utile. Nel conto entrano API, retrieval, database, infrastruttura, osservabilità, revisione umana, gestione degli errori, sviluppo e manutenzione.

Se un task costa poco in API ma richiede dieci minuti di revisione umana, il vero costo non è quello del modello. Allo stesso modo, un modello più costoso può essere economicamente migliore se riduce errori, retry o supervisione. Inserisci anche il costo di switching: quanto costa cambiare provider, modello o architettura se le condizioni cambiano?

8. Elenca i failure mode prima che accadano

Ogni progetto dovrebbe avere un piccolo registro dei modi in cui può fallire. Tra i failure mode tipici ci sono output plausibile ma falso, risposta incompleta, mancato rispetto di un vincolo di formato, recupero di una fonte sbagliata, prompt injection, esposizione di dati non autorizzati, indisponibilità del provider, aumento inatteso dei costi o degradazione dopo un aggiornamento del modello.

Per ogni failure mode definisci quattro elementi: probabilità, impatto, segnale di rilevamento e contromisura. Non serve una matrice complessa; serve sapere cosa osservare e chi deve intervenire.

9. Decidi dove serve davvero l’human-in-the-loop

Mettere un umano nel loop ovunque può annullare il beneficio dell’automazione. Non metterlo mai può essere irresponsabile. La supervisione dovrebbe quindi dipendere dal rischio del singolo output.

Puoi prevedere approvazione obbligatoria prima di un’azione irreversibile, revisione a campione per attività a rischio basso, escalation quando un controllo supera una soglia e blocco automatico per categorie vietate o dati non autorizzati. L’obiettivo è progettare il punto di controllo, non aggiungere genericamente una persona alla fine del processo.

10. Progetta logging, osservabilità e rollback

In produzione devi poter rispondere a tre domande: che cosa è successo, perché non ha funzionato e come torno rapidamente a uno stato sicuro? Per farlo, traccia versione di prompt, modello e retrieval, oltre a costi, latenza, errori applicativi ed errori qualitativi.

Il sistema deve poter disattivare la funzione AI, usare un fallback e tornare a una versione precedente. Il rollback non è soltanto tecnico: se l’AI partecipa a un processo operativo, deve esistere anche una modalità alternativa per continuare il lavoro.

11. Tratta governance e compliance come requisiti di progetto

L’AI Act europeo è applicabile dal 2 agosto 2026 con un calendario progressivo ed eccezioni. Alcune disposizioni erano già operative: pratiche vietate e obblighi di AI literacy dal 2 febbraio 2025; governance e obblighi per modelli GPAI dal 2 agosto 2025. Altri obblighi, in particolare per determinati sistemi ad alto rischio, seguono date successive. La classificazione normativa non dovrebbe quindi essere una verifica finale, ma una domanda iniziale del progetto.

In parallelo, il GDPR continua ad applicarsi quando il sistema tratta dati personali. Privacy by design, minimizzazione, controllo degli accessi, finalità del trattamento e valutazioni sul rischio devono entrare nella progettazione tecnica, non essere aggiunti dopo il prototipo. Questa checklist non sostituisce una valutazione legale o del DPO: serve a evitare che il team tecnico arrivi troppo tardi alle domande normative.

12. Gestisci la Shadow AI offrendo un percorso approvato

Una policy che vieta strumenti non approvati senza offrire alternative può spostare l’uso fuori dalla visibilità dell’IT. Prima di introdurre nuovi controlli, mappa gli strumenti già usati, i motivi per cui vengono scelti e i dati che vi transitano.

Il percorso approvato dovrebbe chiarire categorie di dati ammesse e vietate, strumenti consentiti per i diversi casi d’uso, autenticazione aziendale dove disponibile, logging compatibile con privacy e sicurezza e un canale rapido per richiedere nuovi strumenti o use case. L’obiettivo non è eliminare ogni uso spontaneo, ma renderlo visibile e governabile.

13. Definisci il go/no-go

Prima del rilascio, riunisci in una sola pagina le condizioni che devono essere vere. Il progetto può andare in produzione quando problema e baseline sono chiari, ownership e responsabilità sono assegnate, dati e vincoli sono classificati, gli eval superano le soglie, i failure mode critici hanno contromisure, i costi sono sostenibili e logging, fallback, rollback, sicurezza, privacy e compliance sono stati verificati.

Se manca un elemento essenziale, la decisione non deve essere per forza “abbandonare”. Può essere “correggere e riprovare”. Un prototipo tecnicamente riuscito non obbliga a metterlo in produzione.

14. Rivedi il sistema quando cambia qualcosa di importante

Non serve rivalutare tutto ogni settimana. Serve farlo quando cambia un elemento che può alterare qualità, rischio o costo: modello, prompt di sistema, sorgenti di retrieval, policy del provider, processo aziendale, volume di utilizzo o quadro normativo.

Mantieni un dataset di eval stabile, un changelog delle modifiche, metriche di qualità e costo, un data flow aggiornato e un registro dei principali incidenti e near miss. La revisione periodica diventa così una conseguenza dei cambiamenti reali, non un rito a calendario.

La checklist finale

Prima di considerare un progetto AI pronto per la produzione, verifica questi dieci punti:

1. Problema e baseline sono chiari.
2. Esiste un owner accountable.
3. Dati e flussi sono classificati.
4. Provider e architettura rispettano i vincoli reali.
5. Esistono eval ripetibili e soglie di accettazione.
6. Costi per task e costi umani sono sostenibili.
7. I failure mode principali sono gestiti.
8. Human review ed escalation sono proporzionati al rischio.
9. Logging, fallback e rollback funzionano.
10. Sicurezza, privacy e compliance sono state verificate.

La tecnologia può cambiare rapidamente. Queste domande cambiano molto meno. È questo che rende la checklist utile nel tempo: non dire quale modello comprare, ma rendere esplicite le condizioni con cui decidere se un sistema AI può entrare davvero in un processo aziendale.

Fonti ufficiali da verificare nel tempo

Per gli aspetti time-sensitive di questo articolo sono state verificate il 16 settembre 2026 le fonti ufficiali dell’Unione europea sull’AI Act, il portale del Garante per la protezione dei dati personali e la documentazione ufficiale dei provider citati. Policy, date applicative e condizioni contrattuali possono cambiare e vanno ricontrollate sul servizio effettivamente adottato.