Wie hält ein Heim-AI-Server den Kontext jedes Nutzers getrennt?

Ein Heim-AI-Server kann den Kontext jedes Benutzers getrennt halten und gleichzeitig dasselbe Modell teilen, aber die Trennung kommt nicht vom Modell selbst. Sie entsteht dadurch, dass jeder Chat, jede Erinnerung, jedes abgerufene Dokument, jeder Cache-Eintrag und jeder Werkzeugaufruf an einen authentifizierten Benutzer gebunden wird, bevor diese Informationen die Eingabeaufforderung erreichen.

Wenn sich zwei Personen separat anmelden können, aber die Frage eines Benutzers die Notizen einer anderen Person abruft, liegt der Fehler meist in der Anwendung rund um das Modell. Der nützliche Test ist, ob die Identität den gesamten Anfragestrom überlebt. Dieser Artikel folgt diesem Pfad und zeigt, wo Isolation durchgesetzt werden muss, wo sie häufig versagt und wann eine stärkere Grenze gerechtfertigt ist.

Das Modell kann geteilt werden, aber der persönliche Kontext nicht

Modellgewichte sind die gemeinsame logische Engine. Sie benötigen keine separate Kopie für jedes Familienmitglied oder jeden Kollegen, wenn das Modell gewöhnliche Inferenzanfragen bedient. Was getrennt bleiben muss, sind die Informationen, die um diese Gewichte für eine bestimmte Anfrage herum zusammengestellt werden.

Diese Informationen umfassen den aktuellen Chat, gespeicherte Gesprächsverläufe, Benutzereinstellungen, abgerufene Dateipassagen, Vektor-Suchergebnisse, Werkzeugausgaben, temporäre Caches und Anmeldeinformationen. Zusammen bilden diese Schichten den persönlichen Kontext. Ein anderer Benutzer sollte ein anderes Kontextpaket erhalten, selbst wenn beide Anfragen durch denselben Modellprozess laufen.

Diese Unterscheidung hält die Architektur praktikabel. Ein Heimserver kann vermeiden, mehrere identische Modellkopien zu laden, während er dennoch die Daten isoliert, die jeden Assistenten persönlich machen. Die Isolationsgrenze liegt in Identität, Speicherung, Abruf, Sitzungen und Werkzeugzugriff – nicht in einer Eingabeaufforderung, die das Modell lediglich anweist, die Privatsphäre zu respektieren.

Die Identität muss der Anfrage bis zum Ende folgen

Getrennte Anmeldebildschirme sind nur der erste Schritt. Die Authentifizierung stellt fest, wer die Anfrage stellt; die Autorisierung entscheidet, auf welche Chats, Dateien, Erinnerungen und Aktionen diese Identität zugreifen darf. Effektive Isolation erfordert Autorisierung nach der Authentifizierung an jeder Daten-Grenze, nicht nur wenn der Benutzer die Oberfläche öffnet.

Der Server sollte eine stabile Benutzer-ID aus der verifizierten Sitzung oder dem Zugriffstoken ableiten. Er darf einer in einem Formularfeld, URL-Parameter oder Chatnachricht gesendeten Benutzer-ID nicht vertrauen. Andernfalls kann das Ändern eines vom Client kontrollierten Werts ausreichen, um die Daten einer anderen Person anzufordern.

Diese serverseitig abgeleitete Identität wird dann Teil jeder Abfrage. Gesprächsanfragen, Vektorsuchen, Dateipfade, Cache-Schlüssel und Tool-Zugangsdaten benötigen alle denselben vertrauenswürdigen Benutzerbereich. Wenn ein nachgelagerter Dienst diese verliert, kehrt das System stillschweigend zum gemeinsamen Kontext zurück, obwohl die Benutzeroberfläche weiterhin separate Konten anzeigt.

Dauerhafter Speicher benötigt eine Speicher-Ebene-Grenze.

Langzeitspeicher befindet sich üblicherweise in einer relationalen Datenbank, einem Dokumentenspeicher oder als Dateien auf der Festplatte. Jeder Datensatz benötigt einen Eigentümer- oder Mandantenbezeichner, und jedes Lesen, Aktualisieren und Löschen muss auf diese Identität beschränkt sein. Eine Filterung erst nach einer breit angelegten Abfrage, die bereits Daten zurückgegeben hat, ist zu spät.

Datenbankrichtlinien können einen zweiten Durchsetzungspunkt unterhalb des Anwendungscodes bieten. Wenn die Datenbank den aktuellen Benutzer vor der Rückgabe von Datensätzen überprüft, ist die Wahrscheinlichkeit geringer, dass ein fehlender Filter in einer Anwendungsroute zu einer Offenlegung zwischen Benutzern führt.

