Shadow AI – ukryte ryzyka w pracy testera oprogramowania

Deadline goni, a Ty masz stertę wymagań do przeanalizowania lub zawiły defekt do zgłoszenia. Wklejasz więc fragment dokumentu, log albo całe zgłoszenie do ChatGPT lub Claude, żeby poszło szybciej. Nikt Ci tego wprost nie zabronił, więc gdzie tu problem? A teraz pomnóż tę sytuację przez cały zespół i kilka różnych narzędzi. Otrzymasz zjawisko, które ma już swoją nazwę: Shadow AI. To jedno z najszybciej rosnących ryzyk w firmach tworzących oprogramowanie – i temat, który jeden z najnowszych sylabusów ISTQB dla testerów traktuje całkiem poważnie. W tym wpisie wyjaśniam, czym jest Shadow AI, dlaczego bywa groźne i jak korzystać z AI tak, aby nie narazić siebie ani pracodawcy.

 

Czym właściwie jest Shadow AI?

Najprościej: to używanie narzędzi opartych na sztucznej inteligencji do zadań służbowych bez wiedzy, zgody i nadzoru organizacji – poza jej polityką i procedurami. Jeśli pracujesz w branży od kilku lat, brzmi to znajomo, bo to bliski kuzyn Shadow IT, czyli korzystania z nieautoryzowanych programów, chmur czy urządzeń. Jest jednak istotna różnica.

W przypadku Shadow IT jednym z problemów jest lokalizacja danych – Twój plik ląduje na serwerze, którego nie kontrolujesz, ale wciąż jest to „gdzieś ten jeden plik”. Shadow AI dodaje drugi wymiar. Model nie tylko przechowuje to, co mu wyślesz – on to również przetwarza. Dane mogą zostać zachowane w systemach dostawcy, a organizacja traci kontrolę nad tym, co dzieje się z nimi dalej. W skrajnych przypadkach istnieje ryzyko, że informacje zostaną wykorzystane podczas dalszego rozwoju modelu i potem ujawnione w niezamierzony sposób. Co więcej, danych wprowadzonych do modelu nie da się usunąć w tak prosty i jednoznaczny sposób, jak pliku z dysku czy dokumentu z chmury. Ta potencjalna trwałość i nieprzejrzystość przetwarzania odróżniają Shadow AI od klasycznego Shadow IT.

Warto też pamiętać, że nie chodzi wyłącznie o jeden konkretny model czy jego dostawcę. Pod parasol Shadow AI wchodzą asystenci kodowania na prywatnych kontach, wtyczki do przeglądarki, tłumacze, generatory tekstu i grafiki, a także funkcje AI wbudowane po cichu w narzędzia SaaS używane na co dzień.

Jaka jest skala? Według raportów ponad 80% pracowników sięga po niezatwierdzone narzędzia AI, a szacuje się, że nawet 90% firmowego użycia AI odbywa się bez wiedzy działów IT i bezpieczeństwa. Z kolei z raportu IBM Cost of a Data Breach 2025 wynika, że co piąta badana firma zgłosiła naruszenie danych związane z Shadow AI, a firmy z wysokim poziomem tego zjawiska ponosiły koszty średnio o 670 tys. dolarów większe za naruszenie niż w innych przypadkach. Jeśli więc masz wrażenie, że u Was tego nie ma – często oznacza to po prostu, że jeszcze nikt nie sprawdzał.

 

Dlaczego (nawet dobry) tester sięga po AI po cichu

Zanim przejdziemy do omówienia ryzyka, jedna ważna rzecz: Shadow AI to nie jest zwykle historia o niekompetentnych pracownikach, ale o dobrych specjalistach, którzy chcą pracować szybciej i mądrzej – a narzędzia okazały się szybsze niż korporacyjne zasady.

Jest kilka przyczyn takiego stanu rzeczy. Presja czasu i chęć odhaczenia powtarzalnych zadań. Firmowe narzędzia, które (jeśli w ogóle są) bywają słabsze od tych dostępnych na wyciągnięcie ręki na prywatnym koncie. Brak przygotowania – według badania EY z 2025 roku AI używa już 88% pracowników, ale zdecydowana większość robi to bez odpowiedniego przygotowania ze strony pracodawcy. No i ludzka natura: zakazy w tym obszarze słabo działają – prawie połowa pracowników po firmowym zakazie i tak dalej korzysta z AI, tyle że już całkiem w ukryciu.

Ciekawość nowych technologii i chęć rozwoju to cechy, które u testera bardzo cenię. Problemu nie ma w tym, że sięgasz po AI. Chodzi o to, żeby robić to z głową i z odpowiednimi zabezpieczeniami.

 

Trzy rodzaje ryzyka według ISTQB

