Shadow AI w podmiocie kluczowym i ważnym. Jak ująć ChatGPT w SZBI, zamiast go zakazywać?

Shadow AIShadow AI Korzystanie przez pracowników z zewnętrznych narzędzi sztucznej inteligencji bez zgody i nadzoru organizacji, na przykład wklejanie dokumentów firmy do publicznego czatu z prywatnego konta. to korzystanie z zewnętrznych usług sztucznej inteligencji bez wiedzy i kontroli organizacji: pracownik wkleja fragment umowy do ChatGPT, informatyk prosi Claude’a o poprawienie skryptu z hasłem w środku, handlowiec podłącza asystenta AI do skrzynki pocztowej. Ustawa o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych. nie zna tego pojęcia i niczego takiego nie zakazuje.

Nakazuje za to szacować ryzyko wystąpienia incydentu, zarządzać aktywami, kontrolować dostęp, oceniać dostawców i obsługiwać incydenty. Każdy z tych obowiązków da się przyłożyć do sytuacji, w której informacje podmiotu trafiają do modelu, o którym dział bezpieczeństwa nie wie.

Shadow AI traktuję jak niezarządzaną usługę zewnętrzną i niekontrolowany kanał wypływu informacji, a nie jak osobną kategorię ryzyka, która wymaga osobnego systemu.

Ten tekst jest dla kierowników podmiotówKierownik podmiotu Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie. kluczowych i ważnych oraz osób, którym powierzyli cyberbezpieczeństwo. Opisuję, gdzie w ustawie o KSC, w NIS2Dyrektywa NIS2 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r. i w normie ISO/IEC 27001 jest miejsce na to ryzyko, dlaczego sam zakaz nie broni się przed audytorem, i od czego bym zaczął.

Co właściwie nazywam Shadow AI?

Słowo „AI” w tej nazwie jest mniej ważne niż słowo „shadow”. Chodzi o wszystko, co przetwarza informacje organizacji poza jej wiedzą i kontrolą, tyle że tym razem po drugiej stronie jest model językowy. W praktyce spotykam takie sytuacje:

• pracownik korzysta z publicznego czatu na prywatnym koncie i wkleja do niego dane klientów, dokumentację techniczną, kod, umowy albo dane osobowe;
• ktoś instaluje rozszerzenie AI do przeglądarki albo do środowiska programistycznego, które czyta zawartość każdej otwartej strony lub każdego pliku;
• dział podłącza narzędzie AI do SharePointu, dysku w chmurze, repozytorium kodu albo systemu CRM przez zgodę OAuth, której nikt potem nie przegląda;
• asystent AI dostaje dostęp do poczty i kalendarza;
• informatyk buduje własną automatyzację na kluczu API modelu, a klucz leży w skrypcie;
• pracownik zakłada konto w usłudze AI typu SaaS, płaci kartą służbową i organizacja nie ma nad tym kontem żadnej władzy: ani nad danymi, ani nad tym, kto ma hasło.

Wspólny mianownik jest jeden. Informacja, którą podmiot chroni w swoim systemie informacyjnym, wychodzi poza ten system, a organizacja nie wie, do kogo, na jakich warunkach i na jak długo.

Problemem nie jest model językowy, tylko utrata kontroli nad tym, gdzie płyną informacje i kto ma do nich dostęp.

Czy ustawa o KSC coś o tym mówi?

Wprost nie, i to dobrze, bo ustawa napisana pod konkretną technologię zestarzałaby się w rok. Mówi natomiast rzeczy, które obejmują Shadow AI bez wymieniania go z nazwy.

Art. 8 ust. 1 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSC) nakazuje wdrożyć system zarządzania bezpieczeństwem informacjiSystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. (SZBI) „w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi”. System informacyjny to według art. 2 pkt 14 urządzenia i oprogramowanie „wraz z danymi przetwarzanymi w postaci elektronicznej”. Dane są więc częścią chronionego systemu, a wklejenie ich do zewnętrznego modelu wyprowadza je poza zabezpieczenia, które podmiot dla tego systemu wdrożył.

Dalej art. 8 ust. 1 wymienia to, co SZBI ma zapewnić. Kilka pozycji pasuje do Shadow AI bez naciągania:

• pkt 1: „prowadzenie systematycznego szacowania ryzykaSzacowanie ryzyka Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”. wystąpienia incydentu oraz zarządzanie tym ryzykiem”, czyli scenariusz „dane wychodzą do zewnętrznego modelu” ma być w rejestrze ryzyka, z oceną i decyzją;
• pkt 2 lit. m: „zarządzanie aktywami”, czyli podmiot wie, jakie usługi przetwarzają jego informacje, także te, których nie kupił dział IT;
• pkt 2 lit. n: „polityki kontroli dostępu”, czyli kto i z jakiego konta może dać narzędziu dostęp do danych;
• pkt 2 lit. e: „bezpieczeństwo i ciągłość łańcucha dostawŁańcuch dostaw Dostawcy sprzętu, oprogramowania i usług ICT, od których zależy świadczenie usługi. Ich bezpieczeństwo podmiot uwzględnia w swoim zarządzaniu ryzykiem. produktów ICT, usług ICT i procesów ICT, od których zależy świadczenie usługi”, bo dostawca modelu jest dostawcą usługi ICT;
• pkt 2 lit. d, i oraz j: bezpieczeństwo zasobów ludzkich, edukacja personelu i podstawowe zasady cyberhigieny, bo Shadow AI zaczyna się od człowieka, który chce szybciej skończyć pracę;
• pkt 4: „zarządzanie incydentami”, bo wyciek przez model trzeba obsłużyć jak każdy inny.

NIS2 mówi to samo innymi słowami. Art. 21 ust. 2 dyrektywy NIS2 wymienia wśród obowiązkowych środków bezpieczeństwo łańcucha dostaw (lit. d), praktyki cyberhigieny i szkolenia (lit. g) oraz „bezpieczeństwo zasobów ludzkich, politykę kontroli dostępu i zarządzanie aktywami” (lit. i).

Termin też jest znany. Podmioty, które 3 kwietnia 2026 r. spełniały przesłanki podmiotu kluczowegoPodmiot kluczowy Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. lub ważnego, realizują obowiązki z rozdziału 3 ustawy o KSC w terminie 12 miesięcy od tego dnia (art. 33 ust. 1 ustawy nowelizującej), czyli do 3 kwietnia 2027 r. Ministerstwo Cyfryzacji podaje tę datę wprost jako termin wdrożenia obowiązków, w tym SZBI i obsługi incydentów.

Audytor nie zapyta „czy w firmie jest Shadow AI”, tylko „jak podmiot identyfikuje, ocenia i kontroluje korzystanie przez pracowników z zewnętrznych usług AI, które mogą przetwarzać jego informacje”.

Na to pytanie trzeba mieć udokumentowaną odpowiedź. Polityka z jednym zdaniem „zakazuje się korzystania z ChatGPT” nią nie jest.

Dlaczego zakaz nie działa?

Widziałem organizacje, które zaczęły od zakazu. Efekt był za każdym razem ten sam: ludzie przestali używać modeli na komputerach służbowych i zaczęli na prywatnych telefonach, gdzie nie sięga ani DLP, ani proxy, ani żaden log. Organizacja straciła to, co miała najcenniejszego, czyli wiedzę, że to się dzieje.

Do tego dochodzi ustawa. Art. 8d pkt 4 ustawy o KSC nakazuje kierownikowi podmiotu zapewnić, „że personel podmiotu jest świadomy obowiązków z zakresu cyberbezpieczeństwa i zna wewnętrzne regulacje podmiotu w tym zakresie”. Regulacja, o której wszyscy wiedzą i której nikt nie przestrzega, jest dla audytora gorsza niż jej brak, bo dowodzi, że kierownik o problemie wiedział i wybrał środek, który nie działa.

Zakaz ma sens tylko jako część reguły: „tych danych nie wprowadzasz do żadnego narzędzia poza zatwierdzonym, a zatwierdzone jest to i to”. Bez drugiej połowy zdania zostaje pobożne życzenie.

Jak wpisać Shadow AI do SZBI?

