Zakup systemu AI przez JSFP – jakie wymagania wpisać do SWZ, OPZ i umowy z wykonawcą?

Zakup systemu wykorzystującego sztuczną inteligencję przez jednostkę sektora finansów publicznych (JSFP) nie powinien być traktowany jak zakup zwykłego oprogramowania.

W tradycyjnym systemie IT zamawiający koncentruje się na funkcjonalności, dostępności, wydajności, bezpieczeństwie i cenie. Przy AI dochodzą kolejne pytania: do czego system jest przeznaczony, jak został zakwalifikowany na gruncie AI Act, kto jest jego dostawcą, z jakiego modelu korzysta, jakie są ograniczenia systemu, kto może zmienić model, do jakich logów uzyska dostęp jednostka oraz czy dane JSFP mogą służyć do rozwijania usług innych klientów.

JSFP kupuje nie tylko funkcję AI. Jako zabezpieczenie kontraktowe powinna zapewnić sobie informacje, uprawnienia i mechanizmy kontrolne potrzebne do zgodnego z prawem i audytowalnego używania systemu przez cały okres jego życia. Ich zakres zależy od roli jednostki, rodzaju systemu i konkretnego zastosowania.

Stan prawny: 27 sierpnia 2026 r.

Najpierw ustal role – wykonawca nie zawsze jest dostawcą systemu AI

Jednym z pierwszych zadań przed przygotowaniem SWZ powinno być rozpisanie łańcucha dostaw.

Te role mogą należeć do różnych podmiotów. JSFP może zawrzeć umowę z polskim integratorem, który wdraża aplikację zagranicznego producenta, a ta wykorzystuje model GPAI dostarczany jeszcze przez inną organizację. Dlatego już w postępowaniu warto wymagać mapy łańcucha AI obejmującej co najmniej wykonawcę, dostawcę systemu, istotnych podwykonawców, dostawcę chmury i dostawcę modelu.

Role mogą się zmienić – JSFP może przejąć obowiązki dostawcy

Art. 25 AI Act przewiduje, że dystrybutor, importer, podmiot stosujący lub osoba trzecia może zostać uznana za dostawcę systemu AI wysokiego ryzyka, jeżeli:

• umieści własną nazwę lub znak towarowy na systemie wysokiego ryzyka już wprowadzonym do obrotu lub oddanym do użytku;
• dokona istotnej modyfikacji istniejącego systemu wysokiego ryzyka w taki sposób, że pozostanie on systemem wysokiego ryzyka;
• zmieni przeznaczenie systemu, który wcześniej nie był systemem wysokiego ryzyka, w taki sposób, że stanie się on systemem wysokiego ryzyka.

Jeżeli wskutek jednej z tych okoliczności pojawi się nowy dostawca, art. 25 ust. 2 przewiduje także obowiązek ścisłej współpracy pierwotnego dostawcy z nowym dostawcą. Obejmuje on niezbędne informacje, racjonalnie oczekiwany dostęp techniczny i inne wsparcie potrzebne do zgodności, a w odpowiednich przypadkach:

• dokumentację techniczną wystarczającą do oceny zgodności z obowiązkami z art. 16;
• informacje o znanych ograniczeniach i trybach awaryjnych;
• ukierunkowany dostęp techniczny, w tym do testowania i walidacji.

Obowiązek ten nie ma zastosowania, jeżeli pierwotny dostawca wyraźnie określił, że jego system nie może zostać zmieniony w system AI wysokiego ryzyka. Postanowienia zakupowe powinny więc z góry regulować dostęp do informacji i współpracę na wypadek zmiany roli, z poszanowaniem praw własności intelektualnej, informacji poufnych i tajemnic przedsiębiorstwa.

Art. 25 znajduje się w sekcji 3 rozdziału III, a więc jego stosowanie podlega właściwemu harmonogramowi dotyczącemu systemów wysokiego ryzyka. Dla obecnych zakupów ma to już jednak znaczenie kontraktowe: jednostka powinna ograniczyć możliwość zmian przeznaczenia, modelu lub konstrukcji systemu bez wcześniejszej oceny regulacyjnej.

