"Abbiamo una policy sull'AI." Dov'è l'inventario?

Immaginate la prossima riunione di governance.

Qualcuno chiede quali sistemi di intelligenza artificiale utilizza l'organizzazione. La policy arriva subito. Ha un numero di versione, una data di approvazione e la firma del direttore.

L'inventario richiede più tempo.

Il reparto IT invia un elenco di prodotti approvati. Il Marketing aggiunge l'assistente che usa tramite account personali. Le Vendite menzionano il bot che partecipa alle chiamate con i clienti. Le Risorse Umane dicono che la piattaforma di selezione del personale ha "alcune funzionalità di AI", ma nessuno sa con certezza quali siano attive.

Poi qualcuno chiede cosa fanno le persone con gli strumenti approvati.

Un secondo silenzio.

Tutti pensavano che qualcun altro stesse tenendo traccia. Non necessariamente qualcuno ha mentito. Hanno risposto a domande diverse: cosa era stato approvato, cosa era stato acquistato, cosa si ricordava.

Nessuna di queste coincide esattamente con ciò che viene usato. E sapere cosa viene usato non stabilisce ancora se viene usato correttamente.

Il vostro inventario AI deve descrivere l'organizzazione che avete, non quella che la vostra policy presuppone di avere.

Un elenco di fornitori non è un inventario AI

Il nome di un fornitore indica dove inviare la fattura. Non dice cosa fanno i dipendenti, quali informazioni entrano nel sistema o le cui decisioni vengono influenzate dai suoi output.

Si consideri un assistente usato per riscrivere testi di marketing pubblici. Ora si consideri lo stesso prodotto usato per valutare i candidati a una selezione. Il fornitore non è cambiato. La finalità, le informazioni e le persone coinvolte sì.

La mia raccomandazione è di mantenere un registro per sistema o per deployment, collegando poi i casi d'uso sostanzialmente diversi. Creare una voce separata per caso d'uso quando la finalità, i dati, i permessi o le conseguenze cambiano in misura tale da richiedere una valutazione distinta.

Non serve una riga per ogni prompt. È necessario distinguere "redige contenuti pubblici" da "supporta decisioni di selezione del personale".

Una riga per fornitore nasconde le differenze. Una riga per prompt crea un onere amministrativo insostenibile.

L'inventario non è un accessorio di governance improvvisato. Il Playbook del NIST AI Risk Management Framework affronta esplicitamente gli inventari dei sistemi AI nell'ambito di GOVERN 1.6, includendo perimetro, attributi registrati e responsabilità di manutenzione. (NIST AI Resource Center)

La domanda pratica è se il vostro inventario riesce a rispondere a una domanda di approfondimento.

L'AI che nessuno ha acquistato conta comunque

Si parta dalla shadow AI: strumenti o deployment utilizzati per lavoro senza adeguata visibilità o autorizzazione da parte dell'organizzazione.

Estendete il perimetro di discovery oltre i prodotti acquistati e standalone. Chiedete degli account personali, delle estensioni browser, degli assistenti per le riunioni, delle funzionalità AI integrate nei software esistenti, dei modelli sviluppati internamente e dei workflow che chiamano API di modelli esterni.

Chiedete anche dei fornitori. Un service provider sta usando l'AI per elaborare le vostre informazioni nell'ambito del lavoro che gli avete esternalizzato?

Non limitare l'esercizio alla AI generativa. Includere i sistemi di previsione, classificazione, riconoscimento delle immagini e raccomandazione basati su AI, laddove utilizzati. Una finestra di chat non è un requisito di accesso.

Mantenete visibili le scoperte incerte. "Funzionalità AI da verificare" è uno stato temporaneo accettabile. Escludere silenziosamente qualcosa perché nessuno la comprende non è un metodo di discovery.

Allo stesso modo, registrare gli usi dismessi o bloccati come tali. Non cancellare la loro esistenza solo perché non rientrano più nell'immagine approvata.

Trovare quei sistemi è necessario. Non è però l'intero lavoro.

Lo strumento è approvato. L'uso non lo è.

Ora eliminate gli account personali dalla storia.

Immaginate che tutti usino la piattaforma enterprise approvata. Il Procurement ha verificato il contratto. La Sicurezza ha rivisto il deployment. Il team Privacy ha valutato il trattamento proposto. Gli accessi sono gestiti. Il sistema ha un owner.

Poi qualcuno lo usa per qualcosa che nessuna di quelle revisioni aveva coperto.

