Cifrar la memoria de la IA: por qué una clave por proyecto supera a una por base de datos

Una memoria que vale la pena tener es una memoria que vale la pena proteger. Si un sistema va a guardar lo que le contó sobre el diagnóstico de su hijo, su caso judicial o sus finanzas, entonces la frase «cifrado en reposo» —la que usa todo proveedor— merece una mirada más exigente sobre lo que realmente significa.

Qué suele significar «cifrado en reposo»

Casi siempre significa cifrado de disco o de volumen completo. El disco está cifrado; el proceso de la base de datos tiene la clave y descifra todo lo que lee. Eso defiende contra una sola cosa —que alguien retire físicamente la unidad— y contra casi nada más. Un atacante que alcanza la base de datos en ejecución, una copia robada que viaja con su clave, una consulta interna demasiado amplia: en todos estos casos los datos son legibles sin más, porque desde el punto de vista de la base de datos siempre lo fueron.

Para un producto construido sobre la memoria, además tiene una propiedad incómoda: una clave abre a todos. No hay frontera técnica entre su material y el de otro cliente, solo consultas escritas correctamente.

Una clave por proyecto

FocusLM cifra a nivel de fila, no de disco. Cada proyecto recibe su propia clave de datos. Cada archivo de memoria, cada revisión y cada mensaje del chat de ese proyecto se cifra con esa clave y ninguna otra. Los hilos de chat que no pertenecen a ningún proyecto se cifran con una clave de espacio de trabajo, por el mismo principio.

Esas claves por proyecto están a su vez cifradas por una única clave del entorno, que nunca se guarda junto a los datos que protege. Este arreglo —una clave que cifra claves, que cifran datos— es el cifrado de sobre, y es la recomendación estándar para jerarquías de claves en las guías de gestión de claves del NIST. Aporta dos cosas prácticas: rotar la clave superior toca una pequeña fila por proyecto en vez de recifrar los datos de nadie, y la clave de un solo proyecto puede destruirse por sí sola.

La vinculación es más estrecha que «misma clave, mismo proyecto». Cada valor cifrado está criptográficamente ligado a la fila y el proyecto exactos a los que pertenece, de modo que un texto cifrado copiado a otro proyecto no se descifra en el contexto equivocado: no se descifra en absoluto. Mover datos entre inquilinos no es un error sutil que aparece después; es un error en el momento del intento.

Por qué no buscamos sobre texto cifrado

El deseo evidente es mantener todo cifrado y aun así ejecutar búsqueda de texto ordinaria sobre ello. Existen esquemas —el cifrado determinista hace iguales los valores iguales, el de preservación de orden mantiene los valores ordenables— y son exactamente tan cómodos como suenan.

También filtran. Una larga línea de trabajo sobre ataques de inferencia contra bases de datos cifradas que preservan propiedades muestra que, cuando los textos cifrados preservan la igualdad o el orden, un atacante que solo dispone de la columna cifrada y de estadística pública ordinaria puede recuperar buena parte del texto claro. El análisis de frecuencias hace casi todo el trabajo: en datos reales la distribución de valores rara vez es plana, y un cifrado que preserva la estructura preserva la distribución con ella.

El índice de búsqueda no guarda su texto

La búsqueda semántica necesita vectores, y los vectores tienen su propia historia de privacidad, una fácil de equivocar, porque un embedding parece una lista inerte de números.

No es inerte. En Text Embeddings Reveal (Almost) As Much As Text, Morris y sus colegas mostraron que los embeddings densos pueden invertirse a su texto original tratando la reconstrucción como generación controlada y corrigiendo iterativamente una conjetura hasta que vuelve a embeberse en el mismo punto. Recuperaron el 92 % de las entradas de 32 tokens de forma exacta y extrajeron nombres completos de pacientes de un corpus de notas clínicas. Trabajo posterior generalizó el ataque: un modelo de inversión generativo puede reconstruir frases enteras coherentes a partir de un único embedding de frase, y estudios de seguimiento lo han reproducido y ampliado.

Sin embargo, quitar el texto no cierra ese argumento, y presentarlo como si lo cerrara sería deshonesto. El vector en sí sigue ahí: tiene que estarlo, porque la geometría entre vectores es justo lo que hace posible la búsqueda semántica. Cifrarlo como ciframos una nota no dejaría nada que buscar.

