The sovereignty test in public procurement: scoring an offer when AI runs on-prem

Reading time: about 11 minutes. Cluster: compliance. Author: Fryderyk.

Answer first

The sovereignty test is a government-announced mechanism for scoring bids in IT tenders that adds a third question to price and functionality: does the state keep control over the technology it buys. It is meant to apply to contracts above the thresholds discussed below, and for now it is an announcement from June 2026, not binding law.

The single most useful thing to clear up straight away is this: the sovereignty test does not check the country where the vendor is registered. It checks who really controls the architecture, who owns the model weights and whether the solution can be moved without the vendor's consent. That is why the phrase "a local cloud" does not pass the test by default, while an AI system deployed on-prem, with the weights on the buyer's side, passes its core more easily, regardless of where the operator's data center physically sits. Below I unpack where the test came from, which thresholds it targets, the five criteria it revolves around and what exactly it checks when the object of the contract is a language model.

Table of contents

1. What the sovereignty test is and where it came from
2. Thresholds: when the test comes into play at all
3. The five criteria the assessment revolves around
4. Why "a local cloud" does not pass the test automatically
5. What the test really checks for AI: weights, architecture, portability
6. On-prem and the sovereignty test: where it wins, where it is not enough
7. How to prepare, on the buyer's side and on the bidder's side
8. FAQ
9. Disclosure and biases
10. What this note does not cover
11. Related notes

What the sovereignty test is and where it came from

The technological sovereignty test is a proposal to assess technology projects bought or co-financed by the state against the risk of digital dependence on global suppliers and loss of control over one's own data. It was announced by the prime minister in June 2026, in the context of the state digitalization strategy, and had earlier been advocated by industry groups organized around the idea of digital sovereignty.

This has to be said plainly, because everything about how to treat the topic depends on it: as of today the sovereignty test is an announced direction, not a rule. There is no act, no regulation, no published scoring methodology and no effective date. For the buyer and for the bidder that means one thing: it is worth understanding the logic of the test and preparing for it early, but it must not be cited as a binding requirement in tender documentation. This note therefore describes the announced construction and its practical consequences, not a legal status that may only come into being later.

Why is this a topic for anyone deploying AI at all. Because language models are the cleanest case in which "we are buying technology" and "we are giving up control" can be the same sentence. With classic software the dependency is visible in the license. With a model delivered as a service the dependency sits in a place the contract does not show: in the fact that the weights, the architecture and the inference pipeline stay on the vendor's side, and the buyer gets nothing but an endpoint. The sovereignty test aims exactly at that difference.

Thresholds: when the test comes into play at all

The announcement ties the test to the value of the contract, not to its type. The thresholds mentioned are around 5 million zloty for purchases of digital technology and around 15 million zloty for infrastructure projects. Below those amounts the test, in the announced version, would not be mandatory, though nothing stops a buyer from applying its logic voluntarily as a non-price award criterion.

Two things are worth flagging here. First, the thresholds refer to the value of the whole contract, not to the AI layer alone, so a model deployment can fall under the test even when it is only a fragment of a larger project, for example the modernization of a line-of-business system. Second, the thresholds may change, because they come from an announcement, not from the text of an act. Treat them as an order of magnitude showing that the test targets large procedures, not small license purchases.

The five criteria the assessment revolves around

Announcements and industry proposals keep returning to five dimensions the test would assess. They are worth knowing, because each of them falls differently for public cloud and for on-prem:

• Vendor jurisdiction. Whose law governs the entity controlling the technology and the data. This is the criterion most often mistaken for the whole test, and it is only one of five.
• Portability. Whether the solution can be moved to another vendor or into another environment without that vendor's consent and without rewriting from scratch.
• Open standards. Whether the system rests on open, documented formats and interfaces, or on a closed, proprietary stack.
• Supply-chain security. Whether the dependencies can be traced and audited, from the hardware through the model to the libraries.
• Single-vendor dependence. Whether the buyer has a real alternative, or is locked into one ecosystem.

