Una plataforma que genera agentes de venta verticales, no un chatbot con respuestas armadas.

01Qué es, y qué no es

La diferencia que ordena todo el diseño es una sola, y no es técnica: un buscador espera que el cliente ya sepa lo que quiere. Un vendedor pregunta, entiende el caso y recomienda.

Casi todo lo que se ofrece hoy como “agente de IA para comercios” es un buscador con lenguaje natural: matchea texto contra un catálogo y devuelve resultados. Funciona cuando alguien escribe el nombre exacto de un producto, y se cae cuando alguien escribe “algo para mi perro que está viejo y no come bien”, que es como habla la gente.

Estos agentes están construidos alrededor de la conversación de venta: califican al comprador, recomiendan con criterio, arman el carrito, cierran el pedido contra el stock real y avisan al dueño. La consulta al catálogo es una pieza adentro de eso, no el producto.

02Arquitectura, a nivel de bloques

Multi-tenant real desde el diseño: un solo sistema atendiendo N negocios, no una copia del código por cliente.

• Un motor de venta único y versionado. Es el mismo para todos los clientes y nunca se edita para acomodar a uno. Lo que cambia entre un pet shop y una ferretería no es el código: es configuración.
• La identidad de cada negocio vive como configuración versionada — catálogo, tono, reglas propias del rubro, formas de pago y de entrega, datos de contacto. Se carga por pantalla, queda versionada y el agente la toma sin reiniciar nada.
• El agente no contesta de memoria. Antes de afirmar un precio, un stock o una disponibilidad, ejecuta una herramienta que consulta la base de datos del negocio en ese momento. Si la herramienta no confirma, no lo dice.
• Aislamiento entre negocios impuesto por la base de datos, no por la aplicación. Un error de programación en un endpoint no alcanza para que un negocio vea datos de otro. El detalle está en la sección 07.
• Un cerebro, varios canales. WhatsApp Business API y Telegram corren sobre el mismo motor. Sumar un canal es cablear una entrada y una salida, no reescribir la lógica de venta.
• Dos paneles separados. El del dueño del negocio (pedidos, productos, métricas, conversaciones, usuarios con permisos granulares y auditoría) y el de administración de la plataforma, que es desde donde se da de alta y se configura un cliente nuevo.
• Proveedor de modelo intercambiable. El modelo de lenguaje se cambia con una variable de entorno, y volver atrás es la misma variable. Ya se hizo en producción sin tocar una línea de la lógica de venta.

Stack: Python, PostgreSQL, Nginx, procesos bajo supervisor, servidor propio. Hoy hay 14 servicios corriendo en producción. Cómo están vigilados, respaldados y aislados va en la sección 07.

03La línea que divide el producto: qué garantiza el código y qué depende del modelo

Esta es la decisión de ingeniería más importante del proyecto, y la que probablemente ningún proveedor te va a poner por escrito.

Un modelo de lenguaje no es determinístico: acierta una vez y falla la siguiente con la misma entrada. Por lo tanto, todo lo que no puede fallar nunca no se le puede pedir por escrito al modelo: tiene que estar garantizado por código, fuera de su alcance.

El recorrido del proyecto lo demuestra sin discusión: cada una de las garantías de la columna izquierda empezó como una instrucción escrita en el prompt, y cada una volvió a fallar hasta que se movió al código. Ninguna de las que se movió al código volvió a fallar. Ninguna de las que quedó escrita dejó de fallar.

04El catálogo: dónde está el problema real

El problema no es guardar muchos productos. Es que el agente los conozca todos sin que la conversación se vuelva impagable ni el modelo se pierda.

El techo que casi nadie muestra

Casi todas las implementaciones que circulan meten el catálogo dentro del contexto del modelo. Con veinte productos anda perfecto. Con doscientos, empieza a recortarse en silencio: no hay error, no hay alerta, simplemente hay productos que el agente deja de saber que existen y nunca ofrece. El dueño no se entera nunca — lo único que ve es que no vende.

Medido sobre un catálogo sembrado de 200 líneas antes de resolverlo: 63 productos quedaban invisibles, un 32% del catálogo. Entre ellos, el más caro.

Cómo está resuelto hoy

El agente navega el catálogo en lugar de recibirlo entero: baja por rubro y subrubro hasta el nivel de detalle que la consulta necesita, y nunca devuelve una respuesta vacía — si no reconoce el filtro, devuelve el mapa para poder repreguntar. El resultado se midió contra dos catálogos reales, corriendo cada escenario cinco veces:

Lo difícil de verdad: el vocabulario del comprador

Resuelto el volumen, queda el problema caro, que es de idioma y no de arquitectura: el comprador no escribe el nombre del producto. Escribe “pichicho”, “planchita”, “jarra eléctrica”, “termo para tereré”. Hay literatura académica de cuarenta años sobre esto — dos personas eligen la misma palabra para la misma cosa menos del 20% de las veces — y las plataformas grandes lo resuelven con volúmenes de tráfico que un comercio de barrio no va a tener nunca.

