Twój pracownik stworzył aplikację z AI. Czy pozwolić firmie z niej korzystać?

Tak, ale nie od razu. Aplikację zbudowaną przez pracownika z AI możesz dopuścić, jeśli nie dotyka danych klientów ani systemów firmy albo jeśli przed podłączeniem danych przejdzie przegląd inżyniera, działa na firmowym koncie i ma właściciela, który ją utrzyma. O zgodzie decydują dane i uprawnienia, nie narzędzie.

Handlowiec składa w Lovable panel z danymi z CRM, ktoś z obsługi klienta stawia w n8n automatyzację odpowiadającą na maile albo tworzy własnego GPT z procedurami. Działa, oszczędza godziny i nikt z IT o tym nie wie. To nie zła wola, tylko szybkość.

Zakaz nie działa, bo narzędzie przeniesie się na prywatne konto. Entuzjazm bez sprawdzenia też jest ryzykowny. Wg firmy RedAccess, której badanie WIRED opisał 07.05.2026, ponad 5 tys. aplikacji zbudowanych w Lovable, Replit, Base44 i Netlify nie miało praktycznie żadnych zabezpieczeń, a blisko 2 tys. z nich wyglądało na ujawniające prywatne dane każdemu, kto znał adres. Platformy w tym samym tekście WIRED (07.05.2026) odpowiadają, że widoczność i konfiguracja aplikacji to decyzja jej twórcy, a Base44 zakwestionował, czy dane były prawdziwe.

Szersze tło: czy vibe coding w firmie to szansa, czy pułapka. A jeśli to Ty budujesz z AI, przeczytaj, czy CEO może sam programować z AI.

Co to jest shadow AI i dlaczego dotyczy też aplikacji?

Shadow AI to korzystanie z narzędzi AI bez wiedzy i zgody firmy, a dziś obejmuje nie tylko czaty, ale też aplikacje, automatyzacje i agentów budowanych przez pracowników poza IT. Pracownik, który sam tworzy takie narzędzia bez przygotowania technicznego, to citizen developer.

Wklejony do czatu fragment umowy to jednorazowy wyciek; aplikacja z dostępem do CRM czy skrzynki działa codziennie, ma własne klucze i uprawnienia, a bywa, że i publiczny adres.

Wg IBM w raporcie Cost of a Data Breach 2026 43% z 602 badanych organizacji, które doświadczyły naruszenia danych między 03.2025 a 02.2026, miało incydent związany z shadow AI (rok wcześniej 20%), a średni koszt takiego naruszenia wyniósł 5,39 mln USD. To odsetek badanych firm po naruszeniu, nie wszystkich firm. Wg Netskope (05.01.2026) 47% użytkowników generatywnej AI korzysta z prywatnych kont. Gartner prognozuje (19.11.2025), że do 2030 roku ponad 40% przedsiębiorstw doświadczy incydentów bezpieczeństwa lub zgodności związanych z shadow AI.

Według badania ARC Rynek i Opinia dla Pracuj.pl, opisanego przez Parkiet 02.11.2026, 70% badanych korzystających z AI sięga po narzędzia niezatwierdzone przez pracodawcę. W raporcie AIPORT z 12.05.2026 45,4% pracowników przyznało, że używa AI bez wiedzy pracodawcy, przy czym autorzy zaznaczają, że ich próba 479 osób nie jest reprezentatywna.

Czym grozi narzędzie, o którym IT nie wie?

Narzędzie, o którym IT nie wie, grozi wyciekiem danych, utratą kontroli nad kluczami i uprawnieniami oraz tym, że nikt go nie utrzyma. Źródłem problemu nie jest AI, tylko brak doświadczenia: autor nie wie, czego nie wie.

Dane widoczne dla każdego z linkiem