Questa è la shady AI: uno strumento approvato usato in modo non governato o inappropriato.

Uso questa distinzione per separare due problemi che vale la pena indagare: gli strumenti che non avete adeguatamente censito e gli usi che sfuggono alla governance all'interno dell'ambiente approvato. Sono etichette operative, non un giudizio sull'intenzione dei dipendenti.

Si considerino tre esempi fittizi.

Un assistente è autorizzato per redigere comunicazioni interne generali. Un manager carica note di valutazione identificabili dei dipendenti e chiede di raccomandare chi dovrebbe essere promosso. Il prodotto è approvato. Quella finalità e quegli input non facevano parte dell'approvazione.

Un assistente per le riunioni è autorizzato per i normali incontri di progetto. Qualcuno lo porta in una discussione riservata su un reclamo di un dipendente, nonostante un'esclusione esplicita. Stesso fornitore, stesso account, confine diverso.

Oppure un assistente per il supporto clienti è approvato per redigere risposte, a condizione che un agente le verifichi prima di inviarle. Il team continua a usarlo per il supporto clienti. Nessuno aggiunge un connettore o modifica il modello. Semplicemente iniziano a inviare le bozze senza i controlli richiesti.

La shady AI non è solo un nuovo caso d'uso che nessuno ha valutato. È anche un caso d'uso approvato con le sue misure di sicurezza silenziosamente rimosse.

Il Playbook di NIST affronta esplicitamente l'uso improprio dei sistemi e la necessità di definire il perimetro dell'applicazione e le responsabilità umane. Verificare il nome di un prodotto rispetto a un elenco approvato non risolve quelle domande. (NIST AI Resource Center)

L'approvazione ha bisogno di un confine

"Approvato" ha bisogno di una seconda frase.

Approvato per quali attività? Con quali informazioni? Per quali utenti e destinatari? Con quale autorità di azione? Soggetto a quali controlli?

Senza quei confini, cosa viene esattamente chiesto ai dipendenti di rispettare?

Verificare se le condizioni sono state comunicate, se il workflow le rende praticabili e se qualcuno controlla che vengano rispettate. Non presumere che ogni deviazione sia dolosa. Non presumere nemmeno che l'assenza di intento doloso renda la deviazione innocua.

L'elenco degli strumenti approvati indica cosa le persone possono aprire. Non dice cosa possono fare una volta che è aperto.

Partire dal lavoro. Poi controllare i log.

"Usate l'AI?" non è la domanda da cui partirei.

Chiederei:

"Mostratemi come ora redigete, riassumete, traducete, codificate, classificate o formulate raccomandazioni. Cosa vi aiuta a svolgere quel lavoro?"

Poi chiedere cosa viene caricato, incollato, connesso o generato nel processo.

Svolgere queste conversazioni con le persone che fanno il lavoro, non solo con i responsabili di reparto. Chiedere degli esperimenti e degli account gratuiti, oltre che dei deployment ufficiali. Usare dimostrazioni anonimizzate; la discovery non richiede di copiare i dati dei clienti nelle proprie note.

Per gli strumenti approvati, aggiungere un'altra domanda:

"Cosa succede all'output e quali controlli avvengono prima che qualcuno agisca sulla base di esso?"

È lì che inizia l'indagine sulla shady AI. Un prodotto può essere presente in ogni documento di acquisto e tuttavia essere usato al di fuori dei suoi confini autorizzati.

Successivamente, riconciliare le risposte con le evidenze.

Esaminare acquisti, note spese, contratti e questionari ai fornitori. Nell'ambito della vostra visibilità autorizzata, esaminare inventari applicativi, integrazioni di identità, impostazioni di amministrazione SaaS, estensioni, endpoint di modelli e registri di sviluppo interno.

Investigare le discrepanze. Uno strumento dichiarato senza un acquisto corrispondente non è automaticamente una risposta errata. Un'integrazione che nessuno ha menzionato ha bisogno di un owner. Una funzionalità abilitata richiede una conversazione su se e come viene utilizzata.

Una connessione a un servizio non spiega, di per sé, la finalità aziendale né stabilisce quali informazioni sono state inviate. Registrare cosa è stato verificato, quando, cosa ha rilevato e cosa rimane incerto.

Illustrare l'esercizio ai dipendenti. Incoraggiare la disclosure senza promettere un'immunità generale per gli usi impropri. Concordare un approccio di monitoraggio proporzionato con i team di privacy e legale competenti, inclusa la necessaria consultazione dei dipendenti.

