Doubao amplía gradualmente la automatización de aplicaciones en el teléfono, mientras las principales plataformas deniegan el acceso

15 min de lectura
Doubao Opens Phone App Automation Gradually as Major Platforms Refuse Access

El plazo de aviso de 30 días termina, pero las principales aplicaciones siguen fuera del alcance

Doubao Phone Assistant anunció el 14 de octubre que abriría gradualmente el acceso a la automatización de pantalla en aplicaciones de terceros, tras completar un periodo de aviso público de 30 días para su Protocolo de Ejecución de Automatización de Pantalla (SAEP). Los desarrolladores aún pueden denegar el acceso después de ese periodo, y el asistente no operará las aplicaciones que hayan rechazado explícitamente la automatización.

Contenido
  1. El plazo de aviso de 30 días termina, pero las principales aplicaciones siguen fuera del alcance
  2. ¿Qué cambia tras el periodo de aviso?
  3. Cómo se llegó al 14 de octubre
  4. ¿Qué aplicaciones han denegado el acceso?
  5. Qué controla realmente SAEP
  6. Las acciones permitidas aún requieren autorización
  7. Las restricciones deben funcionar más allá de las promesas del asistente
  8. Los registros de auditoría dejan constancia, con límites de conservación
  9. La elección del usuario y el control del desarrollador siguen en tensión
  10. Qué pueden esperar los usuarios
  11. Puntos clave

La lista de rechazos incluye muchos de los servicios que harían útil a un asistente telefónico para las tareas cotidianas. Entre las aplicaciones del ecosistema de Alibaba figuran Taobao, Tmall, Cainiao, Alipay, DingTalk y Ele.me. Las del ecosistema de Tencent incluyen WeChat, QQ, Honor of Kings y League of Legends: Wild Rift. Otros servicios incluidos en la lista son Meituan, Pinduoduo, Kuaishou, Xiaohongshu, Zhihu, China Merchants Bank e Industrial and Commercial Bank of China.

Por lo tanto, el cambio amplía el acceso, pero no concede un control irrestricto del teléfono. Sustituye el requisito temporal de que los desarrolladores aceptaran activamente la automatización por un mecanismo que abre gradualmente las aplicaciones elegibles, salvo que sus desarrolladores la hayan rechazado o hayan configurado restricciones. Siguen vigentes las reglas de seguridad del sistema, la autorización del usuario y los controles propios de cada aplicación.

Doubao afirma que los desarrolladores pueden presentar un rechazo en cualquier momento y que la plataforma responderá en un plazo de tres días laborables. Ese compromiso de respuesta no equivale a una garantía publicada de que todas las solicitudes se ejecutarán dentro de ese plazo. El anuncio indica que las operaciones pertinentes se desactivarán de inmediato, pero no establece un plazo universal independiente para hacerlo.

La pregunta práctica para los usuarios es qué partes de una tarea puede completar el asistente. Una aplicación puede no estar disponible en absoluto, una página sensible puede estar bloqueada o puede ser necesario que el usuario tome el control para realizar la acción final. SAEP ofrece mecanismos para los tres casos.

Publicidad

¿Qué cambia tras el periodo de aviso?

Durante el periodo de aviso público, Doubao limitó la automatización a las aplicaciones del sistema, las aplicaciones de ByteDance y los servicios de terceros que habían aceptado participar explícitamente mediante SAEP o una comunicación por correo electrónico oficial. Por defecto, no se operaban otras aplicaciones.

Una vez concluido el periodo de aviso, las aplicaciones cuyos desarrolladores no hayan presentado un rechazo por canales oficiales ni configurado una política de desactivación pueden pasar a ser candidatas para el acceso gradual. La explicación del plan publicada en septiembre describía esa apertura como dependiente de los niveles de riesgo, en lugar de como un cambio simultáneo para todas las aplicaciones.

Esta distinción importa al interpretar por qué una tarea no se completa. Antes del 14 de octubre, una aplicación podía ser inaccesible simplemente porque su desarrollador no había aceptado participar activamente. Después del cambio, el acceso aún puede fallar por un rechazo, una restricción de página, una verificación de identidad, un requisito de confirmación del usuario o los propios controles de seguridad de la aplicación.

La versión para consumidores del asistente se lanzó el 14 de septiembre con su función de control del teléfono en fase beta. Otras funciones, como los servicios inteligentes de Doubao, la asistencia para compras, los resúmenes de grabaciones y las tareas de trabajo, son independientes de que una aplicación externa concreta permita la automatización de pantalla.

Cómo se llegó al 14 de octubre

