Contexto Técnico
Veo regularmente la misma solicitud: «quiero un agente local que controle el escritorio con confianza y sin nube». Y casi siempre, la primera idea es tomar una LLM multimodal SotA, alimentarla con capturas de pantalla y definir los clics mediante coordenadas (x,y) o una cuadrícula superpuesta.
He analizado tales prototipos y cada vez me topo con la misma inconsistencia básica: la visión resuelve bien el «encuentra el botón y pulsa», pero comienza a degradarse en el «haz scroll y lee». El desplazamiento se convierte en un bucle: captura → reconocimiento de texto/elementos → decisión → scroll → nueva captura. La latencia y el coste crecen linealmente con la longitud de la página, mientras que la calidad cae de forma no lineal.
El segundo problema es la fragilidad de las coordenadas. Cualquier cambio en el diseño, escalado, diferentes DPI, tooltips, animaciones o simplemente una «fuente ligeramente diferente» rompe el vínculo. El modelo se ve obligado a volver a «mirar» la pantalla constantemente porque carece de anclajes semánticos estables.
El tercero es el coste computacional de la ejecución local. Para que los modelos multimodales trabajen cómodamente, generalmente se necesita una GPU seria (a menudo más de 24GB VRAM), e incluso entonces pagas con tiempo: el contexto de las imágenes es pesado y las pasadas repetidas por la pantalla consumen el ancho de banda.
Cuando diseño la arquitectura de IA para la automatización de escritorio, casi siempre trato de alejarme de los «píxeles» hacia la estructura: árbol de accesibilidad (Accessibility tree), UI Automation, DOM (en controles web) y, a veces, la API de la aplicación si existe. En tales representaciones, un elemento es un rol, un nombre, un estado y una jerarquía, no un área en la pantalla.
Impacto en el Negocio y la Automatización
Si construyes una «automatización con IA» sobre una red de visión, te compras dos partidas de gastos: un runtime caro y un soporte caro. El runtime es costoso debido a la inferencia multimodal y las frecuentes iteraciones de observación. El soporte es caro porque cualquier actualización de la interfaz se convierte en una regresión que no se puede cubrir de manera estable con un «selector», solo con un nuevo ciclo de observaciones.
He visto cómo las empresas terminan limitando al agente a escenarios cortos: abrir una aplicación, presionar 2 o 3 botones, completar un formulario. Esto funciona, pero solo hasta el momento en que se necesita un «operador»: leer listas largas, comparar cadenas, desplazar tablas, recopilar datos de varias ventanas.
¿Quién gana con el acceso estructural? Aquellos cuyos procesos están vinculados a acciones repetibles: back-office, compras, logística, conciliaciones contables, procesamiento de solicitudes, control de calidad. Allí, el control semántico (a través de accesibilidad/DOM) brinda previsibilidad y velocidad, y el modelo se utiliza para la toma de decisiones, no para adivinar píxeles.
¿Quién pierde? Los equipos que intentan «hacer automatización con IA» sin una capa de integración, esperando que la LLM «vea y resuelva» por sí misma. En nuestros proyectos en Nahornyi AI Lab, establezco una capa separada de herramientas: extracción de la estructura de la UI, normalización a un formato único, acciones seguras y solo entonces, planificación del agente.
Al final, la «implementación de IA» se convierte en una tarea de ingeniería: no elegir el modelo más inteligente, sino ensamblar un circuito de control donde el modelo recibe primitivas estables (buscar, enfocar, leer, establecer, desplazar, consultar tabla) y no gasta tokens en ruido visual.
Visión Estratégica y Análisis Profundo
Mi pronóstico es simple: los agentes locales de escritorio se volverán masivos no cuando salga un modelo que «vea» aún mejor, sino cuando aparezcan primitivas de agente estandarizadas sobre la estructura de la UI. La visión permanecerá como un sensor de respaldo: para aplicaciones sin accesibilidad, para VDI/escritorios remotos, para lienzos no estándar.
Ya estoy integrando un patrón híbrido en la arquitectura de soluciones de IA para empresas: «estructura por defecto, visión por necesidad». En la práctica, se ve así: el agente primero trabaja mediante accesibilidad/DOM, y solo si no se encuentra el elemento o el contenido se renderiza como imagen, se activa el modo visual con OCR y verificación.
Hay otro matiz que muchos pasan por alto: la seguridad y la auditoría. Un clic por coordenadas es difícil de explicar y reproducir. Pero la acción «pulsar el botón Enviar en la ventana AprobaciónFactura por accessibility-id» se registra, revisa y cumple con el compliance fácilmente. Para el sector real, este es a menudo el argumento decisivo a favor de la «integración de IA» a través de interfaces estructurales.
Si estás eligiendo una dirección ahora, no invertiría meses en un agente de visión pura para «hacer scroll y leer». Invertiría en una capa de acceso al árbol de la UI, en un toolset adecuado y en el control de calidad de las acciones del agente. Así obtendrás velocidad, estabilidad y un coste total de propiedad manejable.
Este análisis fue preparado por Vadim Nahornyi, experto principal de Nahornyi AI Lab en automatización con IA y arquitectura de implementación de IA en el sector real. Si planeas un agente local para escritorio o quieres reemplazar escenarios de visión frágiles con integración estructural, te invito a discutir la tarea: analizaré tu proceso, propondré una arquitectura de IA objetivo y un plan de implementación con previsión de costes y riesgos.