Model-to-Model Interoperability Constraints in AI Ecosystems

Detailed Explanation with at Least 6 Case Laws — UK, German and EU Competition Law Perspective

1. Introduction

Model-to-model interoperability refers to the ability of different artificial intelligence models, AI agents, and associated infrastructure to communicate, exchange data, transfer tasks, and operate together without being unnecessarily restricted by proprietary technical or contractual barriers.

For example, a business may use one provider’s foundation model for language processing, another provider’s model for image analysis, and a third provider’s model for forecasting. Interoperability allows these components to cooperate through compatible application programming interfaces (APIs), standard data formats, shared protocols, and portable outputs.

The central competition-law concern is whether a company competes by offering a better AI model or protects its market position by preventing rival models from working effectively with its ecosystem.

Interoperability constraints can arise at several levels:

Technical: closed APIs, incompatible data formats, proprietary agent protocols, restricted tool access, or deliberate degradation of external-model performance.

Contractual: exclusivity clauses, restrictive licensing terms, anti-switching provisions, and prohibitions on connecting competing models.

Infrastructure-based: dependence on a single cloud provider, GPU environment, model-hosting service, identity system, or inference API.

Data-related: restrictions on transferring conversation histories, embeddings, evaluation datasets, memory states, and other useful outputs between models.

Commercial: discriminatory pricing, preferential access for affiliated models, tying, bundling, and incentives that make independent interoperability uneconomic.

Not every incompatibility is unlawful. Providers may legitimately protect cybersecurity, confidential information, intellectual property, privacy, and system integrity. The legal question is whether the restriction is objectively justified, proportionate, and consistent with competition rules.

This topic is particularly important in the UK and EU because AI ecosystems increasingly combine foundation models, cloud infrastructure, distribution platforms, and downstream applications. German competition law adds an important dimension through the Bundeskartellamt's powers over undertakings of paramount significance for competition across markets.

2. Legal framework

A. European Union

Article 102 TFEU prohibits the abuse of a dominant position. Where dominance is established, potentially relevant conduct includes:

Refusing access to an indispensable interface or facility.

Discriminating between affiliated and rival AI models.

Tying access to a cloud or distribution platform to use of a particular model.

Restricting interoperability to foreclose downstream competitors.

Using technical restrictions to reinforce switching costs or prevent effective multi-homing.

Article 101 TFEU may apply where agreements between independent undertakings restrict competition—for example, agreements to exclude rival models from interoperable ecosystems or coordinate restrictions on common interfaces.

The EU Digital Markets Act (DMA) also contains obligations relevant to interoperability, switching, and gatekeeper conduct. Its specific duties depend on the designated service and applicable statutory provision; it does not establish a universal requirement that every AI model be interoperable with every other model.

B. Germany

The German Act Against Restraints of Competition (Gesetz gegen Wettbewerbsbeschränkungen, GWB) is especially relevant:

Section 19 GWB: prohibits specified abuses of dominance.

Section 19a GWB: permits the Bundeskartellamt to address certain anticompetitive conduct by undertakings of paramount significance for competition across markets, subject to the statutory requirements and procedure.

Section 20 GWB: addresses certain conduct involving relative or superior market power, including situations where smaller businesses depend on access to a powerful undertaking.

These provisions can be relevant where a cloud provider, mobile ecosystem, or foundation-model supplier controls access to an important technical interface and makes rival AI services less viable.

Section 19a is not a general interoperability mandate. Its application depends on the undertaking's designation, the conduct at issue, and the applicable legal conditions.

C. United Kingdom

The principal UK competition-law provisions are:

Competition Act 1998, Chapter I: restrictive agreements and concerted practices.

Competition Act 1998, Chapter II: abuse of a dominant position.

Digital Markets, Competition and Consumers Act 2024 (DMCC Act): establishes the digital markets competition regime, including conduct requirements for firms designated with strategic market status (SMS).

Under the DMCC regime, the Competition and Markets Authority (CMA) may impose tailored conduct requirements on an SMS firm in relation to its designated digital activity, subject to the statutory framework. Such requirements could be relevant to interoperability, fair dealing, and open choices where the legal conditions are met.

The key distinction is that interoperability may be required by a specific regulatory obligation or remedy, but it is not automatically required merely because a company operates a proprietary AI model.

3. Major competition-law issues

3.1 Refusal to interoperate

A dominant provider may prevent a competing AI model from accessing an operating-system function, agent interface, or application platform. The restriction may prevent a rival from offering equivalent functionality even if its underlying model is technically competitive.

The relevant questions include:

