Porozmawiajmy o Twojej firmie

Dlaczego 10% polskich pracowników wkleja dane firm do publicznych LLM — i co to mówi o governance AI

Dlaczego 10% polskich pracowników wkleja dane firm do publicznych LLM — i co to mówi o governance AI

W ciągu ostatnich dwunastu miesięcy 85% polskich firm objętych badaniem ESET i DAGMA Bezpieczeństwo IT odnotowało co najmniej jeden incydent bezpieczeństwa. Równolegle 10% ankietowanych pracowników przyznało, że udostępnia wrażliwe dane firmowe otwartym modelom AI, a 35% osób korzystających ze sztucznej inteligencji zadeklarowało, że podjęłoby próbę obejścia firmowych blokad publicznych narzędzi LLM. To dane z raportu „Cyberportret Polskiego Biznesu”, opisanego przez Niebezpiecznik.pl. Dotyczą one zarówno pracowników liniowych, jak i osób odpowiedzialnych za bezpieczeństwo IT w firmach zatrudniających co najmniej 10 osób.

Sprawa jest ważna nie dlatego, że po raz kolejny potwierdza, iż ludzie stanowią słabe ogniwo. Istotne jest napięcie, które ujawnia: organizacje chcą innowacji opartych na AI, ale nie zbudowały sankcjonowanych ścieżek jej użycia. W efekcie zakazy i blokady zderzają się z presją na produktywność, a pracownicy wybierają obejście zamiast procedury. Problem ma charakter projektowy, nie motywacyjny. Poniższa analiza opiera się wyłącznie na materiale dowodowym z raportu w relacji Niebezpiecznika. Wszędzie, gdzie źródło czegoś nie potwierdza, zaznaczam to wprost.

Co dokładnie mówią dane

Zacznijmy od liczb, bo bez nich reszta analizy jest spekulacją. Badanie objęło 1026 Polaków pracujących przy komputerze co najmniej trzy dni w tygodniu. W tej grupie znalazło się 457 osób zaangażowanych w obszar bezpieczeństwa, z czego 407 reprezentowało firmy zatrudniające minimum 10 pracowników. Wyniki dotyczące ekspertów odnoszą się wyłącznie do tej ostatniej grupy.

Wskaźnik Wartość Grupa
Firmy z incydentem w ostatnich 12 miesiącach 85% eksperci z firm 10+
Małe firmy (do 50 osób) z potwierdzonym cyberatakiem 68% eksperci
Średnie firmy (51–250 osób) z potwierdzonym cyberatakiem 88% eksperci
Duże firmy (250+ osób) z potwierdzonym cyberatakiem 85% eksperci
Pracownicy czujący się kompetentnie wobec zagrożeń cyfrowych 14% pracownicy
Pracownicy nieznający zasad cyberbezpieczeństwa firmy 50% pracownicy
Rozumiejący pojęcie data poisoning 8% pracownicy
Znający pojęcie deepfake 43% pracownicy
Ci, którzy dali się nabrać na deepfake co trzeci pracownicy
Ci, którzy uwierzyli w inne sfałszowane treści 23% pracownicy
Użytkownicy AI gotowi obejść firmowe blokady LLM 35% użytkownicy AI
Udostępniający wrażliwe dane firmowe otwartym modelom 10% ankietowani
Firmy z zaufaną bazą narzędzi dla pracowników 28% eksperci
Pracownicy, którzy zataili incydent na służbowym sprzęcie 16% pracownicy, którzy napotkali incydent
Wiedzący, czym jest ransomware 17% pracownicy

Dwie rzeczy wymagają ostrożności interpretacyjnej. Po pierwsze, 10% to odsetek wszystkich ankietowanych, a nie wyłącznie użytkowników AI — źródło nie precyzuje mianownika w tym pytaniu. Jeśli wziąć pod uwagę, że 35% odnosi się już do podgrupy korzystających z AI, rzeczywisty odsetek wśród aktywnych użytkowników LLM może być wyższy lub niższy; materiał tego nie rozstrzyga. Po drugie, dane o incydentach pochodzą z deklaracji ekspertów, a nie z audytu technicznego — to samoograniczenie typowe dla badań ankietowych.