Limitare la raccolta, controllare gli accessi e definire i periodi di conservazione. Il principio di minimizzazione dei dati del GDPR si applica anche ai dati personali raccolti durante la discovery. (EUR-Lex)

Non risolvete la shadow AI creando sorveglianza ombra.

Costruire un registro che regge una domanda di approfondimento

Ecco la struttura operativa che utilizzerei. Trattarla come un punto di partenza pratico, non come l'affermazione che ogni framework prescriva esattamente queste colonne.

Mantenere distinguibili uso previsto, uso autorizzato e pratica osservata. Altrimenti, la voce diventerà silenziosamente un'altra copia della policy.

Non aggiungere una vaga colonna "Shady AI: sì/no" e considerare la questione risolta. Registrare il confine, l'osservazione e la differenza.

Un esempio, tre risposte diverse

Si consideri un deployment fittizio: AI-017, un assistente per la redazione di risposte al supporto clienti.

Maya, Head of Support, è owner del caso d'uso. L'assistente usa i ticket dei clienti e una knowledge base controllata per produrre bozze di risposta. La sua integrazione può salvare le bozze, ma non inviarle.

Il workflow autorizzato richiede che un agente di supporto verifichi accuratezza e adeguatezza prima dell'invio.

Durante una simulazione fittizia del workflow, l'agente genera una risposta e la invia senza verificare il contenuto. La revisione richiesta è diventata un clic.

La piattaforma è approvata. Il caso d'uso è autorizzato. La condizione d'uso non viene rispettata.

Sono tre risposte diverse. Una singola cella verde "Approvato" non può rappresentarle tutte.

Registrare l'osservazione, investigare la causa e assegnare un'azione correttiva. Verificare poi che la fase di revisione funzioni nella pratica, piuttosto che limitarsi a emettere un altro promemoria.

Rendere ugualmente esplicite le informazioni mancanti. "Conservazione sconosciuta; assegnata al supplier manager; risposta attesa entro venerdì" è un'indicazione operativa.

"Conservazione: conforme" non è una risposta a meno che qualcuno possa mostrare cosa significa e come è stato stabilito.

Prendere spunto dall'ormai noto SBOM. Costruire un AI-BoM.

Il software bill of materials, o SBOM, parte da un'idea utile: il nome del prodotto non dice cosa contiene il prodotto. Registra i componenti software e le loro relazioni nella supply chain. (NIST)

Un AI bill of materials, o AI-BoM, estende quel lavoro di composizione agli elementi specifici dell'AI. CycloneDX supporta informazioni su modelli, dataset, configurazioni e dipendenze. La documentazione AI di SPDX descrive anche le relazioni che coinvolgono modelli, dati, prompt e agenti. (CycloneDX)

Non si tratta del vostro foglio di calcolo degli strumenti approvati con un nome file più altisonante.

Mantenere distinti tre deliverable:

L'inventario registra cosa usa l'organizzazione, per quale finalità e sotto la responsabilità di chi.

L'AI-BoM registra di cosa è composto e da cosa dipende un determinato sistema.

Il registro dei rischi registra cosa potrebbe andare storto e cosa sta facendo l'organizzazione al riguardo.

Collegarli. Non trasformarli in tre versioni concorrenti della realtà.

Partire da un perimetro definito

Per questo esercizio, partire da un sistema specifico in produzione. Assegnare al suo record di composizione un identificatore, una revisione, un ambiente, una data e un maintainer. Collegare gli SBOM software esistenti e la documentazione a livello di modello dove disponibili.

Essere espliciti su ciò che il record descrive: l'intero deployment, un modello o un servizio del fornitore.

Il documento del modello di un fornitore non descrive l'integrazione con i ticket, il servizio di retrieval e i permessi che i vostri ingegneri hanno aggiunto attorno ad esso.

Per una prima versione pratica, raccoglierei o referenzierei i seguenti gruppi:

Questi gruppi riflettono le più ampie relazioni di composizione descritte da CycloneDX e SPDX. Mapparli nel formato in uso; conservare i dettagli di supporto in record collegati dove il formato scelto non li cattura direttamente. (CycloneDX)

Registrare le relazioni, non solo gli ingredienti

Per AI-017, collegare l'integrazione con i ticket, il servizio di retrieval dalla knowledge base, il modello di generazione ospitato, il template di prompt controllato e l'integrazione per la redazione delle bozze.

Quale componente legge il ticket? Quale fonte viene ricercata? Quale modello riceve le informazioni assemblate? Quale componente scrive la bozza?