Zmiana przeznaczenia, modelu, architektury lub sposobu oznaczenia systemu, która może wpływać na rolę Zamawiającego na gruncie AI Act, wymaga uprzedniej analizy regulacyjnej i zatwierdzenia zgodnie z procedurą zarządzania zmianą.

Najpierw przypadek użycia, potem OPZ

Dokumentacja zakupowa nie powinna zaczynać się od katalogu funkcji produktu. Najpierw trzeba ustalić:

• jaki proces jednostka chce wspomóc i co dokładnie ma robić system AI;
• jakie dane otrzyma, jaki wynik wygeneruje i jak wynik będzie używany przez człowieka;
• jakie osoby mogą odczuć skutki działania systemu;
• czy rozwiązanie spełnia definicję systemu AI i jakie praktyki z art. 5 trzeba wykluczyć;
• czy zastosowanie może odpowiadać załącznikowi III lub podlegać art. 50;
• czy przetwarzane będą dane osobowe i czy może być wymagana DPIA albo – po spełnieniu przesłanek art. 27 – FRIA;
• jakie znaczenie mają cyberbezpieczeństwo, dostępność i przepisy sektorowe.

OPZ, SWZ i umowa – trzy funkcje jednego zabezpieczenia

OPZ i projektowane postanowienia umowy są elementami SWZ lub jej załącznikami. Poniższe rozróżnienie ma charakter funkcjonalny: pokazuje, w której części dokumentacji dane wymaganie powinno zostać opisane, wykazane i zabezpieczone na okres realizacji zamówienia.

Art. 99 PZP wymaga opisu przedmiotu zamówienia w sposób jednoznaczny i wyczerpujący oraz pozwala odnosić wymagane cechy także do procesów innych etapów cyklu życia przedmiotu zamówienia, jeżeli pozostają związane z zamówieniem i proporcjonalne. Art. 106 pozwala żądać proporcjonalnych przedmiotowych środków dowodowych, przy obowiązku akceptowania środków równoważnych. Art. 242 umożliwia stosowanie kryteriów jakościowych, a art. 455 pozwala przewidywać przyszłe zmiany umowy w jasnych, precyzyjnych i jednoznacznych klauzulach przeglądowych.

Co wpisać do OPZ?

1. Zamierzone przeznaczenie i granice systemu

Opis „system AI wspomagający obsługę mieszkańców” jest niewystarczający. OPZ powinien określać konkretny proces, funkcję AI, dane wejściowe, wynik, znaczenie wyniku, rolę człowieka oraz czynności, których system nie może wykonywać.

System może przygotować propozycję klasyfikacji dokumentu do właściwej kategorii. Wynik wymaga zatwierdzenia przez uprawnionego użytkownika. System nie może samodzielnie wywoływać skutków prawnych wobec osoby ani automatycznie zamykać postępowania.

2. Kwalifikacja systemu i dokumentacja dostawcy

Nie wystarczy zażądać oświadczenia o zgodności z AI Act. Wykonawca powinien wskazać dostawcę systemu, zamierzone przeznaczenie i wersję, modele i istotne komponenty zewnętrzne, kwalifikację regulacyjną, możliwe zastosowanie załącznika III, podstawę ewentualnego powołania się na art. 6 ust. 3 oraz obowiązki transparentności z art. 50.

Jeżeli dostawca uważa, że system odpowiadający załącznikowi III nie powinien zostać uznany za system wysokiego ryzyka na podstawie art. 6 ust. 3, ocena powinna zostać udokumentowana zgodnie z art. 6 ust. 4, a rejestracja wynika z art. 49 ust. 2.

3. Informacje o danych treningowych

Zamawiający nie powinien automatycznie wymagać przekazania całego zbioru treningowego. Bardziej proporcjonalne może być żądanie informacji o typach i źródłach danych, językach, okresie pozyskania, reprezentowanych populacjach, ograniczeniach, znanych lukach, metodzie walidacji oraz źródłach systematycznych błędów.

Przy zastosowaniach w polskiej administracji szczególnie wartościowa jest informacja, czy system był testowany w realiach odpowiadających polskiemu językowi urzędowemu, dokumentom i procesom publicznym.

4. Test odbiorowy na danych reprezentatywnych dla jednostki

