Agentes de IA y RPA: cómo se combinan en un proceso real

Cómo combinar agentes de IA y RPA en un mismo proceso: en qué punto entra el modelo dentro de un robot Rocketbot y qué decisiones no conviene delegarle.

En casi todas las llamadas comerciales de los últimos meses aparece alguna versión de la misma duda. Si ya existen agentes de IA que entienden lenguaje natural y pueden tomar decisiones, el cliente quiere saber para qué seguir construyendo robots con pasos fijos. Es una inquietud lógica para quien todavía no ha visto un proyecto por dentro. En la práctica casi nunca hay que elegir entre uno y otro, porque cada uno resuelve un problema distinto y la mayoría de los procesos que automatizamos terminan usando los dos.

Ya hemos aplicado esta combinación en varios proyectos, aunque sin llamarla así. El robot se apoya en un modelo para leer un documento poco común o clasificar algo que no tiene formato fijo, y después continúa con la parte determinística del proceso. Ahora existen herramientas que permiten construirla de forma repetible, sin partir de cero en cada caso.

Diferencia entre un robot RPA y un agente de IA

Un robot RPA ejecuta pasos definidos, siempre en el mismo orden, y por eso se usa en tareas repetitivas de alto volumen sobre sistemas con pantallas o APIs estables. Abre SAP, completa un campo, guarda y pasa al siguiente registro. No tiene margen para interpretar: si encuentra algo que no coincide con lo esperado, se detiene o entra en una excepción.

El agente de IA trabaja con entradas ambiguas, como un mensaje, un párrafo suelto de un documento o una consulta que alguien redactó con sus propias palabras. Devuelve una interpretación, por ejemplo qué tipo de solicitud es y en qué categoría cae, o qué campo representa probablemente un número que llegó sin etiqueta. Esa interpretación viene con un nivel de confianza. La acción en el sistema destino queda a cargo de otra pieza del proceso.

Un error frecuente en proyectos iniciados sin asesoría es tratar al agente como reemplazo del robot completo. El resultado es un modelo que hace clic en pantallas siguiendo instrucciones en lenguaje natural. Es técnicamente posible, pero frágil. En una tarea que se repite igual miles de veces, cada ejecución puede razonar un camino distinto para el mismo caso.

Cómo se conecta el agente dentro de un robot Rocketbot

Construimos sobre Rocketbot, donde el agente es un paso más del flujo y participa una sola vez, en el punto donde hace falta criterio. Cuando el robot llega a ese punto, porque tiene que interpretar un correo, un campo de un PDF o una descripción libre, invoca un módulo de IA con un prompt construido a partir de las variables del proceso. Según el proyecto usamos Gemini o AiStudio. La respuesta vuelve como texto o como campo estructurado y queda guardada en una variable, igual que cualquier otro dato que maneja el robot.

Desde ahí el robot vuelve a ser tan determinístico como cualquiera de los que documentamos en este blog. Un evaluateIf lee esa variable para elegir la rama. Si hay un lote que procesar, lo recorre un for, y los errores quedan contenidos en un trycatch.

Es la misma arquitectura que describimos para el procesamiento inteligente de documentos, con el agente dentro del robot: el modelo (Gemini o el AI Studio de Rocketbot, según el proyecto) lee el PDF y entrega los campos, y el robot los valida y los carga. Un agente que clasifica texto libre sigue el mismo patrón con otro tipo de entrada. Cuando el agente conversa directamente con personas, por WhatsApp, correo o chat, implementamos Melon Help, una plataforma de agentes de IA de la que somos partner, y el robot ejecuta en los sistemas lo que el agente resolvió.

Ejemplo: clasificar solicitudes que llegan por correo

Pensemos en un robot que procesa solicitudes recibidas por correo. Algunas llegan con asunto libre, sin ningún campo estructurado que indique de qué se tratan, y no existe una regla fija a la que el robot pueda mapearlas. Sin un modelo, esa entrada queda fuera de su alcance. Alguien tiene que clasificar cada correo a mano antes de que el proceso automatizado pueda empezar.

Con el agente incorporado, el robot le envía al modelo el asunto y el cuerpo del correo, y le pide una de las categorías que el proceso ya conoce junto con un nivel de confianza. Si la confianza supera el umbral acordado con el cliente, el robot sigue solo por la rama de esa categoría. Si queda por debajo, no fuerza una decisión y deriva el correo a una persona con la categoría sugerida ya marcada. Esa persona confirma en segundos en lugar de leer todo desde cero. Su corrección queda registrada para revisar más adelante si conviene ajustar el umbral.

