L'intelligenza artificiale è entrata nelle aziende prima delle regole per usarla. Nelle PMI che seguo la vedo già ovunque: qualcuno la usa per scrivere email, qualcuno per analizzare documenti, qualche fornitore la integra nei propri strumenti di assistenza. La domanda utile, per chi gestisce l'IT, non è «AI sì o no» — quella discussione è già superata dai fatti — ma: dove è utile davvero, quali rischi introduce, e chi ne risponde. In questo articolo metto in fila utilità, limiti e responsabilità dal punto di vista di chi ha il compito di tenere insieme il quadro.
Dove l'AI è utile davvero
Nella gestione IT quotidiana, i casi d'uso che vedo funzionare hanno un tratto comune: l'AI accelera un lavoro che una persona competente sa già impostare e verificare.
- Classificazione e smistamento: ordinare segnalazioni e richieste, riconoscere ricorrenze nei ticket, dare una prima priorità. Utile dove i volumi rendono il lavoro manuale dispersivo.
- Ricerca documentale: interrogare in linguaggio naturale manuali, procedure, contratti e documentazione tecnica. Per aziende con anni di documenti stratificati, è un guadagno concreto — a condizione che la documentazione esista e sia affidabile.
- Supporto all'analisi: riassumere log e report, confrontare configurazioni, proporre ipotesi diagnostiche da verificare. L'AI amplia le piste; la diagnosi resta di chi conosce il sistema.
- Automazione assistita: bozze di script, di procedure, di comunicazioni tecniche. Il risparmio è reale, ma tutto ciò che va in produzione richiede revisione umana.
Il tratto comune si può rovesciare in un criterio: dove manca la persona in grado di verificare l'output, l'AI non toglie un problema — ne aggiunge uno.
Il primo rischio: i dati che escono
Ogni volta che uno strumento AI viene interrogato, dei dati lasciano l'azienda. È il punto che più spesso viene ignorato nell'entusiasmo iniziale. Le domande da porsi prima di adottare uno strumento sono le stesse che si porrebbero per qualunque fornitore cloud: dove vengono elaborati e conservati i dati inviati? Vengono usati per addestrare modelli? Con quali garanzie contrattuali, e in quale giurisdizione? La differenza è che con l'AI l'invio è capillare e quotidiano: non un'integrazione progettata, ma centinaia di piccoli copia-incolla decisi dai singoli.
Tre categorie meritano attenzione particolare:
- segreti tecnici: credenziali, chiavi, configurazioni di sicurezza non devono mai finire in un prompt — un'abitudine sorprendentemente diffusa quando si chiede aiuto per un problema tecnico;
- log e dati di sistema: sembrano innocui, ma contengono indirizzi, nomi utente, struttura interna della rete;
- informazioni personali: dati di dipendenti e clienti inviati a un servizio esterno costituiscono un trattamento a tutti gli effetti, con ciò che ne consegue in termini di basi giuridiche e responsabilità. Il quadro è lo stesso che ho descritto nell'articolo su GDPR e obblighi tecnici per le PMI.
Errori, allucinazioni e verifica umana
I modelli linguistici producono risposte plausibili, non risposte garantite. Possono inventare dettagli, citare fonti inesistenti, proporre comandi sbagliati con lo stesso tono sicuro con cui propongono quelli giusti. Chi li usa ogni giorno lo sa e sviluppa gli anticorpi; chi li usa da poco tende a fidarsi proprio quando non dovrebbe.
Nel contesto IT questo ha una conseguenza operativa precisa: nessun output AI va eseguito o pubblicato senza verifica umana competente. Un comando suggerito da un modello e lanciato su un server di produzione senza comprenderlo è un incidente in attesa di accadere. Per questo diffido delle narrazioni sull'AI che «risolve gli incidenti da sola»: nella realtà delle PMI, l'AI è un moltiplicatore della competenza di chi la usa. Moltiplicare zero dà zero; moltiplicare l'imprudenza dà guai più veloci.
Autorizzazioni e tracciabilità
Quando l'AI passa dal suggerire all'agire — agenti che eseguono operazioni, automazioni che toccano sistemi — valgono le regole di qualsiasi utenza tecnica, applicate con più severità: privilegi minimi necessari, credenziali dedicate e non condivise, tracciabilità di ciò che è stato fatto, possibilità di interrompere e revocare. Un principio semplice aiuta a non perdersi: un sistema automatico non deve poter fare nulla che l'azienda non affiderebbe a un collaboratore esterno appena arrivato — e ciò che fa deve restare ricostruibile a posteriori.
La dipendenza dal fornitore
Gli strumenti AI evolvono in fretta: modelli che cambiano comportamento da una versione all'altra, condizioni d'uso e prezzi che si aggiornano, servizi che nascono e chiudono. Costruire processi aziendali sopra uno strumento specifico significa accettare una dipendenza, e le dipendenze vanno gestite come tali: sapere quali processi si appoggiano a quale servizio, cosa succederebbe se cambiasse o chiudesse, quanto sarebbe oneroso migrare. È la stessa logica del piano di uscita che applico ai fornitori tradizionali — con in più la velocità con cui questo mercato si muove.
Una policy aziendale essenziale
La risposta realistica non è vietare — il divieto produce solo uso sommerso, sugli account personali e fuori da ogni controllo — ma dare regole semplici e conosciute da tutti. Una policy essenziale per una PMI copre pochi punti:
- quali strumenti sono approvati, con quali account (aziendali, non personali);
- quali dati non devono mai essere inseriti: segreti, dati personali, informazioni riservate di clienti e progetti;
- quali usi richiedono verifica umana prima di produrre effetti (di fatto: tutti quelli che toccano sistemi, clienti o decisioni);
- chi risponde delle automazioni attive e dove sono censite;
- a chi segnalare dubbi ed errori, senza colpevolizzare chi segnala.
Una pagina, scritta in italiano comprensibile, aggiornata quando serve: vale più di un manuale di cinquanta pagine che nessuno leggerà.
Come impostare un progetto pilota
Per chi vuole andare oltre l'uso individuale, il percorso sensato è un pilota delimitato. I criteri che suggerisco: un processo specifico e misurabile (non «adottiamo l'AI», ma «riduciamo il tempo di smistamento delle richieste»); dati non critici nella prima fase; un confronto onesto tra prima e dopo; un responsabile del pilota; una scadenza per decidere se estendere, correggere o fermare; e costi — licenze, integrazione, tempo delle persone — messi in conto dall'inizio. Il pilota serve a imparare, e va considerato riuscito anche quando la risposta è «non ne vale la pena, per ora»: è una decisione informata, ed è il contrario dell'adozione per moda.
Una questione di gestione, non di strumenti
Come si sarà capito, quasi nulla di ciò che rende l'AI sicura e utile in azienda è tecnologico: sono scelte di perimetro, regole, responsabilità e verifica. Per questo il tema rientra nella gestione continuativa dell'IT — accanto a fornitori, rischi e roadmap — ed è con quella lente che lo affronto nel servizio di IT governance, roadmap e budget. Sul fronte più ampio della trasformazione dei processi con l'AI, che esce dal perimetro di questo sito, ho scritto un approfondimento su AI e automazione per le PMI sul mio sito personale.
Se in azienda l'AI è già entrata dalla porta laterale — singole persone, singoli strumenti, nessuna regola — non sei in ritardo: sei nella situazione più comune. Contattami se vuoi metterla in ordine: definire policy, perimetri e un eventuale pilota è un lavoro di settimane, non di anni.