---
title: "Consulenza AI per aziende: cosa deve consegnare un progetto"
url: https://zerofive.ai/blog/strategia/consulenza-ai-cosa-deve-consegnare
canonical: https://zerofive.ai/blog/strategia/consulenza-ai-cosa-deve-consegnare
language: it
published: 2026-09-11
updated: 2026-09-18
author: "ZeroFive.AI"
tags: consulenza AI, AI adoption, governance AI, assessment AI
abstract: "Quali documenti deve lasciare una consulenza AI in azienda: inventario, valutazione del rischio, criteri di accettazione e responsabilita, fase per fase."
---

# Consulenza AI per aziende: cosa deve consegnare un progetto

**In sintesi.** Una consulenza AI utile non consegna una presentazione: consegna decisioni prese e documenti che restano in azienda anche quando il consulente esce. Quattro artefatti distinguono un progetto solido da un esercizio teorico: inventario dei sistemi e dei casi d'uso, valutazione del rischio per ciascuno, criteri di accettazione misurabili e un modello di responsabilità che dica chi decide e chi risponde. Sotto trovi la tabella fase per fase, con l'artefatto atteso, chi lo approva e il criterio che permette di chiudere la fase.

Chi valuta una consulenza AI si trova quasi sempre davanti allo stesso problema: le proposte si assomigliano. Tutte parlano di assessment, roadmap, casi d'uso e change management. La differenza non sta nelle parole, sta in cosa resta in azienda alla fine. Un progetto si giudica dagli oggetti verificabili che produce, perche sono gli unici che sopravvivono al cambio di fornitore, di responsabile o di priorita.

## Il criterio che separa un progetto da una presentazione

Un artefatto e utile quando qualcuno puo usarlo per decidere senza chiedere spiegazioni a chi lo ha scritto. Una matrice di prioritizzazione senza i criteri espliciti non e un artefatto: e un'opinione impaginata. Un registro dei rischi che non indica chi lo aggiorna diventa obsoleto in poche settimane.

Tre domande bastano per valutare qualsiasi consegna:

- Chi la usera dopo la fine del progetto, e per quale decisione?
- Come si aggiorna, con quale frequenza e a cura di chi?
- Cosa succede se la risposta non arriva: quale decisione resta bloccata?

Se una consegna non supera queste tre domande, il suo valore finisce con l'ultima riunione.

## Le fasi e cosa deve produrre ciascuna

| Fase | Decisione da abilitare | Artefatto atteso | Chi approva | Criterio di chiusura |
|---|---|---|---|---|
| Inquadramento | Su quale ambito conviene intervenire | Mappa dei processi candidati con obiettivi misurabili | Direzione sponsor | L'ambito e scritto, con cosa resta fuori |
| Assessment | Quanto l'organizzazione e pronta | Fotografia di dati, competenze, processi e governance | Sponsor e responsabili di funzione | Ogni dimensione ha evidenze, non percezioni |
| Portfolio | Quali casi d'uso finanziare | Elenco valutato su valore, fattibilita, rischio e dati disponibili | Comitato di indirizzo | Le priorita sono ordinate con criteri scritti |
| Validazione | Se l'ipotesi regge | Prototipo con criteri di accettazione definiti in anticipo | Responsabile di processo | Il risultato dichiara passa oppure non passa |
| Messa in produzione | Se il sistema puo entrare nei processi ufficiali | Documentazione tecnica, controlli e piano di monitoraggio | Responsabile di processo e funzione rischio | I controlli sono attivi, non pianificati |
| Continuita | Chi mantiene il sistema nel tempo | Modello di responsabilita e piano di revisione | Direzione | Nomi, frequenze e soglie sono assegnati |

La sequenza conta piu della durata. Saltare l'assessment porta a finanziare casi d'uso che l'organizzazione non puo assorbire. Saltare i criteri di accettazione porta a piloti che non si chiudono mai, perche nessuno ha stabilito prima cosa significa riuscire.

## I quattro documenti che devono restare

### Inventario dei sistemi e dei casi d'uso

