¿Qué proyecto de IA para automatizar móviles es más fuerte? Comparativa de MobiAgent, Mobile-Agent, Mobilerun y mobile-use

Recientemente organicé cuatro proyectos de agentes GUI para móviles: MobiAgent, Mobile-Agent, Mobilerun y mobile-use. Todos tienen que ver con “hacer que la IA opere teléfonos o apps móviles”, pero no ocupan el mismo lugar.

En resumen: MobiAgent se parece más a un sistema de investigación personalizable para agentes en teléfonos; Mobile-Agent es el conjunto de trabajos de Tongyi Lab alrededor de GUI agent; Mobilerun está más orientado a un marco práctico de control de dispositivos móviles, local o en la nube; y mobile-use pone el foco en operar apps reales, descomponer tareas, extraer datos y evaluar con AndroidWorld.

Comparativa Básica

MobiAgent

MobiAgent viene de IPADS-SAI y se posiciona como un sistema personalizable de agentes para teléfonos. No ofrece solo un script de ejecución: reúne la familia de modelos MobiMind, grabación y reproducción de acciones con AgentRR, el benchmark MobiFlow, runners para teléfonos, recolección de datos y una app Android dentro de un mismo sistema.

Su punto fuerte es que el sistema de investigación está bastante completo. MobiAgent se centra en precisión, eficiencia, memoria y secuencias de acciones reutilizables en tareas reales con teléfonos. La memoria de perfil de usuario, memoria de experiencia, memoria de acciones y ejecución multitarea mencionadas en el README muestran que intenta manejar tareas largas y repetitivas.

También tiene una barrera de entrada relativamente alta. Una ejecución completa requiere dispositivos, ADB, despliegue de modelos, dependencias y configuración opcional de bases de datos vectoriales y de grafos. Encaja mejor con investigación o experimentos de ingeniería que con un asistente móvil de “instalar y usar” para usuarios comunes.

Qué Problema Resuelve

Los agentes GUI para móviles son más difíciles que la automatización web o de escritorio. Tienen que entender capturas, reconocer controles, decidir la siguiente acción y ejecutar toques, entrada de texto, retrocesos y cambios de app mediante ADB o un entorno móvil. Las tareas reales rara vez son una única acción dentro de una app; suelen cruzar búsqueda, compras, redes sociales, pagos, mapas y otros flujos.

MobiAgent sistematiza esas piezas:

• MobiMind se ocupa de planificación de tareas, decisión y localización de elementos en la interfaz.
• El runner conecta con el teléfono, ejecuta tareas predefinidas mediante ADB y registra trazas.
• AgentRR reutiliza secuencias de acciones exitosas para reducir coste de razonamiento y operación en tareas repetidas.
• MobiFlow evalúa la finalización de tareas en escenarios móviles reales.
• Las herramientas de recolección, anotación y procesamiento de datos reducen el coste de crear datos de tareas GUI móviles.

Esto lo hace más parecido a una plataforma de experimentación para agentes móviles que a un proyecto de modelo que solo corre demos.

Actualizaciones Recientes

El README muestra que MobiAgent fue abierto en agosto de 2025 y luego siguió completando modelos, Runner, sistema de memoria y capacidad de ejecución en el dispositivo. Desde diciembre de 2025, el proyecto soporta inferencia puramente en el teléfono y publicó un GUI agent runner unificado configurable con MobiAgent, UI-TARS, AutoGLM, Qwen-VL, Gemini y otros modelos.

Para marzo de 2026, el proyecto también publicó el GUI-based mobile “claw” MobiClaw y el nuevo modelo MobiMind-1.5-4B. Esto indica que no se limita a reproducir un paper, sino que sigue empujando ejecución móvil, capacidad del modelo y cadena de herramientas hacia una dirección más productizable.

La Memoria Es Clave

MobiAgent soporta memoria de perfil de usuario, memoria de experiencia y memoria de acciones. La memoria de perfil aporta contexto de preferencias a la planificación; la memoria de experiencia recupera ejecuciones de tareas similares; la memoria de acciones usa AgentRR para cachear y reutilizar secuencias exitosas.

Esto importa porque las tareas en teléfonos son naturalmente repetitivas. Un usuario puede buscar productos en la misma app, abrir contactos fijos o rellenar información en una página concreta. Si el agente tiene que mirar la pantalla, planificar y tocar desde cero cada vez, el coste es alto y los errores son probables. La memoria permite consolidar parte del “flujo aprendido” para que las tareas posteriores sean más rápidas y estables.

