OPZ na AI, część 6. Warstwa kontroli między ludźmi a modelami: polityka AI egzekwowana przez system

Organizacja, która korzysta z kilku modeli i narzędzi AI, potrzebuje jednego miejsca, w którym egzekwuje swoje zasady. Szósty obszar wymagań opisuje taką warstwę kontroli między ludźmi a modelami. To także obszar, w którym najmocniej spotykają się RODO, AI Act i nadzór KRiBSI, która od 28 października będzie mogła prowadzić kontrole

Jeden kontrolowany punkt dostępu

Wszystkie modele i narzędzia AI są dostępne przez jeden punkt z regułami według użytkownika, roli, rodzaju danych, modelu i środowiska. Działanie reguł można sprawdzić przed uruchomieniem. To ogranicza korzystanie z AI poza kontrolą organizacji i jest warunkiem, żeby polityka korzystania z AI działała naprawdę

Ochrona danych przed wysłaniem do modelu

Dane osobowe i poufne, na przykład PESEL, NIP czy adresy e-mail, są wykrywane i maskowane, zanim zapytanie opuści sieć zamawiającego. Zamiast maskowania system może zapytanie zablokować albo przekazać do decyzji człowieka. To praktyczne wykonanie zasady uwzględniania ochrony danych w fazie projektowania (art. 25 RODO). Zapytania z danymi poufnymi trafiają tylko do modeli w środowisku, które zamawiający dopuścił dla danej kategorii danych, a system ma model zapasowy na wypadek awarii

Rejestr zdarzeń i ochrona przed atakami

Każde wywołanie modelu jest zapisywane w rejestrze zabezpieczonym przed zmianą, z okresem przechowywania i dostępem do treści zapytań ustalonymi przez zamawiającego. Od 2 grudnia 2027 roku podmiot stosujący system wysokiego ryzyka z załącznika III AI Act musi przechowywać rejestry zdarzeń co najmniej przez sześć miesięcy (art. 26 ust. 6). Rejestr przyda się jednak wcześniej, jako dowód przy kontroli i audycie. System powinien też wykrywać próby obejścia zasad modelu (prompt injection, jailbreak) i sprawdzać odpowiedzi, zanim trafią do użytkownika, bo model połączony z danymi i narzędziami organizacji staje się nową drogą ataku

Koszty i zmiana modelu

Zamawiający ustala budżety na zespół, projekt i model, a system wykrywa nietypowe zużycie. Model można zmienić w ustawieniach, bez przebudowy aplikacji, po teście na zbiorze zamawiającego. W zamówieniu publicznym taką zmianę trzeba przewidzieć w postanowieniach umowy (art. 455 ust. 1 pkt 1 Pzp). Przy systemie wysokiego ryzyka zmianę przeprowadza i dokumentuje wykonawca, bo istotna zmiana może uczynić zmieniającego dostawcą w rozumieniu AI Act (art. 25)

Nadzór człowieka i przejrzystość

Kroki krytyczne czekają na zatwierdzenie przez uprawnioną osobę, treści wytworzone przez AI są oznaczane, a uprawnienia agentów do narzędzi są nadawane według użytkownika, roli i zespołu. Od 2 sierpnia 2026 roku AI Act wymaga przejrzystości wobec osób, które mają kontakt z AI (art. 50), a od 2 grudnia 2027 roku nadzoru człowieka nad systemami wysokiego ryzyka (art. 14 i 26)

Jak to zapisać

• pokaz konfiguracji reguł dostępu i ich testu na przykładowych zapytaniach
• test maskowania na zapytaniach z danymi osobowymi w czasie demonstracji
• pokaz rejestru zdarzeń i przykładowy eksport
• wynik testu na przykładowych atakach na model
• postanowienie o zmianie modelu i pokaz zatwierdzania kroku krytycznego

To część 6 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ęść: utrzymanie i odpowiedzialność za całość

Hasła ze Słownika zakupów AI: KRiBSI, podmiot stosujący, system AI wysokiego ryzyka, AI Act

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