Tres tecnologías, tres problemas
Las tres suelen presentarse como competidoras. No lo son. Resuelven problemas diferentes y la mayoría de los flujos operativos usan dos o tres a la vez.
- Las reglas fijas — lógica si-entonces, tablas de decisión, validaciones — convierten en acciones conocimientos que ya puedes escribir explícitamente. Son rápidas, gratuitas en su uso, completamente predecibles y verificables mediante pruebas.
- RPA opera un sistema como una persona: pantallas, botones y campos. Existe porque algunos sistemas no tienen una integración útil.
- La IA evalúa entradas que no puedes definir de antemano: texto libre, un documento de diseño desconocido o una conversación.
Criterio 1 — ¿Qué tan variables son las entradas?
Este es el criterio más claro. Si puedes representar la entrada en un esquema — campos, valores y orden fijos —, el procesamiento corresponde a reglas. Un modelo que lee un formulario fijo no aporta nada e introduce una posibilidad de error que antes no existía.
Cuando la entrada es texto libre o un documento cuyo diseño cambia por proveedor, las reglas llegan a su límite. Puedes escribir treinta reglas para treinta diseños y, con el siguiente, empiezas otra vez. Ahí un modelo resulta más económico que mantener reglas.
Criterio 2 — ¿Existe una integración?
RPA es un recurso de emergencia más que una preferencia tecnológica, y eso no es una crítica: a veces es la única ruta. Si el sistema tiene una API o una integración existente, úsala. Si solo funciona por pantalla, RPA es la conexión.
Ten en cuenta sus costos conocidos: un script de RPA se rompe con cada cambio de interfaz, funciona bajo la cuenta de alguien y es difícil de probar. Trátalo como infraestructura temporal con un responsable, no como una solución terminada.
Criterio 3 — ¿Quién debe poder explicar el resultado?
Si un regulador, contador o cliente debe entender por qué se obtuvo un resultado, prefiere reglas donde sea posible. Una regla es la explicación. Un modelo entrega un resultado que debes sustentar después.
Eso no va en contra de la IA, sino a favor de dividir las tareas: deja que el modelo convierta entradas no estructuradas en campos y que una regla decida sobre esos campos. Así la evaluación es explicable y la entrada sigue siendo flexible.
La combinación que suele funcionar mejor
Un flujo operativo suele verse así:
- Un modelo lee la entrada no estructurada y entrega campos con una puntuación explícita de incertidumbre.
- Las reglas validan esos campos: ¿existe el proveedor, es correcto el total, el valor está dentro del límite autorizado?
- Una persona aprueba cuando las reglas señalan dudas o desviaciones.
- Una integración o paso de RPA ejecuta el resultado aprobado en el sistema de destino, con registro de cada paso.
Si mezclas estas cuatro capas, terminas con un modelo que debe recordar valores límite y un script de RPA que debe interpretar texto libre. Ambos fallan de la forma más costosa: en silencio.
Cuándo no usar ninguna de las tres
Cuando el problema es el propio proceso. Si la entrada se vuelve confiable con ajustar el formulario de origen, ese ajuste cuesta menos que cualquiera de las tecnologías anteriores. Y si el proceso ocurre unas pocas veces al año, el trabajo manual es simplemente la solución más económica; se puede decir abiertamente.