RPA + LLM: dónde poner el criterio y dónde la regla

Durante años el argumento en contra de RPA fue siempre el mismo: es frágil. Cambia una etiqueta en el portal, llega un correo redactado distinto, y el robot se cae. Y era cierto.

Después llegaron los modelos de lenguaje y el péndulo se fue al otro extremo: pongámosle un LLM a todo. También es un error, y bastante más caro, porque falla en silencio.

El diseño híbrido consiste en separar con precisión qué pasos requieren reglas deterministas y cuáles demandan el razonamiento contextual de un modelo.

La pregunta que ordena todo

Antes de diseñar, me hago una sola pregunta por cada paso del proceso:

¿Este paso tiene una respuesta correcta verificable, o tiene una respuesta razonable?

Si tiene una respuesta correcta (el RUT valida o no valida, el monto cuadra o no cuadra, el estado existe o no existe), eso es una regla. Determinista, testeable, sin espacio para interpretación.

Si tiene una respuesta razonable (la persona pide una devolución, el documento parece una factura de servicios, el reclamo es urgente), eso es criterio. Y el criterio es exactamente lo que los modelos hacen bien y las reglas hacen pésimo.

El error que más veo es mezclar ambos: pedirle al modelo que calcule totales (tiene respuesta correcta, no la adivines) o escribir doscientas reglas de texto para detectar intención (tiene respuesta razonable, no la codifiques).

Un caso concreto: el triage de correos

Una casilla que recibe solicitudes de clientes. Antes: dos personas leyendo, clasificando y transcribiendo a un sistema legado. El proceso completo, descompuesto:

Paso	Naturaleza	Quién lo hace
Leer el correo y entender qué pide	Criterio	LLM
Extraer datos del cuerpo del correo	Criterio con validación	LLM + reglas
Verificar que el RUT sea válido	Regla	Código
Verificar que el cliente exista	Regla	Consulta a BD
Verificar que el monto cuadre	Regla	Código
Decidir si sigue o se escala	Regla sobre confianza	Código
Ejecutar en el sistema legado	Regla	Robot RPA
Responder al cliente	Criterio con plantilla	LLM + revisión

Fíjate en el patrón: el modelo entiende, el código verifica, el robot ejecuta. Ninguno hace el trabajo del otro.

Y algo importante: el modelo nunca escribe directo en el sistema. Su salida es un objeto estructurado que pasa por validación antes de que el robot lo toque.

{
  "intencion": "solicitud_devolucion",
  "confianza": 0.92,
  "datos": {
    "rut": "12345678-5",
    "numero_documento": "F-100234",
    "monto": 45990
  },
  "campos_dudosos": [],
  "requiere_humano": false
}

Ese confianza y ese requiere_humano no son decorativos: son el contrato entre el modelo y el resto del sistema.

Los tres controles que nunca me salto

1. El modelo propone, el código dispone

Toda salida del LLM se valida contra un esquema antes de usarse. Tipos correctos, campos obligatorios presentes, formatos válidos. Si no pasa el esquema, no hay ejecución: se escala.

Esto suena obvio y aun así es lo primero que se omite cuando hay apuro. Un modelo que devuelve "monto": "cuarenta y cinco mil" en vez de un número no es un caso raro: es martes.

2. Umbral de confianza con destino claro

No basta con que el modelo diga cuán seguro está; hay que definir qué pasa en cada tramo:

• Alta confianza + validaciones OK → el robot ejecuta solo.
• Confianza media → cola de revisión humana, con la propuesta ya armada para aprobar o corregir.
• Baja confianza o validación fallida → sale del flujo automático y se avisa.

El tramo del medio es el que hace que esto funcione en la práctica. No es un fallback: es donde vive la mayoría de los casos reales al principio, y donde el sistema aprende qué le falta.

3. Trazabilidad completa del razonamiento y del resultado

En RPA clásico basta con registrar qué hizo el robot. En híbrido hay que registrar por qué: qué recibió el modelo, qué devolvió, con qué confianza, qué validaciones pasaron y quién aprobó si hubo alguien.

Sin esa bitácora es imposible auditar la decisión ni justificar ante el negocio por qué el sistema aprobó o escaló un caso determinado.

Lo que ganamos y lo que costó

El principal beneficio no estuvo en la velocidad de respuesta, sino en la cobertura del proceso frente a formatos variados. Antes el robot manejaba los correos que venían en el formato esperado, más o menos la mitad, derivando el resto a intervención manual.

Al incorporar el modelo para interpretar la intención en lugar de coincidir patrones rígidos, la cobertura automática creció de forma sostenida y dejamos de mantener reglas de texto frágiles. Ya no hacen falta listas infinitas de palabras clave que actualizar cada vez que alguien redacta de otra manera.

Lo que costó: el diseño toma más tiempo. Hay que pensar los umbrales, escribir los esquemas de validación, armar la cola de revisión y definir la trazabilidad. Es más lento al principio y mucho más estable después.

La regla que me quedó

Si tuviera que reducir todo esto a una frase para pegar en el escritorio:

El LLM para entender, el código para verificar, el robot para ejecutar, la persona para decidir cuando algo no cuadra.

Cada vez que un proyecto híbrido se complicó, fue porque alguna de esas cuatro piezas estaba haciendo el trabajo de otra.