Die Datenschutzerklärung Ihrer App mit einem KI-Assistenten schreiben – ein Prompt, der funktioniert

Ein KI-Assistent schreibt eine Datenschutzerklärung in zehn Sekunden. Das Problem ist, woraus er sie schreibt. Fragt man ihn „Schreib eine Datenschutzerklärung für meine Fitness-App“, hat er nichts als das Wort „Fitness“, also produziert er den Durchschnitt aller Datenschutzerklärungen, die er je gelesen hat: Klauseln über Cookies, die Ihre App nicht setzt, Werbekennungen für eine App ohne Werbung, eine Aufbewahrungsdauer von „so lange wie nötig“ und keines der SDKs, die Sie tatsächlich ausliefern. Es liest sich gut. Es ist aber auch der Teil, den ein Store-Prüfer mit Ihrem Data-safety-Formular und Ihren App-Privacy-Antworten vergleicht, und genau bei diesem Vergleich fällt es durch.

Warum der Ein-Zeilen-Prompt scheitert

• Er erfindet. Ein Modell, das einen Abschnitt füllen soll, füllt ihn. Eine Aufbewahrungsdauer, eine Rechtsgrundlage, eine Firmenadresse – jede plausibel, jede eine Aussage über Ihr Geschäft, die Sie nicht gemacht haben.
• Er ist allgemein, wo er konkret sein muss. Der wichtigste Abschnitt ist die Liste der Drittanbieterdienste, und ein Modell, das Ihre Abhängigkeitsdatei nicht gesehen hat, kann sie nicht nennen.
• Er deklariert zu viel. Daten aufzuführen, die Sie nicht erheben, ist nicht „sicher“. Es ist eine Abweichung von Ihren eigenen Store-Angaben – dasselbe Problem in die andere Richtung.
• Er formatiert für das Chatfenster. Tabellen, Fußnoten und Inline-HTML sehen in der Antwort gut aus und kommen kaputt an, wo immer Sie sie einfügen.

Was ein Prompt ihn tun lassen muss

1. Zuerst Belege lesen. Ein Coding-Agent, der in Ihrem Repository geöffnet ist – Claude Code, Cursor, Codex und ähnliche –, kann build.gradle, Podfile.lock, Info.plist und das Manifest lesen und jedes SDK und jede Berechtigung mit der Datei auflisten, aus der sie stammen. Diese Liste ist die Substanz der Erklärung. Einem Chat-Assistenten ohne Dateizugriff sollte man sagen, dass er Sie bitten soll, diese Dateien einzufügen.
2. Von allem anderen die Finger lassen. Build- und Manifest-Dateien reichen. Es gibt keinen Grund, .env-Dateien, Keystores oder Quellcode zu öffnen, und ein Prompt, der das sagt, ist eine Sorge weniger.
3. Nur fragen, was sich nicht lesen lässt. Wie lange Sie Daten aufbewahren, ob es ein Backend gibt, ob sich die App an Kinder richtet, ob Sie Daten mit einem Partner teilen, der im Build keine Spur hinterlässt. Sonst muss nichts gefragt werden.
4. Raten verweigern. Wo Sie es nicht wissen, schreibt er [confirm: …] statt eines Satzes. Eine sichtbare Lücke lässt sich beheben; eine erfundene Klausel ist eine veröffentlichte Aussage.
5. Für den Ort schreiben, an dem es veröffentlicht wird. Einfaches Markdown, Links nur dort, wo sie nützlich sind – die eigenen Datenschutzseiten der Anbieter, Ihre Support-Adresse – und der Hinweis, dass der Text keine Rechtsberatung ist.

Der Prompt

Kopieren Sie ihn vollständig. Ersetzen Sie die Fakten in eckigen Klammern oben oder lassen Sie sie stehen und den Assistenten fragen.

You are helping me write the privacy policy for my mobile app. It will be published as a web page on AppFoyer and its URL goes into the "Privacy policy" field of Google Play and App Store Connect, where reviewers compare it with what the app actually does. Accuracy matters more than length.

## About the app

- App name: [app name]
- Developer / company: [developer or company name]
- Support email: [support email]
- Platforms: [Android, iOS or both]
- Store listings: [store listing URLs, or "not listed yet"]
- Where this policy will be published: [your AppFoyer site URL]/privacy
- What the app collects, as I declared it: [what the app collects — e.g. account info, analytics, ads, crash reports, location, purchases, or nothing]
- Account deletion page: [your AppFoyer site URL]/account-deletion (only if the app has user accounts)
- Country whose law applies: [country, if you have one]

## Step 1 — find the facts

If you can read this app's source code, read only its build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Info.plist`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file.

From them, list:

- every third-party SDK or service that collects or receives user data (analytics, ads, crash reporting, sign-in, payments, push notifications, backend, AI APIs) and what it receives;
- every permission the app requests and the feature that uses it;
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like).

Show me that list with the file each fact came from, point out anything that contradicts what I declared above, and ask me to confirm it.

If you cannot read the code, ask me to paste the dependency files (for example `app/build.gradle` and `Podfile`) or to list the SDKs and permissions myself.

## Step 2 — ask only what you cannot know

Then ask me, in one short numbered list, and wait for my answers:

1. How long each kind of data is kept, and whether there is a backend (where it runs, what it stores).
2. Whether the app is directed at children under 13.
3. Whether any data is shared with or sold to anyone beyond the services above.
4. Whether the app takes any payments, if the files did not settle it.
5. Anything else you could not determine.

