Google Play ya tiene reglas para cuando un agente de IA usa tu app
Resumen directo: el 29 de octubre Google publicó una actualización de políticas de Play que, entre otras cosas, regula por primera vez cómo se comporta tu app frente a los agentes de IA del dispositivo. Añade una política para la AppFunctions API y da pautas sobre cómo aplica la política de pagos cuando la compra la inicia un agente. No hay nada que tengas que tocar mañana, pero marca hacia dónde va la tienda. Si tu app expone, o va a exponer, funciones a asistentes como Gemini, esto te toca.
Qué ha pasado
El 29 de octubre de 2026 Google publicó su anuncio de políticas en Play Console, con el plazo habitual de al menos 30 días para adaptarse. La mayoría son ajustes ya conocidos: el permiso de red local llega con Android 17 (API 37), el permiso de contactos se restringe y la ubicación pasa a ser obligatoria el 27 de enero de 2027. De eso ya hemos escrito.
Lo nuevo son dos líneas que apuntan al mismo sitio. La primera es una política para la AppFunctions API: una app que exponga funciones a un agente tiene que seguir todas las políticas de Play, y esas funciones no pueden engañar ni manipular a los agentes de IA, saltarse controles de seguridad ni interferir con otras apps. La segunda es una pauta sobre cómo se aplica la política de pagos a las apps que facilitan compras digitales a través de experiencias agénticas.
Son dos frases dentro de un documento largo. Pero es la primera vez que Play trata la superficie del agente como un canal con reglas propias.
Qué es AppFunctions y por qué importa
AppFunctions es una función de plataforma de Android, disponible desde Android 16, con su librería de Jetpack. Permite que tu app declare funciones concretas (reservar, consultar un pedido, iniciar un pago) para que un agente del dispositivo, como Gemini, las descubra y las ejecute. El paralelismo que usa la propia documentación es MCP: donde MCP estandariza cómo un agente llega a herramientas en servidor, AppFunctions hace lo mismo para apps en el teléfono. Es, a grandes rasgos, el MCP on-device.
El mecanismo: anotas las funciones, la librería genera un esquema que el sistema indexa, y quien quiera invocarlas necesita el permiso EXECUTE_APP_FUNCTIONS. A partir de ahí tu app deja de ser solo una pantalla con la que interactúa una persona y pasa a ser también un conjunto de capacidades que otro software puede llamar.
Conviene bajar las expectativas: sigue en preview, la integración con Gemini está en acceso restringido y funciona en dispositivos recientes seleccionados. No es algo que tus usuarios tengan en la mano hoy.
Qué implica para tu producto
Aquí está el cambio que importa, aunque la adopción sea todavía mínima. Si publicas en Play, ya tienes dos superficies que Google revisa: la ficha de la tienda y el binario. AppFunctions añade una tercera, la del agente, y la política del 29 de octubre deja claro que también la va a gobernar.
Eso tiene consecuencias prácticas el día que lo adoptes. Exponer una función a un agente es abrir una entrada nueva, y hay que tratarla como tal: un agente puede llamar a tu función con una intención que tu interfaz nunca habría permitido. "No manipular al agente" y "no saltarse controles de seguridad" no son retórica; quieren decir que la validación que dabas por hecha en la pantalla tiene que vivir también detrás de la función. Y para los pagos que dispara un agente, la regla de siempre: la facturación de Play no desaparece porque la compra la lance un asistente en vez de un dedo.
Para la mayoría hay además una fricción técnica concreta. AppFunctions es nativo de Android, con anotaciones de Kotlin. Si trabajas en Flutter, hoy no hay un camino de primera clase: tocaría exponerlo por platform channels, con el coste de mantenimiento que eso añade por una superficie que casi nadie usa aún.
Nuestra recomendación
No lo construyas todavía. Para casi todos, AppFunctions en octubre de 2026 es una apuesta sin retorno claro: está en preview, en pocos dispositivos, y en Flutter te obliga a interop nativo para un público mínimo.
A quién sí le compensa mirarlo ya: equipos cuyo valor sea una acción discreta y de alta intención —reservar algo o consultar el estado de un pedido— que un usuario pediría sin pensar a un asistente, y que ya van Android-first con audiencia en los móviles más nuevos. Ahí, un prototipo detrás de un feature flag enseña más que la documentación.
Para el resto, el titular no es la API. Google está empezando a tratar al agente como un cliente de tu app, con sus propias reglas, y eso es lo que conviene interiorizar. Cuando AppFunctions (o su equivalente en iOS) salga de preview, la pregunta de producto no será "¿cómo lo integro?" sino "¿qué tres cosas de mi app tienen sentido que haga un agente sin abrir la pantalla?". Esa respuesta la puedes ir pensando ahora; no cuesta nada y te ahorra correr después.
En Dribba llevamos tiempo trabajando con MCP y agentes en producción. Si estás valorando qué parte de tu producto tiene sentido abrir a un agente, y cuál no, es justo el tipo de decisión en la que ayudamos a pensar.
