W wykazie KSC jest 70 tysięcy firm, 62 tysiące wpisano z urzędu. Jeśli jesteście w środku, Wasze narzędzia AI właśnie weszły w zakres

Co się stało 3 października i dlaczego większość firm tego nie zauważyła

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa z 23 stycznia 2026 roku (Dz.U. 2026 poz. 252) weszła w życie 3 kwietnia 2026 roku i zastąpiła stary podział na operatorów usług kluczowych i dostawców usług cyfrowych nowym: podmioty kluczowe i podmioty ważne. Podmioty, które spełniały kryteria w dniu wejścia w życie, miały sześć miesięcy na złożenie wniosku o wpis do wykazu — czyli czas do 3 października 2026 roku. Wykaz otwarto 13 kwietnia, od 13 kwietnia do 6 maja minister dokonywał wpisów z urzędu, samodzielna rejestracja ruszyła 7 maja, a system S46 udostępniono nowym podmiotom 12 czerwca.

Najciekawsza liczba w tym wszystkim to nie 70,4 tys., a proporcja. Sześćdziesiąt dwa tysiące trzysta wpisów z urzędu wobec ośmiu tysięcy stu zgłoszeń własnych oznacza, że dla ogromnej większości objętych podmiotów ta zmiana przyszła z zewnątrz — ktoś je wpisał, a nie one same stwierdziły, że podlegają. To dokładnie ten sam mechanizm zaskoczenia, który opisywaliśmy przy e-Doręczeniach: obowiązek zaczyna biec niezależnie od tego, czy ktoś w firmie o nim wie, a zawiadomienia trafiają do kanału, do którego nikt nie zagląda.

Druga rzecz, która zaskakuje firmy, to kryteria kwalifikacji. O objęciu decyduje połączenie dwóch rzeczy: przynależność do sektora z załączników 1 i 2 do ustawy oraz wielkość przedsiębiorstwa liczona według załącznika I do rozporządzenia Komisji (UE) nr 651/2014. Jak zwracał uwagę Aleksander Elmerych z kancelarii Traple Konarski Podrecki i Wspólnicy, przy samoidentyfikacji nie wystarczy sprawdzić głównego kodu PKD — liczy się faktyczny zakres czynności, także działalność uboczna i usługi świadczone wewnątrz grupy kapitałowej. Dlatego w wykazie znalazły się firmy, które nigdy nie uważały się za infrastrukturę krytyczną: hurtownie spożywcze, producenci oprogramowania w modelu SaaS, firmy budowlane.

Dla czytelnika tego bloga najważniejszy jest jednak jeden sektor z listy kluczowej: zarządzanie usługami ICT. Obejmuje on dostawców usług zarządzanych i dostawców usług zarządzanych w zakresie cyberbezpieczeństwa, a definicja opiera się na instalowaniu, eksploatacji lub konserwacji produktów, usług, procesów ICT albo systemów informatycznych przez wsparcie lub aktywną administrację — na miejscu albo zdalnie. Jeśli ktoś utrzymuje dla Was zdalnie asystenta AI, integracje i serwery, na których to stoi, prawdopodobnie mieści się w tej definicji. A to oznacza, że obowiązki nie kończą się na Was, tylko idą w głąb łańcucha.

Wpis do wykazu to deklaracja statusu, nie zgodność

Tu zaczyna się najczęstsze nieporozumienie, które widzimy w rozmowach z klientami od dwóch tygodni. Firma, która została wpisana do wykazu i odhaczyła sprawę, uważa temat za zamknięty. Tymczasem wpis jest deklaracją statusu, a nie potwierdzeniem, że cokolwiek wdrożono. Realne obowiązki są rozłożone na następne dwa lata i to one kosztują.

Harmonogram wygląda następująco. Do 3 kwietnia 2027 roku podmioty kluczowe i ważne muszą wdrożyć systemowe podejście do cyberbezpieczeństwa oparte na analizie ryzyka, w tym system zarządzania bezpieczeństwem informacji, procedury zgłaszania incydentów, wskazanie osób kontaktowych, weryfikację osób na stanowiskach związanych z bezpieczeństwem oraz podłączenie do systemu S46. Do 3 kwietnia 2028 roku podmioty kluczowe, które wcześniej nie były operatorami usług kluczowych, mają przeprowadzić pierwszy audyt bezpieczeństwa, a potem powtarzać go co najmniej raz na trzy lata. Od tego momentu organy mogą też generalnie nakładać kary administracyjne — z wyjątkiem kary do 100 mln zł, która jest możliwa od dnia wejścia nowelizacji w życie.

