Seguridad de bases de datos vectoriales: Pinecone, Qdrant, Weaviate 2026

Las bases de datos vectoriales son el almacén persistente de las pipelines RAG y la mayoría de aplicaciones LLM modernas. Cada copilot interno, buscador semántico corporativo y agente con memoria a largo plazo termina apoyándose en una base vectorial. Su seguridad es una categoría nueva en 2025 y 2026, y muchos equipos las tratan todavía con asunciones de base de datos relacional tradicional. Esas asunciones no se sostienen: el contenido se almacena como vectores potencialmente invertibles, la autenticación por defecto suele ser permisiva, la multi-tenencia se delega en filtros frágiles y los engines maduran más rápido que los controles aplicados sobre ellos.

Esta guía describe qué es una base vectorial, los players principales en 2026, los riesgos específicos que la diferencian de una base relacional y un plan de hardening realista por engine. Está pensada para CISOs, arquitectos de IA y equipos que estén desplegando o auditando vector databases en producción.

Lo esencial sobre seguridad de bases de datos vectoriales

• Una vector database no es una base de datos tradicional: almacena representaciones vectoriales potencialmente invertibles, no campos opacos.
• El riesgo de embedding inversion convierte los vectores en datos potencialmente reconstruibles, con implicaciones GDPR no resueltas.
• La multi-tenencia depende casi siempre de filtros de metadatos: un bypass de filtro convierte el aislamiento en ficción.
• Las instalaciones por defecto de varios engines abren puertos sin autenticación, y aparecen expuestas a internet con frecuencia.
• Una auditoría de vector database va más allá de la base: cubre engine, modelo de embeddings, retriever, ingestion y consumidores.

Qué es una base de datos vectorial y dónde aparecen

Una vector database es un sistema diseñado para indexar y consultar vectores densos de alta dimensionalidad. En lugar de buscar por igualdad o por rango, ejecuta búsquedas por similitud: dado un vector de consulta, devuelve los top-k vectores más cercanos según una métrica como distancia coseno, producto escalar o distancia euclídea.

Para hacerlo a escala no recorre todos los vectores: construye un índice aproximado que sacrifica recall a cambio de latencia. Las familias más usadas son HNSW (Hierarchical Navigable Small World), IVF (Inverted File Index), PQ (Product Quantization) y sus combinaciones como IVF_PQ o HNSW_PQ. Cada una introduce sus propios parámetros de tuning y compromisos.

Los vectores proceden de un modelo de embeddings que convierte texto, imagen, audio u otra señal en una representación numérica densa. Esa representación captura significado semántico, no caracteres: dos frases con palabras distintas pueden estar muy cerca si dicen lo mismo, y dos frases con palabras casi idénticas pueden estar lejos si su sentido difiere.

Las bases vectoriales aparecen hoy en cuatro casos de uso dominantes:

• RAG (Retrieval Augmented Generation), donde los documentos corporativos se indexan para fundamentar respuestas de un LLM.
• Búsqueda semántica, donde un buscador interno o de catálogo devuelve resultados por significado, no por keyword.
• Sistemas de recomendación modernos, donde los embeddings de usuarios y productos permiten matching afinado.
• Detección de anomalías, donde la distancia de un nuevo vector respecto a un cluster habitual revela comportamiento atípico.

En los cuatro casos, la base vectorial deja de ser una pieza opcional y se convierte en el almacén persistente del que depende toda la aplicación.

Players principales 2026

El mercado se ha consolidado en torno a un puñado de engines, cada uno con su perfil de despliegue y modelo de seguridad nativo.

• Pinecone. SaaS gestionado, opaco, multi-region. Ofrece namespaces, claves API, control de acceso a nivel proyecto y cifrado en reposo. Es la opción más popular en startups por su modelo serverless.
• Qdrant. Engine open source escrito en Rust con cloud propio. Soporta filtros ricos sobre payload, RBAC en versión enterprise y despliegue self-hosted o gestionado.
• Weaviate. Open source con cloud gestionado. Aporta esquema fuerte sobre los datos, módulos de embeddings integrados y multi-tenencia nativa.
• Milvus. Open source con despliegue distribuido para grandes volúmenes. Su oferta gestionada es Zilliz Cloud. Es el preferido para miles de millones de vectores.
• Chroma. Diseño embebido orientado a desarrollo y prototipado. Aparece dentro de muchas aplicaciones LangChain o LlamaIndex iniciales como almacén local sencillo.
• pgvector. Extensión de PostgreSQL que añade tipo vector y operadores de similitud. Es la elección lógica cuando ya hay PostgreSQL con datos relacionales.
• Redis Stack con módulo vectorial, OpenSearch k-NN y Elasticsearch con su capa vectorial. Permiten reaprovechar infraestructura existente sin introducir un nuevo engine.