Does the platform hold a strong or dominant position?

Has access previously been granted to other third parties?

Does the refusal exclude, obstruct, or delay competing services?

Is the restriction objectively necessary for security, privacy, or technical integrity?

Could a less restrictive solution achieve the same legitimate objective?

The distinction between infrastructure developed solely for internal use and a platform designed to support third-party services is particularly important in EU case law.

3.2 Proprietary protocols and technical fragmentation

AI providers may use different tool-calling schemas, agent communication protocols, authentication systems, memory representations, and output formats. Some differences arise naturally from competing technical designs. Others may become exclusionary where a provider deliberately withholds documentation, changes interfaces without reasonable transition periods, or makes rival models materially less functional.

Competition authorities should distinguish ordinary product differentiation from strategic incompatibility designed to increase switching costs or foreclose rivals.

3.3 Data portability and model switching

A user may be able to download documents from one AI platform but still be unable to transfer the information needed to reproduce its functionality elsewhere.

Relevant information may include:

Conversation histories and user-configured preferences.

Agent workflows, tool configurations, and task histories.

Embeddings and retrieval indexes, where technically transferable.

Evaluation results, application logs, and model-generated structured outputs.

Permissions, authentication settings, and audit records.

Portability does not mean that a customer owns every internal model parameter or can demand access to another provider's training data. The legal assessment must distinguish customer-provided data, personal data, generated outputs, confidential information, and the provider's proprietary model weights.

3.4 Cloud and infrastructure dependency

A business that trains on one cloud, deploys on another, and uses a proprietary inference service may face significant migration costs. If the cloud provider also owns a competing foundation model, it may have incentives to favour its own model through pricing, performance, or preferential access to infrastructure.

The issue becomes more serious when combined with long-term commitments, egress charges, incompatible orchestration tools, or technical barriers to moving workloads.

3.5 Self-preferencing and discriminatory access

A provider may give its own model earlier access to operating-system functions, higher request limits, richer contextual data, or more reliable APIs than competing models receive.

Such differences are not automatically unlawful. Authorities must assess the provider's market position, the applicable legal duty, the competitive effects, and any objective justification. Where an ex ante rule requires equivalent access, compliance may be assessed under that rule without having to establish every element of a traditional refusal-to-deal abuse.

4. At least 8 major case laws and their application to AI interoperability

The following cases establish principles that can be applied to AI ecosystems. Most predate modern foundation models; they are therefore analogical precedents, not judgments directly deciding whether one AI model must interoperate with another.

1. Microsoft Corp. v Commission (2007)

Citation: Case T-201/04, General Court.

Principle: Refusal to disclose interoperability information may constitute an abuse of dominance in exceptional circumstances.

The European Commission found that Microsoft had refused to provide competitors with information needed to achieve effective interoperability between their server operating systems and Windows-based systems. The General Court upheld the relevant infringement findings.

Application to AI: A dominant foundation-model provider might restrict access to an interface or protocol necessary for rival models to participate effectively in an ecosystem. The case supports examining whether rivals can achieve commercially viable interoperability through alternative means.

However, it does not establish a general obligation to disclose model weights, training datasets, source code, or confidential model architecture.

2. Oscar Bronner GmbH & Co. KG v Mediaprint

Citation: Case C-7/97, Court of Justice of the European Union, 1998.

Principle: A refusal to provide access to infrastructure developed by a dominant undertaking is subject to a demanding legal test in circumstances where the infrastructure was developed for its own use.

The Court considered whether a newspaper publisher's distribution system was indispensable to a rival and whether refusal of access could eliminate effective competition.

Application to AI: A claimant seeking access to a proprietary inference platform, model-serving infrastructure, or specialised agent interface must establish the applicable legal conditions for a refusal-to-deal claim. The existence of technical inconvenience or higher switching costs alone will not necessarily establish abuse.

The availability of alternative models, cloud services, APIs, or technical workarounds is therefore important.

3. IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG

Citation: Case C-418/01, Court of Justice of the European Union, 2004.

Principle: The Court articulated conditions for exceptional compulsory licensing of intellectual property, including circumstances involving new products for which there is potential consumer demand, the absence of objective justification, and the risk of eliminating competition in a secondary market.

Application to AI: If a model provider owns intellectual property relating to a technical interface, a rival cannot assume that competition law automatically entitles it to a licence. The analysis must consider the relevant intellectual property rights, the competitive effects, the applicable refusal-to-license doctrine, and possible objective justifications.

A requirement to enable interoperability should be carefully distinguished from a demand to reproduce the protected model itself.

