Por Qué tu Agente de IA Inventa Precios: Determinismo vs Probabilismo

La demo siempre funciona. El agente responde con seguridad, el cliente aprueba, se lanza a producción — y falla desde el primer día. Un precio mal citado, un descuento que no existe, una regla de negocio que el agente interpretó a su manera. No es un bug: es la naturaleza del modelo haciendo exactamente lo que fue diseñado para hacer.

Según el reporte State of AI Agents de LangChain, el 57% de las organizaciones ya tiene agentes en producción, y el 32% señala la calidad como la principal barrera para desplegarlos. Es la queja más citada de la industria. Y en la enorme mayoría de los casos que hemos visto, no se resuelve con un mejor prompt ni con un modelo más caro: se resuelve con arquitectura.

El problema, en tres interacciones

El precio exacto de un artículo es $45 pesos. Le preguntas a tu agente cuánto cuesta:

• Primera consulta: responde $43.
• Segunda consulta: responde $45. Correcto.
• Tercera consulta: responde $46.

Nadie cambió el catálogo entre una pregunta y otra. Lo que pasó es que el modelo nunca consultó el precio: lo autocompletó. Para un LLM, "45" es un token que cae dentro de un rango de probabilidad, y "43" o "46" caen en un rango muy cercano. El parámetro de temperatura le da margen para elegir entre ellos. El modelo no está fallando; está generando la secuencia más plausible, que es literalmente su función.

Lo peligroso es que responde las tres veces con el mismo tono de absoluta seguridad. No hay señal de error, no hay excepción en un log, no hay alerta. Solo un cliente al que le cotizaste mal.

Antes esto no era un problema

Vale la pena entender por qué esto es nuevo. Durante décadas, un cálculo o una regla de negocio se resolvían con código determinista: reglas estrictas escritas por programadores, donde la misma entrada produce siempre la misma salida. Consultar un precio era un SELECT. Aplicar un descuento era una función. Podía tomar semanas o meses construirlo, pero el resultado era seguro por diseño.

La llegada de los agentes redujo esos tiempos de desarrollo de meses a horas. El intercambio fue silencioso: se ganó velocidad y se perdió la garantía de exactitud. Para un ingeniero de software el choque entre determinismo y probabilismo es el pan de cada día. Pero al democratizarse la tecnología, ese reto conceptual pasó a un mercado que nunca tuvo que pensarlo, porque antes la precisión venía incluida en el diseño del código.

Las dos rutas para la misma pregunta

La diferencia entre un agente que falla y uno confiable no está en el modelo. Está en quién produce la respuesta:

Por qué el 90% de las implementaciones falla

Este problema aparece en la enorme mayoría de los "chatbots" que instalan consultores y agencias que solo conectan interfaces sin controlar el backend. Enchufan un modelo a WhatsApp, le pegan el catálogo en el prompt y lo entregan. La demo funciona porque en la demo se hacen cinco preguntas amables. Producción son mil preguntas al día, con variaciones que nadie anticipó.

Y aquí está el costo que nadie presupuesta. No son los tokens ni la infraestructura: es lo que pasa mientras nadie se da cuenta. Una empresa puede pasar meses perdiendo clientes, dinero y reputación antes de detectar que el agente está cotizando mal. Cuando por fin lo detecta, descubre que el gasto real no fue la mensualidad del modelo, sino haber construido sobre una arquitectura equivocada desde el primer día. Rehacerlo cuesta más que haberlo hecho bien.

Si estás evaluando presupuestos, vale la pena leer también cuánto cuesta realmente un agente de IA, donde desglosamos los costos que sí se ven.

Cómo se fuerza el determinismo

La solución no es pedirle al modelo que "no invente". Es quitarle la oportunidad de hacerlo. Se logra con dos piezas:

1. Herramientas deterministas

Funciones reales —del estilo de una función Lambda— vinculadas directamente al agente. Cuando el usuario necesita un cálculo estricto, el agente ejecuta la función y devuelve su resultado estructurado, en lugar de intentar adivinarlo. El modelo conserva lo que hace bien: entender la intención, elegir la herramienta correcta, redactar la respuesta. Y pierde lo que hace mal: producir cifras.

