Nel primo articolo di questa serie ho raccontato perché ho scelto di portare l’AI in azienda partendo dall’ecosistema Microsoft già in uso, invece che da un tool esterno. Ho anche accennato a un tema che, quando ne parlo con altri IT Manager e CISO, genera quasi sempre la stessa reazione: stupore. La NIS2, per me, non è stata un ostacolo all’adozione dell’AI. È stata, paradossalmente, quello che mi ha aiutato a farla bene fin dall’inizio.
So che suona controintuitivo e utopico. Chi si occupa di compliance normalmente (e solitamente io sono tra questi) la vive come un freno: un ulteriore livello di burocrazia che rallenta ogni decisione tecnologica.
Provo a spiegare perché nel mio caso è andata diversamente.
Il ruolo che mi ha costretto a guardare le cose da vicino
Sono il sostituto del Punto di Contatto ACN della mia azienda, che rientra tra i “soggetti importanti” secondo il “famoso Decreto”. Questo significa che negli ultimi mesi ho passato parecchio tempo a fare cose che, detto sinceramente, nessuno fa per piacere: censire i fornitori rilevanti, categorizzare attività e servizi, confrontare il piano di risposta agli incidenti con quello che la norma richiede davvero, non con quello che pensavamo bastasse.
Il punto è che questo lavoro mi ha obbligato a farmi, per ogni fornitore tecnologico, una domanda che molti si pongono solo dopo aver già firmato un contratto: chi processa i miei dati, dove, e con quali garanzie contrattuali. Non sono domande astratte. Vuol dire aprire i Data Processing Agreement, capire chi sono i subprocessor, verificare dove risiedono i dati, e mettere tutto questo per iscritto in un registro che, in caso di controllo, deve reggere.
Quando è arrivato il momento di valutare l’AI generativa, questa domanda me l’ero già fatta cento volte per altri fornitori. Non ho dovuto inventarmi un processo nuovo: ho applicato lo stesso metodo che uso per un fornitore di connettività o per un partner di backup.
Perché essere già dentro un perimetro censito ha fatto la differenza
Qui torna il discorso del primo articolo. Il vendor principale del nostro ecosistema era già, di fatto, un fornitore critico censito, con DPA e Product Terms negoziati a livello enterprise. Quando abbiamo iniziato ad attivare funzionalità AI dentro Copilot e poi Cowork, non ho dovuto aprire un fascicolo fornitore da zero: rientravano già nel perimetro contrattuale esistente. Ho dovuto aggiornarlo, certo, e verificare punti specifici legati proprio all’AI — modelli usati, subprocessor coinvolti, residenza dei dati di training e di inferenza — ma partivo da una base solida, non da un foglio bianco.
Chi invece adotta un tool AI “verticale” scelto sul momento, magari perché lo usa un singolo reparto o un dirigente entusiasta (perché ammettetelo, tutti abbiamo un dirigente entusiasta di un tool che gli hanno fatto vedere!), si trova spesso a dover fare questo lavoro sotto pressione, a valle, quando ormai lo strumento è già in uso da mesi e i dati sono già passati di lì. È una delle situazioni più scomode che mi sia capitato di gestire con altri fornitori non-AI, e ho preferito evitarla a monte.
Il censimento come strumento di decisione, non solo di controllo
C’è un altro aspetto che ho scoperto lavorando alla categorizzazione NIS2: il censimento dei fornitori e delle attività non è solo un adempimento da consegnare. È diventato, per me, uno strumento pratico per decidere dove valeva la pena spingere sull’AI e dove no.
Nel nostro caso, mappare 21 attività aziendali su 10 macro-aree richieste dalla normativa mi ha dato una fotografia molto più chiara di quali processi fossero critici, quali toccassero dati sensibili, e quali invece fossero candidati “sicuri” per un primo rollout di automazione AI. Il workflow di approvazione RDA che ho raccontato nel primo articolo, per dire, l’ho scelto anche perché rientrava in un’area a rischio più basso rispetto ad altre — una scelta che difficilmente avrei fatto con la stessa lucidità se non avessi già in mano quella mappatura.
Cosa consiglio a chi si trova nella mia stessa posizione
Se gestite un’azienda che rientra nel perimetro NIS2, o comunque un contesto regolamentato, il mio consiglio è di non trattare la compliance e l’adozione dell’AI come due binari separati che si scontrano. Nel mio caso hanno viaggiato sullo stesso binario, e la seconda ha beneficiato del lavoro fatto per la prima. Il censimento fornitori, la categorizzazione delle attività, la revisione dell’IRP (Incident Response Plan): sono tutte attività che, fatte bene, tolgono attrito a qualsiasi decisione tecnologica venga dopo, AI compresa.
Non significa che tutto sia stato semplice. Restano scadenze da rispettare, documenti da presentare al board e all’ufficio legale, e un lavoro di aggiornamento continuo perché la normativa e i suoi chiarimenti evolvono. Ma la cornice che la NIS2 mi ha dato — sapere sempre chi tratta i miei dati e come — è la stessa cornice che mi ha permesso di dire sì all’AI generativa senza passare mesi a rincorrere garanzie a posteriori.
Nel prossimo articolo entreremo nel pratico: come ho configurato Copilot e Cowork a livello di tenant, partendo proprio da questa base di governance già pronta.