Najprostsze ryzyko to aplikacja albo czat dostępny pod publicznym adresem, który może trafić do wyszukiwarki. RedAccess, według WIRED (07.05.2026), znajdował niezabezpieczone aplikacje zwykłym wyszukiwaniem w Google i Bing. Replit odpowiedział w tym samym tekście WIRED (07.05.2026), że to użytkownik wybiera, czy aplikacja jest publiczna, a Lovable, że za konfigurację odpowiada twórca. Tyle że autor bez doświadczenia może nie wiedzieć, że takie ustawienie istnieje.

TechCrunch 31.07.2025 opisał, że udostępnione rozmowy z ChatGPT trafiały do wyników wyszukiwania; OpenAI tego samego dnia usunęło funkcję, która na to pozwalała. A Korea Herald 03.05.2023 podał, że po trzech przypadkach wklejenia kodu źródłowego i notatek ze spotkań do ChatGPT Samsung zakazał narzędzi generatywnej AI na firmowych komputerach.

Klucze API w kodzie

Klucz API to hasło do konta firmy u dostawcy, a autor bez doświadczenia łatwo zostawi go w kodzie. Wg GitGuardian (17.03.2026) w 2025 roku do publicznych commitów na GitHubie trafiło 28,65 mln nowych sekretów (o 34% więcej niż rok wcześniej), w tym 24 008 w plikach konfiguracji MCP, czyli połączeń agentów AI z innymi systemami. Ten sam raport GitGuardian (17.03.2026) podaje, że ponad 64% sekretów potwierdzonych jako ważne w 2022 roku nadal działało w styczniu 2026.

Za szerokie uprawnienia

Narzędzie, które może zapisywać, usuwać i wysyłać, zrobi to również przez pomyłkę. The Register 27.04.2026 opisał startup PocketOS, w którym agent AI w Cursorze w 9 sekund usunął produkcyjną bazę danych razem z kopiami, używając tokenu znalezionego w niezwiązanym pliku: token miał służyć do zarządzania domenami, a pozwalał na każdą operację. Ważne: według The Register (27.04.2026) założyciel PocketOS to programista z 15-letnim stażem, a nie amator, a dane odtworzył dostawca infrastruktury. Agent AI w firmie bez inżyniera tym bardziej potrzebuje najmniejszych uprawnień.

Prompt injection

Prompt injection to ukryte polecenie w mailu, zgłoszeniu, pliku albo na stronie, które AI potraktuje jak instrukcję od Ciebie. General Analysis w demonstracji z 08.07.2025 pokazał przykład: tekst wpisany przez klienta do zgłoszenia skłonił asystenta programisty z pełnymi uprawnieniami do bazy Supabase do skopiowania prywatnych tabel do odpowiedzi widocznej dla klienta. Invariant Labs 26.05.2025 opisał podobny mechanizm, w którym złośliwe zgłoszenie na GitHubie skłaniało agenta do ujawnienia danych z prywatnych repozytoriów.

Zasada dla CEO: treść od obcych plus dostęp do danych plus możliwość wysyłki oznacza wyciek. Usuń jeden z tych elementów.

Automatyzacje bez właściciela i aktualizacji

Automatyzacja w n8n, Make czy Zapier to też narzędzie z kluczami do poczty i CRM, a gdy nikt jej nie aktualizuje, staje się otwartymi drzwiami. Kanadyjskie Cyber Centre 12.01.2026 ostrzegło przed lukami w n8n, w tym taką, która pozwalała bez logowania wykonać kod przez webhooki, i zaleciło aktualizację do wspieranej wersji. Problemem nie jest n8n, tylko instancja, o której wszyscy zapomnieli. The Verge 28.02.2025 opisał, jak przez błąd w logowaniu dwuskładnikowym pracownika Zapier ktoś dostał się do repozytoriów, do których skopiowano dane klientów „na potrzeby debugowania”. Jeśli automatyzacje w firmie się rozrosły, pomagam je uporządkować, utrzymywać i monitorować.

Prywatne konto i jedna osoba

