Shadow AI jest już w Twoim kodzie. Dlaczego bankowość potrzebuje modelu zarządzania ryzykiem dla AI-Native SDLC

Oto pytanie, które powinno sprawić, że poczujesz się niekomfortowo: ilu z Twoich pracowników używa niezatwierdzonych narzędzi AI? Nie „czy ich użwają”, ale „ilu z nich”. I nie „eksperymentuje”, tylko „używa”. Codziennie. Również na produkcji. Większość z tego przechodzi przez prywatne konta, których IT nigdy nie zatwierdziło, w firmach, które nigdy nie wykupiły subskrypcji.

Często rozmawiamy o kontekcie, szybkości CI (Continuous Integration) i pętlach feedbacku – technologicznym podwoziu, które decyduje o ROI agentów. Ale istnieje warunek wstępny, nadrzędny wobec tego wszystkiego i nie jest on w ogóle technologiczny. To zarządzanie (ang. governance). A ściślej: brak zarządzania dla kodu generowanego przez AI, który znajduje się w Twoim codebase już teraz, umieszczony tam przez deweloperów, którzy po prostu próbowali wykonać swoją pracę.

Jeśli śledzisz prasę finansową przez ostatnie piętnaście lat, „shadow” ma bardzo konkretne konotacje: shadow banking. Pozabilansowe podmioty – CDO, SPV, SIV – które w sposób niewidoczny akumulowały ryzyko aż do 2008 roku, kiedy to, co niewidoczne, stało się katastrofalne. Definiującą cechą shadow banking nie było to, że był nielegalny. Większość z tego była całkowicie legalna. Definiującą cechą było to, że nikt nie widział ekspozycji na ryzyko.

Shadow AI to ten sam wzorzec, rozgrywający się w Twoim codebase zamiast na Twoim bilansie.

Programowanie z prędkością Tab

Obserwuj pracę dewelopera w 2026 roku. Nie na pokazie demo, nie na prelekcji konferencyjnej – po prostu przyjrzyj się jego rzeczywistej pracy. Wpisuje trzy znaki, wciska Tab. Cztery znaki, Tab. Akceptuj, akceptuj, akceptuj. Kod płynie jak podpowiedzi na klawiaturze smartfona, z tą różnicą, że to kod produkcyjny dla Twojego serwisu płatności.

To właśnie nazywam programowaniem z prędkością Tab (Tab-Speed development). Deweloper korzystający z Copilota lub Claude Code nie pisze kodu linijka po linijce. Nawiguje po sugestiach, akceptuje, odrzuca, koryguje kurs. Stosunek liczby naciśnięć klawiszy do powstałych linii kodu uległ odwróceniu. Tam, gdzie deweloper generował kiedyś 50–100 linii przemyślanego, zweryfikowanego kodu dziennie, teraz może stworzyć kilkukrotnie większą objętość w tym samym czasie.

A to dopiero etap pośrednni. Agentowe workflow – w których AI nie sugeruje pojedynczej linii, lecz realizuje całe zadanie end-to-end – już teraz przechodzą z fazy pokazów demo do produkcji. Autonomiczni agenci tworzą pliki, uruchamiają testy, modyfikują zależności i zgłaszają pull requesty. Shadow copiloci powodują wycieki kontekstu. Shadow agenci podejmują na tej podstawie działania.

Twój pipeline CI został zaprojektowany dla jednego pull requestu dziennie na dewelopera – nazywaliśmy to ciągłą integracją (continuous integration), co z perspektywy czasu jest zabawne, bo nie miało w sobie nic z ciągłości. Teraz trafia do niego dziesięć lub piętnaście. Twoja kolejka przeglądu kodu (review queue) ledwo radziła sobie ze zmianami, które człowiek napisał i w pełni rozumiał. Teraz recenzenci patrzą na różnice w kodzie (diffs), których nawet autor nie przeczytał do końca.

Paradoks kolejki zatwierdzeń

W tym miejscu analogia do shadow banking staje się niepokojąca. Twoi deweloperzy wklejają zastrzeżony kod – Twoją architekturę, Twoją logikę biznesową, szczegóły Twoich API – do prywatnych kont ChatGPT, darmowych planów i jakichkolwiek nowych narzędzi, które pojawiły się na Hacker News w zeszły wtorek. Niektórzy uruchamiają już agentowe narzędzia programistyczne, które nie tylko sugerują kod, ale autonomicznie tworzą pliki, wykonują polecenia i zgłaszają PR-y.

