Sistema en producción · dos instancias
Un mismo motor atiende clientes por WhatsApp en dos negocios distintos —una mercería y una agencia de viajes— con modelos de lenguaje que corren en el servidor propio. Ninguna conversación viaja a un proveedor de IA.
2
instancias del mismo motor en negocios distintos
0
conversaciones enviadas a servicios de IA externos
15 min
sincronización incremental del catálogo
3 en 1
búsqueda exacta, vectorial y de texto completo, fusionadas
Todo lo que implica entender al cliente ocurre dentro del servidor. Lo único que sale es la respuesta, por el canal oficial de WhatsApp.
Mensaje o nota de voz
Llega por la API oficial de WhatsApp; si es audio, se transcribe en local.
Híbrida y fusionada
Coincidencia exacta, similitud vectorial y texto completo en español, combinadas por RRF.
Respuesta con modelo local
El modelo de chat corre en el servidor propio, con el catálogo real como contexto.
Puntaje y siguiente paso
Scoring determinista del prospecto y recomendación de la siguiente acción.
Relevo a una persona
Cuando toca cerrar o el caso se sale del guion, la conversación pasa a un vendedor.
Dos negocios muy distintos tenían el mismo cuello de botella: WhatsApp. Una mercería que responde consultas de catálogo todo el día y una agencia de viajes en Chiapas que cotiza paquetes a mano, mensaje por mensaje, con el vendedor copiando datos entre pantallas.
El primer agente se construyó para la mercería. Cuando la agencia planteó su necesidad, la pregunta no fue «¿lo hacemos otra vez?», sino «¿el motor aguanta ser instanciado?». Se levantó la segunda instancia siguiendo una guía de portabilidad escrita para eso, no copiando y pegando el proyecto anterior.
En los dos casos el requisito de partida fue el mismo y no era negociable: las conversaciones con clientes no salen del servidor propio.
IA local o nada: ni una conversación ni un catálogo salen de la máquina.
Delegar la atención a un servicio de IA en la nube resuelve el problema técnico y abre otro: cada mensaje de un cliente —con sus datos, sus dudas y su intención de compra— pasa a manos de un tercero. Para un negocio pequeño esa es información competitiva y personal a la vez.
El segundo problema es de calidad de respuesta. Un modelo suelto que «sabe» del catálogo por memoria inventa referencias que no existen, y en una mercería con miles de claves eso significa prometer un producto que nadie puede entregar.
Y el tercero es de rol: un bot que cotiza por su cuenta y le manda un número al cliente puede comprometer al negocio con un precio que el vendedor no aprobó.
Chat y vectores corren con modelos locales sobre el servidor propio. Las notas de voz se transcriben también en local, con un motor compilado para aprovechar la aceleración del hardware y corriendo como servicio permanente.
psychology Porque la promesa «tus conversaciones no salen de aquí» solo vale si no hay ninguna excepción. Una sola llamada externa para transcribir audio rompería la garantía entera, y es justo la parte donde más datos personales viajan.
Cada respuesta se apoya en una búsqueda que combina coincidencia exacta de clave, similitud vectorial y búsqueda de texto completo en español, fusionando los tres rankings. El catálogo se sincroniza cada 15 minutos y solo se vuelven a calcular los vectores de lo que cambió, comparando hashes.
psychology La coincidencia exacta resuelve cuando el cliente escribe una clave; la vectorial, cuando describe lo que quiere con sus palabras; el texto completo, cuando usa el término del oficio. Ninguna de las tres gana siempre, así que se fusionan en vez de elegir.
En la agencia de viajes, el agente no genera el PDF de cotización ni le manda precios al cliente. Arma el estado del formulario y crea el expediente por API en el cotizador real, para que el vendedor recalcule con el motor bueno y cierre él.
psychology Un segundo motor de precios en el bot sería un segundo lugar donde el precio puede estar mal. Además, lo que se le manda a un cliente con el nombre del negocio encima lo tiene que aprobar una persona del negocio.
El webhook aceptaba peticiones sin comprobar su firma. La corrección se hizo en dos despliegues: primero midiendo con entregas reales, después exigiendo la firma.
psychology El modo estricto mal configurado no falla ruidosamente: deja al bot sordo en silencio, el canal reintenta y termina desactivando el webhook. Encender la verificación a ciegas habría cambiado un agujero de seguridad por una caída difícil de diagnosticar.
El motor corre en Node con Express y se apoya en PostgreSQL con extensión vectorial: el mismo lugar guarda el catálogo, los vectores y el estado comercial de cada conversación. No hay una base aparte para «lo de la IA».
Sobre esa base hay una capa comercial deliberadamente aburrida: puntaje del prospecto con reglas deterministas, recomendación de la siguiente acción, y relevo a una persona cuando el caso lo pide. Nada de eso depende del modelo de lenguaje, y por eso se comporta igual todos los días.
La segunda instancia demostró que el motor era portátil: se levantó siguiendo una guía escrita para instanciarlo, con su propio catálogo, su propio tono y su propia integración —en su caso, contra el cotizador del tour operador— sin bifurcar el código en dos proyectos que después habría que mantener por separado.
El incidente de seguridad se cuenta en abstracto, sin fechas ni detalles de exposición, como manda la regla de publicación del proyecto.
Que «IA local» es una decisión de producto antes que técnica. Es más trabajo y menos comodidad, y a cambio permite decirle a un cliente algo que casi nadie puede decirle: sus conversaciones no están en el servidor de otra empresa.
Que la parte que más valor da no es el modelo, es la búsqueda. Un modelo mediano con buen contexto responde mejor que uno grande adivinando, y además se puede explicar por qué respondió lo que respondió.
Y que endurecer la seguridad también necesita su escalera. Activar de golpe una verificación en un canal que reintenta y castiga el silencio puede tumbar el servicio; medir primero costó un despliegue extra y evitó una caída.