Notice that only the first of these dimensions is about geography. The remaining four are about control, portability and auditability, which are properties of the architecture, not of the address of registration. This is the axis of the whole note.

Why "a local cloud" does not pass the test automatically

The most common shortcut around sovereignty goes like this: since the point is independence from foreign giants, it is enough to buy from a domestic vendor, preferably with a data center in the country. That resolves one of the five dimensions, jurisdiction, and touches none of the other four.

A domestic cloud operator that gives the buyer a model available only through an API still holds the weights on its side, still controls the architecture and still decides on what terms it can be moved. Changing the country of registration does not change the fact that control over the core of the solution is on the vendor's side, not the buyer's. The sovereignty test, if it measures portability, openness and the absence of vendor lock-in, will catch that dependency regardless of whether the server room stands near Warsaw or near Frankfurt.

This is not an argument against domestic vendors. It is an argument for assessing them the same way as anyone else: by how much control they really hand to the buyer, not by their address. "A local cloud" can pass the sovereignty test brilliantly, provided it gives portability, open interfaces and access to the weights. It can also fail, if under a domestic banner it sells the same closed model of dependence as a global hyperscaler. The country of registration is a signal, not proof.

The same logic runs the other way, and that is its most interesting consequence. An open-weights model run on-prem, whose weights have been downloaded and stay on the buyer's side, meets the core of the test even if the model itself was created outside Poland and outside Europe. Sovereignty in this sense is not a property of the technology's origin, it is a property of control over it after deployment.

What the test really checks for AI: weights, architecture, portability

When the object of the contract is a system built on a language model, the five general criteria come down to three very concrete questions.

First: who owns the model weights. This is the boundary question. If the weights belong to the buyer, or are an open-weights model downloaded and maintained locally, control over the core of inference is on the buyer's side. If the weights stay with the vendor and the buyer gets an endpoint, you can only worry about the rest of the test, because the most important dependency is already settled.

Second: can it be moved without the vendor's consent. This is about a real exit, not a clause on paper. Whether the data and vectors can be exported in an open format, whether the prompts and retrieval logic are not locked inside a proprietary API, whether reproducing the behavior at another vendor or in your own environment is a matter of configuration or of rewriting the project from scratch. This is the same problem that, in vendor assessment, is described as the layers of vendor lock-in.

Third: do we have control over the architecture and can it be audited. Whether the buyer knows and can verify where the input data goes, what dependencies the pipeline has, whether it can be logged and reviewed. This is precisely the axis on which public cloud loses, not because it is unreliable, but because it does not let you trace your own dependencies. Control without auditability is a declaration, not control.

Those three questions are at once a map of where on-prem AI has a natural advantage in the test, and a list of the places where even on-prem has to be tightened for the advantage to be real, not merely architectural.

On-prem and the sovereignty test: where it wins, where it is not enough

On-prem wins the test wherever the test measures control. Weights on the buyer's side, inference inside its own perimeter, data that does not leave the organization, and an architecture that can be audited from the hardware to the library. These are properties public cloud does not deliver in full by definition, and that is the reason a serious sovereignty test stops making on-prem look like an expensive whim and turns it into the simplest route to meeting the criteria.

That does not mean on-prem passes the test automatically. Three traps you can fall into despite a local deployment:

• A closed stack under a local banner. On-prem built on a proprietary platform you cannot leave without rewriting the project meets the location criterion and breaks the portability one. Hardware sovereignty does not cure software dependence.
• No auditability despite local inference. If the system sits at the buyer's site but does not log who asked what and where the data went, the control criterion is met only on paper. Without an audit trail there is nothing to prove control with, and that same logging is in any case a minimum requirement on the NIS2 side.
• Dependence on a single maintenance vendor. On-prem maintained solely by one integrator, without documentation that lets someone else take the system over, shifts the lock-in from the technology layer to the competence layer. The single-vendor dependence criterion will catch that too.

The practical conclusion is this: on-prem gives the best starting position in the sovereignty test, but the points are earned not by the mere fact of local deployment, but by portability, open standards and auditability nailed down at the architecture stage.

