The DMA Just Made Assistant Distribution an Integration Problem
The EU's binding Google decisions turn AI assistant distribution from a gatekeeper fight into an engineering problem. What teams should build now.
For roughly a decade, the strategy conversation about consumer AI assistants ended in the same place: it does not matter how good your assistant is if the phone will not let the user summon it. The home button belonged to someone else. So did the wake word. You shipped an app, users tapped an icon, and you competed against something that answered before the screen was unlocked.
On 16 July 2026 the European Commission adopted two binding specification decisions that change that for the European Economic Area. Google must open a defined set of Android capabilities to competing AI services, and share anonymised Google Search data with eligible search providers — including AI chatbots offering search functionality. The Commission’s summary calls it guidance. In practice the regulator has written part of Google’s roadmap.
The interesting question is not whether this is good for competition, but what lands on your sprint board. My read: the distribution barrier genuinely falls, the data remedy is thinner than the headlines suggest, and the real cost is compliance engineering nobody budgeted for.
What the Commission actually ordered#
Two cases, two DMA articles. Interoperability sits under Article 6(7) (DMA.100220); search data sharing under Article 6(11) (DMA.100209). Both were adopted through the Article 8(2) specification mechanism after proceedings opened on 27 January 2026.
The interoperability decision names eleven Android features in four categories, per the Commission’s developer portal:
- Invocation — long-press of the home button or navigation handle, and always-on hotword detection.
- Context — centralised access to app data stored on-device, context-aware intelligence, and ambient data.
- Actions — structured on-device integration, screen automation, and system integration.
- Resources — system-level on-device models, on-device model implementation, and background execution.
Most are due with the next major Android release and by 1 August 2027 at the latest. Concurrent hotword detection — several assistants listening for their own wake words at once — slips to the following release and 1 August 2028. Five of the eleven, those touching on-device data and agentic screen control, sit behind a certification scheme Google must build: draft eligibility terms by 1 February 2027, final terms by 1 May 2027, applications assessed inside four weeks.
That sequence is the actual deliverable. The regulator did not just say “open up” — it specified feature boundaries, certification gates, publication dates, and assessment SLAs. A procurement schedule dressed as an antitrust remedy.
Distribution stops being a gatekeeper problem and becomes an integration problem#
Until now, assistant distribution was a negotiation you could not enter. One counterparty, also your competitor, and the answer was no. Teams built the best standalone app they could and accepted the ceiling.
From 2027 in the EEA, the door has a published lock and a published key-cutting process. That is not the same as an open door. The constraint moves from “we are not allowed” to “we have not built it, certified it, and passed the audit” — solvable with engineering budget, which is why it is now your problem and not your policy team’s. And once everyone can be invoked by hotword, invocation is table stakes and quality of action is the differentiator.
What “opening Android” implies on an engineering roadmap#
Strip away the regulatory language and the eleven features are integration surfaces with very different cost profiles.
Invocation is cheap and mostly product work. Being reachable from a long-press or a hotword is a manifest entry, a default-handler flow, and an onboarding path that survives the user changing their mind. The hard part is not technical: concurrent hotword detection arrives only at the later deadline, so until then the wake word stays winner-take-all per device.
Context access is where your privacy posture becomes code. Centralised access to on-device app data, ambient signals, and screen contents make an assistant feel useful and make a data protection officer reach for a form. They sit behind the certification programme for a reason: if you want them, you will be answering questions about retention, minimisation, and purpose limitation long before you write a line of integration code.
Actions are where the engineering gets genuinely hard. Screen automation and structured integration mean your model is driving other people’s applications. Non-determinism that is charming in a chat window is a defect when it taps a payment button. You need typed intents, a permission model per action class, idempotency on anything that mutates state, and a rollback story. Same discipline that makes Operational Automation work in a back office: never let a probabilistic system take a side effect without a deterministic gate in front of it.
Resources decide your latency budget. System-level on-device models and background execution separate an assistant that answers in a few hundred milliseconds from one that round-trips to a datacentre while the user watches a spinner. The honest architecture is hybrid: a small on-device model for intent classification, wake-word confirmation, and short local answers; a cloud model for anything needing reasoning or fresh retrieval. Design that handoff explicitly and measure perceived latency, not model latency. Users do not experience tokens per second. They experience the gap between speaking and something happening.
What the shared search data is — and what it is not#
Temper expectations here. The Commission’s data access page describes the dataset as anonymised ranking, query, click and view data generated across free and paid search — queries, metadata such as language and device type, viewed URLs, interactions with results, and result positioning.
Then read the exclusions, where the value actually gets set. No account information. No search histories. No precise timestamps. Very long queries, queries containing rare terms, and paid result URLs are suppressed. K-anonymity puts every user in a group of at least a thousand, most in groups an order of magnitude bigger. Contractually, use is restricted to improving search, dataset linking is prohibited, re-identification banned, retention capped — with independent audit before access and annually after.
What survives is a strong head-and-torso relevance signal: useful for ranking common queries and calibrating what “good” looks like on popular intents. What does not survive is the tail, the session, and the person. You cannot rebuild a user journey, and you cannot mine rare high-intent queries — precisely where a specialist assistant would hope to beat a generalist. Eligibility is narrow too: a genuine EEA search service, a monthly EU user floor in the tens of thousands, economic-substance and sanctions screening, plus the audit.
So: a benchmark corpus, not a growth lever. Read that way, the pricing — incremental-cost-based, fixed for five years — is a reasonable line item, not a strategic windfall.
The compliance engineering nobody budgets for#
Staff this first: longest lead time, least glamour.
Consuming a regulated data feed is not an API integration. To pass the audit that gates access, you must demonstrate provenance for every record you hold: where it came from, under which agreement, when it arrived, when it expires, which artefacts derive from it. If a retention cap applies and one of your embeddings was trained on data past its window, “we deleted the source table” is not an answer. Lineage has to reach into model artefacts and eval sets, not just warehouse tables.
Concretely, that means four things most AI stacks lack:
- Immutable audit trails on receipt, access, and derivation — append-only, queryable, retained independently of the data they describe.
- Data-transfer records that survive a lawyer’s reading: agreement version, purpose scope, jurisdiction, fields transferred.
- Consent lineage for anything sourced on-device, tying a permission grant to the exact processing it authorised, with revocation that propagates.
- Purpose limitation enforced in the query layer, not in a policy document — so a dataset restricted to search improvement is technically incapable of joining to your CRM.
If that list feels familiar, it should. It is the architecture GDPR-grade lineage demands in a Hospital Management System, where every access to a patient record must be attributable and every derived dataset carries its consent basis forward. Teams who built that properly already have the substrate for regulated feeds. Teams who treated compliance as a quarterly PDF start from zero.
This is where legacy ERP vendors fail most predictably. Heavy suites trap data in proprietary schemas, log access for licence compliance rather than data protection, and stop lineage at the module boundary; when a regulator asks a question they were never designed to answer, the answer is a consulting engagement. The alternative we argue for — ERP as a data platform with thoughtful UI on top, whether a School ERP or a hospital estate — makes lineage a property of the platform rather than a project. The same Data Platforms discipline that makes analytics trustworthy makes regulated ingestion survivable.
Meaningful versus theatre#
Meaningful. The invocation and action surfaces are real, dated, and specific enough to build against. A published certification process with a four-week assessment SLA beats an unanswerable no. The audit and lineage requirements matter too, though not as regulators intended — they raise the floor on data governance for everyone who wants in.
Theatre, or close to it. Deferring concurrent hotword detection preserves the most valuable slot for another release cycle, by which point defaults will have set. The certification programme is administered by the party with the strongest incentive to make it slow, and the four-week clock constrains the assessment, not the queue in front of it. The search data, after suppression and k-anonymity, is thin enough that “levelling the playing field” oversells it.
Genuinely unresolved. Google’s position, argued by Kent Walker on the company blog, is that this trades European users’ privacy and security for competition. Some of that is a gatekeeper defending a moat. Some is a fair question about handing screen-reading and cross-app action rights to more vendors. Both can be true, and the certification criteria are where it gets settled.
What to do before the deadlines#
Build the action layer now — typed intents, permission classes, idempotency, rollback — because it is the long pole and it pays off whatever the certification terms say. Design for hybrid inference rather than retrofitting it. Stand up lineage and audit trails as platform capabilities, not a project scoped to one dataset. And read the draft eligibility terms the moment they publish: that document, not the Commission’s decision, determines who gets through the door.
The remedy did not hand anyone a market. It converted a closed question into an engineering programme with dates on it — a better problem than the one we had, and one that rewards teams who treated data governance as architecture rather than paperwork.
Regulated data feeds reward teams whose lineage is real. Most discover the gap during the audit. Tell us what you’re building at /#contact.