Tło techniczne: dlaczego publiczny LLM to inny problem niż zwykły wyciek

Co dzieje się z danymi wklejonymi do modelu

Publiczny model językowy przyjmuje tekst, przetwarza go i zwraca odpowiedź. W zależności od dostawcy i ustawień dane wejściowe mogą być zapisywane, wykorzystywane do doskonalenia modelu lub przetwarzane przez podwykonawców w innych jurysdykcjach. Dla firmy oznacza to, że fragment umowy, lista klientów, kod źródłowy albo dane osobowe opuszczają kontrolowany obieg i trafiają do podmiotu trzeciego bez umowy powierzenia przetwarzania.

To jakościowo inny problem niż wysłanie pliku mailem do niewłaściwego adresata. Mail da się cofnąć lub zabezpieczyć, a odbiorca jest znany. W przypadku publicznego LLM nie ma pewności, gdzie treść trafiła, jak długo będzie przechowywana i czy zostanie użyta do trenowania kolejnych wersji modelu. Z punktu widzenia RODO to potencjalne naruszenie obowiązków administratora danych, a nie wyłącznie incydent bezpieczeństwa IT.

Dlaczego blokady nie rozwiązują problemu

Blokada domeny czy aplikacji działa na poziomie sieci lub urządzenia. Nie działa na poziomie intencji. Pracownik, który potrzebuje szybkiej odpowiedzi, znajdzie obejście: telefon prywatny, przeglądarkę w trybie gościa, VPN, alternatywny serwis. Deklaracja 35% użytkowników AI, że podjęłaby próbę obejścia blokad, jest tego bezpośrednim dowodem. Co więcej, blokada bez alternatywy tworzy shadow AI — użycie poza wiedzą i kontrolą organizacji, gdzie nikt nie może doradzić, jakie dane wolno wkleić.

Warto zauważyć, że tylko 28% firm udostępnia pracownikom zaufaną bazę narzędzi. To kluczowa liczba. Jeśli siedmiu na dziesięciu pracowników nie ma zatwierdzonego narzędzia, a jednocześnie odczuwa presję na innowacje, obejście staje się racjonalną strategią, nie przejawem lekkomyślności.

Data poisoning i deepfake — pojęcia, których nie rozumie większość

Data poisoning to celowe manipulowanie danymi treningowymi, by model zachowywał się w określony, szkodliwy sposób. Tylko 8% ankietowanych rozumie to pojęcie. Deepfake zna 43%, ale co trzeci przyznał, że dał się nabrać na zmanipulowane wideo lub grafikę, a 23% na inne sfałszowane treści. To nie jest wiedza akademicka — to warunek rozpoznania ataku socjotechnicznego, który może poprzedzać przejęcie konta lub nieautoryzowany przelew.

Realne konsekwencje dla firmy

Skutki nie ograniczają się do jednego wycieku. Można je pogrupować w cztery warstwy.

  • Prawna i regulacyjna. Wklejenie danych osobowych lub informacji objętych tajemnicą do publicznego modelu bez podstawy prawnej i umowy powierzenia to potencjalne naruszenie RODO oraz zobowiązań umownych wobec klientów. Źródło nie podaje, ile firm zgłosiło takie zdarzenia — to luka w materiale, nie w zjawisku.
  • Reputacyjna. Wyciek danych klientów lub kodu źródłowego ujawniony publicznie wpływa na zaufanie kontrahentów silniej niż incydent wewnętrzny, który udało się opanować.
  • Operacyjna. Jeśli pracownik wkleja fragmenty konfiguracji, zapytań do bazy lub logów, ujawnia strukturę systemów, co ułatwia późniejszy atak. Źródło nie potwierdza, jakie konkretnie dane wyciekały — deklaracja dotyczy „wrażliwych danych firmy” ogólnie.
  • Kulturowa. 16% pracowników, którzy napotkali incydent, zatrzymało tę informację dla siebie. To „milczące ogniwo bezpieczeństwa” opisane w raporcie. Każdy niezgłoszony incydent wydłuża czas reakcji i zwiększa zasięg szkód.

