Skip to main content

AI processing

Sending a user's messages, voice or profile to an AI provider is sharing personal data with a third party. It needs its own disclosure, its own consent, a contract with the provider, and copy that is true. Read this before you add any call to an LLM that carries user content.

How it works​

The sheet appears at the point of use, immediately before the first send. It is not a fourth toggle hidden on the first-run screen among analytics switches. A reviewer's test is simple: did the app ask before it sent anything?

How to build it​

1. List exactly what leaves​

Before writing copy, write the table. Anyone who changes it changes the copy and bumps the AI notice version.

SurfaceData sent to the provider
AI chatEach message, the thread history, context we add on the server
Voice onboardingLive microphone audio, and the answers the model collects
AI-generated text on requestThe user's request and chosen tags
Stored profile reused as contextProfile answers, only when added to a prompt

Keep out of the list: content generated in batch with no user data. Claiming it uses user data is inaccurate too.

Free-text chat often contains health, religion, sexuality or relationship details. That is GDPR Article 9 special category data, which needs explicit consent. Treat the sheet as an affirmative opt-in, never as a notice.

2. A separate purpose​

Add ai_processing to the consent registry, default denied, requires_explicit_optin = true, visible in Settings so the user can withdraw it. Give it its own notice version on its own surface. See The consent model.

Declining must not break the app. Only the AI surfaces are gated. Everything else works.

3. The sheet copy​

The sheet says, in plain words:

  • What is sent: your messages, your voice, your onboarding answers.
  • Who receives it: the provider by name, not "our AI partner".
  • Why: to generate the reply.
  • What they may do with it: only claims you have verified (see below).
  • A link to the versioned privacy policy, and where to change the choice later.
  • Two buttons: "Allow and continue" and "Not now".

Ship these strings bundled with the app. Do not let them be changed over the air.

4. Enforce on the server too​

The device gate is the first line. The server must also refuse AI operations when ai_processing is denied, including on websocket routes. That needs the user or device id in the token. Check this early: guest tokens often lack it.

5. The provider contract​

Before the first production call:

  • A data processing agreement (DPA) with the provider, covering your tier and region.
  • Verify the training position for the exact tier you use. Some providers do not train on paid API traffic but may use data from free or trial tiers. "The provider does not train on your data" may only be written after you have checked your account's terms.
  • Find the provider's retention period for prompts and outputs on that tier, including abuse monitoring logs. Put the same number in the policy.
  • Record the provider in the vendor register with trains_on_our_data and the transfer basis.
  • Send the minimum. Strip email, phone and account ids from prompts. Pass a pseudonymous id only if the provider needs one for abuse detection.

6. Store review​

Apple's App Review Guideline 5.1.2(i), as of October 2026, says apps must clearly disclose where personal data will be shared with third parties, "including with third-party AI", and get explicit permission first. Apple added the AI wording on 13 November 2025. Apple has said a privacy policy alone is not enough.

Also update the App Store privacy labels and the Google Play Data safety form to declare the AI processing. If one store says "shared" and the other does not, reviewers notice.

In the review notes, give exact steps to reach the sheet. Test the sheet on a tablet layout as well as a phone; reviewers often use iPads.

7. AI law​

The EU AI Act's transparency duties for systems that interact with people apply from August 2026. An EU "AI omnibus" regulation (Regulation (EU) 2026/1744) moved several high-risk dates later. If your feature is a chatbot, tell users they are talking to an AI. Ask the DPO whether anything else applies. Sources: Regulation (EU) 2026/1744 on EUR-Lex, Commission news, as of October 2026.

Rules​

Rule

Ask before the first send, at the point of use, naming the provider. Policy text alone does not count as permission, and a toggle buried among telemetry switches is weak evidence.

Rule

Never publish "the provider does not train on your data" or a retention figure until you have checked the terms of the exact tier and account you call. If you cannot verify it, say only "used to generate your reply".

Rule

Seed the ai_processing purpose on the server in every environment before the app that sends it. An unknown purpose is rejected and the user's "Allow" is lost.

Mistakes we made​

  • Store rejection for missing AI consent. The app sent typed text and live voice to an AI provider. The first-run consent screen never mentioned AI, and the only disclosure was one policy line that did not say what was sent. The app was rejected. The fix was a just-in-time sheet plus a dedicated policy section, live before resubmission.
  • The new purpose was discarded by the server. After the fix, the server had no row for ai_processing, so every grant failed validation. See The consent model.
  • The policy named the wrong provider path. The policy said one cloud AI platform; the code used a different API with different terms, plus moderation providers nobody listed. Build the provider list from the code.
  • An unverified "no training" claim. The reassuring line was drafted before anyone checked that the API keys were on a paid tier. It had to be held back until verified.
  • Erasure did not reach the AI service. The relay that told the AI service to delete a user's chat history was switched on in dev only. In production, deleted users' transcripts stayed. Test deletion end to end in production-like config.

Checklist​

  • Table of exactly what is sent, per surface, agreed with the DPO.
  • ai_processing purpose seeded on the server in all environments.
  • Just-in-time sheet before the first send; names the provider; "Not now" keeps the app usable.
  • Sheet strings bundled, not editable over the air; own notice version.
  • Server refuses AI calls when denied, including websockets and guests.
  • DPA signed; training position and retention verified for our tier.
  • Prompts carry no direct identifiers.
  • Privacy policy AI section live before the release.
  • Apple privacy labels and Play Data safety updated.
  • Erasure reaches the AI service's own stores.