Mantenere separati i dati di training dalle informazioni recuperate o fornite durante l'uso. "Dati" non è una relazione sufficientemente precisa.

Si immagini ora un cambio di modello o una libreria vulnerabile nel servizio di retrieval. I record collegati dovrebbero consentire di identificare il deployment interessato e il suo owner senza dover riavviare la discovery.

Raccogliere evidenze dalle configurazioni di deployment, dai manifesti delle dipendenze, dai registri dei modelli e dalla documentazione dei fornitori. Distinguere i fatti verificati internamente dalle dichiarazioni dei fornitori.

Quando un fornitore non divulga una versione esatta del modello o i dataset sottostanti, registrare la limitazione. Acquisire l'identificatore del servizio disponibile, la data della documentazione e le modalità di notifica delle modifiche. Non inventare una precisione che non esiste.

Partire da una tabella strutturata dove necessario, per poi passare a un formato machine-readable supportato dai propri strumenti. Non presumere che un foglio di calcolo diventi interoperabile solo perché il nome del file contiene "BOM".

Tenere fuori dall'AI-BoM credenziali, informazioni grezze sui clienti e contenuti riservati dei dataset. Referenziare invece record controllati.

Gli ingredienti possono restare invariati mentre l'uso va storto

Si torni ad AI-017.

Il modello, l'applicazione e le integrazioni rimangono invariati. Il team semplicemente smette di verificare le bozze.

L'AI-BoM non è necessariamente cambiato. La pratica operativa sì.

Collegare il record di composizione ai casi d'uso autorizzati, alle relative condizioni e alle evidenze dell'operatività reale. Aggiornare l'AI-BoM quando cambiano i componenti o le configurazioni registrati. Rivalutare l'uso quando cambiano la sua finalità, le informazioni, i destinatari o le misure di salvaguardia, anche quando il software non cambia.

Un AI-BoM completo non può dirvi se qualcuno ha effettivamente letto la risposta prima di inviarla.

"Si allena sui nostri dati?" non è l'intera valutazione della privacy

Fare la domanda sul training. Poi continuare.

Un impegno di no-training non risponde se le informazioni vengono conservate per l'erogazione del servizio, archiviate nelle cronologie delle conversazioni, accessibili al personale di supporto o trasmesse a un altro servizio. Trattarle come domande separate che richiedono evidenze.

Per ogni caso d'uso, esaminare prompt, allegati e fonti connesse. Seguire gli output e i log. Stabilire chi riceve le informazioni e quali siano le modalità di cancellazione verificate.

Per gli assistenti che possono agire, esaminare anche l'autorità oltre alle informazioni. Il sistema può leggere un'intera casella di posta, aggiornare un record cliente o inviare materiale all'esterno dell'organizzazione?

L'analisi della CNIL sull'AI agenziale evidenzia le complicazioni create da fonti di dati connesse, memoria persistente, movimenti tra servizi e azioni delegate. Portare alla funzione privacy una descrizione di quelle operazioni, non solo la pagina sulla sicurezza del vendor. (CNIL)

È qui che la shady AI conta. Una valutazione della redazione di comunicazioni interne generali non descrive l'uso di record di valutazione dei dipendenti per raccomandare promozioni.

Identificare la finalità effettiva del trattamento, le parti rilevanti, la base giuridica applicabile, le modalità di trasparenza e gli eventuali trasferimenti internazionali. Collegare l'inventario ai record di trattamento e alle valutazioni della privacy pertinenti. (EUR-Lex)

L'inventario e l'AI-BoM non soddisfano automaticamente tali requisiti. L'Articolo 30 del GDPR riguarda i registri delle attività di trattamento; l'Articolo 35 richiede una DPIA quando il trattamento è idoneo a presentare un rischio elevato per i diritti e le libertà delle persone. La presenza di "AI" nel nome del prodotto non è, di per sé, la valutazione. (EUR-Lex)

Proteggere anche l'inventario stesso. Un registro che descrive fonti sensibili e integrazioni potenti non deve diventare una directory aziendale di risorse interessanti a cui accedere.

"Scoperto" non significa "approvato"

Mantenere separati lo stato di discovery dall'autorizzazione.

"Segnalato da un reparto" e "verificato nella console di amministrazione" descrivono evidenze. "In fase di revisione", "autorizzato con restrizioni", "sospeso" e "dismesso" descrivono decisioni o stati operativi.

