LLM + reglas: cuándo una operación necesita un sistema híbrido

Hay una frase que resume casi todo lo que hay que decidir cuando se mete inteligencia artificial en una operación: los modelos interpretan, los motores controlan.

Un modelo de lenguaje es útil precisamente porque la entrada no siempre llega de forma predecible. Puede interpretar intención, resumir contexto, extraer información de un documento o entender que tres formulaciones distintas significan lo mismo. Esa flexibilidad es su valor.

Pero un descuento, un permiso, un estado de proceso, una condición contractual o una validación crítica no debería depender de que un modelo crea que la respuesta es correcta. Esos puntos necesitan reglas y estados reproducibles.

Un sistema híbrido es, simplemente, el que no confunde esas dos cosas.

La fórmula

Cuando el diseño funciona, se puede escribir en una línea:

LLM para interpretar + motor para validar + software para registrar + persona para resolver excepciones.

Las cuatro piezas tienen función propia. El modelo entiende lo que llega. El motor de reglas o la máquina de estados decide si eso puede avanzar. El software deja registro de qué ocurrió y por qué. Y una persona recibe el caso cuando aparece una excepción que el sistema no debería resolver solo.

Quitar cualquiera de las cuatro produce un tipo de problema distinto: sin modelo, el sistema exige que todo llegue estructurado; sin motor, el proceso depende de una probabilidad; sin registro, nadie puede reconstruir una decisión después; sin la persona, las excepciones se convierten en errores silenciosos.

Dónde va la frontera

La pregunta práctica no es «¿usamos IA?», sino qué parte del recorrido necesita ser exacta. Hay una lista corta de cosas que casi nunca deberían quedar del lado del modelo: permisos, estados, cálculos, elegibilidad, transiciones, límites y reglas de negocio. Todo eso necesita respuestas reproducibles, y para eso existen la lógica determinista, los motores de reglas y las máquinas de estados.

Del otro lado quedan las entradas ambiguas: un mensaje escrito por una persona, un documento que no viene en formato fijo, una solicitud que puede expresarse de diez maneras. Ahí el modelo clasifica, extrae, resume o interpreta —dentro de un alcance definido— y le entrega al motor algo que ya se puede validar.

El mismo recorrido, visto como flujo, tiene siempre las mismas etapas: un evento verificable lo dispara; el sistema valida campos, permisos, formato, duplicados y datos mínimos; la IA interpreta o enriquece lo que llega desestructurado; una regla explícita decide la ruta; el sistema actúa; y todo queda registrado con estado, fecha, versión, fuente, resultado y motivo suficiente para reconstruir qué pasó.

Un ejemplo: una conversación que no entrega el control

En Zyllon, una plataforma SaaS conversacional para seguros, el lenguaje natural se combina con una máquina de estados. El modelo interpreta la conversación; la lógica del sistema mantiene el flujo, las validaciones y la estructura del proceso.

Lo que demuestra no es que la IA sea capaz de conversar —eso ya se da por hecho—, sino que no tiene que sustituir al software tradicional. Puede convertirse en una capa de interpretación dentro de una arquitectura que conserva estados, reglas y trazabilidad. La conversación se siente flexible mientras el proceso sigue siendo auditable.

Seis situaciones en las que el modelo no debe decidir

Hay decisiones en las que velocidad no debe reemplazar criterio. Estas seis tienen tratamiento definido desde el diseño, no como parche posterior:

• Información insuficiente o contradictoria. Detener, señalar la contradicción y pedir el dato o la revisión necesaria.
• Baja confianza del modelo. No convertir una predicción incierta en un hecho; escalar o solicitar confirmación.
• Acción irreversible o de alto impacto. Exigir aprobación humana o una compuerta adicional.
• Negociación, excepción o caso sensible. Asignar a una persona con contexto e historial.
• Decisión legal, fiscal, financiera o profesional regulada. Usar IA sólo como apoyo dentro del alcance permitido y conservar validación profesional cuando corresponda.
• Dato crítico de una fuente no autorizada. No continuar hasta usar una fuente definida como válida para el proceso.

Ninguna de las seis es una limitación del modelo: son decisiones de arquitectura. Un sistema que no las toma explícitamente las toma igual, sólo que por omisión.

Lo que hay que poder responder antes de conectar un modelo

Antes de integrar un LLM a un proceso conviene poder contestar cuatro cosas: qué interpreta o genera exactamente el modelo, con qué fuentes trabaja, cómo se revisa su resultado y qué pasa cuando no está seguro. Si alguna no tiene respuesta, el problema no es el proveedor ni el modelo elegido: es que el recorrido todavía no está descrito.

Y sí, la IA puede equivocarse. Por eso se distingue interpretación probabilística de reglas deterministas, se definen fuentes autorizadas, se registran resultados y se diseñan compuertas de revisión cuando el riesgo lo exige.

Inteligencia donde aporta. Control donde importa.