Dateibasierter Speicher benötigt dieselbe Disziplin. Geben Sie jedem Benutzer ein eigenes Verzeichnis, bewahren Sie Besitz- und Zugriffsregeln und lassen Sie die Anwendung Pfade anhand der authentifizierten Identität auflösen. Ein vom Browser bereitgestellter Ordnername ist keine Autorisierungsgrenze, und ein gemeinsames Servicekonto mit uneingeschränktem Dateisystemzugriff kann sorgfältig eingerichtete Verzeichnisse umgehen.

Der Abruf muss eingegrenzt werden, bevor der Prompt erstellt wird.

RAG schafft einen der wichtigsten Isolationspunkte, da abgerufene Abschnitte direkt in den Arbeitskontext des Modells eingefügt werden. Sobald ein Dokument eines anderen Benutzers im Prompt erscheint, ist es keine verlässliche Lösung, das Modell zu bitten, es nicht zu offenbaren. Die Abrufschicht muss es zuerst ausschließen.

Eine berechtigungsbewusste RAG-Schicht kann Suchergebnisse nach Dokumentenzugriffsrechten filtern, bevor ein Abschnitt in den Prompt eingefügt wird. Die Autorisierungsentscheidung muss die verifizierte Sitzung verwenden und darf sich nicht auf eine im Fragekontext angegebene Identität stützen.

Eine Vektordatenbank kann Datensätze mit einem Namespace oder einer Sammlung pro Benutzer trennen oder mit obligatorischen Metadatenfiltern innerhalb eines gemeinsamen Index. Namespaces oder Sammlungen zur Isolation erleichtern das Eingrenzen von Schreibvorgängen, Suchanfragen und Löschungen, während Metadatenfilter eine kontrollierte Freigabe unterstützen können, wenn ein Haushalt oder Team gemeinsame Dokumente hat.

Die Anwendung sollte den Namensraum aus der verifizierten Sitzung wählen, anstatt ihn aus der Eingabeaufforderung zu übernehmen. Dieselbe Regel gilt, wenn semantische Suche über private Dokumente läuft: Identitätsfilterung gehört in den Abfragepfad vor der Ähnlichkeitsbewertung, nicht in einen Bereinigungsschritt nach der Ergebnisrückgabe.

Geteilte Dokumente benötigen ebenfalls ein explizites Modell. Ein Datensatz kann einem Benutzer, einer Haushaltsgruppe oder einem Arbeitsbereich gehören, aber dieser Umfang sollte als Berechtigungsdaten gespeichert und konsequent ausgewertet werden. Das Kopieren eines Dokuments in mehrere persönliche Indizes kann für ein kleines System einfacher sein; gruppenbasierte Berechtigungen werden leichter zu verwalten, wenn Benutzer und geteilte Ordner wachsen.

Sitzungen und Caches können versehentlich Daten verbinden

Eine Datenbank kann perfekt gefiltert sein, während ein Cache weiterhin Kontext preisgibt. Wenn der Chatverlauf nur unter `conversation_id` zwischengespeichert wird, können zwei Benutzer mit einer Kollision oder vorhersehbaren Kennung denselben Eintrag erreichen. Sicherere Schlüssel enthalten sowohl die vertrauenswürdige Benutzer-ID als auch die Gesprächs-ID.

Die gleiche Grenze gilt für Eingabeaufforderungs-Caches, zwischengespeicherte Datenabschnitte, temporäre Upload-Verzeichnisse und im Speicher gehaltene Sitzungsobjekte. Mandantenbewusste Cache-Schlüssel verringern die Benutzerübergreifende Offenlegung, indem sie die vertrauenswürdige Benutzer-ID sowohl bei Cache-Lese- als auch bei Schreibvorgängen mitführen.

Das Abmelden muss den richtigen Zustand entfernen oder ungültig machen. Das Löschen eines Browser-Cookies bei gleichzeitigem Verbleib der serverseitigen Sitzung, temporärer Dateien oder zwischengespeicherter Eingabeaufforderungen kann auf einem gemeinsam genutzten Computer den Kontext des vorherigen Benutzers offenlegen. Ablauf, Löschung und Kontenentfernung sollten sich auf jeden Speicher auswirken, der persönliche Daten enthält.

Tool-Aufrufe benötigen dieselbe Benutzergrenze

Ein Assistent kann Kalender lesen, E-Mails durchsuchen, NAS-Ordner öffnen oder Automatisierungen auslösen. Diese Tools können mehr offenbaren als die Chat-Datenbank, daher muss jeder Aufruf die Berechtigungen des anfragenden Benutzers verwenden und nicht nur eine einzelne Administratoranmeldeinformation, die vom KI-Dienst gehalten wird.