Sylabus nowej certyfikacji ISTQB Certified Tester: Testing with Generative AI (CT-GenAI), zaktualizowany w kwietniu 2026 roku, wprost wymienia Shadow AI wśród ryzyk i grupuje jego skutki w trzech obszarach: bezpieczeństwa i prywatności danych, zgodności z regulacjami oraz własności intelektualnej. Przejdźmy przez nie po kolei, z perspektywy codziennej pracy testera.

 

1. Bezpieczeństwo i prywatność danych

Prywatne narzędzia AI często nie mają solidnych zabezpieczeń, co otwiera drogę do wycieków. Zobaczmy, co w praktyce może wkleić tester w ciągu dnia pracy: historyjki (wymagania), logi z produkcji, specyfikacje API, dane testowe, zgłoszenia błędów razem ze stack trace, a czasem – z pośpiechu – zrzuty ekranu z wrażliwymi danymi i dane dostępowe czy fragmenty konfiguracji.

W tym kontekście najlepsza zasada, jaką znam to: traktuj każdy prompt jak informację, którą wysyłasz poza swoją organizację. Bo właśnie to robisz.

Jak to wygląda w praktyce, pokazał głośny przypadek Samsunga z 2023 roku. W niecałe trzy tygodnie od dopuszczenia ChatGPT w dziale półprzewodników doszło tam do trzech osobnych wpadek. Co dla nas, testerów, szczególnie wymowne – jedna z nich polegała na wykorzystaniu ChatGPT do optymalizacji sekwencji testowej wykrywającej wadliwe układy. To dosłownie praca z obszaru kontroli jakości. Dane trafiły na serwery dostawcy, na warunkach, które wówczas dopuszczały wykorzystanie ich do trenowania modelu – i nie można było tego cofnąć. Samsung zakazał publicznych narzędzi GenAI i zaczął budować własny model, a restrykcje wprowadziły w ślad za nim m.in. Apple, Amazon i duże banki. Podkreślę: nikt tam nie działał złośliwie, ale dobre intencje nie cofają wycieku.

 

2. Zgodność z regulacjami (compliance)

Korzystanie z niezatwierdzonych narzędzi AI może oznaczać złamanie standardów branżowych i przepisów – z konsekwencjami prawnymi włącznie.

Dla nas najbliższym punktem odniesienia jest RODO. Dane testowe bardzo często zawierają dane osobowe. Wrzucając je do publicznego modelu, można doprowadzić do niekontrolowanego przekazania danych osobowych – potencjalnie poza EOG, bez podstawy prawnej i bez umowy powierzenia. A stawka jest realna: kary z tytułu RODO sięgają do 20 mln euro lub 4% globalnego rocznego obrotu firmy. W sektorach regulowanych – finanse, ochrona zdrowia, administracja – poprzeczka zawieszona jest jeszcze wyżej. To nie przypadek, że banki jako jedne z pierwszych ucięły dostęp do publicznych chatbotów.

Do tego dochodzi nowa warstwa: unijny AI Act, którego przepisy wchodzą w życie etapami. Szczegółowe terminy jeszcze się przesuwają, ale kierunek jest jeden: sieć regulacyjna się zaciska, a „nie wiedziałem” słabo brzmi jako linia obrony.

 

3. Niejasna własność intelektualna

Trzeci obszar bywa najmniej oczywisty, a potrafi zaboleć. Narzędzia AI z niejasnymi warunkami licencyjnymi mogą wciągnąć firmę w spór o własność intelektualną – zwłaszcza gdy w grę wchodzą materiały objęte prawami autorskimi, przetwarzane bez odpowiedniej zgody. Dla zespołu wytwarzającego oprogramowanie działa to w dwie strony:

• Dane na zewnątrz. Firmowy kod, autorskie algorytmy czy zestawy testowe stają się „paliwem” dla modelu i mogą wypłynąć u konkurencji (patrz: Samsung).
• Dane do wewnątrz. Kod czy testy wygenerowane przez AI mogą mieć niejasną licencję albo odwzorowywać fragmenty danych treningowych objętych prawami autorskimi. Ryzyko prawne trafia wtedy wprost do Waszego repozytorium – często z pominięciem code review.

I jeden konkretny, techniczny haczyk, który powinien znać i tester, i programista: halucynacje pakietów (określane też jako slopsquatting). Programista pyta chata AI o nazwę biblioteki do konkretnego problemu, a model potrafi z pełnym przekonaniem podać taką, która… nie istnieje. Hakerzy monitorują powtarzające się halucynacje modeli w tym obszarze i rejestrują takie zmyślone nazwy w repozytoriach npm czy PyPI – ze złośliwą zawartością. Wystarczy bez zastanowienia zainstalować „polecony” pakiet i… brama do ataku na łańcuch dostaw oprogramowania zostaje otwarta. Wniosek jest prosty: każdą zależność podpowiedzianą przez AI trzeba zweryfikować, zanim wyląduje ona w projekcie.

 

