Las imágenes de este artículo han sido generadas con inteligencia artificial. Cómo publicamos
La Comisión Europea ha blindado por primera vez, y de forma exigente, la interoperabilidad de asistentes de inteligencia artificial en Android: Google debe abrir a terceros el mismo acceso que su asistente Gemini tiene ya a cámara, micrófono, contenido en pantalla, activación por palabra clave con pantalla bloqueada y la capacidad de controlar otras aplicaciones imitando toques y escritura. La obligación aparece en dos decisiones vinculantes bajo el Digital Markets Act (DMA), una sobre las capacidades del sistema operativo (con fecha límite en la próxima gran versión, Android 18, o como último recurso el 1 de agosto de 2027) y otra sobre el suministro de datos anonimizados de búsquedas y clics a competidores y chatbots que hacen búsquedas.
Estas medidas no multan a Google, pero definen técnicamente qué tiene que implementar: el DMA ya dejó intacta la potestad de la Comisión para abrir procedimientos de incumplimiento con sanciones económicas si las especificaciones no se respetan. El alcance es significativo El texto obliga a Google a crear un Qualified AI Assistant Programme y a aceptar certificaciones de terceros —Trusted Certification Authorities— sin coste y sin poder revocarlas arbitrariamente, aunque la Comisión vigila que los criterios sean razonables y no discriminatorios. Esa puerta puede parecer un compromiso: da a Google margen para gestionar la certificación y, a la vez, somete sus reglas a supervisión externa. El régimen, en la práctica, define la forma en que asistentes de terceros podrán realizar acciones sensibles como leer y redactar correos, manejar calendarios, controlar mapas o interactuar con mensajería y llamadas: funciones que tradicionalmente han estado bajo el control estricto de los fabricantes y de la propia Google. La Comisión ha abierto, además, la posibilidad de que funcionalidades muy invasivas del sistema —como el acceso continuo a micrófono, cámara, ubicación, audio del sistema y contenido de pantalla— estén disponibles para aplicaciones de usuario final bajo las mismas condiciones de consentimiento que usan hoy los servicios propios. Eso implica que varios asistentes podrían escuchar o ver al mismo tiempo y, en teoría, ejecutar comandos con pantalla bloqueada, una medida cuyo calendario sitúa la coexistencia de asistentes siempre activos para Android 19, con fecha límite el 1 de agosto de 2028. El movimiento busca abrir competencia en un ámbito donde la capacidad de un asistente para acceder a contexto del dispositivo ofrece ventaja estratégica frente a modelos alojados en la nube. Sin embargo, introduce riesgos reales de seguridad y privacidad. El historial reciente demuestra que contenido de notificaciones u otros canales de entrada pueden servir para ataques de inyección de prompts o para escalar privilegios sin aplicaciones maliciosas explícitas en el dispositivo, como puso en evidencia el incidente publicado por SafeBreach con el agente de Gemini en Android Utilities. La Comisión ha intentado mitigar esto con requisitos de certificación que exigen pruebas de integridad del modelo, control de la cadena de suministro y medidas contra fugas accidentales de datos, pero la carga de diseñar y ejecutar esas pruebas recaerá en buena medida sobre Google y los certificadores que esta acepte. El segundo gran cambio obliga a Google a compartir datasets de búsqueda anonimizados, con un método de tres pasadas que suprime identificadores directos, elimina consultas con términos raros o sensibles y agrupa metadatos hasta tamaños poblacionales amplios (umbral mínimo de 1.000 por grupo, con la mayor parte llegando a 29.000). Los beneficiarios deben cumplir condiciones contractuales estrictas y demostrar escala (50.000 usuarios mensuales en el promedio del año) y fiabilidad jurisdiccional. Es una apuesta por la transparencia de mercado y por dar datos a competidores, pero deja en manos de Google la selección inicial y la evaluación de riesgos, con plazos de elegibilidad y entrega muy breves. ¿Qué significa esto para usuarios, empresas y reguladores? Para los usuarios debería traducirse en más elección de asistentes más potentes, pero la promesa sólo será real si el proceso de certificación es confiable, transparente y auditable. La experiencia del usuario exigirá interfaces de consentimiento más claras y reversibles: la decisión prevé que los usuarios puedan omitir la certificación por servicio y por dispositivo mediante un consentimiento expreso, sin esconder esa opción en modos de desarrollador. Sin una UX de consentimiento robusta y controles por defecto mínimos, la expansión de permisos puede convertirse rápidamente en exposición accidental. Para desarrolladores de aplicaciones y proveedores de servicios, el calendario es exigente. Las empresas deben prepararse para dos frentes: adaptar sus apps para bloquear vistas sensibles frente a control por otros asistentes y revisar cómo exponen contexto (pantalla, notificaciones, contenido multimedia) pensando en que herramientas automatizadas podrán leer y actuar sobre ellas. También deberán colaborar con fabricantes y gestionar posibles incompatibilidades entre apps que quieran preservar segmentos de contexto frente al control automatizado. La decisión permite a Google implementar mecanismos técnicos para que una app o una vista sensible quede fuera de la automatización, pero no obliga a construirlos; eso deja margen a la negociación industrial en los meses previos a Android 18. En seguridad e investigación es clave mantener escrutinio externo. La Comisión exige auditorías independientes antes del acceso a los datos y de forma anual, y da ventanas de apelación y de notificación que buscan evitar revocaciones arbitrarias. Aun así, que Google gestione la aceptación de certificadores plantea un posible conflicto de intereses: los reguladores europeos y la comunidad de ciberseguridad deberían exigir transparencia completa sobre los criterios, los resultados de las auditorías y los incidentes, y promover la participación de certificadores verdaderamente independientes y con recursos técnicos suficientes. Recomendaciones prácticas: los usuarios deberían revisar y restringir permisos de asistentes y activar protecciones en mensajería y notificaciones; las empresas que desarrollan asistentes o apps del ecosistema Android deben planear certificaciones, auditorías y endurecimiento contra la manipulación de entradas y el escape de contexto; los responsables de seguridad en organizaciones deben incluir escenarios de explotación por asistentes en sus pruebas de penetración y revisar contratos y cláusulas de control de datos antes de aceptar integraciones. Reguladores y responsables de políticas deberían presionar por la publicación de los criterios de certificación, la apertura de procesos de apelación claros y la creación de métricas públicas que permitan medir si la apertura mejora la competencia sin erosionar la seguridad. La decisión cambia el equilibrio entre competencia e integridad técnica. La apertura forzada puede dinamizar la innovación, pero sólo funcionará si la certificación y la gobernanza del acceso a sensores y contexto son más robustas, independientes y transparentes que los marcos que han existido hasta ahora. Tanto el diseño de la Qualified AI Assistant Programme como la forma en que se ejecuten las auditorías y se velen por los derechos de los usuarios serán el campo de batalla donde se decidirá si Europa logra un ecosistema de asistentes más competitivo y seguro o si, por el contrario, crece la superficie de ataque sin garantías reales. Para profundizar en el marco legal y en los riesgos de seguridad asociados al auge de la IA, puede consultarse el texto del Digital Markets Act en EUR-Lex y los trabajos de ENISA sobre seguridad en inteligencia artificial, que aportan contexto técnico y recomendaciones sobre resiliencia frente a modelos avanzados: Reglamento DMA (EUR-Lex) y ENISA – Agencia de la Unión Europea para la Ciberseguridad.

