Un supermercado quiso ayudar a sus clientes a aprovechar las sobras. Terminó, sin proponérselo, publicando instrucciones para fabricar gas de cloro en la cocina de la casa. El caso del «Savey Meal-bot» de Pak'nSave es uno de los ejemplos más limpios que existen de una verdad incómoda: el modelo hizo exactamente lo que se le pidió, y aun así el resultado fue un desastre. Lo que falló estaba antes, en el proceso.
La cronología
Día 0. Pak'nSave, cadena de supermercados de Nueva Zelanda perteneciente al grupo Foodstuffs, lanza el «Savey Meal-bot»: una aplicación con IA generativa pensada para un problema doméstico y simpático. Tú escribes los ingredientes que te sobraron en la refrigeradora, el bot te devuelve una receta. Es la clase de proyecto que en cualquier comité interno se aprueba en quince minutos: bajo riesgo aparente, alto valor de marca, cero fricción con el negocio principal. La herramienta acepta texto libre del público general.
Día 1. Los usuarios descubren que el campo de ingredientes no distingue entre comida y cualquier otra cosa que haya bajo el fregadero. El bot propone una «mezcla de agua aromática» —descrita como «perfecta para saciar la sed y refrescar los sentidos»— que en realidad produce gas de cloro. También genera un «arroz sorpresa con lejía». Las capturas circulan y el caso salta de las redes locales a la prensa internacional.
Horas después. La respuesta oficial de la empresa apunta a «una pequeña minoría» de usuarios que habrían usado mal la herramienta. La corrección técnica se traduce en un aviso: que cada quien use su propio juicio antes de preparar lo que el bot sugiera.
Cuando un sistema acepta cualquier entrada del público, alguien tiene que diseñar sus límites antes del lanzamiento, y ese alguien no es el usuario.
Qué pasó, en detalle
El Savey Meal-bot funcionaba con una premisa razonable y un supuesto falso. La premisa: un modelo de lenguaje es muy bueno combinando ingredientes en recetas plausibles. El supuesto falso: que quien escriba en la caja de texto va a escribir ingredientes.
Un modelo generativo no verifica la naturaleza de lo que recibe. Recibe una lista de sustancias y devuelve la forma que se le pidió: una receta, con su nombre apetitoso, su descripción sensorial y sus pasos. Si la lista incluye cloro y amoníaco, el modelo no siente alarma; produce el mismo objeto literario que produciría con tomate y albahaca, porque su trabajo es la forma, no la seguridad química. De ahí sale una «mezcla de agua aromática» presentada como refrescante, y de ahí sale un «arroz sorpresa con lejía». El lenguaje seductor no es un fallo adicional: es el producto funcionando según su diseño. Le pediste una receta atractiva y te dio una receta atractiva.
La cobertura en The Guardian documenta tanto las sugerencias como la reacción de la empresa. Y esa segunda parte es la más instructiva para cualquiera que esté por lanzar algo parecido. Atribuir el problema a una minoría de usuarios que hicieron mal las cosas describe correctamente lo que ocurrió y, al mismo tiempo, evade la pregunta que importa: ¿quién era responsable de anticipar que eso ocurriría? Un formulario abierto al público entero recibe, por definición, todo el espectro del público: curiosos, bromistas, gente probando los bordes y gente que sinceramente no sabe qué mezcla es peligrosa. La respuesta «use su propio juicio» traslada al usuario final una tarea que era del diseñador del producto.
Por qué pasó
Nada de esto es un fallo del modelo. El modelo cumplió su especificación con precisión. El fallo está en un eslabón anterior: nadie definió qué entradas eran aceptables y qué salidas eran publicables.
En términos de negocio, el sistema se armó con una sola pieza donde hacían falta tres. La pieza que estaba es el generador: convierte ingredientes en recetas. Las dos que faltaban son el filtro de entrada —una lista de lo que sí cuenta como alimento, con rechazo explícito de todo lo demás— y el filtro de salida —una revisión de la receta generada contra un catálogo de combinaciones prohibidas antes de mostrarla en pantalla. Sin la primera, el usuario define el universo del sistema. Sin la segunda, el sistema publica sin que nadie lea.
Hay un tercer elemento, más sutil, que explica por qué el resultado fue tan vistoso: el bot tenía permiso implícito para hablar de cualquier cosa. No se le declaró un dominio. Un asistente al que se le dice «eres un generador de recetas» sin más entiende que su tema es infinito mientras se le llame receta. Uno al que se le declara «tu catálogo son estos 12.000 productos del supermercado, y fuera de ese catálogo no existes» tiene un piso y un techo. La diferencia entre ambos no es el modelo: es cuánto trabajo de definición se hizo antes de conectarlo.
El bot llamó «mezcla de agua aromática» a una combinación que produce gas de cloro, y la describió como perfecta para saciar la sed.
Dónde te puede pasar a ti
El detalle del cloro hace que el caso parezca ajeno: nosotros no vendemos recetas. Pero el mecanismo —una caja de texto abierta al público conectada a un generador sin límites declarados— es exactamente el mismo que hoy corre en decenas de empresas medianas de la región.
- El bot de atención en WhatsApp. Si le preguntan por un producto que no vendes, ¿dice que no lo tiene o improvisa una descripción? Un cliente que pregunta por un servicio que dejaste de ofrecer hace dos años puede recibir una explicación entusiasta de cómo funciona ese servicio, con tiempos de entrega inventados.
- Las cotizaciones automáticas. Un asistente que arma precios «razonables» a partir de lo que aprendió, en vez de leerlos de tu tabla de tarifas, va a producir números plausibles. Plausible no es correcto, y un descuento inventado que el cliente ya vio por escrito es difícil de retirar.
- La cobranza y los mensajes de mora. Un generador que redacta libremente puede prometer una condonación, un plan de pagos o una fecha que nadie autorizó. Eso ya no es un problema de tono: es una comunicación con efecto comercial y, en algunos países, legal.
- El contenido y las descripciones de producto. Fichas generadas en lote pueden atribuirle a un producto una certificación, un uso médico o una compatibilidad que no tiene. Nadie lo nota hasta que un cliente lo reclama.
La pregunta incómoda, entonces: si hoy alguien le escribe a tu bot algo que tú nunca imaginaste, ¿existe una regla que lo detenga, o dependes de que el usuario se comporte como esperabas?
Cómo se evita
1. Declara el dominio de manera explícita y cerrada. No alcanza con decirle al asistente de qué habla; hay que decirle qué no existe para él. La regla operativa es «lo no declarado no existe»: si un producto, un precio o un servicio no está en la lista que le diste, la respuesta correcta es «no manejo eso, te comunico con una persona». Se implementa esta semana escribiendo el catálogo de capacidades en un documento y conectándolo como única fuente.
2. Valida la entrada antes de que llegue al modelo. Una lista de términos permitidos, o al menos una de términos vetados, filtrando el texto del usuario antes de generar nada. En el caso de Pak'nSave habría bastado con verificar que cada ingrediente estuviera en el catálogo del supermercado. En tu bot equivale a rechazar consultas fuera de tema en vez de dejar que el generador las resuelva.
3. Revisa la salida antes de publicarla. Toda respuesta pasa por un segundo chequeo —reglas fijas o un segundo modelo con criterio de auditor— que la compara contra las prohibiciones del negocio: no prometer plazos, no inventar precios, no dar consejo médico o legal, no mezclar categorías incompatibles. Si no pasa, no se muestra.
4. Escribí y ejecuta una prueba de abuso antes del lanzamiento. Sienta a tres personas del equipo durante una hora con la instrucción de romper el sistema a propósito. Anota cada respuesta indebida como caso de prueba. Ese ejercicio, hecho antes, es la diferencia entre un hallazgo interno y una nota en la prensa.
5. Definí de antemano el camino de escalada y el botón de apagado. Qué señales llevan la conversación a un humano —enojo, insistencia, tema fuera de catálogo, monto por encima de un umbral— y quién puede desactivar el bot en un minuto sin esperar a un proveedor. Ambas cosas se deciden antes, no durante la crisis.
Cómo lo hacemos en Catalizadora
En Cortex, nuestro motor de bots, las capacidades se declaran explícitamente y lo que no está declarado no existe: si el cliente pregunta por algo fuera del catálogo, el bot no improvisa, deriva. Los precios y las condiciones no salen nunca de la memoria del modelo, sino de las tablas del propio cliente —el mismo candado que impide que un asistente invente una tarifa impide que invente un producto—. Y la escalada a un humano se dispara por señales definidas de antemano, no por el criterio del momento.
Atlas guarda el registro completo e inalterable de cada conversación. Eso importa precisamente en casos así: cuando algo sale mal, la diferencia entre «una minoría de usuarios» y un diagnóstico real es tener el historial completo para saber qué se preguntó, qué se respondió y cuántas veces pasó.
La regla, en una línea: un sistema que acepta cualquier entrada necesita sus límites escritos antes del lanzamiento, porque el usuario no los va a poner por ti.
Este es uno de los casos documentados en nuestra hemeroteca de fallas de IA. Todos con su fuente enlazada, y todos con la misma conclusión: el problema casi nunca es el modelo.