El motor calcula, la IA conversa: por qué en Likida nunca se cruzan

Cuando alguien escucha "agentes de IA para liquidar viajes", suele imaginar un modelo de lenguaje mirando un ticket de diésel y decidiendo cuánto se le debe al operador. Eso es exactamente lo que no pasa. El modelo lee el ticket, sí. Conversa con el operador, sí. Decide cuándo mandar un aviso o a quién escalar una duda, también. Lo que nunca hace es calcular el monto final de una liquidación — ese trabajo lo hace un motor determinístico, y la distinción no es un detalle técnico menor: es la razón por la que un contralor puede firmar el número sin tener que confiar en la buena suerte de un modelo.

Qué significa "determinístico" cuando hay dinero de por medio

Un motor determinístico es código que, con los mismos datos de entrada, produce exactamente el mismo resultado todas las veces — hoy, mañana, y dentro de un año, sin importar qué tan distinto amanezca el modelo de lenguaje que lo rodea. Sumar lo comprobado contra el anticipo, aplicar la política de gastos de la flota, verificar si un CFDI (Mexico's digital tax receipt) está vigente: son operaciones que tienen una respuesta correcta, verificable, auditable línea por línea. Un modelo de lenguaje, en cambio, genera texto probabilísticamente — es extraordinario leyendo una foto borrosa de un ticket o entendiendo qué quiso decir un operador que escribió "ya llegue" sin acentos, pero esa misma naturaleza probabilística es la que lo vuelve la herramienta equivocada para decidir un total en pesos.

La división de trabajo, en la práctica

El operador manda las fotos de sus tickets por WhatsApp y escribe "listo". El modelo las lee: extrae el monto, el RFC, el folio fiscal de cada comprobante — trabajo de percepción, no de aritmética de negocio. Esos datos extraídos entran entonces al motor, que los valida contra el SAT (Mexico's tax authority), los compara contra la política de gastos de la flota y calcula la diferencia contra el anticipo. El modelo puede redactar el mensaje que explica el resultado al operador o al jefe de tráfico — conversar sobre el número — pero el número mismo ya salió del motor antes de que el modelo lo tocara.

Esa secuencia importa más de lo que parece: si el orden se invirtiera —si el modelo calculara primero y el motor solo redactara después— cualquier alucinación del modelo llegaría directo a una liquidación real, con dinero real de por medio.

Qué pasa cuando el modelo y el motor no coinciden

Aquí está la regla que sostiene todo lo demás: si la lectura del modelo y el cálculo del motor no coinciden, gana el motor — o no se manda nada. No existe un camino donde la conversación del modelo sustituya al resultado del motor porque suene razonable. Un ticket que el modelo no pudo leer con confianza no se convierte en un monto inventado para no interrumpir el flujo; se queda marcado como pendiente hasta que alguien lo revise. La opción de "mejor una cifra aproximada que ninguna" simplemente no está disponible, porque una cifra aproximada en una liquidación no es una aproximación — es un error con el nombre de alguien encima.

Por qué esto es una decisión de diseño, no una limitación

Sería más simple, en el sentido de escribir menos código, dejar que un modelo de lenguaje moderno calculara todo de principio a fin — hoy son capaces de sostener una conversación completa sobre números. La razón por la que Likida no lo hace así no es que el modelo no pueda sumar: es que un modelo de lenguaje no puede prometer que va a sumar exactamente igual la próxima vez, y una liquidación de viajes no es un borrador que se pueda corregir después — es un documento que un operador cobra, que un contador registra y que un contralor firma. Separar quién calcula de quién conversa es lo que permite que la parte que conversa mejore con cada versión del modelo sin que la parte que calcula tenga que confiar en que esa mejora nunca empeore un número.