Shadow AI w zespole programistycznym: jak nie wynieść kodu klienta do czatu?

Stack trace z produkcji, fragment kodu klienta, mail z wymaganiami do streszczenia. Każdą z tych rzeczy można w kilka sekund wkleić do czatu z AI i w tym samym momencie opuszcza ona firmę, często bez niczyjej wiedzy. Tak wygląda Shadow AI w codziennej pracy programisty.

Od razu zaznaczę, że to nie jest tekst przeciwko AI. Asystenci AI na dobre weszli do pracy programistów i trudno dziś znaleźć zespół, w którym nikt z nich nie korzysta. Problem zaczyna się wtedy, gdy nikt nie wie, z jakich narzędzi korzysta zespół i co do nich trafia. Szczególnie wtedy, gdy kod i dane, na których pracujesz, należą do klienta.

W tym wpisie wyjaśnię, czym jest Shadow AI, jak wygląda w zespole programistycznym i dlaczego współpraca z zewnętrznymi klientami podnosi stawkę. Na koniec przedstawię konkretne rozwiązania, od anonimizacji danych po konfigurację asystentów w IDE, które pozwalają korzystać z AI bez działania w cieniu.

Sekcja 1Czym jest Shadow AI?

Krótko, Shadow AI to korzystanie w pracy z narzędzi AI bez wiedzy i zgody przełożonych albo działu IT. PARP opisuje je jako zjawisko pokrewne do shadow IT, czyli używania niezatwierdzonego oprogramowania. Palo Alto Networks dodaje ważne rozróżnienie. Shadow IT dotyczy głównie nieautoryzowanego dostępu i infrastruktury. Przy Shadow AI dochodzi jeszcze to, co model robi z danymi, jakie odpowiedzi generuje i jak wpływa na decyzje.

Ta definicja obejmuje też dwa przypadki, które łatwo przeoczyć:

• Funkcje AI w narzędziach, które firma już zatwierdziła. Asystent w Jirze, podsumowania w Slacku czy notatki ze spotkań w komunikatorze potrafią pojawić się po aktualizacji, bez żadnego przeglądu bezpieczeństwa,
• Prywatne konto w zatwierdzonym narzędziu. Ten sam czat może być narzędziem firmowym albo Shadow AI. Różnica tkwi w koncie i w umowie, a nie w nazwie aplikacji.

To nie jest zjawisko niszowe. Kilka liczb:

Najbardziej znany przykład z naszej branży to Samsung. W kwietniu 2023 roku media opisały, jak inżynier firmy wkleił do ChatGPT poufny kod źródłowy, żeby go zoptymalizować. Samsung odpowiedział zakazem korzystania z generatywnej AI przez pracowników. Za chwilę zobaczysz, dlaczego sam zakaz niewiele rozwiązuje.

Sekcja 2Dlaczego programiści sięgają po AI na własną rękę?

Bo to działa. Model w kilka sekund tłumaczy stack trace, pisze test, którego nikomu nie chciało się napisać, albo podpowiada, dlaczego zapytanie SQL jest wolne. Przy presji na tempo pracy trudno z tego zrezygnować.

PARP wymienia jeszcze dwa powody, które moim zdaniem są ważniejsze. Pierwszy to brak zasad. Jeśli firma nie powiedziała, z czego korzystać, to każdy korzysta z tego, co zna. Drugi to procedury. Jeśli zatwierdzenie nowego narzędzia trwa tygodniami, to programista, który ma termin na piątek, nie będzie czekał.

A zakaz? Zakaz tylko przesuwa problem. Według badania ESET i DAGMA 35% użytkowników AI próbowałoby obejść firmowe blokady, a 26% wygenerowałoby potrzebne treści na prywatnym sprzęcie i przesłało je na służbową pocztę. Palo Alto Networks zalicza przekonanie, że zakaz zatrzyma Shadow AI, do najczęstszych mitów. Zakaz nie usuwa potrzeby. Sprawia tylko, że przestajesz ją widzieć.

Sekcja 3Jak wygląda Shadow AI w zespole programistycznym?

