Contents

Introduction and Summary 1

1. Features for Invocation. 2

2. Features for Context 2

3. Features for Actions on Apps and the OS. 2

4. Features for Access to Resources 3

5. General Measures for All Features 3

Recommendations 4

Conclusion. 5

Endnotes 5

Introduction and Summary

On January 27, 2026, the European Commission opened a specification proceeding in connection with its designation of Google as a gatekeeper and its Android mobile platform as a core platform service to determine how the company must comply with Article 6(7) of the Digital Markets Act (DMA), which requires Google to provide third parties with effective interoperability for Android.[1] The Commission issued draft measures for Article 6(7) compliance, which encompass features for invocation, context, actions on apps and the operating system, and access to resources, as well as general measures for all features.[2]

The Information Technology and Innovation Foundation (ITIF) welcomes the opportunity to respond to the Commission’s consultation, where it seeks views on the draft measures’ “effectiveness, completeness, the integration effort concerning the measures, and implementation timelines.”[3] ITIF believes the Commission’s draft measures go far beyond what is necessary for Google to comply with Article 6(7) and will yield commercial impracticalities, reduced innovation, increased privacy risk, and a worse Android user experience.

ITIF’s comments mirror the structure of the draft measures: First, ITIF explains why the measures concerning features for invocation may well prove commercially unworkable; second, ITIF highlights how the broad data sharing measures associated with features for context create severe privacy risks; third, ITIF argues that the draft measures surrounding the features for actions on apps and the OS produce a serious free-rider problem that will chill incentives to innovate across the Android ecosystem; fourth, ITIF notes that the draft measures surrounding features for access to resources may ultimately result in a worse user experience; and fifth, ITIF finds that the general measures would impose harmful de facto public utility regulation on Google under the statutory slogan of “effective interoperability.” Recommendations and a brief conclusion follow.

1. Features for Invocation

The draft measures include interoperability provisions designed to enhance “features for invocation, or the ability for an end user to initiate their interaction with an AI service through a variety of access points.”[4] These involve measures to enable equal access for third-party AI services with respect to “contextual invocation through long-press home button/navigation handle,” as well as “always-on hotword detection,” which “allows apps to be invoked through user[s] uttering a hotword or wake word”—a feature which, at present, is said to be only available on Android for Gemini and Google Assistant.[5]

The Commission’s draft measures are flawed by virtue of their design to promote competition in certain AI services which are distinct from the Android operating system core platform service designated under the DMA. As such, they are beyond the scope of what this specification should be focused on. Indeed, for example, the AI assistant space is thriving, with rivals like Perplexity already having considerable success with Samsung in getting its apps preloaded on Android, which includes a voice-activated wake phrase functionality. Moreover, given that requiring concurrent hotwords for multiple agents would be done at the device level, the draft measures will likely prove commercially impractical by virtue of requiring an extensive amount of permissions and manufacturer customizations that will ultimately result in higher costs.

2. Features for Context

The draft measures also detail a number of “features for context, or the ability for an AI service to gather inputs and data to then understand and anticipate end users’ needs and provide helpful suggestions across apps.”[6] Specifically, the draft measures set forth a considerable amount of data sharing obligations with third-party AI services, including the provision of centralized access to apps’ data stored on-device; “proactive suggestions” data generated from a user’s data across apps; “context-aware intelligence” data that allows third-parties to offer their own proactive suggestions; as well as “ambient data,” which reflects “the continuous stream of real-time inputs/outputs from a device’s core sensors (e.g., microphone, camera, screen, speakers).”[7]

Here again, the Commission attempts to promote competition in an AI market other than the designated core platform service. And yet, unlike the data sharing obligations discussed in connection with the specification proceeding for Article 6(11), here there isn’t even any argument that AI assistants pose a disruptive threat to Android in the way that AI chatbots do for search. Indeed, as ITIF there explained, in ordering such unprecedented sharing of user data, not only is it true that “safeguarding user privacy in these circumstances is much easier said than done,” but “even if privacy protections can be crafted in a way that to some sufficient extent preserves the alleged competitive benefits that the Commission seeks, measures must still be taken to ensure that they do not impose prohibitive compliance burdens on firms.”[8]

3. Features for Actions on Apps and the OS

The draft measures also encompass interoperability obligations concerning “features for actions on apps and the OS, or the ability for an AI service to execute tasks on user’s behalf.”[9] These include ensuring “structured on-device integration,” which “enables an AI service to take actions inside other apps on the device in response to user request,” in addition to “screen automation” whereby “[a]genetic AI assistants may take control of other apps to automate multi-step tasks on behalf of the user.”[10] The draft measures also provide for interoperability with respect to certain Google apps, and specifically “the features that are used to integrate Alphabet’s AI services with other Alphabet apps,” as well as “system integration” interoperability, which will allow third-party AI assistants to “interact with the operating system on behalf of the user.”[11]

Once more, the Commission sets forward interoperability measures to promote competition in AI services markets wholly distinct from the Android operating system that has been designated as a core platform service. Further still, the Commission contemplates broad measures to open up Google’s mobile ecosystem to third parties in a way that creates a serious risk of free-riding: User-installed third-party AI services, in particular, are gifted not just extensive access to third-party and Google’s own first-party apps on Android that are complementary with AI services, but also the same access to Android that Google’s own AI tools enjoy. This dampens incentives to innovate across the Android ecosystem.