Skala kar zmieniła się nieporównywalnie wobec ustawy z 2018 roku, gdzie maksima wynosiły 200 tys. zł dla operatora usługi kluczowej i 100 tys. zł dla dostawcy usługi cyfrowej. Teraz podmiot kluczowy odpowiada do 10 mln euro albo 2% światowego obrotu rocznego, podmiot ważny do 7 mln euro albo 1,4%, z karami minimalnymi odpowiednio 20 tys. i 15 tys. zł. Osobna konstrukcja dotyczy kierownictwa: kara osobista do 300% wynagrodzenia (100% w podmiotach publicznych) oraz możliwość zakazu pełnienia funkcji kierowniczych do czasu usunięcia naruszeń. Do tego dochodzi obowiązek corocznego, udokumentowanego szkolenia kierownika podmiotu z cyberbezpieczeństwa.

Warto też wiedzieć, że przepisy o dostawcach wysokiego ryzyka, polecenia zabezpieczające i część przepisów o karach zostały skierowane przez Prezydenta do Trybunału Konstytucyjnego w trybie kontroli następczej. To nie wstrzymuje ustawy ani terminów, ale oznacza, że szczegóły w jednym konkretnym obszarze mogą się jeszcze zmienić. Lista dostawców wysokiego ryzyka na sierpień 2026 roku nie istniała i nie toczyło się żadne postępowanie w tej sprawie — obowiązek oceny ryzyka produktów, usług i procesów ICT istnieje jednak niezależnie od tego, czy taka lista powstanie.

Dlaczego to problem projektu AI, a nie tylko działu IT

Mogłoby się wydawać, że to temat dla administratora i kancelarii, a projekt AI toczy się obok. W praktyce trzy rzeczy sprawiają, że narzędzia AI są jedną z najbardziej kłopotliwych pozycji w tej inwentaryzacji — i jednocześnie jedną z najłatwiejszych do uporządkowania, jeśli zrobi się to teraz.

Po pierwsze, narzędzie AI jest usługą ICT jak każda inna i nie zyskuje żadnego specjalnego statusu dzięki temu, że jest nowoczesne. Jeśli przetwarza Wasze dokumenty, maile, dane klientów albo zapytania z CRM, to wchodzi do zakresu analizy ryzyka. Problem jest w tym, że większość firm nie potrafi wymienić, ile takich narzędzi faktycznie u nich działa — bo część z nich została uruchomiona bez działu IT.

Po drugie, nowoczesne wdrożenia AI nie są pasywne. Asystent podłączony do systemów firmy przez integracje czyta dane, zapisuje dane i wykonuje działania w Waszym imieniu — opisywaliśmy to w tekście o MCP. Z punktu widzenia bezpieczeństwa to nie jest aplikacja, to jest konto z uprawnieniami. A konto z uprawnieniami, które nie figuruje w żadnym rejestrze, jest dokładnie tym, czego audyt szuka.

Po trzecie, narzędzia AI mają nietypowy profil ryzyka, którego klasyczne procedury nie przewidują. Treść, którą model czyta, może zawierać polecenie — mechanizm rozłożyliśmy w tekście o prompt injection. Dostawca modelu może wycofać wersję, na której stoi Wasz proces, co opisywaliśmy przy umowach z dostawcą AI. A przeglądarka z agentem klikającym za pracownika potrafi obejść połowę zabezpieczeń przeglądarkowych, o czym pisaliśmy przy przeglądarkach AI. Każda z tych trzech rzeczy jest zdarzeniem, które trzeba umieć rozpoznać, zarejestrować i w określonych przypadkach zgłosić.

Inwentaryzacja narzędzi AI, którą i tak musieliście zrobić

Pierwszy obowiązek praktyczny brzmi nudno i jest najtańszy: trzeba wiedzieć, co macie. Firma, która nie potrafi wymienić swoich systemów informacyjnych, nie zbuduje analizy ryzyka, bo nie ma dla czego. W obszarze AI ta lista jest zwykle o rząd wielkości dłuższa, niż spodziewa się zarząd, a jej skompletowanie zajmuje tydzień.