Rzadko jest to świadome działanie. Najczęściej to drobne skróty, które w danej chwili wydają się niewinne:

• Stack trace albo logi z produkcji wklejone, żeby szybciej znaleźć błąd. W logach są adresy e-mail, identyfikatory użytkowników, adresy IP, a czasem tokeny z nagłówków,
• Próbka danych z bazy wklejona, żeby model napisał zapytanie albo migrację,
• Plik .env, który asystent w IDE przeczytał razem z resztą repozytorium, bo agent ma dostęp do całego katalogu projektu,
• Kod klienta wklejony do czatu na prywatnym koncie, bo firmowa licencja jest na inne narzędzie albo nie ma jej wcale,
• Specyfikacja albo mail od klienta wrzucony do streszczenia lub tłumaczenia, razem z nazwiskami, planami wdrożeń i nazwami partnerów,
• Bot do notatek na spotkaniu z klientem, który nagrywa rozmowę i wysyła ją do zewnętrznej usługi, często bez zgody pozostałych uczestników,
• Rozszerzenie przeglądarki z AI, które czyta wszystko, co otwierasz, w tym Jirę i Confluence klienta,
• Serwer MCP podpięty do Jiry, Slacka albo bazy danych klienta przez prywatny token z szerokimi uprawnieniami.

Ostatni punkt zasługuje na chwilę uwagi. Agenci AI, którzy sami czytają pliki, uruchamiają polecenia i łączą się z innymi systemami, to dziś codzienność. Palo Alto Networks zalicza nadmiarowe uprawnienia, wycieki poświadczeń i niekontrolowane wywołania narzędzi przez MCP do nowej klasy ryzyk. Jeden z przykładów w ich artykule dotyczy właśnie programisty, który zbudował wewnętrznego chatbota na danych klientów, korzystając z zewnętrznego API do modeli. Projekt nigdy nie trafił do przeglądu bezpieczeństwa.

Shadow AI to zresztą nie tylko dane, które wypływają z firmy. To także kod, który do niej wpływa. Wygenerowane fragmenty bywają przeglądane mniej uważnie niż te napisane przez człowieka, choć powinny przejść przez code review tak samo jak każda inna zmiana. Model potrafi też z pełnym przekonaniem zaproponować bibliotekę, która nie istnieje. PARP wymienia takie halucynacje wśród konsekwencji Shadow AI. W świecie npm to gotowy scenariusz ataku: ktoś rejestruje paczkę o zmyślonej nazwie i czeka, aż ktoś ją zainstaluje.

Sekcja 4Dlaczego współpraca z klientem podnosi stawkę?

Gdy pracujesz nad własnym produktem, wyciek kodu to problem twojej firmy. Gdy pracujesz dla klienta, kod, dane i dokumentacja należą do niego, a ty działasz w ramach umowy. To zmienia kilka rzeczy.

Umowa decyduje, a nie wygoda. NDA, przeniesienie praw autorskich do kodu, a coraz częściej także osobne klauzule o korzystaniu z AI. Jeśli umowa zabrania przekazywania kodu podmiotom trzecim, to dostawca modelu jest takim podmiotem.

RODO. Jeśli w systemach klienta są dane jego użytkowników, to klient powierzył ci je na konkretnych warunkach. Dostawca AI, do którego trafiają te dane, staje się w rozumieniu RODO kolejnym podmiotem, który je przetwarza, a na to klient musi się wcześniej zgodzić. Poradnik Przedsiębiorcy zwraca też uwagę, że takie dane mogą trafić na serwery poza UE, a firma nie ma żadnego zapisu, gdzie i jak są przetwarzane. Kary za naruszenie RODO sięgają 20 mln euro albo 4% rocznego obrotu firmy.

Poufność. Kod, plany wdrożeń i dokumentacja to często tajemnica firmy klienta, a dbanie o ich poufność jest zwykle wprost zapisane w umowie. Kod klienta w prywatnym czacie trudno nazwać dbaniem o poufność. To argument, którego nikt nie chce usłyszeć w sporze z klientem.