La memoria también trae nuevas preguntas de gobernanza. Preferencias de usuario, historial de tareas, rutas dentro de apps y trazas de operación pueden contener información sensible. En un despliegue real, el sistema debe definir qué entra en memoria, cuánto tiempo se conserva, cómo se borra y si el modelo puede reutilizar ese contexto entre tareas.

Quién Debería Seguirlo

Si solo buscas una app lista para automatizar el teléfono, MobiAgent sigue siendo más un marco de investigación e ingeniería. Requiere servicios de modelo, dispositivos móviles, ADB, dependencias y archivos de tareas, así que correrlo completo tiene cierta barrera.

Pero si te interesan mobile GUI agents, agentes en el dispositivo, runners multimodelo, reutilización de trazas o evaluación de agentes, MobiAgent merece seguimiento. Reúne modelos, ejecución, evaluación y pipeline de datos, lo que ayuda a investigadores y desarrolladores a observar mejor los puntos débiles reales de los agentes móviles.

Mobile-Agent

Mobile-Agent viene de X-PLUG/Tongyi Lab. Este repositorio pasó de ser un agente temprano para operar teléfonos a una familia de agentes GUI: Mobile-Agent-v1/v2/v3/v3.5, Mobile-Agent-E, PC-Agent, GUI-Critic-R1, UI-S1, GUI-Owl, ToolCUA y otros están dentro de la misma línea técnica.

Su rasgo principal es la amplitud. Mobile-Agent no se preocupa solo por teléfonos; también cubre escritorio, navegador, teléfonos en la nube, escritorios en la nube, percepción GUI, grounding, diagnóstico de errores, aprendizaje por refuerzo y orquestación de rutas GUI/herramientas. La serie de modelos GUI-Owl hace que parezca más una ruta de modelos base para GUI agent multiplataforma que un único proyecto de automatización móvil.

Su debilidad viene de esa misma amplitud: el repositorio se parece más a una colección de resultados de investigación, y el usuario tiene que decidir primero qué subproyecto, modelo y escenario quiere ejecutar. Es bueno para seguir la evolución técnica y reproducir experimentos, pero no siempre será la forma más rápida de conectarlo a un flujo de negocio.

Qué Problema Resuelve

Los GUI agents no se enfrentan a APIs estándar, sino a interfaces de aplicaciones. Necesitan entender la pantalla, localizar controles, planificar pasos, ejecutar toques o entradas de texto, y corregir la ruta cuando fallan. El móvil es especialmente complejo porque las tareas suelen cruzar varias apps, y el estado de la interfaz cambia con login, permisos, ventanas emergentes, red y recomendaciones personalizadas.

La serie Mobile-Agent divide este problema en varias direcciones:

• Mobile-Agent-v1/v2 explora percepción visual y colaboración multiagente en GUI de teléfonos.
• PC-Agent extiende la operación multiagente al PC.
• Mobile-Agent-v3 y v3.5 avanzan un marco GUI agent multiplataforma.
• Los modelos GUI-Owl ofrecen percepción GUI, grounding y operación end-to-end entre plataformas.
• GUI-Critic-R1, UI-S1, ToolCUA y otros trabajos añaden diagnóstico de errores, aprendizaje por refuerzo y orquestación de rutas GUI/herramientas.

Así, se parece menos a una demo puntual y más a una ruta de investigación e ingeniería alrededor de “computer-use agents”.

El Foco de v3.5

El README del repositorio muestra que Mobile-Agent-v3.5 puede probarse mediante el demo online de ModelScope y el demo online de Alibaba Cloud Bailian; Bailian también ofrece una API v3.5. En marzo de 2026, v3.5 llegó además a los cloud phones Wuying de Alibaba Cloud, ofreciendo experiencia móvil en entornos Android en la nube.

Esto indica que el proyecto está completando formas de uso más allá de “correr experimentos en local”. Para GUI agents, los teléfonos y escritorios en la nube importan: ofrecen entornos de ejecución más estables y reproducibles, reduciendo diferencias de dispositivos locales, versiones del sistema, resolución y estado de apps.