Nie budowałbym osobnego „programu Shadow AI” obok SZBI. Norma ISO/IEC 27001, na której większość podmiotów opiera swój system, jest zbudowana wokół ryzyka: organizacja identyfikuje ryzyko, wybiera sposób postępowania z nim, dobiera zabezpieczenia i sprawdza, czy działają. Załącznik A jest katalogiem referencyjnym, z którego się wybiera, a nie listą do odhaczenia. Shadow AI wchodzi więc do istniejącego ciągu: szacowanie ryzyka, postępowanie z ryzykiem, deklaracja stosowania, zabezpieczenia, monitorowanie.

W rejestrze ryzyka rozbijam Shadow AI na kilka konkretnych scenariuszy, bo jeden wiersz „ryzyko AI” niczego nie mówi:

Numery w ostatniej kolumnie to zabezpieczenia z załącznika A normy PN-EN ISO/IEC 27001:2023-08; przy każdym sprawdź jego brzmienie w swoim wydaniu normy. Kolumna „Środek” jest moją propozycją, nie wymaganiem ustawy: ustawa wymaga, żeby środki były „odpowiednie i proporcjonalne do oszacowanego ryzyka” (art. 8 ust. 1 pkt 2), a co to znaczy w danym podmiocie, wynika z jego rejestru ryzyka.

Organizacja, która korzysta z AI na większą skalę, może sięgnąć po normę ISO/IEC 42001, poświęconą systemowi zarządzania sztuczną inteligencją (polskie wydanie PN-EN ISO/IEC 42001:2026-04). Norma jest adresowana do organizacji, które dostarczają lub wykorzystują produkty albo usługi oparte na systemach AI, więc także do tych, które modele tylko kupują. Nawet wtedy budowałbym jeden system zarządzania z jednym rejestrem ryzyka i jednym przeglądem, a nie trzy równoległe programy zgodności pod trzy dokumenty.

Od czego zacząć?

Pierwsze pytanie audytora będzie brzmiało: jakie narzędzia AI przetwarzają informacje podmiotu? Baza konfiguracji z serwerami i laptopami na to nie odpowie.

Ustawa wymaga zarządzania aktywami (art. 8 ust. 1 pkt 2 lit. m), ale nie mówi, jak ma wyglądać wykaz. Podpowiedź jest w rozporządzeniu wykonawczym 2024/2690, które wiąże wprost tylko wybranych dostawców usług cyfrowych, ale dobrze pokazuje, czego Komisja oczekuje od wykazu aktywów: ma być „kompletny, dokładny, aktualny i spójny”, a zmiany mają być rejestrowane „w możliwy do prześledzenia sposób” (pkt 12.4.1 załącznika). Wytyczne ENISA do tego rozporządzenia dodają klasyfikację aktywów według wymagań poufności, integralności, autentyczności i dostępności (pkt 12.1).

Prowadzę więc osobny rejestr usług AI, a przy każdej usłudze zapisuję:

• właściciela po stronie biznesu i cel, do którego służy;
• rodzaj przetwarzanych informacji i ich klasę;
• typ konta (służbowe, zespołowe, prywatne) i sposób logowania;
• integracje: zgody OAuth, klucze API, wtyczki;
• dostawcę, lokalizację danych, warunki retencji i to, czy dostawca trenuje modele na danych klientów;
• ocenę ryzyka i status: zatwierdzona, tolerowana, zablokowana.

Do tego jedna reguła dla pracowników, którą da się zapamiętać: jeśli narzędzia nie ma w rejestrze, traktuj je jako niezatwierdzone. Rejestr jest jednocześnie najlepszym dowodem dla audytora, bo pokazuje, że podmiot wie, a nie że zgaduje.

Jakie dane mogą trafić do modelu?

Zasady użycia AI piszę w oparciu o klasyfikację informacji, którą podmiot i tak musi mieć (norma ISO/IEC 27001 wymaga jej w zabezpieczeniu 5.12, a wytyczne ENISA podają przykład trzech poziomów: informacje publiczne, wewnętrzne i poufne). Dla użytkownika sprowadzam to do trzech kolorów.

Zielony, dozwolone w każdym narzędziu: informacje publiczne, tłumaczenia tekstów jawnych, szukanie pomysłów, poprawianie stylu tekstu, który i tak trafi na stronę.

Żółty, dozwolone tylko w narzędziach z rejestru: informacje wewnętrzne, dokumentacja operacyjna, kod źródłowy, dane biznesowe, notatki ze spotkań.