Brak śladu. Gdy klient zapyta, gdzie trafiły jego dane, musisz umieć odpowiedzieć. Przy Shadow AI nie ma logów, nie ma listy narzędzi i nie ma umowy z dostawcą. Palo Alto Networks nazywa to brakiem audytowalności.

Zaufanie. Klient wybiera software house między innymi po to, żeby ktoś odpowiedzialnie obchodził się z jego systemami. Jeden incydent potrafi przekreślić lata współpracy.

Sekcja 5Jak ograniczyć Shadow AI?

Wszystkie trzy teksty, na których opiera się ten wpis, dochodzą do tego samego wniosku: zakazy nie działają, a działają zasady, edukacja i zatwierdzone alternatywy. PARP podkreśla, że zbyt skomplikowane procedury popychają ludzi do działania na własną rękę. Moim zdaniem najlepiej ująć to tak: bezpieczna ścieżka musi być najwygodniejszą ścieżką. Poniżej znajdziesz rozwiązania, które to umożliwiają.

Sekcja 5.1Zatwierdzone narzędzia lepsze niż prywatne

Jeśli zatwierdzone narzędzie jest gorsze od tego, z którego programista korzysta prywatnie, to wygra prywatne. Według ESET i DAGMA w korporacyjne licencje AI zainwestowało tylko 38% firm, co dobrze tłumaczy, skąd bierze się reszta.

Co warto zapewnić zespołowi:

• Plany firmowe zamiast kont prywatnych. W usługach konsumenckich rozmowy mogą trafiać do trenowania modeli, jeśli tego nie wyłączysz. Plany firmowe i dostęp przez API zwykle wyłączają to w umowie. Warunki zmieniają się co kilka miesięcy, więc sprawdzaj je u konkretnego dostawcy,
• Jedną bramkę do modeli (AI gateway). Zespół korzysta z modeli przez wspólne proxy, np. LiteLLM, a nie przez prywatne klucze API. Daje to jedno miejsce na klucze, limity, logi i filtry danych. Część bramek potrafi maskować dane osobowe, zanim zapytanie wyjdzie do dostawcy,
• Listę zatwierdzonych narzędzi w README albo na wiki, z informacją, do jakich danych nadaje się każde z nich. Więcej o spisywaniu ustaleń zespołu pisałem w tekście Creating connected remote teams (po angielsku).

Sekcja 5.2Co można wkleić i gdzie?

Palo Alto Networks radzi zacząć od zdefiniowania danych, które nigdy nie mogą trafić do narzędzi GenAI, i powiązać te zasady z prawdziwą pracą zespołu. W zespole programistycznym sprawdza się prosta tabela, którą każdy zrozumie w pół minuty:

Ostatni wiersz celowo jest taki sam w każdej kolumnie. Sekret, który trafił do jakiegokolwiek modelu, traktuj jak sekret, który wyciekł.

Sekcja 5.3Daj modelowi tylko to, czego potrzebuje

Najprostsza forma ochrony danych to nie wysyłać ich wcale. W większości przypadków model nie potrzebuje prawdziwych danych, żeby pomóc:

• Do zapytania SQL wystarczy schemat tabeli, a nie jej zawartość. Wklej CREATE TABLE albo wynik \d orders, a nie wynik SELECT * ... LIMIT 100,
• Do debugowania wystarczy minimalny przykład. Zamiast całego pliku z logiką biznesową klienta wyodrębnij kilka linii, które odtwarzają błąd. Przy okazji często sam znajdziesz przyczynę,
• Do testów i fixture'ów wygeneruj dane syntetyczne, zamiast kopiować je z produkcji.

Na przykład z Fakerem, który ma też polskie dane:

import { fakerPL as faker } from '@faker-js/faker'

const users = Array.from({ length: 50 }, () => ({
  id: faker.string.uuid(),
  name: faker.person.fullName(),
  email: faker.internet.email(),
  city: faker.location.city(),
}))

Warto też zadbać o to, żeby logi w ogóle nie zawierały wrażliwych danych. Wtedy wklejenie stack trace'a staje się dużo mniej ryzykowne. W Node.js logger pino ma do tego opcję redact:

import pino from 'pino'

