Shadow AI to aplikacje i narzędzia AI, które pracownicy zbudowali albo włączyli bez wiedzy działu IT. To nowsza odmiana shadow IT: kolega w jedno popołudnie robi sobie z AI narzędzie do ofert albo raportów i działa ono na jego prywatnym koncie. Zakaz tego nie zatrzyma. Pierwszy krok to rejestr, a przy każdej aplikacji trzy pytania: na czyim koncie działa, jakie dane do niej trafiają i kto ją wyłączy.
Poniżej: skąd bierze się shadow AI, co robić zamiast zakazu i jak w tydzień zrobić rejestr. Artykuł jest dla kierownika IT i dla kierownika działu, którego ludzie budują aplikacje.
Czym jest shadow AI i skąd się bierze?
Jeszcze kilka lat temu ktoś spoza IT mógł zrobić najwyżej skomplikowany arkusz Excela. Dziś buduje z AI aplikację: formularz, mały system zamówień, narzędzie, które czyta maile. Działa, oszczędza mu czas i chce się nią podzielić z kolegami.
Zwykle działa na jego prywatnym koncie. Jego abonament AI, jego hosting, jego hasło. Dział IT o niej nie wie albo wie, ale nie ma czasu jej sprawdzić.
Ludzie nie robią tego, żeby obejść IT. Robią to, bo nagle mogą, a praca musi zostać zrobiona. Brytyjskie National Cyber Security Centre mówi o shadow IT wprost:
It's important to acknowledge that shadow IT is rarely the result of malicious intent. It's normally due to employees struggling to use sanctioned tools or processes to complete a specific task, so they'll adopt unofficial measures to help them complete their work.
Wytyczne dotyczące shadow IT dla organizacji (stan na 11.11.2026)
W przypadku AI to prawda jeszcze bardziej. Różnica wobec dawnego shadow IT to tempo. Aplikacja powstaje w jedno popołudnie i tego samego dnia pracuje na prawdziwych danych klientów.
Jakie trzy pytania zadać przy każdej aplikacji?
Nie trzeba od razu sprawdzać każdej linijki kodu. Do pierwszej decyzji wystarczą trzy pytania:
Na czyim koncie działa? Na firmowym czy na prywatnym koncie osoby, która ją zbudowała. Prywatne konto oznacza, że dane firmy leżą dziś poza firmą.
Jakie dane do niej trafiają? Przykładowe czy prawdziwe dane klientów, faktury, ceny. Im bardziej wrażliwe dane, tym szybciej trzeba się tym zająć.
Kto ją wyłączy? Imię i nazwisko osoby, która za nią odpowiada, i data, kiedy się kończy, jeśli nikt jej nie przedłuży.
Z odpowiedzi wynika jedna z trzech decyzji. Aplikacja może zostać bez zmian. Może przejść na konto firmowe i dostać właściciela. Albo zostaje wyłączona, bo nikt jej już nie potrzebuje.
Trzecie pytanie najczęściej zostaje bez odpowiedzi. Aplikacje z AI powstają szybko i nigdy nie znikają. Nikt ich nie wyłącza, bo nikt nie wie, czy ktoś jeszcze z nich korzysta. Działają więc dalej, z dostępem do danych i bez nikogo, kto by się nimi zajmował.
Zakaz, zatwierdzanie każdej z osobna czy wspólne zasady?
Gdy dział IT odkrywa, że ludzie budują aplikacje, ma trzy możliwości. Każda ma swoją cenę:
Podejście
Co się dzieje
Kiedy ma sens
Zakazać
Aplikacje przenoszą się tam, gdzie nikt ich nie widzi. Ludzie pobierają eksport i wgrywają go do narzędzia AI na prywatnym koncie.
Tylko przy danych, które pod żadnym pozorem nie mogą opuścić firmy.
Zatwierdzać każdą aplikację osobno
Działa przy pięciu aplikacjach. Przy pięćdziesięciu IT nie nadąża z czytaniem, a ludzie przestają pytać.
Przy kilku aplikacjach, które pracują na wrażliwych danych.
Wspólne zasady dla wszystkich aplikacji
IT ustala je raz. Co się ich trzyma, idzie dalej bez czekania. Co od nich odbiega, trafia na biurko IT.
Gdy aplikacji przybywa, a większość robi podobne rzeczy.
Wspólne zasady nie muszą być skomplikowane. Aplikacja startuje z szablonu przygotowanego przez IT, a nie z pustego folderu. Działa na koncie firmowym. Do danych ma dostęp tylko do odczytu i tylko przez jedno miejsce, które IT widzi. I jest w rejestrze z właścicielem i datą końca.
Dane to najdelikatniejszy punkt. Gdy aplikacja nie może sięgnąć do żadnych danych, ludzie zdobywają je inną drogą. Bezpieczniej jest dać dostęp tylko do odczytu, z zapisem, kto o co pytał. O tym, jak ograniczyć to, co wolno AI, piszemy w artykule Guardrails AI: czego agent AI w firmie nie może robić.
Jak w tydzień zrobić rejestr aplikacji AI?
Rejestr to pierwszy krok. Bez niego nie da się zdecydować o niczym innym. Nie potrzeba do tego nowego narzędzia:
01
Zapytać bez konsekwencji
Krótka wiadomość do całej firmy: co zbudowali Państwo albo włączyli z AI i używają co tydzień? Nikt nie dostanie reprymendy za odpowiedź.
02
Zapisać każdą aplikację
Nazwa, kto ją zbudował, kto z niej korzysta i do czego. Wystarczy jeden arkusz.
03
Zadać trzy pytania
Na czyim koncie działa, jakie dane trafiają do środka, kto ją wyłączy. Gdzie brakuje odpowiedzi, tam jest pierwsze zadanie.
04
Zdecydować przy każdej
Zostawić, przenieść na konto firmowe albo wyłączyć. Najpierw te z prawdziwymi danymi klientów.
05
Powtarzać co kwartał
Pojawią się nowe aplikacje. Rejestr bez daty kolejnego przeglądu po pół roku jest nieaktualny.
Najważniejszy jest pierwszy krok. Jeśli ludzie boją się przyznać, co zbudowali, rejestr zostanie pusty, a aplikacje będą działać dalej. Ton wiadomości decyduje bardziej niż jej treść.
Kiedy dział IT powinien przejąć aplikację?
Niektóre aplikacje przerastają osobę, która je zbudowała. Korzysta z nich cały dział, pracują na prawdziwych danych klientów, a ich awaria zatrzymałaby pracę. Wtedy samo przeniesienie na konto firmowe nie wystarczy. Trzeba wiedzieć, co jest pod spodem.
Kod pisany przez AI bywa niespójny. W jednym miejscu dobrze robi kontrolę bezpieczeństwa, w następnym ją pomija. Dokładnie to zobaczyliśmy przy audycie aplikacji, którą założyciel zbudował sam z AI. Kod nie był zły, tylko nikt nie wiedział, gdzie ma dziury.
Werdykt audytu: wzmocnić czy przepisać i co poprawić najpierw.
Przepisanie od zera rzadko jest dobrą odpowiedzią. Zwykle wystarczy wzmocnić kilka miejsc i dodać to, czego AI nie ustawiła. Czego takiej aplikacji zwykle brakuje, opisujemy w artykule Vibe coding na produkcji: czego brakuje prototypowi.
Czy wiedzą Państwo, co u Państwa działa?
Proszę zaznaczyć, co dziś naprawdę wiedzą Państwo o aplikacjach zbudowanych z AI w firmie:
Kiedy nie trzeba się tym zajmować
Ludzie używają AI tylko do pisania tekstów. Kto używa AI do maili i streszczeń i nie buduje aplikacji, potrzebuje raczej zasad, jakich danych nie wpisywać do AI, a nie rejestru aplikacji.
Są dwie aplikacje i obie działają na koncie firmowym. Nie trzeba niczego budować. Wystarczy rejestr raz na kwartał.
Chcą Państwo od razu pełnego systemu zatwierdzania. Bez rejestru nie wiadomo, co się zatwierdza. Najpierw rejestr, potem zasady.
Chcą Państwo wiedzieć, czy aplikacja wytrzyma?
Jeśli w firmie działa aplikacja zbudowana z AI, od której zależy już praca, proszę napisać nam, co robi i kto z niej korzysta. Przy audycie aplikacji zbudowanej z AI w ciągu 10 dni roboczych wiedzą Państwo, czy ją wzmocnić, czy przepisać, a pierwszą poprawkę z werdyktu robimy bezpośrednio w Państwa repozytorium.
Shadow AI to narzędzia i aplikacje AI, których pracownicy używają albo które sami zbudowali bez wiedzy działu IT. Na przykład aplikacja do ofert, którą ktoś zrobił z AI i która działa na jego prywatnym koncie. To nowsza odmiana shadow IT.
Czym różni się shadow IT od shadow AI?
Shadow IT to każde narzędzie poza IT, na przykład prywatny dysk w chmurze albo aplikacja do udostępniania plików. Shadow AI to jego część: konta AI i aplikacje, które pracownicy sami zbudowali z AI. Różnica to tempo. Aplikacja z AI powstaje w jedno popołudnie i od razu pracuje na danych firmy.
Czy shadow AI w firmie trzeba zakazać?
Zakaz rzadko pomaga. Ludzie muszą zrobić swoją pracę, więc aplikacje przenoszą się tam, gdzie nikt ich nie widzi. Lepiej działa rejestr wszystkich aplikacji i prosta droga, żeby przenieść aplikację na konto firmowe.
Jak sprawdzić, jakie aplikacje AI działają w firmie?
Proszę zapytać ludzi wprost i bez wyciągania konsekwencji: co zbudowali albo włączyli, na jakim koncie to działa i kto z tego korzysta. Przy każdej aplikacji warto zapisać trzy rzeczy: na czyim koncie działa, jakie dane do niej trafiają i kto ją wyłączy.
Kiedy dział IT powinien przejąć aplikację zbudowaną z AI?
Gdy korzysta z niej więcej osób, pracuje na prawdziwych danych klientów albo jej awaria zatrzymałaby pracę. Wtedy powinna działać na koncie firmowym, mieć właściciela i przejść przegląd kodu i bezpieczeństwa.
Zapytaj AI o ten artykuł
AI przy odpowiedzi wykorzysta też nasze inne artykuły i doświadczenia z prawdziwych projektów.
Koszt oprogramowania na zamówienie zależy od liczby procesów, integracji, migracji danych i tego, kto je utrzymuje. U nas od 3 980 € netto miesięcznie albo stała cena za jasno określony zakres. Porównanie z projektem i SaaS.
Według słowackiego prawa autorskiego majątkowe prawa do oprogramowania tworzonego na zamówienie wykonuje zwykle klient. Ale prawa to nie to samo co posiadanie kodu. Co sprawdzić w umowie i przy przekazaniu.
Vendor lock-in oznacza, że nie mogą Państwo odejść od dostawcy oprogramowania bez utraty danych, pieniędzy lub czasu. 8 sygnałów, kiedy lock-in nie przeszkadza i jak wygląda umowa, od której można odejść.