Computer Use vs RPA empresa: cuándo usar cada uno
TL;DR
Computer Use vs RPA empresa no es un debate de sustitución, es un debate de arquitectura. El RPA tradicional sigue ganando en procesos masivos, estables y de céntimos por operación. Computer Use de Anthropic gana cuando hay variabilidad, UIs cambiantes, razonamiento condicional o falta de API. En la práctica, las empresas con un RPA Center of Excellence maduro están montando arquitecturas híbridas donde Computer Use orquesta y gestiona excepciones, y el RPA ejecuta el volumen repetitivo. Si ya tienes UiPath, Automation Anywhere o Blue Prism, la pregunta correcta no es “¿lo cambio?”, es “¿qué procesos me están sangrando en excepciones y cuál es el coste real de no resolverlas?”.
¿Por qué esta comparación importa AHORA y no hace tres años?
Llevamos una década viendo cómo el RPA tradicional madura, se consolida en los grandes proveedores (UiPath, Automation Anywhere, Blue Prism) y, sobre todo, llega a un techo. Ese techo no es teórico: lo vemos cada semana en clientes que arrancaron su RPA Center of Excellence en 2018-2020 y hoy están atascados en el mismo punto. Tienen entre 80 y 200 bots desplegados, un equipo de mantenimiento sobredimensionado y una lista de “procesos no automatizables” que nunca baja, porque cada vez que se quita uno entran tres nuevos. Esa lista es justamente la que Computer Use está empezando a desbloquear, y por eso el debate Computer Use vs RPA empresa ha dejado de ser conversación de I+D para convertirse en discusión de comité de dirección.
El lanzamiento de Computer Use por parte de Anthropic en octubre de 2024, seguido de OpenAI Operator y de Google Project Mariner, no introdujo solo una nueva categoría de producto. Introdujo una capacidad que el RPA llevaba diez años sin tener: la de un modelo que ve la pantalla, razona sobre el objetivo y ejecuta acciones sin que nadie le haya grabado paso a paso lo que tiene que hacer. Para un COO que lleva años escuchando que “ese proceso no es automatizable porque la herramienta cambia cada mes”, la implicación es directa: muchos de los procesos que el RPA descartó por brittleness vuelven a estar sobre la mesa. Y los que el RPA sí automatiza, pero con un coste de mantenimiento que se come el ahorro, también.
En los proyectos que llevamos en Datalvar AI, la conversación con los responsables de automatización ha cambiado en seis meses. Hace un año nos preguntaban “¿esto sustituye al RPA?”. Hoy nos preguntan “¿cómo combino esto con lo que ya tengo sin romper el ROI que llevo defendido ante el CFO?”. El cambio es importante: nadie con un RPA Center of Excellence serio quiere tirar la infraestructura existente, pero todos saben que el modelo de “un bot por proceso, mantenido a mano” no escala más. La respuesta híbrida es la que estamos implementando, y este artículo es el mapa de cuándo y cómo hacerlo bien.
¿Cómo funciona el RPA tradicional, exactamente?
El RPA tradicional, en su versión simplificada, es software que automatiza interacciones con interfaces gráficas y APIs siguiendo un script determinista. Un desarrollador (o un ciudadano-desarrollador con herramientas low-code tipo UiPath Studio) graba o programa una secuencia: abrir esta aplicación, hacer clic en este botón identificado por su selector, leer este campo, copiar este valor a este otro sistema. El bot ejecuta esa secuencia miles de veces al día sin desviarse. Cuando el proceso es estable, el ROI es brutal: hablamos de centenares de transacciones por hora con un coste marginal de céntimos. Por eso el RPA conquistó el back office bancario, el procurement, las reconciliaciones contables, el alta y baja de empleados, el procesamiento de facturas estandarizadas.
La mecánica interna combina dos enfoques. Por un lado, conectores API y bases de datos cuando la aplicación destino los ofrece: aquí el bot es un cliente HTTP/SQL con lógica encima, lo cual es estable y rápido. Por otro, selectors de UI (XPath, accesibilidad, OCR de bajo nivel) cuando la aplicación es legacy o no expone API: aquí el bot literalmente “encuentra” el botón en pantalla usando atributos de la interfaz. Las grandes plataformas (UiPath, Automation Anywhere, Blue Prism) han añadido encima capas de orquestación, control de cola, gestión de credenciales y dashboards de monitorización que hacen viable correr cientos de bots en producción. Todo ese stack es lo que un RPA Center of Excellence ha pulido durante años, y no se tira por la ventana.
El problema, conocido por cualquiera que haya pasado de la euforia del primer año a la realidad del tercero, es la fragilidad. Un botón que cambia de sitio, un campo nuevo que aparece, una versión del SaaS que altera el DOM, y el bot se cae. En procesos críticos esto se traduce en incidencias de prioridad uno a horas malas, en colas de tickets para el equipo de mantenimiento y en una tasa de “bots rotos” que en organizaciones grandes ronda fácilmente el 10-20% del parque en cualquier momento dado. A esto se suma la otra limitación estructural: el RPA tradicional no razona. Si el caso se sale del happy path que el desarrollador previó, el bot lo escala a un humano. Y esos casos excepción son donde se queda atrapada la productividad real, porque suelen representar el 15-30% del volumen pero consumen el 60-70% del esfuerzo humano restante.
¿Cómo funciona Computer Use y qué lo hace distinto?
Computer Use es la capacidad, expuesta hoy principalmente por Anthropic con el modelo Claude y por algunos competidores, de que un modelo de lenguaje vea la pantalla como un pixel raster, razone sobre lo que está mirando, y emita acciones de mouse y teclado para lograr un objetivo descrito en lenguaje natural. La diferencia conceptual con el RPA tradicional no es trivial: aquí no hay un script que grabe paso a paso, hay un agente al que se le dice “rellena esta solicitud de proveedor con los datos del PDF adjunto” y el agente decide, en cada paso, dónde tiene que pulsar. La inteligencia está en el modelo, no en el conjunto de reglas predefinidas.
Esto tiene tres implicaciones operativas que cambian el cálculo. La primera es resiliencia frente a cambios de UI moderados: si el botón “Guardar” cambia de la esquina inferior derecha al menú superior, un bot RPA con selector XPath se rompe; Computer Use, en muchos casos, simplemente lo encuentra porque sigue siendo un botón etiquetado “Guardar” en una pantalla coherente. La segunda es razonamiento condicional nativo: si el caso requiere decidir entre tres rutas según el contenido del documento, el modelo puede valorar el contenido y tomar la decisión, en lugar de escalarla a un humano. La tercera, y la más infravalorada en empresa, es no necesitar API: Computer Use puede operar sobre cualquier aplicación que un humano pueda usar, incluido el legacy de los 90 que jamás expondrá un endpoint.
Las limitaciones, sin embargo, son reales y hay que ponerlas sobre la mesa antes de venderle a un comité de dirección que esto reemplaza al RPA. La latencia es el primer obstáculo: cada acción del agente implica una llamada al modelo, evaluación de la pantalla y emisión de la siguiente instrucción. Donde un bot RPA hace 200 transacciones por hora, Computer Use hoy hace decenas. El coste por acción es el segundo: cada paso consume tokens, y un proceso de 30 acciones puede costar varios céntimos o más, frente a los céntimos por proceso completo del RPA. La seguridad es el tercero y, en empresa regulada, el más crítico: dar a un modelo control de mouse y teclado sobre un equipo con credenciales corporativas es una superficie de ataque que requiere sandbox, permisos mínimos y aprobación humana en acciones sensibles. Cualquier discusión seria sobre Computer Use vs RPA empresa tiene que pasar por estos tres puntos, no rodearlos.
¿En qué casos el RPA tradicional sigue siendo claramente mejor?
Hay un escenario en el que el debate Computer Use vs RPA empresa se resuelve sin discusión a favor del RPA: volumen alto, variabilidad baja, coste por operación crítico. Pensamos en reconciliaciones bancarias diarias donde un bot procesa decenas de miles de transacciones contra un extracto, en altas masivas de empleados durante una integración post-fusión, en el procesamiento de facturas estandarizadas en SAP con formato controlado. Son procesos donde cada operación cuesta céntimos en RPA, donde el script lleva años funcionando, donde la aplicación destino apenas cambia, y donde meter Computer Use sería pagar dos órdenes de magnitud más por unidad de trabajo sin ganar nada. En estos casos, el RPA tradicional gana por economía pura.
El segundo escenario donde el RPA gana es el de aplicaciones legacy estables: sistemas core bancarios, ERPs antiguos sin cambios, mainframes con interfaz verde. Aquí el coste de desarrollar un selector estable se amortiza durante años, y la fragilidad típica del RPA no se materializa porque el sistema no se mueve. Hemos visto bots RPA conectados a un AS/400 funcionando sin tocarse durante cinco años seguidos: poner Computer Use ahí sería gasto sin retorno. Adicionalmente, las aplicaciones legacy suelen ser monocromas, predecibles y poco visuales, justo donde el modelo visual de Computer Use aporta menos ventaja diferencial frente a un selector tradicional.
El tercer escenario, especialmente en sectores regulados, es el de auditoría estricta paso a paso. En banca, seguros o sanidad, el regulador exige reconstruir exactamente qué hizo el bot en cada caso: qué campo leyó, qué decisión tomó, qué valor escribió y por qué. El RPA tradicional, con sus logs determinísticos y su lógica explícita, encaja perfectamente con este requisito; un agente probabilístico que razona sobre la pantalla introduce una capa de no-determinismo que complica la trazabilidad legal. No es imposible auditar Computer Use (los logs de pensamiento del modelo ayudan), pero hoy por hoy convencer a un Compliance Officer de que un agente LLM cumple equivalente al RPA tradicional en este punto es una conversación cuesta arriba. Para procesos altamente regulados, conviene mantener RPA como motor y, si acaso, usar Computer Use solo en la capa de excepciones con humano-en-el-loop.
| Característica | RPA tradicional gana | Computer Use gana |
|---|---|---|
| Volumen | Alto (>10.000 ops/día) | Medio-bajo (<2.000 ops/día) |
| Variabilidad del caso | Baja (happy path estable) | Alta (cada caso difiere) |
| Coste por operación | Crítico (céntimos) | Tolerante (decenas de céntimos) |
| Estabilidad de la UI | Alta (legacy, ERPs) | Baja (SaaS modernos) |
| Razonamiento condicional | No requerido | Requerido |
| Disponibilidad de API | Buena | Inexistente |
| Auditoría regulatoria | Determinista necesaria | Explicable suficiente |
¿En qué casos Computer Use cambia el juego?
El primer escenario donde Computer Use desbloquea valor que el RPA no podía es el de procesos con alta variabilidad caso a caso. Pensamos en gestión de excepciones de facturas (cada proveedor mete los datos en sitios distintos del PDF), en clasificación de incidencias de soporte que requiere leer y entender el ticket antes de enrutar, en revisión de contratos donde cada cláusula está redactada de manera distinta. En estos procesos el RPA tradicional se ahoga porque su lógica predefinida no cubre la cola larga de casos, y el resultado es una tasa de excepción brutal que termina escalada a humanos. Computer Use, al razonar caso a caso, absorbe esa variabilidad sin necesidad de pre-codificar cada permutación.
El segundo es el de SaaS modernos que cambian frecuentemente: HubSpot, Salesforce, Notion, plataformas de marketing, ATS de RRHH, herramientas de finanzas como Pleo o Spendesk. Estos productos hacen releases mensuales que rompen selectors RPA con regularidad y obligan a tener un equipo de mantenimiento dedicado solo a reparar bots. Computer Use, al apoyarse en el aspecto visual y semántico de la interfaz, sobrevive a la mayoría de esos cambios. Para un Head of Operations cuyo equipo gasta el 40% del tiempo arreglando bots que se han roto por una actualización, esto no es una mejora marginal: es la diferencia entre tener automatización fiable o no tenerla.
El tercer y cuarto escenarios son los más estructurales. Procesos que exigen razonamiento condicional explícito: aprobaciones que dependen de leer un informe y aplicar política de empresa, triage de candidatos donde hay que valorar el CV antes de moverlo en el ATS, gestión de devoluciones que cruza el motivo del cliente con la política comercial. Y aplicaciones sin API pública: portales gubernamentales, herramientas de proveedores que no exponen endpoints, sistemas web heredados donde el desarrollo de un conector formal cuesta más que el proceso entero. En estos casos el RPA tradicional puede llegar, pero a costa de scripts frágiles que se rompen al menor cambio. Computer Use convierte estos procesos en automatizables a un coste de mantenimiento mucho menor, lo cual es exactamente lo que un RPA Center of Excellence necesita para seguir entregando valor incremental sin doblar plantilla.
Hay un quinto caso emergente que conviene mencionar porque hoy es minoritario pero crece: casos de exploración. Mystery shopping automatizado, QA visual de e-commerce, monitorización competitiva de pricing, comprobación de cumplimiento de SLAs en portales de terceros. Son procesos que no se podían automatizar con RPA porque no hay un happy path: el agente tiene que navegar, evaluar, decidir qué mirar y reportar. Computer Use, en este terreno, está creando categoría nueva.
¿Cómo es una arquitectura híbrida que combina RPA y Computer Use?
La pregunta correcta para una empresa con RPA Center of Excellence maduro no es “Computer Use vs RPA empresa”, es “cómo construyo una arquitectura híbrida donde cada capa hace lo que mejor sabe hacer”. El patrón que estamos viendo emerger, y que en Datalvar AI ya hemos implementado en varios clientes, sigue una lógica de orquestador inteligente + ejecutores especializados. Computer Use ocupa la capa superior como cerebro de orquestación: recibe el caso, lo analiza, decide qué subprocesos invocar y maneja las excepciones. El RPA tradicional ocupa la capa ejecutora: cada vez que el orquestador identifica una secuencia repetitiva conocida, llama a un bot RPA existente vía API o cola, y el bot la ejecuta a su velocidad y coste óptimos.
Esta arquitectura tiene tres ventajas operativas concretas. Primero, protege la inversión RPA existente: los bots que ya funcionan bien no se tocan, simplemente se convierten en “skills” invocables por el orquestador. Segundo, reduce el coste por operación promedio: el grueso del trabajo lo sigue haciendo el RPA a céntimos, y solo la capa de razonamiento y excepciones consume tokens de Computer Use. Tercero, abre la lista de procesos automatizables: aquello que antes se descartaba por variabilidad ahora entra en cartera, porque el orquestador puede absorberla y delegar la parte repetitiva al RPA cuando llega a ella.
La implementación concreta requiere tres elementos. Un bus de eventos o cola (Kafka, RabbitMQ, AWS SQS) que conecte al orquestador con los bots RPA existentes; las plataformas modernas de RPA ya exponen APIs para lanzar procesos remotamente, así que el coste de integración es bajo. Una capa de gobierno de identidades y permisos clara: el orquestador no debería tener credenciales completas, debería invocar a bots que sí las tienen para tareas específicas, manteniendo el principio de least privilege. Y un sistema de logging unificado que combine los logs deterministas del RPA con los logs de razonamiento del agente, para que auditoría y SRE puedan reconstruir qué pasó en cada caso sin saltar entre dos mundos.
| Tipo de proceso | Capa orquestadora | Capa ejecutora | Notas |
|---|---|---|---|
| Reconciliación bancaria diaria | Computer Use solo en excepciones | RPA tradicional para el flujo principal | Mantener RPA, añadir agente solo en cola de excepciones |
| Alta de empleado multi-sistema | Computer Use orquesta el caso | RPA en cada sistema (Workday, AD, Slack) | Agente decide orden y maneja errores; RPA ejecuta cada subtarea |
| Procesamiento de factura no estándar | Computer Use lee y normaliza | RPA carga el resultado normalizado en SAP | Combina extracción IA con carga determinista |
| Monitorización competitiva | Computer Use solo | N/A | RPA tradicional no aporta aquí |
| Reporte regulatorio mensual | RPA solo | N/A | Determinismo y auditoría exigen RPA puro |
¿Cuál es el coste real comparado entre RPA y Computer Use?
El análisis de coste es donde la mayoría de comparativas de Computer Use vs RPA empresa fallan, porque comparan precios de licencia con precios por token sin meter en la ecuación el coste real de mantenimiento y de excepciones. En el RPA tradicional, el coste total se descompone en cuatro partidas: licencia de la plataforma (UiPath, Automation Anywhere, Blue Prism cobran entre 5.000 y 15.000 euros por bot productivo anual en empresa media), infraestructura (VMs o robots desatendidos donde corren los bots, RDP, gestión de sesiones), desarrollo inicial (un proceso medio ronda entre 15 y 60 días-hombre dependiendo de complejidad) y, la partida menos hablada pero más relevante, mantenimiento (entre el 20% y el 40% del coste inicial al año en empresas con procesos sobre SaaS cambiantes). Cuando se suman las cuatro, el coste real por bot productivo está habitualmente entre 25.000 y 70.000 euros anuales, no los 5.000-15.000 de la licencia.
Computer Use, en cambio, se factura por consumo. El modelo de Anthropic para Claude con Computer Use cobra por tokens de entrada (la pantalla que ve, los prompts) y de salida (las acciones que emite, las reflexiones). En un proceso típico de oficina, una sesión completa puede consumir desde unos pocos céntimos a varios euros, dependiendo de cuántas pantallas el agente tenga que evaluar y cuánta cadena de razonamiento involucre. La latencia añadida también es coste indirecto: si un proceso humano tarda 5 minutos y el agente tarda 8, ese delta hay que considerarlo si el proceso es síncrono frente al cliente. La buena noticia es que el coste de desarrollo y mantenimiento baja drásticamente: no hay selectors que reparar, el “prompt” es lenguaje natural mucho más fácil de iterar, y los releases del SaaS de destino no rompen el agente con la misma frecuencia.
El punto de equilibrio, según los modelos que hacemos con clientes, suele caer alrededor de procesos con estas características: volumen entre 500 y 5.000 operaciones mensuales, tasa de excepción superior al 20%, al menos un cambio de UI material por trimestre en la aplicación destino. Por debajo de ese rango, conviene seguir con RPA tradicional puro. Por encima, conviene evaluar híbrido o Computer Use puro. El error que vemos a menudo es decidir en base a coste por operación aislado, ignorando el coste de mantenimiento; cuando se calcula bien, hay procesos donde el RPA “barato” sale 3x más caro al año que un Computer Use “caro” porque el equipo de mantenimiento se come la diferencia. Para un análisis serio recomendamos los informes de Gartner sobre RPA y la categoría emergente de Agentic Automation, donde se discute exactamente este punto de equilibrio.
| Partida de coste | RPA tradicional | Computer Use | Comentario |
|---|---|---|---|
| Licencia / consumo base | 5-15k€/bot/año | Pago por uso | RPA tiene coste fijo independiente del volumen |
| Infraestructura | 2-5k€/bot/año (VMs, RDP) | Mínima (API) | Computer Use elimina sesiones desatendidas |
| Desarrollo inicial | 15-60 días-hombre | 3-15 días-hombre | Prompt vs script |
| Mantenimiento anual | 20-40% del inicial | <10% del inicial | Aquí está el gran diferencial oculto |
| Coste por operación | Céntimos | Decenas de céntimos a euros | RPA gana en operación pura |
¿Qué seguridad y compliance hay que considerar antes de soltar Computer Use?
La seguridad es la conversación que con frecuencia se evita en los primeros meses de evaluación de Computer Use, y luego se convierte en el bloqueante real cuando se intenta llevar a producción. Hay que abordarla desde el principio. El primer concepto a interiorizar es el de blast radius: cuando un agente IA tiene control de mouse y teclado en un equipo con credenciales corporativas, lo que ese agente puede hacer si se equivoca (o si es manipulado por un prompt injection) incluye, potencialmente, todo lo que un empleado con esas credenciales podría hacer. Eso significa, en un caso límite, mover dinero, dar de baja empleados, descargar bases de datos sensibles. El RPA tradicional también tiene blast radius, pero al ser determinista la superficie de error es menor; un bot que está mal programado falla, no improvisa.
Las prácticas defensivas que estamos exigiendo en cada implementación son cuatro. Primera, sandbox aislado: el agente nunca corre en el equipo de un empleado real, corre en una VM efímera con sus propias credenciales de servicio, limitadas al mínimo. Segunda, least privilege explícito: las credenciales que el agente recibe solo permiten el subconjunto exacto de acciones del proceso (leer factura, marcar como pagada), nunca un usuario con permisos genéricos. Tercera, aprobación humana en acciones críticas: cualquier acción con impacto financiero, contractual o de datos personales debe pasar por un humano antes de ejecutarse, con un mecanismo de break-glass para emergencias auditado. Cuarta, defensa contra prompt injection: filtrado de inputs externos (correos, documentos subidos), separación clara entre instrucciones de sistema y contenido del usuario, y monitorización de comportamientos anómalos del agente.
El bloque de compliance añade requerimientos adicionales que conviene anticipar. En sectores regulados (banca, seguros, sanidad, telecos en cierta medida), el regulador va a exigir que se justifique por qué el agente tomó cada decisión. La trazabilidad de Computer Use es razonable hoy (los logs de pensamiento del modelo están disponibles), pero no es equivalente a la del RPA determinista. Hay que documentar en el modelo de control interno que ciertos procesos solo se automatizan con humano-en-el-loop y que existe revisión periódica de muestras. En materia de RGPD, hay que tener cuidado de que el agente no exfiltre datos personales en sus prompts hacia el modelo si el contrato con el proveedor no cubre adecuadamente el procesamiento. Anthropic y los demás proveedores ya ofrecen acuerdos de procesamiento de datos para empresa, pero hay que firmarlos y configurarlos correctamente. Para un marco general recomendamos revisar la guía de seguridad para agentes IA en empresa de McKinsey y los principios de NIST AI Risk Management Framework.
¿Qué caso real respalda esta arquitectura híbrida?
Trabajamos con una empresa industrial española de tamaño medio-grande (anonimizada, sector componentes para automoción, facturación >300M€) que llevaba desde 2019 con un RPA Center of Excellence consolidado sobre UiPath. Tenían unos 90 procesos automatizados en producción, mayoritariamente del back office financiero: reconciliación de pagos a proveedores, conciliación de albaranes con facturas, alta de nuevos vendors, procesamiento de facturas estándar en SAP. El equipo del CoE era de seis personas: dos developers senior, dos junior, un analista de procesos y un líder. El ROI bruto de la unidad estaba en torno a 4x sobre coste, lo cual sobre el papel parecía espectacular.
El problema, que el COO nos describió en la primera reunión con palabras textuales muy gráficas, era que tenían “doce personas a tiempo completo procesando excepciones de facturas” porque el bot RPA solo cubría el happy path (proveedores con facturas estructuradas en formatos conocidos), y la cola larga de proveedores pequeños con facturas no normalizadas se escalaba a humano. Esas doce personas representaban un coste anual cercano al medio millón de euros, y el equipo del CoE llevaba dos años intentando automatizarlas sin éxito porque la variabilidad de los formatos era inmanejable con selectors. Cuando hicimos el análisis de los procesos atascados, encajaban exactamente en el perfil que Computer Use ataca bien: alta variabilidad caso a caso, razonamiento requerido para identificar campos en cada factura, aplicación destino (SAP) estable y con bots RPA ya desarrollados para la carga final.
La arquitectura híbrida que implementamos siguió el patrón que describimos antes. Computer Use recibe la factura no normalizada, identifica visualmente los campos relevantes (proveedor, fecha, conceptos, importes, IVA), los valida contra la base de datos de proveedores, decide si es un caso aprobable automáticamente o si requiere supervisión humana, y en caso afirmativo invoca al bot RPA existente que ya cargaba facturas normalizadas en SAP. El bot RPA no se tocó: siguió haciendo lo que hacía, simplemente ahora recibía inputs del agente en lugar de un humano. Después de seis meses, el equipo de excepciones bajó de 12 FTE a 2 FTE supervisando y validando casos críticos, mientras Computer Use procesaba el 80% del volumen de la cola larga sin intervención. El coste anual del Computer Use rondó los 60.000 euros entre tokens y plataforma; el ahorro neto, descontando el coste, superó los 350.000 euros anuales. Y más importante: liberó al equipo del CoE para meter en cartera procesos que llevaban años en la lista de “no automatizable”.
¿Qué métricas hay que seguir si despliegas Computer Use en producción?
Las métricas con las que se gestionaba un RPA Center of Excellence no son suficientes para gobernar Computer Use, y conviene plantearlas desde el primer día porque luego es más difícil retrofittear. La primera métrica básica es la tasa de éxito por proceso: porcentaje de casos en los que el agente completa el objetivo sin intervención humana. En procesos maduros debería estar por encima del 85%; por debajo del 70%, probablemente el proceso no está bien acotado o la cobertura del happy path es insuficiente y conviene revisar el prompt y los ejemplos. Esta métrica hay que segmentarla por tipo de caso (variabilidad alta vs baja) para no esconder bolsas de mal funcionamiento.
La segunda es latencia media por caso, medida desde que el caso entra en cola hasta que el agente lo cierra. Esto importa por dos motivos: experiencia de cliente si el proceso es síncrono, y planificación de capacidad si es batch. Un agente que tarda el doble de lo previsto puede acumular cola y degradar el servicio sin que aparente “fallar”. A esto hay que sumar coste por acción y por caso: tokens consumidos, tokens generados, llamadas al modelo. Esto se debería traducir a euros y compararse contra el coste humano equivalente para mantener visibilidad financiera continua. Una práctica que recomendamos es alertar cuando el coste por caso supere un umbral predefinido, porque suele ser señal de que el agente está entrando en loops o tomando rutas innecesariamente largas.
La tercera métrica crítica, y muchas veces olvidada, es la tasa de intervención humana y su desagregación: cuántos casos fueron a humano por baja confianza del agente (positivo, sistema funciona como diseñado), cuántos por error real (negativo, hay que ajustar) y cuántos por excepción no anticipada (oportunidad de ampliar cobertura). Esta tasa debe trackearse semana a semana porque marca la madurez del proceso. Adicionalmente, en entornos regulados, hay que mantener métricas de deriva del comportamiento del modelo: comparativa de decisiones del agente sobre casos test conocidos al actualizar versión del modelo, para detectar cambios que afecten al control interno. Para un marco más amplio de KPIs de automatización inteligente, los informes de Forrester sobre Intelligent Automation ofrecen plantillas adaptables.
| Métrica | Umbral típico | Frecuencia revisión |
|---|---|---|
| Tasa de éxito por proceso | >85% en procesos maduros | Semanal |
| Latencia media por caso | Específica al SLA del proceso | Semanal |
| Coste por caso | <30% del coste humano equivalente | Semanal |
| Tasa de intervención humana | Tendencia descendente o estable | Semanal |
| Deriva del modelo en casos test | Cambios <5% en decisiones | Al actualizar versión |
| Incidentes de seguridad | 0 | Continuo, alertas en tiempo real |
¿Cuáles son los próximos pasos si quieres evaluar esto en serio?
Si has leído hasta aquí y estás en un puesto con responsabilidad sobre operaciones, automatización o IT en una empresa que ya tiene RPA, el camino que recomendamos tiene cuatro pasos concretos y secuenciales. Primero, identificar tres procesos candidatos en tu inventario actual: uno donde el RPA esté funcionando bien (no tocar, control), uno donde el RPA tenga una tasa de excepción superior al 20% (candidato a híbrido) y uno que esté en la lista de “no automatizable” por variabilidad (candidato a Computer Use puro). Este ejercicio se hace en una semana revisando dashboards del RPA CoE y conversando con los responsables de proceso.
Segundo, montar un piloto técnico acotado sobre el candidato híbrido, con duración de 8-12 semanas y un objetivo medible (por ejemplo: reducir tasa de excepción humana del 25% al 10%). El piloto debe ejecutarse en sandbox con datos reales pero sin impacto en producción, y debe incluir desde el día uno la arquitectura de seguridad descrita antes (credenciales mínimas, aprobación humana, audit logs). El piloto no es solo técnico: incluye el go-to-process de cómo se integra con el equipo humano de excepciones, cómo se entrena al supervisor, cómo se documenta para auditoría. Tercero, medir contra baseline con las métricas que detallamos en la sección anterior: éxito, latencia, coste por caso, intervención humana. Cuatro semanas de operación con métricas estabilizadas son suficientes para un business case sólido.
Cuarto, decidir y escalar. Si el piloto demuestra el ROI, el plan de escalado debe incluir tres ejes: cartera (qué procesos pasan a híbrido y en qué orden), gobierno (cómo evoluciona el RPA CoE para incorporar la disciplina de agentes IA) y plataforma (qué proveedor de Computer Use se estandariza, cómo se integra con la orquestación RPA existente, cómo se centraliza el logging). En Datalvar AI acompañamos a clientes en cada uno de estos pasos, y la observación que repetimos siempre: este cambio no es un proyecto IT, es una evolución del modelo operativo de la unidad de automatización. Si lo gestionas como un proyecto puntual, fallarás. Si lo gestionas como evolución, en 18 meses tienes un CoE de automatización inteligente que mete en producción procesos que antes ni entraban en cartera.
Preguntas frecuentes
¿Computer Use va a reemplazar al RPA tradicional a corto plazo?
No en el horizonte de 2-3 años, y probablemente no del todo nunca para ciertos perfiles de proceso. El RPA tradicional seguirá siendo más eficiente económicamente en procesos de alto volumen, baja variabilidad, aplicaciones estables y requisitos de auditoría determinista. El error que vemos en algunas conversaciones es plantearlo como sustitución cuando la realidad es complementariedad. Computer Use vs RPA empresa no es una guerra de tecnologías, es una decisión de arquitectura por proceso.
Lo que sí va a cambiar es la composición de la cartera del RPA Center of Excellence. Procesos que hoy están en “no automatizable” entrarán en cartera como Computer Use puro, procesos con alta tasa de excepción se reconvertirán en híbridos y los procesos masivos seguirán como RPA tradicional. En tres años, una unidad de automatización madura tendrá tres tipos de proceso en producción de manera estable, y el papel del líder será orquestar la convivencia.
¿Qué proveedor de Computer Use elegir hoy para empresa?
A junio de 2026, la opción más madura para entornos empresariales sigue siendo Anthropic con Claude Computer Use por la combinación de capacidades del modelo, postura de seguridad y disponibilidad de acuerdos enterprise (DPA, residencia de datos, controles SOC 2). OpenAI Operator y Google Project Mariner son alternativas válidas en evaluación, especialmente si tu empresa ya tiene estandarizado el resto de stack en alguno de esos proveedores.
Más relevante que el proveedor concreto es no atarse: la capa de orquestación que construyas debería abstraer al proveedor del agente para poder cambiarlo en el futuro. Es exactamente la misma disciplina que se aplicaba en RPA cuando se evaluaba UiPath vs Automation Anywhere vs Blue Prism. La diferencia es que el mercado de Computer Use es más joven y va a evolucionar más rápido los próximos 18 meses, así que la opcionalidad vale más.
¿Cuánto cuesta arrancar un piloto de Computer Use?
Un piloto bien acotado, de 8-12 semanas sobre un proceso concreto en sandbox, suele costar entre 30.000 y 80.000 euros incluyendo arquitectura, desarrollo del agente, integración con sistemas existentes, definición de métricas y soporte de cambio. El coste de tokens del agente durante el piloto suele ser una fracción menor, en el orden de 500-3.000 euros dependiendo del volumen de casos.
Más allá del coste directo, conviene presupuestar tiempo del equipo interno: dueño del proceso, RPA CoE lead, IT security, compliance si aplica. El piloto sin participación interna seria no genera la curva de aprendizaje organizativa que es el verdadero entregable, así que tirar de consultora externa “llave en mano” y no involucrarse es el camino más rápido a tener una tecnología que nadie sabe gobernar internamente.
¿Cómo justifico esto ante un CFO escéptico que ya defendió el ROI del RPA?
La conversación no debería plantearse como “esto es mejor que el RPA”, sino como “el RPA sigue siendo rentable en estos procesos y, en estos otros que llevamos años sin poder automatizar o que tienen una cola de excepción cara, esta tecnología abre ROI adicional”. El CFO no quiere oír que su inversión anterior fue insuficiente; quiere oír que va a generar más retorno expandiendo la cartera, no cambiando lo que ya funciona.
El business case se construye con datos concretos: cuántas FTE consumen excepciones hoy, cuántos procesos están en la lista de “no automatizable”, cuál es el coste de mantenimiento del RPA actual (esa partida suele ser invisible y al hacerla visible cambia la conversación). En Computer Use vs RPA empresa, los números honestos suelen vender solos cuando se ponen sobre la mesa con sinceridad operativa.
¿Qué pasa con la auditoría y el control interno?
Es el punto donde más cuidado hay que tener, especialmente si la empresa está en sector regulado. Computer Use es auditable (los logs de pensamiento del modelo, las acciones emitidas, las pantallas evaluadas se pueden guardar) pero no es determinista al mismo nivel que el RPA tradicional. Eso significa que el modelo de control interno hay que adaptarlo: definir qué acciones del agente requieren aprobación humana, qué muestras se revisan periódicamente, qué KRIs se monitorizan.
Lo que estamos viendo en clientes regulados es un patrón de agente con humano-en-el-loop por defecto en producción, donde el agente prepara y propone pero un humano confirma antes de cualquier acción material. Es menos eficiente que la operación totalmente autónoma, pero pasa el filtro de control interno con holgura y aun así libera al equipo humano de la parte de identificación y preparación, que era el grueso del esfuerzo.
¿Cómo se integra Computer Use con el orquestador RPA existente (UiPath Orchestrator, etc.)?
La integración estándar es vía API: las plataformas RPA modernas exponen endpoints para lanzar procesos remotamente, consultar estado y recibir resultados. El agente Computer Use, desde su capa de orquestación, hace llamadas a estos endpoints como invocaría cualquier otra herramienta. UiPath, Automation Anywhere y Blue Prism tienen todas APIs documentadas para esto, y la mayoría de implementaciones que hacemos se montan en pocos días de integración técnica.
Más interesante que la conexión técnica es decidir dónde vive la inteligencia de orquestación. En arquitecturas maduras, vemos dos patrones: o bien el agente IA es el orquestador top-level y el RPA Orchestrator queda como “ejecutor de tareas”, o bien el RPA Orchestrator sigue siendo el director general y el agente IA es invocado como un “skill especial” para casos que requieren razonamiento. No hay una respuesta única; depende de la madurez del CoE y de qué porcentaje de la cartera futura va a ser híbrida o de Computer Use puro.
¿Qué perfiles de equipo necesito para gestionar Computer Use en producción?
El perfil del RPA developer tradicional cambia, no desaparece. Las habilidades de análisis de proceso, integración técnica y gobierno operativo siguen siendo críticas. Lo que se añade es disciplina de prompt engineering aplicada a operaciones, comprensión de modelos LLM, diseño de arquitecturas humano-en-el-loop y monitorización de calidad probabilística. En la mayoría de clientes el equipo existente del RPA CoE absorbe esta evolución con formación de 2-3 meses; en algunos casos se incorpora un perfil más senior con background en ML/IA aplicada para liderar la transformación.
El perfil que sí cobra mucho peso es el de operaciones de IA en producción (a veces llamado AI Ops o LLMOps): monitorización de latencia y coste de tokens, gestión de actualizaciones de modelo, detección de deriva, gobierno de prompts versionados. Es un perfil que el RPA tradicional no necesitaba con esta intensidad y que en una arquitectura híbrida pasa a ser parte permanente del CoE.
¿Quieres aplicar esto en tu negocio?
30 minutos. Sin compromiso. Salimos con un mapa de oportunidades concreto.