Hay una pregunta que sigo escuchando: "¿deberíamos optar por RPA o por agentes de IA?" Da por sentado que hay que elegir uno. En la práctica, trabajan en diferentes partes del mismo proceso — y la pregunta más útil es exactamente dónde pertenece cada uno.
Aquí hay una analogía que me ayudó a pensar en esto con claridad.
En una compañía de seguros, el suscriptor y el tramitador de siniestros hacen trabajos completamente diferentes. El suscriptor analiza el historial del cliente, sopesa los factores, toma una decisión que no está en ningún manual. El tramitador sigue una lista de verificación: rellenar estos campos, generar el documento, enviarlo al cliente. Uno es juicio. El otro es ejecución. Nadie pregunta cuál de los dos es "más eficiente" — porque no están haciendo lo mismo.
Las herramientas de automatización funcionan igual. Para cualquier paso de un proceso, una pregunta es suficiente: ¿hay una respuesta correcta conocida aquí, antes de que alguien lo mire?
Dónde un robot es simplemente mejor
Cargar documentos entrantes en un ERP mediante una regla de enrutamiento estándar. Validar campos de pólizas — importes, fechas, identificadores. Conciliar registros de pagos con asientos contables.
Para todo esto: la regla es clara, la secuencia es fija, el resultado es predecible. RPA lo ejecuta rápido, deja un registro de auditoría completo y no necesita pensar. Incorporar un agente en estos pasos significa añadir coste e impredecibilidad donde ninguno de los dos es necesario.
A veces se subestima cuánto del negocio es realmente así. Las operaciones deterministas no van a desaparecer.
Qué hace un agente — y cómo falla realmente
Un cliente envía un correo electrónico. Solo con el texto, no es obvio si es una queja sobre una reclamación denegada, una consulta de estado o una pregunta sobre los términos de la póliza. Un humano lo lee, entiende el contexto, lo enruta al equipo correcto.
Un agente hace lo mismo: lee el texto, lo clasifica según las instrucciones que has escrito, lo enruta — con un registro de cada decisión.
Esto no es un script con ramas if-else. Es un modelo de lenguaje que actúa sobre el significado del texto, no sobre coincidencias exactas de palabras. Un analista de negocio lo configura a través de instrucciones en lenguaje natural — sin necesidad de código. Pero sí requiere iteración. Compruebas los casos límite, refinas la instrucción, vuelves a comprobar. Lleva tiempo.
Merece la pena entender cómo fallan los agentes antes de desplegar uno. Un robot falla ruidosamente — lanza un error y se detiene, lo notas de inmediato. Un agente puede tomar una decisión incorrecta que parece completamente razonable. Es un tipo de riesgo diferente. Al principio, revisa manualmente una muestra de decisiones, define los casos en los que el agente debe escalar a un humano, y establece ese límite explícitamente. No te saltes este paso.
Por qué un agente no reemplaza a RPA
Un agente puede tomar decisiones. No puede ejecutarlas.
No puede iniciar sesión en un ERP, actualizar un registro, hacer clic en un botón de confirmación en un sistema bancario central. El agente decide; algo más tiene que actuar.
Cada sistema empresarial es su propia interfaz — su propia lógica, su propio versionado, sus propios casos límite. La integración con SAP, Oracle o una plataforma central heredada no se simplifica porque los modelos de lenguaje estén mejorando. Sigue siendo un problema de ingeniería, y es exactamente el problema que RPA fue diseñado para resolver.
Por eso "sustitución" es el marco equivocado. Operan en capas diferentes.
La capa entre ellos: el procesamiento de documentos
Entre el agente y el robot, a menudo hay una tercera pieza.
IDP — Procesamiento Inteligente de Documentos — convierte contenido no estructurado en datos estructurados. Extrae campos de formularios escaneados, PDFs, archivos adjuntos de imágenes, y los pasa adelante en un formato utilizable.
Un agente puede técnicamente leer un documento él mismo. Para tareas puntuales, bien. Para el procesamiento por volumen — es más lento, más caro y la precisión es más difícil de medir. El IDP está diseñado específicamente para esto: entrenado en tipos de documentos específicos, produce una métrica de precisión por campo y señala cuando no está seguro. El agente trabaja entonces con datos que ya están limpios.
Piénsalo como una capa de preparación. Facilita todo lo que viene después.
Cómo se ve esto en la práctica
Liquidación de siniestros. Los documentos llegan por partes — la solicitud inicial hoy, el informe del perito en tres días, la documentación adicional una semana después.
El robot recopila cada documento a medida que llega. El IDP extrae los datos — pero un escáner es de baja calidad, la confianza cae por debajo del umbral, ese documento va a revisión manual. El agente clasifica el caso: estándar o no estándar. El estándar procede automáticamente, el robot introduce la decisión en el sistema central. El no estándar: el cliente está impugnando la estimación de daños, su cuenta entra en conflicto con el informe del perito. El agente genera una solicitud de documentación adicional, se la pasa a un especialista. El especialista decide. El robot ejecuta.
La automatización pura con RPA típicamente alcanza el 60–70% de un proceso antes de toparse con las excepciones. Añade la capa de agentes, y en las implementaciones maduras estás mirando un 90–97% de procesamiento directo. El agente gestiona los puntos de juicio; el robot sigue haciendo la ejecución.
La inversión arquitectónica: cuando el agente está al mando
Todo lo anterior asume que RPA es la capa de orquestación principal — el robot llama al agente cuando se encuentra con un punto de juicio. Eso funciona bien para la automatización existente.
Pero está emergiendo un patrón diferente. Flujos de trabajo agent-first, donde el agente orquesta y el robot es una herramienta que llama.
Construimos un MCP Server para Primo RPA exactamente para esto. MCP — Model Context Protocol — es un estándar abierto que permite a cualquier agente compatible (Claude, Cursor, el tuyo propio) conectarse a la plataforma RPA y usar robots como herramientas invocables. El agente decide cuándo delegar la ejecución estructurada; el robot la ejecuta y devuelve el resultado.
Esto invierte la dirección habitual: no "el robot llama al agente" sino "el agente llama al robot."
¿Por qué importa? Porque si estás construyendo flujos de trabajo basados en agentes ahora, tu infraestructura RPA no tiene que convertirse en una capa heredada con la que trabajar. Se convierte en un servicio — invocable desde cualquier capa de orquestación que estés usando. Todavía estamos aprendiendo dónde funciona mejor este patrón, honestamente. Pero las integraciones que habilita son genuinamente diferentes de lo que era posible antes.
Medir lo que realmente está funcionando
Tres capas, tres cosas diferentes que medir.
Robots: tiempo de ciclo, tasa de excepciones, horas FTE liberadas. Directo.
Procesamiento de documentos: proporción de documentos procesados sin revisión manual, precisión de extracción frente a una referencia etiquetada, porcentaje de casos de baja confianza marcados. El número clave es la tasa de procesamiento directo — qué proporción pasa completamente de forma automática.
Agentes: precisión de decisiones comparada con lo que decidiría un experto, tasa de escalado, tiempo desde la entrada hasta el resultado en casos no estándar.
Cuando los tres funcionan juntos, una métrica de extremo a extremo se vuelve significativa: qué porcentaje del proceso se completa sin intervención humana — desde el documento entrante hasta el registro en el sistema. Ahí es donde realmente se puede ver lo que contribuye cada capa.
Por dónde empezar
Toma uno de tus procesos automatizados — idealmente el que tiene más excepciones yendo a manejo manual — y recorre cada paso con esa única pregunta: ¿hay una respuesta correcta conocida aquí, antes de que alguien lo mire?
Los pasos donde la respuesta es "no" — ahí es donde actualmente está de pie una persona. Esos son los puntos candidatos para la capa de agentes.
Luego: elige uno, define cómo es el éxito antes de empezar, lanza el piloto a pequeña escala. La arquitectura no es complicada. El trabajo siempre está en los detalles.