Czerwony, zakazane w każdym publicznym lub niezatwierdzonym narzędziu: dane osobowe, dane uwierzytelniające i klucze API, informacje objęte tajemnicą przedsiębiorstwa lub tajemnicą ustawową, dane klientów, opisy architektury i zabezpieczeń infrastruktury, dokumentacja incydentów.

Dane osobowe są na czerwonej liście z dodatkowego powodu: ich przekazanie do zewnętrznego dostawcy to temat z RODO, z powierzeniem przetwarzania i z ewentualnym zgłoszeniem naruszenia, a to osobny reżim, którego tu nie rozwijam.

Czy dostawca modelu to dostawca z łańcucha dostaw?

Tak, i to od momentu, w którym pierwszy pracownik zaczął z niego korzystać, a nie od podpisania umowy. Jeżeli informacje podmiotu przetwarza zewnętrzna usługa, podmiot de facto korzysta z usługi ICT tego dostawcy, więc stosuje się art. 8 ust. 1 pkt 2 lit. e ustawy o KSC. Art. 8 ust. 2 dodaje, co przy tym uwzględnić: „podatności związane z dostawcą” i „ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy”. Art. 21 ust. 3 dyrektywy NIS2 mówi o tym samym.

Nie oznacza to, że każdy duży dostawca modelu wymaga ręcznego audytu. Podejście oparte na ryzyku pozwala oprzeć ocenę na dokumentacji dostawcy i na kilku pytaniach, które rozstrzygają najwięcej:

1. Czy dostawca trenuje modele na danych klientów i czy da się to wyłączyć na poziomie organizacji, a nie pojedynczego użytkownika?
2. Jak długo przechowuje prompty i odpowiedzi i gdzie geograficznie?
3. Czy obsługuje logowanie jednokrotne z naszej tożsamości i czy administrator widzi, kto z czego korzysta?
4. Czy udostępnia logi, które da się włączyć do naszego monitorowania?
5. Czy umowa albo warunki usługi mówią o incydentach po stronie dostawcy i o terminie powiadomienia?

Odpowiedzi trafiają do rejestru usług AI razem z decyzją: zatwierdzamy, zatwierdzamy z ograniczeniem do klasy żółtej, odrzucamy.

Konta, zgody i agenci: gdzie DLP nie sięga

Częsty błąd polega na tym, że po wdrożeniu narzędzia zapobiegającego wyciekom (DLP), które zatrzyma numer PESEL wysyłany do czatu, temat uznaje się za zamknięty. DLP widzi treść. Nie widzi zgody OAuth, którą pracownik dał narzędziu AI na czytanie całego dysku, konta założonego na prywatny adres, rozszerzenia przeglądarki ani tokenu API w skrypcie.

Dlatego zaczynam od tożsamości: usługa AI, jeśli ma być zatwierdzona, loguje przez naszą tożsamość korporacyjną, z uwierzytelnianiem wieloskładnikowym, którego ustawa wymaga „w stosownych przypadkach” (art. 8 ust. 1 pkt 2 lit. l). Konto prywatne do pracy odpada, nie dlatego, że pracownik jest podejrzany, tylko dlatego, że po jego odejściu organizacja nie ma jak tego konta zamknąć ani sprawdzić, co w nim zostało.

Potem przeglądam zgody: aplikacje z dostępem do dysków, poczty i repozytoriów, klucze API i konta serwisowe. Wytyczne ENISA przypominają, że tożsamości nadane systemom, a nie ludziom, wymagają osobnego zatwierdzania i niezależnego nadzoru (pkt 11.5 wytycznych).

Agent AI, który dostał uprawnienia do wykonywania operacji w systemie, to konto serwisowe z szerokim dostępem, a nie „pracownik wkleił coś do czatu”.

Ta różnica będzie rosła. Rozszerzenia do środowisk programistycznych, wtyczki i integracje agentów dostają dziś uprawnienia, których kiedyś nie dałoby się nadać bez wniosku do IT. Kontrola rozszerzeń na stacjach roboczych i przegląd uprawnień aplikacji są w 2026 r. równie ważne jak DLP.

Co robić, gdy dane już wypłynęły?

