Zobacz pełne nagranie
KEY TAKEAWAYS
Z tego artykułu wyniesiesz:
- 93% menedżerów IT już używa shadow AI — to nie podkultura, to mainstream. Blokowanie zmienia dynamikę zespołu, nie eliminuje problemu.
- 243 dni to średni czas zanim shadow AI zostanie wykryte — reaktywne governance nie reaguje na narzędzia szybsze niż twoja organizacja.
- Ponad 90% deweloperów używa narzędzi AI do produkcji kodu, a 60% uważa że kod jest lepszej jakości — problem nie jest „czy używać AI", ale „czy wiesz gdzie to się dzieje".
- 5-krokowy proces legalizacji zamienia obronę w kolaborację: pracownik proponuje → security review → pilotaż 2-4 tygodnie → narzędzie żyje lub umiera → ownership model.
- Klasyfikacja danych to fundamenty całej strategii — większość pracowników nie wie do której kategorii należą dane, którymi zajmują się każdego dnia.
Paradoks menedżera IT: gdzie się złamał system kontroli
Twoja firma wydała dziesiątki tysięcy złotych na Microsoft Copilot. Pokazujesz zespołowi statystyki produktywności. Mówisz że to przyszłość. W tym samym momencie blokujesz im dostęp do ChatGPT.
Poczucie absurdu robi się jeszcze większe, gdy patrzysz na dane. Dziewięćdziesiąt trzy procent menedżerów — czyli Twoi bezpośredni przełożeni — już shadow AI używa. Jednocześnie pracowników z zatwierdzonym dostępem do tych narzędzi jest zaledwie od pięćdziesięciu do siedemdziesięciu procent.
Zasada, którą słyszeć będziesz wielokrotnie w tym artykule, pojawia się tu właśnie: jeśli narzędzie jest zbyt niebezpieczne dla zespołu, dlaczego jest bezpieczne dla ciebie? A jeśli jest bezpieczne dla ciebie — czemu bać się że pracownicy go używają?
„My siedzimy na tej gałęzi zwanej AI i pielęgnujemy te liście, żeby coraz więcej rosło tych naszych projektów, a równocześnie lewą ręką intensywnie tą gałąź tniemy"
To nie jest przypadek. To jest symptom głębszego problemu: gdy narzędzia AI stają się naprawdę użyteczne, gdy rzeczywiście przyspieszają pracę, blokowanie przestaje być możliwe na poziomie technologii. Pracownicy znajdą obejście. Kupią Chat GPT Plus za własne pieniądze. Zalogują się z prywatnego urządzenia. Shadow AI nie będzie buntownictwem — stanie się standardem, którego nie widzisz, a model bezpieczeństwa na którym opierała się polityka, ulegnie erozji.
Shadow AI to symptom, nie problem
Pracownik stoi przed wyborem: albo czeka miesiąc na formalne zatwierdzenie dostępu do narzędzia, albo teraz, z własnej subskrypcji, robi to co musi. Większość wybiera drugą opcję. To nie bunt — to racjonalna odpowiedź na system, który stawia opór tam, gdzie powinna być wspólpraca.
Shadow AI nie jest problemem pracowników. Jest symptomem. I jak każdy objaw, mówi nam coś ważnego: że w organizacji brakuje czegoś fundamentalnego. Edukacji. Jasnych procesów. Lub — najczęściej — legitymizacji od liderów, żeby eksperymentować w otwartej drzwi.
„Jeżeli ten proces nie będzie jasny, jeżeli nie będzie jasnych regulacji, to ludzie będą szli na skróty"
Klasyczny przykład: kierownik projektów słyszy o ChatGPT. Widzi że oszczędziłby godziny. Ale nie wie czy dane z projektów można tam wrzucić. Czy to bezpieczne? Czy legalne? Gdzie to zgłosić? Proces nie istnieje — bo go nikt nie napisał. Regulacje nie istnieją. Rezultat: robi to w ciemno.
Problem pogarsza się, gdy dodasz kolejną warstwę: większość pracowników nie wie nawet jak klasyfikować dane.
„Te statystyki bardzo jasno pokazują, że ludzie nawet nie wiedzą, jak klasyfikować dane"
Ten problem zaczyna się zatem nie od tego że zespoły są nieposłuszne. Zaczyna się od tego, że organizacja nie dała im narzędzi do mądrych decyzji. Nie wytłumaczyła dlaczego pewne rzeczy trzeba robić ostrożniej. Nie pokazała że jest miejsce dla eksperymentów — tylko pod warunkami.
Tradycyjne podejście — „zabezpieczyć, nie pytając" — nie rozwiązuje tego problemu. Rozszerza go. Blokowanie uczy zespół że inicjatywa jest karana. Że łatwiej prosić o przebaczenie niż o pozwolenie. Że procedura jest tak skomplikowana, że chyba jednak nie warto.
Rozwiązanie zaczyna się od spojrzenia w lustro: co w naszych procesach, komunikacji i kulturze prowadzi do tego, że ludzie robią rzeczy potajemnie?
Dlaczego blokowanie nie działa
Przygotowałeś bezpieczny zestaw narzędzi. Kupił licencje dla całego zespołu. Wdrożyłeś polityki. I wtedy: zespół znalazł ChatGPT.
Klasyczne podejście do shadow IT to reaktywna obrona: wykrywaj, blokuj, karaj. Problem tkwi w założeniu, którego dane już obaliły. Liczba, którą przytacza Mateusz Chrobok, powinna zaniepokoić każdego CTO:
„Średnio takie użycie narzędzi zewnętrznych jest wykrywane po dwustu czterdziestu trzech dniach"
Dwie-cztery-trzy. Osiem miesięcy między tym, gdy deweloper otwiera ChatGPT, a tym, gdy IT to zauważy. W tym czasie kod trafił do produkcji. Dane przeszły przez niezatwierdzony LLM. Model bezpieczeństwa, na którym opierała się cała architektura compliance, już się zawalił. Reaktywne governance nie reaguje na narzędzia szybsze niż własna organizacja.
Ale liczba 243 dni to tylko preludium. Głębszy problem to czemu blokowanie nie ma szans zadziałać w ogóle.
Weź sobie tę liczbę do serca:
„Ponad dziewięćdziesiąt procent deweloperów używa narzędzi AI-owych do produkcji kodu, a sześćdziesiąt procent z nich uważa, że ten kod jest lepszej jakości"
Czytasz to słowo w słowo: dziewięćdziesiąt procent. Prawie każdy. I sześćdziesiąt procent — prawie siedem na dziesięciu — uważa że to, co robi, to rzeczywiście lepszy kod.
To nie jest już subkultura. To mainstream. Jeśli spróbujesz tego zakazać, nie zatrzymasz przepływu narzędzi — zmienisz tylko dynamikę zespołu. Deweloperzy nauczą się schować lepiej. Nowe narzędzia pojawią się szybciej niż sprzęt compliance ich wykryje.
Ale jest jeszcze coś. Mateusz Chrobok mówi o czymś głębokim:
„Dopóki nie będziemy brudzić sobie rąk i testować granic, to nie będziemy wiedzieli, co można, a co nie można"
Blokowanie jest czystą ręką. Nigdy nie dowiesz gdzie są rzeczywiste ryzyka, bo nigdy ich nie badałeś kontrolowanie. Nigdy nie poznasz możliwości, bo nie pozwoliłeś zespołowi ich eksplorować.
Tradycyjny model compliance — chroń, kontroluj, ukaraj — opiera się na założeniu że możesz przewidzieć wszystkie zagrożenia przed czasem. W erze AI, gdzie nowa kombinacja narzędzi pojawia się co tydzień, to założenie się zawalił.
Ten model jest martwy. Zespół już to wie.
Proces legalizacji — 5 kroków które działają
Większość organizacji zatrzymuje się na kroku 1 — pracownik prosi o pozwolenie, ale nigdy nie dostaje odpowiedzi.
To właśnie tutaj zaczyna się zmiana kultury. Nie w e-mailu do IT. Nie w tabeli ryzyka. Ale w konkretnym, powtarzalnym procesie, który zamienia obronę w kolaborację.
Mateusz Chrobok definiuje to jednym słowem: „Zalegalizować" — co oznacza nie blokowanie, ale przejęcie odpowiedzialności.
Krok 1: Pracownik proponuje narzędzie
Wszystko zaczyna się tym że ktoś mówi: „Chcę używać ChatGPT do tego zadania". Nie ukrywa. Nie czeka na przychylność IT. Po prostu mówi.
Oto jest moment krytyczny — zamiast powiedzieć „nie", mówimy: „Okej, jak chcesz to zrobić?"
Krok 2: Szybki security review
Bezpieczeństwo otrzymuje propozycję i robi to, co powinno: szybko i rzeczowo sprawdza narzędzie. Nie „może zajmiesz się tym za trzy miesiące". Security ma jasny cel: identyfikować ryzyko, nie blokować innowacyjność. Review nie trwa dwa tygodnie — to dni.
Krok 3: 2-4 tygodnie pilotażu
Tu rodzi się druga zmiana. Pracownik, który przyniósł pomysł, nie znika — zostaje. Zostaje osobiście odpowiedzialny.
„Słuchajcie, jak chcecie jakieś nowe narzędzie super, ale to ty, który przychodzisz z tym pomysłem, jesteś osobą, która jest odpowiedzialna za to narzędzie" — Mateusz Chrobok
To stwierdzenie zmienia wszystko. To nie jest IT które decyduje czy narzędzie żyje czy nie. To osoba, która je przyniosła, musi udowodnić wartość. Może to być dwa tygodnie intensywnego testowania. Może miesiąc. Ale to okres gdzie rzeczywiście widać czy narzędzie przynosi wartość, czy tylko hype.
Krok 4: Narzędzie żyje lub umiera
Po pilotażu przychodzi wynik:
„Bezpieczeństwo robi szybki review. Potem jest szybkie dwa tygodnie albo miesiąc, gdzie sprawdzasz, jak to działa, gdzie robimy sobie ewaluację i to narzędzie żyje albo umiera i bierzemy kolejne"
To nie jest dramatyczne. To oznacza tylko tyle: narzędzia, które nie spełniają obietnic, znikają z naturalnym cyklem. Zasoby idą w miejsce, które ich naprawdę potrzebuje.
Krok 5: Ownership model — odpowiedzialność zostaje
Jeśli narzędzie się sprawdzi, pracownik, który je przyniósł, staje się jego „właścicielem" w zespole. To jego odpowiedzialność:
- Czy inni mogą go bezpiecznie używać?
- Czy licencja jest w porządku?
- Czy coś się zmieniło w warunkach korzystania?
To właśnie punkt przełomowy. Shift z „IT mówi co mogę" na „ja odpowiadam za to, co wybieram".
Efekt? Zespoły przestają się czuć ograniczane. Zamiast tego czują się partnerami w decyzji o narzędziach, które faktycznie używają.
Ownership shift — jak oddelegować bez zaufania na ślepo
Menedżerowie IT obawiają się delegowania uprawnień do AI, jakby oddawali kluczyki do serwerowni losowemu pracownikowi. Ale w tej obawie tkwi fundamentalne nieporozumienie.
Oddanie odpowiedzialności za decyzje technologiczne nie oznacza rezygnacji z kontroli — to zmiana mechanizmu, na którym ta kontrola działa.
Kiedy blokujesz dostęp bezpośrednio w infrastrukturze, sprawujesz kontrolę przez prohibicję. Efekt jest iluzoryczny: pracownicy znajdują obejścia. Kiedy zamiast tego dokumentujesz, edukujesz i monitorujesz — sprawujesz kontrolę przez odpowiedzialność. Ta różnica zmienia wszystko.
„Razem za rączkę przejdźmy tą drogę, gdzie będziemy się uczyli, co można, z którym z tych systemów. To jest jedyne wyjście. Inaczej to będzie kwitło"
To nie jest sojusz ze słabością. To pragmatyka. Shadow AI będzie niezależnie od polityki. Pytanie brzmi: czy chcesz wiedzieć gdzie się pojawia, czy wolisz walczyć z boksorem, który trafia w niewidzialne cele?
Model ownership działa na trzech poziomach.
Najpierw — edukacja musi być częścią onboardingu każdego pracownika. Nie jako dodatkowy szkoleniowy weekend, lecz jako integralna część procesu wdrażania. Nowy pracownik uczy się polityki bezpieczeństwa danych w tym samym momencie, w którym uczy się wewnętrznych narzędzi. To ustawia oczekiwania od pierwszego dnia.
Drugi poziom — przejrzystość. Jeśli system jest dostępny, ale dokumentacja mówi dlaczego jest dostępny i jak go bezpiecznie używać, pracownik czuje się partnerem w procesie, a nie podejrzany. Gdy technologia jest dostępna bez sztucznych barier, większość ludzi wybiera bezpieczne ścieżki z własnej woli.
Trzeci poziom — monitorowanie, które edukuje zamiast karać. Gdy pracownik wie że jego aktywność jest logowana, ale logi służą jako wczesne ostrzeżenie lub materiał do uczenia zespołu (nigdy do sądów wysyłkowych), dynamika się zmienia. Staje się partnerem w iteracyjnym procesie, nie celem audytu.
To podejście ma drugi efekt: przyciąga talenty. W technologii panuje gorąca konkurencja o pracowników, którzy nauczyli się już AI używać. Mateusz wyraża to dosadnie:
„Jeżeli chcecie się adaptować i macie chęć uczyć się nowych rzeczy, to powinni być szczęśliwi, bo gorszy pieniądz wyciska z rynku ten lepszy pieniądz"
Organizacje, które tworzą środowisko do nauczenia się — a nie karę za eksperymenty — wciągają najlepszych. Nie dlatego że są „nice guys". Lecz dlatego że są racjonalni.
Klasyfikacja danych — fundamenty, bez których nic nie zadziała
Większość pracowników nie wie, do której kategorii należą dane, którymi zajmują się każdego dnia. I to jest prawdziwe źródło ryzyka — nie samo shadow AI.
Problem jest prosty: czy wiesz jakie dane masz?
Mateusz Chrobok widział to setki razy:
„Te statystyki bardzo jasno pokazują, że ludzie nawet nie wiedzą, jak klasyfikować dane"
To wyjaśnia dlaczego poszczególne departamenty działają na ślepo. IT myśli o bezpieczeństwie, biznes myśli że opóźniamy wdrożenia. Oboje się mylą. Chodzi o brak wspólnego słownika.
Trzy kategorie, które musisz znać
Klasyfikacja nie musi być skomplikowana. Wystarczą trzy kategorie:
Dane publiczne to wszystko, co już jest dostępne w internecie lub może być. Strony www, dokumentacja produktu, komunikaty prasowe, newsy o firmie. Te dane możesz przetwarzać w publicznych modelach bez dodatkowych zabezpieczeń. Ryzyko jest minimalne — zawartość jest już wszędzie.
Dane wewnętrzne to materiały, które pozostają w firmie, ale nie są tajemnicą handlową. Notatki ze spotkań, wewnętrzne dokumenty procesowe, statystyki które czasem trafiają na slajdy dla partnerów. Te dane wymagają kontroli dostępu i powinny być przetwarzane wyłącznie w narzędziach zaaprobowanych przez IT — lokalnie, albo w rozwiązaniach z umowami powiernictwa danych.
Dane wrażliwe i firmowe — tutaj zaczynasz się pocić. Tajemnice handlowe, dane osobowe klientów, informacje finansowe, strategie. Tu obowiązuje specjalna ochrona. Jak mówi Chrobok:
„Można skorzystać sobie z publicznych modeli bez żadnego data processing, bez żadnych zabezpieczeń, no bo to i tak jest publiczne. Ale gorzej jest przy tych danych wrażliwych, firmowych czy jakichś tajemnicach handlowych"
Te dane mogą być przetwarzane wyłącznie w kontrolowanym środowisku — albo wcale.
Praktyka: przełącznik dla zespołu
Co się zmienia? Każdy pracownik zanim wklei cokolwiek do jakiegokolwiek narzędzia AI, zadaje sobie jedno pytanie: do której kategorii to należy?
Jeśli to dana publiczna — dalej. Jeśli wewnętrzna — tylko w zaaprobowanych narzędziach. Jeśli wrażliwa — stop, trzeba inny proces.
To nie blokuje innowacji. Bardzo wręcz uwalnia ją. Bo wtedy zespół przestaje grać w ochronę a zaczyna grać w strategię. Zamiast czuć się przylapany — czuje się wzmocniony wiedzą.
Jeśli chcesz konkretny checklist do tego — przygotowaliśmy Matrycę Klasyfikacji Danych do pobrania. To przepis na rozmowę z zespołem w tym samym języku. Pracownik, zanim wróży dane do AI, zadaje sobie cztery pytania z tej matrycy — i natychmiast wie, czy może dalej czy musi zmienić narzędzie.
Teraz widzisz czemu to jest pierwsza rzecz którą robisz. Nie polityka. Nie zastraszanie. Tylko klasyfikacja danych — a reszta układa się sama.
30-dniowy plan wdrażania
Czytanie o legalizacji shadow AI to jedno. Zastosowanie tego w poniedziałek — całkiem coś innego.
Na podstawie procesu opisanego przez Mateusza, można to rozłożyć na cztery tygodnie. Każdy z nich ma jedno zadanie: zmienić perspektywę zespołu z obrony terenu na rzeczywistą kolaborację.
Zanim zaczynasz — przypomnij sobie słowa Mateusza:
„Dopóki nie będziemy brudzić sobie rąk i testować granic, to nie będziemy wiedzieli, co można, a co nie można"
Tydzień 1: Audyt i buy-in (Dni 1–7)
Zacznij od prawdy. Zmapuj jakie narzędzia AI są już używane w twoim zespole. W tym tygodniu nie chodzi o kontrolę — chodzi o dostęp do informacji.
Przeprowadź rozmowy z zespołem. Nie jako audytor. Jako osoba, która chce rozumieć jakie problemy rozwiązują sobie narzędziami, których nigdy ci nie opowiedzieli. Ty już wiesz, że będą używać AI niezależnie od polityki. Teraz dowiesz się co konkretnie.
Wynikiem tego tygodnia ma być lista narzędzi i mapa tego, gdzie AI jest już wplecione w procesy pracy.
Tydzień 2: Edukacja i framework (Dni 8–14)
Teraz nauczysz zespół mówić twoim językiem — językiem klasyfikacji danych i ryzyka.
Przeprowadź szkolenie z tego, jak rozpoznawać wrażliwe informacje, jakie dane mogą opuszczać organizację, a jakie mogą być bezpiecznie podzielone z narzędziem AI. Ustal ramę zasad — jakie narzędzia przejdą proces legalizacji, na jakiej podstawie będziesz je oceniać.
To tydzień w którym zespół zmienia perspektywę. Zamiast czuć się przylapany — czuje się wzmocniony wiedzą.
Tydzień 3: Pilotaż (Dni 15–21)
Uruchom proces legalizacji. Weź pierwsze narzędzia, które zmapowałeś w tygodniu 1, i przeprowadź ich przez review.
Szybkie oceny pierwszych narzędzi pokażą gdzie są rzeczywiste punkty tarcia i gdzie proces działa gładko.
Tydzień 4: Ewaluacja i iteracja (Dni 22–30)
Przeanalizuj co się nauczyłeś. Które narzędzia przeszły legalizację? Które zostały odrzucone i dlaczego? Co chciałeś wiedzieć wcześniej?
To tydzień do zdecydowania: co żyje, a co umiera. Ale też — co musisz zmienić w procesie legalizacji, żeby był lepszy w następnym cyklu.
Poniedziałek zaczyna się dzisiaj
Tego planu nie wdrażam ja. To plan dla ciebie.
Zespół czeka na znak, że będziesz partnerem, a nie policjantem. Że brudzenie rąk i testowanie granic — to nie bunt, ale niezbędna część pracy z narzędziami, których nigdy całkowicie nie zablokujesz. Legalizacja shadow AI zamienia tę nieuchronność w szansę.
Poniedziałek. Zaczynasz od audytu. Puk do drzwi pierwszej osoby w zespole i pytasz: co robisz z AI?
Reszta będzie następować naturalnie.