La decisión de engine no debería tomarse solo por benchmarks de QPS o integraciones, sino también por las garantías nativas de aislamiento, autenticación, cifrado, audit logging y multi-tenant. Esas garantías varían mucho entre engines.

Riesgos específicos de las bases de datos vectoriales

Una base vectorial introduce vectores de ataque que no aparecen en una base relacional tradicional. Hay que evaluarlos de forma explícita porque las herramientas defensivas heredadas casi nunca los cubren.

• Debilidad de multi-tenencia. La mayoría de implementaciones multi-tenant se apoyan en filtros sobre namespace, metadata o payload. Un bypass de filtro o un error en la construcción de la query devuelven vectores de otro tenant, con exposición cruzada de contenido confidencial.
• Embedding inversion. Investigación académica reciente ha demostrado que los embeddings de modelos generalistas son parcialmente invertibles. A partir de un vector y cierto conocimiento del modelo origen, se reconstruye una aproximación del texto original. Esto convierte los embeddings de PII en datos potencialmente personales bajo GDPR.
• Membership inference. Mediante consultas dirigidas, un atacante infiere si un documento concreto está indexado. En corpus sensibles, ese conocimiento ya es información valiosa.
• Data poisoning. Un atacante con acceso a la ingestion inserta vectores diseñados para dominar los resultados de ciertas consultas. La distancia coseno se manipula artificialmente y el fragmento atacante aparece como contexto en cada respuesta.
• Indirect prompt injection vía documentos indexados. La base vectorial es la puerta natural para instrucciones disfrazadas que el LLM ejecutará en runtime. Un documento legítimo con instrucciones ocultas en metadatos, comentarios HTML o alt text se convierte en vector de prompt injection persistente.
• Fuga de claves API. Las claves de Pinecone, Qdrant Cloud o Zilliz Cloud aparecen con frecuencia hardcoded en repositorios o notebooks públicos. Una clave filtrada concede acceso completo al índice.
• Autenticación débil por defecto. Qdrant local y Weaviate en modo dev arrancan sin autenticación. Más de un equipo asume binding local y termina exponiendo el puerto a la red corporativa o a internet.
• Exposición de red. Los puertos 6333 (Qdrant), 19530 (Milvus), 8080 (Weaviate) y 5432 (PostgreSQL con pgvector) aparecen expuestos accidentalmente. Shodan revela instancias accesibles sin autenticación con frecuencia.
• Cifrado en reposo no por defecto. Varios engines requieren configuración explícita para cifrar índices y payload. Una asunción equivocada se descubre tarde.
• Side-channels de logging. Los logs de queries pueden contener el texto plano de las consultas y, en modos verbosos, fragmentos del contenido recuperado. Esos logs viajan a sistemas de observabilidad rara vez tratados con la sensibilidad de los datos originales.

Patrones de multi-tenencia y sus riesgos

Cuando un despliegue sirve a varios clientes, departamentos o productos, la elección del patrón de aislamiento determina el modelo de amenazas.

• Colección compartida con filtro de metadatos. Todos los vectores conviven en la misma colección y se segregan con un campo tenant_id aplicado como filtro en cada consulta. Es el patrón más barato y el de peor aislamiento. Un fallo de validación en el filtro, una librería cliente que lo construye mal o una mutación del SDK terminan en cross-tenant access.
• Namespace o colección por tenant. Cada tenant tiene su propio namespace o colección dentro del mismo cluster. El aislamiento es mejor porque la API exige seleccionar el namespace y los filtros son menos críticos. La gestión escala peor: crear, migrar y monitorizar miles de namespaces requiere automatización propia.
• Cluster por tenant. Cada cliente tiene su propio cluster. Es el aislamiento máximo y permite cumplir requisitos de residencia y soberanía con menor riesgo. El coste de infraestructura y operación se dispara y obliga a control estricto de capacidad.

La regla práctica es seleccionar el patrón más restrictivo que la economía del producto permita, no el más laxo que la tecnología tolere. Un proveedor que ofrece RAG multi-tenant compartido sin contrato claro de aislamiento acumula deuda de seguridad para el primer pentest serio que reciba.

Embedding inversion attacks

