Keeping the Gate: The European Commission Issues Its Specification Decision on Alphabet’s Operating System Interoperability with AI Assistants

Abstract

This piece analyses the European Commission's Specification Decision on Alphabet’s implementation of Article 6(7) DMA, which mandates vertical interoperability between Google’s Android operating system and competing AI assistants. Comparing the final decision against the April Draft Implementation Measures, the article identifies a marked shift toward regulatory flexibility: while twelve of thirteen originally contemplated features remain in scope, five are now classified as restricted features subject to a gatekeeper-administered certification regime. This reintroduces discretionary control that the EC had previously foreclosed in its Apple specification decision, creating tension in the Commission’s interpretation of the DMA's integrity defence.

The analysis further traces procedural retrenchments, alongside a subtle but consequential drift away from API-based compliance toward outcome-oriented obligations. Collectively, these changes are argued to shift oversight from an automatable, verifiable fire alarm model toward resource-intensive, discretion-laden police patrol enforcement, raising questions about the EC’s capacity to supervise Alphabet’s compliance effectively.

1.     Introduction

Complying with the 6-month deadline that DMA specification proceedings pose on the European Commission (EC), the regulator issued the implementation measures that Google will have to comply with by 2027 to provide vertical interoperability to competing AI assistants wishing to access its operating system (the Specification Decision).1 The 32-page document illustrates the measures that Alphabet will have to implement in the coming year, regardless of the fact that we have not yet learnt what the EC’s fully-fledged reasoning was to reach those conclusions. That will have to wait until the EC publishes the full decision illustrating how it implemented Article 6(7) in this particular scenario.

For the moment being, however, we can clearly see some differences in the EC’s approach if we compare the Draft Implementation Measures it issued in April2 with the regulator’s final specification decision.3 The transformation of the obligations that Google must comply with signals that the EC might be flexibilising its approach towards interpreting integrity in the context of Article 6(7) DMA. If anything, the Specification Decision relays some of the control that it had pulled from Alphabet and ensures that it can keep one of its gates for a bit longer.

2.     The Objectives of the Specification Decision

Let’s recap the meaning of the specification proceedings at Alphabet by the European Commission. As illustrated by the EC on its press release, AI assistants that compete with Alphabet’s proprietary services only have restricted access to key functionalities of the Google Android operating system (OS).4 Without this access, alternative AI assistants cannot compete on an equal footing with Google’s own AI services that do have full access to a wide array of functionalities and features that facilitate the catering of the function of an AI assistant.

Due to these restrictions (and under the impression that Android’s features powering Google’s AI assistants fall under the scope of the DMA), the EC decided to intervene by setting out which implementation measures the gatekeeper must apply to its OS in order to bring it in line with the contestability and fairness objectives. To do that, the Draft Implementation Measures sought to introduce changes relating to how an AI assistant interoperates with Google’s OS by providing equivalent access to competitors to the following features and functionalities:

Table 1. Features and functionalities included under the scope of the specification proceedings.

As you’ll see from Table 1, the Draft Implementation Measures touched upon thirteen different features and functionalities that the gatekeeper had to provide equivalent access to third parties so as to ensure that Article 6(7) was complied with. The integration of all these features aim at avoiding Alphabet’s favouring of its services surfacing at any given point within its OS, be that through having access to capabilities that a competitor cannot reach or by providing faster invocation paths to itself as opposed to competitors.

Alphabet runs its own Gemini on Android in a tight loop. The Draft Implementation Measures ensure that a third-party assistant is provided with parity with Alphabet’s own services at every stage of the same loop. In addition, given that Alphabet is vertically integrated (because it controls both the OS and the downstream services), a gap at any single stage would be enough to make competition on the merits unrealistic.

Due to this reason, the EC designed its implementation measures around four main ideas: invocation, context, actions and resources. First, LPH/LPNH and always-on hotword detection constitute the actual gate to compete on the merits. A third-party assistant can be invisible most of the time for the user if there is no credible way in which a user can reach it or, alternatively, if it’s easier to reach Gemini than the competing service. Second, centralised on-device data access, context-aware intelligence and ambient data access constitute the sensory input to the proceedings. Once the competing AI assistant can be reached (via invocation), it must be able to be invoked with equal functionality to the gatekeeper’s services. In other words, the competing assistant must be able to access screen content and cross-app data to be able to reason on the basis of the same information that Gemini gets for an identical query. Third, structured on-device integration, screen automation and system integration are how the assistant actually does something once the user decides what to do. If the assistant does not have an action layer, then it cannot execute anything on behalf of the user. Fourth, system-level ODMs, ODM implementation and background execution form the computational substrate necessary for competitors to participate in the market. An AI assistant with perfect invocation, context and action-layer access must also be able to run with an acceptable latency and be sufficiently reliable. All the features that the EC decided to include in its Draft Implementation Measures complement each other to regulate each stage in the loop. The Specification Decision follows the same path. It includes twelve of the thirteen features listed in the Draft Implementation Measures to maintain the four-pronged approach towards securing vertical interoperability.

