Audit AI aziendale: cosa cercare in 60 minuti

Un audit AI aziendale ben fatto non è una vendita travestita. È un’ora che produce un documento utile anche se decidi di non continuare. Quello che cambia tra un audit fatto bene e uno inutile è la sequenza di domande del consulente, non il tempo a disposizione.

Questo articolo è la checklist che uso quando faccio un audit di un’ora con un’azienda nuova. Funziona perché segue un ordine: prima il processo, poi i dati, poi le persone, poi il vincolo. Saltare un livello significa costruire una proposta sbagliata.

Il pubblico tipico di questo audit è la PMI italiana che ha già provato qualche tool generativo a livello individuale, vuole capire dove ha senso integrarlo in un processo aziendale, ma non sa da dove cominciare. La risposta onesta richiede meno tempo di quanto sembra — a patto di non perderlo in slide motivazionali.

C’è anche un’altra ragione per cui un audit veloce funziona. Le aziende italiane medie hanno tempo limitato del management per progetti esplorativi: un’ora a calendario di un direttore è un investimento riconoscibile, due giorni di workshop sono un negoziato politico. Vincolare il formato a 60 minuti costringe entrambe le parti a portare densità e a evitare derive.

01. Il processo prima di tutto

La prima domanda non è mai “che AI vuoi usare”. È “quale processo vuoi cambiare”. Senza un processo concreto da analizzare l’audit diventa una chiacchierata su tendenze, e di chiacchierate sull’AI ne girano già abbastanza.

Per ogni processo candidato chiedo: quanti minuti-persona al mese consuma, chi lo esegue, quanti errori produce, quale output finale serve all’azienda. Sono quattro numeri grossolani ma sufficienti per stimare impatto. Se nessuno in azienda li sa rispondere, l’audit registra questo come primo segnale: significa che mancano metriche operative prima ancora di mancare l’AI.

Un processo adatto all’AI ha tre caratteristiche: ripetitivo, basato su testo o dati strutturati, con una definizione chiara di “fatto bene”. I processi creativi puri restano umani. I processi giuridicamente sensibili restano umani con AI come assistente, non come decisore. Il regolamento europeo sull’AI è esplicito su questo punto per i sistemi ad alto rischio.

02. I dati: quanti, dove, come accessibili

Un sistema AI senza dati è un cartellone pubblicitario. Per ogni processo identifico quali dati servono, dove vivono attualmente, in che formato, e chi li può rendere accessibili. Spesso questa è la parte più dolorosa dell’audit: l’idea piaceva, i dati no.

Casi tipici. Dati in PDF scansionati: serve OCR di qualità, e di solito un round di pulizia manuale prima. Dati in fogli Excel diversi per dipartimento: serve una fase di consolidamento, che è progetto a sé. Dati in CRM cloud accessibili via API: scenario migliore, partenza rapida. Dati su carta: stop, prima si digitalizza.

In molti audit la fotografia che esce è questa: il 60% del progetto AI è in realtà un progetto dati che si rivela necessario per primo. Saperlo prima di firmare un contratto consulenziale evita la classica spirale di sotto-stima dei tempi.

Per ognuno calcolo grossolanamente quanti record/documenti/righe ci sono. Un modello generativo che gira su 50 documenti è uno scenario, su 50.000 è un altro. Le architetture cambiano, i costi anche.

03. Le persone: chi guida, chi resiste, chi esegue

L’AI non fallisce per ragioni tecniche, fallisce per ragioni organizzative. Durante l’audit chiedo sempre: chi è lo sponsor interno del progetto, chi userà concretamente lo strumento, chi potrebbe sentirsi minacciato dall’automazione, chi ha potere di veto.

Se lo sponsor è il CEO e l’utente finale è un team operativo che non è stato coinvolto nella decisione, segnalo il rischio. Se lo sponsor è un middle manager senza budget proprio, segnalo un rischio diverso ma simmetrico. Un audit onesto include una mappa degli stakeholder, non solo dei tool.

Il punto non è fare politica aziendale al posto del cliente. È evitare di consegnare una proposta tecnicamente corretta che verrà fermata in fase di approvazione per ragioni che si potevano vedere prima. Una nota di Confindustria Digitale sul tema della formazione AI riporta come il fattore umano resti il moltiplicatore principale di valore — o l’ostacolo principale, a seconda di come viene gestito.

04. Vincoli reali: budget, tempo, normativa, segreto

I vincoli vanno chiesti esplicitamente. Nessuno li racconta spontaneamente perché sembrano debolezze. Lo sono, ma sono debolezze che devono entrare nel piano.

