Reading time: about 8 minutes
Poland's technology sovereignty test for public procurement is still a proposal, not binding law. Prime Minister Donald Tusk announced it on 2 June 2026 at the European Financial Congress in Sopot, and the details have not been published yet. In the shape the reports describe, the test would, for larger IT purchases, check whether a deal makes the state dependent on a single foreign vendor: who controls the system architecture, who holds rights to the AI model weights, where the data sits, and whether you can leave the vendor. For an AI vendor the takeaway is simple even though the rule does not exist yet: the criteria the test would measure are exactly what regulated private buyers increasingly ask about anyway. Below we lay out what is known, what is not, and how to get ready in advance, with a table mapping each expected criterion to a concrete action.
Start with the caveat, because this is easy to over-read. As of August 2026 there is no draft act or regulation introducing the test, and Polish media still describe the government as "announcing" it, as in the CyberDefence24 report. Treat this piece as a map of what is coming, not a description of an obligation. That distinction matters precisely because a product that positions itself as a compliance advisor cannot confuse a proposal with a law.
What the sovereignty test is, and what stage it is at
The idea is simple: before a public institution buys a large IT system or AI service, it would run a structured assessment of how far the purchase deepens dependence on an external, usually non-European vendor. It is not a ban on buying from global firms, it is a deliberate decision: what are we handing to someone else's control, and can we pull back from it.
For now, though, this is a policy direction, not a procedure. The prime minister announced it as part of a wider digital sovereignty strategy backed by the Ministry of Digital Affairs, alongside a plan for annual reports on progress toward independence from external technology. What is missing is what turns an intention into a requirement: a legal act, a precise scoring method and an effective date. So every figure and every criterion below should be read as "this is how it was reported", not "this is what the rule says".
What the test would assess
A fairly consistent set of criteria emerges from the coverage. According to Forbes's analysis, the assessment would cover state control over the system architecture, rights to the AI model weights, and freedom from vendor lock-in. On top of that sits a theme commentators call the core of it: the threat is "jurisdictional, not technical", meaning exposure of data to foreign legal regimes such as the US CLOUD Act or FISA 702.
In practice it reduces to five questions a buyer would ask about every larger deployment:
- Who controls the architecture. Can the institution understand, audit and change how the system works, or is it locked inside someone else's black box.
- Whose model weights are they. Does the buyer have enough right to the model and data to move them, or is it left with a licence the vendor can change.
- Where the data sits and whose law governs it. Processing in the EU under EU law is a different risk from data reachable by a foreign jurisdiction.
- Is there an exit. Can you switch vendor without rewriting everything from scratch, a real exit plan rather than vendor lock-in.
- Is there a control trail. Can you show who accessed what and when, which ties the test straight to the logic of a NIS2 audit.
It is worth noting that none of these questions is new to anyone who has prepared for a NIS2 audit. The sovereignty test only moves them from "good practice" up to "criterion in a tender".
Who it would cover, and from what value
The target is public institutions and their purchases, not private firms. Reports point to value thresholds: the test would cover IT projects above roughly 5 million zloty and infrastructure projects above roughly 15 million zloty. These are numbers from press coverage, not from a legal act, so they may change once a draft appears. There is also talk of building domestic alternatives in selected strategic market segments, such as cloud for public administration, databases and enterprise-class systems.
So why does this concern a vendor selling mostly to industry rather than to public offices? Because the test's criteria rarely stay inside the public sector. Once the state formalises questions about data jurisdiction, model weights and exit plans, those same questions quickly show up in the supply chains of private companies, especially ones covered by NIS2. A manufacturer that wants to supply a large, regulated buyer increasingly answers the same list, just on a vendor form rather than in a public tender.
Table: test criterion versus AI vendor readiness
The simplest way to turn the announcement into action is to line up the expected criterion with what it means for the vendor and a concrete step you can take today.
| Test criterion | What it means for an AI vendor | How to be ready |
|---|---|---|
| Control over architecture | The buyer wants to audit and change the system | On-prem or a dedicated instance, with documentation |
| Rights to model weights | You must show the model and data are portable | Clear licence terms, ability to export the data |
| Data location and jurisdiction | Data cannot fall under a foreign legal regime | Processing in the EU or on-site, a documented boundary |
| No vendor lock-in | Dependence on one vendor is being assessed | Interoperability, standards, a real exit plan |
| Audit trail and compliance | You must demonstrate control over access | Logs, an audit trail, alignment with NIS2 duties |
The pattern is clear: none of these criteria requires waiting for a law. They are properties of a deployment you either have or you do not, and the sovereignty test would at most raise their market price.
The sovereignty test acts as a filter: it passes vendors who hand control back to the buyer.
What it really means for an AI vendor
The biggest change is that sovereignty stops being a soft argument. Until now "your data stays with you" was a benefit you asserted. The sovereignty test turns it into a criterion someone ticks on a bid-evaluation sheet. A vendor that can show control over architecture, data jurisdiction and an exit plan passes the filter; a vendor that cannot drops out, regardless of model quality.
This is neither a purely Polish nor a purely public-sector story. The direction is European, which we covered around the finding that 62% of European organisations lean toward sovereign AI. A Polish manufacturer aiming at a buyer in Germany will meet that expectation sooner than any domestic tender. So readiness for a sovereignty test is worth treating not as a compliance cost but as a sales argument toward customers who are under the same pressure themselves.
The technical core overlaps with what an audit forces anyway: data you are not allowed to release should stay where the buyer controls it. We laid that out in the pieces on why public-cloud AI won't pass your audit and where the real risk of sensitive data in AI sits. The sovereignty test is the same logic, only written into the purchasing procedure.
How to get ready in advance
Since the criteria are known and the rule is only being announced, the best time to prepare is now, before any deadline pressure exists.
- Map where the data goes. For each AI use, establish whether the data leaves an environment you control and whose law governs it. That is the first column of any sovereignty assessment.
- Settle the deployment model. On-prem or a dedicated, isolated instance answers the architecture and jurisdiction questions in one sentence. Which variant is right depends on data sensitivity and scale.
- Write down the exit plan. Document how a vendor can be changed or the data moved. The mere fact that such a plan exists is an answer to the vendor lock-in criterion.
- Put the audit trail in order. Access and provenance logs are both a NIS2 requirement and proof of control in a sovereignty test. One piece of work closes two fronts.
- Track the draft, not the headlines. Base purchasing decisions on the text of the act when it appears, not on press coverage. For preparation, the criteria already known are enough.
The worst case is treating this as distant politics and waking up when a sovereignty criterion lands on a specific vendor form. If you want to check which side of these questions your AI deployment falls on, our readiness mini-audit takes 10 minutes and leaves no data behind. The wider picture of when a private environment is worth it at all is in our piece on private AI for manufacturing.
Frequently asked questions
Is the sovereignty test already in force?
No. As of August 2026 it is a government announcement, made by the prime minister in June 2026, with no draft act, method or effective date. The criteria are known from coverage, but they do not yet have the force of a rule.
Who would it cover?
Public institutions and their larger IT purchases, not private firms. In practice the same criteria seep into the supply chains of private buyers, especially those under NIS2, so they reach vendors selling to industry too.
From what contract value?
Reports mention thresholds of around 5 million zloty for IT projects and around 15 million zloty for infrastructure. Those are figures from press coverage, not from a legal act, so they may change when a draft is published.
What exactly would the test assess?
Control over system architecture, rights to model weights, data location and jurisdiction, freedom from single-vendor dependence, and a trail of control over access. Largely the same questions a NIS2 audit asks.
What should an AI vendor do right now?
Map where the data goes, settle the deployment model, write down an exit plan and put the audit trail in order. These follow from NIS2 anyway, and they also prepare you for the sovereignty test criteria.
Fryderyk, CortexMine. We write about private AI for NIS2-covered manufacturers, based on our own deployments and tests.
Prefer to talk it through? Book a 30-minute call with the founder, no pitch, just your case.