4. Features for Access to Resources

The draft measures also require interoperability with respect to “features for access to resources, or the ability for an AI service to use sufficient hardware and software resources to execute their tasks,” which entails Google granting access to its “system-level on-device models (ODMs),” or its machine learning and large language models that run on Google devices.[12] The Commission’s draft measures also go further and require interoperability for ODM implementation, specifically “grant[ing] parties the same ability to implement and use ODMs as it grants its own models.”[13] Moreover, the draft measures also force Google to “ensure that user-downloaded apps have the same as access to background execution as Alphabet’s apps.”[14]

Not only do these measures go even further in trying to promote competition amongst AI services in a way untethered to Android and encourage further free-riding, in this case on Google’s innovative AI models, but as the draft measures intimate, technical realties like those surrounding “power consumption” are almost certainly likely to result in a worse consumer experience.[15] In particular, the requirements around background execution alone are likely to directly harm consumers with reduced battery life and less available phone memory given the added background demands.

5. General Measures for All Features

The general measures for Android interoperability put forward by the Commission only exacerbate the aforementioned issues with respect to commercial feasibility, reduced privacy, chilled innovation, worse user experience, and going outside the DMA’s proper scope. Of these, several are of special concern. First, the proposed measures make clear that “Google will have to ensure that interoperability is offered free of charge, via complete, accurate and well-documented frameworks and APIs on all Google Android devices, including on devices supplied by OEMs.”[16] But, as ITIF has previously explained, such measures impose heavy costs on gatekeepers while denying them any ability to recover them—even on FRAND terms.[17]

The Commission also mandates that “Alphabet will have to ensure that the features listed above will be accessible to all apps, including user-installed apps and pre-installed apps without system privileges.”[18] That is a recipe for serious privacy and security risks. Specifically, forcing Google to grant third-party access to sensitive features on users’ devices to companies whose practices may not meet its exceptionally high standards could expose European consumers to increased privacy and security risks that far outweigh any benefits in terms of giving competitors increased access.[19]

Similar to its detour into AI markets that are in no need of DMA oversight, the Commission’s view that “Alphabet will have to ensure that the interoperability solutions for third parties will have to be equally effective to those available to Alphabet” goes beyond the scope of the competition policy goals that should orient DMA enforcement.[20] That is, not only is it commercially unrealistic for Google to make third parties as efficient as its own first-party solutions, but “effective interoperability” should be interpreted as offering interoperability solutions to the degree necessary for an equally efficient competitor to compete, which is consistent with the Commission’s broader competition policy framework in the area of unilateral practices.[21]

Furthermore, the proposed measures state that “Alphabet will have to make available to third parties any new functionalities of the listed features once they become available to Alphabet.”[22] Not only does this turn Google’s innovative and customized solutions into white label offerings, a highly problematic public utility-style implementation of the DMA, but not even Google necessarily knows ex ante exactly what interoperability functionality third-party connected devices may desire, or even whether the new integration will be successful, such that the proposed measures thus create a risk of third-party connected device providers unnecessarily bearing the costs of inadequate or failed product developments that would have previously been borne almost exclusively by Google.[23]

Recommendations

For these reasons, ITIF has substantial concerns with the draft measures put forward to specify Google’s interoperability requirements under Article 6(7) of the DMA for its Android operating system and offers the following recommendations for the Commission’s strong and urgent consideration:

▪ DMA oversight of AI services is improper and unnecessary:A specification proceeding that is designed to ensure that Article 6(7) is complied with in the context of protecting competition in Android should not be transformed into a means to promote competition in separate, undesignated, and dynamic AI services markets that are in no way in need of competition regulation like the DMA.

▪ The AI services measures will backfire:Rather than benefit competition and consumers, the various measures that are proposed to help “third-party AI service providers to compete with Alphabet’s AI-based services” are likely to create serious harms vis-à-vis commercial impracticability, privacy and security risks, chilled incentives to innovate, and a worse user experience.[24]

▪ Avoid heavy-handed public utility-style implementation of Article 6(7):The Commission has unfortunately doubled down on the public utility interoperability model it put forward in the Apple Article 6(7) specification proceeding for iOS and connected devices, which will not only impose a huge compliance burden on Google, but also chill innovation and threaten user privacy and security.

▪ EU competition policy protects—not produces—equally efficient competitors:The Commission patently deviates from the foundational concept of protecting as-efficient competitors and instead opts for an interoperability regime that attempts to force Google to make competitors equally efficient as its own offerings. That is not only commercially impracticable, but contrary to the model of competition on the merits that should guide the Commission’s enforcement in the area of unilateral exclusionary practices, including in the context of ex ante regulation like the DMA.

Conclusion

As ITIF made clear in its comment on the Commission’s proposed interoperability measures with Apple’s iOS and connected devices: “As the Commission continues to put forward specific measures that gatekeepers must comply with under the DMA, it is imperative that it avoid unduly chilling innovation and harming European consumers, including through reduced digital privacy and security.”[25] Rather than adopt a more light-touch approach, the draft measures reiterate the public utility interpretation of Article 6(7) in a way that will not only harm consumers and innovation, but confirm that the DMA remains a regime designed to target American firms with huge regulatory and compliance burdens and as such attract the attention of U.S. policymakers considering recourse through Section 301 of the Trade Act of 1974.

Endnotes