Agentes de IA y RPA: Cuatro reglas de diseño que realmente importan

Tienes un agente. Entiende solicitudes, clasifica documentos, toma decisiones. El problema es lo que viene después — entre el momento en que el agente decide y el momento en que algo cambia realmente en un sistema.

En la mayoría de los entornos empresariales, ese hueco lo llena una persona. Alguien toma la salida del agente, abre la aplicación correcta, introduce los datos, envía el formulario. El agente es inteligente, pero no tiene manos.

RPA cierra ese hueco — específicamente en sistemas sin una API utilizable, donde la única vía de acceso es a través de la interfaz de usuario. Este artículo trata sobre cómo diseñar esa conexión para que la combinación funcione realmente en producción.

Por qué la frontera es difícil

Tres propiedades del RPA determinan directamente cómo se diseña la frontera.

La latencia es impredecible. Una llamada a una API devuelve resultado en un tiempo conocido. Un robot trabaja a través de una interfaz de usuario: espera a que se carguen las páginas, espera a que aparezcan los elementos, espera en la cola del orquestador. El mismo robot puede completarse en 10 segundos o en 3 minutos según la carga del sistema. Así funciona la automatización de UI. Para un agente que espera que las llamadas a herramientas se comporten como llamadas a funciones, esto es un desajuste estructural.

Los robots se rompen con los cambios de interfaz. Un robot identifica los elementos de la UI por selectores, nombres de campo o estructura del DOM. Cualquier actualización del sistema — incluso cosmética — puede romper esos identificadores. Cuantos más robots tenga, mayor es la probabilidad de que algo esté roto en cualquier momento.

Los robots son deterministas. Un robot ejecuta exactamente lo que se le indica. Sin interpretación, sin adaptación. Esa es su fortaleza — predictibilidad, auditabilidad — y su restricción fundamental. Si la entrada se desvía del formato esperado, el robot falla o produce una salida incorrecta sin advertencia.

Cuatro reglas para diseñar la frontera

El error más común es diseñar la integración como síncrona. El agente llama al robot, espera un resultado, continúa. Esto funciona cuando el robot responde en milisegundos. Falla cuando el robot tarda 3 minutos — el agente mantiene un contexto abierto, consume tokens, y acaba por agotar el tiempo de espera o reintenta asumiendo que la primera llamada falló.

El valor por defecto correcto es asíncrono. El agente lanza el robot y continúa. El resultado llega mediante callback, polling o un activo compartido. El agente puede ejecutar ramas paralelas o simplemente reconocer que una acción fue iniciada.

Piensa en las acciones de RPA como trabajos enviados a un entorno de ejecución, no como llamadas a funciones que devuelven resultados inmediatos.

La implicación práctica es la selección de tareas. Las tareas donde un humano ya espera — verificación KYC, procesamiento de documentos en lote, informes nocturnos — son candidatos naturales. Las tareas donde la latencia es visible al usuario en tiempo real necesitan un enfoque diferente o un diseño UX explícito para ocultar el retraso.

La asincronía desplaza la complejidad, no la elimina. Una llamada síncrona devuelve un resultado o falla con un error. Una llamada asíncrona tiene cuatro resultados posibles: éxito, error de ejecución, timeout de espera de resultado y ninguna respuesta en absoluto. El agente debe gestionar los cuatro. En la práctica, trabajar con estos resultados ocupa la mayor parte del esfuerzo de integración.

Las operaciones de lectura y escritura tienen perfiles de riesgo diferentes y deben diseñarse como categorías separadas.

Una lectura es segura para reintentar. Si el robot no responde y el agente vuelve a llamar, el peor resultado es una consulta duplicada. Los resultados de lectura también pueden cachearse — el estado de una cuenta, los datos de una contraparte, el contenido de un documento no cambian cada segundo.

Una escritura no es segura para reintentar sin confirmación explícita. Si el agente no recibe acuse de recibo y vuelve a llamar, puede acabar con dos transacciones enviadas o dos registros creados. En sistemas financieros, esto no tiene recuperación.