Es la línea de trabajo principal hoy, y el enfoque es el que corresponde al tamaño del cliente: el sistema propone y una persona confirma, con el trabajo de análisis centralizado en nosotros para que al dueño del negocio le lleguen pocas propuestas y buenas, en vez de una lista que no va a mirar.

05Entrada de datos e integración con sistemas existentes

El punto en el que casi todo proyecto de este tipo se muere: nadie va a cargar su catálogo dos veces.

Y el riesgo no es el que parece. Una foto vieja es un detalle; un precio viejo es una venta mal cobrada. Por eso el problema real no es importar una vez, es mantener sincronizados precio y stock. La estrategia es una escalera de tres escalones, deliberada:

06Dónde corre y con qué se conecta

Dos preguntas que aparecen enseguida cuando quien lee administra infraestructura ajena. Las dos tienen respuesta clara, y ninguna de las dos es “sí” a secas.

¿Puede correr en la infraestructura del cliente?

El sistema no está atado a ninguna nube propietaria: Linux, PostgreSQL, Nginx y procesos supervisados, sobre servidor propio. No hay plataformas cerradas en el medio. Desplegarlo en otra infraestructura es un problema de operación, no de arquitectura.

Pero “local” tiene tres capas, y conviene separarlas porque solo dos dependen de nosotros:

Dos precisiones sobre los datos, que suele ser el fondo real de la pregunta:

• Los datos del negocio no se comparten con nadie. Catálogo, precios, stock, pedidos y clientes viven en la base, aislados por negocio a nivel de motor de base de datos. Lo único que sale es el texto de la conversación hacia el proveedor del modelo.
• La cuenta con el proveedor del modelo es del cliente, no nuestra. Ve su propio consumo y puede revocar el acceso cuando quiera, sin pedirnos permiso. No hay una caja negra intermedia. Y se contrata siempre en plan pagado, donde el contenido no se usa para entrenar modelos: es una condición del alta, no un detalle de configuración.

¿Tiene API?

Hay que separar consumir de exponer.

• Consume APIs de terceros, y eso está en producción: WhatsApp Business API, Telegram y el proveedor del modelo. Integrar con servicios externos es parte del funcionamiento normal, no un experimento.
• No expone una API pública propia. Hoy no hay forma de que un sistema externo opere la plataforma desde afuera. Está así por orden de prioridades, no por imposibilidad: se puso detrás de que exista un socio real que la pida sobre un caso concreto, porque una API diseñada sin saber contra qué se va a usar se rediseña entera la primera vez que alguien la usa de verdad.

Y dos cosas concretas para quien quiera integrar hoy:

07Seguridad

Un agente que atiende compradores maneja datos de terceros y opera sobre el stock y los precios de un negocio. Lo que sigue es específico a propósito: ante alguien del oficio, “usamos los más altos estándares” es lo que dice el que no tiene nada que mostrar.

Aislamiento entre negocios

Es el riesgo número uno de cualquier sistema multi-cliente, y el que peor se ve cuando falla.

• El identificador del negocio viaja firmado dentro del token de sesión, nunca como parámetro. Ningún endpoint lo acepta desde afuera, así que no hay forma de pedir los datos de otro cambiando un número en la URL.
• El aislamiento lo impone el motor de base de datos, no la aplicación: 21 tablas con seguridad a nivel de fila y 42 políticas activas. Un error de programación en un endpoint no alcanza para filtrar datos de un negocio a otro — la base rechaza la consulta igual.
• Cinco usuarios de base distintos, uno por servicio, con permisos mínimos. El proceso que atiende WhatsApp no puede hacer lo que puede el panel, y ninguno de los dos puede borrar histórico. Un servicio comprometido no entrega el resto del sistema.
• Probado ejecutando, no por lectura: con el usuario del cliente y sin negocio fijado se ven cero filas; con un negocio fijado se ven únicamente las suyas; pedir las de otro devuelve vacío, no error. Se verifica con consultas reales, no leyendo el código.

Acceso y permisos

• Contraseñas con bcrypt y factor de costo 12. No se guardan en texto plano ni se pueden recuperar: se reponen.
• Sesiones con token firmado y vencimiento; alta de empleados con contraseña temporal de un solo uso y cambio forzado en el primer ingreso.
• Los permisos se aplican del lado del servidor, no del navegador. Que un botón no se dibuje no es un control: el control es que el servidor rechace la operación — y ese rechazo queda auditado, así que un intento de hacer algo fuera de permiso deja rastro.
• Cambiar los permisos de un empleado invalida su sesión activa en el acto, no en el próximo ingreso. Lo mismo al desactivarlo o reponerle la clave.
• Límite de intentos en el ingreso y límite global de peticiones por minuto.

Rastro y no repudio

• El registro de auditoría es de solo agregado a nivel de base de datos: ni la propia aplicación tiene permiso para borrarlo o reescribirlo. Si alguien discute qué pasó, el registro es incuestionable porque nadie lo pudo tocar.
• Cada pedido guarda quién lo confirmó, lo entregó o lo canceló, con el nombre congelado en el momento — sobrevive a que ese empleado después se dé de baja.
• Descartar no borra: marca. El histórico es evidencia, no un listado de pendientes.