Never guess. Where I do not know an answer, write `[confirm: …]` in the text instead of inventing one.

## Step 3 — write the policy

Sections, in this order, leaving out any that do not apply: Data we collect · How we use it · Third-party services · Purchases and subscriptions · Permissions · Data retention and deletion · Children · Your choices and rights · Changes to this policy · Contact.

- Plain language, short sentences. Describe what this app does; no clauses about things it does not do.
- Under Third-party services, name each provider, say what it receives and why, and link its own privacy policy page.
- Do not invent retention periods, legal bases, company addresses or a data protection officer — use `[confirm: …]`.
- Start with `# Privacy Policy`, then the line `_Last updated: [today's date]_`.
- Write these placeholders exactly as shown, never the values — they are filled in from my settings when the page is published: `{{app_name}}`, `{{developer_name}}`, `{{support_email}}`, `{{public_url}}`.
- In the Contact section, write the address as `[{{support_email}}](mailto:{{support_email}})`.
- If the app has user accounts, link account deletion as `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)` in the retention and deletion section.
- Mandatory if the app is on iOS and has any in-app purchase or subscription — declared above, found in the build files or confirmed by me: in the Purchases and subscriptions section, include this sentence unchanged: For the iOS version, Apple's standard [Licensed Application End User License Agreement](https://www.apple.com/legal/internet-services/itunes/dev/stdeula/) applies to your use of the App. Never leave it out when the app takes payments.
- End with this paragraph, unchanged:

  _This page was generated from a template provided by the hosting platform and completed by the app developer. It is not legal advice. The developer named above is solely responsible for its accuracy and for complying with the laws that apply to them._

## Format — this is pasted into a Markdown editor

- Reply with the finished policy only, as Markdown inside one ```markdown code block, with nothing before or after it.
- CommonMark only: headings, paragraphs, lists, bold, italics and links. No tables, no HTML, no images, no footnotes.
- Links only to the providers' own privacy policy pages, to `{{public_url}}`, to Apple's EULA as above and to the support email. Any other link is shown as plain text on the published page, so leave it out. No link shorteners, no download links.

Er ist für Seiten geschrieben, die auf AppFoyer veröffentlicht werden – deshalb verlangt er Platzhalter im Stil von {{app_name}} und endet mit unserem Hinweis. Wenn Sie woanders veröffentlichen, löschen Sie in „Step 3“ die Zeilen zu den Platzhaltern, zum Löschungslink und zum Schlussabsatz und lassen Sie stattdessen nach den Werten fragen.

Bevor Sie veröffentlichen, was er geschrieben hat

Der Assistent hat den Entwurf geschrieben; veröffentlichen tun Sie ihn. Prüfen Sie in dieser Reihenfolge:

• Jedes SDK aus Ihrer Abhängigkeitsdatei kommt in der Erklärung vor, und nichts kommt vor, was dort nicht steht. Das ist der mechanische Test, und im Grunde der, den Prüfer durchführen.
• Jedes [confirm: …] ist ersetzt durch eine echte Antwort, oder der Satz ist entfernt.
• Der Drittanbieter-Abschnitt stimmt mit Ihrem Data-safety-Formular und Ihren App-Privacy-Antworten überein. Wenn sie sich widersprechen, ist eines davon falsch – korrigieren Sie es, egal welches.
• Wenn die App Zahlungen annimmt, ist der Link zu Apples EULA vorhanden. Eine iOS-App mit In-App-Käufen oder Abos verlinkt in ihrer Datenschutzerklärung Apples Standard-Licensed Application End User License Agreement; der Prompt verlangt das, also prüfen Sie, ob es erhalten geblieben ist.
• Die Aufbewahrungsfristen sind Ihre. Nur Sie wissen, was Ihr Backend speichert und wie lange.
• Alles Ungewöhnliche geht an einen Anwalt. Gesundheitsdaten, Finanzen, Kinder oder Daten, die mit einem Partner geteilt werden – ein Prompt ändert nichts daran, was eine Vorlage nicht abdecken kann.

Was AppFoyer hier tut

Der Editor für die Datenschutzseite im Dashboard hat ein Panel Write it with your own AI (Mit Ihrer eigenen KI schreiben): derselbe Prompt, bereits ausgefüllt mit dem Namen Ihrer App, dem Entwickler, der Support-E-Mail, den Plattformen, den Store-Links und den Daten, die Sie angegeben haben. Kopieren Sie ihn, führen Sie ihn in dem Assistenten aus, den Sie nutzen, und fügen Sie die Antwort wieder in das Panel ein – das Markdown wird aus seinem Codeblock genommen und in den Editor gesetzt, wo die Vorschau genau zeigt, was veröffentlicht wird. Nichts wird öffentlich, bevor Sie auf „Veröffentlichen“ klicken, und der Text durchläuft dieselben automatischen Prüfungen wie jede andere Bearbeitung.

Die Seite mit den Nutzungsbedingungen hat dasselbe Panel mit einem eigenen Prompt – abgedruckt in Braucht Ihre App Nutzungsbedingungen?. Wenn Sie Claude Code nutzen, erledigt das AppFoyer-Plugin dieselbe Aufgabe für alle fünf Seiten ohne Kopieren und Einfügen, und auch es kann nicht veröffentlichen. Keiner der beiden Wege ist Rechtsberatung, und jede Seite sagt das.

Die maßgeblichen Quellen

• Privacy policy requirements – Google Play-Hilfe
• 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