Ihre Compliance-Seiten mit einem Coding-Agent schreiben
Die Fakten für diese Seiten stehen schon in Ihrem Repository. Was ein Agent wirklich ableiten kann, was er Sie fragen muss, und auf welchen Grenzen Sie vorher bestehen sollten.
Ein Coding-Agent, der Ihr Repository lesen kann, hat die Fakten für diese Seiten bereits: den App-Namen, die Bundle-ID, die Store-Links und jedes SDK im Build. Mit den richtigen Werkzeugen entwirft er die Seiten aus diesen Belegen und gibt Ihnen einen Link zur Prüfung – Sie prüfen und veröffentlichen.
Erledigen Sie das stattdessen in wenigen Minuten
AppFoyer hostet die Seiten, um die es in diesem Ratgeber geht – Datenschutzerklärung, Nutzungsbedingungen, Support, Kontolöschung und app-ads.txt –, auf einer eigenen Subdomain, ohne eigene Domain oder eigenen Server. Eine App ist kostenlos, und nichts, was ein Store verlangt, steht jemals hinter einer Bezahlschranke.
Geprüft am 25. September 2026. Store-Richtlinien ändern sich, manchmal ohne Ankündigung. Alles Folgende verlinkt die offizielle Dokumentation, und maßgeblich ist die dort verlinkte Seite, nicht diese hier. Widersprechen sich beide, hat der Store recht. Dieser Ratgeber ist aus dem Englischen übersetzt; Zitate aus der Store-Dokumentation bleiben im englischen Original.
Eine Datenschutzerklärung zu schreiben, ist größtenteils Übertragungsarbeit. Der schwierige Teil – herauszufinden, was Ihre App tatsächlich erhebt – wird von Dateien beantwortet, die bereits in Ihrem Repository liegen, und genau diese Art Arbeit kann ein Agent mit Dateisystemzugriff gut.
Was ein Agent wirklich ableiten kann
Allein aus den Build-Dateien, ohne Sie etwas zu fragen:
| Fakt | Woher er kommt |
|---|---|
| App-Name | strings.xml app_name, CFBundleDisplayName, pubspec.yaml, app.json |
| Application- / Bundle-ID | applicationId in Gradle, PRODUCT_BUNDLE_IDENTIFIER im Xcode-Projekt |
| Plattform | Welche dieser Dateien existieren |
| Datenerhebung | Jedes Drittanbieter-SDK in build.gradle, Podfile, Package.swift, pubspec.yaml, package.json |
| Berechtigungen und Usage-Strings | AndroidManifest.xml, Info.plist |
| Ad-Publisher-ID | Die AdMob-Application-ID im Manifest oder in der plist |
| Eine vorgeschlagene Play-URL | Aus der Application-ID gebildet – ein Vorschlag, kein Fakt, denn die App ist vielleicht nicht gelistet |
Diese Tabelle ist die Substanz einer Datenschutzerklärung. Sie ist auch die Antwort auf „Was erhebt meine App?“ – die Frage, die die meisten Entwickler aus dem Gedächtnis falsch und durch Lesen richtig beantworten.
Was er nicht wissen kann und fragen muss
Ein Agent, der diese Dinge erfindet, ist schlimmer als kein Agent:
- Den Namen Ihrer juristischen Person und die Rechtsordnung, die Ihre Nutzungsbedingungen nennen.
- Die Support-Adresse, die Sie tatsächlich lesen. Er darf sie nie aus einer Git-Konfiguration oder einem Apple-Developer-Login in einer fastlane-Datei erraten.
- Ihre echte App-Store-ID, sofern sie nicht in einer fastlane-Konfiguration steht – die numerische ID lässt sich nicht ableiten.
- Ob die App live ist und unter welchem Eintrag.
- Geschäftliche Fakten: ob Sie Abos verkaufen, ob Kinder eine Zielgruppe sind, ob Sie Daten mit einem Partner teilen, der in der Abhängigkeitsliste keine Spur hinterlässt.
- Alles über Ihr Backend. Nichts im Repository sagt, wie lange Sie Daten aufbewahren.
Ein gutes Ergebnis sieht so aus: Alles Ableitbare ist abgeleitet, mit der Datei und Zeile, aus der es stammt, und übrig bleibt eine kurze Liste von Fragen, die nur Sie beantworten können.
Grenzen, auf denen Sie bestehen sollten
Bevor Sie irgendeinen Agent heranlassen, legen Sie diese fest – sie machen den Unterschied zwischen einem nützlichen Werkzeug und einem Haftungsrisiko:
- Nichts wird ohne den Klick eines Menschen veröffentlicht. Eine generierte Rechtsseite, die ungeprüft live geht, ist das ganze Risiko in einem Satz.
- Jeder abgeleitete Fakt ist zuordenbar. „Ich habe
firebase-crashlyticsinapp/build.gradle:47gefunden“ ist überprüfbar; „Ihre App erhebt Diagnosedaten“ nicht. - Er committet und pusht nicht. Einen Diff vorzuschlagen ist Hilfe; Ihr Repo umzuschreiben nicht.
- Er sendet das Minimum von Ihrem Rechner. Fakten lokal abzuleiten und die Schlussfolgerungen zu senden, ist etwas ganz anderes, als Ihren Quellcode hochzuladen.
- Er sagt, was er nicht weiß. Ein Agent, der einen Platzhalter mit einem plausiblen Satz füllt, hat ein Compliance-Dokument erzeugt, das eine Vermutung enthält.
Stellen Sie diese fünf Fragen jedem Werkzeug in dieser Kategorie, auch unserem.
Wo der Mensch beteiligt bleibt
Der Agent entwirft; Sie entscheiden. Konkret sind Sie derjenige, der:
- die Fragen bestätigt, die er nicht ableiten konnte;
- den Drittanbieter-Abschnitt liest, also den Teil, den ein Prüfer mit Ihrem Data-safety-Formular vergleicht;
- über Aufbewahrungsfristen entscheidet, weil nur Sie Ihr Backend kennen;
- auf „Veröffentlichen“ klickt;
- die Felder in den Store-Konsolen ausfüllt – kein Agent sollte in Ihrer Play Console sein.
Wenn Ihre App mit Geld, Gesundheitsdaten oder Kindern zu tun hat, gehört eine Stunde bei einem Anwalt weiterhin auf diese Liste. Eine aus Belegen entworfene Vorlage ist ein besserer Ausgangspunkt als eine leere Seite; eine Beratung ist sie nicht.
Was AppFoyer hier tut
Es gibt ein Claude Code-Plugin. Sie installieren es, sagen „make this app store-ready“, und der Skill
liest Ihre Build-Dateien, leitet die Tabelle oben mit Datei und Zeile für jeden Fakt ab, fragt nur,
was er nicht finden konnte, und entwirft alle fünf Seiten plus app-ads.txt. Danach gibt er Ihnen
eine URL zur Prüfung im Dashboard.
Die Grenzen oben werden technisch durchgesetzt, nicht nur versprochen. Die Zugangsdaten des Agents
reichen für eine feste Menge von Werkzeugen – Apps auflisten und lesen, Apps anlegen (eine pro Flavor),
Einstellungen ändern, Seiten entwerfen, app-ads.txt, die Checkliste, das App-Icon und eine eigene
Adresse –, und Veröffentlichen gehört nicht dazu: request_publish gibt Ihnen einen Link, keine
Live-Seite. Icon und Adresse sind die beiden Dinge ohne Entwurfsschritt; deshalb sagt der Agent, wann
er sie gesetzt hat, und er ersetzt eine Adresse, die Sie bereits nutzen, nicht ohne Nachfrage. Der
Agent kann nicht veröffentlichen, nicht depublizieren, keine App löschen, keine
Benachrichtigungskanäle ändern und nicht auf Ihren Posteingang für Löschanfragen zugreifen; das sind
Aktionen nur in Ihrer Sitzung, die Sie selbst ausführen. Die vollständige Werkzeugliste und
ausgearbeitete Beispiele finden Sie auf der Doku-Seite zum Agent. Der Skill committet
und pusht nie und schlägt einen Diff nur vor, wenn Sie ihn bitten, die fertigen URLs in die App
einzubauen.
Wenn Ihr Agent nicht Claude Code ist – Cursor, Codex oder ein Chat-Assistent –, gibt es auf der Datenschutzseite stattdessen einen Weg per Kopieren und Einfügen: Der Editor gibt Ihnen einen Prompt, der bereits mit den Angaben Ihrer App ausgefüllt ist; Sie führen ihn aus, wo Sie möchten, und fügen die Antwort wieder ein. Den Prompt und warum er so formuliert ist, finden Sie in Ihre Datenschutzerklärung mit einem KI-Assistenten schreiben.
Wenn Sie keinen Agent haben, gibt es dasselbe als kurzes Formular. Der Weg über den Agent ist schneller, weil die Antworten schon in Ihrem Repository stehen – ein anderes Produkt ist er nicht.
Die maßgeblichen Quellen
- Provide information for Google Play’s Data safety section – Google Play Console-Hilfe, dazu, dass Sie SDK-Daten selbst deklarieren müssen
- App privacy details on the App Store – Apple
- Privacy and security in Firebase – ein Beispiel für die SDK-spezifische Offenlegung, die ein Agent liest