Si quieres evaluar este tipo de agente, es fácil subestimar el entorno estable. Sin un entorno de ejecución controlable, cuesta saber si un fallo se debe a capacidad insuficiente del modelo, cambios de interfaz, problemas del dispositivo o una definición de tarea poco clara.

GUI-Owl Cambia la Capa de Base

Después de Mobile-Agent-v3, GUI-Owl se convirtió en una capa de modelo clave en esta ruta. El README describe GUI-Owl como un GUI VLM multimodal y multiplataforma con percepción GUI, grounding y operación end-to-end. Para GUI-Owl-1.5, la serie ya cubre 2B, 4B, 8B, 32B y 235B, y soporta automatización de escritorio, móvil y navegador.

La importancia de estos modelos es que no solo responden “qué hay en la pantalla”. Deben conectar el objetivo en lenguaje natural, el contenido de la captura, la posición de los elementos de interfaz y la siguiente acción. Para GUI agents, comprensión visual, grounding de coordenadas, planificación de acciones y memoria de estado son inseparables.

Por supuesto, cuanto más general sea el modelo, más importantes se vuelven los límites de ingeniería. En despliegues reales siguen haciendo falta ejecutores, control de permisos, logs de tareas, mecanismos de rollback y confirmación humana. En operaciones de alto riesgo como pagos, cuentas, archivos o envío de mensajes, un GUI agent no debe perseguir solo completar automáticamente; también debe explicar claramente qué va a hacer.

La Nueva Dirección que Sugiere ToolCUA

En mayo de 2026, las noticias del proyecto mencionaron ToolCUA, definido como un Computer Use Agent end-to-end para orquestar rutas óptimas entre GUI y herramientas. Esta dirección es interesante porque reconoce un hecho práctico: no todas las tareas deberían completarse tocando pantallas.

Algunas cosas encajan con GUI, como iniciar sesión en paneles, manejar formularios complejos o leer estados de apps sin API. Otras encajan mejor con herramientas, como buscar, calcular, analizar archivos o acceder a interfaces estructuradas. Un computer-use agent realmente usable debe aprender a cambiar entre ambas.

Por eso la serie Mobile-Agent merece más atención que los primeros proyectos de automatización móvil. Ya no pregunta solo si el agente puede tocar apps como una persona, sino cuándo debe mirar la pantalla, cuándo debe usar herramientas y cuándo debe detenerse para confirmar.

Quién Debería Seguirlo

Si solo buscas un asistente de automatización móvil listo para usar, Mobile-Agent sigue siendo un marco de investigación e ingeniería. Incluye modelos, entornos de ejecución, tareas de evaluación y ejecutores concretos, así que correrlo completo suele requerir configuración.

Pero si te interesan estas preguntas, vale la pena seguirlo:

• Cómo los mobile GUI agents pasan de demos a ejecución estable.
• Si la automatización de escritorio, navegador y teléfono puede unificarse en un mismo marco de agentes.
• Cómo los modelos GUI manejan grounding, reflexión, memoria y diagnóstico de errores.
• Cómo los agentes eligen entre operación GUI y uso de herramientas.
• Si los cloud phones y cloud desktops serán entornos importantes para GUI agents.

Estas preguntas afectan directamente a asistentes personales, automatización de procesos empresariales, operación remota de escritorios, pruebas de apps e integración con sistemas sin API.

Mobilerun

Mobilerun viene de droidrun y tiene una orientación más de ingeniería: permite que LLM agents controlen dispositivos Android e iOS mediante lenguaje natural. Ofrece CLI, TUI, Docker, Python API, portal-based control, vision mode, reasoning mode, salida estructurada, herramientas personalizadas, app cards, trazas de ejecución y servicios de dispositivos en la nube.

Lo más destacado es su independencia del modelo y una forma de despliegue clara. Los desarrolladores pueden conectar OpenAI, Anthropic, Gemini, Ollama, DeepSeek, OpenRouter u OpenAI-compatible providers; también pueden elegir un marco local o Mobilerun Cloud. Para equipos reales, esta separación entre la capa de control del dispositivo y la capa del modelo es muy importante.

También conserva las barreras habituales de la automatización móvil. En Android hacen falta opciones de desarrollador, depuración USB y la Portal app; iOS tiene un flujo separado; las tareas complejas además requieren manejar ventanas de permisos, cambios de página, reintentos tras fallos e investigación de logs. Es más adecuado para quienes quieren incorporar mobile agent como componente de ingeniería.