Dla każdego narzędzia zapisujecie siedem rzeczy — i to jest cały formularz, bez względu na to, czy mówimy o licencji korporacyjnej za 200 tys. zł, czy o darmowym koncie, które ktoś założył w marcu:

• Kto jest dostawcą i na jakiej umowie to działa. Umowa firmowa z przetwarzaniem danych, licencja indywidualna, darmowy plan zaakceptowany kliknięciem regulaminu — to trzy różne poziomy ryzyka i trzy różne rozmowy.
• Jakie dane tam trafiają i z jakich systemów. Nie „dane firmowe”, a konkretnie: treść maili z jednej skrzynki, dokumenty z jednego katalogu, dane klientów z CRM, pliki kadrowe. Jeśli są tam dane osobowe, to równolegle macie temat RODO i ocenę skutków.
• Jakie uprawnienia ma narzędzie w Waszych systemach. Tylko czyta, czy też zapisuje, wysyła, zatwierdza, usuwa. To pytanie rozstrzyga, czy incydent z udziałem tego narzędzia jest kłopotem, czy katastrofą.
• Gdzie fizycznie odbywa się przetwarzanie i czy dane są używane do trenowania modelu dostawcy. Odpowiedź musi wynikać z umowy albo warunków, a nie z zapewnienia handlowca.
• Kto w firmie jest właścicielem tego narzędzia — imiennie. Nie dział, a osoba, która odpowiada za decyzję o jego używaniu i wie, co się stanie, jeśli przestanie działać.
• Co się dzieje z procesem, jeśli dostawca zniknie na tydzień. Dla większości narzędzi odpowiedź brzmi „nic groźnego”, a wtedy nie trzeba wokół nich budować procedur. Dla dwóch albo trzech odpowiedź jest inna i właśnie na nich skupicie uwagę.
• Czy to narzędzie zostało kiedykolwiek przetestowane i na jakim zestawie przypadków. Bez tego nie wiecie, czy działa poprawnie — a co dopiero, czy nadal działa poprawnie. Metodę opisaliśmy w tekście o testowaniu wdrożenia AI.

Wasz dostawca AI jest dostawcą ICT, nawet jeśli nikt go tak nie nazwał

Obowiązki dotyczące łańcucha dostaw ICT są tą częścią ustawy, która najmocniej uderza w projekty AI, bo zmieniają sposób, w jaki trzeba takie narzędzie kupować. Podmiot kluczowy i ważny ma aktywnie oceniać i monitorować dostawców ICT, dostosować do tego umowy, mieć możliwość audytu dostawcy i przyjąć odpowiedzialność za incydenty pochodzące z łańcucha dostaw. Dostawca uznany za wysokiego ryzyka może być ograniczony albo wykluczony.

W praktyce oznacza to, że umowa na asystenta AI przestaje być umową na narzędzie, a staje się umową na usługę ICT w regulowanym środowisku. Minimum, które powinno się w niej znaleźć, to obowiązek powiadomienia Was o incydencie w czasie, który pozwoli Wam zmieścić się we własnych terminach ustawowych, prawo audytu lub przekazania wyników audytów dostawcy, lista podwykonawców i ich zmian, zasady retencji i usunięcia danych po zakończeniu umowy oraz jasność co do tego, na jakich modelach i w jakich lokalizacjach usługa jest świadczona. Co jeszcze powinno znaleźć się w takiej umowie, niezależnie od NIS2 — zwłaszcza w kwestii wersji modelu i planu wyjścia — zebraliśmy w osobnym tekście.

Jest też druga strona tej samej monety i dotyczy ona wielu czytelników bezpośrednio. Jeśli Wasza firma dostarcza komukolwiek oprogramowanie, utrzymuje zdalnie systemy klientów albo prowadzi helpdesk, to prawdopodobnie sami jesteście dostawcą zarządzanych usług ICT — a to sektor kluczowy. Status zależy od wielkości: przy dostawcy usług zarządzanych duży przedsiębiorca jest podmiotem kluczowym, a średni podmiotem ważnym, natomiast przy usługach zarządzanych w zakresie cyberbezpieczeństwa kwalifikacja zaczyna się już od małego przedsiębiorcy. Nawet jeśli nie podlegacie, Wasi klienci będą pytać o status KSC w ankietach bezpieczeństwa, bo mają obowiązek oceniać dostawców. To pytanie już się pojawia w zapytaniach ofertowych i firma, która nie ma na nie odpowiedzi, wypada z krótkiej listy bez żadnego postępowania administracyjnego.