La hipótesis intuitiva durante años fue que los embeddings eran representaciones opacas e irreversibles. La investigación académica entre 2023 y 2024 desmontó esa hipótesis para varias familias de modelos. Mediante optimización sobre el espacio de entrada y conocimiento del modelo de embeddings, es posible reconstruir aproximaciones del texto original, en algunos escenarios con fidelidad alta.

La implicación práctica es directa: si una base vectorial almacena embeddings derivados de datos personales y un atacante exfiltra los vectores, no basta con argumentar pseudonimización. El proceso es parcialmente reversible y los datos siguen siendo personales en el sentido del RGPD.

La defensa pasa por tratar los vectores como contenido sensible equivalente al original. Eso implica cifrado en reposo, control de acceso restrictivo, audit logging de exportaciones masivas y, cuando sea posible, uso de modelos de embeddings que añadan ruido controlado para dificultar la inversión, asumiendo el coste en calidad de retrieval.

Hardening básico Pinecone, Qdrant y Weaviate

Un plan de hardening realista comparte la mayoría de controles, con detalles específicos por engine.

• Autenticación obligatoria. Ningún engine debe arrancar sin auth, ni en desarrollo. Claves API rotadas con cadencia documentada, una clave por servicio consumidor y nunca una clave global compartida.
• TLS en tránsito y cifrado en reposo. Comprobar que ambos están activos y, en cloud, exigir el cifrado con clave gestionada por el cliente cuando el proveedor lo soporte.
• Aislamiento por namespace para multi-tenant. Preferir namespace o colección por tenant frente al filtro compartido. Si el filtro compartido es la única opción, blindar la capa de query con validación estricta y tests específicos.
• Control de acceso por metadata y row-level security. En pgvector, aprovechar el RLS nativo de PostgreSQL para forzar políticas por usuario. En engines sin RLS, propagar la identidad del usuario hasta el retriever y aplicar el filtro en el índice, no como post-procesado.
• Política de red restrictiva. Endpoint privado, VPC peering o PrivateLink. Nunca exponer el puerto a internet. Reglas de firewall que listen origen y destino y revisiones periódicas con herramientas de surface management.
• Rate limiting por clave. Limitar consultas por segundo y volumen de top-k devuelto. El rate limiting es la defensa más efectiva contra membership inference y reconnaissance.
• Audit logging integrado en el SIEM. Logs de queries, mutaciones, gestión de claves y cambios de configuración enviados a Splunk, Sentinel, Elastic o el SIEM corporativo. La retención debe permitir investigaciones forenses.
• Estrategia de backup. Snapshots cifrados, separados del cluster productivo, con plan de restauración probado. La pérdida de un índice de embeddings sin backup obliga a reembeddear el corpus entero, una operación cara y lenta.
• Integridad del modelo de embeddings. Fijar versión exacta del modelo, firmar el artefacto cuando se sirve self-hosted y validar el hash antes de cargar. La cadena de suministro de los modelos open source es un vector real.

A nivel específico, Pinecone exige una buena higiene de claves API y de control de proyectos. Qdrant requiere activar la autenticación por API key y limitar unauthenticated_anon, además de revisar puerto gRPC además del REST. Weaviate obliga a configurar AUTHENTICATION_APIKEY_ENABLED y los módulos de autorización si se usa multi-tenant.

Auditoría de seguridad de una base de datos vectorial

Una auditoría dirigida a la base vectorial cubre cuatro bloques de pruebas, con metodología repetible.

• Recon e inventario. Identificar engine, versión, modo de despliegue, puertos expuestos, configuración de TLS, mecanismos de auth, tipo de claves y permisos asociados, índices presentes, tamaño del corpus y modelo de embeddings utilizado.
• Test de aislamiento multi-tenant. Crear identidades en dos o más tenants y diseñar consultas que intenten cruzar el límite: filtros manipulados, valores límite, inyección en parámetros, abuso del SDK y carreras en la creación de namespaces. Documentar cada técnica probada y su resultado.
• Experimento limitado de embedding inversion. Sobre una muestra controlada y consentida, ejecutar un ataque de inversión académico para evaluar el grado de reversibilidad real con el modelo de embeddings utilizado. El objetivo no es romper el sistema, sino dar evidencia accionable al CISO sobre el riesgo residual.
• Supply chain y configuración. Revisar versiones del engine, dependencias, modelo de embeddings, librerías cliente y orígenes de la imagen contenedor. Comparar configuración real con baseline endurecido.

El entregable debe priorizar findings por explotabilidad e impacto regulatorio, y proponer remediación concreta por engine.