Prędzej czy później ktoś wklei do publicznego modelu coś z czerwonej listy. Wtedy liczy się, czy scenariusz „nieautoryzowane przekazanie informacji do usługi AI” był wcześniej opisany w procedurze obsługi incydentów.

Definicja incydentu z art. 2 pkt 5 ustawy o KSC obejmuje zdarzenie, które „ma lub może mieć niekorzystny wpływ na bezpieczeństwo systemów informacyjnych”, a to bezpieczeństwo to między innymi odporność „na zdarzenia naruszające poufność” przetwarzanych danych (art. 2 pkt 3d). Jeśli dane pochodzą z systemu objętego SZBI, mamy więc incydent, który podmiot obsługuje (art. 11 ust. 1 pkt 1) i klasyfikuje według progów (art. 11 ust. 1 pkt 3).

Większość wycieków przez model nie sięgnie progów incydentu poważnego, bo te odnoszą się przede wszystkim do zakłócenia świadczenia usługi: liczby użytkowników, czasu oddziaływania, zasięgu geograficznego (art. 11 ust. 4). Jeśli jednak sięgnie, wczesne ostrzeżenie idzie do CSIRT sektorowego w ciągu 24 godzin od wykrycia (art. 11 ust. 1 pkt 4). Jeśli w danych były dane osobowe, równolegle biegnie termin z art. 33 RODO. Kolejność działań mam zapisaną z góry:

1. ustalenie, co dokładnie wysłano, kto, kiedy i do jakiego dostawcy;
2. ustalenie klasy danych i tego, z którego systemu pochodzą;
3. sprawdzenie w rejestrze usług AI warunków dostawcy: retencja, trenowanie, możliwość usunięcia;
4. wniosek do dostawcy o usunięcie danych, jeśli warunki to przewidują;
5. ocena wpływu i klasyfikacja: incydent, incydent poważny, naruszenie ochrony danych osobowych;
6. zgłoszenia w terminach, jeśli są wymagane;
7. wniosek na przyszłość: czy zawiodła reguła, narzędzie, czy szkolenie.

Zdarzenie, które udało się zatrzymać na DLP, też zapisuję. Ustawa nazywa je „potencjalnym zdarzeniem dla cyberbezpieczeństwa” (art. 2 pkt 11e) i takie zapisy są najtańszym dowodem, że monitorowanie działa.

Co pokazać audytorowi?

Nie próbowałbym dowodzić, że „w naszym podmiocie nie ma Shadow AI”. Tej tezy nie da się udowodnić, a jeden log z proxy ją obala. Dowodzić da się czegoś innego: że podmiot ma proces identyfikacji, oceny, zatwierdzania, monitorowania i reagowania na korzystanie z usług AI, także tych niezatwierdzonych.

Każde ogniwo ma swój dowód: polityka z datą i podpisem kierownika, wiersze w rejestrze ryzyka z decyzją, rejestr usług AI z historią zmian, konfiguracja logowania jednokrotnego i DLP, logi z wykrywania, zapisy z obsługi incydentów i protokół z przeglądu. Na przegląd przynoszę kilka liczb, które mówią, czy proces żyje:

• ile usług AI wykryto i ile z nich jest w rejestrze;
• jaki odsetek użytkowników korzysta z zatwierdzonego narzędzia zamiast z prywatnych kont;
• ile prób wysłania danych z czerwonej listy zatrzymano;
• ile zgód OAuth dla aplikacji AI czeka na przegląd;
• ile czasu mija od wykrycia nowej usługi do decyzji o zatwierdzeniu albo blokadzie;
• ile incydentów w roku dotyczyło usług AI.

Dowodem dla audytora nie jest brak Shadow AI, tylko ciąg: zasady, ryzyko, rejestr, zabezpieczenia, logi, incydenty, miary, przegląd.

Gdyby kierownik podmiotu chciał zacząć od jednej rzeczy przed 3 kwietnia 2027 r., poprosiłbym o rejestr usług AI z pierwszymi dziesięcioma pozycjami i o decyzję, które narzędzie jest zatwierdzone dla klasy żółtej. Reszta ciągu buduje się wokół tych dwóch dokumentów.

Stan prawny na dzień publikacji: 29.09.2026. Wpis nie był od tego czasu weryfikowany pod kątem zmian w przepisach. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).