Praktyczny wniosek jest taki: inwentaryzacja dostawców AI i inwentaryzacja Waszych własnych usług dla klientów to jedno ćwiczenie, nie dwa. Wykonajcie je razem, zanim ktoś przyśle pierwszą ankietę na trzydzieści pytań.

Agent z uprawnieniami to konto w systemie, nie funkcja w aplikacji

System zarządzania bezpieczeństwem informacji, który trzeba mieć do 3 kwietnia 2027 roku, opiera się na dość klasycznych rzeczach: kontroli dostępu, zasadzie minimalnych uprawnień, rejestrowaniu zdarzeń, zarządzaniu zmianą i okresowym przeglądzie. Problem polega na tym, że wdrożenia AI z ostatnich dwóch lat były projektowane pod kątem skuteczności, nie rozliczalności — i prawie zawsze łamią te zasady w tym samym miejscu.

Najczęstszy wzorzec, który zastajemy: asystent działa na koncie integracyjnym z szerokimi uprawnieniami, bo tak było szybciej na etapie uruchomienia. Konto nie ma właściciela, hasło albo token leży w zmiennych środowiskowych u dostawcy, logi istnieją po stronie narzędzia, ale nie po stronie Waszych systemów, a nikt nigdy nie sprawdził, co dokładnie ten asystent może zrobić, gdyby zrobił coś niezamierzonego. Z punktu widzenia bezpieczeństwa to jest konto serwisowe bez nadzoru i tak zostanie opisane w audycie.

Uporządkowanie tego nie wymaga przebudowy wdrożenia i zwykle zajmuje kilka dni. Agent dostaje własną tożsamość w Waszych systemach, a nie konto pożyczone od administratora albo od pracownika. Uprawnienia zawęża się do operacji, których faktycznie używa — i to się sprawdza na logach, a nie na deklaracji. Każde działanie zapisujące jest rejestrowane po Waszej stronie, z informacją kto, co i na podstawie czego. Operacje nieodwracalne — płatność, wysłanie oświadczenia, usunięcie danych, zmiana statusu zamówienia — zawsze mają w ścieżce człowieka. A dostępy przegląda się okresowo, bo narzędzie, które pół roku temu potrzebowało dostępu do jednego katalogu, dzisiaj zwykle ma dostęp do czterech.

Jeśli szukacie argumentu, żeby to zrobić mimo braku bezpośredniego nakazu w tej konkretnej formie: wdrożenie, którego nikt nie dotyka, degraduje się po cichu niezależnie od przepisów. Wymóg regulacyjny jedynie wyznacza termin tej pracy.

Incydent z udziałem AI: 24 godziny, 72 godziny, miesiąc

Zgłaszanie incydentów poważnych jest w tej ustawie trzystopniowe i warto znać te liczby na pamięć, bo nie da się ich nadrobić później. Wczesne ostrzeżenie składa się w ciągu 24 godzin od wykrycia, właściwe zgłoszenie w ciągu 72 godzin, a raport końcowy w ciągu miesiąca od zgłoszenia. Wszystko idzie przez system S46 do właściwego CSIRT. Obowiązek ten dotyczy incydentów poważnych — nie każde zdarzenie w firmie trzeba zgłaszać i ocena, czy próg został przekroczony, jest osobnym tematem, który warto przepracować z prawnikiem przed pierwszym incydentem, a nie w jego trakcie.

Zegar 24 godzin biegnie od wykrycia. To znaczy, że cała gra toczy się o to, czy w ogóle wykryjecie — i tutaj narzędzia AI są wyjątkowo kłopotliwe, bo ich awarie często nie wyglądają jak awarie. Model, który zaczął zwracać błędne klasyfikacje po aktualizacji u dostawcy, nie wywoła alertu. Asystent, który na skutek wstrzykniętej instrukcji wysłał dane pod zewnętrzny adres, zostawi po sobie poprawnie wykonaną operację. Dlatego wykrywalność w tym obszarze nie bierze się z monitoringu infrastruktury, a z pomiarów jakości działania modelu i z logów operacji zapisujących.

