IA locale e privacy: come verificare quali dati escono davvero dal tuo dispositivo

Che cosa significa davvero «locale»

«Locale» può descrivere aspetti diversi: dove sono archiviati i pesi del modello, dove viene calcolata una risposta oppure quali parti del flusso di lavoro avvengono sul dispositivo. Queste condizioni non sono equivalenti. Un modello può essere scaricato ed eseguito sul computer mentre l’applicazione consulta un servizio esterno per una funzione opzionale, controlla la disponibilità di aggiornamenti o cerca modelli disponibili. Può anche accadere che un’applicazione invii una richiesta a un server di inferenza in esecuzione sullo stesso dispositivo, ma salvi le conversazioni o i log in file accessibili ad altri utenti del sistema.

Perciò, la domanda utile non è soltanto «il modello è locale?», ma «quali componenti partecipano a questa attività, quali dati riceve ciascuno e quali prove ho del loro comportamento?». Il perimetro da controllare comprende l’interfaccia di chat, il processo che carica il modello, gli strumenti attivati, le estensioni, le connessioni di rete, l’archiviazione e i backup. La valutazione riguarda una configurazione specifica: versione dell’applicazione, impostazioni, sistema operativo, modello installato e azioni svolte.

Eseguire l’inferenza sul dispositivo può ridurre la necessità di inviare il prompt a un fornitore remoto per quella specifica operazione, ma non dimostra da solo che l’intera applicazione sia offline. Inoltre, non protegge automaticamente le informazioni da altri account che accedono al computer, software dannoso, autorizzazioni troppo ampie o file conservati dopo la chiusura dell’applicazione. Occorre distinguere fra luogo del calcolo, percorso dei dati e sicurezza del dispositivo.

Disegna il percorso dei dati prima di iniziare le prove

Fai l’inventario di tutti gli elementi coinvolti, non soltanto del modello. Includi l’applicazione che mostra la chat, il server di inferenza, il modello e il suo gestore di download; aggiungi poi ricerca sul Web, strumenti, estensioni, plugin, controlli degli aggiornamenti e opzioni che potrebbero usare servizi cloud. Se l’applicazione consente di passare da una modalità locale a una remota, annota quale modalità è attiva in ogni prova. L’etichetta mostrata nell’interfaccia non sostituisce la verifica delle impostazioni effettive.

Per ogni componente, registra quali informazioni potrebbe ricevere. Un prompt può contenere testo sensibile; un documento allegato può essere letto da uno strumento; una ricerca può trasmettere una query; un log può conservare input e output. Non presumere che tutti questi dati siano trattati allo stesso modo. Un servizio che calcola una risposta, una funzione che consulta Internet e un file di cronologia sono destinazioni e superfici di esposizione diverse.

L’inventario deve distinguere le singole attività. Scaricare un modello, installare un’estensione, scrivere un prompt, allegare un file, avviare una ricerca e controllare gli aggiornamenti sono azioni separate. Se le esegui tutte insieme, sarà difficile attribuire con chiarezza un cambiamento nel traffico. La metodologia NIST per caratterizzare il comportamento di rete offre una base per organizzare le osservazioni attorno ad attività definite in anticipo; il rapporto riguarda i dispositivi IoT, quindi qui viene adattato come metodo di prova, non come certificazione delle applicazioni di IA.

Una prova controllata offline

Una prova senza connessione a Internet consente di verificare quali funzioni restano disponibili dopo aver preparato l’ambiente, ma non dimostra che non ci sia mai stata una trasmissione. Prima di scollegare il dispositivo, installa l’applicazione, scarica il modello da valutare e prepara i documenti di prova. Annota quali risorse sono state ottenute durante questa fase. Se il prodotto offre ricerca, download su richiesta o strumenti remoti, identificali come funzioni distinte dalla chat di base.

Scollega il dispositivo da Internet con un metodo verificabile e annota lo stato della connessione. Prova separatamente una conversazione semplice con il modello già caricato, una richiesta che usa un documento locale e ogni funzione opzionale che ti interessa. Registra se l’attività termina, restituisce un messaggio di errore, resta in attesa o produce un risultato parziale. Ripeti le prove in condizioni simili ed evita di modificare più impostazioni fra una prova e l’altra.

