Skip to content

Data sovereignty and Rust: my talk at Adyen, written out

The written version of my talk at Rust, Data and AI Amsterdam: why lock-in starts as a habit, why ownership is a Rust feature and why sovereignty is about how many moves you have left.

Cover for Data sovereignty and Rust: my talk at Adyen, written out
Updated: Oct 1, 2026
Recording: FunctionalTV

FunctionalTV recorded the evening and kindly let us host the recording ourselves. The slides are online too: in the browser, as a PDF and as source. What follows is close to what I said on stage: I corrected the slips, left out what only works in the room and added a few later notes between square brackets.

Into Microsoft, and out again

For about ten years I helped organisations into the Microsoft ecosystem. For the past year I have been doing the opposite: helping them out. My company HOIST IT does that with a sovereign data platform you can take with you, even if that means leaving us. LakeSail is part of that platform.

Some background first. My last stop in the Microsoft world was a platform that made it even easier to get into Azure: YAML in, data platform in Azure out. Along the way I finished my master’s at Nyenrode, with research into what is called cognitive lock-in. Keep that in mind for the case study in a minute. In 2025 I came to my senses, let Microsoft go and started HOIST IT with my co-founder Dajo Hofman. Our first project was AMALT, with the Dutch Ministry of Defence: a platform that makes learning smarter. It runs air-gapped and on premise, and LakeSail runs there today.

One disclaimer, the same one I gave on stage: I am not a Rust developer. I am an active LakeSail contributor, and I do that with AI at my side.

Why? Somebody else decided

Slide: "Why? Somebody else decided". Four cases: an ICC judge in The Hague whose Microsoft account was blocked under a US executive order in 2025; Claude Fable switched off for everybody three days after launch at the request of the US government in June 2026; an Italian volunteer host named a global terrorist in August 2026, after which the US registry for .org took its domain; and Dutch treatment data that reached insurers without asking patients, ruled unlawful in 2019.
Slide 5 in the deck

I opened with a question to the room: who knows about the case at the bottom left? One hand went up, then a second. It is about an Italian volunteer internet provider that activists have used to host their websites since 2001. A few weeks before the talk the US government named it a terrorist organisation, and a couple of days before the meetup it had to stop. [The provider is Autistici/Inventati. The US State Department designated it on 26 August 2026, together with the Treasury. The .org registry put its domain on hold the next day, and on 7 September the collective announced it would shut down.]

That case is not isolated. In 2025 a judge of the International Criminal Court in The Hague was locked out of their Microsoft account, with personal consequences: cards stopped working and Alexa stopped answering. [Strictly, these are two people under US sanctions. The Microsoft mailbox was chief prosecutor Karim Khan’s, though Microsoft says it did not stop serving the court. The cards and Alexa were judge Kimberly Prost’s.] This summer Claude Fable was switched off worldwide for a while, three days after its launch, at the request of the US government. [It was back on 1 July, after almost three weeks.]

I point at the United States a lot when I talk about sovereignty, but we have our own problems within our own borders too. That is the case at the bottom right: Dutch treatment data that reached insurers without the patients being asked. [That case, mental-health outcome questionnaires gathered for a benchmark the insurers paid for, is in What it really means to own your data. The Dutch data protection authority found in 2019 that it had no legal basis.]

The slide also carries the good news: people are waking up and the law is moving. DORA has asked financial institutions for a tested exit since 2025, and under the Data Act switching charges drop to zero in 2027. And I am far from the first to say all this. Bert Hubert and Marleen Stikker, among many others, warned us long before I did. I have now joined their ranks.

“It’s in a Dutch data centre”

Slide: "27 mental-healthcare record systems". Ten of 27 point to a US cloud; for the other seventeen this check settles nothing. Two name no host and fifteen give no signal either way. Everaars, R. June 2026.
Slide 7 in the deck

Earlier this year I asked a mental-healthcare professional where they thought their patients’ records lived. They used an electronic patient dossier (an EPD) and were convinced it sat in a Dutch data centre. That made me curious, so I had a look, with nothing but public information: where the hostnames resolve, what the job ads ask for and, in some cases, the cloud certifications a supplier proudly advertises. Their EPD turned out to run in Azure.

It was not the only one. At least ten of the 27 systems I looked at point to a US cloud, mostly Azure. That matters because of the CLOUD Act, which gives the US government a way to reach that data, whichever country the disks spin in. [The full research, supplier by supplier, is in A Dutch data centre is not (per se) a sovereign one. Why location settles so little: data residency in the toolkit.]

My own lock-in, by habit

So why are we, especially in the Netherlands, so in love with Microsoft? I think it starts with habit, and I am the perfect example. My first Windows was Windows 95, on my father’s PC, when I was about seven. My first own PC ran Windows XP. As a student I got Office for free, on Windows of course. Only halfway through my data career did I meet the wonderful world of Linux, and even then as WSL, inside Windows.

Slide: "My own lock-in, by habit". A fastfetch screenshot of my workstation with the NixOS logo, on the day of the talk: OS age 2026-05-02, 129 days.
Slide 9 in the deck