Warto przejść przez cztery scenariusze na papierze, zanim staną się rzeczywistością. Pracownik wkleił dokument z danymi klientów do publicznego narzędzia — kto to zauważa, kto kwalifikuje zdarzenie, czy idzie zgłoszenie do CSIRT, czy do UODO, czy do obu. Dostawca modelu zgłosił incydent u siebie — czy umowa daje Wam informację w czasie, który pozwoli Wam zmieścić się w 24 godzinach. Agent wykonał operację masową na skutek treści przeczytanej z zewnątrz — kto ma prawo to zatrzymać i w jakim czasie. Usługa dostawcy przestała działać na dwa dni i proces oparty na niej stanął — czy to jest incydent poważny w Waszym przypadku i kto to rozstrzyga.

Jedna uwaga dla firm, które mają już procedury RODO: terminy są podobne, ale to są dwa różne reżimy, dwa różne organy i dwie różne oceny progu. Planowane jest uruchomienie jednego punktu zgłoszeniowego przez S46, który pozwoli uniknąć dublowania zawiadomień do CSIRT i UODO, ale szczegóły techniczne są wciąż w toku. Do tego czasu trzeba założyć, że zdarzenie może wymagać dwóch zgłoszeń, i przypisać do każdego z nich konkretną osobę.

Shadow AI przestało być problemem kulturowym

O narzędziach AI używanych w firmie bez wiedzy przełożonych pisaliśmy już wcześniej jako o problemie shadow AI — wtedy głównie w kategoriach wycieku danych i utraty kontroli. Dla podmiotu kluczowego albo ważnego ten sam problem zmienia charakter: to nie jest już kwestia dyscypliny w zespole, a luka w inwentaryzacji systemów, na której opiera się cała analiza ryzyka. Nie da się ocenić ryzyka dostawcy, o którego istnieniu nikt nie wie.

Odruch, który pojawia się w tym momencie najczęściej, jest też najgorszy z możliwych: zablokować wszystko. Zablokowanie publicznych narzędzi AI bez dania zespołowi alternatywy nie usuwa shadow AI, tylko przenosi je na telefony prywatne, gdzie nie zostawia żadnego śladu. Z punktu widzenia zgodności to pogorszenie sytuacji, bo wcześniej część tego ruchu była przynajmniej widoczna w logach sieci.

Działa natomiast kolejność odwrotna, którą stosujemy u klientów. Najpierw amnestia i inwentaryzacja: dwa tygodnie, w których każdy może zgłosić narzędzie, którego używa, bez konsekwencji. Potem jedno albo dwa narzędzia zatwierdzone, z umową firmową i jasnymi zasadami, naprawdę dostępne dla wszystkich, którzy ich potrzebują — bo ludzie używają obejść wtedy, gdy oficjalna droga jest gorsza od nieoficjalnej. Potem krótka, jednostronicowa zasada: jakie dane mogą trafiać do narzędzia AI, jakie nigdy, i kto zatwierdza nowe narzędzie. I na końcu kontrola techniczna, która już ma czego pilnować.

Przy okazji warto zdjąć z tej rozmowy jeden fałszywy argument, który pojawia się regularnie. Uruchomienie modelu na własnym serwerze nie zwalnia z żadnego z tych obowiązków, a część z nich przenosi w całości na Was: za utrzymanie, aktualizacje, kopie zapasowe i reakcję na incydent odpowiada wtedy Wasz zespół, nie dostawca. Lokalny model jest dobrą decyzją z innych powodów i w konkretnych sytuacjach, ale nie jest skrótem przez zgodność.

Pięć błędów, które w tym obszarze kosztują najwięcej

Przez ostatnie pół roku rynek zdążył już wytworzyć własny zestaw nieporozumień wokół tych przepisów. Pięć z nich spotykamy regularnie i każde kosztuje albo pieniądze, albo czas, albo jedno i drugie.

