Permisos del asistente de IA en Android 17: privacidad y auditoría

Qué cambia Android 17 para los asistentes de IA

Android 17 alcanzó su versión estable en junio de 2026 y aporta varios cambios relevantes para los asistentes de IA. La respuesta breve es que el sistema favorece entradas más concretas, hace más visible el uso de datos sensibles y establece límites más claros para acciones relacionadas con contactos, ubicación, códigos de un solo uso, redes locales, dispositivos protegidos y determinados comportamientos de audio en segundo plano.

Estos cambios no forman un único permiso llamado “asistente de IA”. Cada tarea sigue utilizando capacidades distintas. Preparar un mensaje puede necesitar un contacto elegido; controlar un dispositivo doméstico puede requerir acceso a la red local; consultar un lugar utiliza ubicación; y una orden por voz depende del micrófono y del estado visible de la grabación. El usuario debe poder reconocer qué permiso corresponde a cada finalidad.

Google resume el lanzamiento y su alcance en el anuncio de la versión estable de Android 17. La llegada efectiva a cada teléfono depende del fabricante, el modelo y su calendario de actualización. Algunas reglas también varían según la versión de Android a la que apunte la aplicación, el soporte del dispositivo y la forma en que el desarrollador implemente el flujo.

El primer paso después de actualizar consiste en revisar las tareas reales del asistente, no solo la lista de permisos instalada. Para cada flujo, identifica el dato mínimo, el estado visible, la confirmación necesaria y la prueba de que la acción terminó correctamente.

Contactos y archivos elegidos en lugar de acceso amplio

Android 17 incorpora un selector de contactos del sistema. Según la documentación de funciones y APIs de Android 17, una aplicación puede pedir al usuario que elija contactos concretos para una tarea. Este recorrido permite preparar determinados mensajes, llamadas o invitaciones sin empezar por una autorización general sobre toda la libreta.

Imagina que solicitas al asistente: “Prepara una invitación para Marta y Luis”. El selector puede mostrar la interfaz del sistema para que elijas las dos personas correctas. La aplicación recibe el alcance necesario para continuar con esos contactos y puede presentar después una vista previa del mensaje. El usuario conserva una decisión visible tanto sobre las personas seleccionadas como sobre el contenido final.

Este patrón resulta especialmente útil cuando hay nombres repetidos, perfiles profesionales y personales o contactos que comparten un número antiguo. La selección explícita resuelve la identidad antes de que el agente planifique la acción. También reduce la posibilidad de que una consulta general del asistente utilice entradas ajenas a la tarea.

El mismo principio se aplica a archivos, fotos y vídeos. Para resumir un documento o analizar una imagen, el usuario puede seleccionar el elemento correspondiente mediante la interfaz prevista por Android. La tarea recibe un recurso elegido, con un origen claro y una duración de acceso que la aplicación debe gestionar.

Seleccionar un dato es el comienzo del control, mientras el destino mantiene su propia importancia. Antes de enviar la invitación, comprueba destinatarios, texto, fecha y aplicación de mensajería. Antes de subir un archivo, revisa qué contiene, a qué servicio se enviará y durante cuánto tiempo seguirá vinculado a la tarea.

• Elige únicamente los contactos necesarios para esa operación.
• Confirma identidades cuando existan nombres parecidos.
• Revisa el canal de comunicación y el contenido preparado.
• Selecciona archivos o imágenes desde una interfaz visible.
• Retira o renueva el acceso cuando cambie la finalidad.

El selector mejora la precisión del alcance, aunque cada aplicación debe adoptarlo donde encaje. Algunos flujos legítimos, como una agenda completa gestionada por el usuario, pueden requerir permisos diferentes. La auditoría debe valorar si la solicitud coincide con la tarea concreta en lugar de imponer un único modelo a todos los usos.

Ubicación y acceso a la red local

Ubicación y red local suelen aparecer juntas en tareas de hogar inteligente, pero representan capacidades diferentes. Android 17 amplía la visibilidad sobre el acceso a la ubicación, mientras la conexión con servicios de la red local dispone de una separación más clara. Un asistente debe explicar cuál necesita y qué pretende hacer con ella.

La guía de Android 17 sobre mejoras de privacidad de ubicación describe nuevas herramientas y señales para que el uso de este dato resulte más comprensible. En un flujo de navegación, el usuario debería poder distinguir entre buscar una dirección escrita y utilizar la posición actual. La segunda opción necesita ubicación; la primera puede comenzar sin ella.

La red local entra en juego cuando una app descubre o controla dispositivos cercanos, como un televisor, una impresora o un servicio doméstico. El permiso correspondiente indica que la aplicación quiere comunicarse dentro de esa red. Esto no equivale a una autorización general sobre la ubicación ni garantiza que todos los dispositivos utilicen el mismo protocolo.

