Tech Sovereignty in AI Recruitment: Why Portability Beats EU-Hosted

If you build a recruitment company in 2026, you do not get to skip the infrastructure question. Candidate data is sensitive. Client data is commercially loaded. AI used in hiring is classified as high-risk under European law. And every layer of the stack you choose is a political and operational decision, not just a technical one.

The default answer in our industry, the answer most agencies give when they get asked, is the same three letters. EU. We host in the EU. Our data lives in the EU. Our vendors are EU-friendly. Stamp the page, move on.

That answer is not wrong. It is sensible. It is a defensible short-term position. And it is not what we mean when we say Radical is sovereign by design.

This is the long version of why. It is also the technology brief I wish every company in our space would write, so that buyers, candidates, and regulators can stop accepting "EU-hosted" as the end of the conversation. It is the start of one.

EU-hosted is not the same thing as sovereign

GDPR has trained the European market to ask one question about a vendor's infrastructure: where does the data physically live. That is a good question. It is not the only question, and on its own it is not enough.

Hosting in the European Union solves a specific problem. It puts the data inside the jurisdictional perimeter where GDPR applies in full, where Schrems II concerns about US data transfers do not apply, and where the EU AI Act, the AI Liability Directive, and the Digital Services Act govern what the vendor can do. That is real. We do it. Our database lives in the EU. Our application is served from European edges. Our email is on a Swiss server. We are deliberately European in the present tense.

But "EU-hosted" answers the question of today. It does not answer the question of tomorrow.

What happens if the vendor gets acquired by a non-European parent and the new ownership decides to relocate infrastructure? What happens if the vendor's pricing changes by 4x and you need to leave on commercial grounds, not technical ones? What happens if a future European Commission tightens or loosens AI rules and you suddenly need to host with a different provider in a different country to comply? What happens if a member state goes through a Trump-style political shift, leaves the EU's data-protection framework, and the legal perimeter you trusted last year now looks like a different perimeter this year?

None of those scenarios is exotic. All of them have happened in some form to some company in the last five years. The right response is not to assume they will not happen to you. The right response is to assume they will, and to architect so that when they do, you can move.

That is sovereignty. Not the address of the server. The ability to change it.

Fiber optic strands, the physical layer of a network that must remain portable

The Trump argument applies to Europe too

When we say a political shift can happen in Europe too, we are not being abstract. The same forces that produced the first Trump administration are present in several European member states. Anti-EU parties poll in double digits in Germany, France, the Netherlands, Italy, and Sweden. Some are in government already. Most have explicit positions on data, digital sovereignty, and the EU AI Act that diverge from the current European consensus.

Imagine, hypothetically, a German federal coalition five years from now that includes a party committed to weakening EU-level data-protection rules and pursuing a national alternative. Imagine a French government that nationalises European cloud infrastructure for strategic reasons. Imagine a Dutch government that decides to make AI hiring tools subject to additional national review beyond the EU AI Act. None of these requires bad faith from anyone. All of them change the operating environment for a recruitment company that holds AI candidate and client data.

If your stack is locked to one vendor in one country, you are exposed to every one of those scenarios. If your stack runs on open standards across multiple jurisdictions and can move within days, you are not. The political risk does not disappear. The operational risk of the political risk does.

This is the same logic that has driven banks, governments, and regulated industries to adopt open-source stacks. Not because open source is ideologically superior, but because open source produces optionality, and optionality is what protects you against scenarios you cannot predict.

Open standards are insurance. They cost a little extra in design and discipline. They pay out exactly when you need them most.

The four layers of a recruitment stack, and what portable looks like at each

Sovereignty is not a single decision. It is a property of the whole stack, and the stack of an AI recruitment company has four layers that all have to be portable independently.

If any one of these four layers is locked in, the whole stack is locked in. A portable database with a locked-in email provider is still hostage. A portable application with a hardcoded AI vendor is still hostage. Sovereignty is the intersection, not the union, of portability across every layer.