• Kupowanie produktu „zgodnego z NIS2” zamiast zrobienia analizy ryzyka. Zgodność jest cechą organizacji i jej procesów, nie licencji. Narzędzie może wspierać wymagania, ale nie może ich spełnić za Was — a faktura za takie narzędzie nie jest dowodem w żadnym postępowaniu.
• Uznanie, że wpis do wykazu zamyka temat. Wpis to deklaracja statusu. Obowiązki merytoryczne zaczynają się 3 kwietnia 2027 roku, a dla podmiotów kluczowych pierwszy audyt to 3 kwietnia 2028 roku. Firma, która zaczyna przygotowania w marcu 2027, będzie to robiła najdroższym możliwym sposobem.
• Niesprawdzenie wpisu dokonanego z urzędu. Przy 62,3 tys. wpisów urzędowych część klasyfikacji — sektor, kategoria podmiotu, dane kontaktowe — będzie wymagała korekty, a zawiadomienia w tej sprawie chodzą też przez e-Doręczenia. Jeśli nikt tej skrzynki nie obsługuje, dowiecie się o problemie z opóźnieniem.
• Oddanie całego tematu działowi IT. Obowiązki dotyczą kierownictwa osobiście, włącznie z corocznym udokumentowanym szkoleniem i możliwością zakazu pełnienia funkcji. Decyzje o tym, które procesy są krytyczne i jakie ryzyko firma akceptuje, nie są decyzjami technicznymi.
• Zamrożenie projektów AI „do wyjaśnienia sytuacji”. To najdroższy z tych błędów, bo nie chroni przed niczym — narzędzia używane nieformalnie nie znikają — a opóźnia pracę, którą trzeba wykonać i tak. Właściwa reakcja to nie wstrzymanie wdrożeń, a wpisanie ich w ramy, które po 3 kwietnia 2027 roku będą obowiązkowe.

Plan na sześć miesięcy do 3 kwietnia 2027

Kolejność, która w tym obszarze najrzadziej kończy się paniką w marcu i najszybciej daje coś, co da się pokazać audytorowi albo klientowi w ankiecie bezpieczeństwa:

1. Tydzień pierwszy: potwierdzenie statusu. Sprawdzenie, czy firma jest w wykazie, w jakiej kategorii i z jakim sektorem, oraz weryfikacja danych, jeśli wpis był dokonany z urzędu. Przy wątpliwościach co do kwalifikacji — analiza prawna oparta na faktycznym zakresie działalności, nie na kodzie PKD. To jedyny krok w tym planie, który naprawdę wymaga prawnika.
2. Tygodnie drugi i trzeci: inwentaryzacja narzędzi AI według siedmiu punktów z tego tekstu, prowadzona razem z inwentaryzacją pozostałych usług ICT. Równolegle amnestia dla shadow AI — dwa tygodnie na zgłoszenie bez konsekwencji. Efektem jest jedna tabela, która potem służy wszystkiemu innemu.
3. Tydzień czwarty: ocena ryzyka dostawców z tej listy, z podziałem na trzy koszyki. Narzędzia, których utrata nic nie zmienia. Narzędzia przetwarzające dane wrażliwe albo osobowe. Narzędzia z uprawnieniami zapisu w Waszych systemach. Dwa ostatnie koszyki to zwykle trzy do pięciu pozycji i tylko one wymagają dalszej pracy.
4. Miesiąc drugi: umowy. Przegląd kontraktów z dostawcami z koszyków drugiego i trzeciego pod kątem powiadamiania o incydentach, prawa audytu, podwykonawców, retencji i lokalizacji przetwarzania. Tam, gdzie umowy nie ma — bo narzędzie działa na licencji indywidualnej albo darmowym planie — decyzja: umowa firmowa albo wyłączenie narzędzia.
5. Miesiąc trzeci: uprawnienia i logi. Własna tożsamość dla każdego agenta, zawężenie uprawnień do faktycznie używanych operacji, rejestrowanie działań zapisujących po Waszej stronie, człowiek w ścieżce operacji nieodwracalnych. To najbardziej techniczny etap tego planu i zwykle najkrótszy.
6. Miesiąc czwarty: procedura incydentu przepracowana na scenariuszach z udziałem AI, z nazwiskami i czasami. Kto kwalifikuje zdarzenie, kto składa wczesne ostrzeżenie w ciągu 24 godzin, kto odpowiada za zgłoszenie w 72 godzinach, kto decyduje o równoległym zawiadomieniu UODO. Plus jedno ćwiczenie na sucho, bo procedura nieprzetestowana jest dokumentem, nie procedurą.
7. Miesiące piąty i szósty: włączenie tego wszystkiego do systemu zarządzania bezpieczeństwem informacji i szkolenia — zarówno obowiązkowe szkolenie kierownictwa, jak i krótkie szkolenie zespołu z zasad korzystania z narzędzi AI. Na koniec przegląd: co z inwentaryzacji zdążyło się zmienić w ciągu tych sześciu miesięcy. Zwykle sporo, i to jest argument za tym, żeby ten przegląd był cykliczny.

