Test suwerenności w przetargach: jak ocenić ofertę, gdy AI stoi on-prem

Czas czytania: ok. 11 minut. Klaster: compliance. Autor: Fryderyk.

Odpowiedź najpierw

Test suwerenności to zapowiedziany przez rząd mechanizm oceny ofert w przetargach IT, który do ceny i funkcjonalności dokłada trzecie pytanie: czy państwo zachowuje kontrolę nad technologią, którą kupuje. Ma dotyczyć zamówień powyżej progów, o których mowa niżej, i na razie jest zapowiedzią z czerwca 2026, a nie obowiązującym prawem.

Najważniejsze nieporozumienie dotyczące tego testu warto rozbroić od razu: test suwerenności nie sprawdza, w jakim kraju zarejestrowany jest dostawca. Sprawdza, kto realnie kontroluje architekturę, do kogo należą wagi modelu i czy rozwiązanie da się przenieść bez zgody dostawcy. Dlatego samo hasło „polska chmura” nie przechodzi testu automatycznie, a system AI postawiony on-prem, z wagami po stronie zamawiającego, przechodzi go z definicji łatwiej, niezależnie od tego, gdzie stoi centrum danych operatora. Poniżej rozkładam, skąd wziął się ten test, jakich progów dotyczy, wokół jakich pięciu kryteriów krąży i co konkretnie sprawdza, gdy przedmiotem zamówienia jest model językowy.

Spis treści

1. Czym jest test suwerenności i skąd się wziął
2. Progi: kiedy test w ogóle wchodzi w grę
3. Pięć kryteriów, wokół których krąży ocena
4. Dlaczego „polska chmura” nie przechodzi testu automatycznie
5. Co test realnie sprawdza przy AI: wagi, architektura, przenośność
6. On-prem a test suwerenności: gdzie wygrywa, a gdzie nie wystarczy
7. Jak przygotować się po stronie zamawiającego i po stronie oferenta
8. FAQ
9. Disclosure i biases
10. Czego tu nie pokrywam
11. Powiązane notatki

Czym jest test suwerenności i skąd się wziął

Test suwerenności technologicznej to propozycja, żeby projekty technologiczne kupowane lub współfinansowane przez państwo oceniać dodatkowo pod kątem ryzyka uzależnienia cyfrowego od globalnych dostawców i utraty kontroli nad własnymi danymi. Zapowiedział go premier w czerwcu 2026, w kontekście Strategii Cyfryzacji Państwa, a jako mechanizm postulowany był wcześniej przez środowiska branżowe skupione wokół idei suwerenności cyfrowej.

Trzeba to powiedzieć wprost, bo od tego zależy, jak traktować cały temat: na dziś test suwerenności jest zapowiedzią kierunku, nie przepisem. Nie ma ustawy, nie ma rozporządzenia, nie ma opublikowanej metodyki punktacji ani terminu wejścia w życie. Dla zamawiającego i dla oferenta znaczy to jedno: warto rozumieć logikę testu i przygotować się do niej wcześniej, ale nie wolno cytować go jako obowiązującego wymogu w dokumentacji przetargowej. Ten tekst opisuje więc zapowiedzianą konstrukcję i jej praktyczne konsekwencje, a nie stan prawny, który dopiero może powstać.

Dlaczego to w ogóle temat dla kogoś, kto wdraża AI. Bo modele językowe są najczystszym przypadkiem, w którym „kupujemy technologię” i „oddajemy kontrolę” potrafią być tym samym zdaniem. Przy klasycznym oprogramowaniu zależność jest widoczna w licencji. Przy modelu dostarczanym jako usługa zależność siedzi w miejscu, którego nie widać w umowie: w tym, że wagi, architektura i pipeline inferencji zostają po stronie dostawcy, a zamawiający dostaje wyłącznie endpoint. Test suwerenności celuje dokładnie w tę różnicę.

Progi: kiedy test w ogóle wchodzi w grę

Zapowiedź wiąże test z wartością zamówienia, a nie z jego rodzajem. Wymieniane progi to około 5 mln zł dla zakupów technologii cyfrowych oraz około 15 mln zł dla projektów infrastrukturalnych. Poniżej tych kwot test, w wersji zapowiadanej, nie byłby obowiązkowy, choć nic nie stoi na przeszkodzie, żeby zamawiający stosował jego logikę dobrowolnie jako element kryteriów pozacenowych.