Druga strona medalu – Shadow AI w testowanym produkcie

Do tej pory patrzyliśmy na testera jako na potencjalne źródło Shadow AI. Ale jest i druga rola, szczególnie istotna dla bardziej doświadczonych osób.

Jako tester jesteś też linią obrony przed Shadow AI ukrytym w samym produkcie. Programista może wpiąć zewnętrzne API modelu lub gotowy komponent AI bez pełnego przeglądu bezpieczeństwa, a kod generowany przez AI bywa włączany do repozytorium bez wystarczającej weryfikacji przez człowieka. Twoja analiza ryzyka powinna więc dziś obejmować pytania w stylu: Czy ta funkcja wywołuje zewnętrzny serwis AI? Jakie dane opuszczają system? Czy model może halucynować w sposób, który wprowadzi użytkownika w błąd? Czy wyjścia są walidowane? Testowaniu systemów opartych na AI – z ich niedeterminizmem, uprzedzeniami (bias) czy dryfem modelu – poświęcony jest osobny sylabus ISTQB Certified Tester AI Testing (CT-AI), aktualnie w wersji 2.0.

Pamiętajmy też, że testy i kod wygenerowane przez AI wymagają ludzkiego przeglądu. To, że narzędzie wygenerowało zestaw „wykonywalnych” przypadków testowych, nie znaczy, że są one poprawne i sensowne. Dla krytycznych ścieżek człowiek w pętli (human-in-the-loop) to nie fanaberia, tylko konieczność.

 

Jak używać AI, nie strzelając sobie (i firmie) w stopę

Skoro zakazy słabo działają, to co działa? Sylabus ISTQB podpowiada: przed ryzykiem Shadow AI chroni przemyślana strategia i konkretne kroki wdrażania GenAI – a nie udawanie, że problemu nie ma. Poniżej dwie grupy wskazówek, bo co innego jest w zasięgu testera, a co innego osoby zarządzającej.

Jeśli jesteś testerem – higiena na co dzień:

• Nie wklejaj danych dostępowych, prawdziwych danych osobowych klientów, firmowego kodu ani niczego objętego NDA (czyli umową o zachowaniu poufności).
• Korzystaj z narzędzi zatwierdzonych przez firmę: wersji biznesowych (te zwykle nie trenują na Twoich danych) albo rozwiązań uruchamianych lokalnie. Najpierw jednak sprawdź, co u Was jest oficjalnie dozwolone – nie zakładaj.
• Zamiast danych produkcyjnych używaj danych zanonimizowanych lub syntetycznych (ich generowanie to zresztą jeden z tematów CT-GenAI).
• Przeglądaj wszystko, co zwróci model – kod, testy, a zwłaszcza podpowiadane zależności.
• Nie wiesz, czy dane narzędzie jest OK? Zapytaj, nie działaj po cichu.

Jeśli prowadzisz zespół lub dział QA:

• Nie działaj tylko przez zakazy – umożliwiaj. Ludzie kombinują na boku wtedy, gdy oficjalne narzędzia są gorsze od tych prywatnych. Daj im dobre, zatwierdzone alternatywy.
• Stwórz prostą, zrozumiałą politykę – choćby na zasadzie świateł drogowych: zielone (narzędzia zatwierdzone do danych wewnętrznych), żółte (dozwolone z ostrożnością i anonimizacją), czerwone (zakazane). Do tego jasne reguły, jakich danych nie wolno wprowadzać do żadnego AI.
• Zainwestuj w szkolenia i kulturę, w której pytania i zgłaszanie wątpliwości jest bezpieczne, a nie ryzykowne. Skoro AI używają niemal wszyscy, a przygotowana jest garstka – to oczywista luka do zasypania.
• Zbuduj strategię i mapę wdrożenia GenAI, o której mówi sylabus. Warto też rozważyć certyfikację CT-GenAI – obejmuje m.in. zarządzanie danymi, prywatność i własność intelektualną.
• I klasyka: świeć przykładem (to bywa najtrudniejsze).

 

Podsumowanie

Shadow AI to nie jest opowieść o nieodpowiedzialnych pracownikach. To opowieść o dobrych specjalistach, którzy sięgnęli po potężne narzędzia szybciej, niż nadążyły za tym firmowe zasady. My, testerzy, jesteśmy tu w dobrym położeniu: rozumiemy ryzyko, mamy odruch pytania „co może pójść nie tak?” i możemy wyprowadzać korzystanie z AI z cienia na światło. Temat AI w pracy testera będzie zresztą wracał na blogu coraz częściej.

A jak to wygląda u Ciebie? Macie w firmie zatwierdzone narzędzia AI i jasną politykę, czy raczej każdy radzi sobie sam? Podziel się swoimi doświadczeniami w komentarzach 🙂