Chapters VII and VIII of the EU Data Act address interoperability — the ability of different cloud services, data services, and data spaces to work together without requiring customers to be permanently tied to a single vendor’s technical architecture. Interoperability has been a policy objective in EU digital regulation for years, but the Data Act translates it from an aspiration into a set of binding legal obligations for cloud providers, data space operators, and the broader ecosystem of data infrastructure companies.

For US technology companies building data infrastructure for EU markets, Chapters VII and VIII are not abstract regulatory goals. They impose concrete obligations around API documentation, technical standards adoption, and participation in the interoperability frameworks being developed under EU auspices. They also interact with the Digital Markets Act’s interoperability requirements for large platforms, creating an overlapping regulatory landscape that companies with significant EU market presence need to navigate carefully. This article explains what interoperability means technically and contractually under the Data Act, what the specific obligations are, how the governance framework for developing interoperability specifications works, and what US companies need to do to ensure compliance.

What Interoperability Means Under the Data Act

Interoperability is a word used in many contexts, and its meaning in the Data Act is specific enough to be worth defining carefully. In the context of Chapters VII and VIII, interoperability has both a technical dimension and a contractual dimension.

Technical Interoperability

Technical interoperability is the ability of two or more systems to exchange information and use the information that has been exchanged. In a cloud services context, this means that a customer should be able to use services from multiple providers in combination, without the providers’ technical architectures creating artificial barriers to integration. It means that data formats should be sufficiently standardized that data generated in one environment can be processed in another without extensive conversion work. It means that APIs should be documented and consistent enough that third-party developers can build integrations without reverse-engineering proprietary interfaces.

The Data Act’s technical interoperability requirements build on a concept from computer science: where two systems use compatible data models, communication protocols, and interface specifications, they are technically interoperable. Where one system uses proprietary, undocumented, or inconsistently implemented interfaces, it creates technical lock-in that prevents customers from combining services from different providers.

Contractual Interoperability

Contractual interoperability is the ability of cloud customers to use multiple providers without contractual barriers. Even if two systems are technically compatible, contractual terms can prevent a customer from using them together: exclusive use clauses, restrictions on data portability between competing platforms, or terms that prohibit the use of competing services can all create contractual lock-in that parallels technical lock-in. The Data Act addresses both dimensions, and compliance requires attention to contract terms as well as technical capabilities.

The Core Interoperability Obligations Under Chapter VII

Chapter VII establishes the primary interoperability obligations for cloud providers and operators of data spaces. These obligations are distinct from the switching requirements in Chapter VI, though they share the same underlying policy objective of reducing lock-in and enabling a competitive, multi-provider cloud market.

API Availability and Documentation

Cloud providers are required to make their APIs available and to document them sufficiently to enable interoperability with other services. This is a two-part obligation. The availability requirement means that the API must be technically accessible to third parties and to customers using multiple providers in combination. The documentation requirement means that the API must be described in sufficient technical detail — endpoints, authentication methods, data formats, request/response structures, versioning information, and error handling — that a competent developer can use it without proprietary assistance from the provider.

API documentation must be kept current and must reflect the actual behavior of the API, not an idealized or outdated description of it. A provider cannot satisfy the documentation requirement by publishing a specification that was accurate two years ago but no longer reflects the current API behavior. The documentation must be maintained as the API evolves, and customers and third parties must be notified of significant changes in sufficient time to adapt their integrations.

Interoperability with Other Services

Beyond API documentation, cloud providers must ensure that their services are capable of interoperating with other cloud services and with the data space infrastructure being developed under EU frameworks. This obligation requires providers to implement technical standards that enable interoperability, rather than designing their services in ways that make integration with other providers unnecessarily difficult.

In practice, this means providers should use open, standardized data formats wherever possible, implement standard communication protocols, and avoid designing proprietary extensions to open standards that introduce incompatibilities. Where a provider uses a proprietary format or protocol, it should document the conversion path to commonly used open standards so that customers and integration partners can work with the data.

Data Space Interoperability

Data spaces are a concept specific to the EU’s data governance architecture. They are federated, sector-specific infrastructures through which data can be shared across organizations while maintaining appropriate governance, access controls, and usage policies. The EU has invested significantly in developing data space governance through initiatives like Gaia-X, the International Data Spaces Association (IDSA), and the sector-specific data spaces funded under EU programs (including mobility, energy, health, agriculture, and manufacturing data spaces).

Chapter VIII of the Data Act addresses the interoperability requirements for data space operators and participants. Operators of data spaces must ensure that their technical infrastructure is compatible with the interoperability specifications developed under EU frameworks, and they must document the conditions under which other organizations can connect to and participate in their data space. This is directly relevant to US companies that want to participate in EU data spaces as either data providers or data consumers.

