Prima di collegare i dati aziendali a un assistente AI

Collegare un assistente AI ai dati aziendali è una decisione sui permessi, non il rilascio di un prodotto. Si parta dal presupposto che tutto ciò che l'assistente può leggere possa essere estratto da chiunque sia in grado di interagire con esso, e che tutto ciò che può fare possa essere attivato da chiunque riesca a influenzarne l'input. Prima dell'avvio del pilota occorre chiarire cinque aspetti: quali dati sono ammessi, che cosa può fare l'assistente, chi può usarlo, che cosa viene registrato e chi è responsabile del rischio.

Una precisazione sulle fonti. I punti tratti da OWASP o NIST sono indicati come tali e corredati di link. Tutto il resto di questa checklist è una nostra raccomandazione, non un requisito imposto da nessuno dei due enti.

Decidere quali dati possono essere utilizzati

Si parta dalla classificazione, perché ogni controllo successivo ne dipende. Se non esiste uno schema, per cominciare ne basta uno a tre livelli, che deve essere messo per iscritto prima che qualcuno colleghi una casella di posta, un file share o un CRM.

Due aspetti colgono spesso impreparati i team. Primo: i connettori di norma acquisiscono interi repository o unità, quindi una cartella di cui nessuno ricorda la condivisione finisce indicizzata. Conviene ripulire le condivisioni prima del collegamento, non dopo. Secondo: i secret presenti nei documenti (chiavi API nelle pagine wiki, password nei ticket) trasformano una funzione di ricerca in una fuga di credenziali.

Presumere che l'assistente leggerà testo ostile

Tutto ciò che l'assistente legge (email in arrivo, pagine web, documenti condivisi, file caricati) va trattato come contenuto che qualcun altro potrebbe aver scritto per manipolarlo. Raccomandiamo di progettare il deployment in modo che ciò non provochi danni, anziché fare del system prompt l'unico controllo.

In pratica:

• Dotare l'assistente del numero minimo di strumenti necessari. Prima di tutto, accesso in sola lettura.
• Richiedere la conferma di una persona per qualsiasi azione con effetti collaterali: invio di email, modifica di record, esecuzione di codice, pagamenti.
• Tenere i contenuti non attendibili lontani dagli assistenti che hanno accesso anche a dati riservati.
• Trattare l'output dell'assistente come input non attendibile per qualunque sistema lo consumi. Se un sistema a valle lo esegue o lo renderizza, va validato come qualsiasi input utente.

Per un elenco di riferimento dei rischi delle applicazioni LLM si consulti la OWASP Top 10 for Large Language Model Applications. La pagina del progetto descrive l'OWASP GenAI Security Project come un'iniziativa open source globale che copre i rischi di sicurezza e di safety dell'AI generativa, inclusi gli LLM, i sistemi di agentic AI e le applicazioni basate su AI. Indica che la Top 10 resta una componente centrale ed elenca una versione 2025. La pagina rimanda a genai.owasp.org/llm-top-10/ per l'elenco più recente. Consigliamo di leggere quell'elenco e di usarne le categorie come struttura del proprio threat model, anziché inventarne una propria.

Controllo degli accessi e logging

L'assistente dovrebbe operare con i permessi della persona che pone la richiesta, non con un service account ad ampio raggio. Se utilizza un'unica identità condivisa con accesso a tutto, un collaboratore junior potrebbe riuscire a recuperare documenti del consiglio di amministrazione formulando bene una domanda. Occorre verificare come il connettore gestisce i permessi per singolo utente e testarlo con due account di diversa seniority prima del go-live.

Poi si decida che cosa registrare. Come minimo serve abbastanza per ricostruire un incidente:

timestamp, user id, assistant/tool name,
source documents retrieved, actions requested,
actions executed, confirmation (yes/no), result status

Si stabilisca in anticipo per quanto tempo conservare questi log, chi può leggerli e se i prompt stessi contengano dati personali. I log delle conversazioni sono a tutti gli effetti un archivio di dati e richiedono la stessa classificazione dei contenuti che riportano. Vanno inviati a chi si occupa del monitoraggio, in modo che un volume anomalo di recuperi da un singolo account non passi inosservato.

Valutare il fornitore prima del contratto

Si rivolgano al fornitore domande dirette e si ottengano le risposte per iscritto:

1. I nostri prompt e i nostri documenti vengono usati per addestrare o migliorare i modelli? Questo può essere escluso per contratto, e non solo tramite un'impostazione?
2. Dove vengono elaborati e conservati i dati e quali sub-responsabili sono coinvolti?
3. Per quanto tempo vengono conservati prompt, output e file caricati, e possiamo cancellarli?
4. Quali controlli amministrativi sono disponibili: single sign-on, accesso basato sui ruoli, esportazione degli audit, allow-list dei connettori?
5. Come vengono notificati gli incidenti di sicurezza e entro quanto tempo?

Si verifichi che le risposte corrispondano alla console di amministrazione reale. Una pagina di policy e un'impostazione configurabile sono cose diverse. Se lo strumento offre plug-in o connettori di terze parti, questi vanno valutati come fornitori distinti.

Assegnare un responsabile al rischio

La governance sembra burocrazia, e in parte lo è, ma è ciò che impedisce i deployment non autorizzati. Il NIST AI RMF Playbook fornisce azioni suggerite allineate alle quattro funzioni dell'AI Risk Management Framework: Govern, Map, Measure e Manage. NIST precisa che il Playbook non è né una checklist né una serie di passaggi da seguire integralmente, e che i suoi suggerimenti sono volontari. Segnala inoltre che l'AI RMF 1.0 è in fase di aggiornamento e che il Playbook seguirà, quindi conviene controllare la versione corrente. Si adotti ciò che si adatta a un'azienda della propria dimensione.

La nostra raccomandazione è tenere un breve registro di tutti gli strumenti AI in uso, ciascuno con un responsabile, i livelli di dati che può toccare e una data di revisione. Si aggiunga una colonna ulteriore: se l'ufficio legale ha confermato che per quel caso d'uso si applicano gli obblighi dell'EU AI Act o del GDPR, e a quali conclusioni è giunto. Non abbiamo valutato qui tali obblighi, quindi la decisione va demandata a un consulente legale o a un esperto di compliance. Se desidera supporto nella creazione del registro e del processo di revisione, il nostro servizio di consulenza comprende valutazioni di readiness.

Da dove iniziare

1. Elencare ogni assistente AI già in uso, compresi gli account gratuiti che i dipendenti hanno attivato per conto proprio, e nominare un responsabile per ciascuno.
2. Redigere la classificazione a tre livelli descritta sopra e indicare a quale livello appartiene ciascuna fonte di dati collegata. Escludere dal perimetro le fonti riservate.
3. Avviare un pilota con accesso in sola lettura, permessi per singolo utente e conferma umana per ogni azione. Testarlo con due account di diversa seniority.
4. Attivare il logging, definire un periodo di conservazione e inviare i log a chi monitora i sistemi.
5. Inviare le domande al fornitore, conservare le risposte scritte insieme al contratto e chiedere all'ufficio legale di confermare se si applicano gli obblighi dell'EU AI Act o del GDPR.
6. Prima di un rilascio più ampio, far testare la configurazione da qualcuno che tenti di attaccarla. Un penetration test con scenari costruiti sui connettori effettivamente in uso mostra ciò che un threat model sulla carta non rileva.