Dwie rzeczy warto tu zaznaczyć. Po pierwsze, progi odnoszą się do wartości całego zamówienia, a nie do samej warstwy AI, więc wdrożenie modelu bywa objęte testem także wtedy, gdy jest tylko fragmentem większego projektu, na przykład modernizacji systemu dziedzinowego. Po drugie, progi mogą się zmienić, bo pochodzą z zapowiedzi, nie z tekstu ustawy. Traktuj je jako rząd wielkości pokazujący, że test celuje w duże postępowania, a nie w drobne zakupy licencji.

Pięć kryteriów, wokół których krąży ocena

W zapowiedziach i propozycjach branżowych powtarza się pięć wymiarów, które test miałby oceniać. Warto je znać, bo każdy z nich inaczej wypada dla chmury publicznej i dla on-prem:

• Jurysdykcja dostawcy. Czyjemu prawu podlega podmiot kontrolujący technologię i dane. To kryterium najczęściej mylone z całym testem, a jest tylko jednym z pięciu.
• Przenośność. Czy rozwiązanie da się przenieść do innego dostawcy albo w inne środowisko bez jego zgody i bez przepisywania od zera.
• Otwarte standardy. Czy system opiera się na otwartych, udokumentowanych formatach i interfejsach, czy na zamkniętym, własnościowym stacku.
• Bezpieczeństwo łańcucha dostaw. Czy da się prześledzić i zaudytować zależności, od sprzętu przez model po biblioteki.
• Ryzyko uzależnienia od jednego producenta. Czy zamawiający ma realną alternatywę, czy jest zamknięty w jednym ekosystemie.

Zauważ, że tylko pierwszy z tych wymiarów dotyczy geografii. Pozostałe cztery dotyczą kontroli, przenośności i audytowalności, czyli cech architektury, a nie adresu rejestracji. To jest oś całego tekstu.

Dlaczego „polska chmura” nie przechodzi testu automatycznie

Najczęstszy skrót myślowy przy suwerenności brzmi: skoro chodzi o niezależność od zagranicznych gigantów, wystarczy kupić od krajowego dostawcy, najlepiej z centrum danych w Polsce. To rozwiązuje jeden z pięciu wymiarów, jurysdykcję, i nie rusza czterech pozostałych.

Krajowy operator chmury, który stawia zamawiającemu model dostępny wyłącznie przez API, wciąż trzyma wagi po swojej stronie, wciąż kontroluje architekturę i wciąż decyduje, na jakich warunkach da się to przenieść. Zmiana kraju rejestracji nie zmienia tego, że kontrola nad rdzeniem rozwiązania jest po stronie dostawcy, a nie zamawiającego. Test suwerenności, jeśli mierzy przenośność, otwartość i brak vendor lock-inu, wyłapie tę zależność niezależnie od tego, czy serwerownia stoi pod Warszawą, czy pod Frankfurtem.

To nie jest argument przeciw krajowym dostawcom. To argument za tym, żeby oceniać ich tak samo jak każdego innego: po tym, ile kontroli realnie oddają zamawiającemu, a nie po adresie. „Polska chmura” może przejść test suwerenności znakomicie, pod warunkiem że daje przenośność, otwarte interfejsy i dostęp do wag. Może też go nie przejść, jeśli pod krajowym szyldem sprzedaje ten sam zamknięty model zależności co globalny hiperskaler. Kraj rejestracji jest sygnałem, nie dowodem.

Ta sama logika działa w drugą stronę i to jest jej najciekawsza konsekwencja. Model otwartowagowy uruchomiony on-prem, którego wagi pobrano i które zostają po stronie zamawiającego, spełnia rdzeń testu, nawet jeśli sam model powstał poza Polską i poza Europą. Suwerenność w tym ujęciu nie jest cechą pochodzenia technologii, tylko cechą kontroli nad nią po wdrożeniu.

Co test realnie sprawdza przy AI: wagi, architektura, przenośność

Gdy przedmiotem zamówienia jest system oparty na modelu językowym, pięć ogólnych kryteriów sprowadza się do trzech bardzo konkretnych pytań.

Pierwsze: czyje są wagi modelu. To jest pytanie graniczne. Jeśli wagi należą do zamawiającego albo są modelem otwartowagowym pobranym i utrzymywanym lokalnie, kontrola nad rdzeniem inferencji jest po stronie kupującego. Jeśli wagi zostają po stronie dostawcy, a zamawiający dostaje endpoint, całą resztą testu można się już tylko martwić, bo najważniejsza zależność jest przesądzona.

