A right with no SDK
Since 12 September 2025, the user of a connected product in the EU can ask for the data that product generates.
Interface
Who builds it?
The regulation grants a right. It ships no API.
Identity
Who authenticates the asker?
Proving that a person owns a machine is not a solved problem.
Evidence
Who keeps the proof?
An obligation you cannot show you met is one you failed.
Expiry
Who revokes it?
Every grant needs an end date. Most designs forget it.
Data Act, Art. 4 and 5 · Art. 50 application date · eur-lex.europa.eu/eli/reg/2023/2854/oj
The Data Act gives the users of connected products (a car, a tractor, a smart meter, an industrial robot) a right to access the data their use of the product generates, and to have it shared with a third party of their choice. It has applied since 12 September 2025 (Article 50).
The four questions on the slide are not legal questions. No article tells you how to authenticate the person asking, where the evidence of a disclosure is kept, or when a delegation expires. They land on an engineering team. That gap between a right and its implementation is the subject of this hour.
Notice the chain behind the first question: the manufacturer, its supplier, its cloud provider, its contract manufacturer in another jurisdiction. Responsibility is legal; the work is distributed.
Where the data comes from
Photo: Benoît Prieur, CC0, Wikimedia Commons A smart meter: consumption, every half hour. Photo: City of Detroit, CC0, Wikimedia Commons A connected car: position, speed, faults, alerts. Photo: Chris Woodrich (Crisco 1492), CC BY-SA 4.0, Wikimedia Commons A wind turbine: vibration, yield, maintenance.
Data Act: Art. 2(5) connected product · Art. 2(6) related service · Art. 4 user access
Three ordinary machines. Each one produces data through its use: a meter's consumption curve, a car's position and fault codes, a turbine's vibration and yield. Until now, that data went to the manufacturer or to the operator of the related service, and the user saw what the app chose to show.
Since 12 September 2025, the person who uses the product can ask for that data, and have it sent to a third party of their choice. Keep these three pictures in mind: every case in this lecture ends up on a machine like one of them.
The argument of this hour
Every new right of access the EU creates is a new interface. Every new interface is a new attack surface.
So the Data Act is not only a legal text. Read closely, it is an architecture specification with a compliance deadline attached.
This is the claim the rest of the lecture tries to earn. The GDPR already taught the lesson: the right of access (Article 15) and the right to data portability (Article 20) created subject access pipelines, and attackers learned to use them, for instance by impersonating a data subject to obtain someone else's data.
The Data Act creates access rights over machine-generated data, at a far larger scale, with industrial systems attached. Three cases below show where this is already true, and four failure modes show where it breaks in production.
How to read these slides
What the text says
Aa
Obligations and rights, paraphrased from the regulation. Set in a serif, like a statute.
Providers shall take measures to prevent unlawful access.
What someone builds
Aa
The engineering reading: components, controls, evidence. Set in a typewriter face, like code.
Key custody, refusal workflow, request log.
What you can cite
Aa
Articles, regulation numbers and dates, in a boxed blue tag, ISO dates so they sort. Check them yourself.
Art. 29(1) 2027-01-12
The engineering column is a practitioner's reading, not legal advice. When the two disagree, the text wins.
This class mixes two disciplines that read the same regulation very differently. To keep them apart on screen, every slide uses the same convention: serif type for what the legal text says, sans-serif for the engineering consequence, typewriter type for anything you can look up and cite.
The legal sentences are paraphrases, kept close to the text. Before quoting any of them in an assignment, read the article in the Official Journal: Regulation (EU) 2022/868 for the Data Governance Act, Regulation (EU) 2023/2854 for the Data Act.
Your guest lecturer
Sitraka Forler
A practitioner who reads regulations from the engine room.
Data and AI practitioner in Luxembourg: data platforms, machine learning, systems architecture Lecturer at IAE Metz and at Centrale Méditerranée (Centrale Marseille) Columnist, AGEFI Luxembourg
Presented in a personal capacity. Nothing here represents the position of any employer, and none of it is legal advice.
Connect on LinkedIn · linkedin.com/in/sitraka-matthieu-forler
I build and run data systems for a living, and I teach machine learning and data analytics to engineering and management students. That is the angle of this hour: not what the regulation means for a court, but what it asks a team to build, operate and prove.
Everything in this deck is my own reading, in a personal capacity. For a real decision, read the article and ask counsel.
In my own name
I speak in my own name only, not on behalf of my employer.
These slides are my reading as a practitioner. They are not legal advice, and they commit no organisation I work with.
One sentence before the content, because this room mixes lawyers and engineers and some of you will quote me. Everything in this hour is my own reading, given in a personal capacity. It does not represent the position of my employer or of any client, and it is not legal advice: for a real decision, read the article in the Official Journal and ask counsel.
Picking up from the 14:15 presentation
Photo: Cayambe, CC BY-SA 3.0, Wikimedia Commons
Group 4 asked: to what extent do the Data Governance Act and the Data Act strengthen the EU's competitiveness, innovation capacity and digital sovereignty?
Their answer: necessary, but not enough.
This hour starts where their recommendation 5 ends: “ask which law can reach the data and who can switch it off.” That is an engineering question.
The Kirchberg plateau, seen from Pfaffenthal: the European institutions, and today's campus.
Group 4 opened the class at 14:15 with this question and this answer. Quote them, credit the group, then hand over: their last recommendation is where this lecture starts.
Points to clarify, kindly, in the questions. (1) “Data Act (2024)”: it is Regulation (EU) 2023/2854, adopted in 2023, in force since 11 January 2024, applicable since 12 September 2025; the syllabus says 2024, so nuance rather than correct. (2) Their slide 35, “€829 bn expected in 2020”: that is the projection made in 2020 for 2025. (3) Their slide 33, the Brussels effect: real for the GDPR, too early to say the DGA and the Data Act are copied worldwide. (4) Their slide 33, “the DGA calls this open strategic autonomy”: ask for the recital number; the phrase comes from the Commission's trade policy. (5) Their slide 41, “15 % since 2022 despite the switching rules”: the rules apply only since September 2025 and charges reach zero in January 2027; their own slide 35 says it is too early to measure.
Questions for the group, each one leads into this lecture. Which indicator would prove in 2028 that the Data Act worked? A provider receives a CLOUD Act order and is bound by Article 32: what does it do, concretely? For the car, where do they draw the line between raw and derived data? Their recommendation 1 is “one rulebook until 2028”: are they against the Omnibus?
Bridges, on yellow notes in the deck: their slide 27 to switching (slides 20 to 25); their slides 37 and 38 to Article 32 (26 to 28); their slides 24 and 29 to product data (29 to 31); their slide 41 to the Omnibus (17); their recommendation 5 to the checklist (37). Our figures agree with theirs: 38 intermediaries, 7 altruism organisations, AI Omnibus dates of December 2027 and August 2028.
Timing: they covered Chapters II to IX in detail (their slide 23). Part 1 shrinks to about five minutes; the ten minutes saved go to the three cases.
This afternoon
Time Part Length 15:30 Why an engineer is reading two regulations 15:37 The two instruments, in engineering terms 15:42 Three obligations turned into architecture 16:14 Where it breaks in production 16:30 Your questions, including the ones I cannot answer
Interrupt at any point. A question asked when it occurs to you is worth three asked at the end.
Four parts, then the questions. Questions are welcome during the lecture too: a question asked when it occurs to you is worth three asked at the end.
The two instruments, in engineering terms
By the end of this part you should be able to say what each text makes somebody build.
Five minutes only: Group 4 presented both texts in detail at 14:15 (their slide 23 lists Chapters II to IX). Go fast through the next slides; the aim is one sentence per text, what it makes somebody build. The time saved goes to the three cases.
Two texts, two different jobs
Data Governance Act 2022/868 Data Act 2023/2854 In force 2022-06-23 2024-01-11 Applies 2023-09-24 2025-09-12 Posture Enabling: creates roles and a trust framework Prescriptive: creates rights and hard obligations Real question Who may act as a trusted go-between? Who may read, move and port machine data? Status Proposed for repeal Applies Amendment proposed Luxembourg Law of 19 December 2025: CNPD supervises intermediation and altruism Bill 8809 , pending: ILR leads, CNPD for personal data
DGA Art. 38 · Data Act Art. 50 · repeal proposed in COM(2025) 837 · eur-lex.europa.eu
The row that matters is posture. The Data Governance Act is permissive: it offers a status (data intermediation service, data altruism organisation) with conditions, and almost nobody was forced to do anything. That is why, as engineering work, it changed little in most organisations.
The Data Act is the opposite. It tells manufacturers, cloud providers and data holders what they must now make possible, whether they want to or not. That is why it has a budget line.
In Luxembourg, the Data Governance Act is implemented by the law of 19 December 2025 (bill 8395A): it creates the Commissariat du Gouvernement à la souveraineté des données for the re-use of protected public data, and makes the CNPD the authority for data intermediation services and the register of data altruism organisations. The Data Act implementing law is bill no. 8809, filed on 28 July 2026 and still in committee: it designates the Institut Luxembourgeois de Régulation (ILR) as competent authority and data coordinator, the Commissariat for Chapter V, the CNPD for personal data, and sets fines in tiers up to one million euros. Source: Chambre des Députés, dossiers 8395A and 8809.
Dates: the Data Governance Act entered into force on 23 June 2022 and applies from 24 September 2023 (Article 38). The Data Act entered into force on 11 January 2024 and applies from 12 September 2025 (Article 50).
Six years, seven dates
Photo: Benoit Brummer (Trougnouf), CC BY 4.0, Wikimedia Commons
2020-02-19
Strategy for data
Nine data spaces announced
Photo: Pigranelle, CC0, Wikimedia Commons
2023-09-24
DGA applies
Intermediaries, altruism
Photo: Benoît Prieur, CC0, Wikimedia Commons
2025-09-12
Data Act applies
Access, sharing, switching
Photo: Sanzzu, CC BY-SA 4.0, Wikimedia Commons
2026-09-12
Access by design
For products placed on the market after this date
Photo: Cayambe, CC BY-SA 3.0, Wikimedia Commons
2026-10-20
Today
Class 5, Kirchberg
Photo: Derrick Coetzee, CC0, Wikimedia Commons
2027-01-12
Switching charges end
None after this date
Photo: GillyBerlin, CC BY 2.0, Wikimedia Commons
2027-12-02
AI Act, high-risk
Annex III; Annex I from 2028-08-02
COM(2020) 66 · DGA Art. 38 · Data Act Art. 50, 29(1) · Reg. (EU) 2026/1744
Six years in seven dates. The Commission's European strategy for data of 19 February 2020 announced nine common European data spaces. The Data Governance Act applies since 24 September 2023 (Article 38), the Data Act since 12 September 2025 (Article 50), and its access-by-design obligation for products placed on the market after 12 September 2026. Switching charges must disappear on 12 January 2027 (Article 29(1)).
The last mark is the AI Act as amended by Regulation (EU) 2026/1744: high-risk obligations for Annex III systems from 2 December 2027, for Annex I products from 2 August 2028. Each photo is credited on the slide.
The numbers to remember
Photo: Steve Jurvetson, CC BY 4.0, Wikimedia Commons
9
common European data spaces in the 2020 strategy
COM(2020) 66
30 days
maximum transitional period of a cloud switch
Art. 25(2)(a)
84 days
from today until switching charges must end
Art. 29(1)
19
ICT providers designated critical under DORA, 18 November 2025
ESAs
Four numbers, all from official sources. Nine: the data spaces named in the 2020 strategy (COM(2020) 66). Thirty days: the maximum transitional period a cloud contract must provide for (Article 25(2)(a) of the Data Act). Eighty-four days: from 20 October 2026 to 12 January 2027, when switching charges must end (Article 29(1)). Nineteen: the ICT third-party providers the European Supervisory Authorities designated as critical under DORA on 18 November 2025.
The text, and the explanation of the text
Screenshot of eur-lex.europa.eu, 17 October 2026 · © European Union, reuse authorised (Decision 2011/833/EU) EUR-Lex: Regulation (EU) 2023/2854, OJ L of 22.12.2023, its ELI and the authentic PDF in 24 languages.
Screenshot of digital-strategy.ec.europa.eu, 17 October 2026 · © European Union, reuse authorised (Decision 2011/833/EU) The Commission's Data Act page: FAQ, helpdesk, explainers. Useful, and not binding.
Cite the regulation by its ELI: eur-lex.europa.eu/eli/reg/2023/2854/oj · Commission FAQ, version 1.4 of 2026-01-22
Two pages you will use all the time, and they do not have the same status. On the left, EUR-Lex: the regulation as published in the Official Journal, with its European Legislation Identifier (ELI) and the authentic PDF in every official language. That is the text a court reads.
On the right, the Commission's Data Act page, with frequently asked questions (first published on 6 September 2024, version 1.4 of 22 January 2026), a legal helpdesk opened on 16 December 2025, and explainers. The model contractual terms and cloud clauses of Article 41 are still a draft, published in English on 19 November 2025. They are very good for understanding the intent, and they bind nobody. When an engineering decision rests on a sentence, check that the sentence comes from the left-hand page.
The Data Governance Act creates three roles Re-use of protected public data Ch. II Public bodies may open data that is confidential, commercially sensitive or personal, under conditions.
You build Secure processing environments, anonymisation pipelines, an access workflow with an audit trail.
Data intermediation Ch. III A notified, supervised status for neutral go-betweens matching data holders and users.
You build Structural separation: the broker may not use the data it brokers. An isolation boundary you must prove.
Data altruism Ch. IV A register for organisations collecting data donated for objectives of general interest, such as research.
You build Granular, revocable consent, and a record of the purpose each record was donated for.
DGA Art. 3 to 9 · Art. 10 to 15 (Art. 12 conditions) · Art. 16 to 25 · Art. 31
Every legal role has an engineering consequence. Structural separation is the interesting one for a security audience: it is not a policy you write, it is an isolation boundary you have to demonstrate. Article 12 requires the intermediation service to be provided through a separate legal person, and the provider may not use the data for other purposes. In practice: separate credentials, separate stores, separate staff, and an auditor who will ask you to show that an engineer on the brokerage side cannot read the brokered payloads. That is a threat model, not a privacy notice.
Uptake of the intermediation status has been low across the EU, which is one of the reasons the Commission proposed to fold this text into the Data Act (two slides on).
Article 31 of the Data Governance Act already contains safeguards against unlawful access by third-country authorities to non-personal data. You will meet the same logic in Article 32 of the Data Act.
The Data Act, read as a backlog
Where What it grants What somebody builds Ch. II Users access the data their connected product generates, and share it with a third party An authenticated access interface, by design, documented before sale Ch. III Fair, reasonable and non-discriminatory terms for making data available Metering, pricing logic, trade secret protection around the payload Ch. V Public bodies may request private data in exceptional need An escalation path, a legal gate, extraction that does not hand over everything Ch. VI Customers may leave a cloud provider with their data and functions Export formats, functional equivalence, a tested exit runbook Art. 32 Safeguards against unlawful third-country access to non-personal data Key custody, jurisdiction mapping, a documented refusal procedure Ch. VIII Interoperability of data spaces; rules for smart contracts Published schemas, and a way to stop automated execution
Three rows deserve attention. Chapter II: "by design, documented before sale" is the expensive phrase. The obligation lands at product definition, not at a compliance review two weeks before launch. Under Article 3(1), it applies to connected products and related services placed on the market after 12 September 2026 (Article 50).
Chapter VI, switching: this is the row with a date on it, twelve weeks from today (case one). Article 32: the sovereignty row, and the only one that can put an engineer in a genuine conflict of laws (case two).
The right-hand column is an engineering reading of the text, not the text. Unfair contractual terms (Chapter IV) are left out of the table: little engineering, large commercial impact. Smart contracts for executing data sharing agreements must, among other things, allow safe termination or interruption (Article 36).
One of the two texts is proposed for repeal
Date Step What happened 2025-11-19 Commission proposal The Digital Omnibus, COM(2025) 837, would repeal the DGA and move intermediation and altruism into the Data Act. 2026-06-22 Parliament draft report Joint ITRE and LIBE committees; amendments tabled in July. No committee vote yet. 2026-10-20 Today A proposal, not law. The DGA and the Data Act both apply as published. 2026-10-21 Council mandate On the Coreper agenda for tomorrow. No mandate adopted so far, no trilogue.
Build capabilities, not article numbers.
Check the procedure file before citing a status: oeil.secure.europarl.europa.eu · 2025/0360(COD)
Group 4 · their slide 41 The data Omnibus is stuck in Council. Same reading here: Coreper meets tomorrow.
The syllabus says Data Governance Act 2022 and Data Act 2024, and that is correct today. But the Commission's Digital Omnibus proposal of 19 November 2025, COM(2025) 837, would repeal the Data Governance Act (together with the Free Flow of Non-Personal Data Regulation, keeping its ban on data localisation requirements, and the Open Data Directive) and move intermediation and altruism into a new chapter of the Data Act, with voluntary registration. Business-to-government access in Chapter V would be narrowed to public emergencies, and custom-made cloud services and smaller providers would get a lighter switching regime for contracts concluded before 12 September 2025.
State of play on 17 October 2026, from the Legislative Observatory and the Council register: the joint ITRE and LIBE draft report is dated 22 June 2026, amendments were tabled on 27 July, and the committees have not voted. In the Council, no negotiating mandate has been adopted; the Coreper agenda of 21 October 2026 lists the mandate for negotiations. It is a proposal, not law.
The engineering conclusion: a compliance architecture that hard-codes one text is technical debt with a legal name on it. What survives a rewrite is the capability: can you identify your data, can you move it, can you prove who touched it.
Check the procedure file, not the press
Screenshot of the Legislative Observatory, European Parliament, 17 October 2026 · © European Union Status: awaiting committee decision. Below the title, every act the proposal would repeal or amend.
One proposal, many texts: it would repeal Regulation 2022/868 and amend the GDPR, NIS2, DORA and the Data Act.
A status in a slide ages in a week. The procedure file is the source.
This is the page I read before each update of this deck. The status line says where the file stands: on 17 October 2026, awaiting a committee decision in Parliament. Under the title, the list of acts the proposal touches is itself a lesson: it would repeal the Data Governance Act, the Free Flow of Non-Personal Data Regulation and the Open Data Directive, and amend, among others, the GDPR, NIS2, DORA and the Data Act.
Press articles are useful to know that something moved. The procedure file and the Council register tell you what actually moved.
Three obligations turned into architecture
Cloud switching. Foreign government access. Access to product data.
Thirty-two minutes, ten more than planned, taken from Part 1. Three cases: cloud switching (Chapter VI of the Data Act), foreign government access (Article 32), access to product data (Chapters II and III). Each case goes from the text to the system it requires, and each picks up one point from Group 4.
Case 01: the exit
Photo: Andrepaul, CC BY-SA 4.0, Wikimedia Commons
A data centre at Bissen, Luxembourg (LuxConnect): where a workload physically runs.
First case: a company decides to leave its cloud provider, or simply needs to be able to. The question is concrete: what can we take with us, how long does it take, and what does it cost. The Data Act answers part of it in Chapter VI, with dates.
The left photo is a Luxembourg data centre at Bissen, run by LuxConnect, the kind of building where regulated workloads of the financial centre actually sit. The right one is the inside of any data centre: cables, racks, and a dependency graph nobody drew completely.
Leaving your cloud provider should cost nothing
Photo: Derrick Coetzee, CC0, Wikimedia Commons
202784 days from today
From this date, providers of data processing services may not impose switching charges on a customer who leaves.
Art. 29(1) · paraphrase
Until then, charges are capped at the provider's costs directly linked to the switching.
Art. 29(2) and (3)
Racks and cables: the easy half of an exit is moving bytes; the hard half is everything wired around them.
Group 4 · their slide 27 €0 switching charges from 12 January 2027. Here: what export and egress must look like.
Article 29 phases switching charges out. From 11 January 2024 to 12 January 2027 a provider may impose reduced switching charges, which may not exceed the costs incurred by the provider that are directly linked to the switching process. From 12 January 2027 it may impose none. This is not a consultation or a guideline: it is a dated provision in a regulation that already applies.
Two nuances. The regulation distinguishes switching charges from the ordinary price of the service, which stays. And the Omnibus proposal would carve some custom-made services under contracts concluded before 12 September 2025 out of certain switching duties.
A question to keep in mind: who in this room has moved a production workload between two cloud providers, and how long did it take?
The switching clock
2024-01-11 2025-09-12
2026-10-20 2027-01-12
Entry into force The Act applies Today Charges fall to zero
Charges may not exceed directly linked costs.
Contracts state the switching process, the assistance owed, the transition period.
Eighty-four days left.
The lock-in that paid for a decade of shortcuts stops working.
Transition
30 days
maximum transitional period in the contract Art. 25(2)(a)
Notice
2 months
maximum notice period for the customer Art. 25(2)(d)
Parallel use
at cost
egress charges may only pass on costs incurred Art. 34
In parallel Financial entities already owe exit strategies under DORA Art. 28(8) . Same engineering, two legal drivers.
The timeline reads left to right. The third mark is today: eighty-four days between this lecture and 12 January 2027. Since 12 September 2025, the contract must describe the switching process, the assistance owed, and a maximum transitional period of 30 calendar days, with a notice period of at most two months for the customer (Article 25).
In Luxembourg the last line matters most. Banks, fund administrators and other financial entities are also under DORA (Regulation (EU) 2022/2554), which requires exit strategies for ICT services supporting critical or important functions (Article 28(8)). In practice you will meet one project with two regulators behind it.
A contested question worth arguing about: who benefits most from free switching? Customers, obviously. But also the largest providers, who can afford to absorb the cost of winning somebody else's customer. Regulation does not always move power where it intended.
What the providers already offer
Provider When you leave Conditions AWS Free data transfer out to the internet, as credits; for EU customers, an EU Data Act Addendum Support request; addendum: 2 months' notice, 30-day transition Google Cloud Free network data transfer when leaving; no-cost multicloud transfer for EU and UK customers Terminate and migrate within 180 days; Data Transfer Essentials, Sept. 2025 Microsoft Azure Free egress over the internet when leaving; at-cost transfer for parallel use in the EEA Support request, 60 days; some network services excluded
Free, on request, with conditions: read the terms, not the announcement.
aws.amazon.com, updated 2026-10-08 · cloud.google.com · learn.microsoft.com
The three largest providers did not wait for 12 January 2027. AWS waives data transfer out to the internet for customers who leave, as credits after a Support request; its blog post, updated on 8 October 2026, says this follows the direction set by the Data Act, and EU customers are pointed to an EU Data Act Addendum with a two-month notice and a 30-day transitional period. Google Cloud has offered free network data transfer for customers leaving since January 2024, with an exit to complete within 180 days, and since September 2025 a no-cost multicloud transfer for EU and UK customers, built in response to the Data Act. Microsoft offers free egress over the internet for customers leaving Azure, through a Support request within 60 days, with some network services excluded, and at-cost transfer for parallel multicloud use for EEA customers.
None of these pages announces anything specific for 12 January 2027: that date comes from Article 29(1) of the regulation. Engineering point: every waiver runs through a support ticket and a deadline, so the exit runbook must include the commercial steps, not only the technical ones.
What "reversible" costs Data is the easy half Open, documented, machine-readable exports. Not a proprietary dump that only the vendor can restore.
Functions are the hard half Managed queues, identity services and serverless runtimes rarely have an equivalent elsewhere.
The runbook must be tested An exit plan never executed is a document, not a capability. Rehearse it yearly on one workload.
Observability is the blind spot Dashboards, alert rules, traces and retention live in the provider's tooling. You arrive blind.
If the contract ended in ninety days, what could we not rebuild?
Data Act Art. 30 functional equivalence (infrastructure services) and open interfaces
The Data Act asks infrastructure providers (IaaS) for functional equivalence after switching (Article 30(1)), and asks providers for exportable data in structured, commonly used and machine-readable formats. Data is the easy half. Functions are harder: a proprietary queue, identity service or serverless runtime has no drop-in equivalent.
The part most migrations forget is telemetry. You can move a workload in a weekend. Rebuilding the alert rules, dashboards, trace sampling and retention policies that tell you the workload is healthy takes months, and until then you are operating a critical system without instruments.
An exit capability is also a security control: it bounds the blast radius of a supplier failure or a jurisdictional shock.
Terraform: the exit, written as code
Business the tool has its own lock-in
Licence: Business Source License since 10 August 2023 (v1.6 onwards); v1.5.7 and earlier stay MPL 2.0
Owner: IBM since 27 February 2025, for $6.4 bn
Fork: OpenTofu, MPL 2.0, Linux Foundation, CNCF sandbox since April 2025
Price: HCP Terraform bills per managed resource; free tier capped at 500 since 31 March 2026
Technical what really moves
Resources are per provider: aws_db_instance is not azurerm_postgresql_flexible_server
Workflow, modules and variables move; resource blocks are rewritten
The state file is your asset inventory, and it holds secrets: encrypt it
Rehearse: plan one workload against a second provider, once a year
Code makes the exit readable , not portable.
Data Act Art. 25(2)(e) exportable data and digital assets · hashicorp.com/license-faq · IBM, 2025-02-27 · cncf.io/projects/opentofu
Why Terraform here: it is the most common way platform teams describe their infrastructure, so it is where an exit plan actually lives. Read it from the business side first. HashiCorp moved Terraform from the Mozilla Public License to the Business Source License on 10 August 2023; releases up to 1.5.7 stay under MPL 2.0. The restriction targets competitors who host or embed Terraform, not ordinary users, but legal teams now have to review it. IBM completed its acquisition of HashiCorp on 27 February 2025, for about 6.4 billion dollars. The community fork, OpenTofu, kept MPL 2.0, sits in the Linux Foundation and was accepted into the CNCF as a sandbox project on 23 April 2025. HCP Terraform, the managed service, bills per resource under management; its legacy free plan ended on 31 March 2026 and the free tier is capped at 500 managed resources.
The technical side. Terraform code is not portable between clouds: each provider has its own resource types, so a PostgreSQL database on AWS and one on Azure are two different blocks with different arguments. What moves is the method: the plan and apply workflow, the module layout, the variables, the review process. The state file is the most useful artefact for the Data Act: it lists every resource you run, a starting point for the exhaustive specification of exportable data and digital assets that a switching contract must contain (Article 25(2)(e)). It also stores secrets in clear text unless you encrypt it; OpenTofu added native state encryption in version 1.7.
The question for the room: if your exit tool changes licence or owner, what is the exit from the exit tool? Pin versions, keep the state in your own storage, and check that your modules run on both Terraform and OpenTofu.
Case 02: the order from abroad
Photo: Alexander Klink, CC BY 3.0, Wikimedia Commons
A court in a third country orders a provider to hand over non-personal data stored in the EU.
Whether the provider can comply depends less on where the data sits than on who holds the keys.
A hardware security module (nCipher nShield F3): the keys live here, not in the application.
Group 4 · their slides 37–38 They showed the CLOUD Act and the ICC case. Here: what Article 32 asks you to log.
Second case: an order from a third-country court or authority reaches a cloud provider, asking for non-personal data stored in the Union. Article 32 of the Data Act tells the provider what it must do to prevent unlawful access, and when such an order can be recognised.
The photo is a hardware security module, a card that generates and keeps cryptographic keys so that the application never sees them. Keep it in mind for two slides from now: custody of the keys is the control that changes the answer.
When a foreign authority asks for EU data
The text Art. 32
Providers must take technical, organisational and legal measures to prevent transfer of, or governmental access to, non-personal data held in the Union where it would conflict with EU or national law.
A foreign order is enforceable only on the basis of an international agreement, or after a reasoned, proportionate and reviewable process.
The system 4 controls
Key custody outside the provider's reach A map of every entity and person that can be compelled A documented refusal and escalation procedure A log of every request received, and of the answer
Where are your keys, and who can be compelled to hand them over?
Article 32(1) obliges providers of data processing services to take adequate technical, organisational and legal measures, including contracts, to prevent international and third-country governmental access to and transfer of non-personal data held in the Union where it would conflict with Union or national law.
Article 32(2) and (3): a decision of a third-country court or authority requiring such a transfer or access is recognised or enforceable only if based on an international agreement, such as a mutual legal assistance treaty. Without one, the provider may comply only where the third-country system requires the decision to be reasoned and proportionate, the order to be specific, and the provider's reasoned objection to be reviewable by a competent court there.
Article 28 adds a transparency duty: providers must publish on their website the jurisdiction to which their infrastructure is subject, and a general description of their measures against unlawful governmental access. That is where the questions about keys start.
The engineering reading is on the right. Encryption alone does not settle the question: if the provider holds the key, the provider can be ordered to use it. That is why the next slide looks at control, not location.
Sovereignty is a chain of control, not a map
Layer What decides it L1 The parent company Ownership reaches across borders. An EU subsidiary may still answer to a group decision. L2 The operating entity Which legal person signs the contract, and under whose law it can be ordered to act. L3 The privileged staff Administrators have passports and employers. Compulsion reaches people, not data centres. L4 The infrastructure Where the bytes rest. The layer everyone discusses, and the weakest guarantee of the five. L5 The keys If the provider can decrypt, it can be ordered to. Custody, not location, is the control.
A reading aid, not legal advice. A real assessment needs the contract, the group structure and counsel in both jurisdictions.
Read the five layers from top to bottom. Data residency (L4) is what most marketing talks about, and it is the weakest of the five guarantees: a compelled administrator (L3) or a parent company (L1) can reach data wherever it physically sits.
The only layer that changes the answer on its own is L5. If the customer holds the keys, in a hardware security module the provider cannot operate, an order to the provider produces ciphertext.
On 3 June 2026 the Commission proposed a Cloud and AI Development Act, COM(2026) 502, whose Article 16 sets up a Union cloud computing sovereignty framework with assurance levels. A useful exercise: for each of these five layers, ask whether such a label could actually verify it.
Case 03: the tractor's data
Photo: Sanzzu, CC BY-SA 4.0, Wikimedia Commons
The farmer wants her machine's data sent to an independent agronomist.
The manufacturer must make it possible, securely, for a recipient it did not choose.
A tractor at work: engine hours, positions, yields, all logged by the machine.
Third case, the one the Data Act was written for. A farmer uses a connected tractor; the machine records engine hours, positions, fuel and yields, and sends them to the manufacturer's platform. She wants that data shared with an independent agronomist, or with a repair shop that is not the dealer.
Articles 4 and 5 give her that right; Article 3(1) asks products placed on the market after 12 September 2026 to be designed for it. The next two slides turn the right into components, and the components into attacks you already know.
The EU has mandated a feature
The text Art. 3 to 5
Connected products must be designed so that the data they generate is accessible to the user, easily, securely and, where relevant and technically feasible, directly.
On request, the data holder makes it available to the user, or to a third party the user names.
The system 4 components
An authenticated read path into telemetry that used to be internal A delegation flow to recipients you did not choose Field-level filtering for trade secrets Rate limits on a public, mandated endpoint
Access by design applies to products placed on the market after 2026-09-12 Art. 3(1) Art. 50 .
Group 4 · their slides 24 and 29 Derived data is out of scope. The line they drew becomes a data schema to write.
Article 3(1) requires connected products and related services to be designed and manufactured so that product data and related service data are, by default, easily, securely, free of charge, in a comprehensive, structured, commonly used and machine-readable format, and, where relevant and technically feasible, directly accessible to the user. It applies to products placed on the market after 12 September 2026. Articles 4 and 5 add the right to obtain the data from the data holder and to have it shared with a third party.
In security terms, the EU has mandated a feature, and mandated features ship on deadlines. Millions of industrial devices are acquiring a documented way to be queried by someone other than their manufacturer. The next slide maps each component to an attack you already know.
The new right, and the old attack
The text creates The system gets The failure you already know A user right to product data An authenticated read path into internal telemetry Broken object-level authorisation: ask for record 1042, get 1041 Sharing with a third party A delegation flow with tokens and an unvetted recipient Consent phishing: the OAuth grant to a hostile app Proof that the user is the user A binding between a person and a resold, shared device Social engineering of the request, as seen under the GDPR Protection of trade secrets Filtering between what is owed and what is confidential Over-disclosure: an export never reviewed field by field Availability of access A public endpoint on an industrial fleet Denial of service on a system with no spare capacity
This table is the thesis of the lecture made concrete: every right of access is an interface, every interface is a surface. Each row pairs something the regulation creates with the component that implements it and a well-known attack class (the OWASP API Security Top 10 for the first, OAuth consent phishing for the second).
The mapping is illustrative. A real threat model is built against a specific design, not against this table. Trade secrets have their own procedure in the text (Articles 4(6) to 4(8)): agreed protective measures first, and a reasoned refusal only in exceptional circumstances.
Where it breaks in production
Not the law. The implementation.
Sixteen minutes on the implementation: four failure patterns observed in practice, the adjacent regimes that ask for the same evidence, and a checklist a platform team can run this quarter.
Four things that fail before lawyers are involved 01 · Identity The right belongs to the user. Systems know accounts, serial numbers and contracts, not people across resale and leasing.
02 · Evidence What did you disclose, to whom, when, on which basis? Thirty-day log retention cannot answer.
03 · Quality Internal telemetry tolerates gaps and drifting clocks. Once it leaves the building, a gap becomes a dispute.
04 · The boundary These texts mostly govern non-personal data; the GDPR, personal data. A machine ID plus a timestamp often identifies a person.
The fourth failure is the intellectually serious one, and it links back to the whole course. A vibration reading from an industrial motor is non-personal data. The same reading, with a machine identifier and a timestamp, in a workshop where one named technician operates that machine, reveals when that person arrived, left and took a break. Nobody designed it as personal data; it became personal data because it was joined.
There is no clean technical boundary, and the Data Act says so itself: it is without prejudice to the GDPR, which prevails in case of conflict (Article 1(5)). The engineering answer is not to classify a stream once, but to classify per field, record the decision, and re-examine it whenever the schema changes.
The second failure, evidence, leads to the claim on the next slide.
When machine data becomes personal data
Photo: GillyBerlin, CC BY 2.0, Wikimedia Commons Robots on an assembly line (Ford, Cologne). Each one logs its cycles, stops and faults.
A vibration reading is non-personal data.
The same reading, with a machine ID and a timestamp, on a line run by one named technician, tells you when that person arrived, paused and left.
Classify per field, record the decision, re-examine it when the schema changes.
Data Act Art. 1(2) personal and non-personal data · Art. 1(5) the GDPR prevails
The fourth failure deserves its own slide, because it links back to the whole course. Nobody designed the robot's log as personal data. It became personal data because it was joined with a roster.
The Data Act covers personal and non-personal data (Article 1(2)) and is without prejudice to the GDPR, which prevails in case of conflict (Article 1(5)). There is no clean technical boundary, so the engineering answer is a decision per field, written down, and reviewed whenever the schema changes.
The adjacent regimes ask the same question
Text What it asks the platform for Cite GDPR 2016/679 Records of processing; breach notified to the authority within 72 hours where feasible Art. 30 Art. 33 NIS2 2022/2555 Early warning within 24 hours, notification within 72 hours, final report within a month Art. 23(4) DORA 2022/2554 Register of ICT third-party arrangements; exit strategies Art. 28(3) Art. 28(8) AI Act 2024/1689 High-risk systems log events automatically over their lifetime Art. 12
Different triggers, different authorities, one shared need: an audit trail somebody designed before the question was asked.
The Data Act does not live alone on a platform. In the same organisation, the GDPR asks for records of processing (Article 30) and a breach notification to the supervisory authority without undue delay and, where feasible, within 72 hours (Article 33). NIS2 asks essential and important entities for an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month (Article 23(4)).
For the AI Act, note that the timeline moved: Regulation (EU) 2026/1744, the Digital Omnibus on AI, published on 24 July 2026, applies the high-risk obligations to Annex III systems from 2 December 2027 and to Annex I products from 2 August 2028. Logging (Article 12) and log retention of at least six months (Articles 19 and 26(6)) are unchanged in substance.
DORA asks financial entities to keep a register of information on all contractual arrangements with ICT third-party service providers (Article 28(3)) and to have exit strategies (Article 28(8)). The AI Act asks high-risk AI systems to technically allow the automatic recording of events over their lifetime (Article 12).
Each regime has its own trigger and its own authority; I am not merging them. The point is architectural: they all end up asking the same logs.
The architect's conclusion
Under this regime, compliance is a telemetry problem.
A regulator does not ask whether you intended to comply. It asks you to show what happened. Showing what happened is observability, and observability was designed for engineers, not for evidence.
Every obligation in this lecture ends in the same place. Did you disclose the data, within the deadline, to the right person, in a usable format? Did you refuse the foreign request, and on what basis? Did you let the customer leave, and what did you hand over? None of those questions can be answered from a policy document. They are answered from logs, traces and records that somebody decided to keep, years before the question was asked.
So the compliance architecture of the next decade is not a new department. It is a retention policy, an identity model and an audit trail, designed on day one by people with your training.
A production checklist
Inventory Which product and service data exist, field by field, personal or not Access path Authenticated, rate-limited, documented before sale Delegation Scoped, expiring, revocable grants to third parties
Exit Open export formats, a rehearsed runbook, telemetry included Keys Who holds them, who can be compelled, where requests are logged Evidence Retention long enough to answer the slowest regulator
Group 4 · recommendation 5 “Ask which law can reach the data and who can switch it off.” That is the Keys line.
Six checks a platform team can run this quarter. None of them depends on the outcome of the Omnibus negotiation: whatever the final numbering, a right of access needs an inventory, an access path, a delegation model, an exit, a key policy and evidence.
For each line, the honest question is not "do we have a policy" but "could we show it working on a real request tomorrow".
Four common misreadings
Heard in the hallway What the text says "The Data Act is about personal data." It covers personal and non-personal data, and leaves the GDPR untouched for personal data. Art. 1(2), 1(5) "Free switching starts in 2027, nothing to do now." Contract terms and the switching process apply since 2025-09-12; only the charges run until 2027. Art. 25, 29 "Data residency solves foreign access." The text speaks of measures against access, not of location. Art. 32(1) "The Omnibus already changed it." A proposal is not law. 2025/0360(COD)
Four sentences I hear in meetings, each corrected by the text itself. The Data Act applies to personal and non-personal data (Article 1(2)) and is without prejudice to the GDPR (Article 1(5)). The switching obligations of Chapter VI apply since 12 September 2025; Article 29 only phases out the charges until 12 January 2027. Article 32 is written in terms of measures to prevent access, not in terms of where data is stored. And the Digital Omnibus remains a proposal until it is adopted and published in the Official Journal.
Three things to take out of this room
Read the obligation as a specification. For every article: who builds it, who operates it, who proves it ran? Build capabilities, not article numbers. Identify your data, move it, prove who touched it. Those survive every rewrite. Threat-model the rights, not only the system. A mandated access path is attack surface from the day it exists.
Digital sovereignty is not decided by where a system is hosted. It is decided by who can operate it, audit it and switch it at three in the morning.
Your questions
Including the ones nobody can answer yet.
Thirty minutes. The next four slides support the discussion: a glossary for mixed teams, four open questions, who supervises what in Luxembourg, and where to read the texts properly.
Law to engineering, a short glossary
The text says An engineer hears Where Data holder The party that controls the data and must serve the request Data Act Art. 2(13) Accessible by design A requirement at product definition, not a late feature Data Act Art. 3(1) Functional equivalence Same outcome on the target platform, after migration Data Act Art. 30(1) Structural separation An isolation boundary you can demonstrate to an auditor DGA Art. 12 Adequate measures Controls, plus the evidence that they ran Data Act Art. 32(1)
Mixed teams lose weeks to vocabulary. This glossary pairs a few legal terms from the two texts with what an engineer would build or check. Definitions are in Article 2 of each regulation; the right-hand column tells you where the term does its work.
Four questions worth arguing about
01 If free switching mainly benefits providers large enough to absorb migration costs, has the EU increased competition or concentrated it?
02 Can any safeguard against foreign government access survive the fact that compulsion reaches people, not machines?
03 Does opening industrial data to users create more security risk than economic value? How would you measure either side?
04 If a regime is rewritten before it is fully implemented, is that regulatory agility or regulatory failure?
Four open questions for discussion. None has a settled answer; the second and third are good subjects for a group report, because they need both a legal and a technical argument.
In Luxembourg: who supervises what
Text Luxembourg Authority GDPR Law of 1 August 2018 CNPD DGA Law of 19 December 2025 CNPD for intermediation and altruism Data Act Bill 8809 , in committee ILR; CNPD for personal data NIS2 Law of 5 May 2026 ILR; CSSF for banking AI Act Bill 8476 , in committee CNPD by default
Screenshot of chd.lu, dossier 8809, 17 October 2026 · Chambre des Députés du Grand-Duché de Luxembourg Bill 8809 at the Chambre des Députés: filed on 28 July 2026, still in committee.
Luxembourg in one table. The CNPD supervises personal data under the law of 1 August 2018, and, since the law of 19 December 2025 implementing the Data Governance Act, data intermediation services and the register of data altruism organisations; the same law creates the Commissariat du Gouvernement à la souveraineté des données for the re-use of protected public data.
The Data Act implementing law is still a bill, no. 8809, filed on 28 July 2026: it would make the Institut Luxembourgeois de Régulation the competent authority and data coordinator, with the CNPD for personal data and fines in tiers up to one million euros. NIS2 is transposed by the law of 5 May 2026, with the ILR as main authority and the CSSF for banking and financial market infrastructures. The AI Act bill, no. 8476, would make the CNPD the default market surveillance authority. Sources: Chambre des Députés and Legilux.
Two dates for context. On 16 December 2024 the Commission sent Luxembourg, with nine other Member States, a reasoned opinion for not yet applying the Data Governance Act (INFR(2024)2063); the law of 19 December 2025 followed. Bill 8809 was formally referred to the Commission des Médias et des Communications on 8 October 2026; no opinion of the Conseil d'État was filed yet on 18 October.
Where to read this properly
Source Reference Data Governance Act Regulation (EU) 2022/868 , OJ L 152, 3.6.2022Data Act Regulation (EU) 2023/2854 , OJ L, 22.12.2023Digital Omnibus COM(2025) 837 , procedure 2025/0360(COD) Adjacent regimes GDPR 2016/679 DORA 2022/2554 NIS2 2022/2555 AI Act 2024/1689 Cloud Draft model terms and cloud clauses, 19.11.2025 · Cloud and AI Development Act, COM(2026) 502 Luxembourg Law of 19.12.2025 (DGA) · bill 8809 (Data Act) · law of 5.5.2026 (NIS2) · chd.lu, legilux.public.lu
Photo: Pigranelle, CC0, Wikimedia Commons The Official Journal, bound: the only authentic text, now online.
Presented in a personal capacity. Nothing here represents the position of any employer, and none of it is legal advice. Slides, notes and summary: sitraka.lu/teaching/eu-data-strategy/
Start with the primary texts on EUR-Lex. The Omnibus proposal is moving: check the procedure file on the European Parliament's Legislative Observatory before relying on any status given here, which is as of 17 October 2026.
Keep going
On the day of this lecture, 20 October 2026, the Luxembourg AI Factory (Luxinnovation) also held an “AI Act Lab”, a hands-on workshop helping companies navigate the EU AI Act and related regulation.
If this hour was useful, here is where to continue. The summary page gives the argument with every source; ZeRegLens is an open-source browser extension I wrote to read EU regulatory texts article by article; the agent casebook explains AI agents from primary sources. The agenda lists technology and finance events in Luxembourg every week, and the weekly newsletter sends them by e-mail. On the same day as this lecture, the Luxembourg AI Factory also held an AI Act Lab, a hands-on workshop on the EU AI Act.
The QR code opens the course page, with the slides in English, French and German and the speaker notes.
Thank you.
Thank you to Roger Tafotie for the invitation, and to this class for an hour of attention.
Sitraka FORLER · lecturer, IAE Metz and Centrale Méditerranée · columnist, AGEFI Luxembourg
Connect on LinkedIn : linkedin.com/in/sitraka-matthieu-forler
Educational material, not legal advice.
Credits: every photo and screenshot carries its credit on its slide (Wikimedia Commons licences, and official pages reused with their source). Logo: University of Luxembourg, a public-domain text logo (Wikimedia Commons), shown only to identify the host institution; this guest lecture is not an official publication of the University. Icons: Font Awesome Free (CC BY 4.0).
Photo: Benoît Prieur, CC0, Wikimedia Commons
Photo: City of Detroit, CC0, Wikimedia Commons
Photo: Chris Woodrich (Crisco 1492), CC BY-SA 4.0, Wikimedia Commons
Photo: Cayambe, CC BY-SA 3.0, Wikimedia Commons
Photo: Benoit Brummer (Trougnouf), CC BY 4.0, Wikimedia Commons
Photo: Pigranelle, CC0, Wikimedia Commons
Photo: Sanzzu, CC BY-SA 4.0, Wikimedia Commons
Photo: Derrick Coetzee, CC0, Wikimedia Commons
Photo: GillyBerlin, CC BY 2.0, Wikimedia Commons
Photo: Steve Jurvetson, CC BY 4.0, Wikimedia Commons
Screenshot of eur-lex.europa.eu, 17 October 2026 · © European Union, reuse authorised (Decision 2011/833/EU)
Screenshot of digital-strategy.ec.europa.eu, 17 October 2026 · © European Union, reuse authorised (Decision 2011/833/EU)
Screenshot of the Legislative Observatory, European Parliament, 17 October 2026 · © European Union
Photo: Andrepaul, CC BY-SA 4.0, Wikimedia Commons
Photo: Alexander Klink, CC BY 3.0, Wikimedia Commons
Screenshot of chd.lu, dossier 8809, 17 October 2026 · Chambre des Députés du Grand-Duché de Luxembourg