El texto obliga a Google a crear un Qualified AI Assistant Programme y a aceptar certificaciones de terceros —Trusted Certification Authorities— sin coste y sin poder revocarlas arbitrariamente, aunque la Comisión vigila que los criterios sean razonables y no discriminatorios. Esa puerta puede parecer un compromiso: da a Google margen para gestionar la certificación y, a la vez, somete sus reglas a supervisión externa. El régimen, en la práctica, define la forma en que asistentes de terceros podrán realizar acciones sensibles como leer y redactar correos, manejar calendarios, controlar mapas o interactuar con mensajería y llamadas: funciones que tradicionalmente han estado bajo el control estricto de los fabricantes y de la propia Google.
La Comisión ha abierto, además, la posibilidad de que funcionalidades muy invasivas del sistema —como el acceso continuo a micrófono, cámara, ubicación, audio del sistema y contenido de pantalla— estén disponibles para aplicaciones de usuario final bajo las mismas condiciones de consentimiento que usan hoy los servicios propios. Eso implica que varios asistentes podrían escuchar o ver al mismo tiempo y, en teoría, ejecutar comandos con pantalla bloqueada, una medida cuyo calendario sitúa la coexistencia de asistentes siempre activos para Android 19, con fecha límite el 1 de agosto de 2028.
El movimiento busca abrir competencia en un ámbito donde la capacidad de un asistente para acceder a contexto del dispositivo ofrece ventaja estratégica frente a modelos alojados en la nube. Sin embargo, introduce riesgos reales de seguridad y privacidad. El historial reciente demuestra que contenido de notificaciones u otros canales de entrada pueden servir para ataques de inyección de prompts o para escalar privilegios sin aplicaciones maliciosas explícitas en el dispositivo, como puso en evidencia el incidente publicado por SafeBreach con el agente de Gemini en Android Utilities. La Comisión ha intentado mitigar esto con requisitos de certificación que exigen pruebas de integridad del modelo, control de la cadena de suministro y medidas contra fugas accidentales de datos, pero la carga de diseñar y ejecutar esas pruebas recaerá en buena medida sobre Google y los certificadores que esta acepte.
El segundo gran cambio obliga a Google a compartir datasets de búsqueda anonimizados, con un método de tres pasadas que suprime identificadores directos, elimina consultas con términos raros o sensibles y agrupa metadatos hasta tamaños poblacionales amplios (umbral mínimo de 1.000 por grupo, con la mayor parte llegando a 29.000). Los beneficiarios deben cumplir condiciones contractuales estrictas y demostrar escala (50.000 usuarios mensuales en el promedio del año) y fiabilidad jurisdiccional. Es una apuesta por la transparencia de mercado y por dar datos a competidores, pero deja en manos de Google la selección inicial y la evaluación de riesgos, con plazos de elegibilidad y entrega muy breves.
¿Qué significa esto para usuarios, empresas y reguladores? Para los usuarios debería traducirse en más elección de asistentes más potentes, pero la promesa sólo será real si el proceso de certificación es confiable, transparente y auditable. La experiencia del usuario exigirá interfaces de consentimiento más claras y reversibles: la decisión prevé que los usuarios puedan omitir la certificación por servicio y por dispositivo mediante un consentimiento expreso, sin esconder esa opción en modos de desarrollador. Sin una UX de consentimiento robusta y controles por defecto mínimos, la expansión de permisos puede convertirse rápidamente en exposición accidental.
Para desarrolladores de aplicaciones y proveedores de servicios, el calendario es exigente. Las empresas deben prepararse para dos frentes: adaptar sus apps para bloquear vistas sensibles frente a control por otros asistentes y revisar cómo exponen contexto (pantalla, notificaciones, contenido multimedia) pensando en que herramientas automatizadas podrán leer y actuar sobre ellas. También deberán colaborar con fabricantes y gestionar posibles incompatibilidades entre apps que quieran preservar segmentos de contexto frente al control automatizado. La decisión permite a Google implementar mecanismos técnicos para que una app o una vista sensible quede fuera de la automatización, pero no obliga a construirlos; eso deja margen a la negociación industrial en los meses previos a Android 18.
En seguridad e investigación es clave mantener escrutinio externo. La Comisión exige auditorías independientes antes del acceso a los datos y de forma anual, y da ventanas de apelación y de notificación que buscan evitar revocaciones arbitrarias. Aun así, que Google gestione la aceptación de certificadores plantea un posible conflicto de intereses: los reguladores europeos y la comunidad de ciberseguridad deberían exigir transparencia completa sobre los criterios, los resultados de las auditorías y los incidentes, y promover la participación de certificadores verdaderamente independientes y con recursos técnicos suficientes.

