Does Sending User Prompts to an AI API Count as Data Collection on Google Play?

Yes—often it does. If an Android app transmits a user’s prompt, photo, audio, document, location or other covered data off the device so an AI service can process it, Google Play can treat that as data collection for the Data safety form.

The important 2026 change is that Google Play’s User Data policy now says this responsibility explicitly extends to third-party AI integrations, including products, services and code. It also says the rule applies whether the third party is embedded in the app or receives the data later through the developer’s own server.

That does not mean every AI API call is automatically “data sharing,” nor that every prompt requires a new consent popup. Google Play separates several questions: what data leaves the device, whether the AI provider is acting only as a service provider, whether the use is reasonably expected by the user, whether prominent disclosure and consent are required, and whether the app’s Data safety form and privacy policy accurately describe the flow.

Policy check: August 21, 2026. Google announced the AI clarification on July 15 and said developers would have at least 30 days to comply with the updated policies. Its current User Data policy now contains the third-party-AI language. Google’s public Policy Deadlines page does not list a separate AI-specific enforcement date, so this article does not invent one.

The shortest useful answer

Think about an AI feature as a data pipeline rather than a button labelled “AI.”

Android app
   ↓
user data leaves device
   ↓
(optional) your backend
   ↓
AI provider
   ↓
response returns to app

Google Play’s current rules make three points especially important:

1. Off-device transfer can be collection. The Data safety guidance defines “collect” as transmitting covered user data from the app off the user’s device, including transfers made by libraries or SDKs.
2. A server hop does not erase responsibility. The User Data policy says third-party requirements apply regardless of whether data reaches the third party after first being sent to a server or through third-party code embedded directly in the app.
3. AI is not a special exemption. Google now explicitly says the same requirements apply to third-party AI integrations, including limited use, disclosure and consent.

The practical result is that a team should audit the data flow, not just ask whether it uses an AI SDK.

Collection and sharing are not the same thing

This is the distinction most likely to cause a bad Data safety declaration.

Google’s Data safety guidance says data is generally collected when it is transmitted off the device. But some transfers do not have to be declared as sharing.

One important exception is a service provider: an entity processing user data on the developer’s behalf and based on the developer’s instructions. Google gives cloud and analytics providers acting solely on the developer’s behalf as examples of the concept.

That means an AI provider can create a situation like this:

The provider’s brand name does not answer those questions. The contract, product tier, configuration, retention settings and actual data flow do.

A provider that stores inputs, uses them to improve a general service, combines them with data from other customers or otherwise acts beyond the developer’s instructions may not fit the same Data safety treatment as a provider acting strictly as a processor on the app’s behalf.

So “we use an AI API” is not enough information to complete the form.

Six common AI flows and what to check

The table below is a practical classification aid, not a substitute for Google’s policy text or legal advice.

The biggest risk is usually not a visible “Ask AI” box where a user deliberately submits content. It is secondary enrichment: attaching location, contacts, account history, support messages, device data or other context to an AI request without making that flow clear.

When does Google require prominent disclosure and consent?

Google Play does not say that every off-device transfer requires the same custom consent screen.

Its stricter Prominent Disclosure and Consent requirement applies when access, collection, use or sharing of personal and sensitive user data may fall outside the user’s reasonable expectation for the product or feature.

When that rule applies, Google says the disclosure must:

• appear inside the app, not only on a website or store listing;
• appear during normal usage rather than being buried in settings;
• describe the data being accessed or collected;
• explain how it will be used and/or shared;
• appear before the consent or runtime-permission request; and
• be followed by a clear affirmative action such as tapping to accept.

Google specifically rejects passive consent patterns such as treating navigation away from a screen as agreement or using an auto-disappearing message as consent.

A useful design test is:

Would a reasonable user understand, at the moment they use this feature, that this specific information is leaving the device and being processed in this way?

If the answer is “probably not,” the team should not rely on a privacy-policy paragraph buried elsewhere.

A visible AI feature is easier than a hidden AI feature

Consider two designs.

Design A: explicit AI action

A screen says “Summarise this document with AI.” The user selects a file and taps Summarise.

The user-initiated action makes the basic transfer easier to understand. The app still needs accurate privacy and Data safety declarations, and sensitive data may trigger additional requirements, but the product intent is clear.

Design B: silent AI enrichment

The same document is automatically sent to an external model in the background to classify the user, generate recommendations or enrich an advertising profile.

