Personal liability zarządu po nowelizacji UKSC: co to znaczy dla decyzji AI

Czas czytania: ~12 min

Dla kogo: CISO, członek zarządu, dyrektor IT i compliance lead w podmiocie kluczowym, który słyszał, że „za NIS2 odpowiada teraz zarząd osobiście", i chce zrozumieć, co to praktycznie znaczy dla decyzji o wdrożeniu AI.

To nie jest porada prawna. To mapowanie struktury obowiązków i pytań, które warto rozstrzygnąć z własną kancelarią. Świadomie nie przytaczam brzmienia ani numeracji konkretnych przepisów — interpretacje praktyczne dopiero się kształtują, a tekst krajowej regulacji weryfikuj u źródła i u prawnika.

Spis treści

1. Co się zmieniło w warstwie odpowiedzialności
2. „Personal liability" — co to realnie oznacza, a czego nie
3. Dlaczego decyzja o AI trafia akurat na to biurko
4. Trzy momenty decyzyjne, w których odpowiedzialność staje się namacalna
5. Co zarząd powinien móc pokazać (ślad decyzyjny)
6. Gdzie w tym wszystkim jest wybór architektury AI
7. Disclosure i biases
8. Co tu nie pokrywam
9. Powiązane

---

1. Co się zmieniło w warstwie odpowiedzialności

NIS2 i jej krajowa transpozycja przesuwają ciężar z „dział IT ma się tym zająć" na „organ zarządzający ma to nadzorować i za to odpowiada". To nie jest kosmetyka. Wcześniej cyberbezpieczeństwo dawało się delegować w dół wraz z odpowiedzialnością. Teraz obowiązek nadzoru nad zarządzaniem ryzykiem jest przypisany do kierownictwa — i tego obowiązku nie da się scedować na podwładnego ani na dostawcę.

W praktyce oznacza to dwie rzeczy. Po pierwsze, zarząd ma obowiązek zatwierdzać i nadzorować środki zarządzania ryzykiem, a nie tylko o nich „wiedzieć". Po drugie, od członków kierownictwa oczekuje się kompetencji pozwalających rozpoznawać i oceniać ryzyko — co implikuje, że „nie znam się na tym" przestaje być linią obrony.

Uwaga: dokładny zakres obowiązków, krąg „kierownictwa" oraz katalog sankcji zależą od finalnej treści krajowej regulacji. Poniższe traktuj jako szkielet do rozmowy z prawnikiem, nie jako wykładnię.

2. „Personal liability" — co to realnie oznacza, a czego nie

Wokół tego hasła narosło sporo nieporozumień, więc rozdzielmy warstwy.

Czym to jest. Reżim przewiduje, że organ zarządzający odpowiada za naruszenie obowiązku nadzoru nad zarządzaniem ryzykiem cyberbezpieczeństwa. To odpowiedzialność za zaniechanie nadzoru, nie za każdy incydent techniczny z osobna. Incydent może się zdarzyć mimo należytej staranności — pytanie regulatora brzmi raczej: czy kierownictwo wdrożyło, zatwierdziło i nadzorowało adekwatne środki.

Czym to nie jest. To nie jest automatyczna odpowiedzialność karna każdego członka zarządu za każdy wyciek. I nie znika z chwilą podpisania umowy z dostawcą — wybór i nadzór nad dostawcą to też element zarządzania ryzykiem, więc „outsourcing" nie przenosi obowiązku nadzoru na zewnątrz.

Praktyczna konsekwencja dla czytelnika tego portalu: jeśli jesteś CISO, twój zarząd zaczyna zadawać pytania, na które wcześniej nie pytał, bo teraz konsekwencja zaniechania jest bliżej niego osobiście. A jeśli jesteś członkiem zarządu — potrzebujesz móc wykazać, że nadzór faktycznie istniał.

3. Dlaczego decyzja o AI trafia akurat na to biurko

Wdrożenie AI w organizacji to często jednoczesny dotyk trzech rzeczy, które reżim traktuje poważnie: przetwarzania dużej ilości danych (w tym wrażliwych), wprowadzenia nowego dostawcy do łańcucha oraz nowej powierzchni ryzyka technicznego.

Gdy te dane trafiają do publicznego API modelu, organizacja wprowadza zewnętrzny podmiot przetwarzający do swojego łańcucha dostaw — i to jest dokładnie ten element, który zarząd ma obowiązek nadzorować. Dlatego pozornie „techniczna" decyzja „którego dostawcy AI użyjemy" przestaje być decyzją wyłącznie działu IT. Staje się elementem, za którego nadzór odpowiada kierownictwo.

To nie znaczy, że zarząd ma czytać dokumentację API. Znaczy, że ma istnieć udokumentowany proces: kto ocenił ryzyko dostawcy, jakie kryteria zastosowano, kto zatwierdził decyzję i na jakiej podstawie.

4. Trzy momenty decyzyjne, w których odpowiedzialność staje się namacalna

Moment 1 — wybór dostawcy. Czy ocena ryzyka dostawcy AI w ogóle się odbyła i czy jest udokumentowana? Brak oceny to nie jest neutralny stan — to brak dowodu na nadzór.