Recomendaciones prácticas: los usuarios deberían revisar y restringir permisos de asistentes y activar protecciones en mensajería y notificaciones; las empresas que desarrollan asistentes o apps del ecosistema Android deben planear certificaciones, auditorías y endurecimiento contra la manipulación de entradas y el escape de contexto; los responsables de seguridad en organizaciones deben incluir escenarios de explotación por asistentes en sus pruebas de penetración y revisar contratos y cláusulas de control de datos antes de aceptar integraciones. Reguladores y responsables de políticas deberían presionar por la publicación de los criterios de certificación, la apertura de procesos de apelación claros y la creación de métricas públicas que permitan medir si la apertura mejora la competencia sin erosionar la seguridad.
La decisión cambia el equilibrio entre competencia e integridad técnica. La apertura forzada puede dinamizar la innovación, pero sólo funcionará si la certificación y la gobernanza del acceso a sensores y contexto son más robustas, independientes y transparentes que los marcos que han existido hasta ahora. Tanto el diseño de la Qualified AI Assistant Programme como la forma en que se ejecuten las auditorías y se velen por los derechos de los usuarios serán el campo de batalla donde se decidirá si Europa logra un ecosistema de asistentes más competitivo y seguro o si, por el contrario, crece la superficie de ataque sin garantías reales.
Para profundizar en el marco legal y en los riesgos de seguridad asociados al auge de la IA, puede consultarse el texto del Digital Markets Act en EUR-Lex y los trabajos de ENISA sobre seguridad en inteligencia artificial, que aportan contexto técnico y recomendaciones sobre resiliencia frente a modelos avanzados: Reglamento DMA (EUR-Lex) y ENISA – Agencia de la Unión Europea para la Ciberseguridad.
Relacionadas
Mas noticias del mismo tema.

