Data Sovereignty and Rust | HoistIT at Rust AI Amsterdam

The third talk at the Rust AI Europe meetup at Adyen in Amsterdam, on 9 September 2026, changed the subject. After two talks on rebuilding Spark in Rust (my write-up of those), Robin Everaars of HoistIT asked a different question: who actually controls your data, and can you prove it?

His title slide read “Data Sovereignty and Rust”. I help clients design platforms that have to keep data inside their own borders and their own control, so this is close to my day job. Everything below comes from his slides. I didn’t record the talk, so I won’t put words in his mouth beyond what was on screen.

Robin Everaars at the podium next to his HoistIT title slide "Data Sovereignty and Rust", dated 2026-09-09

The title slide: “Data Sovereignty and Rust”, Robin Everaars, 2026-09-09.

From helping organisations in to helping them out

The second slide was one sentence: “For ten years I helped organisations into the Microsoft ecosystem. Now I help them out.”

Slide reading "For ten years I helped organisations into the Microsoft ecosystem. Now I help them out." with Robin Everaars on stage

Ten years in the Microsoft ecosystem, and now the way out.

The “Who is talking” timeline filled in the rest: ten years in the Microsoft ecosystem, a last stop on “one platform” (“YAML in, Azure out”), research at Nyenrode on cognitive lock-in, then HoistIT in 2025 with Dajo Hofman. The company’s pitch slide said “We enable data sovereignty” and “Built a sovereign data platform so you can leave, including us.” One line on the timeline slide stood out to me: “Not a Rust developer. Active LakeSail contributor, with AI at my side.”

Why? Somebody else decided

The “Why?” slide had the heading “Somebody else decided”. It showed four short cases, each labelled with where the decision was made: a US executive order (2025), a US export control (June 2026), a US terrorist designation (August 2026), and a Dutch case labelled “Dutch parties, no foreign law”, where treatment data reached insurers without patients being asked (unlawful, 2019). The common thread was that in each case the people using a service didn’t make the call.

A line at the bottom moved to the law: “Luckily, people are waking up. The law is moving. DORA: a tested exit, 2025. Data Act: switching charges zero, 2027.” I checked both against the official texts:

DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), has applied since 17 January 2025. Article 28(8) requires financial entities to have exit strategies for ICT services that support critical or important functions, and says exit plans “shall be sufficiently tested and reviewed periodically”.
The EU Data Act (Regulation (EU) 2023/2854), Article 29(1): “From 12 January 2027, providers of data processing services shall not impose any switching charges on the customer for the switching process.” Until then, only reduced switching charges are allowed.

The slide also credited people who had warned about this earlier, naming Bert Hubert and Marleen Stikker “and many more”.

27 mental-healthcare record systems

This was the part of the talk with data behind it. Slide six opened with a quote from “a mental-healthcare professional, about their electronic patient dossier, earlier this year”: “It’s in a Dutch data centre.” The slide then listed the signals used to check claims like that: resolved hostnames, advertised cloud certifications, and job ads.

The next slide showed the result for 27 mental-healthcare record systems, cited as “Everaars, R. June 2026”:

10 point to a US cloud
2 have no host named
15 give no signal either way

The caption was careful: “Ten point to a US cloud. For the other seventeen this check settles nothing.”

Slide "27 mental-healthcare record systems": 10 of 27 point to a US cloud, 2 have no host named, 15 give no signal either way

Ten of 27 Dutch mental-healthcare record systems point to a US cloud. For the other 17, this check settles nothing.

My take: I like that the slide says what the method can’t tell you. “It’s in a Dutch data centre” can be true and still leave the jurisdiction question open, depending on who runs that data centre. Hostnames, certifications and job ads are public signals that anyone can check, which makes the result easy to reproduce and easy to argue with.

Lock-in is a habit before it is a contract

