Hoe houdt een thuis-AI-server de context van elke gebruiker gescheiden?

Een thuis-AI-server kan de context van elke gebruiker gescheiden houden terwijl hetzelfde model wordt gedeeld, maar die scheiding komt niet van het model zelf. Het komt doordat elke chat, herinneringsrecord, opgehaald document, cache-item en tool-aanroep wordt gekoppeld aan een geverifieerde gebruiker voordat die informatie de prompt bereikt.

Als twee mensen zich apart kunnen aanmelden maar de vraag van de ene gebruiker de notities van een ander ophaalt, ligt de fout meestal in de applicatie rond het model. De nuttige test is of de identiteit het hele verzoekpad overleeft. Dit artikel volgt dat pad en laat zien waar isolatie moet worden afgedwongen, waar het vaak faalt en wanneer een sterkere grens gerechtvaardigd is.

Het Model Kan Gedeeld Worden, maar Persoonlijke Context Niet

Modelgewichten zijn de gemeenschappelijke redeneermotor. Ze hoeven niet voor elk gezinslid of collega een aparte kopie te hebben wanneer het model gewone inferentieaanvragen verwerkt. Wat gescheiden moet blijven, is de informatie die rond die gewichten wordt verzameld voor een specifiek verzoek.

Die informatie omvat de huidige chat, opgeslagen gespreksgeschiedenis, gebruikersvoorkeuren, opgehaalde bestandsfragmenten, vector-zoekresultaten, tool-uitvoer, tijdelijke caches en referenties. Samen vormen deze lagen de persoonlijke context. Een andere gebruiker moet een ander contextpakket ontvangen, zelfs als beide verzoeken via hetzelfde modelproces lopen.

Dit onderscheid houdt de architectuur praktisch. Een thuisserver kan voorkomen dat meerdere identieke modelkopieën worden geladen terwijl toch de gegevens die elke assistent persoonlijk maken geïsoleerd blijven. De isolatiegrens hoort bij identiteit, opslag, ophalen, sessies en toegang tot tools te liggen — niet in een prompt die het model alleen vertelt privacy te respecteren.

Identiteit Moet Het Verzoek Helemaal Volgen

Gescheiden inlogschermen zijn slechts de eerste stap. Authenticatie bepaalt wie het verzoek doet; autorisatie beslist tot welke chats, bestanden, herinneringen en acties die identiteit toegang heeft. Effectieve isolatie vereist autorisatie na authenticatie bij elke gegevensgrens, niet alleen wanneer de gebruiker de interface opent.

De server moet een stabiele gebruikers-ID afleiden van de geverifieerde sessie of toegangstoken. Hij mag geen gebruikers-ID vertrouwen die wordt verzonden in een formulierveld, URL-parameter of chatbericht. Anders kan het wijzigen van één door de cliënt gecontroleerde waarde al genoeg zijn om de gegevens van iemand anders op te vragen.

Die serverafgeleide identiteit wordt dan onderdeel van elke opvraging. Gespreksquery’s, vectorzoekopdrachten, bestands-paden, cache-sleutels en toolreferenties hebben allemaal dezelfde vertrouwde gebruikersscope nodig. Als één downstreamservice die verliest, keert het systeem stilzwijgend terug naar gedeelde context, ook al toont de frontend nog steeds aparte accounts.

Duurzaam geheugen heeft een opslagniveau-grens nodig

Langetermijngeheugen bevindt zich meestal in een relationele database, documentopslag of bestanden op schijf. Elk record heeft een eigenaar of huurder-ID nodig, en elke lees-, update- en verwijderbewerking moet beperkt zijn tot die identiteit. Filteren pas na een brede query die al data heeft teruggegeven is te laat.

Databasebeleid kan een tweede handhavingspunt bieden onder de applicatiecode. Wanneer de database de huidige gebruiker evalueert voordat records worden geretourneerd, is de kans kleiner dat een gemiste filter in één applicatieroute leidt tot gegevenslekken tussen gebruikers.