3.     Restricted Features: Keeping the Gate

Despite the similarities between both versions of the implementation measures, the Specification Decision adds a new caveat to the vertical interoperability regime that will apply to Alphabet. Going back to Table 1, you’ll find five features highlighted in grey (centralised access to apps’ data stored on-device, context-aware intelligence, structured on-device integration, screen automation and system integration), which correspond to those that the EC now defines as restricted features (para 120 of the Specification Decision). In other words, the EC draws out a specialised regime that will apply to these features, whereby Apple may require the developer to demonstrate that its service meets certain eligibility conditions. Apple’s Notarization process when authorising access to alternative app distribution,5 comes readily to mind, which is currently under scrutiny through the EC’s ongoing non-compliance procedure relating to the implementation of Article 6(4) DMA.6 All five features happen to align almost exactly with the features of greatest competitive value to a rival assistant, which are perception and action. Gating these features means a competing assistant cannot reach functional parity with Gemini on its most compelling capabilities until it clears certification.

Alphabet (or a trusted certification authority that it creates) is put behind the wheel of certifying its competitors as meeting the eligibility conditions to be granted access to these features. Depending on the type of service that seeks interoperability, Alphabet is forced to set up a certification process, based on transparent, objective, precise and non-discriminatory criteria (para 125), for AI assistants so that they are granted the status of Qualified AI assistants (paras 123-126) or Qualified Services (para 137). The eligibility conditions include wide and abstract concepts that Alphabet must define in its certification process, that address the functional eligibility of an AI assistant or the agent and model functional risks (para 125). In addition, Alphabet is the undertaking in charge of approving any trusted certification authority, of revoking any certification and of appointing the body where third parties can appeal those decision (para 134).

By adopting this approach, the EC also made the oversight of the implementation of Article 6(7) DMA extremely difficult. Conditions like providing “advanced reasoning capabilities (…) that enable it to interpret and act on user intent autonomously” or being “adequately hardened against key agentic risks” (para 125) do not set out testable metrics that the EC can check, as it could do with a permission scope or an API signature. Instead, the introduction of the certification process pushes supervision to take place via human review over Alphabet or a trusted certification authority, which will be inherently slower and less consistent than an automated gate would be. Thus, the Specification Decision subjects the competitive process of AI assistants competing with Alphabet on its OS to ex post regulatory oversight through enforced self-regulation.7

Building on this shifting of responsibility to the gatekeeper, the Specification Decision grants Alphabet the capacity to temporarily suspend a Qualified AI assistant from accessing the restricted features when it is “in possession of a consistent body of evidence that (it) has been engaging in practices that can cause several and immediate harm to users” (para 131). This mechanism resembles remote app-disable mechanisms that Alphabet has used in the past (e.g., through Play Protect), which have a documented track record of false positives in automated abuse detection. And adding onto that, the EC relays all control on the gatekeeper to construe the consistent body of evidence that will legitimise its exclusion of competitors in the market, without indicating the legal standard that the body of evidence must meet, i.e., whether it should be a conclusive and consistent body of evidence or whether consistency applies regarding Alphabet’s own narrative that a third party may be engaging in harmful practices.

These implementation measures are particularly surprising against the background of the EC’s recent specification decision8 against Apple’s implementation of the vertical interoperability obligation.9 In that decision, the regulator set out in black and white that Article 6(7) DMA “does not provide for any limitations as to the beneficiaries, apps, products and use cases for interoperability with iOS hardware or software feature insofar as this feature is available to, or used by, Apple and intended to be used by a third party that is eligible under Article 1(2) DMA” (para 603 of the Apple Specification Decision). In this same sense, the Specification Decision went on and declared that it “cannot be left to the discretion of the gatekeeper to decide which third parties can benefit from the interoperability mandated by Article 6(7) DMA, whether through discriminatory restrictions of any nature or the outright exclusion of beneficiaries, apps, or use cases” (para 75). In other words, the EC interprets that discretion must not be granted upon the gatekeeper to decide which third parties can benefit from the advantages of Article 6(7) because “such an assessment, which would require an individual examination of the specific circumstances of each third party, is not required by (the provision). Such an assessment would introduce the requirement to investigate on a case-by-case basis the effects on competition of a gatekeeper’s given conduct, which the legislator explicitly rejected” (para 66).

