¿Cómo mantiene un servidor de IA doméstico el contexto de cada usuario separado?

Un servidor de IA doméstico puede mantener el contexto de cada usuario separado mientras comparte el mismo modelo, pero la separación no proviene del modelo en sí. Proviene de vincular cada chat, registro de memoria, documento recuperado, entrada de caché y llamada a herramienta a un usuario autenticado antes de que esa información llegue al prompt.

Si dos personas pueden iniciar sesión por separado pero la pregunta de un usuario recupera las notas de otra persona, la falla suele estar en la aplicación alrededor del modelo. La prueba útil es si la identidad sobrevive a todo el camino de la solicitud. Este artículo sigue ese camino y muestra dónde debe aplicarse el aislamiento, dónde suele fallar y cuándo se justifica un límite más fuerte.

El modelo puede ser compartido, pero el contexto personal no

Los pesos del modelo son el motor común de razonamiento. No necesitan una copia separada para cada miembro de la familia o compañero de trabajo cuando el modelo está sirviendo solicitudes ordinarias de inferencia. Lo que debe permanecer separado es la información ensamblada alrededor de esos pesos para una solicitud particular.

Esa información incluye el chat actual, el historial de conversaciones guardadas, las preferencias del usuario, los pasajes de archivos recuperados, los resultados de búsqueda vectorial, las salidas de herramientas, las cachés temporales y las credenciales. Juntas, estas capas forman el contexto personal. Un usuario diferente debe recibir un paquete de contexto diferente incluso cuando ambas solicitudes se ejecutan en el mismo proceso del modelo.

Esta distinción mantiene la arquitectura práctica. Un servidor doméstico puede evitar cargar varias copias idénticas del modelo mientras aísla los datos que hacen personal a cada asistente. El límite de aislamiento pertenece a la identidad, almacenamiento, recuperación, sesiones y acceso a herramientas, no a un prompt que simplemente indica al modelo respetar la privacidad.

La identidad debe seguir la solicitud hasta el final

Las pantallas de inicio de sesión separadas son solo el primer paso. La autenticación establece quién realiza la solicitud; la autorización decide a qué chats, archivos, memorias y acciones puede acceder esa identidad. El aislamiento efectivo requiere autorización después de la autenticación en cada límite de datos, no solo cuando el usuario abre la interfaz.

El servidor debe derivar un ID de usuario estable a partir de la sesión verificada o el token de acceso. No debe confiar en un ID de usuario enviado en un campo de formulario, parámetro de URL o mensaje de chat. De lo contrario, cambiar un valor controlado por el cliente podría ser suficiente para solicitar los registros de otra persona.

Esa identidad derivada del servidor luego se convierte en parte de cada búsqueda. Las consultas de conversación, búsquedas vectoriales, rutas de archivos, claves de caché y credenciales de herramientas necesitan el mismo ámbito de usuario confiable. Si un servicio descendente lo pierde, el sistema vuelve silenciosamente a un contexto compartido aunque el front-end aún muestre cuentas separadas.

La memoria duradera necesita un límite a nivel de almacenamiento

La memoria a largo plazo generalmente reside en una base de datos relacional, almacén de documentos o archivos en disco. Cada registro necesita un identificador de propietario o inquilino, y cada lectura, actualización y eliminación debe estar restringida a esa identidad. Filtrar solo después de que una consulta amplia ya haya devuelto datos es demasiado tarde.

Las políticas de base de datos pueden proporcionar un segundo punto de aplicación debajo del código de la aplicación. Cuando la base de datos evalúa al usuario actual antes de devolver registros, una omisión de filtro en una ruta de la aplicación tiene menos probabilidades de convertirse en una divulgación entre usuarios.

La memoria basada en archivos necesita la misma disciplina. Asigne a cada usuario un directorio dedicado, mantenga intactas las reglas de propiedad y control de acceso, y haga que la aplicación resuelva las rutas desde la identidad autenticada. Un nombre de carpeta proporcionado por el navegador no es un límite de autorización, y una cuenta de servicio compartida con acceso irrestricto al sistema de archivos puede eludir directorios cuidadosamente organizados.

La recuperación debe delimitarse antes de construir el prompt

RAG crea uno de los puntos de aislamiento más importantes porque los pasajes recuperados se insertan directamente en el contexto de trabajo del modelo. Una vez que el documento de otro usuario llega al prompt, pedir al modelo que no lo revele no es una solución confiable. La capa de recuperación debe excluirlo primero.

Una capa RAG consciente de permisos puede filtrar los resultados de búsqueda según los derechos de acceso a documentos antes de que cualquier pasaje entre en el prompt. La decisión de autorización debe usar la sesión verificada en lugar de una identidad proporcionada en la pregunta.