I podobnie jak w przypadku kryzysu shadow banking, reakcja, która wydaje się najbezpieczniejsza – zakazać wszystkiego, zablokować – to reakcja, która pogarsza problem. Zakazywanie narzędzi AI w 2026 roku to prohibicja. Nie powstrzymasz tego zachowania. Zepchniesz je do podziemia, gdzie nie będziesz widzieć go wcale. Organizacje, które zaczynają od zrozumienia, co pracownicy robią z AI i dlaczego, budują lepsze bariery ochronne niż te, które zaczynają od blokowania.

Shadow AI to próżnia zarządcza. Próżni zarządczej nie da się rozwiązać zakazem technologicznym. Rozwiązuje się ją systemem – takim, który łączy selekcję opartą na ryzyku (risk-based triage), egzekwowanie procedur (policy enforcement) oraz pełną historię tego, jak powstały zmiany wspomagane przez AI.

To jest również problem, nad którym pracowaliśmy w VirtusLab. Stworzyłyśmy Visdom jako modułową platformę do obsługi dostarczania oprogramowania AI-native w ramach istniejącego w organizacji SDLC, zamiast go zastępować. Zapewnia ona warstwę operacyjną pomiędzy programowaniem z AI a produkcją: kontekst, zarządzane workflow, przegląd oparty na ryzyku, egzekwowanie procedur oraz identyfikowalność (traceability).

Agent AI potrafi wygenerować diff w kilka sekund. Doświadczony inżynier wciąż potrzebuje minut – czasem kilkudziesięciu minut – aby go przeanalizować. To są dane zmierzone, a nie hipotetyczne: na próbie 10 000 deweloperów Faros AI ustaliło, że zespoły o wysokim poziomie wdrażania AI scalają o 98% więcej pull requestów, przy czym czas przeglądu na zmianę rośnie o 91%, a średnia wielkość PR-u o 154%. Przełóż tę presję na sześcioosobowy zespół deweloperów, z których każdy generuje osiem PR-ów dziennie, a otrzymasz czterdziesto osiem pozycji w kolejce do przeglądu. Dwóch recenzentów zatwierdzających po dziesięć PR-ów pozostawia dwadzieścia osiem z tyłu. Poniedziałek: 28 nieprzejrzanych. Wtorek: 56. Środa: 84. Do piątku: 140.

Do końca miesiąca zaległości są tak duże, że recenzenci zaczynają przyklepywać wszystko jak leci, aby nadążyć. W tym momencie proces przeglądu staje się gorszy niż bezużyteczny – staje się teatrem. Daje pozory nadzoru, nie zapewniając żadnej realnej treści.

To jest właśnie paradoks kolejki zatwierdzeń: im szybciej generujesz kod, tym bardziej wartościowy staje się przegląd – i tym mniej masz czasu, by go przeprowadzić. Rozwiązaniem nie jest większa liczba recenzentów. Nie da się rozwiązać problemu skalowania wykładniczego poprzez zasoby liniowe. Jedno zastrzeżenie: przegląd to kolejka, którą widzisz. Jeśli zmiany spiętrzają się po przeglądzie, scalone, ale czekające na wdrożenie, oznacza to, że wąskie gardło znajduje się dalej w procesie, a szybsze czyszczenie kolejki przeglądu wypełni tylko następną. Diagnozą jest jedno pytanie: ile zmian przeszło przegląd, ale nie zostało jeszcze udostępnionych użytkownikom?

Zielony / Żółty / Czerwony

Jeśli zakazywanie nie działa, a przepuszczanie wszystkiego jest szaleństwem, to co jest trzecią drogą? 

Potrzebujesz systemu selekcji (triage system). Nie dla deweloperów, a dla zmian. Systemu, który kategoryzuje każdy commit, każdy pull request, każdy diff do jednego z trzech koszyków na podstawie ryzyka i kieruje każdy koszyk do odpowiedniego poziomu nadzoru. Nazywam to modelem Zielony / Żółty / Czerwony (Green / Yellow / Red model), a jego główna myśl jest prosta: nie każda zmiana wymaga weryfikacji przez człowieka, a im mniej zmian jej wymaga, tym wyższe jest Twoje ROI.

To nie jest słabszy governance. To zarządzenie ryzykiem – coś, co bankowość rozumie od dziesięcioleci. Pacjent z zacięciem od papieru nie idzie do chirurga urazowego. Zasoby trafiają tam, gdzie mają znaczenie, ponieważ system nie traktuje każdego przypadku jednakowo. Na każdym szczeblu organizacji praca, która pozostaje do wykonania, to praca, za którą ktoś musi wziąć odpowiedzialność. W przypadku ścieżki Zielonej nie chodzi o ślepe zaufanie maszynie. Chodzi o wyeliminowanie podpisów, których i tak nikt tak naprawdę nie składał.