Secretos y terceros

• Los tokens de plataformas externas se guardan cifrados en la base, no en texto plano. Restaurar un respaldo sin la clave de cifrado no alcanza para usarlos.
• Credenciales fuera del código y de cualquier repositorio, en archivos con permisos restringidos al usuario que los necesita.
• Cada webhook entrante se valida con firma criptográfica. Un mensaje que no venga firmado por el proveedor se descarta sin procesarse: no se puede inyectar una conversación falsa desde afuera.
• Los cambios pasan por una revisión de seguridad antes de desplegarse; es parte del procedimiento, no un extra.

Superficie expuesta y continuidad

• Ningún servicio de aplicación está expuesto a internet. Los siete escuchan solo en loopback y lo único publicado es el proxy inverso, con HTTPS y renovación automática de certificados.
• Firewall con tres puertos abiertos y nada más y bloqueo automático de intentos de fuerza bruta. El acceso administrativo es únicamente por clave criptográfica: la autenticación por contraseña está deshabilitada y el usuario root no puede iniciar sesión, así que la fuerza bruta contra contraseñas no tiene contra qué correr.
• Cabeceras de seguridad y bloqueo de rutas de scanners conocidos en todos los sitios.
• Respaldo diario de las bases con copia fuera del servidor, y las claves de cifrado resguardadas por separado — porque un respaldo cuya llave se perdió no es un respaldo.
• Vigilancia automática cada 5 minutos que avisa cuando algo se cae y también cuando se recupera. Lo segundo suena a detalle y no lo es: sin el aviso de recuperación, un corte de seis segundos se lee como tres horas de caída, y ya nos pasó.

08Cómo se prueba (y por qué esto es la mitad del producto)

Con un componente no determinístico adentro, la pregunta no es “¿anda?”. Es “¿cómo me entero el día que deje de andar?”.

• 32 baterías de prueba automáticas. La mayoría corre sin llamar al modelo: cuestan cero, se corren las veces que haga falta y verifican las garantías de la columna izquierda de la tabla anterior.
• Todo caso que pasa por el modelo se corre cinco veces, no una. Es el criterio que usa la literatura de referencia para agentes con herramientas, y la razón es dura: un modelo de primera línea, en tareas de comercio, resuelve bien poco más de la mitad de los casos en un intento, y la cifra se desploma cuando se exige que acierte varias veces seguidas. Una sola corrida en verde no prueba que algo funcione: prueba que funcionó esa vez.
• Cada prueba lleva su propia prueba de que puede fallar. Se corre a propósito contra una versión rota del sistema y se exige que la detecte. Sin eso, una batería en verde puede simplemente ser incapaz de ver el error, que es la peor forma de falsa seguridad.
• Un detector que conversa solo, dos veces por semana. Un modelo hace de comprador con un objetivo fijo y redacción libre; conversa con el agente de punta a punta; y el veredicto lo da la base de datos, no otro modelo: se verifica que el carrito, el pedido y el stock hayan quedado exactamente como debían. Hoy son 5 escenarios completos con 65 comprobaciones, y avisa por mensaje encuentre o no encuentre algo — un vigilante que solo habla cuando hay problemas es indistinguible de un vigilante muerto.

Dato de la última medición completa de conversación: 123 casos, cada uno corrido 5 veces. 121 dieron resultado idéntico las 5 veces. Ninguno roto. Los 2 restantes están identificados y son de calidad de venta, no de integridad de datos.

09Un motor, tres verticales

La prueba de que es una plataforma y no un producto único es que ya genera verticales que no se parecen entre sí.

10Estado real, sin maquillaje

Lo que corre hoy y lo que todavía no. Separado a propósito, porque mezclarlo es la forma más rápida de perder credibilidad con alguien que va a probarlo.

Ese último renglón es, con distancia, el más honesto del documento: el cuello de botella para escalar no es técnico, es de criterio. Cargar doscientos productos lleva una tarde. Darse cuenta de que una pregunta mal formulada al comprador le hace llevar el producto equivocado, no lo detecta ningún formulario. Ahí es donde está puesto el esfuerzo hoy.

11Para una empresa que ya instala sistemas en comercios

El encaje más natural no es como cliente. Es como canal.

Quien ya entra a un comercio a instalar y capacitar tiene resuelto lo que a nosotros nos cuesta caro: la relación, el conocimiento del negocio y la presencia para el alta. Y a la inversa, un agente de venta 24/7 es un producto recurrente que se apoya exactamente sobre el sistema que ya instaló.

Y lo más concreto: la conexión directa al CRM de la sección 05, que en el caso general no cierra, con un socio que estandariza el sistema en su cartera pasa a ser un trabajo acotado y con sentido económico. Es la conversación que vale la pena tener primero, porque define el orden de todo lo demás.