Onde vive realmente a memória da sua IA?

Olhe para o que se acumula numa memória de IA ao fim de três meses de uso real: nomes de clientes, cláusulas de contratos, conversas sobre salários, a arquitetura de sistemas pelos quais é responsável, aquele detalhe médico que mencionou uma vez para explicar um atraso. Não é uma cache. É um dossiê, e construiu-o por ser útil a si próprio.

Agora responda a três perguntas sobre ele. Em que país estão esses dados? Quem os pode ler? O que lhes acontece se a empresa fechar no próximo ano? A maioria dos produtos de memória não torna essas respostas fáceis de encontrar, e alguns genuinamente não conseguem responder à primeira.

O que o RGPD diz realmente (e o que não diz)

O RGPD não proíbe guardar dados fora da Europa, e quem lhe vende «alojamento na UE ou está ilegal» está a exagerar. O que exige é um fundamento de licitude, limitação das finalidades, segurança proporcionada ao risco e — quando dados pessoais saem do EEE — um mecanismo de transferência válido, com garantias que se aguentem de facto.

É esse último ponto que se torna incómodo. No acórdão Schrems II, o Tribunal de Justiça invalidou o Privacy Shield e deixou claro que uma cláusula contratual de nada serve se o direito de vigilância do país de destino se sobrepuser a ela. As recomendações do CEPD que se seguiram empurraram os responsáveis pelo tratamento para medidas técnicas suplementares, o que na prática quer muitas vezes dizer: mantenha isso na Europa, ou cifre-o de modo a que o prestador não o possa ler.

Duas consequências que contam no momento de escolher um serviço de memória:

• Se é uma empresa que trata dados de clientes, o armazenamento de memória é um subcontratante ulterior. Precisa de um DPA e precisa de saber onde corre — não por pureza, mas porque os seus próprios clientes vão perguntar.
• Se é um particular, nada disto é uma obrigação legal para si. Continua a ser a diferença entre dados sob jurisdição da UE e dados sob a de outra pessoa.

«Conforme com o RGPD» é uma afirmação, não um certificado

Não há nenhum organismo de certificação RGPD a emitir selos. Quando um fornecedor escreve «conforme com o RGPD» numa página de preços, isso é uma autodeclaração. Pode ser inteiramente verdade. Não é prova.

A SOC 2 e a ISO 27001 *são* auditadas, e valem alguma coisa — mas auditam se uma empresa faz o que diz que faz, não onde estão os seus bytes nem se a resposta lhe convém. Um relatório SOC 2 Type 2 e alojamento exclusivamente nos EUA coexistem perfeitamente.

Portanto ignore os selos e peça concretizações:

1. Em que país estão a base de dados de produção e as suas cópias de segurança? Nomeie o fornecedor e a região.
2. Quem tem acesso técnico ao texto em claro, segundo que procedimento, e esse acesso fica registado?
3. Existe um DPA que eu possa assinar, e lista os subcontratantes ulteriores?
4. Como é imposto o isolamento entre clientes — pelo código aplicacional, ou pela base de dados?
5. Cifra em repouso: é ao nível do disco, ou o prestador não consegue ler as minhas linhas de todo? São garantias muito diferentes.
6. Se eu sair: formato de exportação, prazo de eliminação, e a eliminação abrange as cópias de segurança?

Um fornecedor incapaz de responder a seis perguntas factuais sobre a sua própria infraestrutura acabou de lhe dizer algo útil.

A questão de isolamento que ninguém põe

Os serviços multicliente separam os clientes de uma de duas maneiras. Ou o código aplicacional filtra por cliente em cada consulta, ou a própria base de dados se recusa a devolver as linhas de outro cliente.

A primeira é normal e funciona — até que uma consulta em dez mil se esqueça do filtro. Essa família de bugs está por trás de boa parte dos incidentes «vimos os dados de outro utilizador» de que já leu. A segunda custa mais a construir e falha do lado seguro: um filtro em falta devolve nada, em vez de devolver as memórias de outra pessoa.

É uma pergunta legítima, e a resposta diz-lhe como a equipa pensa o modo de falha.

Zero-knowledge: útil, raro e amplamente mal descrito

A resposta mais forte possível é que o prestador não detém nenhuma chave e matematicamente não consegue ler os seus dados. Muito poucos produtos de memória o oferecem, por uma razão aborrecida: a pesquisa semântica precisa de calcular sobre o conteúdo. Pode cifrar blobs que o servidor não consegue ler, mas depois alguma coisa tem de fazer o embedding e a classificação, e essa coisa precisa do texto em claro — no seu dispositivo, ou de todo.

Por isso, quando vir «cifrado de ponta a ponta» num serviço de memória que também faz pesquisa semântica do lado do servidor, leia com atenção. Muitas vezes quer dizer TLS em trânsito e cifra em repouso com uma chave detida pelo prestador. É um desenho razoável. Não é zero-knowledge, e os dois são confundidos constantemente — incluindo, para ser direto, nos textos de marketing de toda esta categoria.

O que fazemos, e o que não fazemos

O Pryzm corre na Hetzner, na Alemanha, num volume cifrado. Cada cliente tem o seu próprio esquema e o seu próprio papel PostgreSQL, por isso o isolamento é imposto pelo motor da base de dados e não pelo nosso código. Além disso, as memórias de cada conta são cifradas com a chave própria da conta (AES-256-GCM), bloqueada pela sua palavra-passe e por uma frase de recuperação. As cópias de segurança são cifradas e ficam na Europa. A jurisdição é europeia e não há casa-mãe norte-americana na cadeia.

O que não reivindicamos: zero-knowledge. Enquanto tem a sessão iniciada, o servidor guarda a sua chave em memória e decifra as suas memórias para responder à sua IA — a pesquisa semântica precisa do texto em claro algures. Existe acesso administrativo técnico aos servidores, restrito e registado. Se precisa de um fornecedor que nunca consiga ler os seus dados, a resposta honesta é alojar você mesmo.

Se preferir não confiar em prestador nenhum, vários servidores de memória auto-alojáveis são bons e gratuitos, e listamo-los na nossa comparação das alternativas. Alojar o seu próprio é a resposta mais forte a todo este artigo.