Come fa un server AI domestico a mantenere separato il contesto di ogni utente?

Un server AI domestico può mantenere separato il contesto di ogni utente pur condividendo lo stesso modello, ma la separazione non deriva dal modello stesso. Deriva dal legare ogni chat, record di memoria, documento recuperato, voce di cache e chiamata a uno strumento a un utente autenticato prima che quell’informazione raggiunga il prompt.

Se due persone possono accedere separatamente ma la domanda di un utente recupera le note di un’altra persona, il problema è solitamente nell’applicazione attorno al modello. Il test utile è se l’identità sopravvive all’intero percorso della richiesta. Questo articolo segue quel percorso e mostra dove l’isolamento deve essere applicato, dove comunemente si rompe e quando è giustificato un confine più forte.

Il modello può essere condiviso, ma il contesto personale no

I pesi del modello sono il motore di ragionamento comune. Non serve una copia separata per ogni membro della famiglia o collega quando il modello serve richieste di inferenza ordinarie. Ciò che deve rimanere separato è l’informazione assemblata attorno a quei pesi per una richiesta particolare.

Queste informazioni includono la chat corrente, la cronologia delle conversazioni salvate, le preferenze dell’utente, i passaggi di file recuperati, i risultati della ricerca vettoriale, gli output degli strumenti, le cache temporanee e le credenziali. Insieme, questi livelli formano il contesto personale. Un utente diverso dovrebbe ricevere un pacchetto di contesto diverso anche quando entrambe le richieste passano attraverso lo stesso processo modello.

Questa distinzione mantiene l’architettura pratica. Un server domestico può evitare di caricare diverse copie identiche del modello pur isolando i dati che rendono personale ogni assistente. Il confine di isolamento appartiene all’identità, allo storage, al recupero, alle sessioni e all’accesso agli strumenti, non a un prompt che semplicemente dice al modello di rispettare la privacy.

L’identità deve seguire la richiesta fino alla fine

Schermate di accesso separate sono solo il primo passo. L’autenticazione stabilisce chi sta effettuando la richiesta; l’autorizzazione decide a quali chat, file, memorie e azioni quell’identità può accedere. Un’isolamento efficace richiede autorizzazione dopo l’autenticazione a ogni confine dei dati, non solo quando l’utente apre l’interfaccia.

Il server dovrebbe derivare un ID utente stabile dalla sessione verificata o dal token di accesso. Non dovrebbe fidarsi di un ID utente inviato in un campo modulo, parametro URL o messaggio di chat. Altrimenti, modificare un valore controllato dal client potrebbe essere sufficiente per richiedere i record di un’altra persona.

Quell'identità derivata dal server diventa quindi parte di ogni ricerca. Query di conversazione, ricerche vettoriali, percorsi di file, chiavi di cache e credenziali degli strumenti necessitano tutti dello stesso ambito utente affidabile. Se un servizio a valle lo perde, il sistema torna silenziosamente a un contesto condiviso anche se il front end mostra ancora account separati.

La memoria durevole necessita di un confine a livello di archiviazione

La memoria a lungo termine di solito risiede in un database relazionale, in un archivio di documenti o in file su disco. Ogni record necessita di un proprietario o identificatore di tenant, e ogni lettura, aggiornamento e cancellazione deve essere limitata a quell'identità. Filtrare solo dopo che una query ampia ha già restituito dati è troppo tardi.

Le politiche del database possono fornire un secondo punto di applicazione sotto il codice dell'applicazione. Quando il database valuta l'utente corrente prima di restituire i record, un filtro mancante in una rotta dell'applicazione ha meno probabilità di diventare una divulgazione tra utenti.

La memoria basata su file richiede la stessa disciplina. Assegna a ogni utente una directory dedicata, mantieni intatti i diritti di proprietà e le regole di controllo accessi, e fai in modo che l'applicazione risolva i percorsi dall'identità autenticata. Un nome di cartella fornito dal browser non è un confine di autorizzazione, e un account di servizio condiviso con accesso illimitato al filesystem può bypassare directory accuratamente organizzate.

Il recupero deve essere definito prima che il prompt venga costruito

RAG crea uno dei punti di isolamento più importanti perché i passaggi recuperati vengono inseriti direttamente nel contesto di lavoro del modello. Una volta che il documento di un altro utente raggiunge il prompt, chiedere al modello di non rivelarlo non è una soluzione affidabile. Il livello di recupero deve escluderlo prima.

Un livello RAG consapevole dei permessi può filtrare i risultati di ricerca in base ai diritti di accesso ai documenti prima che qualsiasi passaggio entri nel prompt. La decisione di autorizzazione deve utilizzare la sessione verificata piuttosto che un'identità fornita nella domanda.