The false-positive math

W tym miejscu pada większość systemów governance: na równowadze fałszywych alarmów (false positives). Ustaw próg dla ścieżki Zielonej zbyt nisko, a będziesz niewidocznie akumulować ryzyko. Jeden zły wzorzec rozpropaguje się w trzydziestu serwisach, zanim ktokolwiek to zauważy. Ustaw go zbyt wysoko, a każda zmiana nadal będzie wymagać weryfikacji przez człowieka. Zastąpisz wtedy jedno wąskie gardło – pisanie kodu – innym – jego przeglądaniem – a Twoja droga inwestycja w AI nie przyniesie żadnego ROI, ponieważ ludzie pozostaną czynnikiem ograniczającym przepustowość.

Pozwól, że zrobię obliczenia, bo w tym miejscu przechodzimy do konkretów. Jeśli przegląd wykonany przez człowieka kosztuje 150 USD w pełnym koszcie pracy inżyniera, a błąd typu false positive, który przedostanie się na produkcję, kosztuje średnio 5 000 USD do naprawienia, to potrzebujesz wskaźnika dokładności ścieżki Zielonej powyżej około 97%. Poniżej tej wartości oczekiwany koszt błędów przewyższa oszczędności wynikające z automatyzacji. Powyżej niej każdy punkt procentowy staje się realnym ROI.

Ten wzór to część, którą warto zapamiętać: podziel koszt jednego przeglądu przez koszt jednego błędu, a otrzymasz dokładność, jaką Twój koszyk Zielony musi osiągnąć, aby automatyzacja się opłacała. Wstaw swoje własne dwie liczby. Liczy się nie tyle wysokość oszczędności, ile fakt, że ten próg jest w ogóle obliczalny – oraz to, że większość organizacji nigdy go nie obliczyła.

I oto dźwignia, która zamienia ten proces w samonapedzający się mechanizm, a nie jednorazową wygraną: koszyk Zielony rośnie z czasem. Każda decyzja na ścieżce Żółtej uczy system czegoś nowego. Każda rozwiązana eskalacja na ścieżce Czerwonej dostarcza sygnał treningowy. Granica przesuwa się nie dlatego, że obniżasz swoje standardy, ale dlatego, że Twoje automatyczne sprawdziany stały się mądrzejsze. To są procenty składane w zarządzeniu (governance).

Ciągła modernizacja

Automatyczne podejmowanie decyzji stwarza kolejną możliwość: autonomiczną ekipę konserwacyjną pracującą na nocnej zmianie.

Każda organizacja inżynieryjna zna te systemy:

• Wewnętrzne narzędzie napisane w Java 8, które wciąż działa na produkcji, bo po prostu działa, ale nikt nie odważa się go dotknąć, ponieważ pierwotny zespół odszedł trzy lata temu.
• Serwis w Python 2 obsługujący fakturowanie dla jednego klienta ze starego systemu (legacy client).
• Biblioteka zablokowana na wersji z 2021 roku, ponieważ aktualizacja kiedyś coś zepsuła i nikt nie miał czasu ustalić, co dokładnie.

Te projekty nadal mają wartość. Przetwarzają transakcje, obsługują klientów i generują przychody. Ale są też obciążeniem: podatnościami na zagrożenia bezpieczeństwa, lukami w zgodności oraz rosnącą niezgodnością z nowoczesną infrastrukturą. Tradycyjny rachunek był prosty: koszt modernizacji przewyższał koszt utrzymania status quo. Zostały więc zamrożone.

Ten rachunek uległ zmianie. Agenci AI, zwłaszcza w połączeniu z deterministycznymi narzędziami transformacji, mogą modernizować te codebase'y w tle, w godzinach poza szczytowymi. Podbić wersję Spring Boot. Zmigrować z JUnit 4 na JUnit 5. Zastąpić wycofane wywołania API (deprecated API calls). Podnieść wersję z Java 11 do Java 21. Nie w formie heroicznego, trzymiesięcznego projektu migracyjnego z dedykowanym zespołem i epikiem w Jira, którego nikt nie chce prowadzić, ale stopniowo, w sposób ciągły, jako proces w tle.