La regla: nunca mezcles lógica de lectura y escritura en el mismo robot. Diséñalos como unidades atómicas separadas. Para las escrituras, exige confirmación explícita antes de que el siguiente paso pueda continuar.

El RPA tradicional pone la inteligencia en el robot — ramifica, decide, gestiona excepciones internamente. Eso tenía sentido cuando el robot era la parte inteligente. En un sistema agente-RPA, el agente es la capa inteligente. El trabajo del robot es la ejecución.

Un robot atómico hace una sola cosa. Recibe una entrada definida y devuelve una salida definida. Toda la lógica de ramificación y el manejo de excepciones viven en el agente.

Un ejemplo concreto: un robot que verifica una contraparte en un registro externo recibe tres campos — nombre de la entidad jurídica, número de registro, jurisdicción. Devuelve un estado (encontrado / no encontrado / error) y, si se encuentra, un indicador de riesgo y la fuente. Ese es el contrato completo. Si el registro no está disponible, el robot devuelve un estado de error. No reintenta internamente, no cambia a un registro diferente. Esa decisión corresponde al agente.

El contrato también hace que los robots sean descubribles. Un agente que puede leer una descripción estructurada de los robots disponibles — qué recibe cada uno, qué devuelve — puede seleccionar la herramienta correcta de forma dinámica. Esto es lo que convierte una biblioteca de automatizaciones en algo sobre lo que un agente puede razonar.

Como efecto secundario, los robots atómicos son más fiables. Menos selectores, menos pasos, menos puntos de fallo.

Esto también cambia cómo funciona la orquestación. Históricamente, el orquestador era el cerebro — secuenciaba los pasos, gestionaba la lógica. En una arquitectura agente-RPA, el agente asume ese rol. El orquestador se convierte en un bus de ejecución.

Los despliegues de RPA existentes casi siempre necesitan ser modificados antes de poder servir como herramientas de agente. Los robots construidos para flujos de trabajo deterministas no están diseñados para recibir entradas variables de un agente. Esta modificación es un prerrequisito, no una optimización.

Un agente es no determinista. Sus decisiones no pueden predecirse o auditarse completamente como lo haría un sistema basado en reglas. Esa es la naturaleza de los sistemas de razonamiento — y crea un problema de gobernanza cuando los agentes interactúan con sistemas financieros, datos regulados o cualquier entorno donde la auditabilidad importa.

La solución es tratar al robot como el límite de cumplimiento.

El robot se ejecuta bajo una cuenta de servicio con permisos explícitamente limitados. Solo puede hacer lo que se le permite, y ese conjunto de permisos se define de antemano — no se infiere en tiempo de ejecución. Cada acción se registra en el orquestador: qué se llamó, cuándo, con qué parámetros y qué devolvió.

Esto significa que, independientemente de lo que decida el agente, el límite del sistema se mantiene. Si el agente realiza una llamada inesperada para cambiar un límite de crédito, pero la cuenta de servicio del robot solo tiene acceso de lectura a ese sistema, la acción no se ejecuta. La no determinación del agente se encuentra con un límite de permisos determinista.

Para entornos regulados — la banca, en particular — esta arquitectura tiene un valor práctico específico: cuando un auditor pregunta qué ocurrió, bajo qué autoridad y con qué restricciones, tienes una respuesta completa. Esa respuesta vive en los registros del orquestador, no en el rastro de razonamiento del agente.

Patrones en la práctica

El agente llama al robot. El agente decide e invoca el robot como herramienta. Verificación KYC: el agente procesa un paquete de documentos, lanza robots en paralelo para verificar registros, recopila resultados. Correspondencia entrante: el agente clasifica una solicitud, el robot crea un ticket. Monitorización de límites: el agente detecta una posición que se acerca a un umbral, llama al robot para actualizar parámetros en un sistema de riesgo heredado. En los tres casos la división es la misma — el agente orquesta, el robot ejecuta una acción definida.