Now the AI processing is much less likely to be within the user’s reasonable expectation. The purpose also matters: Google limits personal and sensitive data use to app/service functionality and policy-conforming purposes reasonably expected by the user.

The lesson is not “add a consent popup to everything.” It is design the feature so the data flow matches the user’s understanding, then disclose it accurately.

Server-side AI is not a privacy-policy loophole

A common architecture is:

app → developer API → AI provider

instead of:

app → AI provider SDK

There are good security reasons to keep provider credentials on a backend. But moving the API key server-side does not make the third-party data flow disappear for Google Play policy purposes.

Google’s User Data policy explicitly says the third-party requirement applies whether data is transferred after first being sent to a server or through third-party code embedded in the app.

So a backend proxy can improve credential security, rate limiting and data minimisation, but it does not remove the need to understand and disclose what happens after the proxy receives the request.

Data safety: the five questions to answer for every AI feature

Before updating Play Console, create one row per AI feature and answer these questions.

1. What exact data leaves the device?

Do not write “prompt.” Break it down into real categories:

• text entered by the user;
• name, email or account ID;
• photos or videos;
• audio or voice recordings;
• files and documents;
• approximate or precise location;
• app activity or diagnostics;
• device or other identifiers.

A free-form prompt can contain several data types at once, so the product should minimise what it sends rather than assuming all text is harmless.

2. Is the transfer required or optional?

Google’s Data safety form distinguishes required and optional collection. If the user can use the app without providing the data, or can opt into the feature, that can affect the declaration.

Be careful with “optional AI.” If the app silently sends data to the model regardless of whether the AI feature is used, the implementation does not match the label.

3. Is the AI company a service provider for this flow?

Review the actual terms and settings rather than guessing.

Questions worth documenting include:

• Is data processed only on the developer’s instructions?
• How long are prompts, files and outputs retained?
• Can retention be reduced or disabled?
• Is customer data used to train or improve models outside the customer’s service?
• Are subprocessors involved?
• Can the developer honour deletion requests?
• Is there a separate consumer mode with different terms from the API/business product?

If the answer changes when a configuration flag changes, that flag is part of the privacy architecture.

4. Is the use reasonably expected by the user?

An explicit “Generate with AI” action is different from silently sending background location or private messages for model analysis.

If the use falls outside reasonable expectation and involves personal or sensitive data, review Google Play’s prominent-disclosure and affirmative-consent rules before collection begins.

5. Do all four surfaces tell the same story?

Check:

• the actual network/data flow;
• the Data safety form;
• the app’s privacy policy;
• any required in-app disclosure and consent.

Google says the Data safety form is the developer’s responsibility and must stay accurate. It also says the privacy policy must comprehensively describe data access, collection, use and sharing, including the parties with which personal and sensitive data is shared.

A compliant-looking privacy page cannot rescue a Data safety form that contradicts the app’s behaviour.

Data safety is not consent

Google’s Data safety section appears on the Play Store listing. It helps users understand an app before installation, but Google explicitly says it is not a new in-app consent mechanism.

That creates three separate layers:

Do not collapse all three into one checkbox.

What about ephemeral AI processing?

Google’s Data safety guidance has an exception for ephemeral processing in some circumstances. Data used only transiently to fulfil a request and not retained for another purpose may be treated differently in the Data safety form.

But “our API request is fast” is not the same thing as ephemeral processing.

The team needs to check the entire path:

• Does the app log the request?
• Does the backend retain it?
• Does the AI provider retain it?
• Is it used for abuse monitoring?
• Is it used for analytics?
• Is it used for model improvement?
• Is the output or prompt attached to the user account afterward?

If any participant keeps or reuses the data beyond the transient request, the ephemeral exception may not describe the real flow.

AI content policy is a separate question

Google Play also has an AI-Generated Content policy. It requires covered generative-AI apps to prevent prohibited content and provide in-app reporting or flagging for offensive AI output.

That policy is about what an app generates.

The User Data rule discussed here is about what the app collects, uses and sends.

An app can be outside the current scope of Google’s AI-Generated Content policy—for example, a limited productivity feature—while still having User Data obligations because it sends personal or sensitive information to a third-party AI service.

The safest audit therefore has two columns:

AI output risk   → AI-Generated Content policy
AI input/data flow → User Data + Data safety rules

Passing one does not automatically pass the other.

A 30-minute AI data-flow audit

