Przejdź do treści

Shadow AI: aplikacje zbudowane z AI poza działem IT

Własność oprogramowania i dostawcy

Filip Papraneczałożyciel Digitaliko

Shadow AI: aplikacje, o których IT nie wie. Ilustracja: trzy aplikacje zbudowane z AI na prywatnych kontach przechodzą przez rejestr i dostają właściciela, konto firmowe albo datę wyłączenia.Shadow AI: aplikacje, o których IT nie wie. Ilustracja: trzy aplikacje zbudowane z AI na prywatnych kontach przechodzą przez rejestr i dostają właściciela, konto firmowe albo datę wyłączenia.

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.

NCSC, Wielka Brytania
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:

  1. 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ą.
  2. 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ąć.
  3. 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.
Przykład poglądowy. Trzy pytania przy aplikacji zbudowanej z AI poza IT: na czyim koncie działa (firmowym czy prywatnym), jakie dane do niej trafiają (przykładowe czy prawdziwe dane klientów) i kto ją wyłączy (właściciel i data końca). Z odpowiedzi wynika jedna z trzech decyzji: zostawić, przenieść na konto firmowe albo wyłączyć.Przykład poglądowy. Trzy pytania przy aplikacji zbudowanej z AI poza IT: na czyim koncie działa (firmowym czy prywatnym), jakie dane do niej trafiają (przykładowe czy prawdziwe dane klientów) i kto ją wyłączy (właściciel i data końca). Z odpowiedzi wynika jedna z trzech decyzji: zostawić, przenieść na konto firmowe albo wyłączyć.

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ścieCo się dziejeKiedy 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ę osobnoDział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 aplikacjiIT 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:

  1. 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ź.

  2. Zapisać każdą aplikację

    Nazwa, kto ją zbudował, kto z niej korzysta i do czego. Wystarczy jeden arkusz.

  3. Zadać trzy pytania

    Na czyim koncie działa, jakie dane trafiają do środka, kto ją wyłączy. Gdzie brakuje odpowiedzi, tam jest pierwsze zadanie.

  4. Zdecydować przy każdej

    Zostawić, przenieść na konto firmowe albo wyłączyć. Najpierw te z prawdziwymi danymi klientów.

  5. 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.
w ciągu 10 dni roboczych

Studium przypadku: audyt aplikacji zbudowanej z AI

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.

Jeśli wolą Państwo najpierw porozmawiać, proszę zarezerwować 15-minutową rozmowę wstępną.

Ile aplikacji zbudowanych z AI potrafiliby Państwo dziś wymienić bez pytania kogokolwiek?

W skrócie

  • Shadow AI to aplikacje i narzędzia AI, które ludzie zbudowali albo włączyli bez IT. Powstają, bo praca musi zostać zrobiona.
  • Przy każdej aplikacji wystarczą trzy pytania: na czyim koncie działa, jakie dane do niej trafiają i kto ją wyłączy.
  • Zakaz tylko ukrywa aplikacje. Lepiej działają wspólne zasady, które IT ustala raz.
  • Aplikację, od której zależą praca i prawdziwe dane, warto sprawdzić, zanim zaczną z niej korzystać kolejni koledzy.

Najczęściej zadawane pytania

Czym jest shadow AI?

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.

ChatGPTClaudePerplexity
Blog

Kolejne artykuły

Własność oprogramowania i dostawcy

Ile kosztuje oprogramowanie na zamówienie?

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.

Własność oprogramowania i dostawcy

Kto jest właścicielem kodu źródłowego oprogramowania na zamówienie?

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.

Własność oprogramowania i dostawcy

Vendor lock-in: jak rozpoznać, że wpadli Państwo w pułapkę

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ść.