Un database vettoriale può separare i record con uno spazio dei nomi o una raccolta per utente, oppure con filtri obbligatori sui metadati all'interno di un indice condiviso. Spazi dei nomi o raccolte per isolamento rendono più semplice definire l'ambito di scritture, ricerche e cancellazioni, mentre il filtraggio dei metadati può supportare la condivisione controllata quando una famiglia o un team ha documenti comuni.

L'applicazione dovrebbe scegliere lo spazio dei nomi dalla sessione verificata piuttosto che accettarlo dal prompt. La stessa regola si applica quando la ricerca semantica viene eseguita su documenti privati: il filtraggio dell'identità appartiene al percorso della query prima della classificazione per similarità, non in una fase di pulizia dopo il ritorno dei risultati.

Anche i documenti condivisi necessitano di un modello esplicito. Un record può appartenere a un utente, a un gruppo familiare o a un workspace, ma tale ambito dovrebbe essere memorizzato come dato di permesso e valutato in modo coerente. Copiare un documento in diversi indici personali può essere più semplice per un sistema piccolo; i permessi basati su gruppi diventano più facili da gestire man mano che crescono utenti e cartelle condivise.

Sessioni e cache possono riconnettere dati per errore

Un database può essere perfettamente filtrato mentre una cache ancora perde contesto. Se la cronologia chat è memorizzata nella cache solo sotto `conversation_id`, due utenti con una collisione o un identificatore prevedibile possono accedere alla stessa voce. Chiavi più sicure includono sia l'ID utente affidabile che l'ID della conversazione.

Lo stesso confine si applica alle cache dei prompt, alle cache dei blocchi recuperati, alle directory temporanee di upload e agli oggetti di sessione in memoria. Le chiavi cache consapevoli del tenant riducono l'esposizione tra utenti trasportando l'ID utente affidabile sia nelle letture che nelle scritture della cache.

Il logout deve rimuovere o invalidare lo stato corretto. Cancellare un cookie del browser lasciando attiva la sessione lato server, file temporanei o prompt memorizzati nella cache può esporre il contesto dell'utente precedente su un computer condiviso. Scadenza, eliminazione e rimozione dell'account dovrebbero propagarsi in ogni archivio che contiene dati personali.

Le chiamate agli strumenti necessitano dello stesso confine utente

Un assistente può leggere calendari, cercare email, aprire cartelle NAS o attivare automazioni. Questi strumenti possono rivelare più del database della chat, quindi ogni chiamata deve utilizzare i permessi dell'utente richiedente anziché una singola credenziale amministrativa detenuta dal servizio AI.

Per i file locali, lo strumento dovrebbe ereditare o applicare l'accesso al filesystem dell'utente. Per le applicazioni connesse, utilizzare token a livello utente quando l'integrazione li supporta. Un token globale può essere comodo durante i test, ma trasforma l'assistente in un modo per aggirare i permessi che gli utenti si aspettano dal servizio originale.

L’output degli strumenti diventa anch’esso contesto. Memorizzalo sotto lo stesso utente e ambito di sessione della richiesta, evita di inserire segreti nella cronologia chat ordinaria e redigi i campi sensibili dai log. Un livello di recupero sicuro non compensa uno strumento che restituisce direttamente i dati di un altro utente.

Quale schema di isolamento si adatta a un server AI domestico?

Il confine giusto dipende dalla sensibilità, dal numero di utenti e da quanto amministrazione il proprietario del server può mantenere. La tabella confronta i design comuni in base a cosa viene condiviso e dove è più probabile che si verifichino errori.

Per la maggior parte delle abitazioni, regole a livello di riga, recupero vettoriale con ambito utente, percorsi file isolati e permessi degli strumenti specifici per utente offrono un compromesso pratico. I container o macchine separate diventano preziosi quando gli utenti non si fidano l’uno dell’altro, gli strumenti eseguono codice arbitrario o le conseguenze di un errore sono particolarmente gravi.

Perché gli account separati continuano a perdere il contesto

Il primo errore è applicare i permessi solo nell'interfaccia. Nascondere le conversazioni di un altro utente in una barra laterale non serve a nulla se l'API le restituisce quando viene fornito un ID diverso. Ogni endpoint del server deve ripetere la decisione di autorizzazione.

Il secondo errore consiste nel filtrare la cronologia della chat ma non il recupero. L'assistente mostra la conversazione corretta ma cerca in un indice vettoriale condiviso senza un filtro utente. La risposta contiene quindi dettagli privati che non sono mai apparsi nel thread visibile.

Il terzo errore è la condivisione dei dati operativi. Log di debug, tracce, cache dei prompt, upload temporanei e analisi possono contenere lo stesso contesto sensibile della risposta finale. Il contesto di runtime può esporre informazioni sensibili anche quando il modello base non è mai stato addestrato su di esse.

L'ultimo errore è fidarsi del modello come livello di controllo accessi. Un prompt di sistema può descrivere le aspettative di privacy, ma non può annullare in modo affidabile un contesto che non avrebbe mai dovuto essere recuperato. I controlli di sicurezza devono decidere cosa raggiunge il modello; il modello non dovrebbe decidere cosa l'utente era autorizzato a recuperare.

