RPA frente a agentes de IA: qué encaja con cada proceso

La respuesta corta: usa RPA cuando el proceso está regido por reglas, es estable y de alto volumen, y la única razón por la que interviene una persona es que dos sistemas se niegan a hablar entre sí. Usa un agente de IA cuando el proceso requiere leer información no estructurada, valorar casos ambiguos o decidir el siguiente paso según un contexto que no se puede enumerar de antemano. Si una persona nueva competente pudiera seguir una lista de comprobación de una página y producir siempre el mismo resultado, eso es terreno de RPA. Si esa persona necesitara un mes de exposición al negocio antes de que su criterio fuera fiable, eso es terreno de agentes — y posiblemente un proceso que no deberías automatizar de principio a fin.

La mayoría de los flujos de trabajo empresariales no son puramente uno u otro. Un flujo típico de factura a pago tiene un paso de lectura complicado (la factura llega como PDF, escaneo o cuerpo de correo), un paso de valoración (¿esto coincide con un pedido de compra? y, si no, ¿quién debe decidirlo?) y un paso determinista (registrar el asiento aprobado en el ERP con las correspondencias de campos exactas). La lectura y la valoración corresponden a un modelo; el registro corresponde a una integración determinista. Los equipos que se queman son los que fuerzan toda la cadena en una sola herramienta porque esa herramienta ya estaba contratada.

Dónde la RPA determinista sigue ganando

La RPA tiene mala reputación por cómo se ha vendido, no por lo que hace. Como categoría, sigue siendo la opción correcta bajo condiciones fáciles de enunciar:

• Las reglas están completas y por escrito. Cada ramificación del proceso se puede expresar como una condición sobre datos estructurados. No queda un residuo de «y luego lo consultas con María, de Tesorería».
• Las entradas ya están estructuradas. Archivos de formato fijo, filas de base de datos, respuestas de API, columnas de hoja de cálculo en posiciones conocidas.
• El coste de una acción equivocada es alto y el coste de una acción detenida es bajo. Ejecución de pagos, asientos contables, aprovisionamiento, presentaciones regulatorias. Quieres un sistema que falle de forma visible, no uno que improvise.
• El volumen es alto y la variación es baja. La rentabilidad de la automatización determinista viene de la repetición. Mil transacciones idénticas al día es el escenario ideal.
• Necesitas explicar exactamente qué ha pasado. Un bot determinista produce el mismo resultado para la misma entrada, siempre, y la lógica se puede auditar línea a línea. Eso importa a auditoría interna de una forma que «lo decidió el modelo» no.

Hay una segunda ventaja, menos obvia: la automatización determinista es barata de ejecutar por transacción y su coste no escala con lo difícil que sea el razonamiento. La inferencia de un modelo cuesta dinero en cada llamada y se encarece cuanto más contexto le das. Para un paso de alto volumen y poca valoración, ejecutar un modelo es pagar por una capacidad que no estás usando.

Dónde ganan los agentes basados en modelos

Los agentes se ganan su lugar allí donde la entrada no está estructurada o donde el camino a través del proceso no se puede conocer de antemano. En concreto:

• Leer documentos que llegan en formatos arbitrarios. Facturas de proveedores, expedientes de siniestros, contratos, avisos de remesa, informes de laboratorio, correo entrante. El mismo campo lógico aparece en un sitio distinto en cada documento. Este es el núcleo de nuestro trabajo de inteligencia documental y de datos.
• Clasificación y enrutamiento cuando las categorías son difusas. Decidir si un mensaje de un cliente es una disputa de facturación, un riesgo de cancelación o una pregunta sobre el producto, y qué evidencia respalda esa decisión.
• Gestión de excepciones. La mayor parte del trabajo en una operación madura está en las excepciones, no en el camino habitual. Un agente puede leer la excepción, reunir los registros relevantes, proponer una resolución y entregarle a una persona una decisión en lugar de un trabajo de investigación.
• Trabajo de varios pasos con una ruta variable. «Concilia esta discrepancia» puede requerir revisar tres sistemas en un orden que depende de lo que devuelva la primera comprobación. Codificar cada ruta como reglas es posible en teoría y penoso en la práctica.
• Redacción y resumen. Respuestas, notas de caso, resúmenes internos: cualquier cosa cuyo resultado es lenguaje y una persona lo revisa.