El cambio de política se produce tras enfrentamientos anteriores entre el control automatizado del teléfono y los sistemas de seguridad de las aplicaciones. En diciembre de 2025, la primera versión preliminar de la tecnología telefónica de Doubao tuvo problemas para iniciar sesión en WeChat, se encontró con desafíos de verificación en Taobao y topó con aplicaciones bancarias que interrumpieron el inicio de sesión o los pagos tras detectar un entorno de riesgo.

El posterior lanzamiento para consumidores estableció un proceso formal de declaración antes de ampliar el acceso. Estos fueron los principales acontecimientos:

  • Diciembre de 2025: Nubia M153 presentó la automatización telefónica de Doubao, seguida de restricciones y desafíos de seguridad en varias aplicaciones importantes.
  • 14 de septiembre de 2026: Se lanzó la versión beta del control del teléfono del asistente para consumidores y comenzó el periodo de aviso de 30 días. Algunos usuarios de M153 dijeron haber perdido tareas automatizadas que antes estaban disponibles.
  • 16 de septiembre: Nubia NaviX Ultra llegó al mercado con el asistente para consumidores. Los informes describen esa fecha como la del lanzamiento o el inicio de las ventas.
  • 17 de septiembre: Doubao aclaró que los desarrolladores aún podían rechazar la automatización después del periodo de aviso.
  • 14 de octubre: Doubao anunció que el periodo de aviso había concluido y que el acceso elegible a aplicaciones de terceros se abriría gradualmente.

Para los usuarios actuales, las restricciones de septiembre podían sentirse como una pérdida de funciones. Algunos informes describieron a propietarios de M153 que ya no podían utilizar tareas automatizadas habituales, como pedir transporte o comida, entre otras. Esas restricciones respondían a las reglas temporales de autorización, y no demostraban que todos los desarrolladores afectados hubieran rechazado el asistente.

Publicidad

¿Qué aplicaciones han denegado el acceso?

La lista de rechazos del 14 de octubre abarca más que Alibaba y Tencent. Los informes también mencionan DeepSeek, WPS y Vipshop, además de aplicaciones de compras, redes sociales, bancos y servicios locales. También se indicó que las aplicaciones de China Mobile, China Unicom y China Telecom habían denegado el acceso.

Estas restricciones afectan a Nubia M153 y Nubia NaviX Ultra. Su importancia no radica tanto en el número de aplicaciones como en los servicios que abarcan. Una tarea de compra puede llegar a un mercado no disponible, una tarea de comunicación puede detenerse en una aplicación de mensajería y una tarea financiera puede enfrentarse tanto al rechazo del desarrollador como a requisitos de seguridad independientes del sistema.

Las descripciones publicadas no ofrecen un recuento completo de todas las aplicaciones accesibles e inaccesibles. Un informe anterior afirmaba que el 90 % de las aplicaciones de uso frecuente había ido incorporando progresivamente el agente de interfaz gráfica de usuario de Doubao, pero no especificaba el método de medición ni el conjunto completo de aplicaciones contabilizadas. Esa cifra no permite determinar la proporción accesible según las reglas de octubre.

Las descripciones de septiembre de los servicios compatibles mencionaban Cao Cao Mobility, Qishui Music y Feishu Minutes. Que un servicio aparezca en una lista de compatibilidad con el control del teléfono no demuestra por sí solo que su desarrollador haya completado todas las partes de la integración técnica de SAEP. La compatibilidad con una tarea y la adopción del protocolo están relacionadas, pero son cuestiones distintas.

Qué controla realmente SAEP

La guía oficial de integración de Doubao describe SAEP como un protocolo mediante el cual las aplicaciones de Android definen límites para un agente de interfaz gráfica de usuario. Un agente de interfaz gráfica de usuario interpreta una interfaz visual y realiza acciones como pulsar botones o introducir texto, en lugar de depender exclusivamente de la interfaz de software específica de una aplicación.

La guía indica que es compatible con ObricUI versión 2.2 y posteriores. Esto no significa que SAEP funcione en todos los teléfonos Android. Los desarrolladores deben comprobar si la función está presente y activada en el dispositivo de destino. Si no lo está, sus aplicaciones deben seguir dependiendo de sus propios controles de seguridad.

Las restricciones operan en tres niveles: App, que abarca toda la aplicación; Activity, que abarca una pantalla o página concreta de Android; e Intent, que abarca una acción comercial, como publicar o eliminar contenido. En este contexto, «intent» se refiere al propósito de una operación, no simplemente al botón visible que pulsa el asistente.

Esta estructura permite que una aplicación autorice cierta asistencia y, al mismo tiempo, proteja los pasos sensibles. Puede prohibir toda actividad del agente mediante global_disable, impedir las capturas de pantalla mediante screenshot_disable o bloquear los clics simulados y la introducción de texto mediante input_disable. Otros controles se ocupan de la modificación de contenido, la publicación definitiva, la eliminación y las recompensas o ventajas promocionales.