Come testare se l'isolamento degli utenti funziona davvero

Crea due account ordinari con dati di test deliberatamente diversi. Dai a Utente A un documento contenente una frase unica e innocua e a Utente B una frase diversa. Nessuna delle due frasi dovrebbe comparire altrove nel corpus di test.

Da Utente B, prova domande dirette, ricerche semantiche vaghe, ID conversazione ipotizzati, link condivisi, file rinominati e richieste che chiedono all'assistente di ignorare le sue regole. L'obiettivo non è solo testare l'interfaccia normale; è verificare che ogni percorso non restituisca dati al di fuori dell'ambito di Utente B.

Ripeti il test dopo il logout, il riavvio del servizio, il riscaldamento della cache, la reindicizzazione dei documenti, il ripristino del backup e la cancellazione dell'account. Queste transizioni spesso utilizzano percorsi di codice diversi dalla chat ordinaria e possono reintrodurre contesti obsoleti che il percorso principale della query gestisce correttamente.

Rivedi i log del server con le stesse due identità. Ogni recupero, lettura di file, scrittura in memoria e chiamata a strumenti dovrebbe portare l'ambito utente previsto senza registrare inutilmente i contenuti privati dei prompt. Un amministratore dovrebbe essere in grado di spiegare perché ogni elemento del contesto è entrato nel prompt finale.

Un design pratico di isolamento per uso domestico

Inizia mantenendo l'esecuzione del modello e i dati localmente, poi usa un servizio di identità e un ID utente affidabile che il server ricava dalla sessione. Passa quell'identità attraverso il servizio chat, l'archivio di memoria, la ricerca vettoriale, il gateway dei file e il livello degli strumenti. Rifiuta le richieste quando manca l'identità o l'ambito di autorizzazione invece di ricorrere a un valore predefinito condiviso.

Mantieni il modello condiviso a meno che una minaccia specifica non richieda runtime separati. Lo stack circostante di archiviazione, recupero, inferenza, interfaccia e permessi è ciò che trasforma i file locali in un assistente privato basato su dati locali. Duplicare i pesi del modello non ripara una query al database senza ambito.

Usa un identificatore utente o spazio di lavoro sui record duraturi, applica l'accesso alle righe sotto l'applicazione dove possibile e metti i dati vettoriali in namespace con ambito utente o partizioni filtrate obbligatorie. Dai ai file temporanei e alle cache lo stesso ambito, quindi imposta regole di scadenza e cancellazione per ogni livello.

Separa intenzionalmente la conoscenza personale da quella condivisa. Un manuale familiare può appartenere a uno spazio di lavoro comune, mentre i documenti fiscali rimangono privati. In un server AI multi-ruolo, l'appartenenza al gruppo dovrebbe determinare quale spazio di lavoro condiviso si unisce al contesto personale dell'utente per quella richiesta.

Scegli un confine più forte quando la minaccia cambia. Se gli utenti possono eseguire codice, installare plugin, montare cartelle arbitrarie o collegare strumenti potenti, i filtri dell'applicazione da soli potrebbero non essere sufficienti. Contenitori separati, macchine virtuali, credenziali e archiviazione possono limitare ciò a cui un servizio compromesso può accedere.

FAQ

Ogni utente ha bisogno di una copia separata del modello AI?

No. Più utenti possono condividere un modello di inferenza perché il contesto personale può essere assemblato separatamente per ogni richiesta. Processi modello separati possono comunque essere utili per utenti non affidabili, adattatori personalizzati, limiti di risorse rigorosi o carichi di lavoro che richiedono un confine operativo più forte.

Una cronologia chat separata è sufficiente per proteggere il contesto personale?

No. La cronologia della chat è solo una fonte di contesto. Documenti recuperati, indici vettoriali, file caricati, cache, credenziali degli strumenti, registri e dati temporanei devono seguire lo stesso confine di identità. Un livello non vincolato può esporre informazioni anche quando la lista delle conversazioni visibili è corretta.

I membri della famiglia possono condividere intenzionalmente qualche contesto?

Sì. Metti i documenti e i ricordi condivisi in un ambito esplicito di famiglia o spazio di lavoro, quindi concedi l'appartenenza agli utenti che ne hanno bisogno. Mantieni i record personali sotto la proprietà individuale. Il generatore di prompt può combinare l'ambito privato dell'utente corrente con gli ambiti condivisi autorizzati senza aprire nessuno dei due a tutti.

La regola pratica è semplice: condividi il modello, non il percorso del contesto. L'identità deve vincolare i dati prima che vengano letti, recuperati, memorizzati nella cache o passati a uno strumento. Se ogni livello può rispondere a quale utente ha autorizzato un elemento, un server AI domestico può rimanere personale anche mentre la sua capacità di calcolo è condivisa.