const logger = pino({
  redact: [
    'req.headers.authorization',
    'req.headers.cookie',
    'user.email',
    'user.phone',
  ],
})

Wskazane pola trafią do logu jako [Redacted]. Przyda się to nie tylko przy pracy z AI, ale też wtedy, gdy logi czyta ktoś spoza zespołu. Pamiętaj tylko, że redact działa na nazwach pól. Adres e-mail wpisany w treść komunikatu błędu zostanie w logu.

Sekcja 5.4Anonimizuj albo pseudonimizuj dane, zanim trafią do modelu

Czasem prawdziwe dane są potrzebne, np. gdy model ma przeanalizować zgłoszenie od klienta albo streścić dokument z wymaganiami. Wtedy przed wysłaniem warto usunąć z nich wszystko, co pozwala kogoś albo coś zidentyfikować.

Najpierw jedno rozróżnienie, bo te dwa pojęcia często się mylą:

• Anonimizacja jest nieodwracalna. Po niej nie da się ustalić, kogo dane dotyczą, więc RODO przestaje je obejmować,
• Pseudonimizacja zamienia dane na znaczniki, a tabelę zamian trzymasz u siebie. Dzięki temu możesz przywrócić oryginały w odpowiedzi modelu, ale dopóki istnieje tabela zamian, w świetle RODO nadal są to dane osobowe.

Przy pracy z modelem częściej przydaje się pseudonimizacja. Zamieniasz nazwę klienta, nazwiska, adresy e-mail i numery PESEL na znaczniki typu [NAZWA_1] czy [EMAIL_2], wysyłasz tekst do modelu, a w odpowiedzi podmieniasz znaczniki z powrotem. Model widzi strukturę problemu, ale nie widzi, kogo on dotyczy. Uproszczona wersja może wyglądać tak:

const PATTERNS: Array<[string, RegExp]> = [
  ['EMAIL', /[\w.+-]+@[\w-]+\.[\w.-]+/g],
  ['IBAN', /\bPL\d{26}\b/g],
  ['PESEL', /\b\d{11}\b/g],
]

export function pseudonymize(text: string, names: string[]) {
  const tokens = new Map<string, string>() // oryginał -> znacznik
  const counters = new Map<string, number>()

  const tokenFor = (label: string) => (value: string) => {
    if (!tokens.has(value)) {
      const next = (counters.get(label) ?? 0) + 1
      counters.set(label, next)
      tokens.set(value, `[${label}_${next}]`)
    }

    return tokens.get(value)!
  }

  let result = text

  for (const [label, pattern] of PATTERNS) {
    result = result.replace(pattern, tokenFor(label))
  }

  for (const name of names) {
    result = result.replaceAll(name, tokenFor('NAZWA'))
  }

  return { text: result, tokens }
}

export function restore(text: string, tokens: Map<string, string>) {
  let result = text

  for (const [original, token] of tokens) {
    result = result.replaceAll(token, original)
  }

  return result
}

Tablica names to słownik nazw, których żadne wyrażenie regularne nie wyłapie: nazwa klienta, nazwy projektów, nazwiska osób po stronie klienta, wewnętrzne domeny. Najlepiej trzymać go w repozytorium projektu, żeby cały zespół korzystał z tej samej listy.

Wyrażenia regularne powyżej to uproszczenie. Nie wyłapią numeru konta zapisanego ze spacjami ani nazwiska, którego nie ma w słowniku. Do poważniejszych zastosowań warto sięgnąć po gotowe narzędzie, np. Microsoft Presidio. Rozpoznaje ono dane osobowe zarówno wzorcami, jak i modelami NLP, a jeśli brakuje mu polskich danych, takich jak PESEL czy NIP, można dopisać własne reguły. Jeszcze lepiej wpiąć pseudonimizację w bramkę do modeli z poprzedniej sekcji. Wtedy działa zawsze, a nie tylko wtedy, gdy ktoś o niej pamięta.

Są jeszcze dwie pułapki, o których warto wiedzieć:

