Abbiamo deciso di fare questa serie di articoli, per spiegare bene l’approccio all’intelligenza artificiale, vista con gli occhi di chi non fa solo teoria, ma deve anche pesare i reali benefici aziendali e di business. Questo è il primo articolo della serie “AI in azienda: da IT Manager a innovatore“.
La maggior parte di quello che si legge sull’AI in azienda nasce in contesti “puliti”: startup, software house, team di sviluppo che partono da un foglio bianco. Il mio contesto è un altro, e credo sia anche il vostro se lavorate in una PMI o grande azienda strutturata come me.
Sono IT Manager di un’azienda di trasporti con oltre 130 filiali sul territorio, e gestisco un team di 13 persone. Il mio perimetro non è “solo AI”: è infrastruttura, telecomunicazioni, cybersecurity, sicurezza fisica e perimetrale, e la gestione di tutti i dispositivi degli utenti, dalla telefonia fissa e mobile fino a PC e notebook. In un contesto così, ogni scelta tecnologica deve fare i conti con la progettualità di scala – 130 sedi non sono un’unica realtà – con l’eterogeneità degli utenti, dall’operatore di magazzino al dirigente, e con un livello di regolamentazione che negli ultimi due anni si è fatto molto più stringente. La nostra azienda rientra tra i “soggetti importanti” secondo il “famoso e fatidico” decreto che recepisce la direttiva NIS2.
In un ambiente del genere l’AI non può essere un esperimento isolato, un giocattolo nuovo da testare in un angolo. Deve entrare in un’infrastruttura che esiste già, rispettare vincoli di sicurezza e compliance che non sono negoziabili, ed essere gestibile da un team che ha già moltissimo altro da fare tutti i giorni.
Perché non sono partito da un tool esterno
La prima domanda che mi sono fatto, più di un anno fa, non è stata “quale AI generativa scelgo”. È stata: dove si inserisce l’AI in quello che ho già costruito? E la risposta è arrivata quasi da sola. Avevamo già un tenant Microsoft 365 completo, licenze attive, un’infrastruttura di identità e sicurezza – Entra ID, Defender, Sentinel – già in produzione da anni. Aggiungere un tool di AI generativa a lato, scollegato da tutto questo, avrebbe voluto dire un fornitore in più da valutare ai fini NIS2, con censimento, DPA e verifica del motore utilizzato (o subprocessor per i più esperti); un nuovo perimetro di identità e accessi da gestire in parallelo a quello che avevo già; dati aziendali che escono da un ambiente presidiato per entrare in uno da presidiare daccapo; e uno strumento in più da spiegare e far adottare a centinaia di persone sparse su 130 sedi.
Partire invece da quello che avevo già – Copilot, e più di recente Cowork – significava aggiungere una capacità a un sistema che conoscevo, con governance, policy di sicurezza e controlli di accesso già in gran parte pronti. Non è stata una scelta di fede verso un vendor. È stata una scelta di superficie di rischio, la stessa logica che uso quando devo decidere se aggiungere un nuovo apparato in rete o consolidare in base a quello già presente.
Il fattore compliance: per me è stato un acceleratore, non un freno
C’è un tema che quasi tutti trattano come un ostacolo, e che per me è stato invece un acceleratore: la NIS2.
Sono il sostituto del Punto di Contatto ACN della mia azienda, quindi il ciclo di adempimenti 2025-2026 l’ho vissuto da dentro: censimento dei fornitori rilevanti, categorizzazione delle attività e dei servizi, gap analysis sul piano di risposta agli incidenti. Questo lavoro ha costretto a farmi, per ogni fornitore tecnologico – AI compresa – una domanda che molti si pongono solo dopo aver già firmato: chi processa i miei dati, dove, e sotto quali termini contrattuali?
Avere l’AI generativa dentro un ecosistema il cui vendor principale era già un fornitore critico censito, con DPA e Product Terms già negoziati a livello enterprise, mi ha semplificato parecchio la vita. Non ho dovuto aprire un fascicolo fornitore da zero per ogni funzionalità AI attivata: rientrava già nel perimetro contrattuale che esisteva. Su questo tornerò con calma nel prossimo articolo, perché merita più spazio di due paragrafi.
C’è un altro aspetto che, col senno di poi, ha pesato più di quanto immaginassi all’inizio: l’ingresso di subprocessor terzi dentro Copilot, che hanno portato al suo interno l’esperienza di risposta di strumenti “personal” a cui molti utenti erano già abituati per conto proprio. Invece di dover convincere le persone a fidarsi di un assistente aziendale percepito come “diverso” da quello che usavano già fuori dall’ufficio, sono riuscito a fargli trovare un’esperienza familiare, su cui già avevano esperienza e feedback, ma dentro un perimetro di dati e sicurezza governato e gestito. È un tema che meriterebbe un articolo a sé, perché tocca sia la governance multi-modello sia l’adozione da parte degli utenti finali – per ora lo segno come promemoria per un prossimo capitolo della serie.
Cosa significa “ecosistema” nella pratica di tutti i giorni
Non parlo solo di Copilot come chatbot che scrive email al posto vostro. Negli ultimi mesi ho portato in produzione, o comunque in fase avanzata di test, diversi pezzi che si tengono insieme:
Copilot nelle applicazioni Office, per l’uso quotidiano diffuso a tutta l’azienda. Cowork / AppBuilder per automazioni più strutturate – un caso concreto è un workflow di approvazione richieste (RDA) che ha tolto di mezzo passaggi manuali, e una gestione documentale dei PDF che, a spanne, fa risparmiare qualcosa come 40 minuti al giorno per operatore.
Microsotìft Sentinel e Microsoft Defender come base della cybersecurity, ora affiancati da capacità AI nell’analisi degli alert. Su questo fronte è stato decisivo anche avere Microsoft Purview integrato nativamente: la protezione e la classificazione dei dati non è un layer aggiuntivo da collegare all’AI con fatica, ma è già lì, applicata anche a quello che passa attraverso Copilot. Per chi come me si occupa anche di sicurezza perimetrale e fisica, non solo di infrastruttura logica, avere un solo pannello di controllo per capire dove vanno i dati aziendali è una differenza che si sente.
Sto valutando Azure MCP Server per interrogare in linguaggio naturale le risorse Azure e i log via KQL, per accorciare la distanza tra “ho un dubbio di sicurezza” e “ho la query pronta per verificarlo”.
Il filo che li tiene insieme non è la tecnologia in sé. È che ogni pezzo si appoggia sugli stessi meccanismi di identità, audit e governance che uso già per il resto dell’infrastruttura, dai firewall perimetrali ai telefoni aziendali.
Cosa troverete nei prossimi articoli
Questo primo pezzo voleva rispondere a una domanda sola: perché Microsoft, e non un tool AI “puro”. La risposta breve è che in un’azienda con 130+ filiali, un team di 15 persone e un obbligo NIS2 da rispettare, l’integrazione e la governance pesano più della singola funzionalità che fa colpo la prima volta che la vedi. Nei prossimi articoli entro nel concreto: come ho configurato Copilot e Cowork a livello di tenant, come funziona oggi la scelta tra modelli diversi – inclusa la disponibilità di Claude di Anthropic dentro Copilot – come ho costruito i primi workflow veri, e come tutto questo si intreccia con il percorso di compliance NIS2 che sto ancora portando avanti.