Czas czytania: około 8 minut
Test suwerenności technologicznej w zamówieniach publicznych to na razie zapowiedź, nie obowiązujące prawo. Premier Donald Tusk ogłosił go 2 czerwca 2026 na Europejskim Kongresie Finansowym w Sopocie, a szczegóły nie zostały jeszcze opublikowane. W formie, o której mówią doniesienia, test miałby przy większych zamówieniach IT sprawdzać, czy zakup nie uzależnia państwa od jednego zagranicznego dostawcy: kto kontroluje architekturę systemu, kto ma prawa do wag modelu AI, gdzie leżą dane i czy da się od dostawcy odejść. Dla dostawcy AI wniosek jest prosty, choć przepis jeszcze nie istnieje: kryteria, które test ma mierzyć, to dokładnie to, o co i tak coraz częściej pytają regulowani odbiorcy prywatni. Poniżej rozkładamy, co wiadomo, czego jeszcze nie, i jak przygotować się zawczasu, z tabelą, która mapuje każde spodziewane kryterium na konkretne działanie.
Zacznijmy od zastrzeżenia, bo tu łatwo o nadinterpretację. Na sierpień 2026 nie ma projektu ustawy ani rozporządzenia, które wprowadzałyby ten test, a polskie media wciąż piszą, że rząd go „zapowiada”, jak w relacji serwisu CyberDefence24. Traktujcie ten tekst jako mapę tego, co się zapowiada, a nie opis obowiązku. To rozróżnienie jest istotne właśnie dlatego, że produkt, który pozycjonuje się jako doradca zgodności, nie może mylić projektu z prawem.
Czym jest test suwerenności i na jakim jest etapie
Idea jest prosta: zanim instytucja publiczna kupi duży system IT albo usługę AI, miałaby przejść przez ustrukturyzowaną ocenę, na ile ten zakup pogłębia zależność od zewnętrznego, najczęściej pozaeuropejskiego dostawcy. Nie chodzi o zakaz kupowania od globalnych firm, tylko o świadomą decyzję: co oddajemy pod cudzą kontrolę i czy potrafimy się z tego wycofać.
Na dziś to jednak kierunek polityki, nie procedura. Premier zapowiedział go jako element szerszej strategii cyfrowej suwerenności, wspieranej przez Ministerstwo Cyfryzacji, wraz z zapowiedzią corocznych raportów o postępach w uniezależnianiu się od zewnętrznych technologii. Brakuje natomiast tego, co czyni wymóg wymogiem: aktu prawnego, dokładnej metodyki punktacji i daty wejścia w życie. Dlatego każdą liczbę i każde kryterium poniżej trzeba czytać jako „tak to opisano w doniesieniach”, a nie „tak stanowi przepis”.
Co test miałby oceniać
Z relacji wyłania się dość spójny zestaw kryteriów. Według analizy Forbesa ocena miałaby dotyczyć kontroli państwa nad architekturą systemu, praw do wag modelu AI oraz wolności od uzależnienia od dostawcy. Do tego dochodzi wątek, który komentatorzy wskazują jako sedno: zagrożenie jest „jurysdykcyjne, nie techniczne”, czyli chodzi o ekspozycję danych na obce reżimy prawne, takie jak amerykański CLOUD Act czy FISA 702.
W praktyce sprowadza się to do pięciu pytań, które kupujący miałby zadać o każde większe wdrożenie:
- Kto kontroluje architekturę. Czy instytucja może zrozumieć, audytować i zmieniać sposób działania systemu, czy jest zamknięta w cudzej czarnej skrzynce.
- Czyje są wagi modelu. Czy odbiorca ma prawo do modelu i danych na tyle, by móc je przenieść, czy zostaje z licencją, którą dostawca może zmienić.
- Gdzie leżą dane i czyjemu prawu podlegają. Przetwarzanie w UE i pod prawem UE to inne ryzyko niż dane dostępne dla obcej jurysdykcji.
- Czy istnieje wyjście. Czy da się zmienić dostawcę bez przepisywania wszystkiego od zera, czyli realny plan wyjścia zamiast vendor lock-in.
- Czy jest ślad kontroli. Czy da się wykazać, kto, kiedy i do czego miał dostęp, co łączy test wprost z logiką audytu NIS2.
Warto zauważyć, że żadne z tych pytań nie jest nowe dla nikogo, kto szykował się do audytu NIS2. Test suwerenności przenosi je tylko z poziomu „dobra praktyka” na poziom kryterium w przetargu.
Kogo miałby dotyczyć i od jakiej wartości
Adresatem są instytucje publiczne i ich zakupy, nie firmy prywatne. Doniesienia wskazują progi wartości: test miałby obejmować projekty IT powyżej około 5 mln zł oraz projekty infrastrukturalne powyżej około 15 mln zł. To są jednak liczby z relacji prasowych, a nie z aktu prawnego, więc mogą się zmienić, gdy pojawi się projekt. Mówi się też o celu rozwoju krajowych alternatyw w wybranych, strategicznych segmentach rynku, takich jak chmura dla administracji, bazy danych i systemy klasy enterprise.
Dlaczego więc temat dotyczy dostawcy sprzedającego głównie do przemysłu, a nie do urzędów? Bo kryteria testu rzadko zostają w sektorze publicznym. Gdy państwo formalizuje pytania o jurysdykcję danych, wagi modelu i plan wyjścia, te same pytania szybko pojawiają się w łańcuchach dostaw firm prywatnych, zwłaszcza tych objętych NIS2. Producent, który chce dostarczać do dużego, regulowanego odbiorcy, coraz częściej odpowiada na tę samą listę, tyle że w formularzu vendora, nie w przetargu publicznym.
Tabela: kryterium testu a gotowość dostawcy AI
Najprościej przełożyć zapowiedź na działanie, zestawiając spodziewane kryterium z tym, co znaczy dla dostawcy, i konkretnym krokiem, który już dziś można wykonać.
| Kryterium testu | Co znaczy dla dostawcy AI | Jak być gotowym |
|---|---|---|
| Kontrola nad architekturą | Odbiorca chce móc audytować i zmieniać system | Wdrożenie on-prem lub dedykowana instancja z dokumentacją |
| Prawa do wag modelu | Trzeba pokazać, że model i dane są przenośne | Jasne warunki licencji, możliwość eksportu danych |
| Lokalizacja i jurysdykcja danych | Dane nie mogą podlegać obcemu prawu | Przetwarzanie w UE albo u odbiorcy, udokumentowana granica |
| Brak vendor lock-in | Oceniana jest zależność od jednego dostawcy | Interoperacyjność, standardy, realny plan wyjścia |
| Ślad audytowy i zgodność | Trzeba wykazać kontrolę nad dostępem | Logi, audit trail, spójność z obowiązkami NIS2 |
Wzorzec jest czytelny: żadne z tych kryteriów nie wymaga czekania na ustawę. To są cechy wdrożenia, które albo się ma, albo nie, a test suwerenności co najwyżej podniesie ich cenę rynkową.
Test suwerenności działa jak filtr: przepuszcza dostawców, którzy oddają kontrolę odbiorcy.
Co to realnie oznacza dla dostawcy AI
Najważniejsza zmiana jest w tym, że suwerenność przestaje być argumentem miękkim. Dotąd „dane zostają u was” było zaletą, którą się deklarowało. Test suwerenności zamienia ją w kryterium, które ktoś odhacza w tabeli oceny ofert. Dostawca, który potrafi wykazać kontrolę nad architekturą, jurysdykcję danych i plan wyjścia, przechodzi filtr; dostawca, który tego nie potrafi, odpada, niezależnie od jakości modelu.
To nie jest wyłącznie polska ani wyłącznie publiczna historia. Kierunek jest europejski, o czym pisaliśmy przy okazji danych, że 62% europejskich organizacji skłania się ku suwerennej AI. Polski producent, który celuje w odbiorcę w Niemczech, spotka to oczekiwanie wcześniej niż krajowy przetarg. Dlatego gotowość na test suwerenności warto traktować nie jako koszt zgodności, tylko jako argument sprzedażowy wobec klientów, którzy sami są pod tą samą presją.
Sedno techniczne pokrywa się z tym, co i tak wymusza audyt: dane, których nie wolno wypuścić, mają zostać tam, gdzie odbiorca je kontroluje. Rozłożyliśmy to w tekstach o tym, dlaczego publiczna AI nie przejdzie waszego audytu oraz gdzie naprawdę leży ryzyko wrażliwych danych w AI. Test suwerenności to ta sama logika, tylko wpisana w procedurę zakupu.
Jak przygotować się zawczasu
Skoro kryteria są znane, a przepis dopiero się zapowiada, najlepszy moment na przygotowanie jest teraz, gdy nie ma jeszcze presji terminu.
- Zmapujcie, gdzie idą dane. Dla każdego zastosowania AI ustalcie, czy dane opuszczają środowisko, które kontrolujecie, i czyjemu prawu podlegają. To pierwsza kolumna każdej oceny suwerenności.
- Rozstrzygnijcie model wdrożenia. On-prem albo dedykowana, odizolowana instancja daje odpowiedź na pytania o architekturę i jurysdykcję jednym zdaniem. Który wariant jest właściwy, zależy od wrażliwości danych i skali.
- Zapiszcie plan wyjścia. Udokumentujcie, jak można zmienić dostawcę albo przenieść dane. Sam fakt, że taki plan istnieje, jest odpowiedzią na kryterium vendor lock-in.
- Uporządkujcie ślad audytowy. Logi dostępu i pochodzenia odpowiedzi to jednocześnie wymóg NIS2 i dowód kontroli w teście suwerenności. Jedna praca zamyka dwa fronty.
- Śledźcie projekt, nie nagłówki. Do decyzji zakupowych bierzcie treść aktu, gdy się pojawi, a nie relację prasową. Do przygotowania wystarczą kryteria, które już są znane.
Najgorszy scenariusz to potraktowanie tematu jako odległej polityki i obudzenie się, gdy kryterium suwerenności trafi do konkretnego formularza vendora. Jeśli chcecie sprawdzić, po której stronie tych pytań leży wasze wdrożenie AI, nasz mini-audyt gotowości zajmuje 10 minut i nie wymaga zostawiania danych. Szerszy obraz, kiedy prywatne środowisko w ogóle się opłaca, rozkładamy w tekście o prywatnej AI w produkcji.
Najczęstsze pytania
Czy test suwerenności już obowiązuje?
Nie. Na sierpień 2026 to zapowiedź rządu, ogłoszona przez premiera w czerwcu 2026, bez projektu ustawy, metodyki i daty wejścia w życie. Kryteria są znane z doniesień, ale nie mają jeszcze mocy przepisu.
Kogo miałby dotyczyć?
Instytucji publicznych i ich większych zakupów IT, nie firm prywatnych. W praktyce jednak te same kryteria przenikają do łańcuchów dostaw odbiorców prywatnych, zwłaszcza objętych NIS2, więc dotykają też dostawców sprzedających do przemysłu.
Od jakiej wartości zamówienia?
Doniesienia mówią o progach około 5 mln zł dla projektów IT i około 15 mln zł dla infrastruktury. To liczby z relacji prasowych, nie z aktu prawnego, więc mogą się zmienić przy publikacji projektu.
Co konkretnie test miałby oceniać?
Kontrolę nad architekturą systemu, prawa do wag modelu, lokalizację i jurysdykcję danych, brak uzależnienia od jednego dostawcy oraz ślad kontroli nad dostępem. To w dużej mierze te same pytania, które zadaje audyt NIS2.
Co dostawca AI powinien zrobić już teraz?
Zmapować, gdzie trafiają dane, rozstrzygnąć model wdrożenia, spisać plan wyjścia i uporządkować ślad audytowy. To działania, które i tak wynikają z NIS2, a przygotowują też na kryteria testu suwerenności.
Fryderyk, CortexMine. Piszemy o prywatnej AI dla producentów objętych NIS2, na podstawie własnych wdrożeń i testów.
Wolicie to omówić? Umówcie 30-minutową rozmowę z założycielem, bez pitchu, po prostu o waszym przypadku.