Bestandsgebaseerd geheugen vereist dezelfde discipline. Geef elke gebruiker een toegewijde map, houd eigendom en toegangscontroleregels intact, en laat de applicatie paden oplossen vanuit de geverifieerde identiteit. Een mapnaam die door de browser wordt geleverd, is geen autorisatiegrens, en een gedeeld serviceaccount met onbeperkte toegang tot het bestandssysteem kan zorgvuldig ingerichte mappen omzeilen.

Ophalen moet worden afgebakend voordat de prompt wordt opgebouwd

RAG creëert een van de belangrijkste isolatiepunten omdat opgehaalde passages direct in de werkcontext van het model worden ingevoegd. Zodra het document van een andere gebruiker de prompt bereikt, is het vragen aan het model om het niet te onthullen geen betrouwbare oplossing. De ophaallaag moet het eerst uitsluiten.

Een permissie-bewuste RAG-laag kan zoekresultaten filteren op basis van documenttoegangsrechten voordat een passage in de prompt wordt opgenomen. De autorisatiebeslissing moet gebruikmaken van de geverifieerde sessie in plaats van een identiteit die in de vraag wordt opgegeven.

Een vector database kan records scheiden met één namespace of collectie per gebruiker, of met verplichte metadatafilters binnen een gedeelde index. Namespaces of collecties voor isolatie maken schrijven, zoeken en verwijderen gemakkelijker af te bakenen, terwijl metadatafiltering gecontroleerd delen kan ondersteunen wanneer een huishouden of team gemeenschappelijke documenten heeft.

De applicatie moet de namespace kiezen op basis van de geverifieerde sessie in plaats van deze van de prompt te accepteren. Dezelfde regel geldt wanneer semantisch zoeken wordt uitgevoerd over privédocumenten: identiteitsfiltering hoort in het querypad vóór de gelijkenisrangschikking, niet in een opruimstap nadat resultaten zijn teruggekeerd.

Gedeelde documenten hebben ook een expliciet model nodig. Een record kan toebehoren aan één gebruiker, een huishoudgroep of een werkruimte, maar die scope moet als permissiegegevens worden opgeslagen en consistent worden geëvalueerd. Het kopiëren van een document naar meerdere persoonlijke indexen kan eenvoudiger zijn voor een klein systeem; groepsgebaseerde permissies worden makkelijker te onderhouden naarmate gebruikers en gedeelde mappen groeien.

Sessies en caches kunnen per ongeluk data opnieuw verbinden

Een database kan perfect gefilterd zijn terwijl een cache nog steeds context lekt. Als chatgeschiedenis alleen wordt gecachet onder `conversation_id`, kunnen twee gebruikers met een botsing of voorspelbare identifier dezelfde invoer bereiken. Veiliger sleutels bevatten zowel de vertrouwde gebruikers-ID als de conversatie-ID.

Dezelfde grens geldt voor promptcaches, opgehaalde chunk-caches, tijdelijke uploadmappen en sessieobjecten in het geheugen. Tenant-bewuste cache-sleutels verminderen blootstelling tussen gebruikers door de vertrouwde gebruikers-ID mee te nemen bij zowel cache-lees- als schrijfoperaties.

Uitloggen moet de juiste status verwijderen of ongeldig maken. Het wissen van een browsercookie terwijl de server-side sessie, tijdelijke bestanden of gecachte prompts beschikbaar blijven, kan de context van de vorige gebruiker op een gedeelde computer blootstellen. Verloop, verwijdering en accountverwijdering moeten zich door elke opslag verspreiden die persoonlijke gegevens bevat.

Tool-oproepen hebben dezelfde gebruikersgrens nodig

Een assistent kan agenda's lezen, e-mails doorzoeken, NAS-mappen openen of automatiseringen activeren. Deze tools kunnen meer onthullen dan de chatdatabase, dus elke oproep moet de permissies van de aanvragende gebruiker gebruiken in plaats van een enkele beheerdersreferentie die door de AI-dienst wordt gehouden.