The speaker then turned the lens on himself. “My own lock-in, by habit” was a timeline of “about 25 years of Windows, to scale”: Windows 95 at age 7, Windows XP on his own PC, Office for free as a student, WSL as his first Linux, ten years of Azure data platforms, and HoistIT since 2025. At the end of the bar: NixOS since 2 May 2026, “day 129” on the day of the talk, and “Windows free”.

The habit slide that followed was more honest still. “Habit, again: the second platform, eight weeks in” showed a devcontainer Dockerfile starting FROM mcr.microsoft.com/devcontainers/python:3.14-bookworm, a Microsoft-hosted base image, and then a devcontainer.json pointing at a Python data image on HoistIT’s own forge instead.

Then came a quote from much closer to the venue: “Our security requirements mandate that all our solutions are hosted on premise.” The source on the slide was the Adyen data science team, “Building our data science platform, 2018”.

Slide quoting the Adyen data science team in 2018: "Our security requirements mandate that all our solutions are hosted on premise."

A 2018 quote from the host: Adyen’s data science team on hosting everything on premise.

Ownership is a Rust feature

This is where Rust came in. The slide “Ownership is a Rust feature” put a short Rust program next to four data-governance ideas:

let records = Records::load();   // one controller of the data
let view = &records;             // supplier access, with an end date
let archive = records;           // a transfer you can prove
drop(archive);                   // erasure, with a receipt
records.len();
// error[E0382]: borrow of moved value

The point was that the compiler enforces one owner at a time, borrows that end, and moves that leave the old name unusable. Those are the same properties you want for data: one controller, time-limited supplier access, a transfer you can prove, and erasure you can show.

Slide "Ownership is a Rust feature" mapping a Rust move, borrow and drop to data controller, supplier access, transfer and erasure

Rust’s ownership rules, read as a data-governance contract.

How Rust contributes to sovereignty

The next slide made the argument in four boxes:

No runtime to license. “The layer is gone, so nobody gets to price it per employee.” It removes the runtime owner. The footnote pointed to the Oracle Java SE Universal Subscription (2023).
A build you can prove. “Vendor the crates, build offline, diff the hash. Work, not a default.” It removes the need to trust someone else’s binary: cargo build --release --offline --locked.
Small teams built the alternative, fast. “Polars in Amsterdam, Qdrant in Berlin, Meilisearch in Paris, Garage on EU research money.” It removes the wait for a vendor to offer one. A footnote said Garage, an S3 store, was built on 5.5 EU-funded person-years.
A floor held by foundations. “The Rust Foundation and the ASF. Plural funders, so no single vendor’s kill switch to throw.” The slide added that this risk is “moved, not removed”: the ASF governs DataFusion, and both foundations are US-registered.

Slide "How Rust contributes to sovereignty" with four boxes: no runtime to license, a build you can prove, small teams built the alternative fast, and a floor held by foundations

Four ways Rust helps, including the caveat “moved, not removed”.

A follow-up slide, “The channel is not sovereign, yet”, was the honest part. crates.io is run by a US-registered foundation, uses a GitHub login, and has hosting donated by AWS and a CDN from Fastly. The suggested fix is your own mirror: cargo vendor, or a registry you run. The slide also noted that Germany’s Sovereign Tech Agency invests in the Rust Foundation’s release and backup infrastructure and pays two Rust maintainers.

My take: the --offline --locked build is the part I’d take straight into a platform team. A vendored, offline, locked build that you can diff by hash is a supply-chain control in its own right, and it shows what the “can we leave?” question looks like in practice.

Sovereignty = ownership = free choice

The definition slide drew three overlapping circles around “ownership”:

Use: who may process it, for what, on whose terms?
Possess: where does it live, and who can reach it?
Dispose: can you end it, and prove it?

Slide "Sovereignty = ownership = free choice", with use, possess and dispose as overlapping circles around ownership

Use, possess, dispose: the three questions behind ownership.