Narzędzie na prywatnym koncie pracownika należy w praktyce do niego, a nie do firmy: bez kopii, dokumentacji i dostępu dla innych. Gdy autor odchodzi, firma zostaje z procesem, który działa, dopóki działa. Opisałem to w tekście o tym, co się stanie, gdy jutro odejdzie jedyny programista.

Pełną listę ryzyk znajdziesz w tekście o 10 zagrożeniach vibe codingu.

Jak ocenić jedno narzędzie, nie znając się na kodzie: 10 pytań

Jedno narzędzie ocenisz bez znajomości kodu, zadając autorowi 10 pytań o dane, dostęp, klucze i to, kto je utrzyma.

1. Jakie dane narzędzie widzi lub zapisuje: dane osobowe klientów lub pracowników, finanse, tajemnicę firmy?
2. Kto może je otworzyć z internetu: czy wymaga logowania firmowym kontem, czy działa na publicznym linku, który może zaindeksować Google?
3. Z jakimi systemami się łączy (poczta, CRM, księgowość, dysk) i co może w nich zrobić: czytać, zapisywać, usuwać, wysyłać?
4. Gdzie są klucze API i hasła (w kodzie, w przeglądarce, w pliku konfiguracji, w GPT) i czyje to klucze?
5. Na czyim koncie działa i kto płaci: firmowe czy prywatne konto pracownika? Gdzie jest kod albo workflow? Zobacz, dlaczego konta i klucze muszą być na firmę i co zabierzesz z platformy no-code.
6. Czy czyta treści od obcych (maile, formularze, zgłoszenia, strony) i jednocześnie może coś wysłać lub zapisać?
7. [DO PRZEGLĄDU PRAWNIKA] Czy z dostawcą jest umowa powierzenia, wiadomo, gdzie są dane, i czy dostawca trenuje na nich modele? O to samo pyta lista UODO dla MŚP z 05.08.2026.
8. Co się stanie, gdy narzędzie przestanie działać albo się pomyli: kto to zauważy, czy jest kopia, czy da się cofnąć zmianę?
9. Kto poza autorem rozumie narzędzie i przejmie je, jeśli autor odejdzie?
10. Czy inżynier inny niż autor przejrzał je przed podłączeniem prawdziwych danych? To, że coś działa na demo, nie znaczy, że jest bezpieczne.

Moja reguła, a nie norma: każde „nie wiem” przy pytaniach 1–6 oznacza żółtą lub czerwoną strefę z tabeli poniżej. Podobną miarę stosuje UODO w liście dla MŚP (05.08.2026): więcej niż trzy odpowiedzi „NIE” oznaczają, że przed dalszym korzystaniem z narzędzia trzeba skonsultować się ze specjalistą.

Zielone, żółte czy czerwone? Tabela ryzyka według danych i połączeń

Kolor strefy zależy od tego, jakie dane narzędzie widzi i co może zrobić w systemach firmy. To moje przełożenie zaleceń NCSC z 18.06.2026, Cyber Centre z 29.10.2026 i listy UODO z 05.08.2026 na decyzję dla jednego narzędzia. Żaden z tych dokumentów nie używa kolorów.

Strefę wyznacza najbardziej ryzykowny element. Kalkulator z jednym połączeniem do CRM z prawem zapisu to już strefa czerwona. Jeśli nikt nie umie odpowiedzieć na pytania 1–5, traktuj narzędzie jak czerwone.

Strefy z filaru o vibe codingu dzielą projekty według stawki kodu; ta tabela dotyczy jednego narzędzia, które już istnieje.

Pozwolić, poprawić czy wyłączyć?

O tym, czy pozwolić na aplikację pracownika, decyduje strefa z tabeli: zielona to zgoda, żółta to zgoda po poprawkach, czerwona to wstrzymanie danych do czasu przeglądu.

