It is understood and accepted by most experts and observers that platform companies like Apple, Google, and Meta are large, systemic, and should be subject to competition disciplines. It is therefore a mystery that, time and again, the European Commission imposes a growing number of competition-regulatory demands on them that degrade user experience and quality, push the companies to pull service and functionality from European consumers, and that are likely to harm rather than encourage competition.
Over the past few months, we at ECIPE have written extensively about the problems created by the Digital Markets Act (DMA) and, more specifically, by the Commission’s use of specification proceedings to determine how digital products should be designed. On 16 July 2026, the Commission adopted two binding specification decisions addressed to Alphabet concerning interoperability with Google Android and access to Google Search data. These decisions prescribe how Google must modify its products, technical interfaces and commercial arrangements to comply with existing obligations under the DMA.
Under Article 6(7) DMA, Google must now provide competing AI services with free and effective interoperability with eleven Android features, through solutions equally effective to those available to Google’s own services. These features are intended to allow rival assistants to respond to customised voice commands, interact with applications, perform background activities and obtain fuller access to the device capabilities needed to execute actions on a user’s behalf. Most changes must be implemented in Android 18 by 1 August 2027 at the latest. Concurrent hotword detection must be implemented in Android 19 by 1 August 2028. Access to each feature is subject to explicit user consent. For five particularly sensitive features – screen automation, structured on-device integration, system integration, centralised access to on-device app data and context-aware intelligence, Google may, in exceptional circumstances, impose objective and non-discriminatory privacy, security and integrity eligibility conditions, supported by independent certification.
Under Article 6(11), Google must now provide eligible search engines, including AI chatbots offering search functionality, with access to anonymised ranking, query, click and view data on fair, reasonable and non-discriminatory (FRAND) terms. The framework governs eligibility, the scope of the data, anonymisation, pricing and the process through which the information will be supplied. The implementation timetable begins immediately and contains milestones running from August 2026 to January 2027. As with the Android decision, the Commission maintains that the framework contains material privacy and cybersecurity safeguards: access is restricted to qualifying recipients, recipients are subject to eligibility and audit requirements, and the end-user data must be anonymised before disclosure.
These safeguards are material and should be acknowledged. They do not, however, resolve the more fundamental questions raised by the decisions:
- Who determines whether a restriction constitutes a legitimate privacy, security or system-integrity safeguard, rather than a disguised obstacle to competition?
- How can competing assistants be permitted to interact with applications, perform actions in the background and access functions integrated with the operating system (OS) without compromising user privacy, device security or system integrity?
- How can search data remain sufficiently granular to provide meaningful competitive value while being sufficiently anonymised to protect the users who generated it?
- Who bears responsibility when access mandated by regulation results in a security breach, privacy violation, unintended action or other harm?
The answers to these questions matter because the decisions extend well beyond Android and conventional online search. Although the legal obligations arise from services already covered by the DMA, their intended competitive effects lie partly in adjacent markets for AI assistants, AI chatbots and agentic systems. The Commission has not designated those AI services as core platform services (CPS). It is nevertheless using obligations attached to Android and Google Search to influence the conditions under which competition among AI assistants, search-enabled chatbots and agentic systems develops. This is a form of cross-market regulatory expansion: obligations attached to established platform services are being used to redistribute technical capabilities and data in markets whose boundaries, competitive constraints and potential bottlenecks remain unsettled.
Regulating Yesterday’s Bottleneck in Tomorrow’s Market
When the DMA was developed, it was largely in response to the platform markets of the 2010s: OS, app stores, defaults, search engines and social networks with relatively identifiable gateways and stable network effects. Because of AI assistants and agents, these markets are no longer stable, and they are now creating different routes to users and different forms of substitution. The relevant competitive interface may therefore shift from one task to another. It is not obvious that Android, or any other single OS layer, will constitute the durable chokepoint through which agent competition must pass. Indeed, competition at the application layer remains fragmented, while concentration may be greater upstream in frontier models, computing infrastructure, cloud distribution or proprietary data. Broadly opening Android or Google Search may regulate a visible downstream interface while leaving untouched the layer at which a durable bottleneck eventually develops.
Additionally, assistants and agents may themselves become gateways capable of challenging existing platforms, but it is not yet clear which ecosystems will prevail, whether users will rely on several assistants or where durable bottlenecks will emerge. The existence of a concrete leveraging risk within an established ecosystem does not establish that the structure of the emerging AI market is already known. Furthermore, market-driven interoperability is also emerging independently of the DMA. The Model Context Protocol, for example, standardises how agents connect to tools and data sources. Model-routing services such as OpenRouter allow developers to access or route requests among hundreds of models through a common interface, selecting models according to task, capability, price or performance. These developments do not prove that competition concerns will never arise, but they demonstrate that the architecture of AI competition is still moving and that interoperability can emerge endogenously rather than exclusively through regulatory mandates.
From Gatekeeping to Systems Engineering
The Commission presents specification proceedings as a means of clarifying how a gatekeeper must comply with the DMA. The Google decisions demonstrate, however, how easily clarification can become something else – architecture regulation. The Commission is setting binding functional outcomes, access conditions and equivalence standards that determine which OS capabilities must be opened, what third-party services must be able to accomplish, what data must be supplied and the conditions under which access must be provided.
Although the Android decision does not prescribe the exact technical implementation, and Google formally retains responsibility for designing the necessary solutions, a choice among technical implementations is not the same as architectural freedom. Requirements concerning equal effectiveness, background execution, contextual information, application control and system-level invocation materially constrain the environment within which implementation can occur.
Moreover, these are not marginal compliance details. They influence the organisation of system components, the structure of interfaces, the distribution of permissions, the interaction between applications and the OS, and the way users experience competing services. That transformation raises an institutional question: does a competition authority possess the expertise and continuing technical visibility required to design complex OS and data-sharing architectures.
An OS is a constantly changing environment of applications, permissions, hardware, software, identities, data flows and vulnerabilities. A technically plausible interface at the time of a decision may become unsafe, obsolete or competitively irrelevant as the technology develops. The difficulty is compounded by Android’s decentralised structure. Device manufacturers make their own implementation, optimisation and interoperability choices. Google establishes important standards and controls key components, but it does not unilaterally determine every feature of every Android device. Moreover, by requiring access to sensitive device-level capabilities under a centrally prescribed framework, the Commission’s approach may constrain or displace manufacturers’ own security, compatibility and certification processes. A specification decision may consequently require Google to deliver outcomes that also depend on original equipment manufacturers and other implementers over which it has incomplete control.
In its strictest form, traditional refusal-to-supply and essential-facilities analysis approaches compulsory access cautiously. It asks whether the input is genuinely indispensable, whether any actual or potential substitute exists, whether the refusal is likely to eliminate all competition on the part of the undertaking requesting access, and whether the refusal is objectively justified. The DMA largely inverts that sequence. Once the gatekeeper and the relevant obligation have been identified, access is substantially presumed; the regulatory debate moves quickly from whether access is necessary to how it should be engineered. The general risk that Google could leverage Android or Search into AI is not itself proof that every limitation on access is exclusionary or that every compulsory-access remedy will improve competition.
Android and the Principle of Least Privilege
The Android decision in particular exposes a sharp tension between competition-law parity and the cybersecurity principle of least privilege. Under that principle, every user, application and system component should receive only the minimum resources and authorisations necessary to perform its particular function, and only for as long as those permissions are required. Modern zero-trust security applies the principle on a contextual, per-request basis: access should not be granted simply because an actor is inside a trusted environment or belongs to an approved category.
While requiring Google to make it technically possible for competing assistants to perform specified tasks does not necessarily conflict with the principle of least privilege, a conflict may arise if “equivalent” or “effective” access is interpreted as requiring third-party assistants to receive broad, continuing or insufficiently differentiated privileges merely because comparable functionality is available to Google’s integrated assistant. Where the equal-effectiveness requirement restricts differentiation beyond the strictly necessary, proportionate, objective and non-discriminatory safeguards permitted by the decision, the decision risks creating what may be described as regulatory privilege escalation. Third-party assistants may acquire deeper pathways into OS functions, applications and user data not because each privilege is technically required for a specific task, but because competition regulation demands functional equivalence with the platform’s integrated service.
The attack surface of a system expands with each additional privileged interface, authorised recipient, and permission pathway and software dependency. Even where an eligible provider is reputable, its software can contain vulnerabilities, its credentials can be compromised, and its own developers, contractors or downstream integrations can misuse access. The threat model cannot be limited to whether the recipient intends to cause harm. Nor should a platform’s refusal or delay automatically be treated as exclusionary. It may reflect unresolved questions about how an assistant can securely invoke another application, execute an action or handle personal information. In agentic systems, the same design choice may simultaneously operate as a safety mechanism, an accountability control and a restriction on access. Its legal significance depends on context.
For five sensitive features, the final decision permits Google, in exceptional circumstances, to assess whether recipients satisfy objective and non-discriminatory privacy, security and integrity criteria. That is an important safeguard. The decisive question, however, is how much discretion remains once a provider qualifies and how narrowly Google may tailor continuing access to particular tasks and risks.
Paradoxically, a decision intended to open Android could potentially encourage Google to close parts of its fragmented ecosystem, standardise implementations more aggressively and reduce the autonomy of device manufacturers. Mandatory functional equivalence could produce less architectural openness rather than more. It may also weaken product differentiation. Device manufacturers and OS providers also compete through software layers, assistant integration, security and hardware-software co-design. If every new capability must be exposed to rivals on equivalent terms, firms may capture less value from developing integrated functions. Over time, that can reduce the incentive to invest in performance-enhancing features or encourage European versions of products that contain fewer capabilities than versions offered elsewhere.
Moreover, consumers themselves do not necessarily prefer the maximum possible number of separately contestable components. Some value modularity and openness. Others deliberately choose integrated products because they offer simplicity, consistency, security, privacy or ease of use. Treating integration only as a competitive restriction ignores the possibility that it is also a product characteristic for which users have a genuine preference.
Search Data and the Anonymisation Trilemma
The search-data decision presents at the data layer the same kind of access problem that operating-system interoperability presents at the technical layer. Here, the relevant principles are data minimisation, purpose limitation and need-to-know access. The Commission seeks to make search data sufficiently useful for competing search engines, including AI chatbots offering search functionality, to develop and optimise their search services, while ensuring that the users who generated the data cannot be re-identified.
This creates an acute operational tension between the GDPR’s anonymisation standard and the DMA’s practical objectives. Recital 26 GDPR treats a person as identifiable by reference to all means reasonably likely to be used, including singling out and indirect identification. Article 6(11) DMA, read with Recital 61 DMA, requires access to ranking, query, click and view data while protecting end users against re-identification without substantially degrading the quality or usefulness of the data.
Those objectives are difficult to reconcile because the value of search data lies in its granularity. Queries, query metadata, ranked results, viewed URLs, interaction data and coarsened timing information reveal how users formulate questions and evaluate results. Even without account-level search histories, combinations of query content, generalised metadata, viewed URLs and interaction information may permit singling out or linkage when combined with auxiliary information. Rare searches and long-tail queries may be especially valuable for improving relevance in smaller linguistic or geographic markets. Yet their rarity may also make them more identifying. Indeed, the Commission’s criticism that Google’s initial proposal removed between 90 and 100 per cent of unique queries illustrates the problem: the records whose suppression may most effectively protect anonymity may also be among those considered necessary for competitive usefulness.
Removing names and direct identifiers is not sufficient. An individual may be singled out through an unusual query or through combinations of query content and associated metadata, or identified through inferences drawn from otherwise innocuous information. Anonymisation is not a permanent characteristic of a dataset: its effectiveness depends on the information, technical capabilities and incentives available to each recipient. That concern is particularly serious where recipients are large AI providers operating eligible online-search services. Such firms may already possess registered-user information, prompt histories, interaction records and powerful inference systems. Those resources remain relevant to the identification-risk assessment even where their combination with the search data is formally prohibited.
Contractual restrictions cannot, by themselves, substitute for technical anonymisation. The Commission does require technical alteration, ring-fenced processing environments, and restrictions on linkage with other datasets, access controls, monitoring and independent audits. Those measures reduce the risk, but they do not make contractual prohibitions equivalent to irreversible anonymisation. Their effectiveness depends on continuing compliance and on protection against misuse, insider access and system compromise. The requirement that anonymisation should occur without substantially degrading the quality or usefulness of the data makes the dilemma particularly acute. The result is an anonymisation trilemma. The Commission seeks data that is simultaneously:
- sufficiently granular to provide meaningful competitive utility;
- sufficiently anonymised that the data relating to the end user who generated the search no longer constitute personal data for the recipient; and
- sufficiently accessible and usable to constitute effective access on FRAND terms.
It is doubtful that all three objectives can be maximised simultaneously. Greater aggregation, filtering, delay and suppression of rare queries reduce re-identification risk but also diminish competitive utility. Preserving the richness of the dataset improves its commercial value but increases the possibility of singling out, linkability and inference. Article 6(11) therefore risks forcing a choice between data that retain substantial utility but present residual identification concerns and data that are safer but less competitively valuable.
Purpose limitation creates a further difficulty. Users provide query and click information to Google to obtain search results. They do not necessarily expect that their behaviour will subsequently be used to develop the search technologies of unrelated search engines or AI-chatbot providers. The Commission prohibits use for general-purpose AI-model training, consumer profiling, advertising and services unrelated to online search. At the same time, it permits a broad range of uses for query understanding, retrieval, ranking and indexing. The boundary between permissible optimisation of search functionality and impermissible improvement of a broader AI system may therefore be difficult to define and supervise in practice.
A disclosure compelled by the DMA may rest on a legal obligation, but that does not eliminate questions of fairness, transparency, user expectations and the proportionality of downstream processing. The allocation of responsibility is equally uncomfortable. Google bears the compliance risk associated with preparing and disclosing the dataset and may face claims if the data of the users who generated the searches have not been effectively anonymised. Recipients bear separate responsibility for their subsequent processing and for personal data relating to individuals mentioned or otherwise identifiable in searches. The Commission prescribes the framework, but practical accountability is divided among Google, recipients, auditors and data-protection authorities.
Access Does Not Guarantee Entry
Access to an input does not supply a competitor with the models, computing infrastructure, technical expertise, capital or distribution necessary to exploit it effectively. The principal beneficiaries may ultimately be large AI providers rather than smaller European search engines or AI developers. Major AI companies are better equipped to integrate with Android, process large datasets and operate compliant ring-fenced environments. The eligibility criteria for access to Google Search data further reinforces this concern. A beneficiary must ordinarily have at least 50,000 monthly EU users, while a company founded fewer than two years ago must have attracted more than €50 million in capital investment. These thresholds may screen out opportunistic applicants, but they also favour firms that already possess substantial scale or financing. Traditional search engines and AI-native services also use data differently. Conventional search depends heavily on crawling, indexing, query volume, ranking and click behaviour. AI-native services, by contrast, may derive much of their broader competitive advantage from model development, prompt-response optimisation, personalisation and continuing interaction with registered users – activities that the shared dataset either cannot lawfully support or may support only insofar as they genuinely form part of online-search optimisation.
Delayed and anonymised search data may consequently have different and potentially limited value for different recipients. The remedy may therefore redistribute advantage rather than reduce barriers to entry. Transferring valuable input from one powerful technology company to another is not the same as creating the infrastructure, capabilities and financing required for genuinely new competitors to emerge. This is the paradox at the centre of the decisions. In trying to prevent the AI market from tipping toward one designated gatekeeper, the Commission may strengthen the handful of AI companies already capable of exploiting mandated access at scale. Regulation intended to preserve competition may influence the firms and architectures around which the market eventually consolidates.
Conclusion
Through these specification decisions, the DMA unfortunately treats access as an instrument for creating competition. In doing so, however, the Commission risks placing competitive parity ahead of security, privacy, product integration and innovation, and requiring those interests to adjust around the remedy. That is the wrong hierarchy. A competition measure should not require a platform to expose more of its system, disclose more data, or shape an emerging market before its competitive structure is sufficiently understood. The Commission has moved beyond asking whether Google is excluding rivals and towards determining which technical privileges, data and architectural advantages those rivals must receive. A market made contestable through regulatory privilege escalation may become less secure without becoming genuinely competitive.
Moreover, blunt and heavy-handed architecture regulation also runs the risk of forcing Google to stop offering European customers access to the same services and functionality that customers elsewhere could get. Apple has already announced that Siri AI will not launch with iOS 27 or iPadOS 27 in the EU, attributing that delay to the interoperability requirements of the DMA. Will Google now do the same with future Gemini functionality – fearing that the risk of complying with the detailed interoperability specifications will compromise architectural integrity and, ultimately, the security of its users? It would not come as a surprise if it does, but it would be another example of how the DMA can create outcomes that are the opposite from its basic objective: more competition!