Voor lokale bestanden moet de tool de bestandsysteemtoegang van de gebruiker overnemen of afdwingen. Voor verbonden applicaties worden tokens op gebruikersniveau gebruikt waar de integratie dit ondersteunt. Een globaal token kan handig zijn tijdens het testen, maar verandert de assistent in een omweg rond de permissies die gebruikers van de oorspronkelijke dienst verwachten.

Tooloutput wordt ook context. Sla deze op onder dezelfde gebruiker en sessie als het verzoek, vermijd het plaatsen van geheimen in gewone chatgeschiedenis en redacteer gevoelige velden uit logs. Een veilige zoeklaag compenseert niet voor een tool die direct data van een andere gebruiker teruggeeft.

Welk isolatiepatroon past bij een thuis-AI-server?

De juiste grens hangt af van gevoeligheid, aantal gebruikers en hoeveel beheer de servereigenaar kan onderhouden. De tabel vergelijkt gangbare ontwerpen op basis van wat gedeeld wordt en waar fouten het meest waarschijnlijk zijn.

Voor de meeste huishoudens bieden regels op rijniveau, gebruikersgerichte vectoropvraging, geïsoleerde bestandsroutes en gebruikersspecifieke toolpermissies een praktisch middenweg. Containers of aparte machines worden waardevol wanneer gebruikers elkaar niet vertrouwen, tools willekeurige code uitvoeren of de gevolgen van een fout uitzonderlijk groot zijn.

Waarom aparte accounts toch context lekken

De eerste fout is het toepassen van permissies alleen in de interface. Het verbergen van de gesprekken van een andere gebruiker in een zijbalk heeft geen effect als de API ze teruggeeft bij een ander ID. Elke serverendpoint moet de autorisatiebeslissing herhalen.

De tweede fout is het filteren van de chatgeschiedenis maar niet van de zoekopdracht. De assistent toont het juiste gesprek, maar zoekt in een gedeelde vectorindex zonder gebruikersfilter. Het antwoord bevat dan privégegevens die nooit in de zichtbare thread zijn verschenen.

De derde fout is gedeelde operationele data. Debuglogs, sporen, promptcaches, tijdelijke uploads en analyses kunnen dezelfde gevoelige context bevatten als het uiteindelijke antwoord. Runtime-context kan gevoelige informatie blootleggen zelfs wanneer het basismodel er nooit op getraind is.

De laatste fout is het vertrouwen op het model als toegangscontrollayer. Een systeemprompt kan privacyverwachtingen beschrijven, maar kan context die nooit had mogen worden opgehaald niet betrouwbaar ongedaan maken. Beveiligingscontroles moeten beslissen wat het model bereikt; het model mag niet bepalen wat de gebruiker mocht ophalen.

Hoe te testen of gebruikersisolatie echt werkt

Maak twee gewone accounts aan met opzettelijk verschillende testgegevens. Geef Gebruiker A een document met een unieke onschuldige zin en geef Gebruiker B een andere zin. Geen van beide zinnen mag ergens anders in de testcorpus voorkomen.

Probeer vanaf Gebruiker B directe vragen, vage semantische zoekopdrachten, geraden gesprek-ID’s, gedeelde links, hernoemde bestanden en verzoeken waarbij de assistent wordt gevraagd zijn regels te negeren. Het doel is niet alleen de normale interface te testen; het is te verifiëren dat elke route geen data buiten de scope van Gebruiker B retourneert.

Herhaal de test na uitloggen, herstart van de dienst, cache-warming, herindexering van documenten, herstel van back-ups en verwijdering van accounts. Deze overgangen gebruiken vaak andere codepaden dan gewone chat en kunnen verouderde context opnieuw introduceren die het primaire querypad correct afhandelt.