Benchmark wykonawcy nie powinien zastępować odbioru. OPZ powinien określić zbiór testowy i legalny sposób jego przygotowania, prawdę referencyjną, czyli prawidłowy wynik ustalony przed testem, wielkość próby, wskaźniki, dopuszczalny poziom wyników fałszywie dodatnich i fałszywie ujemnych, progi akceptacji, zasady ponownego testu oraz skutki niespełnienia parametrów.

Przy systemach wpływających na osoby warto, w zakresie prawnie i metodologicznie dopuszczalnym, analizować różnice parametrów pomiędzy relewantnymi grupami. Jeżeli badanie wymaga wykorzystania cech chronionych, trzeba osobno ustalić podstawę prawną, proporcjonalność i sposób zabezpieczenia danych.

5. Logi – audytowalne, ale proporcjonalne

W zależności od systemu można wymagać rejestrowania wersji modelu i systemu, czasu operacji, użytkownika, istotnych parametrów wejścia, wyniku, interwencji człowieka, akceptacji, korekty albo odrzucenia wyniku oraz błędów i anomalii.

Jednocześnie nie należy automatycznie przechowywać pełnej treści wszystkich dokumentów czy promptów. Logi powinny być objęte minimalizacją danych, kontrolą dostępu, ochroną integralności, uzasadnioną retencją oraz pseudonimizacją lub redakcją, gdy pełna treść nie jest potrzebna. Brak dostępu do logów niezbędnych jednostce do wykonania własnych obowiązków powinien oznaczać niespełnienie wymagania minimalnego.

6. Nadzór człowieka

System powinien umożliwiać człowiekowi obejrzenie wyniku i informacji potrzebnych do jego oceny, odrzucenie rekomendacji, korektę, zatrzymanie procesu, ręczne przejęcie sprawy oraz zarejestrowanie własnej decyzji.

7. Kompetencje i szkolenia

Art. 4 jest już stosowany. W OPZ lub umowie warto przewidzieć szkolenie administratorów, użytkowników i osób sprawujących nadzór, materiały dostosowane do wdrożonej wersji systemu, aktualizacje szkoleń po istotnych zmianach oraz dokumentowanie wykonanych działań.

Obowiązku z art. 4 nie można w całości przenieść na wykonawcę. Wykonawca powinien jednak zapewnić – samodzielnie lub przy udziale dostawcy systemu – wiedzę i szkolenia potrzebne do prawidłowego używania rozwiązania.

8. Dostępność

Jeżeli system ma być używany przez osoby fizyczne, w tym pracowników zamawiającego, art. 100 PZP wymaga uwzględnienia dostępności dla osób z niepełnosprawnościami oraz projektowania dla wszystkich użytkowników, chyba że charakter zamówienia uzasadnia wyjątek. Przy chatbotach, formularzach i interfejsach warto wymagać obsługi klawiaturą, współpracy z technologiami asystującymi, dostępnych komunikatów, alternatywnych sposobów interakcji i dostępności treści generowanych przez system.

9. Cyberbezpieczeństwo właściwe dla AI

Oprócz typowych wymagań dotyczących uwierzytelniania, szyfrowania, uprawnień, API, podatności i reagowania na incydenty trzeba uwzględnić zagrożenia wynikające ze specyfiki AI. W zależności od rozwiązania mogą to być m.in. manipulowanie wejściem, prompt injection, data poisoning, model poisoning, nieuprawnione wydobywanie danych z modelu oraz obchodzenie mechanizmów bezpieczeństwa.

OPZ i umowa powinny określać sposób testowania odporności, zgłaszania podatności i wdrażania poprawek. Wymagania art. 15 dla systemów wysokiego ryzyka będą stosowane zgodnie z właściwym harmonogramem.

Dane JSFP nie powinny służyć do niekontrolowanego trenowania modeli

Zakaz powinien obejmować nie tylko dokumenty przekazane przez jednostkę, ale także prompty, odpowiedzi, feedback, logi, dane telemetryczne, metadane i dane pochodne.

