Agent kodujący jako autor Twoich stron zgodności

Pisanie polityki prywatności to głównie przepisywanie. Najtrudniejsza część — ustalenie, co Twoja aplikacja faktycznie zbiera — wynika z plików, które już leżą w Twoim repozytorium, a to dokładnie taka praca, w której dobry jest agent z dostępem do systemu plików.

Co agent naprawdę może ustalić

Z samych plików buildu, bez pytania Cię o cokolwiek:

Fakt	Skąd pochodzi
Nazwa aplikacji	strings.xml app_name, CFBundleDisplayName, pubspec.yaml, app.json
Application / bundle id	applicationId w Gradle, PRODUCT_BUNDLE_IDENTIFIER w projekcie Xcode
Platforma	To, które z tych plików istnieją
Zbieranie danych	Każdy zewnętrzny SDK w build.gradle, Podfile, Package.swift, pubspec.yaml, package.json
Uprawnienia i opisy użycia	AndroidManifest.xml, Info.plist
Identyfikator wydawcy reklam	Identyfikator aplikacji AdMob w manifeście lub plist
Proponowany URL w Play	Zbudowany z application id — propozycja, a nie fakt, bo aplikacji może nie być w sklepie

Ta tabela to treść polityki prywatności. To także odpowiedź na pytanie „co zbiera moja aplikacja”, na które większość deweloperów odpowiada źle z pamięci, a dobrze po przeczytaniu plików.

Czego nie może wiedzieć i o co musi zapytać

Agent, który to wymyśla, jest gorszy niż brak agenta:

• Nazwa Twojego podmiotu prawnego i jurysdykcja, którą wskazują Twoje warunki.
• Adres wsparcia, który naprawdę czytasz. Agent nigdy nie może zgadywać go z konfiguracji gita ani z loginu dewelopera Apple znalezionego w pliku fastlane.
• Twój prawdziwy identyfikator w App Store, chyba że jest w konfiguracji fastlane — numerycznego identyfikatora nie da się wyprowadzić.
• Czy aplikacja jest już dostępna i pod którą stroną w sklepie.
• Fakty biznesowe: czy sprzedajesz subskrypcje, czy dzieci są grupą docelową, czy udostępniasz dane partnerowi, który nie zostawia śladu na liście zależności.
• Cokolwiek o Twoim backendzie. Nic w repozytorium nie mówi, jak długo przechowujesz dane.

Dobry wynik wygląda tak: wszystko, co da się wyprowadzić, jest wyprowadzone z podaniem pliku i linii, z których pochodzi, a reszta to krótka lista pytań, na które tylko Ty możesz odpowiedzieć.

Granice, których warto się trzymać

Zanim dopuścisz jakiegokolwiek agenta do tej pracy, rozstrzygnij te kwestie — to one odróżniają użyteczne narzędzie od źródła ryzyka:

1. Nic nie zostaje opublikowane bez kliknięcia człowieka. Wygenerowana strona prawna, która trafia do sieci bez przeglądu, to całe ryzyko w jednym zdaniu.
2. Każdy wyprowadzony fakt ma wskazane źródło. „Znalazłem firebase-crashlytics w app/build.gradle:47” da się sprawdzić; „Twoja aplikacja zbiera dane diagnostyczne” — nie.
3. Nie robi commitów ani pushy. Zaproponowanie diffa to pomoc; przepisanie Twojego repozytorium — nie.
4. Wysyła poza Twój komputer minimum. Ustalenie faktów lokalnie i wysłanie wniosków to coś zupełnie innego niż przesłanie Twojego kodu źródłowego.
5. Mówi, czego nie wie. Agent, który wypełnia tekst zastępczy wiarygodnie brzmiącym zdaniem, wytworzył dokument zgodności zawierający zgadywanie.

Zadaj te pięć pytań każdemu narzędziu w tej kategorii, łącznie z naszym.

Gdzie człowiek zostaje w pętli

Agent przygotowuje szkic; Ty decydujesz. Konkretnie to Ty:

• potwierdzasz odpowiedzi na pytania, których nie mógł wyprowadzić;
• czytasz sekcję o podmiotach zewnętrznych, czyli tę część, którą weryfikator porównuje z Twoim formularzem Data safety;
• decydujesz o okresach przechowywania, bo tylko Ty znasz swój backend;
• klikasz „publikuj”;
• wypełniasz pola w konsoli sklepu — żaden agent nie powinien być w Twojej Play Console.

Jeśli Twoja aplikacja dotyka pieniędzy, danych o zdrowiu lub dzieci, godzina prawnika nadal należy do tej listy. Szablon przygotowany na podstawie dowodów to lepszy punkt wyjścia niż pusta strona; nie jest poradą.

Co robi tutaj AppFoyer

Jest wtyczka do Claude Code. Instalujesz ją, mówisz „make this app store-ready”, a skill czyta Twoje pliki buildu, ustala powyższą tabelę z plikiem i linią dla każdego faktu, pyta tylko o to, czego nie znalazł, i przygotowuje wszystkie pięć stron oraz app-ads.txt. Następnie przekazuje Ci URL do przeglądu w panelu.

Powyższe granice są egzekwowane, a nie tylko obiecane. Dane uwierzytelniające agenta dają dostęp do stałego zestawu narzędzi — wyświetlanie listy i odczyt aplikacji, ich tworzenie (jedna na wariant builda), aktualizacja ustawień, szkice stron, app-ads.txt, checklista, ikona aplikacji i własny adres — i publikowania nie ma wśród nich: request_publish daje Ci link, a nie działającą stronę. Ikona i adres to jedyne dwie rzeczy bez etapu szkicu, więc agent mówi, kiedy je ustawił, i nie zastąpi adresu, którego już używasz, bez pytania. Agent nie może publikować, cofać publikacji, usuwać aplikacji, zmieniać kanałów powiadomień ani dotykać Twojej skrzynki próśb o usunięcie; to działania dostępne tylko w sesji, które wykonujesz sam. Pełna lista narzędzi i przykłady są na stronie dokumentacji agenta. Skill nigdy nie robi commitów ani pushy i proponuje diff tylko wtedy, gdy poprosisz go o wpięcie gotowych adresów URL z powrotem do aplikacji.

Jeśli Twoim agentem nie jest Claude Code — tylko Cursor, Codex albo asystent czatu — strona prywatności ma zamiast tego drogę przez kopiuj-wklej: edytor daje Ci prompt już wypełniony danymi Twojej aplikacji, uruchamiasz go, gdzie chcesz, i wklejasz odpowiedź z powrotem. Prompt i to, dlaczego jest tak sformułowany, opisujemy w poradniku Jak napisać politykę prywatności aplikacji z asystentem AI.

Jeśli nie masz agenta, to samo istnieje jako krótki formularz. Ścieżka z agentem jest szybsza, bo odpowiedzi są już w Twoim repozytorium — to nie jest inny produkt.

Źródła oficjalne

• Podawanie informacji do sekcji Data safety w Google Play — Centrum pomocy Konsoli Google Play, o tym, że dane z SDK deklarujesz Ty
• Szczegóły prywatności aplikacji w App Store — Apple
• Prywatność i bezpieczeństwo w Firebase — przykład ujawnienia dla pojedynczego SDK, które czyta agent