Interpretacja: dane sugerują, że firmy inwestują w blokady i szkolenia, ale nie w ścieżki działania. Pracownik, który nie wie, co wolno, i boi się konsekwencji błędu, wybiera improwizację lub milczenie. To hipoteza spójna z liczbami, ale raport nie testuje jej przyczynowo — należy traktować ją jako ramę do własnej diagnozy, nie jako ustalony fakt.

Scenariusze ryzyka

Scenariusz 1: cichy wyciek przez „nieostrożnego innowatora”

Raport rysuje portret pracownika, który testuje wszystko, co wpadnie mu w ręce, ceni szybkość ponad procedury i zwykle pracuje w marketingu lub PR, w dużej firmie, zdalnie. Taki profil łączy wysoką produktywność z wysokim ryzykiem. Wyciek następuje bez złej woli, w trakcie normalnej pracy, i często nie jest w ogóle rejestrowany jako incydent.

Scenariusz 2: obejście blokady i utrata widoczności

Pracownik obchodzi blokadę, korzysta z prywatnego telefonu lub VPN. Firma traci wgląd w to, jakie dane wychodzą i do jakich usług. W razie naruszenia nie ma logów, które pozwoliłyby ocenić skalę. To scenariusz szczególnie prawdopodobny w firmach, które postawiły na zakaz bez alternatywy — a takich, sądząc po 28% z zaufaną bazą narzędzi, jest większość.

Scenariusz 3: socjotechnika oparta na deepfake

Co trzeci ankietowany przyznał, że dał się nabrać na deepfake. W połączeniu z niską znajomością ransomware (17%) i niskim poczuciem kompetencji (14%) powstaje środowisko, w którym sfałszowana wiadomość od „prezesa” lub „klienta” ma realne szanse powodzenia. To ryzyko niezależne od AI w miejscu pracy, ale wzmacniane przez te same deficyty wiedzy.

Scenariusz 4: niezgłoszony incydent

16% zatailo incydent. Jeśli ten odsetek utrzymuje się przy poważniejszych zdarzeniach, czas od kompromitacji do wykrycia wydłuża się z godzin do tygodni. Raport wskazuje, że część pracowników nie zgłasza, bo nie potrafi rozpoznać zagrożenia — to problem edukacyjny, nie tylko kulturowy.

Jak sprawdzić, czy problem dotyczy Twojej firmy

Nie da się tego ustalić z jednego raportu. Potrzebna jest krótka diagnoza własna. Poniższe pytania można zadać w ciągu jednego spotkania zespołu IT i HR.

  1. Czy pracownicy mają zatwierdzoną, udokumentowaną bazę narzędzi AI? Jeśli nie — jesteś w grupie 72% firm bez takiej bazy.
  2. Czy istnieje procedura zgłaszania incydentu, którą pracownik zna i rozumie w mniej niż minutę? Jeśli procedura ma kilka stron, raport sugeruje, że może wywoływać odwrotny skutek.
  3. Czy w ostatnich 12 miesiącach odnotowano incydent związany z AI lub wyciekiem danych przez narzędzia zewnętrzne? Brak rejestru nie oznacza braku zdarzeń.
  4. Czy blokady LLM są jedynym mechanizmem kontroli? Jeśli tak, deklaracja 35% gotowości do obejścia dotyczy także Twoich pracowników.
  5. Czy wiadomo, jakie kategorie danych wolno przetwarzać w modelach zewnętrznych, a jakich nie wolno? Brak klasyfikacji oznacza, że decyzję podejmuje pracownik ad hoc.
  6. Czy szkolenia kończą się testem rozpoznawania phishingu i deepfake, czy tylko prezentacją? 43% zna deepfake, ale co trzeci dał się nabrać — sama znajomość pojęcia nie wystarcza.

Plan reakcji krok po kroku

Krok 1: inwentaryzacja (tydzień 1)

Zbierz listę narzędzi AI faktycznie używanych w firmie — nie tylko zatwierdzonych. Źródłem mogą być logi proxy, analiza ruchu, ankiety w zespołach. Celem jest poznanie skali shadow AI, nie karanie. Bez tego dalsze kroki będą oparte na domysłach.

Krok 2: klasyfikacja danych (tydzień 1–2)