Una base de datos vectorial puede separar registros con un espacio de nombres o colección por usuario, o con filtros de metadatos obligatorios dentro de un índice compartido. Los espacios de nombres o colecciones para aislamiento facilitan delimitar escrituras, búsquedas y eliminaciones, mientras que el filtrado por metadatos puede apoyar el uso compartido controlado cuando un hogar o equipo tiene documentos comunes.

La aplicación debe elegir el espacio de nombres desde la sesión verificada en lugar de aceptarlo desde el prompt. La misma regla se aplica cuando la búsqueda semántica se ejecuta sobre documentos privados: el filtrado de identidad pertenece en la ruta de consulta antes de la clasificación por similitud, no en un paso de limpieza después de que se devuelven los resultados.

Los documentos compartidos también necesitan un modelo explícito. Un registro puede pertenecer a un usuario, a un grupo familiar o a un espacio de trabajo, pero ese alcance debe almacenarse como datos de permiso y evaluarse de forma consistente. Copiar un documento en varios índices personales puede ser más simple para un sistema pequeño; los permisos basados en grupos se vuelven más fáciles de mantener a medida que crecen los usuarios y las carpetas compartidas.

Las sesiones y cachés pueden reconectar datos por accidente.

Una base de datos puede estar perfectamente filtrada mientras una caché aún filtra contexto. Si el historial de chat se almacena en caché solo bajo `conversation_id`, dos usuarios con una colisión o un identificador predecible pueden acceder a la misma entrada. Claves más seguras incluyen tanto el ID de usuario confiable como el ID de conversación.

El mismo límite se aplica a las cachés de prompts, cachés de fragmentos recuperados, directorios temporales de carga y objetos de sesión en memoria. Las claves de caché conscientes del inquilino reducen la exposición entre usuarios al llevar el ID de usuario confiable tanto en las lecturas como en las escrituras de caché.

Cerrar sesión debe eliminar o invalidar el estado correcto. Borrar una cookie del navegador mientras se mantiene la sesión del lado del servidor, archivos temporales o el prompt en caché puede exponer el contexto del usuario anterior en un equipo compartido. La expiración, eliminación y eliminación de cuentas deben propagarse a todas las tiendas que contengan datos personales.

Las llamadas a herramientas necesitan el mismo límite de usuario.

Un asistente puede leer calendarios, buscar correos electrónicos, abrir carpetas NAS o activar automatizaciones. Esas herramientas pueden revelar más que la base de datos del chat, por lo que cada llamada debe usar los permisos del usuario solicitante en lugar de una única credencial de administrador que posea el servicio de IA.

Para archivos locales, la herramienta debe heredar o aplicar el acceso al sistema de archivos del usuario. Para aplicaciones conectadas, use tokens con alcance de usuario cuando la integración los soporte. Un token global puede ser conveniente durante las pruebas, pero convierte al asistente en una vía para evitar los permisos que los usuarios esperan del servicio original.

La salida de la herramienta también se convierte en contexto. Guárdala bajo el mismo usuario y alcance de sesión que la solicitud, evita colocar secretos en el historial de chat ordinario y redacta campos sensibles de los registros. Una capa de recuperación segura no compensa una herramienta que devuelve directamente datos de otro usuario.

¿Qué patrón de aislamiento se adapta a un servidor de IA doméstico?

El límite correcto depende de la sensibilidad, el número de usuarios y cuánto mantenimiento puede realizar el propietario del servidor. La tabla compara diseños comunes según lo que se comparte y dónde es más probable que ocurran errores.

Para la mayoría de los hogares, las reglas a nivel de fila, la recuperación vectorial con alcance de usuario, las rutas de archivos aisladas y los permisos de herramientas específicos para cada usuario proporcionan un punto medio práctico. Los contenedores o máquinas separadas se vuelven valiosos cuando los usuarios no confían entre sí, las herramientas ejecutan código arbitrario o las consecuencias de un error son inusualmente altas.

Por qué las cuentas separadas aún filtran contexto

El primer fallo es aplicar permisos solo en la interfaz. Ocultar las conversaciones de otro usuario en una barra lateral no sirve de nada si la API las devuelve cuando se le da un ID diferente. Cada punto final del servidor debe repetir la decisión de autorización.

El segundo fallo es filtrar el historial de chat pero no la recuperación. El asistente muestra la conversación correcta pero busca en un índice vectorial compartido sin un filtro de usuario. La respuesta entonces contiene detalles privados que nunca aparecieron en el hilo visible.

El tercer fallo es compartir datos operativos. Los registros de depuración, trazas, cachés de mensajes, cargas temporales y análisis pueden contener el mismo contexto sensible que la respuesta final. El contexto en tiempo de ejecución puede exponer información sensible incluso cuando el modelo base nunca fue entrenado con ella.

El último fallo es confiar en el modelo como capa de control de acceso. Un mensaje del sistema puede describir expectativas de privacidad, pero no puede deshacer de forma fiable el contexto que nunca debería haberse recuperado. Los controles de seguridad deben decidir qué llega al modelo; el modelo no debe decidir qué se permitió recuperar al usuario.

