AI locale, privacy e GDPR

Guida: Intelligenza Artificiale Locale › Privacy e GDPR

Eseguire l’AI in locale può ridurre trasferimenti e dipendenze da servizi esterni, ma non garantisce di per sé la conformità al GDPR. Anche in azienda contano base giuridica, finalità, minimizzazione, accessi, log, tempi di conservazione e sicurezza dei sistemi. Se vengono usati plugin, aggiornamenti, backup esterni o modelli cloud, va documentato dove transitano realmente i dati. Questa guida distingue i vantaggi tecnici dalle responsabilità del titolare del trattamento.

Privacy, GDPR e aspetti legali

Per chiunque tratti dati di persone in Europa, questo capitolo conta. Nota: queste sono indicazioni generali, non consulenza legale; per casi specifici, rivolgiti a un esperto.

Perché il locale aiuta con il GDPR

Il GDPR richiede di valutare ogni trattamento di dati personali, anche quando l’inferenza avviene su un server interno. Per un progetto AI occorre identificare finalità, base giuridica, categorie di dati, soggetti autorizzati, retention e possibili trasferimenti tramite componenti accessori. Un’installazione on-premise può semplificare alcune scelte architetturali, ma non risolve automaticamente l’analisi dei rischi, le misure di sicurezza o gli eventuali obblighi di informazione. Si veda il parere EDPB sull’AI per il quadro di riferimento.

Le tue responsabilità restano

Attenzione: il locale semplifica la conformità, non la elimina. Restano tue le responsabilità di base. Devi comunque proteggere il sistema (la sicurezza della Parte VI è parte della conformità: dati ben protetti, accessi controllati). I log delle conversazioni, se contengono dati personali, sono essi stessi dati da trattare secondo le regole — protetti, conservati solo per il necessario, cancellabili su richiesta. Devi informare gli utenti su come tratti i loro dati, anche con un assistente locale. E se l’assistente prende decisioni che riguardano le persone, valgono le regole sulle decisioni automatizzate. In sintesi: il locale toglie il problema più grosso (i dati che escono verso terzi), ma la buona gestione resta a carico tuo.

Un vantaggio competitivo, non solo un obbligo

C’è un risvolto positivo. Sempre più clienti, soprattutto aziendali, fanno domande serie su dove finiscono i loro dati quando toccano un sistema AI. “Li mandiamo a un fornitore esterno” sta diventando una risposta scomoda in molte trattative. Poter dire “il nostro sistema AI gira sulla nostra infrastruttura, i vostri dati non escono” è sempre più un vantaggio competitivo, non solo un adempimento. Per chi offre servizi, costruire sul locale può diventare un argomento di vendita, non solo una cautela.

Quando l’AI locale è davvero locale

Dire “AI locale” non basta: bisogna verificare l’intera catena. Il modello può girare in azienda, ma se l’interfaccia manda telemetria fuori, se i log finiscono su un servizio esterno, se i backup sono sincronizzati senza regole o se l’assistente usa API cloud per completare alcune risposte, allora il trattamento non è più completamente locale. La configurazione corretta va progettata dall’inizio: modello, interfaccia, database vettoriale, file caricati, log, backup e accessi devono stare dentro un perimetro controllato.

Checklist minima di conformità

• Finalità chiara: definisci perché usi l’assistente e quali dati può trattare.
• Minimizzazione: carica solo documenti utili, non archivi interi “per sicurezza”.
• Accessi: ogni utente deve vedere solo ciò che è autorizzato a vedere.
• Log: conserva conversazioni e prompt solo per il tempo necessario, con cancellazione gestibile.
• Backup: cifrati, con retention definita e accesso limitato.
• Audit: registra chi usa il sistema e quando vengono eseguite azioni operative.
• Informativa: spiega agli utenti come vengono trattati i dati anche se il sistema è interno.

Titolare, responsabile e fornitori

Se l’azienda usa una macchina propria nella propria sede, il perimetro è più semplice: resta comunque titolare del trattamento e deve gestire sicurezza, informative e diritti degli interessati. Se invece un fornitore installa, manutiene o accede al sistema, va chiarito il suo ruolo: semplice assistenza tecnica, amministratore di sistema, responsabile del trattamento o altro. La differenza non è burocratica: decide chi può accedere ai dati, con quali istruzioni e con quali obblighi documentali.

Il limite da non superare

L’AI locale non autorizza a usare qualunque dato in qualunque modo. Se il sistema tratta dati sanitari, legali, finanziari, dati di dipendenti o informazioni molto sensibili, serve una valutazione più rigorosa: basi giuridiche, permessi, tempi di conservazione, misure tecniche e, nei casi ad alto rischio, una valutazione d’impatto. Il vantaggio del locale è che riduce esposizione e trasferimenti; non sostituisce una buona governance.

Esempio di configurazione prudente

Una configurazione prudente per una piccola azienda prevede: server locale o workstation dedicata, accesso solo da rete interna o VPN, autenticazione per ogni utente, cartelle documentali separate per reparto, log ridotti al minimo, backup cifrati e un amministratore incaricato. L’assistente deve rispondere solo sui documenti autorizzati e deve poter dire “non ho abbastanza informazioni” quando il RAG non trova fonti utili. Questa frase è importante: un sistema conforme e affidabile non deve sempre rispondere, deve rispondere quando ha basi sufficienti.

Se l’assistente viene esposto al pubblico, per esempio su un sito web, il perimetro cambia: servono filtri sugli input, limiti di uso, protezione da prompt injection, separazione netta tra dati pubblici e dati interni, informativa privacy aggiornata e nessun accesso diretto ai documenti riservati. In quel caso l’AI locale protegge l’infrastruttura, ma la superficie di attacco resta pubblica e va trattata come qualunque applicazione web esposta.

← ApplicazioniTroubleshooting →