Costruire un inventario AI su più sedi

Un'organizzazione con più sedi ha raramente un unico luogo in cui vengono prese le decisioni relative al software. Una sede stipula una licenza, un'altra utilizza una versione gratuita dello stesso strumento, e una terza ha un partner IT locale che ha configurato qualcosa senza consultazione. Un inventario AI che voglia cogliere questa realtà non deve quindi partire da un unico file di origine, ma da più fonti che si completano e si contraddicono a vicenda.

Perché le sedi non danno la stessa immagine

Ogni sede ha una propria storia di acquisti, propri fornitori e spesso un proprio grado di autonomia nelle scelte IT. Ciò che nella sede centrale è un'eccezione può essere diventato la norma in un'altra sede senza che nessuno lo abbia registrato. Un inventario centrale che interroga solo la sede centrale manca quindi per definizione di una parte del quadro. Perché l'elenco IT non è corretto spiega perché una registrazione centrale corrisponde raramente a ciò che viene effettivamente utilizzato, e questo problema si aggrava quando ci sono più sedi.

Cosa registrare per ogni sede

La base è la stessa per ogni sede: quale applicazione viene utilizzata, da chi, per quale compito e sulla base di quali dati. Inoltre è rilevante se l'applicazione è stata acquistata localmente o è stata messa a disposizione centralmente, e se dietro c'è un fornitore che documenta già di per sé come funziona il sistema, oppure se la sede ha assemblato o adattato il sistema stessa. Questa distinzione determina infatti chi è responsabile per ciò che accade esattamente. Cosa registrare per ogni applicazione lo descrive nel dettaglio, e la stessa registrazione vale indipendentemente dalla sede: solo il modo in cui si recuperano le informazioni varia da una sede all'altra.

Da dove provengono i dati

Con una sola sede è semplice chiedere in giro. Con più sedi ciò non è più gestibile senza una struttura. Due fonti sono allora utilizzabili in parallelo. La prima è ciò che l'ambiente IT stesso già mostra: registri di acquisto, file di licenza e segnali tecnici che indicano l'uso di AI, anche se nessuno ha segnalato esplicitamente tale utilizzo. Cosa rivelano i dati di acquisto e licenza mostra quali indizi si possono trovare in essi, e quali segnali IT sono utilizzabili approfondisce l'aspetto tecnico: quale traffico, quali abbonamenti e quali integrazioni indicano un uso dell'AI che non è registrato formalmente da nessuna parte.

La seconda fonte è il collaboratore stesso. Nessuna scansione tecnica rileva perché qualcuno utilizza uno strumento, per quale compito esattamente, o quanto spesso. Questo lo sa solo chi svolge il lavoro. Con più sedi ciò significa che è necessario un modo per porre questa domanda ovunque nello stesso modo, senza che una sede si senta più controllata di un'altra. Come chiederlo senza conseguenze descrive perché questa condizione sia determinante per l'attendibilità di ciò che si raccoglie: chi teme una conseguenza risponde in modo incompleto o non risponde affatto, e questo effetto non è necessariamente distribuito allo stesso modo tra sedi con culture o stili di gestione diversi.

Un ruolo per applicazione, indipendentemente dalla provenienza

Un'applicazione acquistata nella sede A e adottata informalmente nella sede B resta la stessa applicazione, con lo stesso ruolo e lo stesso livello di rischio. L'inventario non deve quindi essere classificato separatamente per sede, ma per applicazione, con un'annotazione su dove e da chi viene utilizzata. Così si evita che lo stesso strumento venga valutato in modo diverso in due luoghi, e che un rischio già segnalato in una sede resti inosservato in un'altra. È rilevante anche se la sede ha costruito o configurato qualcosa essa stessa sulla base di un modello di AI, oppure se acquista semplicemente un prodotto già pronto. Siete fornitore o utilizzatore aiuta a fare questa distinzione, che può variare da una sede all'altra, anche in caso di utilizzo della stessa tecnologia sottostante.

Unire tutto in un unico quadro

Una volta raccolti i dati delle sedi, il passo successivo è unirli in un unico elenco senza duplicati, con per ogni applicazione un ruolo chiaro, una stima del rischio e un'indicazione di dove viene utilizzata. Questo quadro costituisce la base per determinare quali misure di governance sono necessarie e dove richiedono attenzione prioritaria. Il modo esatto in cui questo quadro viene costruito e mantenuto dipende dalle dimensioni e dalla struttura dell'organizzazione; non esiste un modello fisso valido per ogni situazione.