Für lokale Dateien sollte das Tool die Dateisystemzugriffsrechte des Benutzers übernehmen oder durchsetzen. Für verbundene Anwendungen verwenden Sie benutzerspezifische Tokens, sofern die Integration diese unterstützt. Ein globales Token mag während der Testphase praktisch sein, verwandelt den Assistenten jedoch in eine Umgehung der Berechtigungen, die Benutzer vom ursprünglichen Dienst erwarten.

Tool-Ausgaben werden ebenfalls zum Kontext. Speichere sie unter derselben Benutzer- und Sitzungsebene wie die Anfrage, vermeide es, Geheimnisse im normalen Chatverlauf abzulegen, und schwärze sensible Felder in Protokollen. Eine sichere Abfrageschicht kompensiert nicht ein Tool, das direkt Daten eines anderen Benutzers zurückgibt.

Welches Isolationsmuster passt zu einem Heim-KI-Server?

Die richtige Grenze hängt von Sensibilität, Anzahl der Benutzer und dem Verwaltungsaufwand des Serverbesitzers ab. Die Tabelle vergleicht gängige Designs danach, was geteilt wird und wo Fehler am wahrscheinlichsten sind.

Für die meisten Haushalte bieten zeilenbasierte Regeln, benutzerspezifische Vektorabfragen, isolierte Dateipfade und benutzerspezifische Tool-Berechtigungen einen praktischen Mittelweg. Container oder separate Maschinen werden wertvoll, wenn Benutzer einander nicht vertrauen, Tools beliebigen Code ausführen oder die Folgen eines Fehlers ungewöhnlich hoch sind.

Warum separate Konten dennoch Kontext preisgeben

Das erste Versagen besteht darin, Berechtigungen nur in der Benutzeroberfläche anzuwenden. Das Ausblenden der Unterhaltungen eines anderen Benutzers in einer Seitenleiste nützt nichts, wenn die API sie bei einer anderen ID zurückgibt. Jeder Server-Endpunkt muss die Autorisierungsentscheidung wiederholen.

Das zweite Versagen besteht darin, den Chatverlauf zu filtern, aber nicht die Abfrage. Der Assistent zeigt die korrekte Unterhaltung an, durchsucht jedoch einen gemeinsamen Vektorindex ohne Benutzerfilter. Die Antwort enthält dann private Details, die im sichtbaren Thread nie erschienen sind.

Das dritte Versagen sind gemeinsam genutzte Betriebsdaten. Debug-Protokolle, Traces, Prompt-Caches, temporäre Uploads und Analysen können denselben sensiblen Kontext wie die endgültige Antwort enthalten. Laufzeitkontext kann sensible Informationen offenlegen, selbst wenn das Basismodell nie darauf trainiert wurde.

Das letzte Versagen ist, das Modell als Zugriffskontrollschicht zu vertrauen. Ein Systemprompt kann Datenschutzanforderungen beschreiben, aber er kann Kontext, der niemals abgerufen werden sollte, nicht zuverlässig rückgängig machen. Sicherheitskontrollen müssen entscheiden, was das Modell erreicht; das Modell sollte nicht entscheiden, was der Benutzer abrufen durfte.

Wie man testet, ob die Benutzerisolation wirklich funktioniert

Erstellen Sie zwei gewöhnliche Konten mit absichtlich unterschiedlichen Testdaten. Geben Sie Benutzer A ein Dokument mit einem einzigartigen harmlosen Ausdruck und Benutzer B einen anderen Ausdruck. Keiner der Ausdrücke sollte irgendwo sonst im Testkorpus vorkommen.

Versuchen Sie von Benutzer B aus direkte Fragen, vage semantische Suchen, vermutete Gesprächs-IDs, geteilte Links, umbenannte Dateien und Anfragen, die den Assistenten auffordern, seine Regeln zu ignorieren. Das Ziel ist nicht nur, die normale Schnittstelle zu testen, sondern zu überprüfen, dass jeder Pfad keine Daten außerhalb des Bereichs von Benutzer B zurückgibt.

Wiederholen Sie den Test nach Abmeldung, Neustart des Dienstes, Cache-Warmup, Neuindizierung von Dokumenten, Wiederherstellung von Backups und Löschung von Konten. Diese Übergänge verwenden oft andere Codepfade als der normale Chat und können veralteten Kontext wieder einführen, den der primäre Abfragepfad korrekt handhabt.