Moje stanowisko: dobrze, jak pracownicy sami budują narzędzia, ale musi to zostać sprawdzone przez doświadczoną osobę. Wyjątkiem jest rozwiązanie, które działa tylko wewnątrz organizacji, a nie publicznie, i nie ma dostępu do wrażliwych danych.

Pozwól

Narzędzie z zielonej strefy dopuść od razu, pod trzema warunkami: wpis do rejestru (wystarczy arkusz: nazwa, autor, dane, połączenia, data przeglądu), firmowe konto i właściciel, który za nie odpowiada.

Pozwól po poprawkach

Narzędzie z żółtej strefy dopuść po przeglądzie inżyniera i z terminem wdrożenia poprawek. Typowe poprawki: klucze poza kodem, najmniejsze uprawnienia (tylko odczyt, jeśli zapis nie jest potrzebny), kopia danych, właściciel i zastępca, data następnego przeglądu. W tym pomaga przegląd narzędzia przed podłączeniem danych.

Przejmij, przepisz albo wyłącz

Narzędzie z czerwonej strefy albo takie, o którym nikt nie umie odpowiedzieć na pytania 1–5, przejmij do IT, przepisz albo wyłącz. Jeśli firma już na nim polega, zacznij od przejęcia; tu pomaga usługa przejęcie narzędzia, na którym firma już polega. Każda aplikacja wymaga opieki, o czym piszę w tekście o tym, czy aplikację można zostawić bez utrzymania. Zamiast prywatnych GPT rozważ firmowego asystenta wiedzy.

Co zrobić w pierwszych 48 godzinach po odkryciu narzędzia?

W pierwszych 48 godzinach ogranicz ryzyko, nie niszcząc narzędzia: zabezpiecz dostęp, zmień klucze i zdecyduj według tabeli.

1. Nie wyłączaj w panice. Nagłe wyłączenie zatrzyma pracę i zatrze ślady.
2. Porozmawiaj z autorem bez szukania winnych. Potrzebujesz jego wiedzy, a pracownik, który boi się kary, powie mniej.
3. Odetnij publiczny link. Włącz logowanie albo ustaw aplikację jako prywatną.
4. Zmień klucze API i hasła i zapisz nowe poza kodem.
5. Wpisz narzędzie do rejestru z odpowiedziami na 10 pytań.
6. Wyznacz właściciela po stronie firmy.
7. Zdecyduj według tabeli: pozwól, popraw albo przejmij.

Jeśli dane mogły wyciec, wyciek danych przez pracownika traktuj jak każdy incydent; kroki opisałem w części o pierwszej godzinie po awarii.

RODO i AI Act: co musisz załatwić, zanim narzędzie dotknie danych

Stan prawny na 11.11.2026. Zanim narzędzie dotknie danych osobowych, firma musi mieć umowę z dostawcą, podstawę przetwarzania, informację dla osób, których dane dotyczą, i wiedzę, gdzie dane są przechowywane; to minimum z pkt 8 listy UODO dla MŚP z 05.08.2026.

[DO PRZEGLĄDU PRAWNIKA] Administratorem danych jest firma, nie autor narzędzia. Z RODO (rozporządzenie 2016/679, tekst na 11.11.2026) wynikają trzy kluczowe obowiązki: umowa powierzenia z dostawcą narzędzia (art. 28), odpowiednie zabezpieczenia (art. 32) i zgłoszenie naruszenia do UODO w ciągu 72 godzin (art. 33).

[DO PRZEGLĄDU PRAWNIKA] Art. 4 AI Act, stosowany od 2.02.2025 i zmieniony przez pakiet AI Omnibus (w mocy od 27.07.2026), zobowiązuje firmy stosujące AI do podejmowania środków wspierających kompetencje w zakresie AI (treść art. 4, stan na 11.11.2026). Typowe narzędzie wewnętrzne nie jest systemem wysokiego ryzyka, chyba że ocenia ludzi (np. w rekrutacji); przepisy dla takich systemów z załącznika III będą stosowane od 2.12.2027.