• Model potrafi zmienić znacznik, np. odmienić go przez przypadki, i wtedy restore go nie znajdzie. Po polsku zdarza się to częściej, niż byś chciał, więc przeglądaj odpowiedź, zanim gdzieś ją wyślesz,
• Kod trudno zanonimizować. Nazwy pakietów i klas, adresy usług, komentarze i sama logika biznesowa potrafią zdradzić klienta. Przy dokumentach i logach pseudonimizacja sprawdza się dobrze, ale przy kodzie klienta właściwą drogą jest zatwierdzone narzędzie i zgoda klienta, a nie zamiana nazw.

Sekcja 5.5Odgródź sekrety od asystentów w IDE

Asystent w edytorze widzi więcej niż czat w przeglądarce. Agent, który sam przegląda repozytorium, przeczyta też .env, jeśli mu na to pozwolisz. Większość narzędzi pozwala wykluczyć wybrane pliki:

• Claude Code: reguły deny w .claude/settings.json,
• Cursor: plik .cursorignore w składni .gitignore,
• GitHub Copilot: content exclusion w ustawieniach repozytorium albo organizacji, w planach Business i Enterprise.

Przykład dla Claude Code:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Ten plik trafia do repozytorium, więc reguły obowiązują cały zespół, a nie tylko osobę, która o nich pamiętała.

Traktuj to jednak jak barierkę, a nie sejf. Najlepiej chroniony sekret to taki, którego nie ma na dysku programisty. Lokalnie korzystaj z kluczy do środowiska deweloperskiego, produkcyjne trzymaj w menedżerze sekretów, a skaner sekretów, np. gitleaks w hooku pre-commit, złapie to, co prześlizgnie się do kodu.

Sekcja 5.6Model lokalny dla najbardziej wrażliwych projektów

Są projekty, w których klient nie zgodzi się na żadną zewnętrzną usługę, np. w bankowości, medycynie albo administracji publicznej. Wtedy zostaje model uruchomiony lokalnie, np. przez Ollamę albo LM Studio. Dane nie opuszczają komputera, więc większość problemów z tego wpisu po prostu znika.

Ceną jest jakość i sprzęt. Lokalne modele są słabsze od największych modeli w chmurze i potrzebują sporo pamięci. Do wyjaśnienia fragmentu kodu, napisania testu czy przeglądu zmian często jednak wystarczą. Rozwiązaniem pośrednim może być model uruchomiony w regionie UE u dostawcy chmury, z którym klient już ma podpisaną umowę.

Sekcja 5.7Ustal zasady z klientem na starcie projektu

Najtańszy moment na rozmowę o AI to kick-off, a nie incydent. Kilka pytań, które warto zadać przed pierwszą linijką kodu:

1. Czy możemy korzystać z asystentów AI przy pracy nad waszym kodem?
2. Z jakich narzędzi i na jakich planach? Czy macie własną listę zatwierdzonych narzędzi albo licencję, z której możemy korzystać?
3. Czy dane osobowe z waszych systemów mogą trafić do dostawcy AI? Jeśli tak, to dopiszmy go do umowy powierzenia danych.
4. Czy możemy nagrywać i transkrybować spotkania?
5. Czy kod wygenerowany przez AI wymaga oznaczenia albo dodatkowego przeglądu?

Odpowiedzi zapisz w umowie albo przynajmniej w dokumentacji projektu, obok zasad pracy z repozytorium. Jeśli klient ma własną licencję na narzędzie AI, korzystaj z niej przy jego kodzie. Wtedy to klient kontroluje, gdzie trafiają jego dane, a ty masz zasady czarno na białym.

Sekcja 5.8Inwentaryzacja i szybka ścieżka dla nowych narzędzi

Palo Alto Networks zaczyna od widoczności, bo nie da się zarządzać czymś, czego nie widać. W zespole programistycznym oznacza to przegląd:

• rozszerzeń w IDE i w przeglądarce,
• serwerów MCP i tokenów, z których korzystają agenci,
• botów do notatek podpiętych do kalendarzy i komunikatorów,
• funkcji AI, które pojawiły się po aktualizacjach w Jirze, Slacku czy GitHubie.