Dane Zamawiającego nie mogą być wykorzystywane do trenowania, dostrajania, oceny ani rozwijania modeli lub usług przeznaczonych dla innych klientów. Odstępstwo wymaga uprzedniego pisemnego uzgodnienia stron, wykazania zgodności takiego wykorzystania z przepisami o ochronie danych osobowych oraz innymi właściwymi regulacjami, a także jednoznacznego określenia ról i odpowiedzialności stron.

Sama zgoda kontraktowa JSFP nie rozstrzyga zgodności wykorzystania danych osobowych do nowego celu. Jeżeli wykonawca zaczyna używać danych do rozwijania własnych modeli, trzeba ponownie ocenić role stron, podstawę prawną, ograniczenie celu i obowiązki transparentności.

Transfery danych poza EOG

Deklaracja „serwery znajdują się w UE” nie zawsze zamyka problem. Trzeba sprawdzić również, skąd możliwy jest dostęp do danych, gdzie działają podwykonawcy oraz czy dane mogą zostać przekazane do państwa trzeciego lub organizacji międzynarodowej.

Art. 44 RODO wymaga, aby transfer danych osobowych poza UE/EOG spełniał warunki rozdziału V RODO, także przy dalszych transferach. W braku decyzji stwierdzającej odpowiedni stopień ochrony konieczne może być zastosowanie odpowiednich zabezpieczeń z art. 46.

Umowa powinna regulować państwa przechowywania danych, miejsca przetwarzania i zdalnego dostępu, podstawę transferu, dalsze transfery, informowanie o zmianach, reagowanie na żądania organów państw trzecich oraz możliwość sprzeciwu wobec zmiany zwiększającej ryzyko prawne.

Co wpisać do SWZ?

SWZ powinna odpowiadać na pytanie, jak wykonawca ma wykazać, że oferowany system rzeczywiście spełnia wymagania. Można wymagać opisu architektury, mapy ról w łańcuchu AI, dokumentacji kwalifikacji, instrukcji używania, raportów z testów, dokumentacji bezpieczeństwa, przykładowych logów, demonstracji nadzoru człowieka, wykazu podwykonawców, informacji o modelach zewnętrznych oraz dowodów dotyczących deklarowanych parametrów.

Art. 106 PZP wymaga, aby środki dowodowe były niezbędne, proporcjonalne i związane z przedmiotem zamówienia. Zamawiający powinien również akceptować środki równoważne.

Tajemnica przedsiębiorstwa nie może oznaczać braku weryfikacji

Dostawca może mieć uzasadniony interes w ochronie kodu, parametrów modelu, szczegółów danych treningowych, dokumentacji technicznej i tajemnicy przedsiębiorstwa. Nie oznacza to jednak, że JSFP powinna zaakceptować brak informacji potrzebnych do zgodnego używania systemu.

Można stosować ograniczony dostęp dla wskazanych osób, bezpieczne repozytorium, wgląd bez prawa kopiowania, raport niezależnego audytora, certyfikat lub inny równoważny dowód. Warunkiem jest to, aby dowód faktycznie pozwalał zweryfikować wymaganie, a nie jedynie stwierdzał, że „system przeszedł audyt”.

Co koniecznie zabezpieczyć w umowie?

1. Utrzymywanie zgodności

Umowa powinna wymagać aktualności dokumentacji, kwalifikacji, instrukcji oraz informacji o modelach, dostawcach i podwykonawcach. Jeżeli podczas kilkuletniej umowy zacznie być stosowany nowy obowiązek regulacyjny, mechanizm kontraktowy powinien pozwalać dostosować system w wymaganym terminie.

2. Zarządzanie zmianą

Trzeba rozróżnić poprawkę, aktualizację, zmianę wersji, zmianę modelu lub jego dostawcy, zmianę przeznaczenia i istotną modyfikację. Umowa powinna określać, które zmiany wymagają powiadomienia, zgody, ponownego testu, aktualizacji dokumentacji i ponownej kwalifikacji regulacyjnej. Klauzule powinny uwzględniać art. 455 PZP.

3. Audyt i dowody zgodności

Umowa powinna dawać JSFP możliwość weryfikacji wykonywania kluczowych obowiązków poprzez prawo audytu, dostęp do dokumentacji i logów, wyniki niezależnego audytu, wyjaśnienia eksperta, testy techniczne i współpracę podczas kontroli organu.

