alberaplfirma doradcza

albera.pl / Blog / Prawo

Prawo4 min czytania

OPZ na AI, część 2. Dane i jurysdykcja: suwerenność opisana cechami

O suwerenności danych decyduje to, gdzie są przetwarzane, kto i na jakiej podstawie może po nie sięgnąć oraz ile kosztuje odejście od dostawcy. Pochodzenie dostawcy nie może być wymaganiem, ale cechy rozwiązania mogą

Zamawiający, który chce chronić dane, często myśli o krajowym dostawcy. Prawo zamówień publicznych zabrania jednak opisywania przedmiotu zamówienia przez wskazanie pochodzenia, jeśli mogłoby to uprzywilejować albo wyeliminować niektórych wykonawców (art. 99 ust. 4). Rozwiązanie jest proste: suwerenność trzeba opisać cechami, które da się sprawdzić

Znane miejsce przetwarzania

Oferta powinna wskazywać, gdzie są przetwarzane i przechowywane dane, kopie zapasowe i rejestry zdarzeń, także przy wsparciu technicznym, na przykład w Unii Europejskiej albo w Europejskim Obszarze Gospodarczym. Od tego zależą obowiązki z RODO przy przekazywaniu danych poza EOG. Ostrożnie z wymogiem przetwarzania wyłącznie w jednym państwie: dla danych nieosobowych prawo UE co do zasady zakazuje takich wymogów, także w zamówieniach publicznych, chyba że uzasadnia je bezpieczeństwo publiczne (rozporządzenie (UE) 2018/1807, art. 4)

Dane nie trenują cudzych modeli

Tego, co raz trafiło do trenowania, nie da się wycofać. Dlatego dane, dokumenty, zapytania i odpowiedzi zamawiającego nie powinny służyć do trenowania ani ulepszania modeli dostawcy i jego innych klientów, także u podwykonawców. Po zakończeniu umowy dane wracają do zamawiającego i są usuwane z potwierdzeniem, z wyjątkiem tych, które prawo nakazuje przechowywać. RODO przewiduje zwrot albo usunięcie danych osobowych zależnie od decyzji administratora (art. 28 ust. 3 lit. g)

Kto może sięgnąć po dane

Dostawca powinien wskazać, czy on albo jego podwykonawcy podlegają przepisom państw spoza Unii, które mogą nakazać przekazanie danych, i jak postąpi w takim przypadku. Tam, gdzie wymagają tego dane, klucze szyfrowania powinny być w rękach zamawiającego. Gdy rodzaj danych tego wymaga, na przykład przy danych szczególnie chronionych, można wymagać uruchomienia systemu na infrastrukturze zamawiającego, ale trzeba to uzasadnić w dokumentach zamówienia

Wyjście od dostawcy i dostawcy wysokiego ryzyka

Koszt zmiany dostawcy decyduje o tym, czy organizacja ma jeszcze wybór. Umowa powinna przewidywać eksport danych, dokumentów, konfiguracji i zapisanych poleceń w otwartych formatach oraz znany z góry koszt wyjścia. Przy usługach w chmurze pomaga Akt w sprawie danych: od 12 stycznia 2027 roku dostawcy nie będą mogli pobierać opłat za zmianę dostawcy (art. 29). Jest też jedno miejsce, w którym pochodzenie dostawcy ma znaczenie z mocy ustawy. Od 3 kwietnia 2026 roku zamawiający odrzuca ofertę, która obejmuje produkt ICT wskazany w decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka (art. 226 ust. 1 pkt 19 Pzp). Taką decyzję wydaje minister właściwy do spraw informatyzacji (art. 67b ustawy o krajowym systemie cyberbezpieczeństwa)

Jak to zapisać

  • oświadczenie o miejscu przetwarzania danych, kopii i rejestrów, z obowiązkiem informowania o zmianie
  • zakaz trenowania na danych zamawiającego, także w warunkach usługi modelu i u podwykonawców
  • opis zarządzania kluczami i oświadczenie o przepisach spoza UE
  • plan wyjścia w ofercie i próbny eksport przy odbiorze
  • oświadczenie, że oferta nie obejmuje produktów dostawcy uznanego za dostawcę wysokiego ryzyka

To część 2 z 9 serii „OPZ na AI krok po kroku”. Każde wymaganie z tego wpisu, z podpowiedzią, jak je sprawdzić w ofercie, znajdą Państwo na stronie Czego wymagać od systemu AI i jego dostawcy. Poprzednia część: skład systemu i łańcuch dostaw

Co z tego wynika dla kupującego

  • suwerenność opisana cechami, a nie pochodzeniem dostawcy
  • dane zamawiającego nie trenują cudzych modeli
  • plan wyjścia i eksport w otwartych formatach w umowie
  • oferta bez produktów dostawcy wysokiego ryzyka

Hasła ze Słownika zakupów AI: opis przedmiotu zamówienia (OPZ), NIS2 i krajowy system cyberbezpieczeństwa

Aleksandra Albera

Prawniczka specjalizująca się w prawie nowych technologii: AI Act, systemy zarządzania AI według ISO/IEC 42001, cyberbezpieczeństwo i ochrona danych. Audytor wiodący ISO/IEC 42001. Czuwa nad prawną stroną zamówień, umów i dokumentacji AI