Konfigurację serwerów MCP w repozytorium, np. plik .mcp.json, przeglądaj w pull requestach tak samo jak nowe zależności w package.json. Tokeny dla agentów wydawaj z minimalnymi uprawnieniami, osobne dla każdego klienta, a najlepiej tylko do odczytu.

Drugi element to szybka ścieżka dla nowych narzędzi: prosty formularz, osoba odpowiedzialna za decyzję i termin odpowiedzi liczony w dniach, a nie w miesiącach. Palo Alto Networks zaleca też ponowną ocenę zatwierdzonych narzędzi co 6-12 miesięcy, bo nowe funkcje AI pojawiają się w nich bez zapowiedzi.

Sekcja 5.9Ucz na przykładach, a nie regulaminem

Regulamin, którego nikt nie czyta, niczego nie zmieni. Dużo lepiej działa przykład z własnego projektu: stack trace z adresami e-mail klientów albo plik .env, który agent miał w kontekście. Palo Alto Networks również zaleca edukację na prawdziwych przykładach.

To zresztą nie tylko dobra praktyka. Od lutego 2025 roku AI Act wymaga od firm, które korzystają z AI, żeby ich pracownicy mieli odpowiednie kompetencje w tym zakresie. Krótkie szkolenie na przykładach z własnych projektów spełni ten wymóg lepiej niż prezentacja z regulaminem.

Sekcja 6Co zrobić, gdy dane już trafiły do czatu?

Prędzej czy później to się zdarzy. Wtedy liczy się szybkość:

1. Sekret (klucz API, hasło, token) unieważnij i wygeneruj nowy. Samo usunięcie rozmowy nie wystarczy, bo nie wiesz, gdzie i jak długo jest przechowywana,
2. Usuń rozmowę i sprawdź, czy konto nie ma włączonego trenowania modeli na rozmowach,
3. Zgłoś to liderowi zespołu albo osobie, która w firmie odpowiada za ochronę danych. Jeśli w treści były dane osobowe klienta, to klient musi się o tym dowiedzieć od razu, a nie przy okazji. To on decyduje, czy zgłosić naruszenie do UODO, a ma na to tylko 72 godziny,
4. Zapisz, co się stało, i sprawdź, której zasady zabrakło.

I to jest moim zdaniem najważniejsze: nie karz za zgłoszenie. Jeśli przyznanie się do błędu kończy się konsekwencjami, to następnym razem nikt się nie przyzna, a Shadow AI zejdzie jeszcze głębiej w cień.

Sekcja 7Checklista

Zanim wkleisz cokolwiek do modelu, sprawdź:

• czy to narzędzie jest zatwierdzone i czy korzystasz z konta firmowego,
• czy w treści nie ma sekretów: kluczy, haseł, tokenów, zawartości .env,
• czy w treści są dane osobowe i czy możesz je zanonimizować,
• czy te dane należą do klienta i czy klient zgodził się na takie użycie,
• czy model naprawdę potrzebuje tych danych, czy wystarczy mu schemat albo minimalny przykład.

Sekcja 8Podsumowanie

W tym wpisie opisałem, czym jest Shadow AI, jak wygląda w pracy zespołu programistycznego i dlaczego praca dla zewnętrznych klientów podnosi stawkę. Shadow AI nie bierze się ze złej woli. Bierze się z presji na tempo pracy, z braku zasad i z procedur, które trwają dłużej niż termin zadania w Jirze. Dlatego, jak zauważa PARP, jest to problem organizacyjny, a nie tylko technologiczny.

Jeśli chcesz go ograniczyć, polecam trzymać się kilku zasad:

• Daj zespołowi zatwierdzone narzędzia, które są wygodniejsze niż prywatne,
• Ustal z klientem zasady korzystania z AI, zanim powstanie pierwsza linijka kodu,
• Wysyłaj do modelu tylko to, czego potrzebuje, a resztę anonimizuj,
• Odgródź sekrety od asystentów w IDE,
• Rozmawiaj o incydentach, zamiast za nie karać.

Mam nadzieję, że ten tekst okaże się przydatny. Jeśli masz pytania albo uwagi, to zachęcam do podzielenia się nimi w komentarzach.