Esprimi il risultato indicando chiaramente i suoi limiti. Se una conversazione funziona offline, puoi concludere che quella specifica attività ha funzionato in quella configurazione durante la prova. Non puoi concludere che l’applicazione non trasmetta mai dati, che non avvii connessioni quando tornerà online o che un’altra modalità d’uso si comporti allo stesso modo. Se una funzione non funziona, hai stabilito che, in quelle condizioni, l’operazione testata non era disponibile senza rete; questo, da solo, non identifica quali dati sarebbero stati inviati né a quale destinazione.

La documentazione di LM Studio, per esempio, distingue le attività che dichiara utilizzabili offline, come la chat e il lavoro con i documenti, da quelle che generano richieste di rete, come cercare o scaricare modelli e controllare gli aggiornamenti. È un esempio di come un’applicazione possa descrivere le proprie modalità, ma non sostituisce la verifica del dispositivo, della versione e delle impostazioni effettivamente valutate.

Osserva il traffico per singola attività

La prova più informativa separa gli eventi e prende nota di ciò che accade prima, durante e dopo ciascuno. Registra le connessioni a riposo; poi avvia il programma, carica il modello, invia un prompt di prova, allega un documento innocuo, attiva una ricerca, installa un’estensione e controlla gli aggiornamenti. Non riunire tutti i passaggi in un’unica sessione se devi attribuire le connessioni. Ripeti le azioni pertinenti per verificare se lo schema osservato si ripresenta.

Documenta il momento, l’azione, il processo associato, se riesci a identificarlo, la destinazione visibile e la durata approssimativa. Conserva anche le impostazioni esatte e gli eventuali messaggi di errore. Osservare una connessione non basta per affermare quale contenuto sia transitato; allo stesso modo, il nome di una destinazione non dimostra da solo che trattamento sia stato riservato ai dati. Se non puoi ispezionare il contenuto, registra questo limite e non colmare la lacuna con un’ipotesi.

Confronta tre situazioni: applicazione inattiva, uso di base e ciascuna funzione opzionale. Se compare una connessione durante un aggiornamento o un download, separala dalla prova del prompt. Se durante una prova non osservi traffico, limita la conclusione a quella prova e agli strumenti di monitoraggio utilizzati: una rilevazione momentanea potrebbe non intercettare connessioni intermittenti, ritardate o avviate da un altro componente. Per una verifica più importante, chiedi a una persona competente di documentare il metodo e ripetere il protocollo.

Controlla cronologia, log e autorizzazioni

La privacy non si esaurisce quando viene generata una risposta. Cerca dove vengono salvati conversazioni, documenti temporanei, cache e log. Controlla sia le impostazioni dell’applicazione sia i file che genera, poi verifica quali account del sistema possono leggerli. Considera anche la sincronizzazione delle cartelle, i backup e gli strumenti di diagnostica, se vengono usati sul dispositivo. Non presumere che chiudere una finestra equivalga a cancellare i dati o che un’opzione di pulizia riguardi tutti i componenti.

Come esempio specifico, la documentazione di LM Studio indica che le conversazioni vengono salvate in file JSON e descrive i percorsi per diversi sistemi operativi. La documentazione del comando per visualizzare il flusso dei log segnala che questi possono mostrare il testo di input e output del modello e del server. Sono dettagli utili per controllare quell’applicazione e la sua configurazione, ma non vanno automaticamente estesi ad altri runtime.

Prima di inserire informazioni sensibili, prova la cancellazione con dati fittizi: individua i file prima e dopo, usa il metodo documentato e controlla che cosa rimane. Se il prodotto non spiega dove vengono archiviati i dati o come eliminarli, registra il punto come incerto e chiedi chiarimenti al fornitore o all’amministratore del sistema. Limitare le autorizzazioni dell’account che esegue l’applicazione può ridurre il numero di persone in grado di accedere ai file, ma non sostituisce i controlli del sistema, la cifratura quando pertinente o una politica di conservazione.

Un server sul dispositivo potrebbe essere raggiungibile dalla rete

Un’API locale consente a un’applicazione client di inviare richieste al server di inferenza. «Locale» può significare che il processo è in esecuzione sul tuo computer, ma l’interfaccia di rete su cui è in ascolto determina da dove è possibile raggiungerlo. Un servizio limitato a un’interfaccia di loopback è pensato per ricevere richieste dallo stesso dispositivo; un servizio accessibile tramite un’interfaccia di rete può accettare connessioni da altri dispositivi, a seconda della configurazione e delle regole di rete. Verifica il comportamento effettivo, invece di dedurlo dalla parola «locale».

