Las demostraciones son fascinantes. Una IA recorre un flujo de reservas complejo, cambia de una aplicación a otra, rellena formularios administrativos y completa de forma autónoma tareas que duran varias horas. En 2024–2025, Computer Use de Anthropic, Operator de OpenAI, Project Mariner de Google y una oleada de startups mostraron agentes capaces de manejar ordenadores como las personas.
En 2026, estas herramientas son reales y funcionan. Algunas empresas ya las implantan con éxito en producción. Sin embargo, esas implantaciones no se parecen a las demostraciones: están mucho más acotadas, más restringidas y rodeadas de salvaguardas. Este artículo explica los patrones que separan una demostración de un sistema de producción.
Ya explicamos los fundamentos en un artículo de nivel intermedio. Este va más allá: patrones de producción, fallos recurrentes, viabilidad económica y cómo implantar un sistema de control del ordenador que resulte útil a gran escala.
La realidad de producción
Algunos patrones que observamos en implementaciones reales de producción:
Patrón 1: predominan las tareas acotadas. Las implantaciones funcionan con tareas específicas y bien definidas, no para “hacer cualquier cosa” ni “manejar cualquier sitio web”. Se centran en flujos de trabajo concretos dentro de sitios concretos.
Patrón 2: alcance estricto. Las tareas están muy delimitadas. El agente solo puede ejecutar determinadas acciones en sitios concretos. Todo lo que quede fuera del alcance provoca una detención, no una improvisación.
Patrón 3: flujos de trabajo grabados antes que exploración autónoma. Muchas implantaciones usan flujos grabados —pasos definidos una vez y repetidos con pequeños ajustes— en lugar de agentes plenamente autónomos. Son más fiables y fáciles de mantener.
Patrón 4: supervisión humana para acciones con consecuencias. Toda acción con consecuencias importantes —financieras, legales o de cara al cliente— pasa por revisión humana.
Patrón 5: monitorización exhaustiva. Se registra cada acción, se detectan anomalías, existen interruptores de emergencia y el equipo de operaciones vigila los paneles.
Patrón 6: disciplina de costes. La viabilidad económica importa. Muchas propuestas de “IA que lo hace todo” no compiten con las alternativas humanas o de RPA.
Patrón 7: especializados frente a generales. Las implantaciones suelen utilizar modelos o configuraciones especializados, no un modelo general de control del ordenador para cualquier tarea.
Estos patrones reflejan el aspecto habitual de la IA en producción: un alcance más limitado y salvaguardas más sólidas de lo que sugiere el marketing.
Dónde destacan en producción los agentes que controlan ordenadores
Categorías concretas de tareas en las que un agente que controla el ordenador es la herramienta adecuada:
1. Extracción de datos de sitios sin API
Muchas herramientas empresariales, portales administrativos y pequeños servicios B2B carecen de API, o la que ofrecen presenta grandes lagunas. Los agentes pueden extraer datos manejando directamente la interfaz de usuario.
Ejemplos en producción:
- Descargar facturas de 50+ portales de proveedores.
- Extraer datos de casos de sitios web de sistemas judiciales.
- Revisar las páginas de precios de la competencia.
- Agregar datos de portales de informes de cumplimiento normativo.
Cuando la alternativa consiste en que una persona haga clics repetitivos, el control automatizado del ordenador es una opción clara.
2. Cumplimentación de formularios a gran escala
Enviar el mismo tipo de formulario a muchos sitios diferentes. Cada sitio es ligeramente diferente; una API sería ideal pero no existe.
Ejemplos:
- Aplicaciones gubernamentales (cada agencia tiene su propio portal).
- Informes de cumplimiento.
- Incorporación de clientes en sistemas de proveedores.
- Configuración de cuentas para herramientas SaaS.
3. Pruebas de interfaz de usuario y calidad
Estos agentes resultan útiles para el control de calidad. Pueden recorrer aplicaciones, probar flujos de usuario e informar de problemas.
Ejemplos:
- Pruebas de extremo a extremo de aplicaciones web.
- Pruebas de regresión visual.
- Auditorías de accesibilidad.
- Validación de flujos de usuario en múltiples dispositivos.
Se aproxima a la RPA, pero añade la flexibilidad de la IA para adaptarse a cambios en la interfaz.
4. Flujos de trabajo entre aplicaciones
Tareas que abarcan múltiples aplicaciones sin un punto de integración único.
Ejemplos:
- Extraer datos de un CRM, formatearlos y subirlos a una herramienta de análisis.
- Tomar tickets de soporte al cliente, crear tareas en una herramienta de proyectos, actualizar el estado en un CRM.
- Agregar informes de múltiples herramientas internas.
Cuando no puedes o no quieres integrar las aplicaciones de forma directa, un agente ofrece un puente flexible.
5. Procesos repetitivos de múltiples pasos
Tareas que una persona repite una y otra vez.
Ejemplos:
- Incorporación de nuevos clientes mediante un proceso de 30 pasos.
- Conciliación de datos entre dos sistemas semanalmente.
- Generación de informes periódicos que requieren extraer datos de múltiples fuentes.
Si un proceso está bien definido, se repite con frecuencia y actualmente exige clics manuales, es un buen candidato.
Dónde siguen fallando
En el otro extremo están las tareas para las que estos agentes aún no están preparados en producción.
1. Tareas que requieren juicio
“Encuéntrame un buen proveedor”. Los agentes pueden recorrer sitios de proveedores, pero no juzgar cuál responde mejor a tus necesidades específicas.
2. Tareas con patrones de interfaz de usuario nuevos
Ante un sitio nuevo que nunca han visto, los agentes tienen dificultades para descubrir convenciones de interfaz poco habituales. Se desenvuelven mejor con patrones comunes —formularios, listas y menús de navegación— que con diseños personalizados.
3. Tareas con medidas anti-bot fuertes
Muchos sitios detectan y bloquean activamente la automatización. Los agentes pueden sortear estas medidas con esfuerzo, pero entran en un juego constante del gato y el ratón que rara vez compensa.
4. Acciones individuales de alto riesgo
Enviar un pago, firmar un documento legal, publicar públicamente en nombre de alguien. El alcance de una acción equivocada es grande; la revisión humana es esencial.
5. Tareas que requieren contexto del mundo real
El agente solo ve lo que aparece en pantalla. Desconoce tu relación con ese cliente, el contexto reciente del equipo o la situación política. Las tareas que dependen de ese contexto fallan.
6. Exploración abierta
“Encuentra la mejor oferta” o “investiga a fondo a esta persona” son tareas sin criterios claros de finalización. Los agentes se atascan o se detienen demasiado pronto.
La arquitectura
Un sistema de producción para agentes que controlan ordenadores consta de estas capas:
┌─────────────────────────────────────┐
│ Orchestration │ Schedules, retries, escalations
├─────────────────────────────────────┤
│ Task definition + scope │ What the agent does and doesn't do
├─────────────────────────────────────┤
│ Agent runtime (Computer Use SDK) │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ Browser / desktop environment │ Isolated, sandboxed
├─────────────────────────────────────┤
│ Authentication and session │ Credentials, cookies, MFA handling
├─────────────────────────────────────┤
│ Result handling │ Capture, validate, store
├─────────────────────────────────────┤
│ Monitoring + alerts │ Real-time observability
└─────────────────────────────────────┘
Revisaremos estas capas una por una.
Definición de tarea
El paso más importante. Define lo que hace el agente, de forma estrecha.
Una buena definición de tarea incluye:
Desencadenante. ¿Qué inicia la tarea? (Programación temporal, evento o acción manual.)
Entradas. ¿Qué datos tiene el agente? (Registro específico, datos estructurados de formulario.)
Alcance. ¿Qué sitios, acciones y rutas de la interfaz están permitidos?
Criterios de éxito. ¿Cómo se ve la finalización?
Condiciones de detención. ¿Qué provoca la finalización anticipada?
Salida. ¿Qué datos devuelve el agente?
Semántica de errores. ¿Cómo se clasifican y notifican los errores?
Una tarea mal definida: “Enviar nuestro informe de cumplimiento semanal.”
Una tarea bien definida:
Task: Submit weekly compliance report to portal X.
Trigger: Cron, every Monday at 9 AM.
Inputs:
- Report data file (CSV) from /reports/weekly.csv
- Submitter info from environment variables (name, ID).
- Credentials from secrets manager.
Scope:
- Site: https://portal.example.gov/submit (and subpaths)
- Allowed actions: navigate, click, type, upload, submit, screenshot.
- Forbidden: visit external sites, change account settings, navigate away from submission flow.
Success criteria:
- Receive confirmation page with submission ID.
- Capture submission ID.
Stop conditions:
- Confirmation received: success.
- CAPTCHA: escalate to human.
- Login failure: escalate to human.
- Form validation error: report and stop.
- Timeout 5 minutes: report and stop.
Output:
- Submission ID.
- Screenshot of confirmation page.
- Timestamp.
Errors:
- Validation: log, notify owner, do not retry.
- Auth: log, notify ops, do not retry.
- Network: retry once, then escalate.
Este es el nivel de precisión propio de producción. “Enviar el informe” es lo que se ve en las demostraciones.
Aplicación del alcance
El alcance no es solo una descripción: se aplica durante la ejecución.
Lista de URLs permitidas. El agente solo puede navegar a URLs que coincidan con un patrón definido. Fuera de la lista, la navegación está bloqueada.
Filtrado de acciones. Solo se permiten determinados tipos de acciones. La capacidad general de “manejar el ordenador” se sustituye por una lista explícita de acciones autorizadas.
Filtrado de elementos. Algunas páginas contienen elementos con los que el agente nunca debe interactuar —configuración, cierre de sesión o botones peligrosos—. Pueden excluirse de la capa de percepción.
Límites de tiempo. Las tareas tienen máximos estrictos. Si no terminan en N minutos, se cancelan.
Límites de pasos. Las tareas tienen límites de pasos. La misma lógica que los bucles del agente.
La implementación varía según la plataforma: Computer Use de Anthropic, Operator de OpenAI y Browserbase ofrecen mecanismos diferentes. El principio es universal: aplica el alcance durante la ejecución, no te limites a describirlo en el prompt.
Autenticación
Es un desafío constante. Las implantaciones en producción deben autenticar la sesión del agente.
Sesiones preautenticadas. Una persona inicia sesión una vez; se capturan las cookies o los tokens de sesión y el agente trabaja dentro de esa sesión. Se renuevan cuando sea necesario.
Cuentas de servicio. Cuentas dedicadas para el agente (si el sitio las admite). Permisos limitados, registro de auditoría.
Inyección de credenciales. El agente recibe las credenciales durante la ejecución, las usa para iniciar sesión y después las descarta. Se requiere almacenamiento y tratamiento seguros.
Manejo de MFA. Un desafío real. Opciones:
- Usar secretos TOTP que el agente puede calcular.
- Enviar la solicitud de MFA a una persona para su aprobación.
- Usar cuentas/sitios que permitan tokens API en lugar de MFA.
OAuth. En sitios modernos, los flujos OAuth funcionan bien: el agente obtiene un token mediante un flujo que una persona ha aprobado previamente.
El patrón: los agentes nunca deben utilizar el acceso personal de un usuario a sus cuentas. Deben disponer de credenciales limitadas, auditables y revocables.
Validación de resultados
Cuando el agente afirme que ha terminado correctamente, verifica el resultado.
Capturar artefactos. Capturas de pantalla, archivos descargados y datos de salida. No confíes en el informe del agente: comprueba las pruebas.
Verificar condiciones de éxito. ¿El formulario realmente se envió? ¿Hay una confirmación? ¿Los datos eran correctos?
Verificación cruzada. Si puedes verificar el éxito a través de un canal diferente (una API, una confirmación por correo electrónico, una verificación en la base de datos), hazlo.
Detección de anomalías. ¿La ejecución fue inusualmente larga, corta o cara? Investiga cualquier anomalía.
El patrón: presupón que el agente puede equivocarse. Debes contar con una verificación independiente de su informe.
Manejo de errores
Las tareas de control del ordenador pueden fallar de muchas formas. Clasifica y gestiona cada una:
Errores de red. Sitio caído o tiempo de espera agotado. Reintenta con espera exponencial.
Fallo de autenticación. Inicio de sesión fallido, sesión expirada. Refresca credenciales o escala.
Cambios en la interfaz de usuario. El sitio ha cambiado y no se encuentra el elemento esperado. Detén la ejecución y avisa al equipo de mantenimiento.
Errores de validación. Entrada de formulario rechazada. Registra, notifica, no reintenta ciegamente.
Detección anti-bot. CAPTCHAs o bloqueos. Escala el caso y considera añadir el sitio a una lista de exclusión.
Confusión del agente. El agente se atasca, repite acciones o se desvía del flujo previsto. Detén la ejecución, registra lo ocurrido e investiga.
Cuota/límite de frecuencia. El sitio ha limitado la frecuencia del agente. Espera y reintenta, o reprograma la tarea.
Cada categoría requiere una respuesta distinta. Patrón deficiente: “el agente falló; reintenta”. Patrón correcto: “el agente falló en la categoría X; sigue el procedimiento X”.
Monitorización
Registra cada acción, traza cada ejecución y haz visible cada anomalía.
Registros por ejecución:
- Marcas de inicio/finalización.
- Todas las acciones tomadas.
- Todas las capturas de pantalla.
- Resultado (éxito/fallo/escalado).
- Coste.
- Métricas de rendimiento.
Panel de ejecuciones: el equipo de operaciones puede ver las ejecuciones activas, los fallos recientes y la profundidad de la cola.
Métricas agregadas:
- Tasa de éxito por tipo de tarea.
- Distribución de latencia.
- Coste por ejecución.
- Tasa de anomalías.
Alertas:
- La tasa de éxito cae por debajo del umbral.
- El coste por ejecución aumenta.
- Tipos específicos de fallo aumentan.
- La interfaz de usuario del sitio podría haber cambiado (múltiples fallos recientes en el mismo paso).
Esta monitorización permite detectar los problemas antes de que se conviertan en incidentes.
La economía
La pregunta directa: ¿controlar el ordenador con un agente resulta más barato que la alternativa?
Costes:
- Coste por ejecución: normalmente €0.50-€5 según la complejidad de la tarea (las llamadas a modelos de visión son caras).
- Infraestructura: entorno de ejecución gestionado (Browserbase, similar) o autoadministrado.
- Mantenimiento: las tareas dejan de funcionar cuando cambian los sitios. Exigen cierto trabajo continuo.
Alternativas:
- Persona a €30/hora: una tarea de 10 minutos cuesta €5. Una tarea de 1 minuto cuesta €0.50.
- Herramientas RPA: menor coste por ejecución, pero requieren una automatización estructurada.
- Integración directa de API: mucho más barata por llamada, pero requiere que la API exista.
- Externalización en países con menores costes laborales: €5-10/hora, con un cálculo similar al del personal interno.
La economía favorece el control del ordenador mediante agentes cuando:
- El sitio no tiene API.
- La tarea dura lo suficiente para que la automatización amortice los costes fijos.
- El volumen es suficiente para que el tiempo de trabajo manual se acumule.
- El sitio es relativamente estable (bajo coste de mantenimiento).
La economía no favorece este enfoque cuando:
- Existe una API (úsenla).
- La tarea es corta e infrecuente.
- El sitio cambia constantemente.
- La tarea presenta demasiados casos límite (alto coste de mantenimiento).
Ejercicio útil: estima el coste por tarea del agente frente al de una persona, multiplícalo por el volumen y compara.
Patrones de producción que funcionan
Algunos patrones de implementaciones exitosas:
Patrón 1: El enfoque de “receta grabada”
Para tareas acotadas y de gran volumen, graba una vez el flujo de trabajo con pasos explícitos y haz que el agente lo repita para cada entrada con pequeños ajustes.
Este enfoque se acerca a la RPA tradicional, pero conserva la flexibilidad de la IA para gestionar variaciones menores, como un botón que cambia ligeramente de posición o un diálogo de confirmación adicional.
Resulta mucho más fiable que una operación plenamente autónoma.
Patrón 2: El patrón de “extraer y enviar”
Muchos flujos de trabajo tienen dos fases:
- Extraer datos de algún lugar.
- Enviar datos a algún lugar.
Separar ambas fases en distintas ejecuciones del agente —o recetas— simplifica el sistema. Cada fase tiene criterios de éxito más claros y sus fallos no se propagan a la otra.
Patrón 3: El patrón de “punto de control humano”
El agente realiza de forma autónoma el trabajo preliminar y después muestra un estado “listo para actuar” que requiere aprobación humana. Una persona revisa y aprueba; entonces el agente ejecuta la acción.
Se utiliza para pagos, publicaciones públicas y envíos sensibles. El agente ahorra tiempo en el trabajo preliminar y una persona detecta posibles errores.
Patrón 4: El patrón de “agente especialista”
En lugar de un agente general, utiliza agentes especializados en tareas concretas. Cada uno se configura, prueba y mantiene para su flujo de trabajo.
Un agente general “operar cualquier sitio web” es difícil de mantener. Un agente “enviar nuestro informe de cumplimiento semanal” es sencillo.
Patrón 5: El patrón de “volver a RPA”
Cuando la flexibilidad de la IA no sea necesaria —el sitio es estable y el flujo está fijado—, vuelve a la RPA tradicional con scripts de Playwright o Selenium. En esos casos resulta más barata, rápida y fiable.
Usa agentes que controlan el ordenador solo cuando la flexibilidad de la IA aporte valor.
Patrón 6: El patrón de “ejecución en lotes”
No ejecutes agentes bajo demanda para tareas de gran volumen. Agrupa el trabajo y ejecuta los agentes en paralelo conforme a una programación.
Ejemplo: en lugar de “el usuario envía una solicitud y el agente se ejecuta de inmediato”, coloca las solicitudes en una cola y ejecuta agentes en lotes de 15 minutos. Así se nivela la carga y se simplifica la arquitectura.
Lo que puede salir mal
Una lista breve de modos de fallo habituales:
El sitio ha cambiado. El agente funcionó perfectamente durante 6 meses, pero un rediseño lo rompe todo. Sin monitorización, te enteras por usuarios enfadados.
La detección anti-bot se actualizó. El sitio implementó detección de bots. Las ejecuciones del agente fallan cada vez más. Finalmente, la cuenta se bloquea.
Espiral de costes en una tarea atascada. El agente queda atrapado en una página confusa. Cada ciclo exige una llamada al modelo de visión: €100 en una hora.
Acción equivocada. El agente hizo clic en el botón equivocado. Canceló un pedido en lugar de confirmarlo. O envió un mensaje a la persona equivocada.
Bloqueo en MFA. El agente no puede completar la MFA. Las ejecuciones en producción se atascan y la cola crece.
Cuenta bloqueada. El sitio detectó actividad inusual, suspendió la cuenta. Todas las tareas similares se rompen hasta que se restaure la cuenta.
Fuga de credenciales. El agente expuso accidentalmente credenciales en un registro o captura de pantalla. Incidente de seguridad.
Problema de privacidad. El agente capturó accidentalmente información personal en capturas de pantalla que se registraron.
La mayoría puede prevenirse con los patrones anteriores, pero todos han ocurrido en implantaciones reales. Incorpora las defensas adecuadas.
La economía: un ejemplo calculado
Este es un escenario modelizado, no un caso de cliente, y lo indicamos expresamente: un modelo de ROI que puedes recalcular con tus propios datos es más útil que un “caso anonimizado” imposible de verificar.
Tarea: enviar informes periódicos de cumplimiento normativo a 12 portales de organismos diferentes. En Estonia, piensa en los portales que todavía exigen introducir los datos formulario por formulario: informes de e-MTA, encuestas de Statistics Estonia y trámites a escala de la UE.
Referencia manual: 12 portales × 90 minutos = 18 horas/semana. Con un coste laboral total de €30/hora, son €540/semana.
Automatizado:
- Ejecuciones del agente: 12 × ~€2 (modelo de visión + infraestructura del navegador) = €24/semana.
- Mantenimiento: ~2 horas de ingeniero/mes a €100/hora ≈ €46/semana. Los portales cambian; presupuesto para esto o la automatización muere silenciosamente.
- Gestión de fallos: con una tasa de éxito autónoma del 92%, aproximadamente una ejecución por semana se escala a una persona. Reserva 30 minutos para revisarla: €15/semana.
- Total: ~€85/semana, ahorrando ~€455/semana ≈ €23,500/año.
Dos cifras determinan si este cálculo se sostiene.
Primero, la tasa de éxito. Por debajo de aproximadamente el 85%, la atención humana consume el ahorro. Mídela durante un período paralelo de dos semanas antes de confiar en el sistema; no la tomes de una diapositiva comercial.
Segundo, la carga de mantenimiento. Cada rediseño de un portal provoca un fallo, y un conjunto de 12 portales sufrirá varios al año. Si no puedes asignar a alguien para corregirlos en el plazo de un día laborable, el proceso manual resultaba más barato.
Lista de verificación para implementación
Si vas a implantar en producción un sistema de agentes que controlan ordenadores:
- La tarea es estrecha y bien definida.
- El alcance se impone en tiempo de ejecución, no solo se describe.
- Presupuestos de pasos/tiempo/coste definidos.
- Estrategia de autenticación con credenciales seguras.
- Medidas anti-bot contempladas (usar cuentas legítimas y respetar los límites de frecuencia).
- Clasificación y gestión de errores.
- Validación de resultados independiente del informe del agente.
- Monitorización y alertas.
- Interruptores de emergencia.
- Supervisión humana para acciones con consecuencias.
- Registro de auditoría.
- Gestión de la privacidad y la PII.
- Estructura de costes viable frente a las alternativas.
- Plan de mantenimiento cuando los sitios cambien.
Ninguno de estos puntos es trivial. Omitir cualquiera de ellos crea un riesgo.
Ajusta la tecnología a la tarea
En producción, los agentes que controlan ordenadores y navegadores son distintos de las demostraciones virales: tareas acotadas, salvaguardas sólidas, monitorización intensa, puntos de control humanos y una economía realista.
En las tareas adecuadas son realmente útiles: extracción de datos de sitios sin API, cumplimentación masiva de formularios, flujos entre aplicaciones y trabajo repetitivo en interfaces. Las implantaciones reales ahorran tiempo y dinero.
Para las tareas inadecuadas —juicio abierto, interfaces nuevas o acciones individuales de alto riesgo— todavía no están preparados. No intentes forzarlos.
La clave consiste en ajustar la tecnología a la tarea. Bien implantados, estos agentes son una herramienta útil dentro del stack de IA de producción. Mal implantados, se convierten en una forma cara de introducir nuevos modos de fallo.
Elige tareas acotadas. Incorpora salvaguardas. Monitoriza con rigor. Mantén el sistema de forma constante. Así es como estos agentes se ganan un lugar en los sistemas de producción.