Publicidad

Las acciones permitidas aún requieren autorización

La guía oficial establece una distinción fundamental entre el permiso de una aplicación y la decisión final del sistema. El resultado depende de la identidad y la condición de confianza del agente, del nivel de seguridad del sistema, de la política declarada por la aplicación y de la autorización del usuario para la tarea concreta.

Las aplicaciones no pueden rebajar el nivel de seguridad del sistema. Si el sistema exige bloquear una acción o solicitar la intervención del usuario, una aplicación no puede convertir ese resultado en un permiso. Cuando hay conflicto entre varias reglas aplicables, prevalece el resultado más restrictivo. Si falla la interpretación de la política, el sistema recurre a la política predeterminada utilizable de la aplicación y registra el motivo.

La guía describe tres resultados principales. ALLOW autoriza la capacidad del sistema pertinente, pero no elimina los requisitos de autenticación de la aplicación ni de autorización del usuario. BLOCK detiene la acción y el asistente no debe buscar otra forma de eludir la restricción. CALL_USER pausa la automatización para solicitar una confirmación del sistema o que el usuario tome el control manualmente.

Una confirmación solo se aplica al paso específico que se muestra al usuario. No es un permiso general para todas las acciones posteriores. Entre las actividades sensibles para las que el sistema puede exigir una confirmación, que el usuario tome el control o un rechazo figuran los pagos, las transferencias, la autenticación de cuentas, la publicación, la eliminación y los cambios de permisos.

En la documentación aparece una cuarta etiqueta, CLARIFY, para solicitudes de aclaración o restricciones menos estrictas. Su significado preciso y disponibilidad dependen del paquete de software de destino. La guía también advierte a los desarrolladores que no supongan que el orden de las reglas App, Activity e Intent permite que una regla posterior anule una restricción anterior.

Las restricciones deben funcionar más allá de las promesas del asistente

La afirmación técnica más importante de SAEP es que las restricciones deben operar en los puntos de control del sistema, en lugar de depender únicamente de que el agente decida respetarlas. El acceso a capturas de pantalla, la lectura mediante accesibilidad, los clics y la entrada de datos simulada deben pasar por vías de ejecución controladas.

La guía ofrece ejemplos concretos. Una prohibición de la aplicación puede impedir que esta aparezca en la pantalla virtual del agente. Una restricción de capturas de pantalla puede recurrir a una capa de visualización segura. Los límites de entrada pueden detener las acciones simuladas en la vía de gestión de entradas de Android.

Hay una salvedad importante: la aplicación completa de las restricciones sobre las acciones comerciales depende de la versión del sistema de destino. Los desarrolladores no deben considerar suficiente como prueba de que una restricción de publicación, eliminación o recompensa se aplica técnicamente el hecho de que un agente afirme haberla respetado.

La integración básica recomendada consiste en incluir una política estática en la aplicación. El sistema la lee y almacena en caché cuando se instala o actualiza la aplicación, sin necesidad de que el proceso de esta esté en ejecución. Las actualizaciones dinámicas opcionales permiten cambiar las reglas según la situación del usuario o las condiciones comerciales. Deben utilizar números de versión cada vez mayores y, si falla una actualización, debe conservarse la política válida anterior.

Publicidad

Los registros de auditoría dejan constancia, con límites de conservación

El protocolo proporciona interfaces para que las aplicaciones consulten los agentes registrados y los registros de auditoría relacionados con su propia aplicación. La información de identidad puede incluir el identificador del agente, el nombre del paquete, la firma, el tipo, la condición de confianza y la versión. El mero hecho de estar registrado no significa que un agente esté autorizado para todas las acciones comerciales.

El diseño de auditoría registra tanto la decisión de la política como el resultado real de la ejecución. Esto permite a los desarrolladores distinguir entre una acción permitida que falla y una acción rechazada seguida de un intento de eludir la restricción. Los registros pueden vincular un agente con una sesión, un paso de una tarea, la aplicación de destino, la página, el tipo de acción, la versión de la política y el código del motivo.

La guía exige limitar la información divulgada: los registros de auditoría no deben contener capturas de pantalla originales, información personal sensible introducida por los usuarios ni árboles completos de controles de la interfaz. Las aplicaciones solo pueden consultar registros asociados a su propio paquete, no inspeccionar los historiales de otras aplicaciones.

Los registros se almacenan en una zona segura del dispositivo y, por defecto, se conservan durante 60 días. También se inicia la eliminación por antigüedad cuando la base de datos supera los 100 MB o el número de registros excede los 100.000. Estos son límites alternativos, por lo que un dispositivo con mucha actividad puede perder registros antiguos antes de que transcurran 60 días. Las funciones reales de consulta, exportación y conservación dependen de la versión del sistema.