Agent identyfikuje przestarzałą zależność, tworzy brancha, aplikuje zmianę, uruchamia zestaw testów i zgłasza PR – który następnie przechodzi przez ścieżki Zieloną / Żółtą / Czerwoną. Jeśli testy przechodzą i żadne reguły architektoniczne nie zostaną naruszone, zmiana automatycznie się merguje. Ścieżka Zielona. Człowiek nigdy tego nie widzi. Codebase staje się odrobinę zdrowszy. Można powtarzać bez końca.

To jest właśnie ciągła modernizacja. Małe, zautomatyzowane zmiany kumulują się z czasem w usprawnienia architektoniczne, nie rywalizując o uwagę człowieka. Budzisz się w poniedziałek rano i dowiadujesz się, że czterdzieci siedem podbic wersji zależności zostało scalonych przez noc, trzy zostały oznaczone jako Żółte do przeglądu, a codebase jest zauważalnie zdrowszy niż był w piątek.

Ścieżka audytu: gdzie wpisuje się Visdom AI Tracing

Ale istnieje drugi wymiar, a ten wiąże się z konkretnym terminem: identyfikowalność (traceability).

Kiedy audytor, regulator, zespół ds. bezpieczeństwa klienta lub śledczy zajmujący się obsługą incydentów spojrzy na Twój codebase, zada pytania, na które większość organizacji nie potrafi obecnie odpowiedzieć:

• Skąd wziął się ten kod?
• Czy został napisany przez człowieka, czy wygenerowany przez AI?
• Przez jaki model? Jaką wersję?
• Jaki kontekst lub specyfikacja go wywołały?
• Kto dokonał przeglądu – i czy ten przegląd był merytoryczny, czy powierzchowny?
• Kiedy kod został zatwierdzony?
• Kiedy został wdrożony?

Minimum programowe dla ścieżki audytu (minimum viable audit trail) dla kodu generowanego przez AI to pięć pól:

• origin model
• timestamp
• context
• approver
• deployment date

Pięć pól. Jeśli dzisiaj ich nie posiadasz, kumulujesz dług zgodności (compliance debt) w tym samym wykładniczym tempie, w jakim kumulujesz kod.

W tym miejscu shadow banking staje się ukrytym zobowiązaniem. W 2008 roku pytanie brzmiało: co tak naprawdę znajduje się w naszym bilansie? W AI-native SDLC pytanie brzmi: co tak naprawdę znajduje się w naszym codebase? Organizacje, które nie potrafią na nie odpowiedzieć, ostatecznie odbiorą tę samą lekcję.

To jest dokładnie ten problem, do którego rozwiązania został zaprojektowany Visdom AI Tracing. Rejestruje on interakcje AI w całym cyklu życia oprogramowania – prompty, wywołania modeli, odpowiedzi, użycie narzędzi, zmiany w plikach, sesje, commity oraz przypisanie autorstwa kodu – i łączy je w pełną, odporną na manipulacje ścieżkę audytu. Zamiast odtwarzać zdarzenia po fakcie, zespoły otrzymują wyszukiwalną historię rozwoju, która pokazuje, jak powstał kod, jakie narzędzia i modele były zaangażowane, jakie procedury miały zastosowanie i kto zatwierdził wynik.

Dla banku jest to czarna skrzynka wspieranego przez AI dostarczania oprogramowania. Visdom AI Tracing dodaje przypisywanie autorstwa na poziomie linii kodu, egzekwowanie procedur, rejestry zgodności, narzędzia śledcze oraz analitykę użycia i kosztów. W połączeniu z zapewnianym przez Visdom kontekstem, przeglądem opartym na ryzyku, bezpieczeństwem i zarządzanymi workflow agentów, zamienia on aktywność AI z niewidocznej ekspozycji w widoczny i kontrolowany proces operacyjny. Ta warstwa musi działać z prędkością maszynową, ponieważ governance, który jest wolniejszy od pracy, którą zarządza, zawsze zostanie obejściowy.

Pytanie nie brzmi już „czy”

Shadow AI nie zniknie. Programowanie z prędkością Tab nie zniknie. Objętość kodu generowanego przez AI w Twoim codebase będzie tylko rosła. Coinbase opublikowało własną krzywą: kod generowany przez AI stanowił 5,7% wszystkiego, co zostało scalone (merged) w I kwartale 2025 roku, przekroczył 50% w IV kwartale 2025 roku i osiągnął „prawie całość” nowego kodu w ciągu roku.

Pytanie nie brzmi, czy na to zezwolić – ten pociąg odjechał, kiedy pisałeś swój dokument dotyczący polityki AI.

Pytanie brzmi, czy będziesz mieć widoczność, identyfikowalność i inteligentną selekcję przed pierwszym poważnym ustaleniem z audytu, czy po nim.