Moment 2 — przepływ danych. Czy organizacja wie i potrafi wykazać, jakie kategorie danych opuszczają jej środowisko (lub nie opuszczają) w trakcie działania systemu AI? „Wydaje nam się, że nic wrażliwego" nie jest odpowiedzią, którą da się obronić przed audytem.

Moment 3 — reakcja na incydent. Czy istnieje plan na sytuację, w której to komponent AI jest źródłem albo wektorem incydentu? Obowiązki zgłoszeniowe nie znikają dlatego, że problem dotyczy „nowej technologii".

W każdym z tych momentów pytanie audytora czy regulatora będzie podobne: pokażcie ślad. Nie intencję, nie deklarację — ślad decyzyjny.

5. Co zarząd powinien móc pokazać (ślad decyzyjny)

Minimalny zestaw artefaktów, które zamieniają „nadzorowaliśmy" z deklaracji w fakt:

• Udokumentowana ocena ryzyka dla wdrożenia AI, z datą i autorem.
• Kryteria wyboru dostawcy i zapis, że zostały zastosowane — w tym jak potraktowano kwestię przepływu danych i podprocesorów.
• Zatwierdzenie na poziomie kierownictwa, z którego widać, że organ zarządzający się tym zajął, a nie tylko dostał notatkę do wiadomości.
• Mapa przepływu danych pokazująca, co i dokąd trafia w działającym systemie.
• Logi i możliwość rekonstrukcji — żeby po incydencie dało się odtworzyć, co się stało.

Wspólny mianownik: audytowalność. Reżim premiuje organizacje, które potrafią pokazać, jak podejmowały decyzje, a nie tylko twierdzić, że były ostrożne.

6. Gdzie w tym wszystkim jest wybór architektury AI

Tu dochodzimy do sedna z perspektywy tego portalu. Architektura wdrożenia AI bezpośrednio wpływa na to, jak łatwo (albo jak trudno) wytworzyć ten ślad decyzyjny.

Wdrożenie oparte o publiczne API modelu wymaga udokumentowania i nadzorowania zewnętrznego przetwarzania danych: gdzie trafiają, kto jest podprocesorem, jak wygląda umowa powierzenia, co się dzieje przy zmianie warunków. To wykonalne, ale generuje ciągły obowiązek nadzoru nad podmiotem, na który organizacja ma ograniczony wpływ.

Wdrożenie on-prem przesuwa granicę: jeśli dane nie opuszczają środowiska, znika spora część pytań o łańcuch dostaw i podprocesorów — za cenę przejęcia odpowiedzialności za własną infrastrukturę, jej utrzymanie i bezpieczeństwo. To nie jest „lepsze", to jest inny rozkład tego samego ryzyka: mniej ryzyka po stronie zewnętrznego dostawcy, więcej po stronie własnych kompetencji operacyjnych.

Świadomość tego rozkładu jest właśnie tym, czego reżim oczekuje od kierownictwa — nie konkretnego wyboru, lecz wykazania, że wybór był świadomy.

Disclosure inline: pracuję nad CortexMine, productized platformą on-prem AI dla europejskich producentów, więc mam interes w kategorii „on-prem / productized". Productized on-prem to jedna z odpowiedzi na problem śladu decyzyjnego, ale nie dla każdego: organizacjom o niskim profilu wrażliwości danych albo bez zaplecza operacyjnego do utrzymania własnej infrastruktury często bardziej opłaca się dobrze udokumentowane wdrożenie chmurowe niż własna serwerownia. Wybór zależy od profilu ryzyka, nie od tego, co akurat buduję.

// disclosure i biases7. Disclosure i biases

Autor pracuje nad CortexMine, productized on-prem AI platform dla europejskich producentów. Ten post dotyka kategorii (on-prem vs publiczna chmura), w której mam oczywisty interes, dlatego analizę odpowiedzialności starałem się trzymać na poziomie neutralnym: opisuję strukturę obowiązków i pytań, nie rekomenduję konkretnego rozwiązania. Tam, gdzie stronniczość mogłaby zaważyć na wnioskach, oznaczam to inline. Treść nie jest poradą prawną.

8. Co tu nie pokrywam

• Brzmienie i numeracja konkretnych przepisów krajowej regulacji — celowo ich nie przytaczam; to musi potwierdzić prawnik na aktualnym tekście ustawy.
• Katalog i wysokość sankcji — celowo nie podaję kwot, bo zależą od finalnej regulacji i kategorii podmiotu.
• Sektory inne niż produkcja i pokrewne podmioty kluczowe — energetyka, zdrowie, finanse mają własną specyfikę.
• Szczegółowe mapowanie obowiązków łańcucha dostaw — pokryte osobno w analizie obowiązków wobec dostawców AI dla podmiotów kluczowych.
• Operacyjny widok wdrożenia AI w produkcji — biznesową perspektywę znajdziesz na aidlafabryk.pl.

9. Powiązane

• NIS2 a vendor AI w łańcuchu dostaw: obowiązki podmiotów kluczowych
• Public cloud LLM a NIS2: szybka analiza wymogów łańcucha dostaw
• Vendor lock-in w AI: trzy warstwy, dwie pułapki kontraktowe