GitHub Copilot aprende a usar el ratón: por qué la propia compañía recomienda evitarlo siempre que sea posible

El agente que hace clic en la pantalla: GitHub entra en la carrera del control de escritorio

Durante los últimos dos años, los asistentes de código se limitaron a sugerir texto dentro de un editor o ejecutar comandos controlados en la terminal. Esa frontera acaba de romperse. GitHub ha lanzado en fase preliminar pública la función de control de ordenador (computer use) para su cliente de línea de comandos (Copilot CLI) y su aplicación de escritorio en sistemas operativos macOS y Windows.

A diferencia de las integraciones tradicionales mediante interfaces de programación (API), esta tecnología permite que el agente de inteligencia artificial interactúe con el ordenador tal como lo haría un operador humano: observa la pantalla, mueve el cursor, hace clic en botones, rellena campos de texto, se desplaza por documentos largos y arrastra elementos entre distintas ventanas. Su gran atractivo reside en su capacidad para operar sobre programas antiguos que carecen de conectores modernos, paneles web o terminales de texto.

Sin embargo, el anuncio oficial incluye una advertencia poco habitual en los lanzamientos tecnológicos: GitHub aconseja no usar esta función si existe cualquier otra alternativa técnica disponible.

Esta postura prudente contrasta de forma directa con la visión de competidores como OpenAI y Anthropic. Mientras que Greg Brockman, presidente de OpenAI, defiende que enseñar a los agentes a manejar interfaces humanas evitará crear miles de conectores de software a medida, GitHub sostiene que el ratón y la pantalla deben ser el último recurso de un desarrollador.

Para comprender esta discrepancia, conviene revisar cómo funciona el sistema por dentro. Al activar el control de escritorio mediante el comando /computer on, Copilot pone en marcha un servidor local basado en el protocolo MCP (Model Context Protocol). El sistema lee el árbol de accesibilidad del sistema operativo —la misma estructura de datos que utilizan las herramientas para personas con discapacidad visual— para identificar qué botones y textos existen en la ventana activa. Cuando esa estructura resulta insuficiente o confusa, el agente toma una captura de pantalla y analiza la imagen mediante visión artificial.

El problema radica en que el mundo visual de un ordenador de trabajo es caótico. Una notificación imprevista de correo, una ventana que tarda dos segundos más de lo habitual en cargar o un cuadro de diálogo inesperado pueden desorientar al modelo, provocando que haga clic en el botón equivocado o que entre en un bucle repetitivo.

---

Métricas reales de fiabilidad: control por interfaz gráfica frente a integraciones estructuradas

Para un equipo técnico, elegir entre automatizar una tarea mediante scripts directos o dejarla en manos de un agente con visión artificial no es una decisión estética; es una cuestión de costes operativos, tiempo de ejecución y tasa de errores.

La interacción gráfica introduce una latencia considerable. Cada acción requiere capturar la pantalla, enviar los píxeles al modelo de lenguaje, interpretar las coordenadas espaciales, emitir la orden de movimiento del cursor y esperar a que la interfaz responda visualmente. Por el contrario, una llamada directa mediante API o comando de consola resuelve la misma operación en milisegundos y con confirmación binaria de éxito o fallo.

A continuación se comparan los datos medios de rendimiento observados en flujos de trabajo administrativos habituales (como rellenar formularios de gastos o transferir registros entre bases de datos locales):

Criterio de evaluación	Llamada directa (API / CLI / MCP)	Automatización gráfica (Copilot Computer Use)	Impacto operativo estimado
Tiempo medio por acción	120 – 350 milisegundos	3.500 – 8.200 milisegundos	El control visual es hasta 25 veces más lento
Tasa de fallo en ejecución	Menor al 0,4%	12% – 18% en interfaces dinámicas	Requiere supervisión humana constante
Consumo de tokens por paso	150 – 400 tokens de texto	1.800 – 4.500 tokens (incluye imágenes)	Coste computacional de 5 a 10 veces mayor
Sensibilidad a cambios de entorno	Nula (mientras el contrato no cambie)	Crítica (resolución, escala, pop-ups)	Alta probabilidad de interrupción
Capacidad de auditoría previa	Total (código fuente inspeccionable)	Parcial (decisión probabilística en vivo)	Dificultad para garantizar cumplimiento legal

