El RPA y los agentes de IA resuelven problemas distintos, así que la decisión se toma paso por paso y no herramienta por herramienta. Use un agente cuando el paso exige criterio, RPA o una API cuando exige determinismo y una persona cuando exige responsabilidad. La mayoría de los procesos de finanzas y operaciones contiene los tres casos.
Esta guía le ofrece una forma de clasificar los pasos de un proceso, un ejemplo desarrollado en cuentas por pagar y una lista de verificación breve. Está escrita para quienes son dueños del proceso, es decir, líderes de finanzas, operaciones y servicios compartidos, no para el equipo que elige una herramienta.
¿Cuál es la diferencia entre el RPA y un agente de IA?
El RPA sigue un guion. Repite los mismos clics, en el mismo orden, sobre las mismas pantallas, y hace exactamente lo que se le indicó. Por eso es rápido, barato de operar y fácil de auditar, y por eso también se rompe cuando cambian los datos de entrada o la pantalla.
Un agente de IA interpreta la situación. A partir de un objetivo, un conjunto de herramientas autorizadas y sus políticas, lee información no estructurada, como una factura con un formato desconocido o un correo de un proveedor, y decide qué acción autorizada tomar. Esa flexibilidad es su valor y también su riesgo: sin controles, la misma entrada puede producir una respuesta distinta otro día.
Una API está del lado determinista, junto al RPA. Cuando un sistema ofrece una API estable, llámela directamente. El RPA es para los sistemas que no la tienen.
¿Cómo se decide qué necesita cada paso?
Hágase tres preguntas por cada paso, en este orden.
- ¿El paso exige criterio? Si una persona tiene que leer algo desordenado, interpretar una intención o aplicar una política con excepciones, un agente es candidato. Ejemplos: clasificar un documento, codificar una factura según política, redactar la respuesta a un proveedor.
- ¿El paso exige determinismo? Si la misma entrada siempre debe producir el mismo resultado y la acción escribe en un sistema de registro, use RPA o una API. Ejemplos: registrar un asiento contable, actualizar un campo del maestro de proveedores, ejecutar una regla de conciliación bancaria.
- ¿El paso exige responsabilidad? Si una persona con nombre debe responder por el resultado, porque se mueve dinero por encima de un umbral, se le comunica algo a un cliente o cambia un control de auditoría, mantenga a una persona en la decisión. El agente puede prepararla. La persona la firma.
Muchos pasos cumplen más de una condición. Sepárelos. La parte de criterio va a un agente, la parte de registro va a RPA o a una API y la aprobación queda con una persona. Es el principio de neutralidad tecnológica con el que trabajamos: el proceso decide la herramienta, no al revés.
¿Cómo se ve esto en cuentas por pagar?
Cuentas por pagar (CxP) reúne las tres necesidades en un solo flujo, y tenemos publicados los resultados de un caso: un agente de CxP en un fabricante regional (anonimizado). Así se clasifican sus pasos.
- Criterio (agente): leer cada factura, extraer los campos, cruzarla con la orden de compra y codificarla según la política, incluidas las facturas que llegan con formatos que nadie previó.
- Determinismo (RPA o API): registrar la factura aprobada en el ERP y actualizar el registro de pago. Son pasos fijos con un resultado fijo.
- Responsabilidad (persona): las facturas que el agente escala porque quedan fuera de la política o de lo que puede resolver.
El resultado medido: 92% de las facturas se procesó sin intervención manual en el mes 2 y 95% en el mes 6. El rendimiento de CxP se triplicó con el mismo equipo y el costo quedó por debajo de $0.40 por factura. El resto pasó a personas, con una ruta definida para llegar a ellas.
Dos controles hacen confiables esas cifras. El agente se evalúa contra un conjunto de 500 facturas de referencia, de modo que cada cambio recibe una calificación. Y las versiones del prompt y del modelo se fijan cada trimestre, de modo que cualquier resultado puede rastrearse hasta la versión exacta que lo produjo.
¿Cuándo no conviene usar un agente?
No use un agente en un paso que es una secuencia fija sobre un sistema estable. El RPA o una API es más barato, más rápido de ejecutar y más fácil de explicar a un auditor. Tampoco use un agente para tomar una decisión que nadie pueda revisar después. Si no puede reproducir por qué actuó, no debería actuar solo.
Y no use RPA en un paso que depende de leer documentos variados o texto libre. El bot resolverá los formatos para los que se construyó y enviará todo lo demás a una cola de excepciones que las personas atienden a mano. Esa cola es donde los agentes se justifican.
Lista de verificación antes de asignar un paso a una herramienta
- ¿Escribió el paso y decidió si debería existir?
- ¿La entrada es estructurada y estable (RPA o API) o variada y no estructurada (agente)?
- ¿La acción escribe en un sistema de registro? Si es así, ¿es reversible o la aprueba una persona?
- ¿Quién es el responsable con nombre del resultado?
- ¿Existe un conjunto de evaluación construido con casos reales y una nota mínima que el agente debe alcanzar?
- ¿Cuál es la ruta de excepciones y quién la atiende?
- ¿Puede pausar el agente de inmediato y reproducir cualquier decisión que tomó?
- ¿Las versiones del prompt y del modelo están fijas, con una fecha de revisión?
Preguntas frecuentes
¿Los agentes de IA van a reemplazar al RPA?
No, porque cubren pasos distintos. El RPA y las API siguen siendo la opción correcta para el trabajo determinista sobre sistemas estables, y los agentes suelen llamarlos para ejecutar lo que deciden. La pregunta útil es dónde corresponde cada uno dentro de un proceso concreto.
¿Necesitamos un agente si nuestro RPA ya funciona?
No necesariamente. Si sus bots corren sin una cola de excepciones que crezca, déjelos como están. Si las personas aún resuelven a mano excepciones que dependen de leer y de tener criterio, ahí un agente puede ayudar, al inicio con revisión humana.
¿Cómo se mantienen auditables las decisiones de un agente?
Registre cada prompt, llamada a herramienta y resultado con la identidad del operador, evalúe al agente contra un conjunto fijo de casos reales y fije las versiones del prompt y del modelo para que los resultados sean rastreables. Nuestro artículo sobre cómo gobernar agentes de IA en finanzas explica estos controles en detalle.