La contrapartida es que los agentes son probabilísticos. La misma entrada puede producir un resultado ligeramente distinto. Eso es aceptable cuando una persona revisa el resultado, cuando la acción es reversible, o cuando tienes una capa de validación determinista detrás del modelo que rechaza cualquier cosa fuera de rango. No es aceptable cuando el resultado del agente va directo a un sistema de registro sin ningún control.

Por qué falla el screen-scraping

El modo de fallo más habitual en los programas de automatización de primera generación es un bot que maneja la interfaz de usuario de una aplicación: haciendo clic en coordenadas, leyendo píxeles, pasando de un campo a otro con el tabulador. Funciona en la demo y se degrada a partir de ahí, por razones estructurales:

• La interfaz no es un contrato. Los proveedores cambian diseños, renombran campos, insertan ventanas modales y despliegan pruebas A/B sin previo aviso. Una API tiene versionado y política de obsolescencia. Una pantalla no tiene ninguna de las dos cosas.
• Los tiempos son inestables. Los bots esperan intervalos fijos a elementos que tardan un tiempo variable en cargar. Bajo carga, la espera resulta demasiado corta y el bot actúa sobre una página que no ha terminado de renderizarse.
• El fallo es silencioso y parcial. Un bot de interfaz que pierde su posición a mitad de secuencia puede haber confirmado ya media transacción. Conciliar eso después suele suponer más trabajo del que el bot ahorró.
• Los entornos cambian con el tiempo. Actualizaciones del navegador, resolución de pantalla, avisos de certificados, caducidad de sesión, desafíos de autenticación multifactor. Cada uno de estos es un incidente de producción para un bot de interfaz y un no-evento para una integración.
• Las credenciales viven en el lugar equivocado. La automatización de interfaz suele significar que una cuenta de servicio, con los permisos de una persona, inicia sesión en la sesión de esa persona. Es una historia más difícil de contar a tu equipo de seguridad que una credencial de API con alcance limitado. Explicamos cómo lo gestionamos en nuestro enfoque de seguridad.

Añadir un modelo de IA a un bot de screen-scraping no soluciona esto. Un modelo de visión que encuentra el botón «Enviar» es más resistente a los cambios de diseño que el clic por coordenadas, lo cual es una mejora real, pero sigue operando contra una interfaz sin compromiso de estabilidad, sigue sujeto a los tiempos, y ahora es más lento y más caro por acción. Usa automatización de interfaz cuando de verdad no haya otra puerta de entrada al sistema: un producto de proveedor sin API, una pantalla verde de mainframe, una aplicación heredada que nadie puede modificar. Trátala como un puente con fecha de caducidad conocida, no como una arquitectura.

La arquitectura híbrida que de verdad aguanta

El patrón que construimos con más frecuencia separa el proceso en capas con características de fiabilidad distintas y comportamientos de fallo distintos.

Una capa de ingesta recoge lo que llegue —correo, descarga de un portal, depósito SFTP, webhook de API— y lo normaliza en una única representación interna. Esta capa es determinista. No interpreta; recopila y marca la hora.

Una capa de comprensión usa modelos para convertir contenido no estructurado en campos estructurados con señales de confianza asociadas. Aquí es donde ocurren la extracción, la clasificación y la resolución de entidades. Su salida es una propuesta, no un hecho.

Una capa de validación es determinista y no negociable. Comprueba la salida del modelo frente a las reglas de negocio, los datos de referencia y las tolerancias: si este proveedor existe, si las cuentas cuadran, si este importe está dentro del rango aprobado, si la fecha tiene sentido. Todo lo que falla va a una cola de personas con el motivo concreto adjunto. Esta capa es la razón por la que la arquitectura es fiable: hace que un error del modelo se convierta en una excepción enrutada en lugar de una transacción errónea.

Una capa de acción escribe en los sistemas de registro a través de API, con claves de idempotencia para que un reintento no pueda duplicar un registro. Esta capa es determinista y debería ser aburrida.

Una capa de observabilidad registra cada entrada, cada salida del modelo, cada decisión de las reglas y cada acción, enlazadas por un identificador de caso. Cuando alguien pregunte dentro de seis meses por qué una transacción concreta se gestionó de esa manera, puedes responder en minutos.

La propiedad importante de este diseño es que la parte probabilística queda contenida. Los modelos hacen lo que se les da bien —leer y valorar— y nunca obtienen acceso de escritura directo a nada que importe. Así construimos la automatización inteligente de procesos que los equipos de operaciones están dispuestos a dejar funcionando sin supervisión.

