O que significa a eliminação completa de dados pessoais numa base de dados vetorial?

A eliminação completa de dados pessoais de uma base de dados vetorial significa que os dados já não podem ser obtidos através da API e que também foram removidos, expiraram ou se tornaram irrecuperáveis por meios criptográficos no estado físico dos índices e nas cópias dependentes.

A dificuldade é que um sistema RAG não armazena um objeto num único local. O texto original pode gerar blocos, embeddings, metadados, índices de grafos, caches, réplicas, registos, instantâneos e cópias de segurança. Eliminar o registo principal é apenas a primeira transição nesse ciclo de vida.

Eliminação lógica e apagamento físico são estados diferentes

Os índices vetoriais precisam frequentemente de alterações rápidas sem reconstruir imediatamente grandes estruturas de grafos ou segmentos. Uma operação de eliminação pode, por isso, marcar um ponto como indisponível para consultas normais, enquanto os bytes antigos permanecem num segmento do índice até ocorrer compactação, otimização ou substituição do segmento.

O estudo Ghost Vectors de 2026 demonstrou que embeddings eliminados suavemente podem continuar fisicamente recuperáveis a partir de ficheiros de índice HNSW em bruto, mesmo após a eliminação ao nível da API. Os investigadores demonstraram a recuperação de atributos sensíveis a partir de vários tipos de embeddings, tornando concreta a distinção entre invisibilidade na pesquisa e apagamento físico.

Isto não significa que todas as bases de dados vetoriais mantenham todos os vetores eliminados para sempre. Significa que uma garantia de eliminação tem de descrever o ciclo de limpeza do motor de armazenamento. “A consulta já não o devolve” é um teste funcional, não uma prova de que a representação subjacente desapareceu.

As cópias derivadas alargam a superfície de eliminação para além do vetor principal

Um documento privado pode existir como texto bruto, vários blocos, embeddings, metadados do documento, caches de reclassificação, resumos gerados, citações de conversas e caches de resultados de pesquisa. Se qualquer derivado puder revelar as informações pessoais eliminadas, eliminar um ID de embedding não conclui o pedido ao nível do utilizador.

Um fluxo de trabalho de eliminação de dados para RAG privado dá ênfase ao âmbito da eliminação no RAG em registos de origem, embeddings, índices derivados e camadas de retenção. A lição arquitetural útil é a proveniência: cada registo gerado precisa de um caminho estável de regresso à identidade de origem, para que um pedido de eliminação possa encontrar os seus descendentes.

O artigo relacionado da ZimaSpace sobre marcadores de eliminação em índices vetoriais analisa um mecanismo ao nível do índice. O apagamento completo é mais abrangente, porque tem de acompanhar os dados pessoais em toda a pilha de recuperação, não apenas remover um nó do grafo da pesquisa normal.

A compactação, as réplicas e as cópias de segurança criam cronogramas de eliminação diferentes

As réplicas ativas podem precisar que a eliminação seja propagada imediatamente, enquanto as cópias de segurança imutáveis podem conservar os dados antigos até expirar o respetivo período de retenção documentado. Uma tarefa de compactação pode reescrever fisicamente os segmentos do índice mais tarde do que a eliminação através da API. Estes cronogramas devem ser explícitos, para que o sistema consiga distinguir entre “não acessível”, “expurga pendente” e “expirou de todas as cópias retidas”.

A explicação do Qdrant sobre a limpeza orientada pelo otimizador descreve como os pontos eliminados e os segmentos fragmentados são tratados através da otimização, em vez de assumir que cada alteração reescreve instantaneamente o armazenamento. Embora os detalhes sejam específicos do produto, isto ilustra uma realidade geral dos repositórios vetoriais: a manutenção do esquema físico pode ficar atrasada relativamente à eliminação lógica.

As cópias de segurança também precisam de uma regra para o momento da restauração. Se for restaurada uma cópia de segurança antiga, o sistema não pode ressuscitar silenciosamente uma eliminação ocorrida depois dessa cópia. Mantenha um registo de eliminações durável, ou um estado de reconciliação equivalente, que possa ser reaplicado após a recuperação de desastre até que todas as cópias de segurança que contenham os dados antigos tenham expirado.

-15% OFF

ZimaBoard 2 - Mini Servidor Doméstico para a Sua Grande Ideia

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Uma declaração de eliminação precisa de um estado final verificável

Defina os objetos abrangidos pelo pedido, remova-os da recuperação online, propague a eliminação para réplicas e derivados, acione ou aguarde o mecanismo de limpeza física do motor e registe quais as cópias de segurança retidas que ainda contêm cópias históricas. Em seguida, teste tanto o acesso normal através da API como a exposição a níveis inferiores de armazenamento, de acordo com o modelo de ameaça.

Um estudo de sistemas de bases de dados sobre apagamento significativo na presença de dependências formaliza um requisito mais exigente do que simplesmente eliminar uma linha: as dependências de dados restantes não devem permitir que as informações apagadas se tornem inferíveis. Isto reforça o limite sistémico aqui aplicável — a eliminação tem de considerar representações dependentes e cópias retidas, e não apenas o ID do vetor principal.

Considere a eliminação concluída apenas relativamente a um limite documentado: as cópias pesquisáveis desapareceram agora, a limpeza física do armazenamento ativo foi verificada, os derivados foram expurgados e as cópias de segurança retidas são abrangidas por uma política explícita de expiração ou apagamento criptográfico. Se o sistema não consegue enumerar os locais para onde um documento de origem foi propagado, não pode afirmar com segurança que uma eliminação solicitada pelo utilizador alcançou todas as cópias.