¿Dónde vive realmente la memoria de su IA?

Mire lo que se acumula en una memoria de IA tras tres meses de uso real: nombres de clientes, condiciones de contratos, conversaciones sobre salarios, la arquitectura de sistemas de los que usted es responsable, ese detalle médico que mencionó una vez para explicar un retraso. No es una caché. Es un expediente, y lo construyó siendo útil a sí mismo.

Ahora responda a tres preguntas sobre él. ¿En qué país están esos datos? ¿Quién puede leerlos? ¿Qué pasa con ellos si la empresa cierra el año que viene? La mayoría de los productos de memoria no ponen fácil encontrar esas respuestas, y unos cuantos sencillamente no pueden responder a la primera.

Lo que el RGPD dice de verdad (y lo que no)

El RGPD no prohíbe almacenar datos fuera de Europa, y quien le venda «alojamiento en la UE o es usted ilegal» está exagerando. Lo que exige es una base jurídica, limitación de la finalidad, seguridad proporcionada al riesgo y —cuando los datos personales salen del EEE— un mecanismo de transferencia válido con garantías que de verdad se sostengan.

Esa última parte es la incómoda. En Schrems II el Tribunal de Justicia anuló el Privacy Shield y dejó claro que una cláusula contractual no sirve de nada si el derecho de vigilancia del país de destino pasa por encima. Las recomendaciones posteriores del CEPD empujaron a los responsables del tratamiento hacia medidas técnicas complementarias, lo que en la práctica suele significar: guárdelo en Europa, o cífrelo de modo que el proveedor no pueda leerlo.

Dos consecuencias que importan al elegir un servicio de memoria:

• Si es una empresa que trata datos de clientes, el almacén de memoria es un subencargado del tratamiento. Necesita un DPA, y necesita saber dónde corre; no por pureza, sino porque sus propios clientes lo van a preguntar.
• Si es un particular, nada de esto es una obligación legal para usted. Sigue siendo la diferencia entre datos bajo jurisdicción europea y datos bajo la de otro.

«Conforme al RGPD» es una afirmación, no un certificado

No existe ningún organismo de certificación del RGPD que emita insignias. Cuando un proveedor escribe «conforme al RGPD» en una página de precios, eso es una autodeclaración. Puede ser totalmente cierta. No es una prueba.

SOC 2 e ISO 27001 *sí* se auditan y valen algo, pero auditan si una empresa hace lo que dice que hace, no dónde están sus bytes ni si esa respuesta le conviene. Un informe SOC 2 Type 2 y un alojamiento exclusivamente estadounidense conviven perfectamente.

Así que ignore las insignias y pida datos concretos:

1. ¿En qué país están la base de datos de producción y sus copias de seguridad? Nombre al proveedor y la región.
2. ¿Quién tiene acceso técnico al texto en claro, mediante qué procedimiento, y queda registrado ese acceso?
3. ¿Hay un DPA que pueda firmar, y enumera a los subencargados?
4. ¿Cómo se impone el aislamiento entre clientes: por el código de la aplicación, o por la base de datos?
5. Cifrado en reposo: ¿a nivel de disco, o el proveedor no puede leer mis filas en absoluto? Son garantías muy distintas.
6. Si me voy: formato de exportación, plazo de supresión, y ¿la supresión incluye las copias de seguridad?

Un proveedor incapaz de responder a seis preguntas factuales sobre su propia infraestructura le ha dicho algo útil.

La pregunta sobre el aislamiento que nadie hace

Los servicios multicliente separan a sus clientes de una de estas dos maneras. O el código de la aplicación filtra por cliente en cada consulta, o la propia base de datos se niega a devolver las filas de otro inquilino.

La primera es normal y funciona, hasta que una consulta de cada diez mil olvida el filtro. Esa familia de fallos está detrás de buena parte de los incidentes de «hemos visto los datos de otro usuario» sobre los que ha leído. La segunda cuesta más construirla y falla del lado seguro: un filtro que falta no devuelve nada, en lugar de los recuerdos de otra persona.

Es una pregunta legítima, y la respuesta le dice cómo piensa el equipo sobre el modo de fallo.

Conocimiento cero: útil, raro y muy mal descrito

La respuesta más fuerte posible es que el proveedor no posee ninguna clave y matemáticamente no puede leer sus datos. Muy pocos productos de memoria lo ofrecen, por una razón aburrida: la búsqueda semántica necesita calcular sobre el contenido. Puede cifrar blobs que el servidor no lee, pero entonces algo tiene que calcular los embeddings y la clasificación, y ese algo necesita el texto en claro: en su dispositivo, o de ninguna manera.

Así que cuando vea «cifrado de extremo a extremo» en un servicio de memoria que además hace búsqueda semántica del lado del servidor, léalo con atención. A menudo significa TLS en tránsito y cifrado en reposo con una clave en manos del proveedor. Es un diseño razonable. No es conocimiento cero, y los dos se confunden constantemente, incluidos, por ser francos, los textos de marketing de toda esta categoría.

Lo que hacemos, y lo que no

Pryzm corre en Hetzner, en Alemania, sobre un volumen cifrado. Cada cliente tiene su propio esquema y su propio rol de PostgreSQL, así que el aislamiento lo impone el motor de base de datos y no nuestro código. Además, los recuerdos de cada cuenta se cifran con la clave propia de la cuenta (AES-256-GCM), bloqueada por su contraseña y una frase de recuperación. Las copias de seguridad están cifradas y se quedan en Europa. La jurisdicción es europea y no hay matriz estadounidense en la cadena.

Lo que no afirmamos: conocimiento cero. Mientras tiene la sesión abierta, el servidor guarda su clave en memoria y descifra sus recuerdos para responder a su IA: la búsqueda semántica necesita el texto en claro en algún sitio. Existe un acceso administrativo técnico a los servidores, restringido y registrado. Si necesita un proveedor que nunca pueda leer sus datos, la respuesta honesta es alojarlo usted mismo.

Si prefiere no confiar en ningún proveedor, varios servidores de memoria autoalojables son buenos y gratuitos, y los listamos en nuestra comparativa de las alternativas. Alojarlo usted mismo es la respuesta más fuerte a todo este artículo.