Drugie: czy da się to przenieść bez zgody dostawcy. Chodzi o realny exit, a nie o klauzulę na papierze. Czy da się wyeksportować dane i wektory w otwartym formacie, czy prompty i logika retrievalu nie są zamknięte w własnościowym API, czy odtworzenie działania u innego dostawcy albo we własnym środowisku jest kwestią konfiguracji, czy przepisania projektu od zera. To ten sam problem, który przy ocenie vendorów opisuje się jako warstwy vendor lock-inu.

Trzecie: czy mamy kontrolę nad architekturą i czy da się ją zaudytować. Czy zamawiający wie i może sprawdzić, gdzie trafiają dane wejściowe, jakie zależności ma pipeline, czy da się to zalogować i przejrzeć. To jest dokładnie ta oś, na której chmura publiczna przegrywa nie dlatego, że jest zawodna, tylko dlatego, że nie pozwala prześledzić własnych zależności. Kontrola bez audytowalności jest deklaracją, nie kontrolą.

Te trzy pytania są jednocześnie mapą, gdzie on-prem AI ma naturalną przewagę w teście, i listą miejsc, w których nawet on-prem trzeba dopiąć, żeby przewaga była realna, a nie tylko architektoniczna.

On-prem a test suwerenności: gdzie wygrywa, a gdzie nie wystarczy

On-prem wygrywa test tam, gdzie test mierzy kontrolę. Wagi po stronie zamawiającego, inferencja we własnym perymetrze, dane, które nie opuszczają organizacji, i architektura, którą można zaudytować od sprzętu po bibliotekę. To są cechy, których chmura publiczna z definicji nie daje w komplecie, i to jest powód, dla którego przy poważnym teście suwerenności on-prem przestaje być droższym kaprysem, a staje się najprostszą drogą do spełnienia kryteriów.

To nie znaczy, że on-prem zdaje test automatycznie. Trzy pułapki, w które można wpaść mimo lokalnego wdrożenia:

• Zamknięty stack pod lokalnym szyldem. On-prem oparty na własnościowej platformie, z której nie da się wyjść bez przepisania projektu, spełnia kryterium lokalizacji, a łamie kryterium przenośności. Suwerenność sprzętowa nie leczy uzależnienia software'owego.
• Brak audytowalności mimo lokalnej inferencji. Jeśli system stoi u zamawiającego, ale nie loguje, kto o co pytał i dokąd trafiały dane, kryterium kontroli jest spełnione tylko deklaratywnie. Bez śladu audytowego nie ma czym udowodnić kontroli, a to samo logowanie jest zresztą minimalnym wymogiem po stronie NIS2.
• Zależność od jednego dostawcy utrzymania. On-prem utrzymywany wyłącznie przez jednego integratora, bez dokumentacji pozwalającej przejąć system, przenosi lock-in z warstwy technologii na warstwę kompetencji. Test uzależnienia od jednego producenta wyłapie i to.

Wniosek praktyczny jest taki: on-prem daje najlepszą pozycję wyjściową w teście suwerenności, ale punkty zdobywa się nie samym faktem lokalnego wdrożenia, tylko przenośnością, otwartymi standardami i audytowalnością dopiętymi na etapie architektury.

Jak przygotować się po stronie zamawiającego i po stronie oferenta

Dopóki nie ma metodyki ustawowej, najrozsądniej potraktować pięć kryteriów jako kryteria pozacenowe, które zamawiający może zdefiniować już dziś, a oferent może pod nie przygotować ofertę.

Zamawiający, który chce ocenić suwerenność rozwiązania AI, powinien zażądać w postępowaniu odpowiedzi na konkretne pytania, a nie deklaracji: gdzie fizycznie odbywa się inferencja, czyje są wagi i czy zamawiający je otrzymuje, w jakim formacie da się wyeksportować dane i wektory, jakie interfejsy są otwarte, jak wygląda ścieżka wyjścia od dostawcy i kto poza dostawcą jest w stanie utrzymać system. To jest w istocie ten sam szkielet, którym ocenia się dowolnego vendora AI pod kątem ryzyka, tylko przefiltrowany przez pytanie o kontrolę.

Oferent, który chce wypaść w tym teście dobrze, powinien umieć na te pytania odpowiedzieć twardo, a nie hasłem. „Rozwiązanie suwerenne” nic nie znaczy. „Wagi przekazujemy zamawiającemu, dane nie opuszczają jego perymetru, eksport w otwartym formacie, pełen ślad audytowy, dokumentacja pozwalająca przejąć utrzymanie” znaczy wszystko. Im więcej z pięciu kryteriów oferent potrafi udowodnić dowodem, a nie deklaracją, tym mocniejsza pozycja, niezależnie od tego, czy test stanie się kiedyś obowiązkiem ustawowym, czy zostanie dobrą praktyką zamawiających.