Qué Problema Resuelve

Lo más difícil de la automatización móvil es que entre una tarea en lenguaje natural y una operación real en el dispositivo hay muchas capas. El modelo necesita saber qué app está abierta, qué controles hay en la página, si necesita capturas para contexto visual, dónde tocar después y cómo continuar tras un fallo.

Mobilerun organiza estas capacidades en un marco:

• Ejecutar tareas puntuales en lenguaje natural, inspeccionar dispositivos, reproducir macros y depurar flujos mediante CLI y TUI.
• Construir flujos personalizados de automatización móvil con Python API.
• Soportar Android e iOS. Android usa Portal app y accesibilidad; iOS sigue un flujo Portal separado.
• Combinar accessibility tree y capturas para que el modelo lea UI estructurada y contexto visual.
• Soportar modos como --vision, --vision-only y --reasoning para tareas de distinta complejidad.
• Soportar salida estructurada, app cards, herramientas personalizadas, credenciales y trazas de ejecución.

Esto hace que Mobilerun se parezca más a un “mobile agent runtime” que a un simple simulador de tocar pantallas enviando capturas a un modelo.

Marco Local y Servicio en la Nube

Mobilerun separa con claridad el marco local y Mobilerun Cloud. El marco local sirve para desarrolladores que ejecutan agentes en sus propias máquinas y dispositivos con mayor control a nivel de código. Cloud apunta a dispositivos hospedados, REST API, SDKs y flujos a escala.

Esta separación importa. Muchos escenarios empiezan como “ayúdame a ejecutar una tarea en el teléfono”, pero al entrar en uso de equipo aparecen gestión de dispositivos, concurrencia, logs, reintentos, permisos y llamadas API. Cloud no reemplaza el marco local; empuja la operación de dispositivos y la integración de flujos hacia servicios backend.

El README también distingue varios tipos de dispositivos en la nube: hardware del propio usuario, cloud phones hospedados y teléfonos físicos hospedados. La diferencia no es solo coste; afecta control de riesgo de apps, confianza de identidad y estabilidad de tareas. En ecommerce, redes sociales, finanzas o servicios locales, un dispositivo real y uno virtual pueden comportarse de forma muy distinta.

Por Qué Importa Ser Independiente del LLM

Los mobile GUI agents todavía cambian rápido, y es difícil decir qué modelo será mejor a largo plazo. Las tareas también exigen cosas distintas: algunas dependen más de visión, otras de planificación larga, otras del uso de herramientas y otras de ejecución masiva de bajo coste.

Mobilerun elige una ruta independiente del modelo. Su valor está en separar control de dispositivo, ejecución de tareas, trazado de logs y elección del modelo. Los desarrolladores pueden estabilizar primero el flujo del dispositivo y luego cambiar modelos según coste, precisión y latencia.

Esto ayuda al despliegue real. Una empresa no va a reescribir la capa de control de dispositivos solo porque un demo de modelo se vea bien. Es más razonable conservar un marco de ejecución unificado y tratar el modelo como un componente reemplazable.

Escenarios Adecuados

Mobilerun encaja actualmente con varias necesidades:

• QA y pruebas de regresión de apps móviles.
• Extraer datos de apps nativas y devolver resultados estructurados.
• Ejecutar automáticamente tareas repetitivas en teléfonos.
• Empaquetar flujos móviles en lenguaje natural para usuarios no técnicos.
• Ejecutar automatizaciones en múltiples dispositivos.
• Conectar agendas, notificaciones o disparadores personalizados a flujos móviles.

No es todavía un asistente de consumo que controle el móvil inmediatamente tras instalarlo. En Android hacen falta ADB, opciones de desarrollador, depuración USB y Portal app; iOS tiene su propio flujo de integración. Para funcionar de forma estable también hay que gestionar configuración del modelo, estado del dispositivo, ventanas de permisos y recuperación ante fallos.

mobile-use

mobile-use viene de minitap-ai y busca que AI agents usen apps reales de Android e iOS. Soporta control por lenguaje natural, UI-aware automation, extracción de datos y distintas configuraciones de LLM, y destaca su rendimiento en el benchmark AndroidWorld. El README también menciona que el proyecto es el primer agentic framework que alcanza 100% en AndroidWorld benchmark.