Le quattro categorie che indago sempre:

1. Budget: range realistico per i primi 12 mesi, distinguendo CAPEX (licenze, integrazioni) da OPEX (token, manutenzione, formazione).
2. Tempo: c’è una scadenza esterna (lancio prodotto, audit cliente, gara) che vincola il rollout?
3. Normativa: il processo tocca dati sensibili, salute, finanza personale, decisioni HR? Il regolamento europeo AI ha categorie precise e va letto prima di scegliere il tooling.
4. Segreto: l’output va condiviso con clienti? Resta interno? Il dato di partenza è coperto da NDA verso terzi?

Senza queste risposte una proposta è un esercizio teorico.

C’è un quinto vincolo che entra raramente in conversazione ma pesa: il vincolo culturale. Esiste in azienda una storia recente di progetti tecnologici falliti? Esiste una resistenza generalizzata verso fornitori esterni? Esiste un fornitore IT preferito che va coinvolto comunque? Questi elementi non sono ostacoli, sono dati di campo che condizionano sequenza e modalità di rollout.

05. Cosa NON entra in un audit di un’ora

Mettere limiti chiari evita malintesi. In 60 minuti non si fa: integrazione tecnica, scelta definitiva del modello, training su dati proprietari, analisi legale puntuale, design dell’interfaccia. Si fa scoperta strutturata e mappatura priorità.

Un cliente sano di mente non si aspetta il piano operativo finale da un’ora di call. Un cliente che lo pretende sta confondendo l’audit con il progetto. La distinzione vale anche economicamente: l’audit costa €240, un piano operativo per un processo singolo parte da una cifra diversa che dipende da scope e dati.

Capita anche il caso opposto. A volte dopo 30 minuti è chiaro che il progetto non sta in piedi: dati troppo scarsi, normativa che lo proibisce, processo che cambia entro tre mesi per ragioni indipendenti. In quel caso si chiude prima e si usa il tempo restante per disegnare alternative — il deliverable cambia formato, non valore.

06. Il deliverable: tre priorità impatto/sforzo

Il documento che produco dopo l’audit non è una vendita. È una matrice impatto/sforzo con tre priorità ordinate. Per ognuna scrivo:

• Processo target e metrica baseline attuale
• Architettura tecnica plausibile (modello, integrazione, dati richiesti)
• Range di costo per implementazione e per esercizio annuale
• Tempi realistici per uno spike di validazione e per un rollout completo
• Rischi specifici di quel processo

Tre priorità, non dieci. Dieci priorità non sono priorità. L’ordine impatto/sforzo permette al cliente di scegliere: vuole partire dal quick win basso-sforzo per fare cultura interna, o vuole attaccare subito il processo più strategico anche se richiede più tempo? La decisione resta sua, ma con dati davanti.

Lo standard del documento è ~12 pagine PDF, consegnato in tre giorni lavorativi. Niente template di slide riempite di icone. Un testo argomentato che il management può girare al CFO senza dover spiegare ogni riga.

Una matrice impatto/sforzo onesta deve includere anche scenari “non fare AI”. Se il problema si risolve con una macro Excel scritta bene, lo scrivo. Se si risolve con un riassetto di processo prima di qualsiasi tooling, lo scrivo. Il valore dell’audit non è giustificare un progetto, è dare una decisione informata. La differenza è sottile ma la sente subito chi è già passato per consulenze gonfiate.

07. Quando l’audit non serve

Onestà tecnica: ci sono casi in cui sconsiglio un audit. Tre scenari frequenti.

Azienda pre-AI assoluta: nessun tool generativo è mai entrato, nemmeno ChatGPT individuale. In quel caso suggerisco prima un workshop di alfabetizzazione di mezza giornata, costa diversamente e produce diverso valore. La formazione AI strutturata precede la consulenza, non la sostituisce.

Azienda con piano AI già scritto: hanno fatto un audit altrove, hanno un partner tecnico, gli serve un secondo parere su un punto specifico. In quel caso conviene una sessione mirata di consulenza a ore, non un audit di scoperta.

Azienda senza processo digitale di base: se la gestione documentale è ancora in cartelle Windows condivise senza versioning, l’AI è il passo numero quattro, non il passo numero uno. Va detto. Il cliente ringrazia, anche se delude la roadmap interna del momento.

Una nota meta. Il fatto che un consulente sappia mandare via clienti non in target è di solito un buon segnale. Una associazione italiana professionisti intelligenza artificiale come riferimento di settore aiuta proprio a normalizzare queste regole deontologiche, che altrimenti diventano scelte individuali.

