AI assistants are moving closer to the operating system.
That changes the privacy decision for app teams.
It is no longer only about what your app stores, what your backend processes, or what your own AI feature can access. The next question is what happens when another AI assistant can search, retrieve, interpret, or act on data your app makes available on the device.
That is the useful signal behind the European Commission’s July 2026 DMA guidance to Google.
The Commission’s Android AI measures require Google to provide effective interoperability for certain Android features relevant to AI services. The measures cover areas such as contextual invocation, centralised access to on-device app data, context-aware intelligence, structured app actions, on-device model access, and background execution.
In simple terms, rival AI assistants may need deeper Android access to compete fairly.
For software teams, the practical question is this:
If AI assistants can reach deeper into the device, what should your app intentionally share, protect, and explain to users?
What changed
On July 16, 2026, the European Commission published guidance under the Digital Markets Act relating to Google Android AI interoperability and Google Search data sharing.
The Android decision focuses on how third-party AI services should receive effective interoperability with Android features that Google’s own AI services can use.
The Commission’s published measures include several categories:
- invocation features, such as contextual launch and hotword-related access,
- centralised access to apps’ data stored on-device,
- context-aware intelligence,
- structured on-device integrations,
- system-level on-device models,
- hardware resources for on-device model operation,
- and background execution.
One important section discusses centralised access to app data stored on-device. The measure refers to access to data that apps choose to share in a centralised manner, allowing cross-app search and retrieval.
That phrase matters:
apps choose to share.
This is where product teams enter the governance conversation.
Why this matters for app and SaaS teams
Many software products already live across mobile apps, web dashboards, backend APIs, notifications, support workflows, and AI features.
If AI assistants become more integrated into the operating system, users may expect those assistants to help them find information, summarize activity, trigger actions, or move between apps.
That can be useful.
But it also raises questions:
- Which app data should be searchable by an assistant?
- Which data should stay inside the app?
- Which actions can an assistant trigger?
- What should require the app UI?
- How should users know what is being shared?
- What happens when multiple assistants request similar access?
- Can users change the sharing level later?
These are not only technical permissions.
They are product governance decisions.
The data-access problem
A product may hold different kinds of data:
- public content,
- user-created notes,
- private messages,
- customer records,
- financial information,
- health information,
- internal business data,
- notifications,
- location signals,
- saved preferences,
- task history,
- and support interactions.
Not all data belongs in the same sharing model.
Some information may be safe and useful for AI-assisted search.
Some may be useful only with explicit user action.
Some should never leave the product boundary except through carefully designed flows.
The mistake is treating app data as one category.
It is not.
The 7-check Android AI interoperability review
1. Data category
Start by classifying what the app stores on-device.
Separate:
- public content,
- user-owned content,
- account data,
- sensitive records,
- transactional data,
- notifications,
- settings,
- and data that belongs to a business or workspace.
The goal is not to slow the product team.
The goal is to avoid exposing different data types through one broad integration path.
Review question:
What kind of data could an assistant discover or retrieve?
2. User intent
AI assistant access should follow user intent, not only technical availability.
For example, a user may want an assistant to find a document title, but not read all document contents. A user may want a calendar summary, but not expose private notes. A user may want an action shortcut, but not allow background changes.
Teams should decide which access requires:
- user opt-in,
- in-the-moment confirmation,
- app-level permission,
- workspace admin approval,
- or no sharing at all.
Review question:
Did the user clearly choose this data-sharing behavior?
3. Action boundary
Search and action are different.
Letting an assistant find information is not the same as letting it change something.
A product should distinguish between:
- search,
- retrieval,
- summarization,
- drafting,
- navigation,
- data update,
- transaction,
- deletion,
- submission,
- or external send.
An assistant that can read a task list should not automatically be able to close tasks, update account records, send messages, or trigger billing changes.
Review question:
Can the assistant only read, or can it also act?
4. Sensitive workflow protection
Certain workflows should require stronger control.
Examples include:
- billing,
- account deletion,
- permission changes,
- data export,
- customer record updates,
- legal or compliance content,
- medical or financial information,
- identity verification,
- and admin actions.
Even if an assistant can help users reach those areas faster, the final step may still need app-owned confirmation.
Review question:
Which workflows should stay inside the app experience?
5. Visibility to users
Users should understand when external AI services can use app data or trigger app actions.
This does not mean burying people in permission text.
It means making the permission meaningful:
- what is shared,
- why it is shared,
- which assistant can use it,
- what actions are allowed,
- and how to turn it off.
The product should not make users guess what the assistant can see.
Review question:
Can a normal user understand what the assistant is allowed to do?
6. Revocation and change
Consent and permissions should not be permanent by default.
Users may change their mind. A company may switch assistant providers. A workspace admin may restrict access. A regulation may require tighter control. A feature may change.
Teams should design revocation clearly:
- user-level off switch,
- workspace-level controls,
- admin policy,
- audit trail,
- permission expiry,
- and fallback behavior when access is removed.
Review question:
Can access be changed or removed without breaking the product?
7. Audit and support
When AI assistants interact with app data, support teams may need to answer new questions.
A user may ask:
- Why did the assistant show this?
- What data was used?
- Which app allowed it?
- Did an action happen?
- Can I reverse it?
- How do I stop this next time?
Teams should plan basic audit trails and support language before launch.
Review question:
Can the team explain what happened if a user questions an assistant action?
A simple implementation model
A practical model is to separate app data and actions into four tiers.
Tier 1: Safe discovery
Data that can be found or surfaced without exposing sensitive content.
Examples:
- public help pages,
- feature names,
- document titles,
- app shortcuts,
- non-sensitive metadata.
Tier 2: User-approved retrieval
Data that may be retrieved only when the user clearly asks.
Examples:
- personal notes,
- task lists,
- saved items,
- account-specific summaries.
Tier 3: App-confirmed actions
Actions where the assistant can prepare the step, but the app should confirm before completion.
Examples:
- updating a record,
- sending a message,
- exporting a file,
- changing a setting.
Tier 4: Protected workflows
Areas that should stay behind app-owned controls.
Examples:
- billing changes,
- permission changes,
- account deletion,
- sensitive data exports,
- regulated data.
This model keeps the product useful without treating assistant access as all-or-nothing.
Founder takeaway
AI interoperability may create better user experiences.
But deeper assistant access also makes data governance more important.
For founders, the decision is not only whether to support AI assistants.
It is whether the product can clearly answer:
- what data can be discovered,
- what data can be retrieved,
- what actions can be triggered,
- what needs confirmation,
- what remains protected,
- and how users can change their choice.
The useful product question is not:
Can an assistant use our app data?
It is:
Should it, under which conditions, and with what user control?
That is where AI interoperability becomes a product governance decision.
Top comments (0)