Cómo elegir, proceso a proceso

Pasa cada proceso candidato por estas preguntas, en orden. La primera que dé una señal clara suele resolverlo.

Cuando la respuesta es «todavía no automatices esto»

Rechazamos trabajo, o lo posponemos un trimestre, cuando vemos estas señales. Decirlo pronto sale más barato que descubrirlo durante la construcción.

• Nadie puede describir el proceso actual de forma consistente. Si tres personas que hacen el trabajo a diario lo describen de tres maneras distintas, no tienes un proceso, tienes un conjunto de hábitos. Automatizarlo congela el desacuerdo dentro del código.
• El volumen no justifica nada. Una tarea que se hace un puñado de veces al mes, y la hace alguien que se le da bien, normalmente no merece una construcción, un pipeline de despliegue y una rotación de guardias.
• Los datos de origen están rotos. Si el maestro de proveedores está lleno de duplicados, la automatización procesará duplicados más rápido. Arregla primero la fuente, o haz que limpiarla sea el proyecto.
• El sistema está a punto de sustituirse. Si la migración del ERP llega el año que viene, construir contra el sistema saliente compra unos meses de beneficio y una reconstrucción completa.
• El verdadero cuello de botella es una decisión, no el trabajo. Si los casos se quedan días esperando a que alguien los apruebe, recortar minutos del procesamiento no cambia nada. Arregla el camino de aprobación.
• No hay un responsable. La automatización necesita a alguien que responda por la cola de excepciones y por las reglas. Sin eso, se degrada silenciosamente y todo el mundo la esquiva.

Qué determina el coste y el esfuerzo en cada caso

Ninguno de los dos enfoques tiene un precio fijo, pero los factores que lo determinan difieren de una forma que conviene conocer antes de presupuestar.

En la automatización determinista, el coste lo domina la superficie de integración: cuántos sistemas, lo bien documentadas que están sus API, cuántos datos de referencia hay que mapear, y cuántos casos límite tiene realmente el negocio frente a los que dice tener. El esfuerzo de construcción se concentra al principio; el coste continuo es el mantenimiento cuando cambian los sistemas conectados. El coste de ejecución por transacción es insignificante.

En la automatización basada en agentes, el coste lo domina la evaluación. Construir una primera versión que funcione con documentos de muestra es rápido. Llegar a una versión en la que confíes sin supervisión implica montar un conjunto de pruebas representativo, medir la precisión por campo y por tipo de documento, ajustar, y fijar los umbrales de confianza que enrutan los casos correctos a personas. Ese trabajo de evaluación es el proyecto. El coste de ejecución es por transacción y escala con el volumen y el tamaño del contexto, así que pertenece al presupuesto operativo y no a la partida de capital. Nuestro enfoque de entrega coloca el conjunto de evaluación en su sitio antes de la construcción, porque es la única forma honesta de saber cuándo algo está terminado.

En un enfoque híbrido, se aplican tanto el esfuerzo de integración como el de evaluación, compensados por el hecho de que la capa de validación determinista te permite lanzar con una precisión de modelo más baja de la que necesitarías de otro modo: las excepciones se enrutan a personas en lugar de provocar errores. Si quieres comprobar si un proceso concreto merece el esfuerzo antes de hablar con nadie, nuestra calculadora de valor trabaja con las variables de volumen y tiempo de gestión que determinan la respuesta.

Una secuencia práctica

Empieza por el proceso, no por la herramienta. Averigua dónde va realmente el tiempo: normalmente es un paso de lectura y una cola de excepciones, no las pulsaciones de teclas. Automatiza primero la columna vertebral determinista, para tener una ruta fiable sobre la que actuar. Después añade delante la capa de comprensión, con una persona revisando el resultado hasta que las cifras se sostengan. Luego sube el umbral de confianza para el procesamiento directo, categoría a categoría, con la posibilidad de volver a bajarlo. Los procesos que implican contacto con clientes suelen seguir un arco parecido en nuestro trabajo de operaciones de atención al cliente con IA: primero borrador y revisión, gestión autónoma para categorías concretas una vez que la evidencia lo respalda.

Si tienes un proceso concreto en mente y quieres una respuesta directa sobre qué enfoque encaja —incluido si merece la pena automatizarlo siquiera—, habla con nosotros. Una conversación breve de alcance sobre volúmenes, sistemas y de dónde vienen las excepciones suele bastar para saberlo.

Preguntas que nos hacen sobre esto