Automatización de procesos con IA vs. RPA: cuál necesita tu operación

Casi toda empresa que ya intentó automatizar algo tiene la misma cicatriz: un robot de RPA que funcionó seis meses y se rompió cuando alguien movió un campo en el ERP. Vale la pena entender por qué pasa eso antes de decidir con qué tecnología automatizar lo siguiente.

Qué hace realmente el RPA

El RPA (Robotic Process Automation) automatiza la interfaz, no el proceso. Graba una secuencia de acciones — abre esta pantalla, copia este campo, pégalo en aquel formulario — y la repite. Es determinista: la misma entrada produce siempre la misma salida.

Eso lo hace excelente para tareas que cumplen tres condiciones:

• Alto volumen y baja variación. Mil facturas idénticas en formato.
• Reglas explícitas. Si el monto supera X, va a esta cola.
• Sistemas estables. Nadie va a rediseñar esa pantalla el mes que viene.

Y lo hace frágil justo donde esas condiciones fallan. El RPA no entiende lo que está copiando: reconoce posiciones y patrones. Cambia el patrón y el robot no se adapta, se cae.

Qué agrega la IA

La automatización con IA no reemplaza la ejecución, reemplaza la interpretación. En vez de “el campo en la posición 3 es el total”, el sistema lee el documento y determina cuál es el total, aunque el proveedor haya cambiado su plantilla.

Eso abre tres capacidades que el RPA clásico no tiene:

1. Entrada no estructurada

Correos, PDFs con formatos distintos, fotos de remisiones, notas de voz de un operador. El RPA necesita que alguien normalice todo eso primero. Un modelo lo procesa directo.

2. Decisión con contexto

Un robot de RPA sigue un árbol de reglas que alguien escribió. Un sistema con IA puede correlacionar señales de varias fuentes — el histórico del proveedor, la orden de compra, el registro de recepción — y evaluar si algo se sale de lo normal, incluso cuando nadie escribió una regla para ese caso específico.

3. Tolerancia al cambio

Si el proveedor cambia el diseño de su factura, el modelo sigue encontrando los datos. No hay que reprogramar nada.

Dónde sigue ganando el RPA

Esto no es una lista de razones para tirar el RPA. Hay casos donde meter un modelo es peor ingeniería:

• Cuando la regla es exacta y auditable. Un cálculo fiscal no necesita interpretación, necesita certeza. Un if es mejor que un modelo.
• Cuando el costo por transacción importa. Millones de operaciones idénticas al mes: la inferencia cuesta y la regla no.
• Cuando el sistema no tiene API. A veces la única puerta de entrada es la interfaz, y ahí el RPA es la herramienta correcta.

La respuesta práctica: capas, no bandos

En operaciones reales la división limpia casi nunca existe. Lo que funciona es usar cada tecnología en la capa donde es fuerte:

Capa	Qué la resuelve mejor
Leer entrada ambigua	IA / modelos
Aplicar política y límites	Reglas explícitas
Decidir en casos grises	IA con contexto
Aprobar lo crítico	Una persona
Ejecutar la acción	API, o RPA si no hay API

Un flujo típico de recepción de facturas se ve así: el modelo extrae los datos del PDF, una regla verifica que el monto esté dentro del contrato, la IA marca que este proveedor nunca había facturado ese concepto, una persona aprueba, y recién entonces una integración escribe en el ERP.

Cada paso usa la herramienta adecuada, y el paso irreversible — escribir en el ERP — sólo ocurre después de una validación humana.

Cómo elegir para un proceso concreto

Tres preguntas que ordenan la decisión:

1. ¿La entrada llega siempre igual? Si no, necesitas IA en la lectura.
2. ¿Alguien puede escribir todas las reglas? Si sí, escríbelas: son más baratas, más rápidas y auditables.
3. ¿Qué pasa si se equivoca? Si la consecuencia es cara o irreversible, el paso final necesita aprobación humana, sin importar qué tecnología uses.

La tercera es la que más se salta y la que más caro sale.

---

¿Tienes un proceso concreto en mente y no sabes en qué capa cae cada parte? Cuéntanos cómo funciona hoy y lo desarmamos contigo.