Now, running HOIST IT, I am finally Windows free: 129 days on the day of the talk, and the screenshot is the proof. I have become a full-on Linux geek and terminal warrior. I run NixOS, because a build that you can reproduce is the same idea as an exit that you can prove.

Habit runs deep all the same. Eight weeks into building our platform, working on the project with Defence, we were still pulling our Python dev container from Microsoft’s registry. We have since replaced it with an image we build and host ourselves, but it shows how quietly habit does its work. [That is what my research was about: the skills you have built up make the familiar option feel like the only one, so switching feels harder than it is. The toolkit has more on vendor lock-in.]

A shout-out to our host. I did some research on the building we were in, and Adyen has run everything itself for a long time. In 2018 its data science team wrote that their security requirements mandate that all their solutions are hosted on premise. They were sovereign well before it was cool: the true hipster definition. They did it knowing full well what it cost, because anything else was not acceptable to them.

Ownership is a Rust feature

Slide: "Ownership is a Rust feature". A short Rust program: 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; then records.len() fails with error E0382, borrow of moved value.
Slide 12 in the deck

Then the bit we were there for. I think ownership is a Rust feature. The left side of this slide is plain Rust code. In Rust every value has exactly one owner. Other parts of a program can borrow a value for a while. Only the owner can hand it over or throw it away, and after that the old owner cannot touch it anymore. The comments on the right are mine, and they are what is missing in many organisations: one controller of the data, supplier access that has an end date, a transfer that you can prove (which also proves the previous holder no longer has access) and a receipt when you get rid of the data.

I asked the room to explain the error at the bottom, because, honestly, I wrote this slide with the help of some AI and had not looked into it myself. Someone did: after the move into archive, records no longer owns anything, so the compiler refuses to let you use it. That is exactly the property I want for data. Once it has been handed over, the old owner cannot quietly keep using it.

Ownership is not the only thing Rust brings to sovereignty. There is no runtime to license, so nobody gets to price that layer per employee, as happened with Oracle’s Java SE subscription in 2023. That one had fully passed me by at the time. What I find most interesting is who owns the language itself: nobody in particular. Foundations with many funders hold it, so there is no single vendor that can throw a kill switch on the language. [That risk is moved rather than removed: the Rust Foundation and the Apache Software Foundation, which governs DataFusion, are both registered in the US. The slide has two more points: a build you can prove (vendor the crates and build offline) and small teams that built the alternatives fast, such as Polars in Amsterdam, Qdrant in Berlin, Meilisearch in Paris and Garage on EU research money.]

The channel is not sovereign, yet

Slide: "The channel is not sovereign, yet". crates.io runs on hosting donated by AWS and a CDN by Fastly, under a US-registered foundation with a GitHub login. Your mirror, through cargo vendor or a registry you run, is yours from there. Germany noticed: the Sovereign Tech Agency invests in the Rust Foundation's release and backup infrastructure, and its fellowship pays two Rust maintainers since June 2026.
Slide 14 in the deck

That said, Rust is not fully sovereign yet. The distribution channel runs on AWS, the CDN is Fastly and you log in to crates.io with GitHub. You can reduce that dependency by mirroring the crates you use into a registry of your own, but that is not a permanent fix. Luckily Germany noticed: through its Sovereign Tech Agency it invests in the Rust Foundation’s release and backup infrastructure, and since June 2026 it pays two Rust maintainers. That gives us an alternative route.

Sovereignty is ownership is free choice

Slide: "Sovereignty = ownership = free choice". A Venn diagram of three rights with ownership where they meet: use (who may process it, for what, on whose terms?), possess (where does it live, and who can reach it?) and dispose (can you end it, and prove it?).
Slide 15 in the deck

I had been talking about sovereignty for a while without explaining it. I explain it as ownership, and to make it simple I translate ownership into free choice. Ownership breaks down into three rights. Use: who may process the data, for what and on whose terms? Possess: where does it live, and who can reach it? And dispose, the one that matters most: can you get rid of your data, and can you get rid of your systems? When you have all three, you own it. If not, you are renting.

Those rights apply on four layers. The data, where ownership is the goal. The software, because you need to control the software to control the data. The hardware, where portable software makes whatever runs underneath, a cloud or your own rack, a choice instead of a dependency. And the layer that is often forgotten: the organisational one, the laws, terms and agreements that apply. I wrote about a case where everything checked out as sovereign: the data on their own servers, in their own building, maintained by their own staff, even the software. But a contract signed long before said they could not move the data without the original supplier, at a steep price.

For the platform we build, that translates into open standards for the data, so you can take it anywhere. Access to the source, so you can hoist the platform too. It runs wherever Kubernetes runs, air-gapped included. And a tested exit that is written into our agreements, so you can leave us behind.

Destroy it and prove it

Slide: "Destroy it and prove it". A terminal recording of hoist security crypto-shred-verify: records sent for a subject are readable, the key is destroyed, reads fail with "encryption key not found" while the records are still on the topic, and the run ends with RESULT: PASS.
Slide 20 in the deck