Cómo probar si el aislamiento de usuarios realmente funciona

Crea dos cuentas ordinarias con datos de prueba deliberadamente diferentes. Dale al Usuario A un documento que contenga una frase única e inofensiva y al Usuario B una frase diferente. Ninguna de las frases debe aparecer en ningún otro lugar del corpus de prueba.

Desde el Usuario B, intenta preguntas directas, búsquedas semánticas vagas, IDs de conversación adivinados, enlaces compartidos, archivos renombrados y solicitudes que pidan al asistente ignorar sus reglas. El objetivo no es solo probar la interfaz normal; es verificar que cada ruta no devuelva datos fuera del alcance del Usuario B.

Repite la prueba después de cerrar sesión, reiniciar el servicio, calentar la caché, reindexar documentos, restaurar copias de seguridad y eliminar cuentas. Estas transiciones a menudo usan rutas de código diferentes a las del chat ordinario y pueden reintroducir contexto obsoleto que la ruta principal de consulta maneja correctamente.

Revisa los registros del servidor con las mismas dos identidades. Cada recuperación, lectura de archivo, escritura en memoria y llamada a herramientas debe llevar el alcance de usuario esperado sin registrar innecesariamente el contenido privado de los mensajes. Un administrador debe poder explicar por qué cada elemento del contexto entró en el mensaje final.

Un diseño práctico de aislamiento para uso doméstico

Comienza manteniendo la ejecución del modelo y los datos localmente, luego usa un servicio de identidad y un ID de usuario confiable que el servidor derive de la sesión. Pasa esa identidad a través del servicio de chat, almacenamiento de memoria, búsqueda vectorial, puerta de enlace de archivos y capa de herramientas. Rechaza las solicitudes cuando falte la identidad o el alcance de permiso en lugar de recurrir a un valor predeterminado compartido.

Mantén el modelo compartido a menos que una amenaza específica requiera entornos de ejecución separados. La pila circundante de almacenamiento, recuperación, inferencia, interfaz y permisos es lo que convierte archivos locales en un asistente privado basado en datos locales. Duplicar pesos del modelo no repara una consulta de base de datos sin ámbito.

Usa un identificador de usuario o espacio de trabajo en registros duraderos, aplica acceso a filas debajo de la aplicación cuando sea posible y coloca datos vectoriales en espacios de nombres con ámbito de usuario o particiones filtradas obligatorias. Da a los archivos temporales y cachés el mismo ámbito, luego establece reglas de expiración y eliminación para cada capa.

Separa el conocimiento personal y compartido intencionalmente. Un manual del hogar puede pertenecer a un espacio de trabajo común, mientras que los registros fiscales permanecen privados. En un servidor de IA con múltiples roles, la membresía de grupo debe determinar qué espacio de trabajo compartido se une al contexto personal del usuario para esa solicitud.

Elige un límite más fuerte cuando la amenaza cambie. Si los usuarios pueden ejecutar código, instalar complementos, montar carpetas arbitrarias o conectar herramientas potentes, solo los filtros de la aplicación pueden no ser suficientes. Contenedores separados, máquinas virtuales, credenciales y almacenamiento pueden limitar lo que un servicio comprometido puede alcanzar.

Preguntas frecuentes

¿Cada usuario necesita una copia separada del modelo de IA?

No. Varios usuarios pueden compartir un modelo de inferencia porque el contexto personal puede ensamblarse por separado para cada solicitud. Procesos de modelo separados pueden ser útiles para usuarios no confiables, adaptadores personalizados, límites estrictos de recursos o cargas de trabajo que requieren un límite operativo más fuerte.

¿Es suficiente un historial de chat separado para proteger el contexto personal?

No. El historial de chat es solo una fuente de contexto. Los documentos recuperados, índices vectoriales, archivos subidos, cachés, credenciales de herramientas, registros y datos temporales deben seguir el mismo límite de identidad. Una capa sin ámbito puede exponer información incluso cuando la lista visible de conversaciones es correcta.

¿Pueden los miembros de la familia compartir intencionalmente algo de contexto?

Sí. Coloca documentos y memorias compartidas en un ámbito explícito de hogar o espacio de trabajo, luego concede membresía a los usuarios que la necesiten. Mantén los registros personales bajo propiedad individual. El generador de indicaciones puede combinar el ámbito privado del usuario actual con los ámbitos compartidos autorizados sin abrir ninguno a todos.

La regla práctica es simple: comparte el modelo, no la ruta del contexto. La identidad debe restringir los datos antes de que se lean, recuperen, almacenen en caché o pasen a una herramienta. Si cada capa puede responder qué usuario autorizó un elemento, un servidor de IA doméstico puede seguir siendo personal incluso cuando su capacidad de cómputo se comparte.