[DO PRZEGLĄDU PRAWNIKA] Jeśli Twoja firma jest podmiotem kluczowym lub ważnym w rozumieniu nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252, w mocy od 03.04.2026), narzędzia pracowników wchodzą w zakres zarządzania ryzykiem.

Zasady dla całej firmy, czyli polityka AI, to osobny temat: tu chodzi o jedno narzędzie, a polityka mówi, co wolno wszystkim, zanim ktokolwiek coś zbuduje. Szerzej o tym, kto odpowiada za kod i dane, piszę w tekście o odpowiedzialności za kod AI.

To nie jest porada prawna.

Kto ma to zatwierdzać, gdy nie masz CTO?

Gdy nie masz CTO, narzędzia pracowników powinna zatwierdzać osoba techniczna z zewnątrz, na podstawie rejestru i przeglądu co kwartał. Cyber Centre w wytycznych z 29.10.2026 pisze wprost, że wykwalifikowane osoby muszą przeglądać ważne decyzje i zatwierdzać kod przed wdrożeniem.

Ty decydujesz o biznesie, osoba techniczna o bezpieczeństwie. Rejestr prowadzi ktoś w firmie, a kwartalny przegląd obejmuje nowe narzędzia, zmiany uprawnień i to, czy właściciele nadal pracują w firmie. Taką rolę może pełnić CTO na część etatu. Kto ustala zasady AI w całej organizacji, opisałem w tekście o roli Chief AI Officera.

Robię też przegląd (audyt) narzędzi zbudowanych przez pracowników. Każdy taki audyt wyceniam indywidualnie; szczegóły znajdziesz na stronie audytu kodu.

FAQ

Co to jest shadow AI?

Shadow AI to korzystanie z narzędzi AI bez wiedzy i zgody firmy: czatów, ale też aplikacji, automatyzacji i agentów budowanych przez pracowników. Wg Netskope (05.01.2026) 47% użytkowników generatywnej AI korzysta z prywatnych kont. Problemem nie jest AI, tylko to, że firma nie wie, jakie dane są w użyciu.

Czym grozi shadow AI firmie?

Shadow AI grozi wyciekiem danych, kluczami API w niepowołanych rękach, zbyt szerokimi uprawnieniami i narzędziami, których nikt nie utrzymuje. Wg IBM (raport Cost of a Data Breach 2026) 43% badanych organizacji, które doświadczyły naruszenia danych, miało incydent związany z shadow AI, a średni koszt takiego naruszenia wyniósł 5,39 mln USD.

Pracownik zrobił aplikację w Lovable (Replit, Cursor). Czy firma może z niej korzystać?

Tak, jeśli aplikacja nie dotyka danych klientów i systemów firmy albo przejdzie przegląd inżyniera, działa na firmowym koncie i ma właściciela. Sprawdź widoczność: wg RedAccess, cytowanego przez WIRED (07.05.2026), ponad 5 tys. aplikacji z takich platform praktycznie bez zabezpieczeń, a platformy odpowiadają, że ustawienia zależą od twórcy.

Jak sprawdzić aplikację pracownika, jeśli nie znam się na kodzie?

Zadaj autorowi 10 pytań: jakie dane widzi, kto ma dostęp z internetu, z czym się łączy, gdzie są klucze, na czyim koncie działa i kto je przejmie. Lista UODO dla MŚP z 05.08.2026 przyjmuje, że więcej niż trzy odpowiedzi „NIE” oznaczają konsultację ze specjalistą.

Czy aplikacja zbudowana przez pracownika może przetwarzać dane klientów (RODO)?

[DO PRZEGLĄDU PRAWNIKA] Może, ale odpowiada za to firma jako administrator, a nie pracownik. Według listy UODO dla MŚP z 05.08.2026 przed użyciem narzędzia na danych klientów trzeba mieć umowę z dostawcą, podstawę przetwarzania, informację dla osób i wiedzę, gdzie dane są przechowywane.

