Determinismo primero, LLM después

Hay una tentación comprensible cuando empezamos a integrar modelos de lenguaje en un flujo de trabajo: si un LLM puede interpretar una instrucción y devolver una respuesta convincente, parece que también puede encargarse de todas las decisiones intermedias.

El problema es que muchas de esas decisiones no necesitan interpretación. Necesitan exactitud.

Un identificador debe cumplir un formato. Una operación no debe ejecutarse dos veces. Un documento debe tener unos campos obligatorios. Un estado no puede avanzar si falta una autorización. Una fecha debe ser válida. Ninguno de esos problemas mejora necesariamente porque los expresemos en lenguaje natural y se los entreguemos a un modelo.

Mi criterio ha ido evolucionando hacia una regla simple: utilizar código determinista para las reglas que puedo expresar de forma explícita y un modelo para aquello donde realmente hay ambigüedad. Que una comprobación sea reproducible no garantiza que esté bien definida: también hay que probarla.

No todas las incertidumbres son iguales

Imaginemos que recibimos un documento y necesitamos incorporarlo a un sistema. Podemos tener al menos tres problemas distintos.

Primero, localizar información relevante dentro del documento. Si el formato cambia, una herramienta capaz de interpretar texto puede resultar útil.

Segundo, comprobar que los datos obtenidos son válidos. Un identificador puede tener longitud, estructura y reglas conocidas. Esa validación debe ser reproducible.

Tercero, decidir qué hacer con el resultado. Si falta un dato obligatorio o la información contradice el estado actual, el sistema no debería inventar una respuesta para completar el flujo. Debería rechazarla o pedir una decisión.

Meter las tres cosas en una única petición al modelo puede producir una demo atractiva. También mezcla responsabilidades difíciles de auditar.

El LLM como propuesta, no como autoridad

Me resulta más cómodo pensar en la salida del modelo como una propuesta estructurada.

El modelo puede decir: «Creo que este texto corresponde a tal campo». El sistema comprueba si ese campo existe, si el valor tiene una forma válida, si coincide con otras evidencias y si se cumplen las reglas de negocio antes de guardar nada.

Ese diseño acepta una limitación fundamental: una respuesta bien redactada no equivale a una respuesta correcta.

Ya había encontrado algo parecido al evaluar razonamiento de modelos. Una solución podía terminar con el resultado esperado y, sin embargo, utilizar un argumento incorrecto para justificarlo. Si solo miraba el resultado, la evaluación no detectaba el problema.

En procesos operativos, la lección es todavía más importante. No basta con que el resultado parezca plausible. Necesito saber qué condición concreta permite aceptarlo.

Una cadena con fronteras claras

Una arquitectura razonable puede expresarse así:

Entrada → extracción o interpretación → validación determinista → reglas de negocio → acción controlada → evidencia del resultado.

El modelo puede intervenir en la parte de interpretación. No necesita decidir por sí solo si se guarda una entidad, se cambia un estado o se envía algo fuera del sistema.

Por ejemplo, cuando un texto no encaja con una categoría conocida, el modelo puede sugerir una clasificación con incertidumbre explícita. El código, por su parte, puede decidir que las categorías desconocidas no se guardan automáticamente.

Esto no impide utilizar IA. Evita darle a la IA responsabilidades que el sistema ya sabe resolver mejor.

Validar también significa saber detenerse

Una de las peores características de una automatización es que se sienta obligada a continuar.

Si faltan datos, conviene diferenciar entre una ausencia recuperable y un bloqueo real. Si una fuente falla, puede haber un reintento razonable. Si dos fuentes se contradicen, quizá haya que escalar una pregunta. Si el sistema no puede demostrar que una operación se realizó, no debería marcarla como completada.

La frase «no tengo evidencia suficiente» puede ser una salida mucho más valiosa que una respuesta aparentemente completa.

En muchos procesos la calidad no depende de cuántos casos consigamos completar, sino de cuántos errores somos capaces de impedir antes de que tengan consecuencias.

Una ventaja menos visible: poder probar el sistema

Cuando separo interpretación de validación, también separo las pruebas.

Puedo probar el validador con entradas correctas, incorrectas, vacías y límite sin llamar a ningún modelo. Puedo comprobar las transiciones de estado de forma repetible. Puedo registrar qué propuso el modelo y qué aceptó realmente el sistema.

Si algo falla, la pregunta deja de ser «¿por qué la IA hizo esto?» y se convierte en varias preguntas más pequeñas: ¿extrajo mal un valor?, ¿la validación era insuficiente?, ¿la regla permitía una acción que no debía?, ¿faltaba una comprobación posterior?

Esas preguntas son mucho más útiles cuando hay que mantener un producto.

Tampoco hay que convertirlo en un dogma

No todo problema tiene una frontera limpia. Hay situaciones donde una decisión semántica sí forma parte del resultado final. Otras veces, una regla demasiado rígida produce más falsas alarmas que valor. Y hay comprobaciones externas que tampoco ofrecen certeza absoluta.

La idea no es prohibir a los modelos decidir. Es identificar qué parte del proceso puede comprobarse sin ellos y no delegar innecesariamente esa parte.

Un LLM amplía la clase de entradas que un programa puede entender. No debería obligarnos a renunciar a las propiedades que ya sabemos exigir al software: validación, trazabilidad, idempotencia y control de errores.

Mi regla provisional es esta: todo lo que pueda demostrarse con una condición clara, que lo demuestre el código. Lo que necesite interpretación, que lo proponga el modelo. Y lo que tenga consecuencias, que pase por una frontera explícita antes de ejecutarse.