Supongamos que pides: “Busca la impresora del despacho y abre la pantalla para imprimir este archivo”. El agente puede necesitar acceso a la red local para localizar el dispositivo, pero el archivo debe seleccionarse por separado. Después conviene mostrar el nombre de la impresora, el documento, las páginas y las opciones antes de enviar el trabajo.

Si el usuario deniega el acceso, el asistente debe conservar el objetivo y ofrecer una recuperación concreta. Puede explicar qué función quedó detenida, abrir la página de permisos correspondiente o permitir que el usuario introduzca manualmente el destino. Cambiar silenciosamente a otra red o ampliar la búsqueda produciría un alcance distinto al elegido.

Para auditar estas tareas, prueba ubicación y red local por separado. Retira la ubicación y comprueba si una búsqueda por dirección todavía funciona. Después revoca la red local y observa si el agente presenta el dispositivo como inaccesible. El mensaje de recuperación debe identificar el permiso ausente sin mezclar ambas causas.

Códigos de un solo uso y notificaciones sensibles

Los códigos de un solo uso, conocidos como OTP, pertenecen al proceso de autenticación. Aunque lleguen por SMS o notificación, su finalidad es demostrar que la persona controla una cuenta, un número o una sesión. Android 17 refuerza la protección del contenido relacionado con estos códigos para mantenerlos fuera de recorridos rutinarios de automatización.

La lista oficial de cambios de comportamiento de Android 17 reúne las modificaciones de privacidad, seguridad, compatibilidad y ejecución que pueden afectar a las aplicaciones. La protección de contenido sensible implica que un asistente debe tratar el código como una credencial temporal, no como otro fragmento de texto disponible para resumir, reenviar o incorporar a su memoria de conversación.

Un flujo apropiado puede comenzar cuando el usuario abre una aplicación que solicita verificación. El sistema muestra la notificación o el mecanismo de introducción permitido, y la persona completa el paso mediante la interfaz prevista. El asistente puede explicar dónde continuar o mantener la tarea en espera, mientras el secreto permanece dentro del recorrido de autenticación.

La separación también protege contra errores de destinatario. Una orden general como “reenvía los últimos mensajes a mi compañero” debe excluir los códigos de autenticación. Del mismo modo, un resumen de notificaciones debería centrarse en información ordinaria y señalar que existe una solicitud de verificación sin reproducir su valor.

Si el acceso automático al código queda restringido, la recuperación debe ser visible. El asistente puede pedir al usuario que complete la verificación en la app, esperar a que cambie el estado de la sesión y continuar después con la tarea original. También debe reconocer cuándo el código ha caducado y permitir solicitar uno nuevo desde el servicio adecuado.

El resultado que hay que verificar es la autenticación, no la lectura del código. Una pantalla de cuenta abierta, una sesión iniciada o un mensaje de verificación correcta proporcionan la evidencia necesaria para continuar. El secreto puede desaparecer sin afectar al resto del flujo.

Comportamiento bajo el Modo de Protección Avanzada

Android 17 expone a las aplicaciones el estado del Modo de Protección Avanzada. Esta señal permite que una app adapte su comportamiento cuando el usuario ha elegido políticas de seguridad más estrictas. En lugar de tratar una restricción como un error inesperado, el asistente puede mostrar que el dispositivo está operando bajo un nivel de protección reforzado.

Los usuarios protegidos pueden encontrar límites adicionales en operaciones consideradas de mayor riesgo. La experiencia adecuada consiste en identificar la política activa, explicar qué paso está afectado y ofrecer una ruta compatible. Por ejemplo, una importación desde una fuente restringida puede sustituirse por una selección mediante el sistema, o una acción automática puede quedar preparada para revisión manual.

El asistente debe conservar la decisión de seguridad del usuario. Si una tarea entra en conflicto con la política, la recuperación se adapta al modo activo: utilizar una herramienta permitida, reducir el alcance, abrir la pantalla oficial o dejar una propuesta sin ejecutar. El estado visible evita que la persona interprete el bloqueo como un fallo aleatorio.

También conviene probar cómo responde cada flujo con el modo activado. Una aplicación puede reconocer la señal de Android 17 y mostrar instrucciones específicas; otra puede limitar una función según sus propias políticas. La disponibilidad de la API no implica que todas las apps hayan adoptado la misma respuesta.

Quien prefiera reducir la automatización puede revisar Cómo desactivar la IA en Android y usar controles opcionales. El objetivo es elegir qué funciones permanecen activas y qué acciones requieren intervención directa, manteniendo una configuración comprensible.

Micrófono y audio en segundo plano

Los asistentes de voz dependen del micrófono, pero la autorización para utilizarlo debe conservar una finalidad visible. Android 17 incorpora cambios de comportamiento relacionados con el audio en segundo plano y la ejecución, de modo que las aplicaciones necesitan revisar cómo inician, mantienen e interrumpen sesiones de voz.

En primer plano, el usuario puede pulsar un botón, ver una animación de escucha y formular una orden. El estado resulta fácil de reconocer. Cuando la interacción continúa mientras se cambia de app o se apaga la pantalla, cobran más importancia los indicadores del sistema, la notificación de la sesión y la posibilidad de detenerla inmediatamente.

