Una conversación aparentemente inocente bastó para sacar a un asistente comercial de su carril. El chatbot de la tienda oficial de la Real Federación Española de Fútbol terminó mostrando consultas SQL, estructuras de base de datos y hasta sugerencias para vender camisetas no oficiales.
El episodio no consiste solo en una respuesta extraña. Expone algo más delicado cuando un asistente conectado a inventarios, documentos internos o bases de datos entiende demasiado y filtra más de la cuenta, la frontera entre atención al cliente y fuga de información se vuelve muy fina.
Así acabó enseñando consultas que nadie debía ver
Un usuario de X fue empujando la conversación paso a paso hasta comprobar que el sistema abandonaba su función comercial. En lugar de limitarse a recomendar productos o resolver dudas de compra, el asistente empezó a comportarse como una herramienta técnica.
Entonces explicó cómo lanzar consultas SQL sobre una tabla de camisetas, con ejemplos para localizar tallas disponibles y niveles de stock. No era una simple rareza verbal, sino una pista de cómo estaba organizado el acceso a la información por debajo de la interfaz.
Después fue un poco más lejos y ofreció recomendaciones técnicas para montar una web de venta de camisetas con Python y FastAPI, una deriva que encaja con lo que ya muestran técnicas de prompting cuando el sistema no separa bien contexto, memoria y límites de uso.
El problema aparece cuando el asistente confunde ayuda con acceso
Lo llamativo no es que el chatbot respondiera mucho, sino que respondiera fuera de propósito. Un asistente de tienda debería moverse dentro de un perímetro claro y, sin embargo, aquí terminó revelando lógica interna y contenido impropio de un escaparate digital.
El caso muestra cómo una manipulación conversacional puede desviar la tarea original del sistema hasta convertir una interfaz de venta en una puerta de entrada a datos y funciones que no estaban pensados para el público.
Esa técnica suele describirse como prompt injection. La idea es sencilla en apariencia y bastante incómoda en la práctica el usuario no rompe el sistema desde fuera, sino que lo persuade desde dentro para que ignore sus instrucciones iniciales.
Las bases de datos conectadas multiplican el riesgo
Cuanto más útil es un asistente, más tentación existe de conectarlo a catálogos, inventarios y repositorios corporativos. Ahí gana rapidez para atender, pero también aumenta la superficie de exposición si la configuración falla o si los filtros no distinguen bien entre consulta legítima y exploración maliciosa.
En ese terreno trabajan los llamados red teamers, el nombre que usa la industria para quienes fuerzan deliberadamente a una inteligencia artificial con el fin de localizar vulnerabilidades. Su tarea consiste en probar los bordes antes de que lo haga alguien con menos paciencia y peores intenciones.
Ese trabajo ya tiene paralelos claros en la detección automática de fallos, donde el valor del sistema depende tanto de su capacidad para encontrar errores como de evitar que esos errores acaben convertidos en un manual de uso para atacantes.
Las grandes tecnológicas ya pelean con el mismo desvío
OpenAI, Google y Microsoft llevan tiempo destinando recursos a detectar intentos de manipulación y a bloquear respuestas problemáticas en modelos de lenguaje. No es una batalla secundaria, porque el éxito de estos asistentes depende menos de lo que saben que de cuándo deben callar.
Visto así, el incidente de la tienda no resulta anecdótico. Un chatbot capaz de enseñar consultas para revisar stock o de sugerir cómo levantar una tienda paralela de camisetas deja una imagen bastante concreta del problema una conversación puede parecer atención al cliente y acabar pareciéndose demasiado a una auditoría involuntaria.