Sicurezza dei dati nell'implementazione dell'IA: cosa può essere condiviso con i modelli e cosa no

«E dove finiranno i nostri dati?» È una domanda che sentiamo a ogni primo incontro. E a ragione. Perché la cosa peggiore che si possa fare è copiare un contratto con un cliente in un chatbot pubblico «solo per fargli fare un breve riassunto».

Vediamo come si fa in modo corretto.

1. Partite dalla classificazione dei dati

Non tutti i dati sono uguali. Prima di automatizzare qualsiasi cosa, metteteli in ordine:

• Pubblici: catalogo, prezzi sul sito, articoli aperti al pubblico. Qui i rischi sono quasi nulli.
• Interni: regolamenti, istruzioni, corrispondenza. Se trapelano è spiacevole, ma non è una catastrofe.
• Dati personali: nomi, numeri di telefono, indirizzi di clienti e dipendenti. Qui si applica la legge, quindi vanno trattati di conseguenza.
• Segreto commerciale: prezzi per clienti chiave, report finanziari, condizioni contrattuali. È la categoria più sensibile.

Per ogni categoria servono regole proprie. E queste regole vanno fissate prima di partire, non dopo.

2. Tre opzioni di deployment

API cloud dei grandi fornitori. I modelli più potenti, con il minimo di infrastruttura. C’è però una sfumatura importante: le condizioni d’uso dei dati nelle API business e in una chat pubblica gratuita non sono le stesse. Prima di trasmettere dati sensibili, bisogna leggere con attenzione i termini del fornitore specifico e scegliere il piano adatto.

Modelli locali sul vostro server. I dati non escono affatto dal vostro perimetro. Oggi i modelli aperti sono già adatti a molte attività: classificazione, estrazione di campi, ricerca nei documenti. Il prezzo da pagare è hardware e manutenzione.

Ibrido. Spesso è la scelta più sensata. Le informazioni sensibili vengono elaborate in locale oppure anonimizzate, mentre i compiti più complessi con dati non sensibili vanno a un modello cloud più potente.

3. Regole pratiche che funzionano

• Anonimizzazione. Prima di inviare un testo a un modello esterno, sostituite nomi, numeri di telefono e numeri di conto con etichette. Il modello riceverà il contenuto, non i dati personali.
• Diritti di accesso. L’assistente aziendale mostra a un dipendente solo i documenti a cui ha già accesso.
• RAG invece del fine-tuning. I vostri documenti restano nel vostro database, e il modello riceve solo il frammento necessario per quella risposta specifica. Maggiori dettagli nell’articolo cos’è RAG.
• Registro delle attività. Ogni richiesta, risposta e chiamata a uno strumento viene registrata. Se qualcosa va storto, si vede esattamente cosa è successo e quando.
• Chiavi solo sul server. Le API key non devono mai finire nel browser o nell’app mobile.
• NDA. Prima di entrare davvero nelle vostre basi dati, firmiamo un accordo di non divulgazione e facciamo i test su dati sintetici o anonimizzati.

4. Cosa non fare assolutamente

• Non copiare documenti sensibili in chat pubbliche gratuite.
• Non dare a un agente di IA permessi più ampi di quelli realmente necessari per il compito.
• Non collegare il modello direttamente al database di produzione senza un livello intermedio di controlli.

La sicurezza non è un’opzione separata da aggiungere alla fine. Va progettata nell’architettura fin dal primo giorno. Durante l’audit dei processi aziendali analizzeremo i vostri dati e sceglieremo l’opzione di deployment più adatta. Se volete capire come funziona tutto questo in una base di conoscenza aziendale, leggete la pagina Base di conoscenza aziendale e RAG.