08. Tre esempi concreti di output diversi

Per dare un’idea concreta di cosa esce da un audit, tre scenari realistici che variano per settore e maturità. Sono ricostruzioni anonime ma rispecchiano la struttura tipica del deliverable.

Scenario A — Studio professionale, 12 persone, processo di prima review documenti. Priorità 1: assistente di estrazione clausole standard da contratti cliente in entrata, basato su LLM con retrieval su template interni. Impatto stimato: 6 ore-persona settimana risparmiate. Sforzo: progetto da 6-8 settimane. Priorità 2: redazione bozza email risposta cliente con tone-of-voice studio. Priorità 3: knowledge base interna ricercabile in linguaggio naturale.

Scenario B — PMI manifatturiera 80 dipendenti, ufficio acquisti. Priorità 1: classificazione automatica RDA (richieste di acquisto) in entrata con instradamento al buyer corretto. Quick win basso-sforzo, ROI in 8 settimane. Priorità 2: estrazione strutturata da offerte fornitore in PDF formato eterogeneo. Sforzo medio, 12-16 settimane. Priorità 3: previsione consumi su materie prime ricorrenti. Sforzo alto, integrazione ERP necessaria.

Scenario C — E-commerce piccolo, 5 persone interno + agenzia. Priorità 1: assistente di scrittura schede prodotto su catalogo nuovo, con voice consolidato. Tempi rapidi, costo basso. Priorità 2: customer service di primo livello su FAQ ricorrenti via chat. Priorità 3: analisi review prodotto per estrarre pattern qualitativi.

Tre aziende, tre matrici diverse. Quello che resta costante è il formato: ogni priorità con metrica, architettura, costo, tempo, rischio. Niente di più.

09. Come prepararsi alla call

Cinque minuti di preparazione del cliente moltiplicano il valore dell’ora. Tre cose che chiedo prima:

1. Una descrizione testuale (anche breve) del processo o problema. Non slide, non roadmap aziendale, una pagina di testo.
2. Eventuali screenshot di tool attuali, file campione anonimizzati, esempi concreti di input/output del processo.
3. La persona giusta dall’altra parte: chi conosce operativamente il processo, anche se non è la persona che ha preso contatto.

Quando questi tre elementi ci sono, in 60 minuti si fa scoperta vera. Quando mancano si finisce per spiegare il proprio contesto a vicenda invece di lavorare sul caso. Funziona lo stesso, ma con meno densità informativa.

Se vuoi vedere il formato del deliverable prima di prenotare, la pagina audit ne descrive struttura e tempi, e la pagina esperto AI racconta come l’audit si inserisce nel percorso più ampio di consulenza.

10. Errori comuni che invalidano un audit

Cinque errori che ho visto ripetersi e che producono deliverable inutili anche quando il consulente è competente.

Confondere audit con demo tool: il cliente vuole vedere ChatGPT, Copilot, Claude in azione. È legittimo, ma è un’altra cosa. Una demo si fa in 15 minuti. Un audit usa quei 15 minuti per capire perché un tool sì e un altro no nel contesto specifico.

Saltare la fase processo per parlare di dati: capita quando il referente è tecnico. Si finisce in una conversazione su modelli, embedding, vector db, senza aver mai definito cosa va prodotto in output. Il deliverable risulta corretto ma scollegato dal business.

Promettere il piano operativo nello stesso documento: il piano operativo richiede una fase di approfondimento, non si scrive in tre giorni partendo da un’ora di call. Chi lo promette o sta confondendo i livelli o sta gonfiando il preventivo.

Ignorare costi di esercizio: l’implementazione AI ha un costo una tantum. Il modello generativo ha un costo per token, per richiesta, per utente — che si ripete ogni mese. Un audit che cita solo costi di sviluppo è un audit incompleto.

Lasciare il cliente con un PDF senza next step: il documento deve includere tre azioni concrete per i 30 giorni successivi, indipendenti dal fatto che il cliente scelga di proseguire la consulenza. Anche un “leggi questi tre articoli, fai questi due workshop interni” è un next step utile. Senza, il PDF resta una bella riflessione in archivio.

Il filo conduttore è uno solo: un audit serve a far prendere una decisione informata, non a vendere il passo successivo della consulenza. Quando le due cose coincidono per ragioni di merito è un buon risultato. Quando il consulente le confonde sistematicamente è un problema, e si vede dopo poche pagine di deliverable.