Su punto brillante es la descomposición de tareas y la extracción estructurada. Por ejemplo, encontrar correos no leídos en Gmail y devolver remitente y asunto en un formato JSON especificado está mucho más cerca de necesidades reales de producción que “abrir Ajustes y mirar la batería”. Lleva a los mobile GUI agents desde “pueden operar” hacia “pueden organizar información dentro de una app”.

Sus limitaciones están sobre todo en el soporte de dispositivos y el entorno de ejecución. Android puede usar teléfonos físicos o emuladores; iOS por ahora soporta principalmente simuladores en macOS, y los dispositivos físicos iOS todavía no están soportados. El arranque rápido con Docker también está orientado principalmente a Android. Al evaluarlo, conviene confirmar primero si el dispositivo objetivo y el escenario de la app quedan cubiertos por la ruta de ejecución actual.

En Qué Se Diferencia de la Automatización Móvil Tradicional

La automatización tradicional de teléfonos suele depender de scripts, coordenadas, IDs de controles o flujos fijos. Funciona con páginas estables, pero falla fácilmente cuando cambia la interfaz, aparecen ventanas emergentes, varían los resultados de búsqueda, se desplazan listas o la operación cruza apps.

La ruta de mobile-use consiste en hacer que el AI agent procese directamente objetivos en lenguaje natural y estado de la UI:

• El usuario describe la tarea en lenguaje natural, sin escribir cada paso de antemano.
• El marco lee la interfaz móvil y usa el modelo para decidir la siguiente acción.
• Puede extraer información de apps y devolverla en un formato especificado, como JSON.
• Soporta distintas configuraciones de LLM, incluyendo OpenAI API compatible providers.
• Android puede correr en teléfonos físicos o emuladores; iOS por ahora apunta principalmente a simuladores en macOS.

Este tipo de marco encaja mejor con tareas móviles “semiestructuradas”: el objetivo está claro, pero el estado de la página, los datos y la ruta no son idénticos cada vez.

El Resultado en AndroidWorld Merece Atención

El README de mobile-use menciona que el proyecto alcanzó 100% de completitud en AndroidWorld benchmark y enlaza el paper correspondiente. Más allá de los detalles concretos de evaluación, esto muestra que el equipo da mucha importancia a la descomposición de tareas y a la ejecución evaluable.

Esto es más importante que una simple demo. Un problema común de los GUI agents es que pueden parecer inteligentes en un video, pero volverse inestables al cambiar la tarea, el dispositivo o el estado inicial. Los benchmarks no representan por completo el uso real, pero obligan al sistema a enfrentarse a tareas estandarizadas y exponen planificación, grounding, recuperación y comprensión de estado.

El título del paper enlazado en el README también apunta a la dirección: mejorar la precisión en AndroidWorld mediante descomposición de tareas. Para agentes móviles, las tareas complejas rara vez se completan con un único gran prompt; necesitan dividirse en subtareas ejecutables y revisar el estado en cada paso.

La Extracción de Datos Es una Entrada Práctica

Un caso realista para mobile-use es extraer datos de apps nativas. Mucha información no se expone mediante APIs y solo puede verse dentro de interfaces de apps: listas de correos, estados de pedidos, contenido social, paneles administrativos, notificaciones, etc.

El ejemplo del README abre Gmail, encuentra correos no leídos y devuelve remitente y asunto como JSON. Esta dirección es práctica porque lleva los mobile GUI agents de “ayúdame a operar algo” a “ayúdame a estructurar y sacar información de una app”.

Pero también crea límites. La extracción de datos involucra cuentas, privacidad, términos de plataforma y permisos de acceso. En uso real conviene definir con claridad propiedad del dispositivo, autorización de la tarea, forma de guardar datos y alcance de salida. La interfaz de un teléfono no debe tratarse como una fuente ilimitada de datos.

Barreras de Despliegue y Límites

mobile-use soporta inicio rápido desde la plataforma y ejecución desde código fuente. La vía de código requiere configurar .env, LLM y dependencias. En Android se pueden usar teléfonos físicos o emuladores, y el arranque rápido con Docker por ahora está orientado principalmente a Android. En iOS hacen falta macOS, Xcode y Facebook iOS Development Bridge; el README también indica que los dispositivos iOS físicos no están soportados por ahora.