Despite the limitations introduced by the EC in its previous specification decision, the regulator now decides that Alphabet’s special situation merits to flexibilise its position in favour of reintroducing some gatekeeper discretion over who may benefit from the regulatory provisions. Such discretion was, however, clearly limited by the EC via its previous specification decision, given that “absent verifiability, the gatekeeper retains broad discretion to abuse its power” (para 122).

By this same token, the Specification Decision enters into a blatant contradiction with the EC’s previous track record when it comes to interpreting the integrity defences that can take place under Article 6(7) DMA. The provision reads that “the gatekeeper shall not be prevented from taking strictly necessary and proportionate measures to ensure that interoperability does not compromise the integrity of the operating system, virtual assistant, hardware or software features provided by the gatekeeper, provided that such measures are duly justified by the gatekeeper” (highlight added). The gating of certain restricted features by the EC falls right into the definition of the range of measures that the gatekeeper may adopt, not to compromise the OS’ integrity.

The enforcer was quite clear in distinguishing integrity from security and privacy when deciding on Apple’s interpretation of vertical interoperability (para 102 of Apple’s specification decision). According to the enforcer, “the records of the legislative process that led to the adoption of the DMA indicate that the legislator has considered but ultimately rejected the position that cyber security and end user data protection may serve as a justification. Instead, it decided in favour of a justification grounded on integrity only” (para 103). Following this reasoning, the EC highlighted that a gatekeeper “may not justify integrity measures by the mere fact that third parties are not the gatekeeper, and therefore cannot be trusted”, because trust is “a subjective assessment exclusively within the gatekeeper’s control (… and not) independently verifiable” (paras 112-113). However, when one turns to the eligibility conditions that the EC spelled out for certification, most of them indirectly touch upon trust. For instance, one of the main criteria that Alphabet can incorporate into its certification process is that of the developer’s reputability conditions that require the competitor to show it “remains abreast of emerging AI-based vulnerabilities” and has “policies and processes to monitor and assess the resilience of its AI assistant” (para 125 of the Specification Decision).

The inconsistency in the EC’s enforcement of Article 6(7) can be explained in one of two ways. On one side, the EC believes that the services concerned in the present case merit that an integrity screening is administered by the gatekeeper, without presenting any further friction (which is, in my own view, the less likely scenario). On the other side, the regulator perceives the risk profile of agentic AI features to be qualitatively different from those presented by third-party physical connected device. In other words, given that AI assistants (and the opening up of the ecosystem relating to the OS in the intensity presented by the EC in its Draft Implementation Measures) pose more risks overall, different legal standards must be tailored to each gatekeeper, without incurring a breach of the principle of equality.

4.     Procedural Changes: Deadlines and Transparency Tempered

As much as commentators of the DMA might have anticipated the changes that the Specification Decision will bring to the market, they will have to wait a bit more for those changes to crystallise in the market. As opposed to the early 2027 deadlines that the Draft Implementation Measures had introduced, the Specification Decision delays the deadline for their application until August 2027 (and pushes that further for the case of the always-on hotword detection to August 2028). One can only expect that the deadline shifting was caused by the dialogue between the EC and the gatekeeper once the Draft Implementation Measures were made live and subject to public consultation.

A more worrying development has materialised in the Specification Decision concerning the transparency of Alphabet’s compliance with the implementation measures. In the Draft Implementation Measures, the enforcer compelled the gatekeeper to provide the EC “with a non-confidential version of (… an) Initial Implementation Report, Monthly Implementation Report, Pre-release Feature Implementation Report, Final Feature Implementation Report and Semi-annual Implementation Report (…) for publication when (the reports are) due” (para 157 of the Draft Implementation Measures). The Specification Decision lowers these transparency obligations substantially, mirroring the DMA’s overall approach in providing few opportunities to third parties to actually perceive what is happening behind closed doors. The Specification Decision now only requires Alphabet to provide the EC with a confidential and a non-confidential version of the Final Feature Implementation Report when each report is due. The rest of the reports will only be made available in their non-confidential versions “upon the Commission’s request” (para 163 of the Specification Decision).

By doing so, the enforcer takes the stance of a police patrol as opposed to taking recourse of fire alarm oversight, as McCubbins & Schwartz pointed out in the early 1980s.10 Fire alarm oversight is preferable to the police patrol approach to the extent that third parties can continuously monitor disclosed material and trigger enforcement via complaints, which makes it cheaper and more scalable for the regulator. Notwithstanding, the EC maintains the DMA’s confrontation with being flooded with third-party input and, thus, shifts enforcement towards a one-on-one discussion with the gatekeeper.

5.     A Matter of Wording? APIs vs. Outcome-Oriented Outcomes