El robot llama al agente. Aquí el robot dirige el flujo de trabajo principal pero delega un paso cognitivo. Screening AML: el robot recopila datos y descarga extractos, luego pasa el paquete completo al agente para análisis de riesgo. Respuesta a incidentes de seguridad: el robot recopila registros de toda la infraestructura, el agente evalúa la señal, el robot ejecuta la respuesta. El robot maneja el trabajo estructurado y navegable. El agente maneja la interpretación.

El robot prepara datos para el agente. Este es fácil de pasar por alto porque no hay llamada directa en ninguna dirección — el robot simplemente se ejecuta en segundo plano. El caso más claro es la indexación RAG desde sistemas heredados. Si los sistemas fuente no tienen API — archivos antiguos, gestión documental heredada, portales internos — la única vía de extracción es la automatización de UI. El robot se ejecuta según un horario, extrae documentos, los deposita en almacenamiento, y el pipeline de indexación estándar se encarga del resto. El agente nunca llama a este robot directamente. Simplemente se vuelve más capaz.

El fallo parcial no es un caso límite

En el patrón KYC anterior, tres robots se ejecutan en paralelo. En producción, uno de ellos ocasionalmente no responderá. Esto es normal — no es un caso límite.

Cuando una llamada paralela no devuelve resultado, el agente tiene cuatro opciones:

Esperar. Mantener el flujo de trabajo abierto hasta que llegue el resultado o se active un timeout. Correcto cuando los datos que faltan son necesarios para la decisión y el retraso es aceptable.

Continuar con datos parciales. Continuar con lo que llegó y señalar explícitamente la brecha. Aceptable cuando la verificación que falta es complementaria — pero la brecha debe ser visible en la salida. Una decisión tomada con datos incompletos que parece completa es un problema de auditoría.

Escalar. Derivar el caso a un humano con una descripción clara de lo que falta. En entornos regulados, la escalada suele ser el valor por defecto correcto, no un recurso de última instancia.

Reintentar una vez, luego escalar. Un reintento cubre los fallos transitorios. Más de uno sin resultado señala algo estructuralmente incorrecto.

La elección entre estas opciones no debe inferirse en tiempo de ejecución. Debe especificarse por llamada a robot en tiempo de diseño: qué significa este resultado para la decisión y qué ocurre si no llega.

Lo que sorprende a los equipos en la práctica

Los robots existentes necesitan una modificación significativa. Los robots construidos para procesos deterministas esperan entradas fijas y limpias. Cuando un agente empieza a llamarlos con parámetros variables — diferentes formatos de nombre, diferentes casos límite — fallan o producen salidas incorrectas. Reconstruir los robots existentes como herramientas atómicas no es una tarea pequeña. Presupuesta para ello.

La latencia plantea una pregunta útil. La primera reacción ante robots lentos es hacerlos más rápidos. La pregunta más productiva es: ¿qué tareas necesitan realmente ser síncronas? Normalmente, menos de lo que se asume.

La frontera debe decidirse, no asumirse. Sin una decisión arquitectónica explícita, deriva durante el desarrollo. La lógica acaba en robots que debería estar en el agente. Los agentes obtienen acceso al sistema que debería pasar por los robots. Cuando algo falla, es imposible rastrear dónde se tomó la decisión y bajo qué permisos se ejecutó la acción. En entornos regulados, esa ambigüedad no es aceptable.

Por dónde empezar

Si estás evaluando dónde encaja el RPA en tu plataforma de agentes, busca tareas que cumplan tres criterios a la vez: entrada variable o no estructurada que el agente pueda manejar; un conjunto finito de acciones en un sistema sin API utilizable; y tolerancia para la ejecución asíncrona.

Si ya tienes un portfolio de RPA, comienza identificando los robots que vale la pena atomizar primero. Los buenos candidatos tocan un solo sistema, se completan en menos de un minuto y devuelven una salida lo suficientemente predecible como para describirse en un contrato. Los robots que abarcan múltiples sistemas o devuelven estructuras variables no son imposibles de exponer — pero el coste de modificación es mayor.

Empieza con los sencillos. Haz que el patrón funcione de extremo a extremo. Las automatizaciones complejas pueden venir después, una vez que sepas que la frontera se mantiene.