DeepSeek y la “base de datos expuesta”: cuando un chatbot filtra historial de chats por mala configuración

INTELIGENCIA ARTIFICIAL · SEGURIDAD · PRIVACIDAD

1) Qué pasó en el caso DeepSeek (y por qué debería importarte)

A finales de enero de 2025, investigadores de seguridad publicaron un hallazgo incómodo: una instancia de ClickHouse (base de datos muy usada para analítica y almacenamiento de logs) estaba expuesta en internet y se podía acceder sin autenticación. Lo más delicado: a través de la ruta /play (la interfaz web), se podían ejecutar consultas SQL directamente desde el navegador.

Dentro, había tablas de telemetría. Y una destacaba por encima de todas: log_stream. Ahí aparecían más de un millón de entradas con información que, en cualquier equipo serio, se considera “zona roja”: mensajes en texto plano (historial), referencias a endpoints internos, metadatos operativos y secretos (claves o tokens) que, si caen en malas manos, pueden convertir una filtración en una escalada.

Lo relevante no es el nombre del producto. Es el patrón: la empresa crece rápido, el chatbot explota en uso, el sistema se llena de logs y trazas… y alguien deja un puerto abierto “solo un momento”. Si ya te preocupa la privacidad y los puntos ciegos de los sistemas generativos, este caso encaja perfecto con los errores típicos al usar IA (privacidad, alucinaciones y más).

2) La idea clave: el chatbot “habla”, pero quien “recuerda” es otra cosa

Cuando piensas en un chatbot, imaginas esto: tú preguntas, el modelo responde y fin. En la realidad, una app de IA moderna es un conjunto de piezas:

Cliente (web/app)
  → API / Gateway
    → Servicio de chat (orquestación)
      → LLM (proveedor o modelo propio)
      → Observabilidad: logs / trazas / métricas
      → Almacenamiento: BD de chats + analítica (ClickHouse/ELK) + vector DB (RAG)
      → Gestión de secretos: keys, tokens, credenciales
    

La fuga “clásica” no pasa porque el modelo sea malicioso. Pasa porque alguien dejó expuesto el lugar donde se vuelcan los rastros: logs de peticiones, trazas de microservicios, respuestas parciales, errores, payloads completos “por si acaso”. Y esos rastros suelen contener justo lo que nunca deberías almacenar sin cuidado: el texto exacto de lo que el usuario escribió.

3) Por qué pasa tanto: logs, vectores y APIs son el triángulo de las fugas

A) Logs y trazas: el “modo debug” que se queda en producción

En IA se instrumenta muchísimo: latencia por token, prompts, respuestas, fallos de herramientas, rutas internas… El problema es que el “log útil” se convierte en “log peligroso” cuando incluye contenido en claro. Y cuando ese log vive en una base de datos de analítica (rápida, cómoda, consultable), el impacto se multiplica.

B) Vectores (RAG): embeddings que parecen inocuos… hasta que no

Si tu chatbot usa RAG, seguramente guardas documentos y fragmentos en una vector DB con metadatos (usuario, tenant, origen, timestamps). Aunque un embedding no sea “texto legible” como tal, la fuga del sistema de recuperación suele venir por otro lado: metadatos, endpoints sin auth, llaves compartidas, filtros mal aplicados. De ahí a un “cross-tenant” (ver datos de otro cliente) hay un paso.

C) APIs: la autopista de entrada… y a veces de salida

Una API mal protegida puede exponer historiales completos, endpoints internos, o incluso llaves en responses de error. El patrón típico: endpoints administrativos que nacieron para pruebas, CORS demasiado permisivo, tokens sin caducidad real, o “temporalmente sin login” para que el equipo de producto valide rápido.

4) Qué tipo de datos se “cuelan” en una fuga así

Cuando una base de datos de logs queda pública, lo que aparece no suele ser “un CSV aburrido”. Suele ser un mapa de tu sistema y, de regalo, contenido sensible. Por experiencia, lo que más se ve es:

• Texto en claro: prompts, respuestas, fragmentos recuperados del RAG, mensajes del sistema.
• Secretos: API keys, tokens de sesión, claves temporales pegadas en headers o errores.
• Rutas internas: nombres de endpoints, servicios, spans de tracing, estructura de microservicios.
• Metadatos “inofensivos”: user_id, tenant, timestamps, IPs, nombres de modelos y versiones.
• Detalles operativos: rutas de archivos, nombres de directorios, identificadores de colas, workers.

Y ojo: esto afecta tanto si consumes un proveedor externo como si montas tu propio stack. Si de verdad necesitas una IA más cerrada y controlable, te puede interesar explorar enfoques tipo chatbot privado con documentos en local, donde reduces superficie y dependencias (aunque sigues necesitando buenas prácticas).

5) Checklist de 7 puntos para que tu IA no filtre historiales “por accidente”

6) Un test rápido: “¿podría pasarnos mañana?”

Te dejo cinco preguntas para hacer en tu próxima reunión (o para hacerte tú mismo si vas solo). Si dudas en más de dos, merece la pena parar y revisar:

• ¿Dónde se guarda exactamente el historial: BD principal, logs, analítica, vector DB… o “todas a la vez”?
• ¿Tenemos alguna base o dashboard accesible desde internet “porque era cómodo”?
• ¿Alguien puede ver prompts/respuestas completas en herramientas internas sin necesitarlo?
• ¿Hemos visto alguna vez keys o tokens en logs (aunque fuera “solo una vez”)?
• ¿Podemos borrar un chat y estar seguros de que desaparece también de logs y backups razonablemente?

7) Cierre: la seguridad en IA no es “ponerle un candado al modelo”

El caso DeepSeek es un recordatorio muy útil porque no es ciencia ficción. Es el tipo de incidente que puede ocurrir en cualquier equipo que construya rápido, conecte muchas piezas y tenga presión por sacar producto.

Si estás desplegando asistentes, piensa así: tu riesgo no vive solo en el prompt. Vive en los logs que guardas “por si acaso”, en la base de analítica que expusiste “solo para mirarlo”, en el endpoint administrativo que nadie cerró, y en esa vector DB que asumiste que “ya viene segura”.

La buena noticia es que la mayoría de estas fugas se previenen con disciplina básica: inventario, aislamiento, autenticación, minimización y monitorización. No es glamuroso. Pero es exactamente lo que evita que el “historial de chat” acabe donde nunca debió estar: a la vista de cualquiera.