Ustal trzy poziomy: dane publiczne (można wklejać wszędzie), dane wewnętrzne (tylko zatwierdzone narzędzia z umową), dane wrażliwe (tylko narzędzia z umową powierzenia i szyfrowaniem, jeśli w ogóle). Klasyfikacja musi być krótka i zrozumiała dla nie-technicznego pracownika. Długa procedura prawnicza, jak sugeruje cytowany w raporcie Paweł Jurek z DAGMA, wywołuje chaos i strach przed zgłaszaniem incydentów.

Krok 3: sankcjonowana ścieżka (tydzień 2–4)

Udostępnij co najmniej jedno zatwierdzone narzędzie AI z jasnymi zasadami: co wolno wklejać, czego nie wolno, gdzie szukać pomocy. Jeśli firma nie może wdrożyć własnej instancji, warto rozważyć narzędzia z gwarancjami umownymi dotyczącymi przetwarzania danych. Cel jest prosty: pracownik ma mieć szybszą drogę zgodną z zasadami niż obejście.

Krok 4: procedura zgłaszania (tydzień 3)

Jedna strona, jeden kanał, jasne zapewnienie, że zgłoszenie błędu nie skutkuje karą. Warto oddzielić zgłaszanie incydentów od oceny pracownika. Raport wskazuje, że strach przed konsekwencjami jest jednym z powodów tuszowania zdarzeń.

Krok 5: szkolenie celowane (tydzień 4–6)

Zamiast ogólnego kursu — moduły dopasowane do ról. Marketing i PR: deepfake, wizerunek, dane klientów. IT: data poisoning, łańcuch dostaw modeli. Kadry: dane osobowe w LLM. Każdy moduł powinien kończyć się krótkim testem rozpoznawania, nie quizem z definicji.

Krok 6: monitoring i przegląd (od 2. miesiąca)

Ustal metryki: liczba zgłoszeń, czas reakcji, odsetek pracowników z dostępem do zatwierdzonych narzędzi, liczba wykrytych prób obejścia blokad. Przeglądaj co kwartał. Bez metryk nie da się ocenić, czy działania przynoszą efekt.

Typowe błędy

  • Zakaz bez alternatywy. Blokada LLM bez zatwierdzonego narzędzia przenosi użycie poza kontrolę firmy.
  • Procedura dłuższa niż potrzeba. Dokument na wiele stron, pisany pod wymogi prawne, nie pod decyzję pracownika w 30 sekund.
  • Szkolenie bez testu rozpoznawania. Znajomość definicji deepfake nie chroni przed nabraniem się na deepfake.
  • Karanie za zgłoszenie błędu. Efekt: 16% pracowników zatrzymuje informację dla siebie, a czas reakcji rośnie.
  • Brak klasyfikacji danych. Pracownik sam decyduje, co jest wrażliwe — zwykle po fakcie.
  • Traktowanie AI jako tematu wyłącznie IT. Decyzje o wklejaniu danych podejmują marketing, sprzedaż i HR, nie administrator.
  • Pomiar tylko incydentów zgłoszonych. Liczba zgłoszeń może rosnąć wraz z zaufaniem, a nie wraz z liczbą ataków — bez kontekstu metryka myli.

Działania krótkoterminowe (do 30 dni)

  1. Opublikuj jednostronicową zasadę: co wolno wklejać do AI, czego nie wolno, gdzie zgłosić wątpliwość.
  2. Wskaż jeden zatwierdzony kanał AI lub tymczasowo jedną bezpieczną alternatywę.
  3. Uruchom kanał zgłaszania incydentów z gwarancją braku kary za błąd.
  4. Zbierz listę narzędzi AI używanych w firmie — choćby przez ankietę.
  5. Przeprowadź 15-minutowe spotkanie w zespołach o deepfake i phishingu, z przykładami.

