¿Cuánto cuesta un AND frente a preguntarle lo mismo a un LLM?

Hace poco me encontré revisando un fragmento de código donde había que decidir si continuar con una operación. La condición era trivial: la transacción estaba aprobada y el usuario seguía activo. Alguien propuso, medio en broma, resolverlo preguntándole a un modelo de lenguaje. Funcionaría. Y esa es exactamente la razón por la que vale la pena detenerse a pensarlo.

Una decisión aparentemente simple

El caso es común. Un servicio recibe un evento, tiene dos señales —transactionApproved y userActive— y debe decidir si sigue adelante. La regla es explícita, conocida y estable: si ambas son verdaderas, se continúa.

La opción determinista

if (transactionApproved && userActive) {
  // continuar con la operación
}

Este AND se evalúa en nanosegundos. No consume red, no depende de un servicio externo y no tiene variación entre ejecuciones; su costo es, a efectos prácticos, cero. Además es fácil de leer, de probar y de razonar: dado el mismo input, siempre produce el mismo output.

¿Qué cambia cuando entra un LLM?

Delegar esa misma decisión a un modelo de lenguaje cambia varias propiedades a la vez:

• Determinismo. La respuesta puede variar entre llamadas para el mismo input.
• Latencia. Se pasa de nanosegundos a una llamada de red, con un tiempo de respuesta de otro orden de magnitud.
• Consumo de tokens. Cada evaluación tiene un costo por tokens de entrada y de salida.
• Consumo de infraestructura. Cada evaluación implica tráfico de red y capacidad de cómputo en un servicio externo.
• Costo operativo. Ese costo se multiplica por el volumen de eventos.
• Complejidad. Aparecen prompts, manejo de errores del proveedor, reintentos, límites de tasa y una dependencia externa más en la ruta crítica.

Nada de esto significa que un LLM sea "malo". Significa que resolver un AND con un LLM paga todos esos costos para obtener algo que una condición booleana ya resolvía de forma más simple y predecible.

Costo técnico de elegir mal

El problema no suele ser una decisión aislada, sino el patrón. Cuando se normaliza usar un modelo para reglas que son deterministas, el sistema hereda latencia variable, una factura que crece con el tráfico y una superficie de fallo más grande, todo para lógica que cabía en una línea. La deuda no se ve el primer día; se ve cuando el volumen sube.

Dónde sí aporta un LLM

Un LLM es la herramienta adecuada cuando el problema tiene una forma que una regla no captura bien:

• Lenguaje natural. Clasificar, resumir o extraer intención de texto libre.
• Contexto ambiguo. Situaciones donde las condiciones no están enumeradas y dependen de matices.
• Información no estructurada. Documentos, correos, transcripciones y datos que no encajan en columnas.

En esos casos el modelo hace algo que el código imperativo no puede hacer de forma razonable, y el costo se justifica.

Una regla de diseño útil

Antes de introducir un modelo en una ruta de decisión, suelo hacerme una sola pregunta:

¿Esto necesita razonamiento o solamente necesita una regla?

Si la respuesta es "una regla" —las condiciones son conocidas y finitas—, el lugar de esa lógica es el código. Si la respuesta es "razonamiento" —hay ambigüedad, lenguaje o contexto que enumerar sería imposible—, entonces un LLM empieza a tener sentido.

Conclusión

Un AND y una consulta a un LLM pueden resolver el mismo caso puntual, pero no son intercambiables: uno es determinista, instantáneo y de costo mínimo; el otro es probabilístico, más lento y facturable. Elegir bien no es una cuestión de moda, sino de identificar si el problema pide una regla o pide criterio. Quizás una buena arquitectura con IA sea, sobre todo, la que sabe exactamente cuándo no usarla.

Publicado originalmente en LinkedIn.