Así que el siguiente paso es ligar el espacio de vectores a la misma clave por proyecto que ya protege el contenido: los vectores de cada proyecto residen en un espacio que solo la clave de ese proyecto describe. Eso mantiene la búsqueda intacta y a la vez vuelve los vectores inutilizables en las coordenadas propias del modelo de embeddings, donde operan los ataques de inversión publicados. Eso eleva el coste de un ataque en vez de eliminarlo, y preferimos decirlo así antes que llamarlo cifrado. Está en marcha, no entregado.

La consecuencia para un producto de memoria es directa: un índice de vectores robado debe tratarse como texto claro robado. Por eso el índice de FocusLM guarda el vector, la ruta del archivo y una huella con clave, y no el texto de sus notas. Cuando una búsqueda coincide, el fragmento que usted lee se obtiene y descifra del almacén cifrado en ese momento. El índice sabe dónde hay algo relevante; no sabe qué dice.

Borrado que sobrevive a la copia de seguridad

«Borrar» en la mayoría de los sistemas significa marcar una fila como borrada. Los datos permanecen: en la tabla, en el volcado de anoche, en la réplica, en cualquier retención que tengan las copias. Para una nota sobre la enfermedad de un hijo, eso no es borrar en ningún sentido que la persona que lo pide reconocería.

Como cada proyecto tiene su propia clave, podemos hacer algo más fuerte: borrar un proyecto destruye esa clave. El texto cifrado permanece donde ya está, y nada de ello puede volver a leerse: ni en la base de datos en vivo, ni en una instantánea tomada antes del borrado. Esto es el crypto-shredding, y es la respuesta estándar al borrado en sistemas donde sobrescribir físicamente cada copia es impracticable o no verificable, es decir, todo sistema distribuido con copias de seguridad.

Trabajo reciente afila el caso específicamente para sistemas de IA. Un estudio de 2026 sobre bases de datos de vectores encontró que los embeddings que solo han sido borrados de forma lógica siguen siendo reconstruibles desde la estructura del índice: el borrado es una marca, y los datos siguen ahí para quien lee el archivo en vez de preguntar al motor de consultas. Combinado con la inversión de embeddings, un borrado lógico en un almacén de vectores no es un borrado en absoluto.

Qué sigue siendo honestamente visible

Las promesas de cifrado valen exactamente lo que admiten sus excepciones. Las nuestras:

• La estructura no es contenido. Los nombres de carpetas y archivos de su memoria se guardan en claro, porque el sistema los recorre y aplica globs. Una ruta como salud/oncología/… revela un tema aunque la nota en sí sea ilegible.
• Títulos de chat. El título de un hilo se guarda en claro para que la barra lateral lo busque, y se genera a partir de su primer mensaje. La conversación está cifrada; la frase que la abrió, no.
• Nombres de archivo. El nombre que subió viaja en la clave de almacenamiento y en el registro operativo, aunque el contenido del archivo esté sellado.
• Los vectores de búsqueda, por ahora. Hoy están en el índice en el espacio propio del modelo de embeddings, el espacio al que se aplica la investigación de inversión. Ligarlos a la clave del proyecto es el trabajo descrito arriba.
• Metadatos operativos. Qué modelo se ejecutó, cuánto tardó, cuánto costó. No lo que se dijo.

Un patrón las recorre: el contenido está protegido, los nombres no. Rutas, títulos y nombres de archivo son lo que el sistema debe leer para organizar y encontrar, así que siguen legibles. Es un límite real, es el que querríamos que nos contaran como usuarios, y es lo siguiente en lo que trabajar, no una nota al pie que se despacha con la mano.

Por qué esto importa en un producto de memoria en particular

Un asistente de chat que le olvida entre sesiones guarda poco que valga la pena robar. Un sistema construido para acumular las cosas a las que usted vuelve una y otra vez —la memoria estructurada que hace posibles las respuestas fundamentadas— acumula justo el material que nunca debería filtrarse. El valor de la memoria y su sensibilidad crecen juntos; son la misma propiedad vista desde dos lados.

Esa es la razón para invertir la ingeniería en una clave por proyecto en vez de en una casilla que dice cifrado. Cuanto más fuerte es la memoria, menos aceptable es la respuesta corriente.