Se le condizioni d'uso vengano effettivamente rispettate richiede un'altra risposta.

Un sistema può essere verificato come presente e risultare comunque inaccettabile per l'uso corrente. Aggiungerlo al registro non lo legittima.

Instradare le scoperte verso la valutazione, con owner nominativi e date. Darei priorità all'indagine dove l'uso riguarda informazioni sensibili, decisioni consequenziali sulle persone, permessi ampi o dipendenze di produzione.

Per la shady AI, decidere se la risposta richiede chiarire le istruzioni, ripristinare una misura di salvaguardia, limitare l'accesso, valutare un nuovo uso o interrompere l'attività.

Dove mancano informazioni, decidere cosa può accadere mentre la lacuna viene colmata. "In fase di revisione" non deve significare "proseguire indefinitamente".

Dove la discovery suggerisce un'esposizione o un incidente, utilizzare il processo di risposta esistente. Completare la voce dell'inventario non equivale al contenimento. Le linee guida di governance di NIST collegano esplicitamente il monitoraggio dell'AI alla risposta agli incidenti e alla responsabilità di gestire i problemi. (NIST AI Resource Center)

Una volta stabiliti i fatti, collegarli al lavoro di gestione del rischio esistente. Gli articoli sulla costruzione di un registro dei rischi AI e sull'integrazione del rischio AI nell'ISMS trattano il passo successivo. (Cyber Academy)

Una cella verde è una decisione che qualcuno deve essere in grado di spiegare.

Tenerlo aggiornato, o chiamarlo documento storico

Assegnare un custode all'inventario e business owner alle sue voci. I technical owner devono mantenere le evidenze di composizione e configurazione pertinenti. Il Playbook di NIST tratta la titolarità definita e la revisione continua come attività di governance, non come operazioni di manutenzione facoltative dopo la raccolta iniziale. (NIST AI Resource Center)

Collegare gli aggiornamenti ai cambiamenti che già richiedono attenzione: nuovi casi d'uso, funzionalità abilitate, modifiche ai modelli, nuove fonti di dati, integrazioni aggiuntive, permessi modificati e dismissioni.

Includere anche i cambiamenti operativi. Rimuovere una fase di revisione o modificare chi riceve un output può richiedere una rivalutazione anche quando non viene rilasciato nuovo codice.

Per AI-017, passare da "salva bozze di risposta" a "invia risposte automaticamente" richiede una nuova decisione. Scoprire che gli agenti inviano già le bozze senza verificarle richiede un'azione immediata, non al prossimo rilascio software.

Aggiornare insieme i record collegati e conservare le versioni precedenti rilevanti. È necessario stabilire cosa era in uso al momento di un evento, non solo cosa è configurato oggi.

Usare le revisioni periodiche per rilevare i cambiamenti mancati, non come autorizzazione a ignorare tutto ciò che accade tra una revisione e l'altra.

Per il reporting al management, mostrare la titolarità verificata, le valutazioni in ritardo, le lacune informative irrisolte e le deviazioni dalle condizioni approvate. Descrivere il perimetro del lavoro di discovery svolto.

Prestare attenzione all'affermazione "100% dell'AI inventariata". Contare tutto ciò che è già nel proprio elenco non dimostra che non manchi nulla.

Partire dall'inventario. Poi collegare il resto.

Scegliere un reparto e analizzare il suo lavoro reale.

Registrare i sistemi e gli usi. Verificare i owner. Tracciare le informazioni. Confrontare le condizioni approvate con la pratica osservata. Costruire l'AI-BoM per un deployment significativo e collegarlo all'inventario.

Trasformare le domande senza risposta in azioni assegnate.

Questo fornisce un punto di partenza migliorabile, non un'affermazione di completezza priva di fondamento.

La prossima volta che qualcuno chiede quale AI utilizza l'organizzazione, dovete essere in grado di mostrare cosa avete trovato, da cosa dipende, chi ne è responsabile e cosa resta ancora da risolvere.

Potete allegare anche la policy. Non dovrebbe però essere la vostra unica risposta.

Per il lavoro di governance più ampio, esplorate il mio AI Risk Governance Toolkit. Utilizzatelo insieme a questo approccio, con i fatti, i owner e le decisioni di cui la vostra organizzazione ha effettivamente bisogno.

Esplora l'AI Risk Governance Toolkit →

Trovate l'AI che nessuno ha dichiarato. Esaminate l'AI che tutti hanno approvato. Documentate da cosa dipendono entrambe e verificate come vengono entrambe utilizzate.