Es la diferencia entre un agente que sabe el precio y uno que lo busca. Profundizamos en el mecanismo en custom tools y prompts a medida.

2. Una fuente de verdad única

Una herramienta determinista sirve de poco si consulta datos dispersos: precios en un Excel, políticas en PDFs, promociones en la cabeza de alguien, historial en chats. Ahí es donde entra un grafo de conocimiento como capa de infraestructura: mapea todas las fuentes de la empresa en una red estructurada, con entidades y relaciones, de la que el agente extrae los datos duros directamente.

La diferencia frente a una búsqueda por similitud —como en un sistema RAG clásico— es que el grafo entiende validez temporal. Una promoción que venció el mes pasado es historia, no una respuesta.

El vacío del que casi nadie habla: el QA

La automatización y el vibe-coding pusieron la inteligencia al alcance de cualquiera. Lo que no se democratizó fue el rigor. Implementar un proceso de QA profundo antes de mandar un agente a producción sigue siendo un hueco enorme en la industria, y es la razón por la que tantos proyectos mueren en el mes tres.

Un QA mínimo para un agente que toca datos duros incluye:

• Batería de casos con respuesta conocida. Cincuenta preguntas cuyo resultado correcto está verificado, ejecutadas contra cada cambio de prompt, de modelo o de herramienta.
• Repetición. La misma pregunta veinte veces. Si el resultado varía, el dato no está saliendo de una fuente determinista.
• Casos límite reales. Productos con descuento vigente, precios con impuesto incluido, artículos descontinuados, promociones vencidas ayer.
• Trazabilidad. Poder responder, para cualquier conversación, de qué fuente salió cada dato que el agente afirmó.
• Escalamiento explícito. Qué hace el agente cuando la herramienta no devuelve resultado. La respuesta correcta es pasar a un humano, nunca improvisar.

Cuándo NO deberías meter un agente

Ser honestos con esto ahorra mucho dinero. Hay dos escenarios donde un agente es la herramienta equivocada:

Consultas directas a bases de datos estructuradas. Si el objetivo es extraer datos de una tabla, una función determinista o un query de toda la vida es infinitamente superior: más rápido, más barato y más seguro. La IA es excelente después, interpretando esos datos o generando analítica sobre ellos, pero no en la extracción.

Parchar un proceso que ya está roto. Es el error más común que vemos. Cuando el proceso operativo de fondo no funciona, lo que la empresa necesita es gestión de procesos, reingeniería o desarrollo de software tradicional. Un agente encima de un proceso roto solo automatiza el desorden y lo hace más rápido.

Si estás decidiendo qué tipo de solución necesitas, la comparativa entre agentes de IA y chatbots tradicionales ayuda a acotar el problema antes de elegir tecnología.

Lo que deberías preguntarle a quien te implemente

Si vas a contratar a alguien para que te construya un agente, estas cinco preguntas separan a quien controla el backend de quien solo conecta interfaces:

• Cuando el agente cita un precio, ¿de dónde sale exactamente ese número?
• ¿Qué pasa si le pregunto lo mismo veinte veces seguidas?
• ¿Cómo se entera el agente de que una promoción venció?
• ¿Qué batería de pruebas se corre antes de cada cambio?
• ¿Qué hace el agente cuando no tiene el dato?

Si las respuestas hablan de prompts y no de herramientas, fuentes de verdad y pruebas, la demo te va a encantar y producción te va a doler.

En resumen

Un LLM es un motor que autocompleta secuencias. Por más que parezca razonar, su naturaleza probabilística sigue ahí, y ninguna instrucción la elimina. La confiabilidad no se consigue pidiéndole al modelo que se porte bien, sino diseñando el sistema para que los datos duros nunca dependan de él: herramientas deterministas que ejecutan, una fuente de verdad única de donde leen, y un QA serio antes de producción.

Es exactamente la razón por la que 2026 se está llenando de capas de control determinista sobre los agentes. No es una moda: es la industria descubriendo, a base de golpes en producción, lo que la ingeniería de software sabía desde siempre.