Wspólne dowody, odrębne oceny prawne
Rejestr systemów, uprawnień i incydentów może wspierać kilka działań związanych ze zgodnością. Jest użyteczny wtedy, gdy wiadomo, jaki obowiązek potwierdza każdy dokument. Wspólne narzędzie nie sprawia, że wymagania NIS2, AI Act i RODO stają się zamienne.
NIS2 jest dyrektywą wymagającą wdrożenia do prawa krajowego. AI Act i RODO są rozporządzeniami. Najpierw trzeba ustalić zakres właściwych przepisów krajowych NIS2, systemy i role objęte AI Act oraz przetwarzanie danych osobowych. Mogą też obowiązywać dodatkowe regulacje sektorowe.
Gdzie prace się pokrywają
Zarządzanie ryzykiem. Art. 21 NIS2 dotyczy proporcjonalnych środków cyberbezpieczeństwa podmiotów objętych zakresem. Art. 9 AI Act określa zarządzanie ryzykiem przez cykl życia systemu wysokiego ryzyka. Wspólny katalog może wspierać obie analizy, z rozróżnieniem ryzyk dostępności, integralności i poufności od wpływu na zdrowie, bezpieczeństwo i prawa podstawowe.
Monitoring. Monitorowanie bezpieczeństwa i działania AI może korzystać ze wspólnej infrastruktury. Każdy cel wymaga jednak określenia zdarzeń, wskaźników, retencji i dostępu. Panel bezpieczeństwa sam nie potwierdza właściwego działania modelu.
Dokumentacja. Kontrola wersji, odpowiedzialność i zapisy przeglądów mogą być wspólne. Dokumentacja techniczna AI Act z art. 11 i załącznika IV ma wymagania, których ogólna polityka bezpieczeństwa nie zastępuje.
Reakcja na incydenty. Jedna ścieżka wewnętrznej eskalacji może prowadzić do różnych kwalifikacji prawnych, odbiorców i terminów. Incydent bezpieczeństwa, naruszenie ochrony danych i poważny incydent AI mogą się pokrywać, ale mają odrębne przesłanki.
Przydatny wspólny rejestr ryzyk
| Pole | Znaczenie |
|---|---|
| System, dane i proces | Łączy ryzyko z rzeczywistym działaniem. |
| Osoby i usługi objęte wpływem | Pokazuje możliwą szkodę. |
| Właściwe przepisy | Wyjaśnia, jaki obowiązek jest oceniany. |
| Zagrożenie lub scenariusz błędu | Opisuje, co może pójść nieprawidłowo. |
| Prawdopodobieństwo i wpływ | Dokumentuje metodę oceny oraz założenia. |
| Zabezpieczenia i dowody | Pozwala sprawdzić, czy środek został wdrożony i działa. |
| Właściciel i ryzyko pozostające | Przypisuje odpowiedzialność za decyzję. |
| Termin i powód przeglądu | Wiąże rejestr ze zmianami w organizacji. |
Częstotliwość przeglądów wynika z ryzyka i właściwych wymagań. Spotkanie kwartalne albo roczny audyt mogą być wyborem operacyjnym, ale nie stanowią uniwersalnego kalendarza ustawowego każdego rejestru.
DPIA i FRIA wymagają własnych wniosków
DPIA według RODO jest wymagana, gdy przetwarzanie prawdopodobnie powoduje wysokie ryzyko dla praw i wolności osób, z uwzględnieniem art. 35 i właściwych wytycznych organu nadzorczego. Odpowiedzialność spoczywa na administratorze; jeżeli wyznaczono inspektora ochrony danych, należy zasięgnąć jego opinii.
FRIA z art. 27 AI Act dotyczy wskazanych podmiotów stosujących i zastosowań systemów wysokiego ryzyka, z określonymi wyłączeniami. Można ponownie wykorzystać opis procesu, osób i zabezpieczeń, ale trzeba udokumentować spełnienie odrębnych kryteriów każdej oceny. Rozszerzony szablon DPIA nie staje się automatycznie prawidłową FRIA.
Jeden rejestr incydentów, osobne ścieżki zgłoszeń
Wspólna chronologia powinna dokumentować wykrycie, ocenę, decyzje i komunikację. Należy wyznaczyć odpowiedzialność za ustalenie, które obowiązki zgłoszenia mają zastosowanie, w tym RODO, NIS2 lub AI Act. Każda ścieżka powinna wskazywać właściwy organ, odbiorcę i termin.
Nie można zakładać, że jeden raport wysłany do jednego organu spełni wymagania wszystkich regulacji. Przewodnik po raportowaniu NIS2 opisuje etapy z dyrektywy i znaczenie przepisów krajowych.
Narzędzia dopasowane do pracy
Kontrolowany arkusz i repozytorium dokumentów mogą wystarczyć przy niewielkim, dobrze określonym procesie. Dedykowana platforma może ułatwić zarządzanie dostępem, zbieranie dowodów i koordynację wielu osób. Sama liczba pracowników lub arbitralny próg liczby systemów AI nie rozstrzygają wyboru.
Sprawdź, czy użytkownik potrafi znaleźć aktualny dokument, ustalić właściciela, dołączyć dowód i odtworzyć historię decyzji. Miejsce przechowywania i dostęp muszą odpowiadać rodzajowi informacji, w tym danym osobowym lub poufnym.
Kolejność wdrażania
Zinwentaryzuj systemy i istniejące dowody, oceń zakres obowiązków z odpowiednimi specjalistami, wskaż luki i właścicieli działań. Następnie wdrażaj zabezpieczenia, testuj reakcję na incydenty oraz przeglądy i aktualizuj ustalenia.
Harmonogram powinien wynikać z obowiązujących wymagań i rzeczywistego nakładu pracy. Nie ma jednego sześciomiesięcznego programu, który zapewni zgodność każdej organizacji.
Wymagania w projekcie oprogramowania
Wymagania bezpieczeństwa, dokumentacji i nadzoru trzeba określić dla konkretnego zastosowania oraz roli organizacji. Ocenę prawną należy powiązać z decyzjami technicznymi i organizacyjnymi.
Q-Dev to software house QA10. Projektujemy oprogramowanie według uzgodnionego zakresu; cenę i harmonogram ustalamy dla konkretnego projektu. Prawa do kodu przechodzą na klienta po rozliczeniu całego projektu.
Źródła prawne
NIS2 — dyrektywa (UE) 2022/2555, w szczególności art. 20–23; RODO oraz AI Act. Dla danej organizacji trzeba sprawdzić aktualne przepisy krajowe, właściwy organ i wymagania sektorowe. Ten opis nie potwierdza stanu polskiego procesu legislacyjnego w dniu wdrożenia.
SŁOWNIK
Pojęcia z artykułu
Krótkie wyjaśnienia terminów, do których warto wrócić.
Cały słownik