Let me walk through how we make each layer portable at Radical, in the same level of detail I would want to read from any vendor before signing a contract.

Layer one: PostgreSQL, the unglamorous foundation

Our database runs PostgreSQL on Supabase in the EU region. PostgreSQL is one of the oldest, most boring, and most consequential pieces of software in modern infrastructure. It is fully open source under the PostgreSQL License. It has no single corporate owner. It has been ported to every operating system that matters and runs on hardware ranging from a Raspberry Pi to the largest data centres in the world.

The reason this matters is not romantic. It is practical. Every PostgreSQL database can be dumped to a portable format, the SQL dump, in a single command. Every PostgreSQL database can be restored from that format into another PostgreSQL instance, anywhere, in another single command. The schema travels. The data travels. The indexes travel. The constraints travel. Nothing is left behind that only the original vendor can read.

We deliberately do not use proprietary Supabase extensions that lock the schema into Supabase. We use standard PostgreSQL types, standard SQL, and a small set of widely-supported extensions like pgcrypto that are available on every major Postgres host. We treat Supabase as a great DX layer on top of an open standard, not as a destination. Tomorrow, if we need to, we can move to Leaseweb in the Netherlands, Hetzner in Germany, Scaleway in France, or self-host on our own server, in a matter of days. The data does not change. The schema does not change. The hosting changes.

This is not a hypothetical exercise. We regularly test the dump-and-restore path. We hold backup snapshots in a second European jurisdiction. If Supabase ever became a problem, commercially or politically, we would have a working alternative running before the end of the week.

Layer two: Next.js, the open application framework

Our application runs Next.js. Next.js is open source under the MIT license, maintained by Vercel as the primary sponsor but used and contributed to by a much wider community. The framework itself is not tied to any single host. A Next.js application is just a Node.js application with some opinions about file structure and rendering. Anything that can run Node can run our application.

We deploy to Vercel today because Vercel is the best operational experience for a Next.js application: edge rendering in Europe, instant deploys, preview environments per branch. That is real value, and we pay for it consciously.

We also know what the migration looks like. Next.js applications run on Scaleway in France, on Hetzner in Germany, on OVH, on Clever Cloud, on Render, on any Linux server with Node installed, and in a Docker container on any Kubernetes cluster anywhere. The build output is standard. The runtime is standard. The migration is engineering work, not a rewrite. We estimate it at two to four days of focused work, including DNS cutover, environment variable migration, and validation.

We do not use Vercel-specific features that would lock us in. We do not use Edge Config for runtime config. We do not use Vercel Postgres or KV. Our analytics is consent-first and provider-agnostic. The choice of Vercel is a productivity choice, not a strategic one, and we have already done the design work to make the move reversible.

Code on a developer screen, the open-source layer that keeps an application portable

Layer three: email on open standards, the most underestimated layer

Email is the layer where most companies surrender sovereignty without realising it. The default decision is Google Workspace or Microsoft 365. Both are good products. Both are also, by default, American services running on American infrastructure under American jurisdiction, with their own search syntax, their own proprietary inbox formats, their own data-export workarounds, and their own deep integration into the operating system of the company. Once you are inside, leaving costs months.

We chose differently. Our email runs on kSuite from Infomaniak, a Swiss provider. Infomaniak is not subject to US jurisdiction. Switzerland has its own data-protection regime that is recognised as adequate by the European Commission. The infrastructure runs on renewable energy in Swiss data centres.

That choice would still be a vendor decision if we had stopped there. We did not. The reason we can use kSuite without lock-in is that kSuite is fully compatible with IMAP and SMTP, the two open email standards that have existed since the 1980s and that every email client and server in the world supports. Our inboxes are accessed through standard clients. Our outbound mail goes through standard SMTP. We do not depend on a proprietary kSuite API. We do not use kSuite-specific labels or features in our automated workflows.