The keen observer might have also stumbled upon some notable differences between the Draft Implementation Measures and the Specification Decision when it comes to the relevance of APIs in the implementation of Article 6(7) DMA. The EC maintains a general obligation on Alphabet to make available “complete, accurate, and well-documented APIs to the extent that access to such APIs is relevant for the implementation of the measures” (para 149). Some of the features still explicitly require Alphabet to provide access to third parties via “specialised APIs for specific tasks”, such as in the case of system-level on-device model implementation (para 83).

However, the regulator drops references to measures compelling the gatekeeper to provide API access as far as invocation and the action layer are concerned. For example, the Draft Implementation Measures highlighted that “Alphabet shall create an API or open existing APIs to allow third-party developers to enrol these first stage sound models” in the context of always-on hotword detection (para 14 of the Draft Implementation Measures). The Specification Decision reduces the obligation to compelling Alphabet to provide “the ability to enrol a sound model (…) to persistently store and retrieve the sound model upon request” (para 13 of the Specification Decision). Similarly, the Draft Implementation Measures required “Alphabet (to) allow third-party apps to use the same system-privileged APIs that Alphabet’s AICore uses, or APIs that provide equivalent functionalities” (para 108 of the Draft Implementation Measures). In the Specification Decision, the obligation is replaced by a general obligation to “allow third-party access to the same functionalities to install, run and use them as available to AICore ODMs and related software, with the exception of functionalities that are available only to internal operating system components” (para 95 of the Specification Decision).

Although the change might be imperceptible for some, it is meaningful. APIs are fixed, discoverable and independently testable artifacts. The regulator can easily point to it so that third parties can call it from outside the ecosystem. Once the calls are made, it can then compare its documented behaviour with the actual observed behaviour that they exert when interacting with third parties and detect whether discrepancies ensue. With the broader wording that the Specification Decision now incorporates, Alphabet can satisfy the EC’s requirements via different means (e.g., through a public SDK call or an undocumented system call reachable only via reflection) and with different openness, discoverability and stability properties. In turn, the EC’s police patrol oversight role is further extended and complicated to the extent that it will now have to establish through behavioural testing whether the mechanisms rolled out by Alphabet achieved parity with what Gemini gets. This places a higher evidentiary burden on the enforcer, which it might not be able to attend to with limited resources and manpower.

• 1Case DMA.100220 | Alphabet – OS – Google Android – Art. 6(7) – SP – AI (16 July 2026).
• 2Case Summary - Case DMA.100220 | Alphabet – OS – Google Android – Art. 6(7) – Features for AI or AI-Related Services (16 April 2026).
• 3See comment, Alba Ribera Martínez, ‘All for One, and One for None: The European Commission’s Implementation Measures Target New Entries in the AI Assistant Market’ (SSRN, 6 June 2026), available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6888799.
• 4Directorate-General for Competition and Directorate-General for Communications Networks, Content and Technology, ‘Commission provides guidance to Google for AI interoperability on Android and sharing of Google Search data under the Digital Markets Act’ (Digital Markets Act (DMA), 16 July 2026), available at https://digital-markets-act.ec.europa.eu/commission-provides-guidance-google-ai-interoperability-android-and-sharing-google-search-data-under-2026-07-16_en.
• 5Apple, ‘Update on apps distributed in the European Union’ (Apple Developer), available at https://developer.apple.com/support/dma-and-apps-in-the-eu/.
• 6Directorate-General for Competition and Directorate-General for Communications Networks, Content and Technology, ‘Commission sends preliminary findings to Apple and opens additional non-compliance investigation against Apple’ (Digital Markets Act (DMA), 24 June 2024), available at https://digital-markets-act.ec.europa.eu/commission-sends-preliminary-findings-apple-and-opens-additional-non-compliance-investigation-2024-06-24_en.
• 7John Braithwaite, ‘Enforcer Self-Regulation: A New Strategy for Corporate Crime Control’ (1982) 80(7) Michigan Law Review 1466.
• 8Case DMA.100203 – Article 6(7) – Apple – iOS – SP – Features for Connected Physical Devices (19 March 2025).
• 9Alba Ribera Martínez, ‘Interoperability by Design or Denial? The European Commission’s Preliminary Findings on Apple’s Implementation of Vertical Interoperability’ (Kluwer Competition Law Blog, 3 February 2025), https://legalblogs.wolterskluwer.com/competition-blog/interoperability-by-design-or-denial-the-european-commissions-preliminary-findings-on-apples-implementation-of-vertical-interoperability/.
• 10Mathew D. McCubbins and Thomas Schwartz, ‘Congressional Oversight Overlooked: Police Patrols versus Fire Alarms’ (1984) 28(1) American Journal of Political Science 165.