Controlla l’indirizzo di ascolto, la porta, le opzioni di accesso alla rete e i controlli di autenticazione. Verifica se un altro dispositivo della rete può raggiungere il servizio e se può inviare richieste senza credenziali. Fallo soltanto in un ambiente autorizzato, usando un modello e contenuti di prova. Una risposta del server non dimostra che tutti i suoi strumenti siano isolati: controlla separatamente quali file, funzioni o estensioni può richiamare il client che invia le richieste.

La documentazione di LM Studio descrive un server API locale utilizzabile su localhost o in rete. Questa possibilità è un motivo per ispezionare l’interfaccia e le impostazioni attive, non la prova che ogni installazione sia in ascolto sulla rete o sia esposta per impostazione predefinita. Se non hai bisogno di accedere al servizio da altri dispositivi, limita l’accesso al computer stesso usando le opzioni disponibili e le regole di sistema. Se invece l’accesso remoto è necessario, applica controlli di accesso e limita le autorizzazioni del processo a quelle indispensabili.

Distingui fatti osservati, dichiarazioni e questioni aperte

Un rapporto utile distingue tre livelli. Il primo riguarda ciò che è stato osservato: per esempio, una funzione specifica non ha funzionato offline oppure è stata registrata una connessione durante una determinata attività. Il secondo riguarda quanto dichiarato dal fornitore nella documentazione o nelle informative, come le funzioni che afferma essere disponibili offline o i casi in cui dichiara di trasmettere dati. Il terzo riguarda ciò che non è ancora stato stabilito: il contenuto di una connessione cifrata non ispezionata, il comportamento di un’altra versione o l’accesso ai file da parte di processi esterni.

Un’informativa sulla privacy è una fonte primaria per conoscere le dichiarazioni del fornitore sul proprio prodotto, ma non verifica in modo indipendente che cosa abbia fatto una specifica installazione. Viceversa, una cattura del traffico descrive ciò che uno strumento ha osservato in un determinato periodo e in una specifica configurazione, ma non sostituisce una spiegazione contrattuale sulla conservazione o sul trattamento dei dati. Combina i due tipi di evidenza e conserva la data, la versione e le condizioni di ciascuno.

La matrice seguente aiuta a evitare conclusioni più ampie di quanto consentano le prove. Se il risultato dipende da un’impostazione, registra sia lo stato osservato sia il valore esatto di quell’impostazione. Se non riesci a riprodurre un’osservazione o a identificarne l’origine, classificala come questione aperta. Per decisioni ad alto rischio, una valutazione informale non sostituisce la revisione della sicurezza, della privacy e dei requisiti legali applicabili.

Lista di controllo prima di usare dati sensibili

La decisione finale non dovrebbe dipendere da un’etichetta commerciale o da una singola prova. Valuta il tipo di dati, l’impatto di un’eventuale divulgazione, le funzioni davvero necessarie, l’accesso fisico e logico al dispositivo, il livello di evidenza raccolto e la possibilità di cancellare o controllare i log. Se non riesci a chiarire un punto importante, non trasformare l’incertezza in un’ipotesi favorevole: limita l’uso, disattiva la funzione dubbia oppure sospendi la valutazione finché non ottieni una risposta verificabile.

Per mantenere il controllo, conserva una breve registrazione della configurazione e del protocollo. Ripeti le prove dopo aggiornamenti importanti, modifiche alle estensioni o cambiamenti della rete: il risultato descrive la configurazione testata, non tutte le versioni future. Conserva schermate o note senza dati sensibili e limita l’accesso a questi materiali. Se rilevi un invio inatteso, sospendi l’uso di dati reali, conserva le prove non sensibili e chiedi una revisione tecnica prima di riprendere.

Usa questa lista come soglia pratica, non come certificazione di privacy. Per esplorare modelli locali, consultare confronti o scoprire altri strumenti, puoi partire dalle guide di Inferama sui modelli locali, dalle pagine di confronto e dal catalogo di scoperta; la valutazione della privacy, tuttavia, deve riguardare l’applicazione e la configurazione che userai davvero.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.