Encaje regulatorio

El marco regulatorio aplicable a una base vectorial no es exclusivo de la IA y depende del contenido indexado.

RGPD entra en juego siempre que los embeddings deriven de datos personales. La discusión abierta es si el embedding en sí mismo es dato personal. La posición prudente, dada la literatura sobre embedding inversion, es tratarlo como tal cuando el corpus original lo era. Esto implica base legal documentada, plazos de conservación, derecho al borrado que alcance a los vectores y a sus backups, y una evaluación de impacto cuando el riesgo sea alto.

El EU AI Act afecta a la base vectorial cuando alimenta un sistema clasificado como de alto riesgo. Un RAG que apoya decisiones de RR. HH., crédito, evaluación educativa o acceso a servicios esenciales arrastra a la vector database a las obligaciones de gobernanza, supervisión humana, registro de actividad y gestión de riesgos del sistema.

NIS2 aplica a entidades esenciales e importantes y, dentro de las obligaciones del artículo 21, exige gestión de riesgos de cadena de suministro. El engine de vector database y el modelo de embeddings son piezas de esa cadena, y su selección, monitorización y plan de respuesta a incidentes deben quedar formalizados.

Preguntas frecuentes

¿Un embedding es dato personal bajo GDPR?

La interpretación prudente es que sí cuando el texto origen era personal, dado que los embeddings de modelos generalistas son parcialmente invertibles. La AEPD no ha publicado guía específica, pero el principio de precaución aconseja tratarlos como dato personal y aplicar los mismos controles.

¿Es seguro un Pinecone multi-tenant compartido?

Lo es si los namespaces se usan correctamente, la identidad de cada tenant se propaga al retriever y las claves API se segregan por servicio. No lo es si todos los tenants conviven en la misma colección con un filtro de metadata aplicado por la aplicación cliente. Para datos regulados, conviene namespace por tenant o índice dedicado.

¿Pgvector vale lo mismo que Pinecone?

Para volúmenes medios y donde ya hay PostgreSQL, pgvector es perfectamente válido y aprovecha RLS, roles y políticas ya operadas por el equipo. Pierde frente a Pinecone en escalabilidad horizontal masiva y en tuning de índices a gran escala. La decisión debe responder a perfil de carga, no a moda.

¿Se puede borrar un embedding y cumplir el derecho al olvido?

Sí, todos los engines maduros soportan borrado por ID o por filtro. El reto operativo es asegurar que el borrado alcanza también a backups, snapshots, índices secundarios y copias derivadas. Sin un proceso formal, el borrado puede ser parcial y dejar al cumplimiento expuesto.

¿Cómo se testea el aislamiento de una base vectorial?

Con dos identidades en tenants distintos, una batería de queries para cruzar el límite y una matriz de técnicas: manipulación del filtro, parámetros límite, inyección en el payload, abuso del SDK y condiciones de carrera. Un test serio no cabe en una hora; lo razonable es entre dos y cinco días por engine y patrón de aislamiento.

¿Se puede auditar una base vectorial SaaS sin acceso al backend?

Sí, pero el alcance cambia. La auditoría se centra en configuración del tenant, gestión de claves, política de red, RBAC, audit logs y comportamiento observable de la API. Se complementa con revisión documental de los compromisos del proveedor (SOC 2, ISO 27001, addendum GDPR). La parte interna del engine queda fuera del alcance y debe reflejarse en el informe.

Recursos relacionados

• Seguridad de RAG: riesgos y controles
• OWASP LLM Top 10 explicado
• Seguridad de agentes IA autónomos: riesgos
• Seguridad MCP: Model Context Protocol
• Pentesting de modelos IA y LLM: metodología
• Pentesting cloud: AWS, Azure y GCP

Auditoría de base de datos vectorial con Secra

En Secra auditamos despliegues de bases vectoriales en producción con enfoque ofensivo y trazabilidad regulatoria. El servicio incluye revisión específica del engine elegido (Pinecone, Qdrant, Weaviate, Milvus, Chroma o pgvector), pruebas de aislamiento multi-tenant con dos o más identidades, experimento limitado de embedding inversion sobre muestra consentida, validación de la cadena de suministro del modelo de embeddings y recomendaciones de hardening priorizadas por explotabilidad e impacto. Si tu organización tiene un RAG corporativo, un buscador semántico o un agente con memoria a largo plazo apoyado en una base vectorial, podemos auditarlo. Escríbenos desde /es/contacto/ y coordinamos un diagnóstico inicial sin compromiso.