Działania długoterminowe (3–12 miesięcy)

  1. Wdróż klasyfikację danych i powiąż ją z polityką DLP.
  2. Zbuduj lub rozszerz zaufaną bazę narzędzi — cel: znacząco powyżej 28% pracowników z dostępem.
  3. Wprowadź warstwowy monitoring (logi, korelacja zdarzeń) zamiast polegania wyłącznie na zgłoszeniach ludzi.
  4. Dostosuj szkolenia do ról i powtarzaj je cyklicznie z testami rozpoznawania.
  5. Ustal kwartalny przegląd metryk i aktualizuj politykę wraz ze zmianą narzędzi.
  6. Sprawdź, czy firma podlega ustawie o Krajowym Systemie Cyberbezpieczeństwa — raport wskazuje, że 37% ekspertów tego nie wie.

Checklista praktyczna

Obszar Pytanie kontrolne Status
Narzędzia Czy istnieje zatwierdzona baza narzędzi AI? tak / nie
Dane Czy klasyfikacja danych jest krótka i znana pracownikom? tak / nie
Zgłoszenia Czy incydent można zgłosić w jednym kanale bez obawy o karę? tak / nie
Szkolenia Czy szkolenia kończą się testem rozpoznawania deepfake i phishingu? tak / nie
Monitoring Czy firma rejestruje próby obejścia blokad i użycie zewnętrznych LLM? tak / nie
Metryki Czy liczba zgłoszeń i czas reakcji są mierzone kwartalnie? tak / nie
Zgodność Czy wiadomo, czy firma podlega ustawie o KSC? tak / nie

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy. Traktuj AI jak każdy inny kanał wyjścia danych, nie jak modny dodatek. Zdecyduj, kto odpowiada za politykę AI — najlepiej jedna osoba z mandatem, nie komitet. Zapewnij budżet na zatwierdzone narzędzie i na szkolenia celowane. Nie karz za zgłoszenie błędu; karz za ukrycie incydentu. Pamiętaj, że 85% firm w badaniu miało incydent w ciągu roku — pytanie nie brzmi „czy”, ale „kiedy” i „jak szybko to wykryjemy”.

Administrator / zespół IT. Zbierz dane o faktycznym użyciu AI, zanim wprowadzisz kolejną blokadę. Zbuduj jedną zatwierdzoną ścieżkę i uczyń ją wygodniejszą niż obejście. Wdróż rejestrowanie zdarzeń i korelację, bo raport pokazuje, że poleganie wyłącznie na ludziach zawodzi — 17% wie, czym jest ransomware, a 16% zatailo incydent. Ustal metryki i raportuj je kwartalnie. Sprawdź obowiązki wynikające z ustawy o KSC, jeśli firma może podlegać regulacji.

HR i przełożeni. Usuń z oceny pracowniczej karanie za zgłoszenie incydentu. Wprowadź krótkie, regularne ćwiczenia rozpoznawania deepfake i phishingu. Zadbaj, by nowi pracownicy przechodzili szkolenie z AI przed pierwszym dniem pracy z narzędziami zewnętrznymi.

Dane z raportu nie dowodzą, że polskie firmy są wyjątkowo nieostrożne. Pokazują raczej, że w większości nie zaprojektowały ścieżki użycia AI — a pracownicy, pod presją produktywności, projektują ją sami. To różnica, która zmienia sposób reakcji: z dyscyplinowania ludzi na projektowanie systemu.

Na koniec zastrzeżenie metodologiczne. Wszystkie liczby pochodzą z badania ankietowego na próbie 1026 osób, w tym 407 ekspertów z firm 10+. Deklaracje o gotowości do obejścia blokad i o udostępnianiu danych mierzą intencje i przyznanie się do zachowania, nie rzeczywisty wolumen wycieków. Raport nie podaje, jakie dane wyciekały najczęściej ani ile incydentów było związanych z AI. Te luki warto uwzględnić, planując własną diagnozę — i nie traktować żadnej z liczb jako precyzyjnego pomiaru całego polskiego biznesu.

Weryfikacja praktyczna: jak sprawdzić, czy polityka AI działa w Twojej firmie

Deklaracje z badania ESET i DAGMA mierzą intencje, nie stan faktyczny organizacji. Dlatego po wdrożeniu zasad warto przejść od pytań „czy mamy politykę” do pytań „czy polityka zmienia zachowanie”. Poniższe sekcje opisują, jak to sprawdzić krok po kroku, bez opierania się wyłącznie na ankietach wewnętrznych.

Test 1: czy zatwierdzona ścieżka jest szybsza niż obejście