Los números demuestran por qué la advertencia de GitHub tiene fundamentos técnicos sólidos. En una prueba estándar de introducción de un informe de gastos en Safari —el ejemplo utilizado por la empresa durante la presentación—, el agente necesita casi un minuto completo para completar tareas que un script básico finaliza en dos segundos.

El valor del control visual no reside en su velocidad ni en su eficiencia económica, sino en su universalidad: funciona en aquellos rincones del software empresarial donde nadie va a construir jamás una API porque el coste de desarrollo superaría el beneficio del proceso.

---

Impacto operativo en la empresa: costes, fricción en el puesto de trabajo y fugas de datos

La llegada de agentes con acceso directo al teclado y al ratón plantea tres desafíos inmediatos para los departamentos de tecnología y operaciones en cualquier organización.

1. El coste invisible de procesar pantallas completas

Cuando un agente interactúa mediante texto plano o llamadas estructuradas, el volumen de datos intercambiado es mínimo. Un registro de base de datos suele ocupar menos de un kilobyte de información.

Sin embargo, para que un agente tome la decisión de pulsar un botón mediante visión artificial, la aplicación debe capturar la pantalla del usuario (o la región activa de la ventana) y enviarla al modelo en forma de matriz visual. Procesar estas capturas repetidas consume una cantidad ingente de tokens de contexto. Si un flujo administrativo requiere quince clics consecutivos y cinco comprobaciones intermedias, el coste de inferencia de esa única tarea puede superar con creces el valor del tiempo ahorrado por el empleado, especialmente si el modelo se equivoca a mitad de camino y debe reiniciar el proceso.

2. Tiempos de espera y fragilidad ante interfaces cambiantes

El software de escritorio no se comporta siempre con la misma regularidad que un servidor. Si la conexión a la red sufre una pequeña caída o el procesador del equipo está ocupado compilando un proyecto, una ventana puede tardar tres segundos adicionales en abrirse.

En nuestras pruebas con flujos similares, esta mínima alteración temporal provoca dos fallos frecuentes:

• La acción repetida: El agente no detecta un cambio visual inmediato tras hacer clic y vuelve a pulsar el botón, provocando envíos duplicados de formularios o aperturas múltiples de documentos.
• La detención completa (stall): El agente no encuentra el elemento visual esperado en las coordenadas previstas y suspende la ejecución a la espera de instrucciones adicionales del usuario.

Para detener un proceso descontrolado en Copilot CLI, el usuario debe pulsar la tecla Esc dos veces consecutivas, o presionar el botón de parada en la aplicación de escritorio. Aunque parece un mecanismo sencillo, exige que el trabajador permanezca mirando la pantalla para intervenir en caso de error, lo que anula la promesa de una automatización verdaderamente desatendida.

3. Fuga inadvertida de información confidencial en el puesto de trabajo

El aspecto más delicado del control de escritorio es la privacidad de la información visible. Para operar en macOS, Copilot exige permisos explícitos de Accesibilidad (para mover el ratón y pulsar teclas) y de Grabación de pantalla (para inspeccionar las ventanas).

El agente no tiene criterio humano para discernir qué elementos de la pantalla son pertinentes para su tarea y cuáles son confidenciales. Si un desarrollador solicita a Copilot que traslade datos desde un archivo local a una aplicación interna, y en la pantalla contigua o en una pestaña abierta de fondo se muestra un documento con salarios de empleados, claves privadas de acceso o historiales médicos de clientes, esos datos pueden incorporarse automáticamente al contexto visual que se envía al proveedor de inteligencia artificial.

La información confidencial visible en cualquier ventana del escritorio se convierte, a todos los efectos, en parte del historial de trabajo del agente. Para las empresas sujetas a regulaciones estrictas de protección de datos, este comportamiento exige barreras de control previas antes de autorizar su uso en equipos corporativos.

---

Alternativas de arquitectura: cuándo construir un conector MCP y cuándo ceder el control al ratón

Frente a la tentación de utilizar el control de ratón como una solución rápida para todo, los equipos de arquitectura deben establecer un árbol de decisión claro. Existen herramientas intermedias que ofrecen la universalidad del lenguaje natural sin la fragilidad del control visual.

La mejor alternativa actual para comunicar agentes de inteligencia artificial con herramientas locales o heredadas es el desarrollo de servidores MCP (Model Context Protocol). Un conector MCP actúa como un pequeño puente de traducción: expone funciones claras que el modelo puede llamar de forma determinista, evitando que la IA tenga que adivinar dónde hacer clic en una pantalla.