If Infomaniak ever became a problem, for any reason, we would migrate to another IMAP and SMTP provider, or self-host a mail server with Postfix and Dovecot on the same Hetzner box we use as a Postgres backup. The mailbox content moves as standard mbox. The send-and-receive setup moves as DNS records. Days, not months.

Most companies could not do this. They are locked into Gmail or Outlook by years of accumulated workflows, integrations, and habits. We avoided that lock-in by making the boring choice on day one.

Layer four: model-agnostic AI, the layer that matters most going forward

Our matching layer uses large language models. We call them through an abstraction. The abstraction has one purpose: every prompt, every output, every parsed response is structured so that the model behind the call is interchangeable.

Today we use Anthropic's Claude models, deployed in Europe and accessed through their API. We chose Claude for reasoning quality and for their published safety posture, both of which line up with how we think about responsible AI. We pay them. We use them. We are happy customers, today.

Tomorrow, if a different model is better, or cheaper, or politically required to run inside the EU, the swap is a configuration change, not a rewrite. Our prompts are versioned in our own repo, not in the vendor's prompt store. Our outputs are JSON in our own schema, not opaque vendor objects. The matching logic that turns model output into a shortlist is ours, not theirs.

This matters more than it sounds. The AI model market in 2026 is volatile. Frontier models change every six months. Pricing varies by a factor of twenty between providers. Political pressure to use European models is rising. Sovereign AI initiatives in France, Germany, and the Netherlands are funding open-weight alternatives at scale. The right architecture is not to bet on the model you like today, but to make the bet itself reversible.

Mistral, the French foundation model lab, releases its weights openly. Their flagship instruction-tuned model is available under permissive licensing. We have evaluated it in our matching layer. We are not running it in production today because Claude wins on the specific tasks our pipeline runs, by our internal metrics. But the day Mistral, or any other open European model, becomes the better choice, the switch is hours of integration work, not a strategic rebuild.

That is what model-agnostic means in practice. Not "we said we are model-agnostic in our marketing." But "we wrote the abstraction, we tested the swap, and we own the prompts."

Open source is the foundation, not the hobby

For two decades, open source was the part of the stack that serious enterprises kept at arm's length. You could use Linux on the server. Postgres was fine for analytics. But the application, the CRM, the data warehouse, the AI layer, those needed to be a brand-name vendor with a sales rep and a logo.

That world is over.

The European Commission's own Open Source Software Strategy commits the Commission to publishing software it produces as open source, to integrating open source into internal IT governance, and to applying the explicit principle of "stay in control." The strategy is not a press release. It is operational guidance for one of the largest IT estates on the continent. Linux Foundation Europe coordinates digital sovereignty initiatives across multiple member states, with the NeoNephos foundation specifically focused on open cloud infrastructure for European customers.

Banks have moved core systems to PostgreSQL. Governments have moved national infrastructure off proprietary databases. Mistral, a European-founded AI lab valued in the billions, ships open-weight models as its core product. Hugging Face, also European-founded, hosts the largest collection of open AI models in the world. The GitHub Octoverse report tracks the explosive growth of typed languages and AI-related repositories, much of it European in origin.

When we made the decision in 2024 to build Radical's stack on open standards everywhere, we did not feel ideologically pure. We felt like we were following the obvious trajectory. The companies and institutions we respect most were already there. The only debate was how completely to commit.

We committed completely.

What this means for our clients

A client who hires through Radical is hiring AI talent. They are also, by extension, accepting the way we hold their data. The intake conversations, the briefing notes, the shortlist rationale, all of it ends up inside our stack. Sovereignty is not just an abstract value. It is a promise about what happens to that data if anything about our infrastructure changes.

The promise is simple. The data stays in the European Union by default. If anything about the regulatory or commercial environment changes, we move the data, on open standards, to another jurisdiction inside Europe that the client is comfortable with. We do not lose data in a migration because the migration is built into the architecture. We do not hold the data hostage because the export format is open. The client can request a full export of their own data in a portable format at any time, and we will deliver it within a week.