4. Slovak Telekom a.s. v European Commission

Citation: Case C-165/19 P, Court of Justice of the European Union, 2021.

Principle: The stringent Bronner indispensability test does not necessarily govern every form of access-related abuse, particularly where the dominant undertaking is already subject to a regulatory access obligation.

Application to AI: Where a cloud or platform operator already provides access to third parties, or is subject to a specific statutory access obligation, it may be inappropriate to treat every discriminatory access condition as an entirely new refusal-to-deal scenario.

An authority should identify the actual conduct, the existing legal obligations, and the correct legal test rather than mechanically applying Bronner to every interoperability dispute.

5. Google Android Auto / Enel X Italia v Google

Citation: Case C-233/23, Court of Justice of the European Union, 2025.

Principle: A dominant undertaking's refusal to ensure that a third-party application interoperates with its digital platform can potentially constitute an abuse even when that platform is not indispensable to the application's commercial operation, where the platform was not developed solely for the dominant undertaking's own needs.

The dispute arose because Enel X sought to make its electric-vehicle charging application, JuicePass, interoperable with Android Auto. The Court clarified the relevance of the platform's design and the potential exclusionary effects of refusal.

Application to AI: This is particularly significant for AI agents and operating-system assistants. If a platform is designed to accommodate third-party applications, selectively denying an independent AI assistant access to relevant functions may be problematic where it obstructs competition and lacks objective justification.

The decision does not mean that every model must be compatible with every platform. Its reasoning depends on the facts and circumstances identified by the Court.

6. Google Android Commission Decision (2018)

Citation: European Commission, Case AT.40099.

Principle: Restrictions involving distribution, pre-installation, and contractual arrangements may reinforce the market position of a dominant ecosystem.

The Commission examined Google's Android-related practices, including restrictions and incentives associated with the distribution of search and browser services.

Application to AI: An ecosystem owner could potentially reinforce model dominance by tying access to a major distribution channel to the use of its own AI assistant, discouraging device manufacturers from distributing alternatives, or making third-party models less discoverable.

The relevant lesson is that competition analysis should examine the entire distribution system, not merely the technical compatibility of individual models.

7. Microsoft Corp. v Commission — tying of Windows Media Player

Citation: Case T-201/04, General Court, 2007.

Principle: The bundling of a dominant product with a separate product can restrict competition where the applicable legal requirements for abusive tying are satisfied.

The same judgment that addressed interoperability also upheld findings relating to Microsoft's tying of Windows Media Player with its dominant operating system.

Application to AI: A cloud platform might bundle model access, proprietary orchestration tools, agent memory, and distribution services in ways that make competing models commercially unattractive.

A bundle is not unlawful simply because it integrates multiple functions. The question is whether the arrangement forecloses competition and lacks sufficient objective justification under the applicable rules.

8. Meta Platforms Inc. and Others v Bundeskartellamt

Citation: Case C-252/21, Court of Justice of the European Union, 2023.

Principle: The case examined the relationship between data processing, user consent, and competition-law enforcement concerning a dominant digital platform.

The judgment addressed how data protection rules interact with competition-law assessments of a platform's collection and combination of personal data.

Application to AI: A provider may claim that interoperability is restricted to protect privacy or prevent unauthorised transfer of personal data. Those interests can be legitimate, but they must be assessed against the actual technical and legal circumstances.

Conversely, access to data accumulated through a dominant ecosystem may contribute to competitive advantages that independent model providers cannot easily reproduce. Data protection law is neither a blanket exemption from competition law nor an automatic entitlement to receive another provider's data.

5. Current EU development: AI interoperability on Android

A particularly relevant development occurred on 16 July 2026, when the European Commission issued binding specification measures to Google under the Digital Markets Act. The measures address how competing AI services can obtain access to features controlled by Android, as well as conditions concerning access to Google Search data.

Digital Markets Act (DMA)

+1

The significance is that AI interoperability is no longer only a hypothetical extension of traditional software competition cases. It is now the subject of a specific regulatory process.

The Commission's approach illustrates three important principles:

Effective access: third-party AI services should be able to compete with the gatekeeper's own services on relevant platform capabilities.

Proportionate safeguards: interoperability measures may incorporate legitimate privacy and cybersecurity protections.

Transparent conditions: access terms and pricing should not undermine the effectiveness of the required interoperability.

Digital Markets Act (DMA)

+1

The measures concern obligations applicable to a designated gatekeeper and the specified services. They do not impose a universal duty on every AI developer to open its model to competitors.

6. German competition-law application

The German framework offers several avenues for examining restrictions in model ecosystems.

