Your Model Vendor Became a Third Party You Declare

For most of the last two years, the decision to call a hosted model from inside your app was an engineering choice. Pick a provider, add the SDK, ship the feature. The store review was about crashes and screenshots.

That is no longer where it sits. Both major app stores now treat a third-party AI integration, any arrangement where your app sends user data to a model your organization does not run, as a data-sharing relationship you have to declare by name.

Apple wrote it into the review guidelines on November 13, 2025, in section 5.1.2(i). The clause reads:

You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so.

Google Play arrived at the same place from the other direction. Its July 15, 2026 policy announcement clarified that the User Data policy requirements apply to third-party AI integrations, and that developers remain responsible for compliance, including limited use, disclosure and consent.

Neither of these is a new law. Both are conditions of staying in the store.

The Two Stores Want Two Different Artifacts

This is the part teams miss, because at a glance the two requirements look like the same requirement. They are not, and satisfying one does nothing for the other.

Apple wants a moment inside the app. The guideline asks for explicit permission before the data is shared, which means an in-app disclosure and a consent action the user actually takes. A line buried in a linked privacy policy is not the permission the clause describes.

Google wants a declaration in your store metadata. Its User Data policy requires two separate things: a privacy policy disclosing any parties with which personal or sensitive user data is shared, and a clear and accurate Data safety section, the structured form in Play Console detailing collection, use and sharing. The policy adds that the section must be consistent with the privacy policy, so a model provider named in one and missing from the other is itself the problem.

So a team that builds a careful consent sheet and never updates the Data safety form has an Apple-compliant app with a Google problem. A team that fills in the form and lets the privacy policy carry the disclosure has the reverse. One artifact is a product change. The other is a submission change. They are owned by different people on most teams, which is exactly why one of them gets missed.

Where This Actually Bites

The obvious case, a chat assistant on your home screen, is the case teams already handle. The failures come from the integrations nobody filed under AI.

  • A feature that quietly acquired a provider. Smart reply in a support inbox, a summarizer in a document view, autocomplete in a search field. Each one may route user text to an outside model, and none of them looked like an AI launch when it shipped.
  • An SDK that calls a model on your behalf. Your app added an analytics or support vendor. That vendor added AI. Your disclosure obligation moved without a line of your own code changing.
  • A provider swap. These are not rare, because providers retire model versions on their own schedule. The migration ticket says change the endpoint. It does not say update the Data safety form, and the form now names a company you no longer send data to.
  • Consent placed after the first call. A permission prompt that appears the second time a user opens the feature is late. The clause is about permission before the sharing, which makes it an onboarding design constraint rather than a legal copy task.

There is a timing reason to look now rather than next quarter. The same Google Play announcement carries the annual target API level deadline of August 31, 2026, the yearly requirement to build against a recent Android version, so most teams are shipping a submission around it regardless. That build is the one that should carry the disclosures.

Four Questions Before Your Next Submission

None of these require a lawyer to answer. They require somebody to actually go and look.

Four labelled checks in a row: provider inventory, consent placement, metadata accuracy, and change ownership, with the last one highlighted.
Four Checks Before the Next Submission

1. Which providers receive user data, by name?

Not which providers you have a contract with. Which ones receive user data in production, including the ones reached through a vendor SDK rather than your own client. If the list takes more than a day to produce, that is the finding.

2. Is there a consent action before the first transmission?

In the app, in front of the user, ahead of the first call that carries their data. Verify it against the build rather than the design file, because a consent screen that ships behind a feature flag is not shipped.

3. Does the Data safety section match what the app does today?

Open the current Play Console entry next to the current provider list and compare them line by line. This form is filled in once at launch and then inherited by every release after it, which is how it drifts.

4. Who re-checks this when a provider changes?

The other three questions are a point-in-time audit. This one decides whether you are back here in six months. Attach the check to the event that breaks it, a provider being added, swapped or removed, and give it a named owner.

Key Takeaways

  • Both stores now treat a third-party model provider as a data recipient your app has to disclose. Apple wrote it into guideline 5.1.2(i) in November 2025, and Google Play clarified the same obligation in July 2026.
  • The two requirements produce different artifacts. Apple wants in-app disclosure and explicit permission before sharing. Google wants the sharing declared in your privacy policy and your Data safety section.
  • Satisfying one does not satisfy the other, and they usually belong to different owners on the team.
  • The exposure is concentrated in features nobody labelled as AI: summarizers, smart replies, and vendor SDKs that added a model after you integrated them.
  • Consent has to precede the first transmission, which makes it an onboarding decision rather than a policy document edit.

Frequently Asked Questions

Does this apply if the model runs on our own servers?

Apple ties the obligation to sharing personal data with a third party. A model your organization hosts and controls is not a third party, so the disclosure question turns on who operates the system receiving the data, not on whether the feature is described as AI.

Is an updated privacy policy enough?

For Google it is part of the answer and not all of it, because the Data safety section is a separate structured declaration. For Apple the guideline asks for explicit permission before sharing, which a policy document the user never opens does not provide.

What if the data we send is anonymized?

Then the question becomes whether it is genuinely outside the definition of personal data, which is a determination to make deliberately and write down, not one to assume because a user identifier was stripped. The same question governs anything your agent keeps. Free-text a user typed often carries identifying detail regardless of the fields around it.

Sources

  1. Apple, "App Review Guidelines," section 5.1.2(i), 2026. Link.
  2. Google Play, "Policy announcement: July 15, 2026," 2026. Link.
  3. Google Play, "User Data policy," 2026. Link.
  4. TechCrunch, "Apple's new App Review Guidelines clamp down on apps sharing personal data with third-party AI," 2025. Link.

Next Steps

Most teams can answer the provider question in an afternoon and find at least one integration they had not counted. Stable Solutions builds AI features with the provider inventory, the consent moment and the store declarations treated as part of the feature rather than as paperwork after it. Explore our App and Web Development services or contact our team to review what your current app is sending, and to whom.