Prawo audytu powinno być proporcjonalne i respektować bezpieczeństwo innych klientów, własność intelektualną oraz tajemnicę przedsiębiorstwa. Niezależny certyfikat lub raport może ograniczać potrzebę audytu własnego w zwykłych warunkach, ale nie powinien go wyłączać po poważnym incydencie, istotnej zmianie systemu lub uzasadnionym podejrzeniu naruszenia.

4. Podwykonawcy i modele zewnętrzne

Umowa powinna zapewniać aktualną informację o istotnych podwykonawcach, dostawcach chmury i modeli oraz lokalizacjach przetwarzania. Zmiana dostawcy podstawowego modelu może wpływać na jakość, bezpieczeństwo, prywatność i kwalifikację systemu, dlatego nie powinna być traktowana jak niewidoczna aktualizacja techniczna.

5. Współpraca przy DPIA i FRIA

Jeżeli spełnione są przesłanki art. 27, FRIA wykonuje właściwy podmiot stosujący, nie dostawca. Nie każda JSFP i nie każdy system AI podlegają FRIA. Umowa powinna wymagać od wykonawcy przekazania dokumentacji, wyjaśnienia ryzyk, dostarczenia właściwych informacji z art. 13, współpracy przy aktualizacji oceny i udziału eksperta w rozsądnym zakresie.

6. Transparentność i obowiązki informacyjne

Art. 50 jest zasadniczo stosowany od 2 sierpnia 2026 r. Komisja opublikowała również niewiążące prawnie wytyczne dotyczące jego stosowania, które pomagają interpretować zakres obowiązków dostawców i podmiotów stosujących.

Przy odpowiednich systemach trzeba określić, kto odpowiada za poinformowanie o interakcji z AI, oznaczanie treści syntetycznych, informacje dotyczące określonej biometrii lub rozpoznawania emocji oraz oznaczenia deepfake i treści wskazanych w art. 50. Obowiązki z art. 26 ust. 11 będą stosowane zgodnie z harmonogramem właściwym dla systemów wysokiego ryzyka.

7. Incydenty

Umowa powinna wymagać szybkiego przekazania informacji o poważnym incydencie, istotnej podatności, degradacji parametrów, systematycznym błędzie, naruszeniu bezpieczeństwa, zmianie wpływającej na kwalifikację oraz incydencie u podwykonawcy lub dostawcy modelu.

8. Monitoring po odbiorze

Umowa powinna określać parametry monitorowane podczas eksploatacji, częstotliwość pomiarów, źródła danych, progi ostrzegawcze i krytyczne oraz działania po wykryciu degradacji. Należy ustalić, kiedy pogorszenie wyniku wymaga ponownego testu, korekty, powrotu do poprzedniej wersji albo czasowego wyłączenia funkcji.

9. Skutki niezgodności

Umowa może wiązać konkretne naruszenia z obowiązkiem usunięcia niezgodności, ponownym testem, wyłączeniem funkcji, wstrzymaniem odbioru lub płatności w prawnie dopuszczalnym zakresie, karą umowną, wykonaniem zastępczym albo rozwiązaniem umowy.

Przykładowe naruszenia to niezgłoszona zmiana modelu, nieuprawnione wykorzystanie danych do trenowania, brak wymaganych logów, niewykonanie obowiązku informacyjnego, niezgłoszona zmiana podwykonawcy, spadek parametrów poniżej minimum i brak eksportu danych po zakończeniu umowy. Zgodnie z art. 433 PZP postanowienia nie mogą m.in. przewidywać kar za zachowanie niezwiązane z przedmiotem umowy ani przerzucać na wykonawcę odpowiedzialności za okoliczności, za które wyłączną odpowiedzialność ponosi zamawiający.

10. Zakończenie umowy i migracja

Plan wyjścia powinien zostać zaprojektowany przed podpisaniem umowy. Należy uregulować eksport danych, logów i konfiguracji, historię wersji, formaty, dokumentację, pomoc migracyjną, usunięcie danych, potwierdzenie usunięcia, zakończenie dostępu podwykonawców i retencję wymaganą przez prawo.

Matryca: gdzie umieścić wymaganie?

Co z systemami istniejącymi i art. 111?