The Bundeskartellamt's proceedings involving large digital companies demonstrate the relevance of ecosystem power, self-preferencing, and the extension of market power across adjacent services. Its Meta proceedings, for example, addressed the linking of virtual-reality headsets with Facebook accounts.

Proceedings against Meta/Facebook

+1

For AI, the analogous question is whether a provider uses control over an operating system, cloud platform, distribution channel, or user-data infrastructure to restrict competition between models.

7. UK competition-law application

Under Chapter II of the Competition Act 1998, an AI provider's interoperability restrictions may be examined where the provider is dominant and the conduct amounts to an abuse.

Potentially relevant conduct includes:

Refusing access to an important interface in circumstances where the legal test for abuse is met.

Giving affiliated models preferential access to a distribution platform.

Imposing restrictive terms that substantially disadvantage rival models.

Tying cloud infrastructure to proprietary model services.

Using interoperability restrictions to reinforce switching costs and obstruct downstream entry.

Chapter I may be relevant where independent businesses agree to restrict compatibility or exclude competing model providers.

The DMCC Act 2024 adds an ex ante framework for firms designated with strategic market status. Where a relevant conduct requirement is imposed, the CMA can address the specified behaviour under that regime. The designation and the terms of the conduct requirement are crucial: not every AI company is subject to SMS obligations.

8. Illustrative hypothetical

Suppose AlphaAI operates a widely used mobile operating system, cloud service, and foundation model. It allows its own model to access device functions, user-authorised context, and agent tools. Competing models can run on the same device, but they are denied equivalent access to those functions.

The authority should investigate the following questions.

Step 1 — Market position

Determine whether AlphaAI is dominant or subject to an applicable gatekeeper or SMS regime. Examine alternatives, network effects, switching costs, and control over distribution.

Step 2 — Access comparison

Compare the capabilities, latency, data access, pricing, rate limits, and permissions available to AlphaAI's own model and to rival models.

Step 3 — Justification

Assess whether restrictions are necessary and proportionate to protect privacy, security, intellectual property, or system integrity.

Step 4 — Competitive effects

Examine whether rival models lose users, cannot develop viable services, or face higher costs because of the restrictions, and whether competition and consumer choice are harmed.

Step 5 — Appropriate remedy

Depending on the legal basis, consider documented APIs, fair access conditions, interoperability testing, non-discrimination safeguards, or a targeted prohibition of exclusionary terms.

If the evidence establishes an applicable infringement, the remedy should address the restriction without requiring unnecessary disclosure of model weights, training data, or unrelated confidential information.

9. Remedies and regulatory safeguards

Effective interoperability remedies should be designed around the source of competitive harm.

Regulators should avoid mandating identical model performance. Different models may have different capabilities, resource requirements, and safety architectures. The appropriate goal is to prevent unjustified exclusion, not eliminate legitimate technical competition.

10. Critical analysis

The central policy challenge is balancing open AI ecosystems against innovation incentives and legitimate control over proprietary technology.

Overly restrictive ecosystems can entrench gatekeepers, weaken multi-homing, and make independent AI developers dependent on a small number of infrastructure providers. Interoperability can reduce switching costs, encourage specialised model development, and allow businesses to combine services from different suppliers.

However, mandatory interoperability can also create risks. It may increase attack surfaces, expose confidential information, facilitate misuse, weaken safety controls, or impose costly engineering obligations on smaller developers. Requiring the disclosure of sensitive model internals could also reduce incentives to invest in research.

A sound framework should therefore distinguish between:

Basic functional interoperability — enabling systems to exchange information and perform agreed tasks.

Enhanced platform interoperability — providing access to operating-system functions, tools, or platform capabilities.

Data portability — enabling lawful transfer of user or business data.

Model disclosure — providing access to weights, training data, source code, or internal architecture.

These categories involve different technical and legal interests. A finding that one is necessary does not automatically justify the others.

11. Conclusion

Model-to-model interoperability constraints are an emerging competition-law issue at the intersection of platform governance, intellectual property, data access, cloud dependency, and AI innovation.

The most relevant authorities include Microsoft v Commission, Bronner, IMS Health, Slovak Telekom, Enel X v Google, the Google Android proceedings, and Meta Platforms v Bundeskartellamt. Together, they provide a framework for assessing refusal to interoperate, ecosystem tying, discriminatory access, and the interaction between competition and data protection rules.

The central legal test is not whether AI models are technically different. It is whether a provider with the relevant market power or regulatory obligations uses interoperability restrictions in a way that unlawfully forecloses competition, without adequate objective justification.