AIOTI views on the European Data Act

AIOTI published its views on the European Data Act, which is now in the legislative process of discussions between the Council of the European Union and the European Parliament.

The Alliance for IoT and Edge Computing Innovation welcomes the Data Act and its particular focus on IoT related data. We also appreciate the effort made by the European Parliament and by the Council to intervene on the Act to further strengthen its scope and vision.

It is the opinion of our members that some additional input might be required to clarify specific concepts on B2B data sharing, on cloud switching, on international transfers and government access, on interoperability, and on implementation and enforcement.

Chapters II and III – B2B data sharing

We welcome the Data Act’s B2B data sharing mechanisms, as we believe these have the potential to ease additional data flows, which will help to develop European competitiveness and an innovative data driven economy.

However, we think that additional clarity is needed on several elements, such as the concept of a data holder or the scope of the data to be shared and accessed by the user.

In general, setting different standards to define data holders for personal and non-personal data is neither appropriate nor justified. Therefore, Recital 24, which equates personal data holder to a data controller, and Article 2(6) which considers as a non-personal data holder any entity that has the technical ability to make data available, should use the same criteria. This will foster trust in data flows and technology and allow cloud vendors to implement the right safeguards to ensure that clients have control over their data (as required by Recital 78). Consistent with the above, Recital 21 should be clarified to ensure that cloud storage providers, who never act as data controllers, would also not function as data holders.

The current text provides for “necessary measures” to protect trade secrets and confidential business data that could lead to the revelation of trade secrets. Especially, in relation to third parties. In practice, this will lead to difficulties, especially in the case of medium-sized companies, which may end with the loss of valuable information and create new uncertainties and business risks for companies engaging in the data economy.

In fact, the Section 2 of the Explanatory memorandum of the proposal states: “The protection of confidential business data and trade secrets is an important aspect of the well-functioning of the internal market, as is the case for other contexts in which services are exchanged and goods are traded” by mentioning both the term “confidential business data” and “trade secrets” and not only the notion of trade secret.

It is true that in most cases these two categories will overlap. This being said, certain confidential business data may not qualify as trade secrets but may nevertheless warrant protection for instance when datasets that do not qualify as a trade secret individually, but when cross-referenced, would reveal trade secrets.

We would also point out that, in the EU, mechanical engineering industry is characterized by medium-sized companies. The requirements of the Data Act represent an unproportionate burden for the sector, but also in other sectors SMEs will face difficulties to cope with the additional burden, sometimes unnecessary, and to protect their know-how.

Finally, we would note that data space initiatives and data sharing models are launched, which are not only about technical interoperability, but also provide for data governance models, adapted in detail to the needs of a sector or a business ecosystem. One example would be Manufacturing-X which aims at creating a common data space for manufacturing. This will enable the easy and swift set-up of data exchange mechanisms by reducing the legal and technical transaction costs, whilst creating trust in the lawful use of data. There is the risk that the horizontal provisions of the Data Act are constraining the potentials of these data space arrangements.

Chapter VI – Cloud switching

In recent years, the strong growth of cloud computing has transformed traditional models of computing. When fully utilized, it enables levels of scalability, flexibility, and choice that cannot be readily matched using a traditional on-premises IT stack. However, enterprises have been held back from migrating certain complex and sensitive workloads to the cloud due to interoperability, portability, security, and regulatory concerns.

Under a hybrid cloud model, workloads are deployed on a combination of private cloud and public cloud, often in conjunction with a traditional on-premises stack. This allows an enterprise to keep critical applications or sensitive data on-premises while reducing costs and enhancing efficiency by migrating other workloads to private or public clouds.

Multi-cloud architectures involve the use of cloud computing and storage services supplied by multiple providers to eliminate reliance on any single cloud provider (a mono-cloud approach). This enhances business continuity and security and is particularly valued for mission-critical workloads and customers in sensitive sectors such as banks and governments. A typical multi-cloud implementation utilizes two or more public clouds as well as multiple private clouds in a heterogeneous architecture.

The Data Act requirements on Cloud switching should be targeted at avoiding vendor lock-in, while keeping the right balance between clients’ and providers’ operational responsibilities. These provisions must account for the practical and technical complexity of moving workloads while preserving customers’ needs to be supported in their transitions, and in general, strike the right balance between customer choice, competition and technical aspects.

The other elements of concern we have identified are as follows:

1- Fixed term contracts – Article 23.1(a) provides that the customer may at any time terminate the contract with a maximum notice period of 30 days. This provision, read in conjunction with Article 25, seems to end the well-established practice of fixed term contracts, which feature lower prices and enable both customers and providers to manage and plan their costs, revenues and investments. The benefits of such contracts are hence shared by cloud providers and their customers alike. Customers can deploy cloud solutions at a lower cost, and cloud providers can predict budgets and invest funds into innovation, R&D, compensation of employees, etc. An absolute right to terminate cloud contracts at any time would undermine parties’ decision to enter into fixed term contracts, resulting in increased prices for customers, and fewer options for cloud providers to invest in innovative products and services.

2- The timelines set by Chapter VI to switch from one provider to another also need to be re-examined. To allow for a workable, stable and smooth migration, customers should provide termination notices a minimum of 30 days before the switching process can start, to allow the incumbent provider to prepare the switching process. Only at the end of the switching process should the contract be terminated (contrary to the current wording of Article 23.1(a)). Also, if a provider can prove that limited timelines for a migration process are “technically unfeasible”, it is in the interest of service and business continuity that this process should be prolonged for as long as necessary to become technically feasible to complete the migration, and not only for 6 months. (Art. 24.2).

3 – The obligation for a Cloud service provider to ensure service continuity in Art. 24.1(a)(2). Even in traditional outsourcing contracts, which are subject to lengthy negotiations, clients/users and providers agree on specific service level agreements that providers must comply with during the termination assistance phase, where providers help clients to migrate their workloads to another provider. The service levels agreed therein never foresee a 100% service continuity, as parties understand and agree that the service will not be the same during a termination phase as during the operational phase of the contract. Parties also know that business and service continuity is better guaranteed through collaboration between the service providers (both the incumbent and new service provider) and the client, rather than through shifting obligations onto the incumbent provider.

4 – Scope of the porting obligations – Article 24.1(b) contains a sweeping, all-encompassing obligation to port “at minimum” all (i) data imported by the customer at contract start; and (ii) all data and (iii) metadata created by the customer and by the use of the service. While there is no doubt that data imported or created by the customer should be exportable, the need to port all metadata is questionable. The broad scope of Article 24.1(b) may result in overloading the switching process, and therefore jeopardise the success of these sometimes-complex projects.

5 – Functional equivalence Articles 26.1 and 2.16 set an obligation of result for the incumbent IaaS provider to ensure the same service parameters in the environment of one of its competitors. This is confusing, legally, operationally and technically. It is indeed hard to understand what is precisely expected from the incumbent provider. In other words, how is it envisaged that a provider will ensure the same level of security and performance, and even more so the same quality of service, output and performance in the environment of one of its competitors?

Should the incumbent provider have access to its competitors’ environment? If so, how can the new provider ensure security of its environment? Or should the incumbent provider compare service level agreements? Should it audit the environment of the new CSP? Or is it just jointly liable for an area over which it has no control?  And what happens if the customer does not contract the same level of service because it deems it doesn’t need the same level of service?

Also, functional equivalence as envisaged could eliminate competitive advantages that IaaS providers use to differentiate, because:

– it forces CSPs to share intellectual property, trade secrets, and other competitive advantage with competitors, to ensure they are able to provide the same function/capabilities; and

– it incentivizes clients to select the cheapest service available given their former provider is responsible to ensure they benefit from the same service parameters (such as security, features, availability, etc.), thereby blocking innovation, optimization and differentiation.

We believe that to achieve interoperability in the IaaS sector, (i) the scope of any potential functional equivalence requirements should be agreed with the customer in the contract; (ii) interoperability and any functional equivalence related thereto should be a joint task for both the incumbent and the new provider; and (iii) providers should not be performing work outside their environment.

6- Open interfaces Article 26(2) sets an obligation for providers of data processing services that are not IaaS to adopt open interface publicly available and free of charge. However, the current wording of the text could lead to diverse interpretations of what constitutes “open interfaces” and lead to the adoption of interfaces with extremely different degrees of openness and therefore would not reach the announced target of solving the lock in, problem cloud customers are facing on the European market.

Therefore, a definition of “open interface” is also needed to better understand how those obligations will be applied. Currently a few cloud services are already characterized by full competition (i.e., no lock in, no lock out and fair contractual practices). Therefore, clarifying the meaning of open interfaces could also provide clarity on the regulatory treatment of those specific service types.

In addition, open interface being publicly available is a key element to ensure fair competition between cloud providers and avoid that gatekeepers could lock our European small software providers to access cloud infrastructure and develops new services and sell innovative cloud solution on the European market.