Ese umbral se calibra con los primeros lotes reales de cada cliente, porque el nivel de ambigüedad de una "solicitud de cambio de dirección" varía de una empresa a otra.

Decisiones que no le delegamos al modelo

En todos los proyectos donde participa un agente mantenemos una regla fija, sin importar la presión de plazo o de presupuesto. El modelo interpreta y clasifica, y con eso entrega una lectura inicial. Las decisiones de negocio las firma una persona: autorizar pagos, aprobar montos, elegir qué factura se paga y cuál se rechaza, o cerrar un reclamo a favor o en contra del cliente. El robot ejecuta lo que esa persona confirmó y nunca actúa solo con la sugerencia del modelo.

Un modelo de lenguaje puede sostener una interpretación equivocada con la misma seguridad que una correcta. En decisiones con consecuencias legales o financieras directas, esa seguridad aparente es un riesgo serio. Sus errores, además, cambian de un caso a otro. Una regla mal escrita en un robot falla siempre igual y se audita con facilidad. Detectar una interpretación equivocada antes de que llegue al sistema destino cuesta bastante más.

Definir quién puede decidir qué, y quién solo ejecuta lo que otro autorizó, es el mismo ejercicio que hicimos con credenciales y cuentas de servicio en el artículo sobre seguridad y gobierno en proyectos de RPA. En este caso lo aplicamos al modelo.

Cuándo no hace falta un agente

Muchos procesos que parecen requerir IA se resuelven sin ella. Puede que la entrada ya traiga un campo fijo con el tipo de solicitud, o que los casos ambiguos sean tan pocos que una persona los separa en cinco minutos a la semana. En esos escenarios basta con RPA puro, que es más barato de construir y no tiene el costo recurrente de las llamadas al modelo. Un agente solo sumaría mantenimiento (prompts que hay que revisar, respuestas que pueden variar entre versiones del modelo) para un problema que una regla simple ya resolvía.

Antes de proponer un agente preguntamos si el dato que necesita el proceso llega como texto libre, sin estructura. Cuando la respuesta es sí, el agente empieza a justificarse, siempre que el volumen alcance para pagar el flujo completo con su validación humana. Esa pregunta la hacemos temprano, cuando se decide qué procesos automatizar primero. Un candidato con entrada ambigua sigue en la lista, aunque la respuesta cambia el tipo de proyecto que hay que diseñar.

Preguntas frecuentes

¿Un agente de IA puede reemplazar completamente a un robot RPA?+

Todavía no, al menos para operar sistemas con pantallas fijas de forma repetible. Si un ERP se usa quinientas veces al día, cada ejecución tiene que seguir el mismo camino. Un agente se orienta en la interfaz con flexibilidad, y por eso dos ejecuciones del mismo caso no siempre toman la misma ruta.

¿Qué pasa si el modelo cambia de versión y empieza a responder distinto?+

Es un riesgo real y otra razón para no dejarlo decidir solo. El umbral de confianza y la validación humana absorben buena parte del problema. Si el modelo empieza a fallar más, sube el volumen que se deriva a revisión, y eso aparece en las métricas antes de convertirse en un error silencioso en el sistema destino.

¿Esto encarece mucho el proyecto respecto de un robot RPA tradicional?+

Depende sobre todo de cuántos puntos de interpretación tenga el proceso. Un robot con un único paso de clasificación agrega poco sobre el costo base que explicamos en cuánto cuesta automatizar un proceso. Lo que sube el costo es diseñar y calibrar el umbral y el circuito de revisión humana, un trabajo que de todos modos hay que hacer para que el resultado sea confiable.

¿Se puede usar cualquier modelo de IA para esto?+

Técnicamente sirve casi cualquiera que reciba texto y devuelva una respuesta. Lo recomendable es fijar el modelo desde el inicio y no cambiarlo a mitad de proyecto. Un umbral calibrado con un modelo no se traslada directamente a otro, porque cada uno tiene sus propios sesgos al expresar qué tan seguro está de una respuesta.

¿Esto es lo mismo que "agentic AI" o "agentes autónomos"?+

No exactamente. Aquí describimos un modelo que interpreta un dato puntual dentro de un flujo que el robot sigue controlando paso a paso. Un agente autónomo, en el sentido que ha tomado el término últimamente, encadena varias decisiones y acciones por su cuenta sin que una persona revise cada tramo. Eso todavía lo manejamos con mucho más cuidado, solo en pasos acotados y nunca en un proceso completo.