Ruoli e Responsabilità nei Progetti AI per PMI: Chi Fa Cosa (Guida 2026)

Un progetto AI in produzione ha 6 ruoli necessari anche in una PMI da 50 dipendenti: Sponsor, AI Champion, Process Owner, Utenti, IT/Security, Partner esterno. Il più sottovalutato è l'AI Champion — quello senza cui tutto degrada nei 6 mesi dopo il go-live.

Perché la governance AI fallisce nelle PMI

Quando un progetto AI in una PMI italiana degrada nei mesi successivi al go-live, la causa quasi mai è tecnica. È sempre la stessa: non è chiaro chi è accountable per cosa. Il fenomeno è prevedibile.

Il primo segnale è la risposta evasiva quando qualcuno chiede "chi gestisce l'AI?". Le risposte tipiche: "lo gestisce l'IT" (ma l'IT non sa fare prompt engineering), "lo gestisce chi l'ha implementato" (ma il consulente esterno non è più stabilmente disponibile), "lo gestisce il responsabile operations" (che però non ha tempo né formazione specifica).

Il secondo segnale è quando emergono problemi e si scopre che nessuno li sta tracciando sistematicamente. Gli edge case vengono "gestiti uno alla volta" da chi li incontra, senza pattern recognition. Le metriche vengono raccolte sporadicamente. Le decisioni di iterazione vengono prese in modo reattivo invece che pianificato.

La radice del problema non è la mancanza di processi — è la mancanza di accountability esplicita. Nessuno ha il proprio nome scritto accanto a "responsabile della performance del sistema AI". Senza un nome esplicito, la performance degrada inevitabilmente.

La matrice RACI per progetti AI in PMI

RACI è il framework di accountability più semplice e più efficace: per ogni attività si definisce chi è Responsible (chi esegue), Accountable (chi risponde del risultato), Consulted (chi viene consultato prima della decisione), Informed (chi viene informato dopo la decisione).

Per un progetto AI tipico in PMI italiana, la matrice RACI sulle 10 attività chiave del post-implementazione:

• Definizione delle metriche di successo — A: Sponsor · R: AI Champion · C: Process Owner · I: Partner esterno
• Raccolta settimanale delle metriche — A: AI Champion · R: AI Champion · I: Process Owner
• Triage degli incident di produzione — A: AI Champion · R: AI Champion · C: Partner esterno · I: Sponsor (se severity alta)
• Modifica prompt e calibrazione — A: AI Champion · R: AI Champion · C: Partner esterno · I: Process Owner
• Approvazione iterazioni strutturali — A: Sponsor · R: AI Champion · C: Partner esterno · I: tutti
• Gestione accessi e permessi — A: IT/Security · R: IT/Security · C: AI Champion · I: Process Owner
• Compliance e audit GDPR — A: IT/Security · R: IT/Security · C: Partner esterno · I: Sponsor
• Feedback continuo sulla qualità output — A: Process Owner · R: Utenti finali · I: AI Champion
• Decisione di scaling a nuovi casi d'uso — A: Sponsor · R: Process Owner · C: AI Champion, Partner esterno · I: IT
• Rinegoziazione contratto consulenza — A: Sponsor · R: AI Champion · C: IT (per termini tecnici)

La regola critica: una sola persona Accountable per ogni attività. Se in una riga ci sono due A, l'attività non ha owner reale.

I 6 ruoli essenziali (anche se non sono persone full-time)

1. Sponsor (CEO o C-level)

Cosa deve fare: approvare il budget per la fase post-pilota (manutenzione, iterazioni, scaling). Decidere le priorità quando emergono conflitti tra reparti. Validare la roadmap a 12 mesi presentata dall'AI Champion al mese 6.

Cosa NON deve fare: micro-gestire le decisioni tecniche. Modificare prompt senza consultare l'AI Champion. Cambiare il budget mensilmente sulla base dell'umore. Il ruolo dello Sponsor è strategico, non operativo.

Allocazione tempo: 2-4 ore/mese in regime di crociera. Più alta nei momenti decisionali (mese 6 e mese 12).

2. AI Champion interno

Il ruolo più sottovalutato — e quello senza il quale tutto il resto degrada. È la persona che tiene insieme il sistema giorno per giorno: raccoglie metriche, gestisce gli incident di livello 1-2, decide le micro-iterazioni sui prompt, coordina con il partner esterno, fa da ponte tra utenti finali e team tecnico.

Profilo ideale: una figura interna esistente con buona comprensione dei processi di business e curiosità tecnica. NON deve essere il CTO, NON deve essere un junior — il punto ideale è un mid-level con 3-7 anni di esperienza nel ruolo originale. Spesso emerge da Operations, Customer Success o IT, ma può venire anche da altre funzioni.

Allocazione tempo: 20-50% del proprio ruolo originale, a seconda del numero di sistemi AI attivi. Va formalizzato: senza una percentuale esplicita, il ruolo viene mangiato dalle responsabilità "principali" e l'AI degrada. Per la formazione strutturata dell'AI Champion vedi formazione AI team aziendale.

KPI dell'AI Champion: tasso di adozione del sistema, tempo medio di risoluzione incident, % miglioramento mese su mese sulle 5 metriche chiave del sistema. Per il framework di misurazione del ROI a cui questi KPI si agganciano, vedi come misurare il ROI di un progetto AI a 6 mesi. Bonus annuale legato a questi KPI.

3. Process Owner (il manager del reparto impattato)

È il manager del reparto in cui l'AI viene usata: customer service, marketing, operations, sales. Ha ownership operativa del processo che l'AI accelera o sostituisce parzialmente.

Responsabilità: assicurarsi che il team usi il sistema, raccogliere feedback strutturato sulla qualità dell'output, segnalare quando i pattern degli input cambiano, validare le iterazioni proposte dall'AI Champion prima dell'implementazione.

Errore tipico: il Process Owner viene marginalizzato durante l'implementazione e poi si ritrova un sistema nel proprio reparto che non controlla. La governance corretta lo coinvolge dal primo giorno e lo mantiene nel loop attraverso la roadmap 12 mesi post-pilota.

4. Utenti finali

Sono le persone che usano l'AI ogni giorno. Il loro ruolo nel post-implementazione è il feedback loop: ogni override manuale, ogni risposta sbagliata, ogni edge case viene loggato. Non come lamentela, ma come dato strutturato che alimenta le iterazioni.

Per funzionare, serve un canale formale (form, ticket system, slack channel dedicato) dove gli utenti possono segnalare problemi senza attrito. Senza canale formale, il feedback si perde — e il sistema migliora più lentamente.

5. IT / Security

Ruolo limitato in scope ma critico per quello che riguarda. Responsabilità: gestione degli accessi e permessi (chi può usare il sistema con quali dati), compliance GDPR e privacy by design, audit di sicurezza periodici, gestione delle credenziali API verso provider esterni (OpenAI, Anthropic, etc.).

Cosa NON è ruolo dell'IT: ottimizzazione dei prompt, scelta del modello AI, gestione delle metriche di business. Quando l'IT viene caricato di queste responsabilità senza avere la competenza specifica, il sistema degrada.

6. Partner esterno (consulente AI)

Anche dopo il go-live, il partner esterno mantiene un ruolo — la cui ampiezza dipende dal modello scelto (retainer continuativo, audit periodici, o on-demand). Vedi quando portare l'AI in-house dopo la consulenza per il framework di scelta.

Tipicamente il partner gestisce: evoluzioni tecniche complesse (es. cambio di modello, integrazione di nuove fonti dati), audit periodici della performance e governance, supporto al lancio di nuovi casi d'uso, escalation di problemi che l'AI Champion non sa risolvere autonomamente.

Il documento da scrivere il giorno del go-live

L'errore più frequente è non formalizzare la governance per iscritto. Il fix è un "AI Governance One-Pager": una singola pagina A4 che chiunque in azienda può leggere in 2 minuti per capire chi fa cosa.

Template del one-pager:

• Sistema: nome del sistema AI, caso d'uso, data di go-live, reparto di riferimento.
• Sponsor: nome e cognome, ruolo in azienda, contatto.
• AI Champion: nome, ruolo originale, % di tempo allocato, KPI sui quali è valutato.
• Process Owner: nome del manager del reparto impattato.
• Tier di escalation: tier 1 (utente finale → AI Champion via [canale]) — risposta in [tempo]. Tier 2 (AI Champion → Partner esterno via [canale]) — risposta in [tempo]. Tier 3 (Partner esterno → vendor di modello via [canale]).
• Cadenze di review: settimanale (metriche operative), mensile (review delle 5 metriche chiave), trimestrale (review strategica con Sponsor).
• Indicatori di salute del sistema: le 5 metriche principali con soglie di alert.

Questo documento va scritto il giorno del go-live (non al mese 3, non al mese 6) e va pubblicato in un canale interno accessibile a tutti. Quando emerge un problema, la prima domanda è "cosa dice il governance one-pager?".

Come gestire le decisioni che nessuno vuole prendere

Lo scenario tipico: a 6 mesi dal go-live, le metriche mostrano un calo del 15% nella quality score del sistema. Tutti lo vedono, nessuno vuole essere quello che "decide di intervenire". L'AI Champion non si sente legittimato a chiedere budget extra; il Process Owner non vuole sembrare incompetente; lo Sponsor non vuole gestire un problema che dovrebbe essere già stato risolto a livello operativo. Risultato: il sistema continua a degradare. Per il framework di diagnosi quando le metriche calano, vedi se il pilota AI non funziona, cosa fare.

Il fix di governance: definire trigger automatici per le decisioni. Nel governance one-pager, scrivere esplicitamente:

• Se la quality score cala del 10% per 2 settimane consecutive, l'AI Champion HA L'OBBLIGO di chiamare una review.
• Se in review emerge che serve un intervento del partner esterno, lo Sponsor HA L'OBBLIGO di approvare il budget entro 5 giorni.
• Se l'AI Champion ritiene che il sistema debba essere temporaneamente disattivato, HA L'AUTORITÀ di farlo, comunicando entro 24h allo Sponsor.

Le decisioni difficili diventano routine se l'autorità è pre-allocata. Senza pre-allocazione, ognuno aspetta che decida qualcun altro.

Cosa NON fare nella governance AI di una PMI

Cinque anti-pattern che vediamo nelle PMI italiane che provano a copiare la governance enterprise senza adattarla.

1. Scrivere una AI policy di 30 pagine basata su template enterprise. Diventa un documento che nessuno legge e nessuno applica. La governance AI di una PMI funziona quando sta su un foglio A4 e il team se la ricorda senza riaprirla. Se ti serve un sommario per capire la tua governance, è troppo lunga.

2. Centralizzare tutte le decisioni AI sull'IT. L'IT è competente sulla parte tecnologica, non sui processi di business. Le decisioni "quando intervenire sull'AI", "quando estendere lo scope", "quando ritirare il sistema" sono di chi conosce il processo: Process Owner + AI Champion, non IT in isolamento.

3. Lasciare l'AI Champion senza budget decisionale. Se l'AI Champion deve chiedere approvazione per ogni modifica al prompt o per ogni API extra, non è champion — è messaggero. Definisci una soglia di spesa autonoma (1-3K€/mese a sua discrezione) che non richiede approvazioni puntuali.

4. Confondere governance con burocrazia. La governance serve a velocizzare le decisioni difficili, non a rallentare quelle facili. Se il tuo processo produce più report che decisioni, è progettato male. Una governance ben fatta riduce il time-to-decision; una mal fatta lo aumenta.

5. Trattare la governance come esercizio una-tantum. La governance va aggiornata ogni 6 mesi: cambiano i sistemi, cambiano le persone, cambia il contesto regolatorio (AI Act in particolare). Una governance scritta una volta sola e mai più rivista diventa fiction operativa nel giro di 12 mesi.

Se vuoi un workshop di 4 ore per costruire la governance AI della tua azienda con il framework RACI completo, parla con IL DOGE DI VENEZIA. Lo facciamo on-site (Nord Italia, principali città del Sud) o in remoto. La prima call diagnostica è gratuita.