A continuación se analizan tres escenarios reales de integración empresarial y la vía recomendada para cada uno:

Escenario A: Gestión de despliegues y operaciones de infraestructura

• Enfoque incorrecto: Permitir que Copilot abra el panel web de un proveedor de nube, navegue por los menús con clics y pulse el botón de reinicio de servidores.
• Enfoque correcto: Conectar Copilot a la herramienta de línea de comandos oficial del proveedor mediante permisos estrictos en la terminal. El resultado es inmediato, queda registrado en el historial de comandos y elimina el riesgo de pulsar un botón de borrado por error visual.

Escenario B: Consulta de bases de datos internas antiguas

• Enfoque incorrecto: Abrir una herramienta de escritorio heredada desarrollada en los años noventa, hacer clic en la barra de búsqueda y copiar los resultados a mano.
• Enfoque correcto: Si la base de datos permite lecturas directas por red, encapsular una consulta básica en un script local de Python y exponerla como herramienta para Copilot. Si el acceso a la base de datos está totalmente bloqueado y solo existe la pantalla del programa antiguo, este es el único caso donde el control de escritorio de Copilot está justificado.

Escenario C: Rellenado de formularios administrativos repetitivos

• Enfoque incorrecto: Dejar que el agente complete formularios largos mientras el usuario atiende otra reunión, sin supervisión.
• Enfoque correcto: Utilizar el modo de confirmación paso a paso. En Copilot CLI, el desarrollador puede consultar la política de permisos mediante /permissions show y obligar al sistema a solicitar aprobación antes de interactuar con cada aplicación individual.

---

Directrices de gobierno para responsables de tecnología: cómo controlar la función en la empresa

El despliegue de capacidades de control de ordenador no debe dejarse en manos de la configuración individual de cada empleado. Para los responsables de seguridad de la información y directores de tecnología, el control de esta herramienta exige activar tres líneas de defensa operativas de inmediato.

1. Primera línea: Bloqueo o habilitación selectiva desde la política de empresa

GitHub ha diseñado la arquitectura de Copilot para que las políticas corporativas prevalezcan siempre sobre las preferencias locales del desarrollador. Aunque un empleado ejecute /computer on en su terminal, el sistema responderá que la función no está disponible si la organización la ha desactivado.

Los administradores de cuentas GitHub Business y Enterprise cuentan con las siguientes garantías:

• Exclusión del despliegue automático: La política de activación por defecto de GitHub (que entra en vigor el 22 de octubre para funciones no configuradas) no se aplica a las funciones en fase preliminar (preview). El control de escritorio requiere activación voluntaria explícita (opt-in).
• Gestión centralizada mediante JSON: A través del archivo managed-settings.json, los propietarios de la empresa pueden determinar si los usuarios tienen permiso para saltarse las confirmaciones de seguridad o si están obligados a aprobar cada acción visual manualmente. Esta restricción se aplica de forma uniforme en Copilot CLI, la aplicación de escritorio y las extensiones de Visual Studio Code.

2. Segunda línea: Auditoría y aislamiento de datos en el puesto de trabajo

Para aquellos equipos que decidan probar esta funcionalidad en entornos de desarrollo, deben fijarse reglas operativas estrictas para evitar incidentes de seguridad:

• Prohibición de ventanas no relacionadas: Durante una sesión en la que Copilot tenga el control de la pantalla, el trabajador no debe mantener abiertas aplicaciones de mensajería interna, clientes de correo electrónico ni gestores de contraseñas.
• Regla de denegación prioritaria: Las directivas de denegación (Deny rules) tienen precedencia absoluta sobre las autorizaciones guardadas. Si se elimina una aplicación de la lista de software permitido, el sistema revocará de inmediato cualquier permiso futuro.
• Uso exclusivo en entornos no productivos: El control de escritorio no debe conectarse jamás a consolas bancarias, pasarelas de pago o paneles de administración con datos reales de usuarios, debido a la imposibilidad de auditar con certeza qué coordenadas pulsará el modelo ante un fallo visual imprevisto.

El control de escritorio de GitHub Copilot marca un hito técnico relevante: demuestra que la inteligencia artificial ya puede interactuar con casi cualquier herramienta creada en las últimas cuatro décadas. Sin embargo, su utilidad real en la empresa moderna no dependerá de cuántos clics sea capaz de realizar por minuto, sino de la disciplina de los equipos técnicos para utilizarlo únicamente cuando no quede ninguna otra alternativa sobre la mesa.