FAQ

Czy test suwerenności już obowiązuje?

Nie. Na sierpień 2026 jest to zapowiedź kierunku polityki, ogłoszona w czerwcu 2026 w kontekście Strategii Cyfryzacji Państwa. Nie ma ustawy, rozporządzenia ani opublikowanej metodyki punktacji. Warto przygotować się do jego logiki, ale nie należy powoływać go jako obowiązującego wymogu w dokumentacji przetargowej.

Od jakiej wartości zamówienia test miałby obowiązywać?

W zapowiedziach padają progi około 5 mln zł dla zakupów technologii cyfrowych i około 15 mln zł dla projektów infrastrukturalnych. Progi odnoszą się do wartości całego zamówienia, więc warstwa AI bywa objęta także wtedy, gdy jest fragmentem większego projektu. Ponieważ pochodzą z zapowiedzi, mogą się zmienić.

Czy kupno od polskiego dostawcy wystarczy, żeby przejść test?

Nie automatycznie. Kraj rejestracji rozwiązuje najwyżej jedno z pięciu kryteriów, jurysdykcję. Pozostałe cztery, przenośność, otwarte standardy, audytowalność łańcucha dostaw i brak uzależnienia od jednego producenta, dotyczą architektury i kontroli, a nie adresu. Krajowy dostawca, który trzyma wagi i zamyka rozwiązanie w własnym API, może testu nie przejść.

Dlaczego on-prem AI ma przewagę w teście?

Bo test mierzy kontrolę, a on-prem z definicji daje jej najwięcej: wagi po stronie zamawiającego, inferencję we własnym perymetrze, dane, które nie wychodzą z organizacji, i architekturę, którą da się zaudytować. To cechy, których chmura publiczna nie oferuje w komplecie. Zastrzeżenie: on-prem zamknięty w własnościowym stacku albo bez audytowalności spełnia test tylko częściowo.

Czy model spoza Europy może przejść test suwerenności?

Tak, jeśli chodzi o model otwartowagowy pobrany i utrzymywany lokalnie, którego wagi zostają po stronie zamawiającego. Suwerenność w ujęciu testu jest cechą kontroli nad technologią po wdrożeniu, a nie cechą pochodzenia modelu. Zamknięte API zagranicznego dostawcy i lokalnie uruchomiony model otwartowagowy tego samego pochodzenia wypadają w teście zupełnie inaczej.

// disclosure i biasesDisclosure i biases

Piszę z perspektywy osoby pracującej nad rozwiązaniami AI uruchamianymi poza chmurą publiczną, więc mam naturalną skłonność do akcentowania przewag on-prem tam, gdzie wchodzi kontrola i audytowalność. Starałem się to zrównoważyć: tekst wprost pokazuje, że on-prem nie przechodzi testu automatycznie i że można w lokalnym wdrożeniu odtworzyć te same zależności, które test ma wyłapać. Wszystkie stwierdzenia o samym teście dotyczą stanu zapowiedzi z połowy 2026 i mogą się zdezaktualizować, gdy powstanie tekst ustawy albo metodyki. To nie jest porada prawna dotycząca konkretnego postępowania.

// co tu nie pokrywamCzego tu nie pokrywam

• Gotowej punktacji ani wag poszczególnych kryteriów, bo metodyka testu nie została opublikowana i każda liczba byłaby zmyślona.
• Interpretacji prawnej konkretnego postępowania o udzielenie zamówienia, bo to zależy od jego przedmiotu i wymaga analizy prawnej, a nie ogólnej.
• Pełnego mapowania testu suwerenności na NIS2, AI Act i RODO, które prowadzę osobno w notatce o cross-mappingu regulacji.
• Metodyki liczenia kosztu on-prem kontra chmura, którą pokrywa osobny tekst o TCO i kalkulator.
• Sizingu sprzętu pod konkretny model, bo to temat prowadzony liczbami z benchmarków, nie regulacją.

Powiązane notatki

• Cross-mapping NIS2, AI Act, RODO, ISO 27001 bez dublowania
• Public cloud LLM a NIS2: szybka analiza Art. 21 ust. 1 lit. d
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe
• DIY, productized czy managed: trzy modele on-prem AI i kto je utrzymuje
• Monitoring i observability dla on-prem LLM: co logować i jak