E il documento su cui poggiano tutti gli altri. Deve elencare, per ciascun sistema o caso d'uso: finalita, dati utilizzati, chi lo usa, chi ne risponde, in quale processo entra e quale decisione influenza. Senza questo elenco non e possibile valutare il rischio, ne rispondere a una richiesta di chiarimento interna o esterna. La stessa struttura serve poi per la gestione del rischio e per gli obblighi documentali, quindi conviene costruirla una volta sola e riutilizzarla.

### Valutazione del rischio per caso d'uso

Il rischio non e una proprieta della tecnologia: dipende dall'uso. Lo stesso modello puo essere irrilevante in una bozza interna e delicato in una decisione che riguarda persone. La valutazione deve indicare il tipo di impatto, chi puo essere toccato, quali controlli sono previsti e chi supervisiona. Il [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) organizza questo lavoro in quattro funzioni, governare, mappare, misurare e gestire, ed e un riferimento utile perche non richiede certificazione per essere adottato.

### Criteri di accettazione

Sono la difesa piu efficace contro i piloti infiniti. Vanno scritti prima di iniziare e devono includere: la misura di riferimento attuale, il risultato atteso, come si misura, su quale campione, chi verifica e cosa si fa se il risultato non arriva. Un criterio accettabile e verificabile da una persona diversa da chi ha costruito il sistema.

### Modello di responsabilita

Per ogni sistema in produzione servono tre nomi: chi lo usa nel processo, chi risponde degli esiti e chi verifica che continui a funzionare come previsto. Quando questi ruoli non sono assegnati, la supervisione umana resta un principio dichiarato e non un controllo reale.

## Come leggere una proposta

Una proposta si valuta meglio con domande concrete che con il confronto tra prezzi:

1. Quali documenti resteranno in azienda, e in quale formato modificabile?
2. Chi li mantiene dopo la chiusura del progetto?
3. Quali criteri decidono se un caso d'uso passa in produzione?
4. Cosa accade se l'assessment mostra che l'ambito iniziale non e il piu adatto?
5. Quali competenze vengono trasferite alle persone interne, e come si verifica il trasferimento?
6. Quale parte del lavoro dipende da strumenti o licenze specifiche, e cosa resta se cambiano?

L'ultima domanda merita attenzione particolare. Una consulenza legata in modo rigido a una piattaforma produce risultati che si spostano male quando le condizioni cambiano, e le condizioni nel campo dell'AI cambiano spesso.

## Un esempio ipotetico

Un'azienda di servizi vuole ridurre il tempo di risposta alle richieste dei clienti. Un progetto impostato correttamente non parte dallo strumento: parte dalla misura attuale, per esempio il tempo medio e la percentuale di richieste che richiedono una seconda lavorazione. Definisce poi cosa significa migliorare, quale margine di errore e tollerabile, chi verifica le risposte prima dell'invio nei primi mesi e quando la supervisione puo essere ridotta. Al termine, l'azienda possiede una misura, un criterio, un controllo e un responsabile. Questo esempio e illustrativo e serve a mostrare la struttura, non descrive un risultato ottenuto.

## Cosa evitare

- Roadmap dettagliate su dodici mesi costruite prima di conoscere la qualita dei dati.
- Elenchi di quaranta casi d'uso senza criteri di selezione.
- Stime di beneficio senza la misura di partenza corrispondente.
- Documenti consegnati solo in formato presentazione, non aggiornabili.
- Governance descritta come principio, senza nomi e frequenze.

## Il passo successivo

Se stai valutando una consulenza AI, conviene partire da una fotografia sincera del punto in cui sei: cosa e gia in uso, con quali dati, con quali responsabilita assegnate. Puoi approfondire il nostro approccio nella pagina [Servizi](/servizi) e nella [guida al framework di AI adoption](/blog/strategia/framework-ai-adoption-guida-pratica-imprese), oppure iniziare con l'[autovalutazione della tua azienda](/avvia-ai-rating).

Se preferisci discuterne direttamente, puoi [fissare un incontro di valutazione](https://calendly.com/fabiolalli/zerofive): in trenta minuti chiariamo ambito, vincoli e quali documenti servirebbero davvero nel tuo caso.