Doubao ha descrito por separado su preferencia por procesar la información sensible en el dispositivo. Su equipo afirma que los datos que deben enviarse a la nube reciben cifrado adicional en el dispositivo y que la clave correspondiente se destruye al finalizar la sesión. Se trata de prácticas de diseño declaradas, no de una conclusión independiente de que todos los procesos desplegados las cumplan.

La elección del usuario y el control del desarrollador siguen en tensión

SAEP ofrece a los desarrolladores una forma estructurada de rechazar o limitar la automatización, pero esto no resuelve el debate jurídico sobre si un asistente que actúa en nombre de un usuario necesita un permiso independiente de cada aplicación. Las reglas de funcionamiento del protocolo y la situación jurídica de la autorización del usuario son cuestiones distintas.

Ge Jiangqiu, profesor asociado de la Facultad de Derecho de la Universidad de Fudan, sostiene que un agente, en esencia, ayuda al usuario o actúa en su nombre, y que los efectos jurídicos de sus acciones corresponden a ese usuario. Wu Peicheng, investigador de la Facultad de Derecho Guanghua de la Universidad de Zhejiang, respalda un enfoque basado en una única autorización del usuario y sostiene que exigir permisos adicionales de las plataformas restringiría el uso cotidiano y elevaría los costos del sector.

Zhai Wei, director ejecutivo del Centro de Investigación sobre Derecho de la Competencia de la Universidad de Ciencias Políticas y Derecho de China Oriental, plantea el acceso entre aplicaciones en términos del control del usuario sobre sus datos personales, incluida su portabilidad y eliminación. Huang Yinxu, profesor asociado de la Facultad de Derecho de la Universidad Renmin de China, sostiene de manera similar que una autorización válida del sistema no debería exigir permisos reiterados de plataformas externas cuando un agente ejecuta fielmente las instrucciones del usuario.

Estas son posturas académicas, no un fallo judicial que elimine las restricciones de los desarrolladores. En la práctica, el enfoque anunciado por Doubao respeta los rechazos explícitos. Por tanto, según las reglas de funcionamiento del asistente, las instrucciones del usuario no anulan la prohibición de una aplicación.

Publicidad

Qué pueden esperar los usuarios

La versión del NaviX Ultra con 12 GB de memoria y 512 GB de almacenamiento se puso a la venta por 5.999 yuanes, con un precio inicial de 5.499 yuanes tras la subvención nacional. Esto supone una reducción de 500 yuanes, o alrededor del 8,3 % del precio anunciado. Comprar el dispositivo no garantiza el acceso a todas las aplicaciones ni que se complete cualquier tarea.

Las demostraciones de Doubao muestran la experiencia prevista: un asistente que utiliza la cámara para encontrar un armario de dimensiones y presupuesto determinados, o que usa una dirección conocida para pedir un vehículo. Esas demostraciones ilustran flujos de trabajo previstos, no prueban que todos los servicios de compras o transporte los permitan según las reglas actuales.

No se ha anunciado un calendario detallado para habilitar el acceso a aplicaciones concretas tras el 14 de octubre. Las descripciones publicadas tampoco establecen una tasa definitiva de aceptación, un calendario completo de despliegue ni una aplicación técnica uniforme de todas las restricciones sobre acciones específicas en las versiones compatibles.

La próxima prueba práctica será comprobar si los usuarios reciben explicaciones previsibles cuando una tarea se detiene: si se debe al rechazo de un desarrollador, a una página protegida, a una regla de seguridad del sistema o a una solicitud de confirmación personal. La apertura gradual amplía el alcance posible del asistente, mientras que SAEP determina dónde debe terminar.

Puntos clave

  • Doubao anunció la apertura gradual de la automatización de pantalla en aplicaciones de terceros el 14 de octubre, tras un periodo de aviso de 30 días.
  • El asistente no operará las aplicaciones que denieguen explícitamente el acceso.
  • La lista de rechazos incluye importantes servicios de Alibaba y Tencent, bancos, plataformas de compras y otras aplicaciones populares.
  • Los desarrolladores aún pueden denegar el acceso; Doubao se compromete a responder en un plazo de tres días laborables.
  • SAEP permite establecer restricciones para aplicaciones completas, páginas individuales y acciones comerciales específicas.
  • Los requisitos de seguridad del sistema y la autorización del usuario siguen siendo necesarios, incluso cuando una aplicación permite la automatización.
  • La guía oficial especifica ObricUI 2.2 y versiones posteriores, y algunas funciones dependen de la versión de destino.
  • No se ha anunciado un calendario detallado para habilitar aplicaciones concretas.
Compartir este artículo

También le puede interesar