Un progetto AI è un cambiamento operativo, non l’acquisto di uno strumento
Il quadro AI RMF del NIST organizza la gestione del rischio in quattro funzioni: governare, contestualizzare, misurare e gestire. Non è una lista di adempimenti da spuntare e va adattato a risorse e contesto; l’idea utile per una PMI è più semplice: il controllo deve accompagnare tutto il ciclo di vita, non comparire solo alla fine.
Prima di scegliere piattaforme o integrazioni, scrivete una scheda di avvio di una pagina. Deve rispondere a cinque domande: quale passaggio concreto rallenta il lavoro; quale output AI sarebbe utile; chi usa e chi approva quell’output; quali dati entrano; quale conseguenza è inaccettabile. Se la scheda non è chiara, il progetto non è ancora pronto a partire.
La scheda minima di avvio
- Problema osservabile: descrivete un passaggio, non un desiderio generico. Per esempio: “classificare le richieste email in arrivo” invece di “usare l’AI nel customer care”.
- Decisione e confine: indicate cosa l’AI può proporre e cosa non può eseguire. Una bozza, una priorità o una classificazione non sono la stessa cosa di inviare, modificare o autorizzare.
- Responsabile del processo: nominate la persona che conosce l’attività e può giudicare il risultato nel lavoro reale.
- Dati e accessi: elencate fonte, titolare, aggiornamento previsto, destinatari e permessi minimi necessari.
- Misura di esito: scegliete un indicatore di qualità e uno di impatto operativo, con una base di confronto rilevata prima del test.
Questa preparazione non sostituisce valutazioni legali, contrattuali o di sicurezza quando necessarie. Evita però una causa frequente di spreco: scoprire, dopo avere configurato tutto, che l’attività scelta non è abbastanza stabile o che l’output non può essere usato senza un controllo oneroso.
1. Partire dallo strumento invece che da una decisione utile
“Mettiamo un chatbot” o “attiviamo un agente” non sono obiettivi. Sono ipotesi di soluzione. Senza una decisione o un passaggio da migliorare, il team accumula demo gradevoli ma non sa scegliere tra velocità, accuratezza, costo e rischio. Anche un risultato linguisticamente convincente può essere inutilizzabile se non contiene i dati che servono a chi lavora dopo.
Invertite la domanda: non “cosa può fare questa AI?”, ma “quale output, ricevuto da quale ruolo, cambierebbe un passaggio ripetuto?”. Poi fissate un confine: per esempio, la soluzione può proporre una categoria e indicare la fonte; non può modificare il gestionale. L’obiettivo diventa verificabile e l’eventuale automazione successiva è una decisione separata.
2. Lasciare le responsabilità implicite
Nei progetti piccoli è facile dire che “se ne occupa l’IT” oppure che il fornitore “gestisce l’AI”. Questo lascia senza risposta chi aggiorna le istruzioni, chi corregge una risposta errata, chi autorizza un nuovo collegamento e chi interrompe il flusso in caso di anomalia. Un ruolo tecnico può non conoscere le eccezioni del processo; chi lo conosce potrebbe non avere il potere di intervenire.
Usate quattro ruoli, anche se alcune persone coincidono: proprietario del processo, proprietario dei dati, responsabile tecnico degli accessi e decisore dell’accettazione. Per ogni output ad impatto esterno, aggiungete un contatto per l’escalation. Il NIST indica che ruoli, linee di comunicazione, monitoraggio e revisione sono elementi della governance; la responsabilità della leadership non si trasferisce al software.
3. Trattare i dati aziendali come un unico blocco disponibile
Dire “abbiamo i documenti” non basta. Una cartella può contenere versioni superate, istruzioni contraddittorie, informazioni personali o file che non dovrebbero raggiungere quel fornitore o quel gruppo di utenti. Se le fonti non sono identificabili, quando l’AI dà un risultato sbagliato non è possibile capire se il problema viene dal dato, dall’istruzione o dal modello.
Costruite un piccolo registro delle fonti prima del pilot. Per ciascuna: scopo d’uso, proprietario, data o segnale di aggiornamento, utenti autorizzati, informazioni da escludere e procedura di ritiro. Applicate minimizzazione e permessi per ruolo: un sistema che riassume procedure interne non richiede automaticamente accesso a tutte le anagrafiche o alla posta del personale. Per dati personali, segreti commerciali o decisioni che incidono sulle persone, coinvolgete le figure competenti prima di caricare o collegare dati; l’architettura e le basi giuridiche vanno valutate nel caso concreto.
Per l’AI generativa, il profilo NIST dedicato è una risorsa trasversale che accompagna l’AI RMF e richiama l’integrazione delle considerazioni di affidabilità nella progettazione, nell’uso e nella valutazione. In pratica, conservare la provenienza delle fonti e registrare le correzioni vale più di raccogliere indiscriminatamente materiale.
4. Scambiare una demo per un pilot misurabile
Una demo dimostra che un sistema può produrre un output. Un pilot risponde a una domanda più esigente: con casi rappresentativi del nostro lavoro, la qualità è sufficiente e il tempo complessivo migliora? Se si testano solo i casi facili o si cambiano istruzioni e dati senza annotarlo, il confronto non regge e la decisione di estendere il progetto diventa una scommessa.
Preparate un set di test prima della configurazione finale. Include richieste normali, incomplete, ambigue, eccezionali e casi in cui l’AI dovrebbe dichiarare di non poter rispondere. Per ogni caso indicate l’output atteso, la fonte o regola di riferimento, il revisore e il motivo di accettazione o rifiuto. Separate i casi usati per costruire la soluzione da quelli tenuti per la verifica; altrimenti si finisce per misurare quanto bene il sistema ricorda gli esempi già visti.
Definite anche una condizione di stop. Può essere una categoria di errore che richiede sempre revisione umana, una fonte non aggiornata o un accesso inatteso. Le indicazioni congiunte richiamate da CISA per sistemi AI acquisiti da terzi puntano a riservatezza, integrità e disponibilità, oltre a controlli per proteggere, rilevare e rispondere ad attività dannose. Un pilot serio verifica anche come si fermano e si segnalano i problemi, non solo le risposte corrette.
5. Chiamare “supervisione umana” una revisione senza regole
La formula “un umano controllerà” è insufficiente se non chiarisce chi controlla, quando, con quali informazioni e con quale facoltà di blocco. Una persona che riceve cento proposte poco spiegabili a fine giornata tende a confermare per fretta. In quel caso la supervisione esiste sulla carta, non nel processo.
Collegate il controllo alla gravità dell’azione. Per un contenuto interno a basso impatto può bastare un campionamento programmato. Per messaggi verso clienti, cambi a listini, registrazioni o priorità che danneggiano qualcuno, impostate un’approvazione prima dell’azione e una via di escalation. La schermata di revisione dovrebbe mostrare input, fonti disponibili, output proposto, autore della decisione e motivazione dell’eccezione. Così una correzione diventa apprendimento controllabile, non una modifica invisibile.
6. Rimandare sicurezza e formazione al giorno del lancio
Un collegamento rapido a CRM, posta o gestionale può ampliare molto l’effetto di un errore. Gli accessi vanno quindi definiti con il caso d’uso: account nominativi dove possibile, privilegi minimi, separazione tra test e ambiente operativo, registro delle azioni importanti e procedura per revocare chiavi o accessi. Verificate inoltre chi gestisce vulnerabilità, aggiornamenti, incidenti e cessazione del servizio. Sono domande che cambiano a seconda del contratto e dell’architettura, perciò non esiste una configurazione sicura valida per tutti.
La formazione non coincide con una presentazione dello strumento. Le FAQ ufficiali della Commissione europea sull’AI literacy spiegano che le misure per chi fornisce o impiega sistemi AI devono considerare conoscenze, esperienza, istruzione, formazione e contesto d’uso. Alla data del documento consultato, l’articolo 4 è applicabile dal 2 febbraio 2025 e le regole di supervisione e applicazione indicate dalla Commissione decorrono dal 2 agosto 2026. Non è una certificazione automatica: documentate istruzioni pratiche, esercitazioni sugli errori probabili, limiti dell’uso e canale per segnalare problemi; fate verificare gli obblighi che riguardano il vostro caso.
7. Misurare solo il risparmio promesso e non il lavoro reale
“Ridurre i tempi” è un obiettivo incompleto. Bisogna includere il tempo per preparare dati, verificare proposte, gestire eccezioni, aggiornare fonti e correggere errori. Misurate almeno: qualità accettata dal revisore, quota di casi inoltrati a una persona, tempo totale per pratica e numero o gravità delle anomalie. Un miglioramento di velocità che trasferisce il lavoro di controllo a un altro reparto non è necessariamente un miglioramento del processo.
Esempio ipotetico: decidere se proseguire dopo un pilot
Immaginate una PMI che usa l’AI solo per proporre una categoria a 100 richieste interne, senza aggiornare sistemi né inviare comunicazioni. È un esempio didattico, non un benchmark di mercato né un’offerta. Prima del pilot la lavorazione richiede 4 minuti a richiesta. Nel pilot, proposta e controllo richiedono in media 1 minuto; 20 richieste passano a revisione aggiuntiva di 2 minuti e l’aggiornamento settimanale delle istruzioni richiede 30 minuti.
Il tempo netto risparmiato nell’esempio è (4 − 1) × 100 − (20 × 2) − 30 = 230 minuti. Il numero, da solo, non autorizza l’estensione: il responsabile deve guardare i 20 casi eccezionali, gli errori rifiutati e l’effetto sulle persone coinvolte. Se la qualità non supera la soglia che l’azienda ha definito prima del test, la scelta corretta può essere correggere perimetro o dati, mantenere una bozza assistita, oppure fermarsi.
Checklist di decisione: estendere, modificare o fermare
| Domanda prima della decisione | Se manca una risposta verificabile |
|---|---|
| Il processo, il proprietario e l’azione consentita sono scritti? | Restare in esplorazione: non collegare azioni reali. |
| Le fonti hanno titolare, aggiornamento e accessi coerenti con lo scopo? | Ridurre il set di dati e risolvere permessi o qualità. |
| Il test copre anche eccezioni, rifiuti e casi da inoltrare? | Aggiungere casi e ripetere la valutazione. |
| Chi controlla gli output sa bloccare e motivare un’eccezione? | Ridisegnare la supervisione prima di aumentare il volume. |
| Qualità, tempo totale e anomalie sono confrontati con una base iniziale? | Non dichiarare il pilot riuscito né estenderlo. |
La checklist non assegna un voto universale: serve a rendere esplicita la decisione. Conservate versione delle istruzioni, fonti usate, risultati dei test e motivazioni. Un cambiamento di modello, fornitore, integrazione o processo può cambiare i rischi e richiedere una nuova verifica.
Da dove cominciare senza allargare subito il perimetro
Scegliete un’attività frequente ma reversibile, con un proprietario disponibile e un modo semplice per confrontare prima e dopo. Limitate dati e utenti, fate proporre all’AI invece di agire, osservate gli errori per un periodo definito e decidete con le evidenze raccolte. Questa sequenza non promette che ogni idea diventi un progetto: rende più economico capire quali idee meritano investimento.
Se il caso coinvolge più reparti, sistemi aziendali o decisioni ad alto impatto, una consulenza sull’intelligenza artificiale può aiutare a mettere a fuoco processo, dati, ruoli e criteri di verifica prima di impegnare risorse. Per iniziare una valutazione, puoi anche descrivere volontariamente il caso all’assistente in basso: indica l’attività, chi la svolge oggi, l’output desiderato e cosa non deve mai accadere. Non servono dati riservati per formulare questa prima domanda.