Najprostsza weryfikacja dotyczy czasu. Poproś losowo wybranych pracowników z marketingu, sprzedaży i HR o wykonanie typowego zadania z użyciem AI — np. streszczenia dokumentu — najpierw przez narzędzie zatwierdzone, potem przez dowolne publiczne LLM. Zmierz czas do pierwszego użytecznego wyniku oraz liczbę kroków. Jeśli ścieżka zgodna z zasadami jest dłuższa lub wymaga więcej wysiłku, 35% deklarujących gotowość do obejścia blokad nie jest abstrakcją — to przewidywalny skutek projektu, nie problem charakteru pracowników.

Test 2: czy klasyfikacja danych jest zrozumiała bez szkolenia

Pokaż pięć przykładowych fragmentów treści (np. fragment umowy, notatkę ze spotkania, opis produktu, dane klienta, wewnętrzny e-mail) i poproś o zaklasyfikowanie ich do poziomów: publiczne, wewnętrzne, wrażliwe. Jeśli odsetek błędnych odpowiedzi przekracza kilkanaście procent, klasyfikacja jest zbyt skomplikowana. Pamiętaj o kontekście z raportu: połowa pracowników deklaruje, że nie zna zasad cyberbezpieczeństwa firmy, a Paweł Jurek z DAGMA wskazuje, że długie, nieżyciowe procedury wywołują chaos i poczucie zagubienia zamiast pewności działania.

Test 3: czy szkolenie uczy rozpoznawania, a nie definicji

Zamiast quizu z definicji deepfake przygotuj zestaw autentycznych i zmanipulowanych materiałów w proporcjach znanych tylko osobie układającej test. Mierz nie tylko trafność, ale i pewność odpowiedzi — raport zwraca uwagę, że z punktu widzenia dezinformacji gorsza od naiwności bywa nadmierna pewność siebie. Skoro 43% zna pojęcie deepfake, a co trzeci pracownik przyznaje, że dał się nabrać na zmanipulowane wideo lub grafikę, sama znajomość terminu nie jest miarą odporności.

Test 4: czy kanał zgłoszeń działa w praktyce

Przeprowadź ćwiczenie: wyślij do wybranego zespołu kontrolowany, fałszywy incydent (np. podejrzany e-mail) i sprawdź, ile osób zgłosi go w wyznaczonym kanale oraz jak szybko. Powtórz ćwiczenie po kwartale. Rosnąca liczba zgłoszeń przy stałej liczbie zdarzeń kontrolowanych oznacza rosnące zaufanie do kanału, nie rosnące zagrożenie — bez tego rozróżnienia metryka liczby zgłoszeń myli.

Monitoring po wdrożeniu: co mierzyć i jak uniknąć pułapek

Monitoring nie może opierać się wyłącznie na deklaracjach ludzi ani wyłącznie na logach. Raport pokazuje, dlaczego oba źródła zawodzą osobno: 16% pracowników zatrzymuje informację o incydencie dla siebie, a jednocześnie 2/3 firm przyznaje, że różnorodność zagrożeń utrudnia ich wykrywanie. Potrzebna jest korelacja źródeł.

Warstwa techniczna

  • Rejestruj próby dostępu do publicznych narzędzi LLM przez proxy i analizę ruchu — nie po to, by karać, ale by znać skalę shadow AI.
  • Koreluj zdarzenia z różnych systemów zamiast polegać na pojedynczych alertach; różnorodność zagrożeń wymusza łączenie sygnałów.
  • Ustal punkt odniesienia przed wdrożeniem zasad, inaczej nie odróżnisz wzrostu wykrywalności od wzrostu liczby ataków.

Warstwa ludzka

  • Mierz odsetek pracowników z dostępem do zatwierdzonych narzędzi — cel powinien być znacząco wyższy niż dotychczasowy poziom.
  • Mierz czas od zgłoszenia do reakcji, nie tylko liczbę zgłoszeń.
  • Sprawdzaj, czy przełożeni nie naciskają na innowacje AI bez równoległego ustalenia zasad — raport wprost wskazuje na presję szefów i kolegów jako tło ryzykownych zachowań.

Warstwa zgodności