Estas limitaciones no sorprenden. La automatización móvil depende más de dispositivos, permisos del sistema y canales de depuración que la automatización de navegador. iOS, en particular, es más cerrado. Tener acceso estable a simuladores ya aporta valor, pero aún queda distancia hasta “automatizar cualquier iPhone real”.

Por eso, al evaluar mobile-use no conviene mirar solo el rendimiento del modelo. También hay que revisar si el dispositivo objetivo, el tipo de app, el entorno de ejecución y el límite de cumplimiento encajan.

Quién Debería Seguirlo

mobile-use es interesante para:

• Investigadores que estudian AndroidWorld, mobile GUI agents y métodos de descomposición de tareas.
• Desarrolladores que quieren conectar operación móvil en lenguaje natural a herramientas internas.
• Equipos que necesitan extraer datos estructurados de apps nativas.
• Personas que hacen QA móvil, pruebas de regresión o pruebas exploratorias.
• Quienes quieren comparar rutas como mobile-use, Mobilerun y Mobile-Agent.

Si el objetivo es un asistente de teléfono para usuarios comunes, todavía es más un marco de ingeniería e investigación. Si el objetivo es validar la viabilidad de agentes móviles, ofrece un muy buen punto de partida open source.

Comparativa de Funciones

Ventajas y Limitaciones

La ventaja de MobiAgent es que el sistema está completo y sirve para estudiar el ciclo cerrado de modelos, memoria, aceleración y evaluación en phone GUI agents. Su limitación es una cadena de despliegue larga, configuración de ingeniería pesada y un coste de entrada alto para desarrolladores comunes.

La ventaja de Mobile-Agent es que tiene la ruta técnica más amplia. Permite ver cómo GUI agent evoluciona desde teléfonos hacia escritorio, navegador, uso de herramientas y modelos base. Su limitación es que la familia de proyectos es compleja; si quieres aterrizar un escenario concreto directamente, primero hay que filtrar bastante.

La ventaja de Mobilerun es una interfaz de ingeniería clara, independencia del modelo y separación explícita entre marco local y servicio en la nube. Encaja con integrar automatización de dispositivos móviles en productos o herramientas internas. Su limitación es que todavía hay que lidiar con permisos, entorno, estado de apps y costes de nube.

La ventaja de mobile-use es su foco en apps reales, descomposición de tareas y extracción estructurada de datos. La dirección AndroidWorld también lo hace más fácil de evaluar. Su limitación es el soporte limitado para dispositivos iOS físicos, y el uso completo todavía requiere configurar modelos, dispositivos y entorno de ejecución.

Recomendaciones de Uso

Si quieres investigar agentes móviles, mira primero MobiAgent y Mobile-Agent. El primero se concentra más en el ciclo cerrado del sistema en el teléfono; el segundo es mejor para observar la evolución multiplataforma de GUI agent.

Si quieres automatización de apps móviles, QA, extracción de datos o flujos internos, mira primero Mobilerun y mobile-use. Mobilerun se parece más a un framework de ejecución que puede integrarse en sistemas de ingeniería, mientras que mobile-use es más adecuado para validar operación de apps en lenguaje natural y extracción estructurada.

Si te interesa la forma futura de los asistentes personales, vale la pena seguir los cuatro. MobiAgent representa investigación sistemática sobre phone agents, Mobile-Agent representa la ruta de GUI agent multiplataforma, Mobilerun representa infraestructura de control de dispositivos, y mobile-use representa descomposición de tareas en apps reales y desarrollo guiado por evaluación.

Mi Lectura

Las diferencias entre estos cuatro proyectos muestran que los mobile GUI agents ya no consisten solo en “hacer que el modelo mire capturas y toque botones”. Las preguntas reales son: cómo entiende el modelo la interfaz, cómo controla el ejecutor el dispositivo de forma estable, cómo se descomponen y evalúan las tareas, cómo se gestionan los dispositivos en la nube, cómo se devuelven resultados estructurados y cómo se limitan los riesgos.

A corto plazo, los escenarios más realistas serán QA, extracción de datos, automatización de flujos internos y pools de dispositivos controlados. A largo plazo, quien logre estabilizar el control del dispositivo, la capacidad del modelo, los límites de permisos, el seguimiento de logs y los mecanismos de confirmación del usuario estará más cerca de un asistente móvil de IA realmente usable.