The European Data Innovation Board

The European Data Innovation Board (EDIB) is the governance body responsible for developing interoperability specifications under the Data Act and the Data Governance Act. The EDIB brings together representatives from Member State regulatory authorities, industry, civil society, and technical experts to develop the standards and specifications that will operationalize the Act’s interoperability requirements.

Understanding the EDIB’s role is important for US companies because it is through the EDIB process that the specific technical standards required for compliance will be defined. The Data Act itself establishes the high-level obligation to ensure interoperability; the EDIB’s work product will determine what specific standards, formats, and specifications must be implemented to satisfy that obligation.

The EDIB’s interoperability work is ongoing. As of the Act’s September 2025 applicability date, the EDIB had issued guidance and was in the process of developing formal interoperability specifications in several areas. The specifications for cloud-to-cloud switching interoperability, data space participation standards, and API documentation requirements are among the most actively developed areas. US companies should monitor EDIB outputs and engage with the specification development process where possible — participation in consultation processes provides advance notice of what will be required and the opportunity to influence technical specifications in ways that align with existing industry capabilities.

Open Standards and Their Role

The Data Act’s interoperability framework is grounded in open standards — technical specifications developed through open processes, freely available for use, and not controlled by any single vendor. The Act’s preference for open standards reflects a broader EU policy position that open, vendor-neutral standards create more competitive, innovative, and resilient digital markets than proprietary standards controlled by individual companies.

Several categories of open standards are directly relevant to the Data Act’s interoperability requirements.

Data Format Standards

For data exchange and portability, open standards like JSON (JavaScript Object Notation), Apache Parquet, OpenDocument formats, and sector-specific standards like HL7 FHIR for health data are relevant. The choice of appropriate data format standard depends on the type of data and the use case; the Act does not mandate a single format for all purposes, but it requires that formats used are open and documented.

API Standards

For API documentation and interoperability, OpenAPI Specification (OAS) is the dominant open standard for RESTful APIs. Providers that document their APIs using OAS can ensure that their documentation is machine-readable and can be processed by a wide range of standard developer tooling. GraphQL and gRPC each have their own open specification formats for providers using those paradigms. The Act does not mandate a specific API architecture, but the documentation must be in a form that enables independent integration, which OpenAPI-compliant documentation satisfies.

Security and Identity Standards

Interoperability in data environments requires not just data format compatibility but also compatible approaches to authentication, authorization, and identity management. Open standards like OAuth 2.0, OpenID Connect, and SAML 2.0 are widely used in enterprise cloud environments and support interoperability without requiring customers to use a single identity provider. Providers that implement these standards allow customers to use their existing identity infrastructure when connecting to the provider’s services from multiple environments.

Data Space Standards

For data space participation, the IDS-G (International Data Spaces Governance) standard published by the IDSA is among the most relevant technical frameworks. Gaia-X has developed its own technical specifications for federation, credential verification, and service description that are actively used in the EU data space ecosystem. Companies participating in EU data spaces should familiarize themselves with these frameworks, as they provide the operational vocabulary for interoperability in federated data environments.

Relationship to the Digital Markets Act

The Data Act’s interoperability requirements do not exist in isolation. They sit alongside the Digital Markets Act (DMA), which imposes its own interoperability obligations on designated ‘gatekeeper’ platforms. Understanding the relationship between these two frameworks is important for US technology companies that may be subject to both.

The DMA designates certain large platforms as ‘gatekeepers’ based on criteria around size, market impact, and entrenchment. As of 2025, the designated gatekeepers include the major US technology companies in search, social media, messaging, operating systems, and app stores. For these companies, the DMA imposes specific interoperability obligations that go beyond what the Data Act requires: for example, messaging interoperability obligations under DMA Article 7 require designated messaging gatekeepers to provide third-party messaging services with the technical means to interoperate with their platforms.

The Data Act’s interoperability obligations are broader in scope — they apply to all cloud providers and data space operators, not just designated gatekeepers — but they are less prescriptive in their technical requirements, relying more on the EDIB standard-setting process to define specific requirements. A company that is both a DMA gatekeeper and a cloud provider subject to the Data Act faces obligations under both frameworks, and the two sets of requirements need to be managed in coordination.

For most US cloud providers, the DMA gatekeeper designation will not apply. The designation thresholds are high, and the Commission’s designation decisions have focused on a small number of companies with dominant positions in specific markets. For providers that are not DMA gatekeepers, the Data Act’s Chapter VII and VIII obligations are the primary interoperability framework.