How to prepare, on the buyer's side and on the bidder's side

As long as there is no statutory methodology, the most sensible approach is to treat the five criteria as non-price award criteria that a buyer can define today and a bidder can prepare an offer against.

A buyer who wants to assess the sovereignty of an AI solution should require answers to concrete questions in the procedure, not declarations: where inference physically happens, who owns the weights and whether the buyer receives them, in what format the data and vectors can be exported, which interfaces are open, what the exit path from the vendor looks like and who besides the vendor is able to maintain the system. This is in essence the same skeleton used to assess any AI vendor for risk, only filtered through the question of control.

A bidder who wants to do well in this test should be able to answer those questions with something hard, not with a slogan. "A sovereign solution" means nothing. "We hand the weights to the buyer, the data does not leave its perimeter, export is in an open format, there is a full audit trail, and there is documentation that lets maintenance be taken over" means everything. The more of the five criteria a bidder can back with evidence rather than a declaration, the stronger the position, regardless of whether the test ever becomes a statutory obligation or stays a good practice of buyers.

FAQ

Is the sovereignty test already in force?

No. As of August 2026 it is an announced direction of policy, made in June 2026 in the context of the state digitalization strategy. There is no act, regulation or published scoring methodology. It is worth preparing for its logic, but it should not be invoked as a binding requirement in tender documentation.

From what contract value would the test apply?

The announced thresholds are around 5 million zloty for purchases of digital technology and around 15 million zloty for infrastructure projects. The thresholds refer to the value of the whole contract, so the AI layer can be covered even when it is a fragment of a larger project. Since they come from an announcement, they may change.

Is buying from a Polish vendor enough to pass the test?

Not automatically. The country of registration resolves at most one of the five criteria, jurisdiction. The other four, portability, open standards, supply-chain auditability and the absence of single-vendor dependence, are about architecture and control, not the address. A domestic vendor that holds the weights and locks the solution inside its own API may fail the test.

Why does on-prem AI have an advantage in the test?

Because the test measures control, and on-prem gives the most of it by definition: weights on the buyer's side, inference inside its own perimeter, data that does not leave the organization, and an architecture that can be audited. These are properties public cloud does not offer in full. Caveat: on-prem locked in a proprietary stack, or without auditability, meets the test only partly.

Can a model from outside Europe pass the sovereignty test?

Yes, if it is an open-weights model downloaded and maintained locally, whose weights stay on the buyer's side. Sovereignty in the sense of the test is a property of control over the technology after deployment, not a property of the model's origin. A foreign vendor's closed API and a locally run open-weights model of the same origin score completely differently.

// disclosure & biasesDisclosure and biases

I write from the perspective of someone working on AI solutions run outside the public cloud, so I have a natural tendency to stress the advantages of on-prem where control and auditability come into play. I have tried to balance that: the text says plainly that on-prem does not pass the test automatically and that a local deployment can reproduce the very dependencies the test is meant to catch. All statements about the test itself concern the state of the announcement from mid-2026 and may go out of date once the text of an act or a methodology exists. This is not legal advice on any specific procedure.

What this note does not cover

• A ready scoring scheme or the weights of individual criteria, because the methodology of the test has not been published and any number would be invented.
• The legal interpretation of any specific award procedure, because that depends on its subject and requires legal analysis, not a general one.
• The full mapping of the sovereignty test onto NIS2, the AI Act and the GDPR, which I run separately in the note on cross-mapping regulations.
• The methodology of costing on-prem versus cloud, which a separate text on TCO and the calculator covers.
• Hardware sizing for a specific model, because that is a topic driven by benchmark numbers, not by regulation.

Related notes

• Cross-mapping NIS2, AI Act, GDPR, ISO 27001 without duplication
• Public cloud LLM and NIS2: a quick read of Art. 21(1)(d)
• Vendor lock-in in AI: three layers, two contractual traps
• DIY, productized or managed: three on-prem AI models and who maintains them
• Monitoring and observability for on-prem LLM: what to log and how