Uwzględnij obowiązki regulacyjne: raport wskazuje, że 37% ekspertów nie wie, czy ich firma podlega ustawie o Krajowym Systemie Cyberbezpieczeństwa. To pytanie należy do checklisty przeglądu kwartalnego, podobnie jak aktualizacja polityki po każdej zmianie narzędzi.

Rytm przeglądów

  1. Przegląd miesięczny: incydenty, zgłoszenia, czas reakcji.
  2. Przegląd kwartalny: metryki, testy rozpoznawania, aktualizacja klasyfikacji danych.
  3. Przegląd roczny: ponowna inwentaryzacja narzędzi AI, ocena zgodności, rewizja szkoleń.

Checklisty wdrożeniowe i kontrolne

Checklista przed startem (dzień 0)

  • Czy znasz listę narzędzi AI faktycznie używanych w firmie, także niezatwierdzonych?
  • Czy istnieje jedna osoba odpowiedzialna za politykę AI z realnym mandatem?
  • Czy klasyfikacja danych mieści się na jednej stronie i jest zrozumiała bez szkolenia?
  • Czy zatwierdzona ścieżka użycia AI już istnieje, zanim wprowadzisz blokady?
  • Czy kanał zgłoszeń incydentów jest jeden i oddzielony od oceny pracowniczej?
  • Czy wiadomo, czy firma podlega ustawie o KSC?

Checklista po 30 dniach

  • Czy co najmniej jedno zatwierdzone narzędzie AI jest dostępne dla zespołów, które go potrzebują?
  • Czy przeprowadzono test klasyfikacji danych i znane są jego wyniki?
  • Czy odbyły się krótkie spotkania o deepfake i phishingu z przykładami, nie z definicjami?
  • Czy zebrano dane o skali shadow AI z co najmniej dwóch źródeł (ankieta i logi)?
  • Czy pierwsze zgłoszenia incydentów wpłynęły i zostały obsłużone bez karania zgłaszających?

Checklista po kwartale

  • Czy odsetek pracowników z dostępem do zatwierdzonych narzędzi wzrósł względem punktu odniesienia?
  • Czy czas reakcji na zgłoszenia spadł lub utrzymuje się na założonym poziomie?
  • Czy test rozpoznawania deepfake i phishingu pokazuje poprawę trafności przy spadku nadmiernej pewności odpowiedzi?
  • Czy liczba wykrytych prób obejścia blokad jest monitorowana i interpretowana w kontekście?
  • Czy polityka została zaktualizowana po zmianie narzędzi lub dostawców?
  • Czy potwierdzono ponownie status zgodności z ustawą o KSC?

Checklista dla przełożonych zespołów

  • Czy w zespole wiadomo, gdzie zgłosić wątpliwość dotyczącą wklejania danych do AI?
  • Czy nowi pracownicy przechodzą szkolenie z AI przed pierwszym użyciem narzędzi zewnętrznych?
  • Czy nikt nie jest oceniany negatywnie za zgłoszenie błędu lub incydentu?
  • Czy presja na „innowacje AI” idzie w parze z przypomnieniem zasad, a nie zamiast nich?

Żadna z powyższych checklist nie zastępuje pomiaru — służą one do uporządkowania weryfikacji i przeglądów. Wszystkie liczby przywołane w tych sekcjach pochodzą z badania ankietowego opisanego w raporcie Cyberportret Polskiego Biznesu (próba 1026 osób, w tym 407 ekspertów z firm 10+) i mierzą deklaracje oraz przyznane zachowania, nie rzeczywisty wolumen zdarzeń.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

  1. Pracownicy czują się zagrożeni, ale ładują dane firm do AI (niebezpiecznik.pl)
  2. Before you continue to Google (news.google.com)

Zdjęcie wyróżniające: Andrea Piacquadio / Pexels.

Masz pytanie do tego tematu? Napisz do nas — odpowiemy konkretnie.

Porozmawiajmy

Potrzebujesz kogoś, kto ogarnie technologię w Twojej firmie?

Porozmawiajmy o tym, co możemy przejąć, usprawnić albo zbudować. Pierwsza rozmowa jest bezpłatna i do niczego nie zobowiązuje.