Aktualny art. 111 ust. 2 odnosi się do systemów wysokiego ryzyka wprowadzonych do obrotu lub oddanych do użytku przed właściwą dla danej kategorii datą rozpoczęcia stosowania rozdziału III: przed 2 grudnia 2027 r. dla art. 6 ust. 2 i załącznika III albo przed 2 sierpnia 2028 r. dla art. 6 ust. 1 i załącznika I. Rozporządzenie stosuje się do operatorów takich systemów zasadniczo wtedy, gdy od właściwej daty system zostanie poddany znaczącym zmianom konstrukcji.

Jednocześnie dostawcy i podmioty stosujące systemy wysokiego ryzyka przeznaczone do używania przez organy publiczne mają podjąć działania zapewniające zgodność najpóźniej do 2 sierpnia 2030 r. Dlatego kilkuletnia umowa zawierana obecnie powinna przewidywać dostarczenie brakujących elementów zgodności w odpowiednim terminie.

Unijne klauzule modelowe jako punkt startowy

Public Buyers Community udostępnia zaktualizowane EU AI Model Contractual Clauses: wersję pełną dla systemów wysokiego ryzyka, wersję uproszczoną dla innych systemów, komentarz i tłumaczenia, w tym wersję polską.

Nie jest to kompletna umowa. Klauzule trzeba uzupełnić o kwestie właściwe dla konkretnego postępowania, takie jak odpowiedzialność, testy, płatności, zmiany, kary, własność intelektualna, dane, wyjście z usługi i wymagania polskiego PZP.

Dziesięć pytań przed publikacją SWZ

1. Czy opisaliśmy przeznaczenie, a nie tylko funkcje produktu?
2. Czy znamy wykonawcę, dostawcę systemu, model i istotnych podwykonawców?
3. Czy wiemy, jaka jest przewidywana kwalifikacja AI Act?
4. Czy jednostka otrzyma dokumentację potrzebną do własnych obowiązków?
5. Czy system zapewnia wymagane logi i prawo audytu?
6. Czy odbiór odbędzie się na danych reprezentatywnych dla jednostki?
7. Czy zmiana modelu wymaga powiadomienia lub zgody?
8. Czy dane JSFP są chronione przed nieuzgodnionym wykorzystaniem do trenowania?
9. Czy znamy miejsca przetwarzania oraz potencjalne transfery poza EOG?
10. Czy po zakończeniu umowy uzyskamy dane, logi, konfigurację i dokumentację potrzebną do migracji?

Jeżeli na kilka z tych pytań odpowiedź brzmi „nie wiadomo”, dokumentacja zakupowa prawdopodobnie nie jest jeszcze gotowa.

Podsumowanie

Zakup systemu AI przez JSFP powinien zaczynać się od przypadku użycia i kwalifikacji regulacyjnej, a nie od prezentacji handlowej produktu.

przypadek użycia → role w łańcuchu AI → kwalifikacja → OPZ → dowody w SWZ → test odbiorowy → umowa → monitoring → aktualizacje → ponowna kwalifikacja regulacyjna → zakończenie współpracy

Najważniejszym celem kontraktu jest utrzymanie przez JSFP kontroli nad informacją, dowodami, zmianą i wyjściem z usługi. Przy systemach AI umowa nie jest dodatkiem do compliance. Jest jednym z podstawowych mechanizmów zapewnienia zgodności.

Podstawy prawne i materiały

• AI Act – tekst skonsolidowany na 27 lipca 2026 r. – w szczególności art. 4, 6, 12–15, 25–27, 49–50, 111 i 113.
• Rozporządzenie (UE) 2026/1744 – zmiany harmonogramu i przepisów przejściowych.
• Prawo zamówień publicznych – Dz.U. 2026 poz. 793 – m.in. art. 99, 100, 106, 242, 433 i 455.
• RODO – w szczególności art. 28 oraz rozdział V dotyczący transferów do państw trzecich.
• Wytyczne Komisji dotyczące art. 50 AI Act – niewiążący materiał interpretacyjny opublikowany 20 lipca 2026 r.
• EU AI Model Contractual Clauses – pełna i uproszczona wersja klauzul wraz z komentarzem i tłumaczeniami.