La pregunta que frena a casi todo negocio antes de poner un bot de inteligencia artificial a atender clientes es siempre la misma: «¿y si se equivoca?». Y es una pregunta correcta, porque un modelo que cotiza mal cuesta plata y credibilidad. Lo que casi nadie explica es que esa pregunta tiene una respuesta arquitectónica, no una respuesta de fe: se diseña el sistema para que la inteligencia artificial nunca pueda equivocarse en lo que importa. Este es el principio con el que construí un sistema que toma pedidos y cobra por WhatsApp, y la razón por la que se puede vender con garantías en lugar de con esperanza.
La idea que ordena todo: la IA nunca tiene el control. Se le delegan tareas acotadas de interpretación (entender qué quiere alguien, reconocer productos de un catálogo conocido, leer un número de un comprobante) y el código determinista se queda con todo el dinero: los precios, los totales, el resumen, la confirmación, los cambios de estado. No es una postura filosófica, es ingeniería de riesgo: se diseña para que todos los errores posibles del modelo caigan en la categoría barata.
¿Puede un bot de IA cobrar sin equivocarse?
Sí, si la IA no calcula el dinero. El patrón seguro le delega solo interpretación (clasificar la intención, reconocer productos de un catálogo, transcribir un comprobante) mientras el código determinista calcula precios, totales y confirmaciones. Como el modelo queda fuera del camino del dinero, su peor falla produce una repregunta, nunca un precio equivocado.
| Tarea | Quién la hace | Si falla, qué cuesta |
|---|---|---|
| Entender qué quiere el cliente | IA (clasificar intención) | Una repregunta |
| Reconocer productos del catálogo | IA (extraer contra lista conocida) | Una repregunta |
| Leer el monto de un comprobante | IA (transcribir) | Una revisión humana |
| Calcular precios y totales | Código determinista | No puede fallar por el modelo |
| Confirmar el pedido y cobrar | Código determinista | No puede fallar por el modelo |
| Cambiar de etapa o pasar a humano | Código determinista | No puede fallar por el modelo |
La columna de la derecha es el punto entero del diseño. Un modelo que se equivoca clasificando cuesta un mensaje de más; uno que se equivoca cotizando cuesta dinero y confianza. Todo el sistema está construido para que solo pueda ocurrir lo primero.
Qué se le delega a la IA (y por qué solo eso)
En el sistema que construí, el modelo hace exactamente tres cosas. Clasifica la intención de un mensaje, es decir, decide si alguien está saludando, pidiendo, preguntando por su pedido o quejándose. Extrae productos de lo que escribió el cliente, pero siempre contra un catálogo conocido, no inventando referencias. Y transcribe el monto de la imagen de un comprobante de pago. Nada más.
Lo que tienen en común esas tres tareas es que son de interpretación de lenguaje, que es donde un modelo es genuinamente mejor que cualquier regla que uno escriba. Y lo que tienen en común sus fallas es que son recuperables: si clasifica mal, el sistema repregunta; si no reconoce un producto, repregunta; si lee mal un comprobante, un humano lo revisa. Ninguna de esas fallas puede llegarle al cliente convertida en un precio incorrecto, porque el precio no pasa por ahí.
La prueba más dura: correr con el modelo apagado
Un principio que no se prueba es un deseo. La forma de verificar que la IA de verdad está fuera del camino crítico es brutalmente simple: correr toda la suite de pruebas de conversación sin la clave de la API. Sin ella, cada llamada al modelo falla y devuelve vacío, y el sistema tiene que seguir funcionando. Con el modelo caído, el flujo no revienta ni improvisa: degrada a repreguntas y a un pase a una persona.
Eso no es una limitación del test, es exactamente lo que el producto promete. Si el sistema solo funciona cuando el modelo responde bien, entonces el modelo está en el camino crítico y la promesa de fiabilidad es falsa. Si el sistema sobrevive al modelo apagado, la promesa es verificable. Esa es la diferencia entre decir «es confiable» y poder demostrarlo, que es justamente lo que exige automatizar con criterio.
Tres lecciones que solo aparecen en producción
Nunca cobrar cero: el precio sale de una función, no de un campo
Un producto con precios por porciones tenía el campo de precio suelto en cero, y al imprimir la carta se leía ese campo: el cliente vio un producto a cero pesos. La regla que quedó grabada es que el precio siempre sale de la función que conoce todos los modos de cobro, nunca de un campo directo. Y cuando no se puede cotizar algo, la respuesta correcta es una lista vacía, no un cero. Porque vacío significa «no puedo cobrar esto todavía», y cero significa «es gratis». Un sistema que confunde ambas cosas regala producto.
Sin datos, no confirmar: la entrega a 200 kilómetros
Sin zonas de cobertura configuradas, el bot confirmó un domicilio a más de doscientos kilómetros del negocio, con el envío en cero pesos. El error no fue del modelo, fue del diseño: el sistema asumía que si no había restricción, todo estaba permitido. La regla que quedó es la inversa: sin zonas declaradas, el bot no confirma domicilios, pasa a una persona. Un valor por defecto que permite todo es una bomba de tiempo; el defecto seguro es no decidir y escalar.
No contradecir a quien ya pagó
Al probar la lectura de comprobantes con una imagen legible pero atípica, el modelo respondió que eso no era un comprobante. Si esa respuesta le llegara al cliente, el día que el modelo se equivoque con una captura real le estaríamos diciendo a alguien que ya pagó que no pagó. El cambio fue quitar esa respuesta del camino del cliente: ese caso no le dice nada a quien escribió y solo deja una nota para el equipo. Es el principio otra vez, aplicado al detalle: la falla del modelo puede costar una revisión, nunca una acusación.
Cómo se diseña un sistema así
- Lista todo lo que el sistema decide: precios, totales, confirmaciones, cambios de estado, envíos, escalamientos. Esa lista es tu inventario de riesgo.
- Marca lo que toca dinero o es irreversible: todo eso queda en código determinista, sin excepciones. Si una decisión no se puede deshacer, no la toma un modelo.
- Delega a la IA solo interpretación de lenguaje: entender, clasificar, extraer contra listas conocidas, transcribir. Tareas donde el modelo aporta de verdad y su error es recuperable.
- Define la degradación: qué pasa cuando el modelo falla o no está. La respuesta correcta siempre es repreguntar o pasar a un humano, con disparadores deterministas, nunca improvisar.
- Pruébalo con el modelo apagado: corre el flujo completo sin API. Qué ocurre después: si sobrevive, tienes un sistema que puedes garantizar; si no, sabes exactamente qué dependencia crítica tienes que sacar del camino del dinero.
Cuándo NO aplica este patrón
Hay casos donde encerrar a la IA de esta forma es innecesario. Si el bot no toca dinero ni toma decisiones irreversibles, por ejemplo un asistente que solo responde preguntas frecuentes o resume información interna, el nivel de rigor puede ser menor: su peor falla es una respuesta imprecisa, no un cobro mal hecho. Y si lo que buscas es exactamente una conversación abierta y creativa (un asistente de ideas, un explorador de contenido), poner al modelo dentro de una máquina de estados determinista mata justo lo que querías. El patrón se justifica cuando hay dinero, compromisos o datos sensibles en juego, no como dogma. La pregunta que decide es simple: si el modelo se equivoca en su peor día, ¿el costo es un mensaje de más o una factura mal cobrada? Con lo primero puedes vivir; para lo segundo existe esta arquitectura.
Errores comunes al montar bots de IA con dinero de por medio
- Dejar que el modelo calcule: pedirle a la IA que sume un total o aplique un descuento. Es la falla que cuesta plata y credibilidad; ese cálculo es código.
- Confiar en el prompt como garantía: creer que instruir bien al modelo equivale a control. Un prompt es una probabilidad, no una restricción; la garantía la da la arquitectura.
- No definir la degradación: no decidir qué pasa cuando el modelo falla. Sin ese camino, el sistema improvisa justo en el peor momento.
- Defaults permisivos: asumir que sin configuración todo está permitido (como confirmar cualquier domicilio). El valor por defecto seguro es escalar, no permitir.
- Que la falla del modelo llegue al cliente: exponer respuestas dudosas del modelo en vez de convertirlas en una revisión interna. El cliente no debería enterarse de que el modelo dudó.
Preguntas frecuentes
Lo es si la IA no calcula el dinero. El diseño seguro le delega solo interpretación de lenguaje (entender qué pide alguien, reconocer productos de un catálogo, leer un comprobante) y deja precios, totales y confirmaciones en código determinista. Así, la peor falla posible del modelo es una repregunta o un pase a un humano. Un bot que cotiza con el modelo sí es riesgoso; uno donde el modelo nunca toca el dinero, no.
Porque «casi nunca» no es una garantía que puedas vender, y los errores no son gratuitos: un total mal calculado cuesta dinero y confianza del cliente. El cálculo es justamente lo que el código hace perfecto y sin variabilidad. Delegarle al modelo algo que una función resuelve con certeza es asumir riesgo sin ganar nada, porque la IA no aporta valor sumando, aporta valor entendiendo.
Córrelo sin la clave de la API. Si todas las llamadas al modelo fallan y el flujo sigue funcionando (repreguntando o escalando a un humano), tienes la prueba de que el modelo está fuera del camino crítico. Si el sistema se rompe o empieza a dar resultados incorrectos, el modelo está en el camino del dinero y hay que sacarlo. Es la verificación más simple y la más reveladora.
Repreguntar o pasar a una persona, con disparadores deterministas que decidan cuál de las dos. Lo que nunca debe hacer el sistema es adivinar y seguir adelante como si hubiera entendido. Una repregunta cuesta un mensaje; una suposición equivocada sobre un pedido cuesta el pedido. Definir esa degradación de antemano es parte del diseño, no un detalle de implementación.
Sí, y es donde más importa, porque ahí el bot no solo conversa: mueve oportunidades, dispara automatizaciones y toca datos de clientes. El principio es el mismo: la capa de IA interpreta y el sistema decide. Cuanto más pueda ejecutar el bot dentro de tu operación, más crítico es que las acciones con consecuencia (cobrar, cambiar estados, borrar) estén en código y no a criterio de un modelo.
Principio verificado construyendo y operando un sistema real de pedidos por WhatsApp con cobro, a julio de 2026. El caso va anonimizado por confidencialidad del cliente. Si necesitas diseñar una capa de IA que puedas garantizar en vez de esperar que funcione, ese diseño es parte de lo que hago; hablemos en contacto.
Y una advertencia que acompaña a este principio: el bot no aprende solo. El modelo está congelado; lo que mejora lo mejora una persona leyendo lo que falló.
Antes de abrir un bot al público hay otro riesgo que casi nadie mira: la agenda del teléfono y el modo pruebas.
El sistema donde se aplicó todo esto, con sus números y su estado real, está documentado en el caso de construcción de Antojo.
Y cuando otra IA revisa lo que la primera produjo, aparece una decisión que casi nadie toma bien: el evaluador necesita ojos frescos, sin compartir el contexto de quien produjo la pieza.
La idea que hace confiable a un bot
La confianza en un sistema con inteligencia artificial no viene de que el modelo sea bueno, viene de que el modelo no pueda hacer daño cuando sea malo. Se consigue con una decisión de diseño tomada antes de escribir la primera línea: la IA interpreta, el código decide, y todo lo que toca dinero o es irreversible vive del lado determinista. Hecho así, un bot se puede vender con garantías, probar con el modelo apagado y operar sin cruzar los dedos cada mañana. Y esa arquitectura, como la modularidad o la madurez operativa, no se agrega después: es la que decide si el sistema sirve. La pregunta no es si tu bot se va a equivocar, se va a equivocar. Es qué te va a costar cuando lo haga.
