Usare un agente di programmazione per scrivere le tue pagine di conformità

Scrivere un’informativa sulla privacy è soprattutto trascrizione. La parte difficile, capire cosa raccoglie davvero la tua app, trova risposta in file che sono già nel tuo repository, ed è esattamente il tipo di lavoro in cui è bravo un agente con accesso al filesystem.

Cosa può ricavare davvero un agente

Dai soli file di build, senza chiederti nulla:

Fatto	Da dove viene
Nome dell’app	strings.xml app_name, CFBundleDisplayName, pubspec.yaml, app.json
Application id / bundle id	applicationId in Gradle, PRODUCT_BUNDLE_IDENTIFIER nel progetto Xcode
Piattaforma	Quali di quei file esistono
Raccolta di dati	Ogni SDK di terze parti in build.gradle, Podfile, Package.swift, pubspec.yaml, package.json
Permessi e stringhe di utilizzo	AndroidManifest.xml, Info.plist
ID publisher pubblicitario	L’ID applicazione AdMob nel manifest o nel plist
Un URL Play proposto	Costruito dall’application id: una proposta, non un fatto, perché l’app potrebbe non essere pubblicata

Quella tabella è la sostanza di un’informativa sulla privacy. È anche la risposta a “cosa raccoglie la mia app”, la domanda su cui la maggior parte degli sviluppatori sbaglia andando a memoria e azzecca leggendo.

Cosa non può sapere e deve chiedere

Un agente che si inventa queste cose è peggio di nessun agente:

• La ragione sociale e la giurisdizione indicata nei tuoi termini.
• L’indirizzo di supporto che leggi davvero. Non deve mai indovinarlo da una configurazione git o da un login sviluppatore Apple trovato in un file di fastlane.
• Il tuo vero ID App Store, a meno che non sia in una configurazione di fastlane: l’ID numerico non si può ricavare.
• Se l’app è pubblicata, e con quale scheda.
• Fatti commerciali: se vendi abbonamenti, se i bambini sono un pubblico di riferimento, se condividi dati con un partner che non lascia traccia nell’elenco delle dipendenze.
• Qualsiasi cosa sul tuo backend. Nulla nel repository dice per quanto tempo conservi i dati.

Un buon risultato è questo: tutto ciò che si può ricavare viene ricavato con il file e la riga da cui proviene, e ciò che resta è un breve elenco di domande a cui puoi rispondere solo tu.

Limiti su cui insistere

Prima di far avvicinare un agente qualsiasi a tutto questo, decidi questi punti: sono la differenza tra uno strumento utile e un rischio:

1. Nulla viene pubblicato senza il clic di una persona. Una pagina legale generata che va online senza revisione è l’intero rischio in una frase.
2. Ogni fatto ricavato è attribuibile. “Ho trovato firebase-crashlytics in app/build.gradle:47” si può verificare; “la tua app raccoglie dati diagnostici” no.
3. Non fa commit né push. Proporre un diff è un aiuto; riscrivere il tuo repository no.
4. Invia il minimo fuori dalla tua macchina. Ricavare i fatti in locale e inviare le conclusioni è molto diverso dal caricare il tuo codice sorgente.
5. Dice ciò che non sa. Un agente che riempie un segnaposto con una frase plausibile ha prodotto un documento di conformità che contiene un’ipotesi.

Fai queste cinque domande a qualsiasi strumento di questa categoria, compreso il nostro.

Dove la persona resta nel processo

L’agente redige; tu decidi. In particolare, sei tu che:

• confermi le domande che non ha potuto ricavare;
• leggi la sezione sulle terze parti, che è la parte che un revisore confronta con il tuo modulo Data safety;
• decidi i periodi di conservazione, perché solo tu conosci il tuo backend;
• fai clic su pubblica;
• compili i campi della console dello store: nessun agente dovrebbe stare dentro la tua Play Console.

Se la tua app tocca denaro, dati sanitari o bambini, un’ora di un avvocato fa ancora parte di questo elenco. Un modello redatto a partire da prove è un punto di partenza migliore di una pagina bianca; non è una consulenza.

Cosa fa AppFoyer

Esiste un plugin per Claude Code. Lo installi, dici “make this app store-ready”, e la skill legge i tuoi file di build, ricava la tabella qui sopra con file e riga per ogni fatto, chiede solo ciò che non ha potuto trovare, e redige tutte e cinque le pagine più app-ads.txt. Poi ti consegna un URL di revisione nella dashboard.

I limiti descritti sopra sono imposti, non promessi. La credenziale dell’agente raggiunge un insieme fisso di strumenti: elencare e leggere le app, crearle (una per flavor), aggiornare le impostazioni, redigere le pagine, app-ads.txt, la checklist, l’icona dell’app e un indirizzo personalizzato. E la pubblicazione non è tra questi: request_publish ti dà un link, non una pagina online. L’icona e l’indirizzo sono le due cose senza un passaggio di bozza, quindi l’agente ti dice quando li ha impostati, e non sostituisce un indirizzo che usi già senza chiedertelo. L’agente non può pubblicare, annullare la pubblicazione, eliminare un’app, modificare i canali di notifica o toccare la casella delle richieste di eliminazione; sono azioni riservate alla sessione che compi tu. L’elenco completo degli strumenti ed esempi pratici sono nella pagina della documentazione dell’agente. La skill non fa mai commit né push, e propone un diff solo quando le chiedi di collegare gli URL finali all’interno dell’app.

Se il tuo agente non è Claude Code (Cursor, Codex o un assistente di chat), la pagina della privacy ha invece una strada copia e incolla: l’editor ti dà un prompt già compilato con i dati della tua app, lo esegui dove vuoi e incolli la risposta. Il prompt, e perché è formulato così, sono in Scrivere la tua informativa sulla privacy con un assistente IA.

Se non hai un agente, la stessa cosa esiste come breve modulo. La strada dell’agente è più veloce perché le risposte sono già nel tuo repository: non è un prodotto diverso.

Le fonti ufficiali

• Provide information for Google Play’s Data safety section — Guida di Google Play Console, sul fatto che i dati degli SDK spetta a te dichiararli
• App privacy details on the App Store — Apple
• Privacy and security in Firebase — un esempio dell’informativa per singolo SDK che un agente legge