Bekijk serverlogs met dezelfde twee identiteiten. Elke opvraging, bestandslezing, geheugenbewerking en toolaanroep moet de verwachte gebruikersscope dragen zonder onnodig privé promptinhoud vast te leggen. Een beheerder moet kunnen uitleggen waarom elk contextitem in de uiteindelijke prompt is opgenomen.

Een praktische isolatieontwerp voor thuisgebruik

Begin met het lokaal houden van modeluitvoering en data, gebruik vervolgens één identiteitsdienst en één vertrouwde gebruikers-ID die de server uit de sessie afleidt. Geef die identiteit door via de chatdienst, geheugenopslag, vectorzoekfunctie, bestandsgateway en toollaag. Weiger verzoeken wanneer de identiteit of permissies ontbreken in plaats van terug te vallen op een gedeelde standaard.

Houd het model gedeeld tenzij een specifieke dreiging aparte runtimes vereist. De omliggende stack van opslag, ophalen, inferentie, interface en permissies is wat lokale bestanden verandert in een persoonlijke assistent die is gebaseerd op lokale gegevens. Het dupliceren van modelgewichten repareert geen ongescopeerde databasequery.

Gebruik een gebruikers- of werkruimte-ID op duurzame records, handhaaf rijniveau-toegang onder de applicatie waar mogelijk en plaats vectordata in gebruikersgescopeerde namenruimten of verplichte gefilterde partities. Geef tijdelijke bestanden en caches dezelfde scope en stel verval- en verwijderregels in voor elke laag.

Houd persoonlijke en gedeelde kennis bewust gescheiden. Een huishoudhandleiding kan bij een gemeenschappelijke werkruimte horen, terwijl belastinggegevens privé blijven. In een AI-server met meerdere rollen moet groepslidmaatschap bepalen welke gedeelde werkruimte wordt toegevoegd aan de persoonlijke context van de gebruiker voor dat verzoek.

Kies een sterkere grens wanneer de dreiging verandert. Als gebruikers code kunnen uitvoeren, plugins kunnen installeren, willekeurige mappen kunnen koppelen of krachtige tools kunnen verbinden, zijn applicatiefilters alleen mogelijk niet voldoende. Aparte containers, virtuele machines, referenties en opslag kunnen beperken wat een gecompromitteerde service kan bereiken.

FAQ

Heeft elke gebruiker een aparte kopie van het AI-model nodig?

Nee. Meerdere gebruikers kunnen één inferentiemodel delen omdat persoonlijke context voor elk verzoek afzonderlijk kan worden samengesteld. Aparte modelprocessen kunnen nog steeds nuttig zijn voor niet-vertrouwde gebruikers, aangepaste adapters, strikte resourcebeperkingen of workloads die een sterkere operationele grens vereisen.

Is een aparte chatgeschiedenis voldoende om persoonlijke context te beschermen?

Nee. Chatgeschiedenis is slechts één bron van context. Opgehaalde documenten, vectorindexen, geüploade bestanden, caches, toolreferenties, logs en tijdelijke gegevens moeten dezelfde identiteitsgrens volgen. Eén ongescopeerde laag kan informatie blootgeven, zelfs als de zichtbare gesprekslijst correct is.

Kunnen gezinsleden opzettelijk wat context delen?

Ja. Plaats gedeelde documenten en herinneringen in een expliciete huishoud- of werkruimtescope en geef vervolgens lidmaatschap aan de gebruikers die het nodig hebben. Houd persoonlijke gegevens onder individueel eigendom. De promptbouwer kan de privé-scope van de huidige gebruiker combineren met geautoriseerde gedeelde scopes zonder dat een van beide voor iedereen toegankelijk wordt.

De praktische regel is eenvoudig: deel het model, niet het contextpad. Identiteit moet gegevens beperken voordat ze worden gelezen, opgehaald, gecached of doorgegeven aan een tool. Als elke laag kan aangeven welke gebruiker een item heeft geautoriseerd, kan een thuis-AI-server persoonlijk blijven, zelfs als de rekenkracht wordt gedeeld.