Co zrobić, jeśli w kodzie aplikacji są klucze API?

Natychmiast zmień te klucze u dostawcy, a nowe zapisz poza kodem, w bezpiecznym miejscu. Samo usunięcie z kodu nie wystarczy. Wg GitGuardian (17.03.2026) ponad 64% sekretów potwierdzonych jako ważne w 2022 roku nadal działało w styczniu 2026, bo nikt ich nie unieważnił.

Czy automatyzacja w n8n, Make albo Zapier to też shadow AI?

Tak, jeśli powstała bez wiedzy firmy i ma dostęp do jej danych lub systemów. Taka automatyzacja ma klucze do poczty czy CRM i wymaga aktualizacji. Cyber Centre 12.01.2026 ostrzegało przed lukami w n8n pozwalającymi wykonać kod bez logowania i zalecało aktualizację.

Co to jest prompt injection i czy dotyczy firmowego GPT albo agenta?

Prompt injection to ukryte polecenie w mailu, zgłoszeniu lub pliku, które AI wykona jak instrukcję od Ciebie. Dotyczy każdego GPT lub agenta, który czyta treści od obcych. General Analysis 08.07.2025 pokazał, jak tekst w zgłoszeniu klienta skłonił asystenta z pełnym dostępem do bazy do skopiowania prywatnych danych do odpowiedzi.

Kto odpowiada za narzędzie, gdy jego autor odejdzie z firmy?

Odpowiada firma, dlatego każde narzędzie musi mieć właściciela, zastępcę i działać na firmowym koncie, a nie na prywatnym koncie autora. Cyber Centre w wytycznych z 29.10.2026 podkreśla, że kod przed wdrożeniem muszą zatwierdzać wykwalifikowane osoby, czyli ktoś poza autorem musi go rozumieć.

Czy zakazać pracownikom budowania narzędzi z AI?

Zakaz zwykle nie działa, bo przenosi narzędzia na prywatne konta. Wg Netskope (05.01.2026) odsetek użytkowników AI na prywatnych kontach spadł w ciągu roku z 78% do 47%, gdy firmy zaczęły dawać narzędzia firmowe. Lepiej ustalić, co wolno budować samodzielnie, a co wymaga przeglądu.

Czy AI Act wymaga szkolenia pracowników z AI?

[DO PRZEGLĄDU PRAWNIKA] AI Act nie wskazuje w art. 4 konkretnej formy szkolenia. Po zmianie przez pakiet AI Omnibus, w mocy od 27.07.2026, przepis zobowiązuje firmy stosujące AI do podejmowania środków wspierających kompetencje w zakresie AI. Krótkie szkolenie z zasad korzystania z AI pozostaje najprostszym takim środkiem.

Co zrobić, gdy narzędzie pracownika ujawniło dane?

[DO PRZEGLĄDU PRAWNIKA] Odetnij dostęp, zmień klucze, zabezpiecz ślady i oceń, czyje dane wyciekły. Jeśli wyciekły dane osobowe, RODO w art. 33 (stan na 11.11.2026) daje 72 godziny na zgłoszenie naruszenia do UODO, chyba że jest mało prawdopodobne, by powodowało ono ryzyko dla ludzi. Nie szukaj winnych: autor wie najwięcej o tym, co się stało.

Zakończenie

Zakaz narzędzi budowanych z AI nie działa, ale ślepa zgoda też nie. Shadow AI w firmie przestaje być problemem, gdy decydujesz na podstawie danych i uprawnień, a nie wyglądu narzędzia. Każde narzędzie potrzebuje właściciela, firmowego konta i drugiej pary oczu.

Masz w firmie narzędzie zbudowane przez pracownika i nie wiesz, w której jest strefie? Napisz do mnie, a ustalimy, od czego zacząć.

Zobacz wersję Markdown →