Antes de comenzar una captura de voz, comprueba:

• Qué aplicación utilizará el micrófono.
• Si la tarea es una orden breve, un dictado o una grabación prolongada.
• Qué indicador mostrará Android durante la escucha.
• Dónde se guardará o enviará el audio.
• Cómo se detiene la sesión y qué parte se conserva.

Durante el uso, el asistente debe mostrar que escucha, transcribe o procesa. Una llamada entrante, la pérdida de foco, la retirada del permiso o una política de segundo plano pueden interrumpir el recorrido. En ese caso, el estado debe cambiar de inmediato para que el usuario sepa que la captura terminó.

Después, hay que revisar el resultado. Para un mensaje dictado, comprueba texto y destinatario. Para una nota de voz, verifica archivo y ubicación. Para una orden, confirma qué herramienta se ejecutó. El permiso de micrófono permite captar audio dentro de sus condiciones; cada acción posterior conserva sus propios permisos y confirmaciones.

La recuperación de una sesión interrumpida debe evitar duplicados. Si una grabación quedó incompleta, el asistente puede ofrecer continuar en un archivo nuevo o descartar el fragmento. Si una orden se transcribió parcialmente, conviene mostrarla antes de ejecutar. Así, el cambio de comportamiento del sistema se convierte en un estado comprensible, no en una acción silenciosamente incompleta.

Auditoría de permisos para un asistente en Android 17

Una auditoría útil empieza por las tareas y termina con resultados observables. Revisar únicamente la pantalla de permisos revela qué accesos están concedidos, pero no demuestra cómo se comporta el asistente cuando falta uno, cambia el estado de la app o una política de Android 17 limita la operación.

Para profundizar en la diferencia entre aislamiento técnico y permisos reales, consulta Sandbox de agentes de IA y permisos del teléfono: por qué aún hacen falta límites. Un entorno aislado limita parte de la ejecución; los permisos siguen definiendo qué datos y operaciones puede utilizar cada herramienta.

La auditoría debe repetirse después de una actualización importante del sistema, de la aplicación o del fabricante. El comportamiento puede cambiar por compatibilidad, permisos revocados automáticamente o nuevas políticas. Superar una prueba hoy ofrece evidencia sobre esa configuración, mientras el registro de excepciones ayuda a detectar cambios posteriores.

Para ampliar la revisión hacia batería, estado del dispositivo y notificaciones, utiliza Comprobar salud del teléfono Android con IA: batería, permisos y notificaciones. Ambas guías comparten el mismo criterio: seleccionar contexto, limitar alcance, confirmar la acción y comprobar el resultado.

Aplicar los controles de Android 17 en FoneClaw

En FoneClaw diseñamos las tareas Android compatibles alrededor de herramientas explícitas, permisos visibles y recuperación. Una prueba de bajo riesgo después de actualizar a Android 17 puede consistir en preparar un mensaje para dos contactos elegidos, sin enviarlo durante el primer recorrido.

El usuario inicia la tarea y selecciona a las personas mediante el mecanismo disponible en su dispositivo. El modelo configurado dentro del agente interpreta la intención; FoneClaw recibe el contexto seleccionado y prepara el texto. Antes de avanzar, mostramos destinatarios, contenido y herramienta de comunicación para que puedan revisarse.

Si falta un permiso o el acceso se revocó, la tarea conserva su objetivo y presenta el estado correspondiente. El usuario puede conceder el alcance necesario, volver a seleccionar los contactos o dejar el borrador preparado. Esta recuperación evita sustituir silenciosamente el contexto y permite continuar desde el paso pendiente.

El progreso visible también ayuda cuando el flujo pasa por más de una pantalla. Android Halo: estado y progreso de agentes de IA en la barra superior explica cómo una señal persistente puede mostrar si el agente está esperando una selección, preparando una propuesta, solicitando aprobación o verificando el resultado.

Después de aprobar una acción compatible, comprobamos el estado en la aplicación de destino. Para un mensaje, el usuario debe ver el destinatario y el contenido en el lugar esperado. Para una tarea de red local, conviene confirmar el dispositivo elegido y el cambio producido. Si el resultado permanece ambiguo, el flujo vuelve a verificar antes de repetir la operación.

La disponibilidad práctica depende de Android, el teléfono, los permisos, el estado de las apps, la región y la tarea. Nuestra página de funciones de FoneClaw mantiene el alcance actual de las acciones compatibles. La página de descarga de FoneClaw permite elegir la opción vigente para probar un flujo reversible en un dispositivo compatible.

La prueba queda completa cuando el usuario puede responder cinco preguntas: qué contexto seleccionó, qué permiso concedió, qué herramienta actuó, qué dato confirmó y dónde vio el resultado. Ese recorrido convierte los cambios de privacidad de Android 17 en controles que pueden comprobarse durante una tarea real.