Ghost Vectors: los embeddings eliminados siguen siendo recuperables en las bases vectoriales RAG

¿Qué es esto?

En junio de 2026, Chandranil Chakraborttii, Jackeline García Alvarado, Sitora Abdulofizova y Shivanshu Dwivedi (Trinity College) publicaron Ghost Vectors: Soft-Deleted Embeddings Remain Reconstructible in HNSW Vector Databases. El artículo examina una suposición silenciosa presente en casi toda arquitectura de generación aumentada por recuperación (RAG): que cuando se elimina un registro de la base vectorial, el dato desaparece.

Por lo general no es así. La mayoría de las bases vectoriales de producción construidas sobre índices HNSW (Hierarchical Navigable Small World) implementan la eliminación como un borrado lógico (soft delete): el registro se marca con una «lápida» (tombstone) para que la búsqueda deje de devolverlo, pero el embedding subyacente permanece escrito físicamente en los archivos de índice del disco. Los autores muestran que esos vectores «eliminados» pueden leerse directamente desde el índice en bruto, en la capa de almacenamiento, y luego invertirse para reconstruir una aproximación del contenido original. Como los embeddings suelen codificar datos personales o médicos, una simple solicitud de eliminación se convierte en un problema de cumplimiento frente a regímenes de borrado de datos como el artículo 17 del RGPD y HIPAA.

Cómo funciona

Dos hechos se combinan, y ninguno requiere atacar una API de consulta en producción.

Primero, el borrado lógico no elimina. Para mantenerse rápido, un índice HNSW marca un nodo como eliminado y lo omite durante el recorrido, difiriendo la recuperación efectiva de ese espacio a una compactación o reconstrucción posterior (a menudo poco frecuente). Hasta entonces, el vector, y cualquier carga útil almacenada junto a él, permanece en el disco. Los autores confirmaron este comportamiento en tres implementaciones HNSW distintas: la lectura de los archivos de índice en bruto recupera vectores que la API declara eliminados, evitando por completo la capa de acceso.

Segundo, los embeddings no son de un solo sentido. Con el modelo de inversión Vec2Text, listo para usar y sin ningún ajuste fino específico del dominio, el equipo reconstruyó contenido legible a partir de los vectores recuperados en varios conjuntos de datos reales y varias modalidades, tanto texto como imágenes, con tasas de reconstrucción significativas. No hace falta código de explotación para entender el resultado: un embedding es una proyección con pérdida pero reversible de su entrada, así que quien puede leer el vector puede aproximar el texto de origen. El modelo de amenaza apunta aquí a cualquiera con alcance a la capa de almacenamiento — una instantánea de disco robada, un bucket de copia de seguridad mal configurado, un volumen en la nube dejado legible o un actor interno — y no a un usuario remoto que consulta el punto de acceso de búsqueda.

Por qué importa

Las canalizaciones RAG se han convertido, sin ruido, en almacenes duraderos de texto sensible: transcripciones de soporte, expedientes de RR. HH., notas clínicas, contratos. Los equipos tratan el embedding como un bloque numérico opaco y anonimizado, y consideran que una eliminación a nivel de API cumple la solicitud de borrado de un usuario. Este artículo invalida ambas suposiciones a la vez. El vector es recuperable, y es reversible: por tanto «lo eliminamos» puede ser falso justo cuando un regulador, un auditor o una obligación de notificación de brechas depende de que sea cierto.

La brecha es especialmente peligrosa porque es invisible desde el propio punto de vista de la aplicación. Consulte la API tras una eliminación y el registro habrá desaparecido de verdad; inspeccione el archivo de índice o una copia de seguridad nocturna y seguirá ahí. Cada réplica, instantánea y copia fría que capturó el vector antes de la compactación es una copia independiente del dato «olvidado». Es el primo, en la capa de almacenamiento, de la fuga en el momento de la recuperación tratada en la fuga de la base de conocimiento RAG, y un recordatorio —junto a trabajos como el fracaso de las defensas por embeddings en entornos multiagente— de que los embeddings merecen el mismo trato que los datos brutos que codifican.

Defensas

El artículo es constructivo: nombra el fallo y aporta una mitigación.

1. No equipare una lápida con un borrado. Si su postura de cumplimiento afirma que el dato está eliminado, el vector y su carga útil deben eliminarse realmente del índice, de sus réplicas y de sus copias de seguridad, no solo ocultarse de la búsqueda. Planifique y verifique las compactaciones/reconstrucciones en lugar de aplazarlas indefinidamente.

2. Destruya por criptografía en vez de borrar lógicamente. Los autores proponen la Epoch Key Rotation: cifrar los vectores almacenados y, al eliminar, descartar la clave para que el cifrado sea irrecuperable. Informan de que esto reduce la reconstrucción de PII observada al 0 %, se ejecuta en unos 2,5 ms para 500 vectores eliminados y emite una prueba firmada con ECDSA de que la eliminación ocurrió — un artefacto auditable que presentar a un regulador.

3. Trate los embeddings como datos regulados. Cifre los índices vectoriales en reposo, restrinja el acceso a los archivos en bruto y a las instantáneas con los mismos controles que aplica al corpus de origen, y mantenga los embeddings de datos personales o de salud fuera de almacenamientos de baja confianza.

4. Extienda la eliminación a todo el linaje. Un borrado verificado debe alcanzar cada copia de seguridad, réplica e instantánea exportada que alguna vez contuvo el vector. Inventaríe esas copias antes de prometer a un usuario que su dato ha desaparecido.

5. Produzca evidencia de eliminación. Para el artículo 17 del RGPD y HIPAA, una prueba de borrado criptográfica y con marca de tiempo es mucho más sólida que una API que devuelve «no encontrado».

Estado

Elemento	Referencia	Fecha	Notas
Artículo Ghost Vectors (arXiv 2606.18497)	arXiv	2026-06	Trinity College; tres implementaciones HNSW analizadas
Método de recuperación	arXiv	2026-06	Lectura de archivos de índice en bruto en el almacenamiento + inversión Vec2Text, sin ajuste fino
Tipos de datos reconstruidos	arXiv	2026-06	Embeddings de texto e imagen en varios conjuntos de datos
Encuadre de cumplimiento	arXiv	2026-06	Artículo 17 del RGPD, requisitos de borrado de HIPAA
Defensa propuesta	arXiv	2026-06	Epoch Key Rotation: 0 % de reconstrucción de PII, ~2,5 ms / 500 vectores, prueba de eliminación firmada con ECDSA

La conclusión no es que «las bases vectoriales están rotas». Es que la eliminación en un almacén RAG es una propiedad de la capa de almacenamiento, no una respuesta de API — y si sus garantías de borrado se detienen en la interfaz de consulta, el fantasma de cada registro eliminado sigue en sus archivos de índice.