The “Layers of data sovereignty” slide then split the problem into four layers. Data: the records, and ownership is the goal. Software: control the software, and you control the data. Hardware: portable software makes the hardware a choice. Organisational: law, terms and agreements decide whether the other three count. HoistIT has written up the fourth layer on its blog: The fourth layer of data sovereignty.

Destroy it and prove it

HoistIT’s own platform slide mapped the same four layers to promises:

Data: “Open standards. Take it anywhere, from anywhere. Destroy it and prove it.”
Software: “Source access. Hoist the platform too.”
Hardware: “Any Kubernetes. Air-gapped included.”
Organisational: “A tested exit. Leave even us behind.”

HoistIT "Our platform" slide mapping data, software, hardware and organisational layers to open standards, source access, any Kubernetes and a tested exit

“Destroy it and prove it”, next to “a tested exit” on HoistIT’s platform slide.

“Destroy it and prove it” got a recorded terminal demo. Some fields of a record (a customer ID and a loyalty segment) were encrypted at rest while the rest stayed plaintext. While the key existed, the record could be read back from the broker. After the key was destroyed, reading it returned “encryption key not found”, while the records were still on the topic and none had been deleted. The demo’s summary line: “erasure destroys the key, never the records”. It ended with RESULT: PASS. This is crypto-shredding. Because the photos of that demo show key identifiers and record hashes, I’ve left them out.

My take: crypto-shredding is the right answer to “how do you delete one person’s data from an append-only log or a backup?”, and I’ve seen teams get stuck on that question for months. The bit that’s easy to skip is the “prove it” step: a verifiable check that the key is gone, not just a ticket that says someone deleted it.

Do the self-check

The last content slide was a grid you can use on Monday morning. Rows are Possess (“Do we hold it?”), Use (“Can we run it our way?”) and Dispose (“Can we leave?”). Columns are the four layers:

	Data	Software	Hardware	Organisational
Possess	Is there a complete copy we control?	Do we hold the source and the keys?	Whose rack, and whose jurisdiction?	Do the terms let us hold it?
Use	Open formats, tooling we did not buy?	Runs with no vendor control plane?	Can we add a node this week?	Can we change it without approval?
Dispose	Export in hours, or in quarters?	Can we fork it, or is it a renegotiation?	Ours outright, or a renewal date?	Can we exit, and prove it?

Slide "Do the self check": a grid of possess, use and dispose questions across data, software, hardware and organisational layers, ending with "Can we exit, and prove it?"

The self-check grid. The last cell, highlighted: “Can we exit, and prove it?”

Three things to take home

The closing slide listed three points:

“Lock-in is a habit before it is a contract.” It cited Murray and Häubl (Journal of Consumer Research, 2007) and Bert Hubert (berthub.eu).
“Sovereignty over software includes what it is built with, and the channel that ships it.”
A quote attributed to Edzo Botjes, “in conversation, September 2026”: “It is not a question not whether the blow lands. Sovereignty determines how many moves you have when it does.”

The same slide pointed to HoistIT’s blog and an open toolkit, “free and no sign-up”, with twelve questions. The slide explained that Hummel and colleagues read 341 papers and found no shared definition of sovereignty, “so ours is written down”.

Closing slide "Three things to take home": lock-in is a habit before it is a contract, sovereignty over software includes the channel that ships it, and a quote on how many moves you have

Three things to take home, with links to HoistIT’s blog and open toolkit.

What I’m taking back to client work

Most sovereignty talks I see stay at the level of cloud regions and certifications. This one went further. It went down to a build flag, a key that gets destroyed, and a grid of twelve questions you can answer for each system. The “habit” framing is the one I’ll reuse. Most of the lock-in I find in platform reviews wasn’t a decision anyone made. It was a default nobody changed: a base image, a login, a managed service that was one click away.

If you run a platform for a regulated organisation, the self-check grid is a good agenda for your next architecture review. And the DORA and Data Act dates above mean that “can we exit, and prove it?” is now a legal question for some teams, not only an engineering one.

Data Sovereignty and Rust: Robin Everaars at Rust AI