This is the operational expression of "trustworthy by design." A client should not have to take our word for it. The architecture proves it.

What this means for our candidates

A candidate joining Radical takes the APAC assessment and joins a community. The data they share with us, the test results, the conversation notes, the role preferences, the personal context that shapes a good match, all of it sits inside our stack. The same sovereignty principle applies.

A candidate's data is theirs. The legal vehicle for that is GDPR. The technical vehicle is portability and minimisation. We store what we need, encrypted at rest, in a database we control, in a jurisdiction we choose. A candidate can request export or deletion at any time and we deliver within the GDPR-mandated window, in practice usually within days.

But more deeply: a candidate joining Radical is not trapped inside a US-vendor ecosystem. Their data never gets siloed in a proprietary applicant tracking system that they cannot leave. If Radical ever stopped operating, the data we hold could be migrated to another European recruiter or returned to the candidate, on open standards, without the loss that usually comes with the death of a vendor.

That is what we mean when we say a Radical stops being a commodity. Not just in the placement process, but in the way their data is held over the years.

A map of Europe, the geography of the jurisdictional perimeter we operate inside

A checklist for evaluating tech sovereignty in any vendor

If you are a buyer, a candidate, or a regulator evaluating an AI vendor in 2026, here is the checklist we wish more people would apply. We apply it to ourselves. We apply it to every vendor we use. We expect to be held to it.

If any of these answers comes back vague, the vendor is not sovereign by design. They might be sovereign by accident. They might never need the sovereignty they did not build. But you are taking a bet, and you should price it.

What we are not pretending

A few honest caveats so this piece does not read like marketing.

Portability is not free. Every layer of abstraction we maintain costs us engineering time. The model-agnostic AI abstraction is more code than a direct SDK call. The avoidance of Vercel-specific features means we ship some things more slowly than a team that fully embraces the platform. The PostgreSQL-first design means we sometimes choose a slightly more verbose schema over a slick proprietary type. These costs are real.

We pay them on purpose because the alternative cost, lock-in, is paid all at once and at the worst moment, when you need to move.

We are also not fully sovereign in every direction at every moment. Our DNS runs on a global provider with a US parent. Our CI runs on GitHub Actions, also US-owned, though the source code itself is replicable and we have backups in European Git hosts. Our payment provider is European. Our analytics is consent-first and self-hosted, but our error tracking is currently a third-party tool we are auditing for sovereignty. We are honest about the gaps. We close them when the cost of closure is reasonable. We do not pretend they are not there.

Sovereignty is a posture and a roadmap, not a finished destination. The point is to move toward it consistently and to be transparent about where you are on the path.

Why we wrote this

Because the recruitment industry, including the AI recruitment slice of it, is going to be one of the most-scrutinised sectors under the EU AI Act over the next decade. Hiring AI is classified as high-risk for a reason. The data is sensitive. The decisions affect careers. The bias risks are real. The accountability requirements are binding.

Compliance with the AI Act is the floor. Sovereignty is the ceiling we choose to aim at. They are not the same thing, and treating them as the same thing is how an industry loses the trust it needs to earn.

We are a Netherlands-based company. We are European by choice. We are small. We are honest about the size of our footprint and the scope of our claims. But the principle we set out here is portable, in every sense of that word: it can be applied to any recruitment company, any AI vendor, any infrastructure decision. We hope more companies in our space publish their own version of this brief. The conversation about sovereign AI in Europe is too important to leave to PowerPoint and policy papers.

Real sovereignty is operational. It lives in the dump-and-restore command. It lives in the IMAP setting. It lives in the abstraction layer that swaps a model. It is unglamorous, technical, and decisive.

European today. Sovereign always. Human on the loop. That is the stack we build on, and the standard we hold ourselves to.

Welcome to Radical.