Then the example I like most, about the dispose part. This is a recording of our platform’s command line, showing crypto shredding. I send some example data to the platform. It is intercepted before it reaches Kafka and encrypted. It is stored encrypted on the bus and later, through LakeSail, in storage. Meanwhile a key is created for that subject, and that key is what you need to read the data. With the key I can read the decrypted records. After I destroy the key, all I get is garbage, even though the records are still there.

Deleting data, especially at scale, is hard and slow. This way you have a way to get rid of it and proof that it is actually gone.

The self-check, and a show of hands

Then I asked the room to do the self-check. It crosses the three rights with the four layers into twelve questions about one platform you own, from “Is there a complete copy we control?” to “Can we change it without approval?”. I asked everyone to pick one they found interesting and to think about whether they had an answer, without saying it yet.

Then I asked for hands on the bottom right: can you exit a vendor you depend on today, and prove it? Take any vendor. No hands went up. I think that proved my point. [The twelve questions are on slide 21. This site has a shorter self-check and an exit-readiness checklist.]

How LakeSail made leaving possible

A shout-out to LakeSail, and to what I think they did very smartly: they speak the Spark protocol. Take me as the case study again. First I was used to Windows, later to Spark. One of the main reasons I chose LakeSail is that it speaks the language I already knew. That also gave me a way back: I could try LakeSail and return to what I knew if it did not work for me. Lowering the switching cost, the mental one included, is what made leaving possible.

It is also why I still use Apache Kafka and not yet Apache Iggy, which is written in Rust: as far as I know it does not speak the Kafka protocol yet.

Three things to take home

Slide: "Three things to take home". 01: Lock-in is a habit before it is a contract (Murray and Häubl, Journal of Consumer Research 2007; Bert Hubert). 02: Sovereignty over software includes what it is built with, and the channel that ships it. 03: "It is not a question whether the blow lands. Sovereignty determines how many moves you have when it does." (Edzo Botjes, in conversation, September 2026).
Slide 23 in the deck

All in all, three things to take home. Lock-in is a habit before it is a contract. Sovereignty over software includes what it is built with and the channel that ships it. And, in the words of Edzo Botjes: it is not a question whether the blow lands; sovereignty determines how many moves you have when it does.

From the questions

The questions afterwards were good, so here are the main ones, paraphrased.

Switching is easy when there is a commodity standard, like Spark. What about emerging technology, where there is none yet? First I would challenge you: are there really no standards? And if not at your layer, is there one a layer up? Our platform is configured with YAML and Python, and for data platforms there are standards gaining adoption quickly, such as the Open Data Contract Standard and the Open Data Product Standard. If there truly is none, you have no option but to build your own and hope it catches on. Keep your eyes open, see what others do and adapt to that, even if it means supporting more than one standard and the overhead that comes with it.

So sovereign data means going back to open source, our own operating systems and on-premise storage, like twenty years ago? Not per se. I am not anti-cloud. Our platform runs wherever Kubernetes runs, and that includes Azure. It depends on your risk profile: how bad is it if the kill switch is pressed, and how severe is it if someone else reaches the data you process? Defence runs it themselves, and healthcare should perhaps consider the same. I use a European cloud myself, and I still have an Azure tenant somewhere that I need to get rid of. Fully on premise would mean taking all the maintenance back, which a small company like mine cannot do. A European cloud covers the CLOUD Act part, but what matters is that you can move: if you are not happy with one European provider, you can go to another. I expect the pendulum to swing back somewhat. Some workloads stay in Azure, for good or bad reasons, the important ones go to a European cloud and the truly critical ones to your own hardware. Even within a Dutch cloud, someone might have a bad day and press a switch, so portability is what counts.

Europeans distrust sending prompts to US AI companies, yet are fine with Microsoft and AWS holding their data. Why? I think it is several things at once. One is habit: I took myself as the case study for a reason. Microsoft is what I grew up with, and many people I speak to, former colleagues included, say there is no alternative. I tell them there is one, since I am building it. Still they stick to that position. The other is that for a long time the US and Europe were good friends, and I hope we stay good friends. There was no reason to worry, even when the US did some things differently. That changed quickly, in our government too, especially over the last ten months or so. You now see many initiatives popping up that raise awareness and help organisations move.

Is a municipality really safer running its own IT than on Azure or AWS, whose security teams are probably better? There are good developments. KPN works with several other companies on a European cloud aimed at the Dutch government, and the government has always had its own data centres for the critical things. I trust that it will be done well, but I honestly have not looked behind the scenes, so that is as far as I can answer. [The initiative I could not name on stage is most likely the Open Cloud Alliantie: seven Dutch IT companies, KPN among them, that proposed a sovereign government cloud in April 2026.]

Thanks to the organisers, to Adyen and LakeSail for hosting and to FunctionalTV for the recording. If you want to talk about any of this, get in touch.

Revision history
  • : Published.

Copyright 2026HOIST IT. All Rights Reserved