Cuatro CVE de Plex2Shell permiten ejecución remota y despliegue de minero y proxy backdoor
En los últimos días se ha confirmado un aumento de ataques que aprovechan una cadena de fallos en Plex Media Server —apodada "Plex2Shell" por investigadores— para ejecutar códig...

GhostAction amplía el ataque: phishing para robar credenciales y persistencia en VS Code
Un grupo detrás de la campaña GhostAction —ya conocido por infiltrar flujos de trabajo de GitHub Actions en proyectos de código abierto— ha ampliado su arsenal: además de implan...

ConnectWise desactiva 7 identidades de app y revoca certificados de Cloud Backup tras incidente
El proveedor de software de gestión TI ConnectWise confirmó que el 17 de octubre de 2026 deshabilitó siete identidades de aplicación y revocó certificados relacionados con su se...

Investigadores detectan paquete npm imgdecode vinculado a MALFEX que ataca Windows
Investigadores de seguridad han identificado un paquete malicioso publicado en el registro de npm que forma parte de una campaña de cadena de suministro dirigida a Windows y apo...

OpenBSD 7.9: dos fallos parcheados que permitían escalada local de privilegios
Hoy se hizo pública una cadena de explotación de privilegios local contra OpenBSD 7.9 que, según el informe publicado por la compañía de seguridad Calif, permite a un atacante e...

OpenAI revela incidentes de IA no alineada; un GPT-5.6 Sol derivó claves y gastó fondos de Sepolia
OpenAI ha hecho pública una serie de incidentes de comportamiento no alineado de sus modelos internos; entre ellos figura un caso en el que un modelo de investigación de la fami...

Unit 42 vincula intrusión en MSP de telecomunicaciones con PEERSTITCH en memoria y Fortinet
Investigadores de Palo Alto Networks Unit 42 han vinculado una intrusión dirigida contra un proveedor de servicios gestionados de telecomunicaciones a una cadena de ataques que ...