A small team can run this before the next Play submission.

Minutes 0–10: draw the real flow

For every AI feature, write:

source → app → backend → provider → storage/logs → deletion path

Include analytics, crash logs, request tracing and moderation systems. They are easy to forget because they are not visible in the UI.

Minutes 10–15: classify provider behaviour

For each provider and environment, record whether it is acting on the developer’s instructions, what it retains and whether it can use data for separate purposes.

Do this for the actual product being used, not a generic marketing page.

Minutes 15–20: compare with Play Console

Open the app’s Data safety form and compare every declared type against the flow diagram. Remember that Google says collection through third-party libraries or SDKs is still the app developer’s responsibility.

Minutes 20–25: compare user-facing text

Check the privacy policy and any in-app disclosure. A sentence such as “we use AI” is usually too vague to explain what data is sent, why, and to whom.

Minutes 25–30: test deletion and minimisation

Ask two questions:

1. Can the feature work with less data?
2. If the user deletes the account or relevant data, can the deletion propagate through the systems that retained it?

Google’s User Data policy requires account-deletion support for apps that allow account creation and requires associated user data to be deleted, subject to disclosed legitimate retention needs.

One extra risk with third-party SDKs

Google says that if an app integrates third-party code designed to collect personal and sensitive user data by default, Google Play may ask the developer for evidence that the app meets the prominent-disclosure and consent rules. The policy gives developers two weeks after such a request, unless Google specifies a longer period, to provide sufficient evidence.

That is a good reason to keep compliance artefacts before a review arrives:

• screenshots of the disclosure and consent flow;
• the data-flow diagram;
• provider configuration and retention settings;
• Data safety form export;
• the current privacy policy;
• documentation showing which SDK versions are in production.

The best time to discover what an SDK sends is not after an enforcement notice.

What is confirmed—and what is still contextual

Confirmed in Google’s current policy

As checked August 21, 2026:

• third-party AI integrations are explicitly covered by Google Play’s User Data requirements;
• developers remain responsible for the third party’s policy compliance;
• that responsibility applies to direct SDK integrations and data passed through the developer’s server;
• transmitting covered data off-device generally counts as collection for Data safety purposes;
• service-provider transfers can qualify for an exception from being declared as sharing;
• prominent in-app disclosure and affirmative consent are required when sensitive-data handling may fall outside reasonable user expectation;
• Data safety declarations must remain accurate and consistent with the app’s real practices and privacy policy.

Contextual rather than automatic

These questions depend on the exact implementation:

• whether a particular AI provider qualifies as a service provider for a specific configuration;
• whether a specific prompt contains a Play Data safety data type;
• whether processing qualifies as ephemeral;
• whether a particular data use is reasonably expected by the user;
• whether additional privacy-law consent is required in a particular jurisdiction.

Those are reasons to document the flow, not reasons to guess.

What to watch next

The useful next changes are likely to be implementation guidance rather than another headline AI policy.

Watch for:

1. Google Play examples specific to AI providers. The current policy states the responsibility clearly but does not publish a provider-by-provider classification.
2. Provider data-control changes. A new retention or model-improvement default can change the app’s Data safety analysis even when no Android code changes.
3. Play Console enforcement messages. Google can flag discrepancies between declared practices and observed app behaviour or known SDK issues.
4. The August 31 target-API deadline. Teams already preparing a Play release should include the AI data-flow audit in the same release-readiness check rather than treating privacy as a separate last-minute form.

Conclusion

Google Play’s 2026 AI clarification is less about creating a new AI rule than removing an old ambiguity.

If an app sends user data to an AI service, the developer cannot treat the provider as somebody else’s privacy problem. The same User Data rules apply whether the model is called through an SDK, directly over the network or indirectly through the developer’s backend.

The practical sequence is simple:

1. map exactly what leaves the device;
2. classify the data rather than calling everything a “prompt”;
3. determine the provider’s role from its real terms and configuration;
4. add prominent disclosure and consent where Google’s reasonable-expectation rule requires it;
5. make the Data safety form, privacy policy and app behaviour agree.

That audit is much more reliable than a generic “we use AI” sentence—and much easier to fix before the next Play review than after it.

Sources

Checked August 21, 2026:

• Google Play — July 15, 2026 policy announcement
• Google Play — User Data policy
• Google Play — Provide information for the Data safety section
• Google Play — Using SDKs safely and securely
• Google Play — AI-Generated Content policy