Usar un agente de programación para escribir tus páginas de cumplimiento

Escribir una política de privacidad es sobre todo transcribir. La parte difícil —averiguar qué recopila realmente tu app— la responden archivos que ya están en tu repositorio, que es justo el tipo de trabajo en el que es bueno un agente con acceso al sistema de archivos.

Qué puede deducir de verdad un agente

Solo a partir de los archivos de build, sin preguntarte nada:

Dato	De dónde sale
Nombre de la app	strings.xml app_name, CFBundleDisplayName, pubspec.yaml, app.json
Application id / bundle id	applicationId en Gradle, PRODUCT_BUNDLE_IDENTIFIER en el proyecto de Xcode
Plataforma	Cuáles de esos archivos existen
Recopilación de datos	Cada SDK de terceros en build.gradle, Podfile, Package.swift, pubspec.yaml, package.json
Permisos y textos de uso	AndroidManifest.xml, Info.plist
ID de publisher de anuncios	El application id de AdMob en el manifest o el plist
Una URL de Play propuesta	Construida a partir del application id: una propuesta, no un hecho, ya que puede que la app no esté publicada

Esa tabla es la sustancia de una política de privacidad. También es la respuesta a “qué recopila mi app”, la pregunta que la mayoría de los desarrolladores responde mal de memoria y bien leyendo.

Qué no puede saber y debe preguntar

Un agente que se inventa esto es peor que no tener agente:

• El nombre de tu entidad legal y la jurisdicción que indican tus términos.
• La dirección de soporte que realmente lees. Nunca debe deducirla de una configuración de git ni de un inicio de sesión de desarrollador de Apple encontrado en un archivo de fastlane.
• Tu id real del App Store, salvo que esté en una configuración de fastlane: el id numérico no se puede deducir.
• Si la app está publicada, y con qué ficha.
• Datos del negocio: si vendes suscripciones, si los niños son un público objetivo, si compartes datos con un socio que no deja rastro en la lista de dependencias.
• Cualquier cosa sobre tu backend. Nada en el repositorio dice cuánto tiempo conservas los datos.

Un buen resultado se ve así: todo lo deducible está deducido, con el archivo y la línea de donde salió, y lo que queda es una lista corta de preguntas que solo tú puedes responder.

Límites que conviene exigir

Antes de dejar que cualquier agente se acerque a esto, decide lo siguiente: es la diferencia entre una herramienta útil y un riesgo.

1. Nada se publica sin el clic de una persona. Una página legal generada que se publica sin revisar es todo el riesgo en una frase.
2. Cada dato deducido es atribuible. “He encontrado firebase-crashlytics en app/build.gradle:47” se puede comprobar; “tu app recopila diagnósticos” no.
3. No hace commit ni push. Proponer un diff es ayuda; reescribir tu repositorio no.
4. Envía lo mínimo fuera de tu máquina. Deducir los datos localmente y enviar las conclusiones es muy distinto de subir tu código fuente.
5. Dice lo que no sabe. Un agente que rellena un marcador de posición con una frase verosímil ha producido un documento de cumplimiento que contiene una suposición.

Hazle esas cinco preguntas a cualquier herramienta de esta categoría, incluida la nuestra.

Dónde sigue interviniendo la persona

El agente redacta; tú decides. En concreto, eres tú quien:

• confirma las preguntas que no pudo deducir;
• lee la sección de terceros, que es la parte que un revisor compara con tu formulario de Data safety;
• decide los plazos de conservación, porque solo tú conoces tu backend;
• hace clic en publicar;
• rellena los campos de la consola de la tienda: ningún agente debería estar dentro de tu Play Console.

Si tu app toca dinero, datos de salud o niños, una hora de un abogado sigue teniendo su lugar en esta lista. Una plantilla redactada a partir de evidencia es un punto de partida mejor que una página en blanco; no es asesoramiento.

Qué hace AppFoyer aquí

Hay un plugin de Claude Code. Lo instalas, dices “make this app store-ready” («prepara esta app para las tiendas») y el skill lee tus archivos de build, deduce la tabla de arriba con archivo y línea para cada dato, pregunta solo lo que no pudo encontrar y redacta las cinco páginas más app-ads.txt. Después te entrega una URL de revisión en el dashboard.

Los límites de arriba se aplican, no solo se prometen. La credencial del agente llega a un conjunto fijo de herramientas —listar y leer apps, crearlas (una por flavor), actualizar la configuración, redactar páginas, app-ads.txt, el checklist, el icono de la app y una dirección personalizada— y publicar no está entre ellas: request_publish te da un enlace, no una página publicada. El icono y la dirección son las dos cosas sin paso de borrador, así que el agente te dice cuándo las ha configurado, y no sustituirá una dirección que ya usas sin preguntarte. El agente no puede publicar, despublicar, eliminar una app, cambiar los canales de notificación ni tocar tu bandeja de solicitudes de eliminación; esas son acciones solo de sesión que haces tú. La lista completa de herramientas y ejemplos prácticos están en la página de documentación del agente. El skill nunca hace commit ni push, y propone un diff solo cuando le pides que conecte las URL finales en la app.

Si tu agente no es Claude Code —Cursor, Codex o un asistente de chat—, la página de privacidad tiene en su lugar una vía de copiar y pegar: el editor te da un prompt ya rellenado con los datos de tu app, lo ejecutas donde quieras y pegas la respuesta. El prompt y el porqué de su redacción están en Escribir tu política de privacidad con un asistente de IA.

Si no tienes agente, lo mismo existe como un formulario corto. La vía del agente es más rápida porque las respuestas ya están en tu repositorio; no es un producto distinto.

Las fuentes oficiales

• Proporcionar información para la sección Data safety de Google Play — Ayuda de Google Play Console, sobre que los datos de los SDK te corresponde declararlos a ti
• Detalles de privacidad de las apps en el App Store — Apple
• Privacidad y seguridad en Firebase — un ejemplo de la divulgación por SDK que lee un agente