Co mierzyć, żeby wiedzieć, że to nie jest teatr

W tym obszarze wyjątkowo łatwo wyprodukować dokumentację, która nie opisuje rzeczywistości. Dlatego warto mieć kilka liczb, które pokazują stan faktyczny, a nie stan papieru.

Pierwsza: odsetek narzędzi AI z inwentaryzacji, które mają przypisanego imiennie właściciela i umowę firmową. Na starcie u większości klientów jest to poniżej połowy. Druga: liczba kont integracyjnych z uprawnieniami zapisu, których nie da się przypisać do konkretnego procesu i osoby — cel to zero i to jest miernik, który najszybciej robi wrażenie na audytorze. Trzecia: czas od zdarzenia do jego zarejestrowania w ćwiczeniu na sucho, liczony w godzinach i zestawiony z progiem 24 godzin.

Czwarta, najbardziej niewygodna: ile narzędzi AI pojawiło się w firmie od ostatniego przeglądu i ile z nich przeszło przez zatwierdzenie. Jeśli ta pierwsza liczba rośnie, a druga stoi, to znaczy, że oficjalna droga jest dla zespołu gorsza od obejścia — i problemem nie jest dyscyplina, a proces zatwierdzania. Piąta, przydatna sprzedażowo: czy potraficie odpowiedzieć na standardową ankietę bezpieczeństwa klienta bez zwoływania spotkania. To ten sam zestaw informacji, więc jeśli inwentaryzacja jest zrobiona porządnie, odpowiedź zajmuje godzinę, a nie dwa tygodnie.

Czego nie mierzyć: liczby stron polityki bezpieczeństwa, liczby przeszkolonych osób bez sprawdzenia, czy cokolwiek z tego wynika, i liczby zablokowanych domen. Każdą z tych liczb da się poprawić, nie poprawiając niczego realnego.

Od czego zacząć

Trzy pytania na jedno spotkanie. Czy firma jest w wykazie KSC i w jakiej kategorii — a jeśli nikt tego nie sprawdził, to jest to pierwsza czynność na jutro, bo wpisy z urzędu są czterokrotnie liczniejsze od zgłoszeń własnych. Czy istnieje jedna lista narzędzi AI używanych w firmie, z właścicielem i umową przy każdej pozycji. I czy wiecie, które z tych narzędzi mają uprawnienia do zapisu w Waszych systemach. Jeśli odpowiedź na którekolwiek z tych pytań wymaga tygodnia pracy, to właśnie od tego zaczyna się cała reszta.

Nasze zdanie jest takie: dla firm, które są w wykazie, ten rok jest wyjątkowo dobrym momentem na wdrożenia AI, a nie złym. Nie dlatego, że przepisy w czymkolwiek pomagają, ale dlatego że praca, którą trzeba wykonać do 3 kwietnia 2027 roku — inwentaryzacja systemów, porządek w uprawnieniach, umowy z dostawcami, procedura incydentu — to dokładnie ta sama praca, która odróżnia wdrożenie AI działające po roku od pilotażu porzuconego po trzech miesiącach. Robi się ją raz i liczy dwa razy. Od czego ją rozpocząć i jak wygląda w praktyce, rozłożyliśmy w tekście o audycie AI w firmie, a obowiązki wynikające z drugiego reżimu, o którym trzeba pamiętać równolegle, zebraliśmy w tekście o AI Act w małej firmie.

Jeszcze raz, bo to ważne: nie jesteśmy kancelarią i powyższe nie jest poradą prawną — kwalifikacja podmiotu i ocena progu incydentu to rozstrzygnięcia, które warto potwierdzić z prawnikiem na konkretnym stanie faktycznym. Jesteśmy natomiast firmą, która wdraża AI i musi te wymagania uwzględniać w każdym projekcie. Jeśli chcecie sprawdzić, jak to wygląda u Was, umówcie bezpłatną konsultację albo zobaczcie, jak prowadzimy konsulting i wdrożenia AI.