Überprüfen Sie Serverprotokolle mit denselben zwei Identitäten. Jeder Abruf, jede Dateilesung, jeder Speicherzugriff und jeder Werkzeugaufruf sollte den erwarteten Benutzerumfang tragen, ohne private Eingabeaufforderungen unnötig aufzuzeichnen. Ein Administrator sollte erklären können, warum jeder Kontextpunkt in die endgültige Eingabeaufforderung gelangt ist.

Ein praktisches Isolationsdesign für den Heimgebrauch

Beginnen Sie damit, die Modellausführung und Daten lokal zu halten, verwenden Sie dann einen Identitätsdienst und eine vertrauenswürdige Benutzer-ID, die der Server aus der Sitzung ableitet. Übergeben Sie diese Identität durch den Chat-Dienst, den Speicher für Erinnerungen, die Vektorsuche, das Dateitor und die Werkzeugebene. Lehnen Sie Anfragen ab, wenn die Identität oder der Berechtigungsumfang fehlt, anstatt auf einen gemeinsamen Standard zurückzugreifen.

Halte das Modell geteilt, es sei denn, eine spezifische Bedrohung erfordert separate Laufzeiten. Der umgebende Stack aus Speicher, Abruf, Inferenz, Schnittstelle und Berechtigungen verwandelt lokale Dateien in einen privaten Assistenten, der auf lokalen Daten basiert. Das Duplizieren von Modellgewichten behebt keine unbeschränkte Datenbankabfrage.

Verwende einen Benutzer- oder Arbeitsbereichsbezeichner auf dauerhaften Datensätzen, setze Zeilenzugriff möglichst unterhalb der Anwendung durch und lege Vektordaten in benutzerspezifischen Namensräumen oder verpflichtend gefilterten Partitionen ab. Gib temporären Dateien und Caches denselben Bereich und setze Ablauf- und Löschregeln für jede Ebene fest.

Trenne persönliches und geteiltes Wissen bewusst. Ein Haushalts-Handbuch kann zu einem gemeinsamen Arbeitsbereich gehören, während Steuerunterlagen privat bleiben. In einem AI-Server mit mehreren Rollen sollte die Gruppenmitgliedschaft bestimmen, welcher geteilte Arbeitsbereich den persönlichen Kontext des Benutzers für diese Anfrage ergänzt.

Wähle eine stärkere Grenze, wenn sich die Bedrohung ändert. Wenn Benutzer Code ausführen, Plugins installieren, beliebige Ordner einbinden oder leistungsstarke Tools verbinden können, reichen Anwendungsfilter allein möglicherweise nicht aus. Separate Container, virtuelle Maschinen, Zugangsdaten und Speicher können einschränken, was ein kompromittierter Dienst erreichen kann.

FAQ

Benötigt jeder Benutzer eine separate Kopie des KI-Modells?

Nein. Mehrere Benutzer können ein Inferenzmodell teilen, weil persönlicher Kontext für jede Anfrage separat zusammengestellt werden kann. Separate Modellprozesse können dennoch nützlich sein für nicht vertrauenswürdige Benutzer, benutzerdefinierte Adapter, strenge Ressourcenbeschränkungen oder Arbeitslasten, die eine stärkere operative Grenze erfordern.

Reicht ein separater Chatverlauf aus, um den persönlichen Kontext zu schützen?

Nein. Der Chatverlauf ist nur eine Quelle des Kontexts. Abgerufene Dokumente, Vektorindizes, hochgeladene Dateien, Caches, Tool-Zugangsdaten, Protokolle und temporäre Daten müssen dieselbe Identitätsgrenze einhalten. Eine unbeschränkte Ebene kann Informationen preisgeben, selbst wenn die sichtbare Gesprächsliste korrekt ist.

Können Familienmitglieder absichtlich einige Kontexte teilen?

Ja. Lege geteilte Dokumente und Erinnerungen in einem expliziten Haushalts- oder Arbeitsbereich fest und gewähre dann den Benutzern, die sie benötigen, die Mitgliedschaft. Persönliche Aufzeichnungen bleiben im individuellen Besitz. Der Prompt-Builder kann den privaten Bereich des aktuellen Benutzers mit autorisierten geteilten Bereichen kombinieren, ohne dass einer von beiden für alle geöffnet wird.

Die praktische Regel ist einfach: Teile das Modell, nicht den Kontextpfad. Die Identität muss die Daten einschränken, bevor sie gelesen, abgerufen, zwischengespeichert oder an ein Tool weitergegeben werden. Wenn jede Ebene beantworten kann, welcher Benutzer einen Eintrag autorisiert hat, kann ein Heim-AI-Server persönlich bleiben, auch wenn seine Rechenleistung geteilt wird.