6 – The financial restrictions of Art. 25 also raise questions: if additional obligations and responsibilities are imposed on a Cloud provider when a client terminates a cloud contract, should these be provided at cost for 3 years and then for free (resulting in the provider making a loss)? This would be especially unreasonable if the contract is terminated due to the customer’s breach.

We believe the objective should be that customers be made aware of what it would cost them to enter into a specific contract. Customers are able to review the relevant information to calculate the total cost of ownership (TCO) of selecting a specific vendor over another. Therefore, it would be fairer to all if the costs were transparent and communicated well in advance rather than asking providers to not invoice the switching services they provide.

Chapter VII – International transfers and government access

Regulation should strive to solve conflict of laws, not reinforce them, and we believe conflict of laws should be solved through multilateral government talks, not by one government regime imposing unilateral requirements on a specific sector.

Personal data and non-personal data are different in nature, requirements and legal mechanisms and these differences should be accounted for in policies addressing international transfer of data and government access to data.

GDPR clearly sets forth conditions for lawful cross-border transfers, and thereby creates certainty, whereas Recital 77 contains a reference to a broad list of rules applicable throughout Europe and in the Member States and therefore creates ambiguity.

Cloud users, unlike cloud providers, know their data. Practically this means users know whether their data is subject to trade secrets, IPRs, national security schemes or other Union or Member State law. Cloud providers typically do not have access to data stored or hosted on behalf of their clients and are not able to determine what legal restrictions may apply to the data that they are processing. Similarly, they do not have sufficient visibility of the laws and surveillance practices employed by sovereignty governments outside the EU that could result in unlawful data access. Therefore, in practice, these providers will have no way to comply with Article 27.1.

The “data holder” is a defined term under Article 2(6) of the Data Act and refers to the entity that must share data under Chapters II and III of the Act. Therefore, it seems that this term should not be used in Article 27, as this would cause confusion.

Chapter VIII – Interoperability

Article 28 sets forth essential requirements regarding interoperability for operators of data spaces.  It is therefore of paramount importance to define which entities are “operators of data spaces”. Platforms that serve to exchange data should not be subject to these requirements by default. For example, some platforms used today work very well to exchange data, and these platforms are not Blockchain enabled as required by Article 28.1(d).

These requirements however all make sense for the well-defined upcoming Common European data spaces.

Article 30 sets forth essential requirements regarding smart contracts for data sharing. The essential requirements of Article 30.1(b) and (c), as they relate to termination and interruption of smart contracts, data archiving and continuity, would best be applied to smart contracts that allow the exchange of value or assets such as cryptocurrencies. The rationale is that the requirements on termination and interruption of smart contracts set forth in Art. 30.1(b) aim to address issues and disputes that could financially harm a Blockchain participant.

Also, archiving data for continuity purposes as required under Art. 30.1(c) will serve auditability and dispute resolution objectives, which again are useful in the framework of exchanging values or assets and are not required for other types of smart contracts, such as those deployed in member only Blockchain enabled platforms.

There is no doubt that access control mechanisms as referred to in Article 30.1(d) should be implemented. However, their level of implementation will depend on the type of smart contract, and hence on the access controls necessary for that specific smart contract (i.e., the specific Blockchain application). For example, in the case of a permissioned Blockchain that only the members of the application are entitled to enter, access control is inherently imposed. But if the purpose and use of the Blockchain application is to share information with a wide audience, access controls may not be required. Therefore, the requirement that “access control must be protected at the smart contract layer” is problematic and should be removed.

Chapter IX – Implementation and Enforcement

In the Commission proposal, enforcement is done by Data Protection Authorities, and authorities to be set up by Member States (incl. to enforce the cloud switching requirements of Chapter VI). At the same time, it is stated that “the authority of sectoral authorities shall be respected”, but it is not clear whether this mean they should be involved, consulted or competent.

We caution against this framework, which will undoubtfully lead to fragmentation and call for competence of a pan-European enforcement body, responsible to provide official interpretation of the regulation, while the national supervisory authorities’ guidance should not be binding. Also, we urge lawmakers to think of other ways to further avoid fragmentation, such as a one-stop-shop mechanism with one lead authority, or the implementation of a specific unit within the national Data Protection Authorities, responsible for issues related to, non-personal data sharing. This could be more efficient than assigning competence to separate bodies, because in any event, DPAs will be competent for matters related to mixed data sets.