Compliance Timeline

The Data Act’s interoperability obligations became applicable in September 2025, alongside the Act’s other provisions. However, the practical implementation of interoperability requirements depends in part on the specification development work being done by the EDIB, which is an ongoing process. For obligations that depend on specific standards not yet finalized by the EDIB, the compliance timeline is tied to when those standards are published and a reasonable implementation period has elapsed.

For API documentation and open standards adoption obligations that do not depend on EDIB specifications — because adequate open standards already exist — the September 2025 applicability date is the compliance deadline. Providers that have been operating with poorly documented proprietary APIs are already in a period of potential non-compliance for those aspects of their services that are subject to the Act.

The staged nature of the EDIB specification process creates both a compliance planning challenge and an opportunity. The challenge is that companies do not always know in advance exactly what technical specifications will be required, making it difficult to plan engineering work. The opportunity is that companies can participate in the EDIB consultation process to influence what those specifications look like, and they can build for known open standards now — rather than waiting for EDIB outputs — knowing that the EDIB is unlikely to diverge substantially from established industry norms.

Practical Guidance for US Technology Companies

US technology companies building data infrastructure for EU markets need to approach Chapters VII and VIII as a combination of technical, contractual, and governance obligations.

API Documentation Audit

The first practical step is to audit existing API documentation for completeness, accuracy, and format. APIs that are undocumented, documented only in proprietary formats, or documented in ways that do not reflect the current behavior of the service need to be remediated. The remediation plan should prioritize APIs that are most relevant to interoperability — the APIs through which customers access and export their data, through which third parties build integrations, and through which the service interacts with other cloud or data space services.

Open Standards Adoption

Companies should assess where their current technical architecture uses proprietary formats or protocols where open standards are available. Where switching to open standards is technically feasible without disproportionate disruption, prioritizing that migration satisfies the Data Act’s interoperability requirements and also generally improves the service’s integration ecosystem. Where proprietary approaches are necessary for technical or business reasons, the company should document the conversion path to open standards and make that documentation available to customers and integration partners.

Data Space Participation

US companies that want to participate in EU data spaces as data providers or consumers need to implement the technical standards used in those data spaces. This currently means implementing the IDSA connector architecture or equivalent for data space connectivity, using Gaia-X-compatible service descriptions where required by the data space operator, and ensuring that their access control and data usage policy implementation is compatible with the data space’s governance framework. The specific requirements vary by data space, and companies should engage with the operators of the relevant sector data spaces directly to understand what is needed.

Contract Review

From a contractual perspective, companies should review their standard terms for clauses that restrict interoperability — prohibitions on connecting to competing services, restrictions on using data with third-party tools, or terms that prevent customers from building integrations using the provider’s documented APIs. Such clauses may conflict with the Act’s interoperability framework and should be removed or revised.

EDIB Engagement

US companies with significant EU market presence should consider engaging with the EDIB specification development process. The EDIB consults publicly on draft specifications, and industry participants can submit comments, request technical working group participation, and contribute to the shaping of interoperability standards. This engagement is particularly valuable for companies with advanced technical capabilities — their input can help ensure that EDIB specifications are technically sound and practically implementable. It also provides advance notice of what specific compliance requirements will look like, enabling better planning.

Coordination Between Data Act and DMA Compliance

For US companies that face obligations under both the Data Act and the Digital Markets Act, interoperability compliance efforts should be coordinated across both regulatory frameworks. Requirements that overlap — such as API documentation, data portability, and access to platform data for third parties — can often be addressed through a unified technical program rather than treated as separate regulatory workstreams. A coordinated approach is more efficient and reduces the risk of implementing solutions that satisfy one framework while inadvertently creating tension with another.

The Bigger Picture

Chapters VII and VIII of the Data Act sit within a broader EU vision of a data economy where data can flow freely across organizational and national boundaries, where interoperable infrastructure enables innovation across sectors, and where no single company can use technical lock-in to extract rents from an ecosystem it effectively controls. For US technology companies, this vision represents both a challenge and an opportunity.

The challenge is that compliance requires real engineering investment, attention to technical standards, and engagement with a governance process that is still actively developing its outputs. Companies that have relied on proprietary formats, undocumented APIs, or contractual restrictions to maintain customer relationships will need to change their approach. The opportunity is that a genuinely interoperable EU data infrastructure creates a larger, more accessible market for new entrants and specialized service providers. Companies that build to open standards and invest in interoperability will be able to participate in that market on more competitive terms than those that wait for the regulatory minimum to be enforced.