Dla firmy technologicznej wprowadzenie autonomicznych agentów piszących kod może zacząć się jako eksperyment zwiększający produktywność. Dla banku zaczyna się to od problemu z zakresu architektury, bezpieczeństwa i governance, ponieważ system AI, który czyta repozytoria, wykonuje polecenia, wywołuje API, modyfikuje kod i otwiera Pull Requests, jest nowym maszynowym aktorem wewnątrz Software Development Lifecycle.
Bank musi zatem zdecydować, do czego ten aktor może mieć dostęp, z jakich modeli może korzystać, dokąd mogą przesyłać się dane, jak chronione są credentials, jak jego wyniki są niezależnie weryfikowane, kiedy wymagana jest akceptacja człowieka oraz jak każde działanie może zostać odtworzone miesiące później na potrzeby bezpieczeństwa, compliance lub audytu. Żadna z tych rzeczy nie może być wdrożona wewnątrz system promptu ani oddelegowana do samego agenta. Wymagają one mechanizmów kontrolnych znajdujących się poza modelem: zarządzania dostępami, izolacji sieciowej, egzekwowania polityk, orkiestracji workflow, niezależnych bramek jakości oraz warstwy audytowej.
Visdom to platforma AI-native SDLC stworzona dla branż regulowanych, w których autonomiczna AI w procesie wytwarzania oprogramowania musi współistnieć z rygorystycznymi wymogami dotyczącymi bezpieczeństwa, governance, audytowalności i nadzoru człowieka. Jest stworzona wokół tych ograniczeń na poziomie architektonicznym: implementacja typu self-hosted, kontrolowany dostęp do modeli, izolowane wykonywanie agentów, jednoznaczne approval gates oraz weryfikowalny ślad audytowy.
Agenci kodujący działają wewnątrz tego środowiska, a nie są przez nie zastępowani. Claude Code, Codex, IBM Bob lub inny agent wykonują pracę wdrożeniową, podczas gdy Visdom określa kontekst, jaki otrzymuje agent, granice, w których działa, walidację, jaką musi przejść jego wynik, oraz dowody zachowane z wykonania.
1. Bank musi kontrolować, dokąd trafia jego kod i prompty
Gdy AI dołącza do procesu deweloperskiego, kod źródłowy przestaje być jedynym wrażliwym zasobem. Prompty przenoszą logikę biznesową, szczegóły architektury, opisy zgłoszeń, informacje o incydentach oraz fragmenty wewnętrznej dokumentacji. Wykonania agentów generują telemetrię opisującą repozytoria, systemy i aktywność inżynieryjną. Bank musi dokładnie wiedzieć, gdzie to wszystko jest przetwarzane i czy cokolwiek z tego opuszcza jego infrastrukturę.
Visdom działa w modelu self-hosted wewnątrz środowiska Kubernetes klienta. Nie ma tu panelu sterowania obsługiwanego przez dostawcę ani wychodzącej telemetrii do infrastruktury VirtusLab. Wdrożenie obsługuje również działanie w trybie air-gapped: obrazy platformy są dostarczane jako podpisane pakiety do wewnętrznego rejestru kontenerów banku, bez konieczności łączności z Internetem.
Dostęp do modeli podlega tej samej zasadzie. Visdom wykorzystuje architekturę BYO-LLM, co oznacza, że agent nigdy nie komunikuje się bezpośrednio z dostawcą modelu — przechodzi przez warstwę sterowników i bramkę LLM gateway, którą kontroluje bank. Bank może kierować ruch do zatwierdzonego modelu zewnętrznego przez własną bramkę lub uruchamiać modele open-weight całkowicie wewnątrz własnej infrastruktury. Wersje modeli są jednoznacznie przypięte, zamiast odwoływać się do wariantu „latest”, a listy dozwolonych są egzekwowane jako polityka: wykonanie, które żąda modelu spoza zatwierdzonej listy, jest blokowane i rejestrowane jako zdarzenie audytowe.
W kontekście DORA istotnie zmienia to obraz ryzyka stron trzecich. Platforma self-hosted bez panelu sterowania dostawcy zmniejsza ekspozycję na koncentrację ICT opisaną w artykułach 28–30 oraz upraszcza strategię wyjścia, którą bank musi udokumentować dla każdego krytycznego dostawcy ICT.
2. AI potrzebuje granic egzekwowanych maszynowo
Tradycyjne zarządzanie pracą deweloperów opiera się na założeniu, że człowiek rozumie polityki organizacji. Autonomiczny agent nie spełnia tego założenia. Wykonuje polecenia, modyfikuje pliki i komunikuje się z zewnętrznymi systemami, a nakazanie mu w system promptcie, aby trzymał się z dala od środowiska produkcyjnego lub od danych uwierzytelniających, nie stanowi granicy bezpieczeństwa. Mechanizmy kontroli bezpieczeństwa muszą ograniczać agenta, zamiast polegać na tym, że pamięta on o ich przestrzeganiu.
Visdom wdraża to na warstwie wykonawczej. Zadania agenta uruchamiają się jako odizolowane Kubernetes Jobs. Polityka sieciowa działa w trybie domyślnej odmowy (default-deny), a ruch wychodzący jest ograniczony do jednoznacznie zatwierdzonych celów: Jira, Bitbucket, rejestrów pakietów oraz bramki LLM gateway banku.
Platforma egzekwuje również ograniczenia dotyczące samej zmiany, skonfigurowane dla poszczególnych repozytoriów lub procesów workflow: limity liczby i zakresu modyfikowanych plików, ochronę ścieżek krytycznych, ograniczenia dotyczące usuwania lub zmiany nazw publicznych interfejsów bez wyraźnej autoryzacji, a także budżety tokenów i kosztów.
3. Agent nie powinien posiadać danych uwierzytelniających
Agent kodujący potrzebuje danych uwierzytelniających, aby uzyskać dostęp do repozytoriów, interfejsów API, rejestrów pakietów i modeli. Prawdziwy klucz API znajdujący się w środowisku agenta może pojawić się w kontekście modelu, w wygenerowanym kodzie, w wyniku wykonania polecenia lub w logach.
Visdom rozdziela możliwość użycia danych uwierzytelniających od możliwości ich zobaczenia. Dane poufne są pobierane w trybie just-in-time z magazynu secret store banku, takiego jak HashiCorp Vault, a agent otrzymuje symbol zastępczy zamiast rzeczywistej wartości. Przezroczysty proxy sieciowy podstawia właściwe dane uwierzytelniające w momencie, gdy żądanie wychodzi do jednoznacznie autoryzowanego celu, i odrzuca żądanie w każdym innym miejscu.
Proxy chroni wartość sekretu, a nie uprawnienia do niego dołączone, dlatego autoryzacja jest określana dla każdego celu z osobna i oceniana przy każdym żądaniu. Agent, który ma dostęp do serwisu Bitbucket, nie może wykorzystać tego uprawnienia do połączenia się z dowolnym innym punktem końcowym, a zakres tego, co może zrobić w każdym celu, stanowi część polityki, a nie właściwość samego tokenu.
Daje to bankowi również strukturalną odpowiedź na zjawisko shadow AI. Dostęp do zatwierdzonych modeli odbywa się za pośrednictwem platformy, dzięki czemu surowe klucze API od dostawców modeli nigdy nie muszą być dystrybuowane do deweloperów ani do agentów.
4. Każda akcja AI wymaga przypisania autorstwa
Commit w systemie Git mówi o tym, co zostało zmienione i które konto dokonało zmiany. To zbyt mało, gdy AI bierze znaczący udział w procesie wdrażania.
Załóżmy, że zgłoszenie Pull Request powoduje incydent produkcyjny sześć miesięcy po połączeniu zmian. Bank musi być w stanie odtworzyć, który model wygenerował zmianę i w jakiej wersji, jaki prompt zapoczątkował pracę, jaki kontekst został dostarczony, jakie narzędzia wywołał agent, które pliki skontrolował i zmodyfikował, które polityki były aktywne oraz który człowiek dokonał przeglądu wyniku.
Visdom AI Tracing pełni w tym przypadku rolę czarnej skrzynki (flight recorder). Rejestruje sesje agentów, prompty, wywołania modeli, użycie narzędzi, modyfikacje plików oraz powstałe commity. Każde zdarzenie jest haszowane algorytmem SHA-256 i połączone w łańcuch z poprzednim, dzięki czemu jakakolwiek późniejsza edycja zapisanego zdarzenia przerywa ten łańcuch, a sam łańcuch jest podpisany kluczem Ed25519 organizacji.
Visdom zapewnia również przypisywanie autorstwa AI na poziomie konkretnych linii kodu, wykorzystując historię Git oraz parsowanie tree-sitter (tree-sitter buduje drzewo składniowe pliku, dzięki czemu przypisywanie podąża za strukturą kodu, a nie za surowymi numerami linii). Przypisanie autorstwa jest rozstrzygające na poziomie sesji i commitów. Na poziomie linii jest to mapowanie oparte na zasadzie best-effort, którego dokładność spada w przypadku dużych refaktoryzacji i ponownego formatowania — co warto zaznaczyć z góry, zamiast odkrywać to podczas prezentacji demonstracyjnej.
W ten sposób zarządzanie AI (AI governance) przestaje być jedynie deklaracją, że AI było używane zgodnie z polityką, a staje się dowodem na to, jak faktycznie zostało użyte.
Przeczytaj również: Shadow AI jest już w Twoim kodzie. Dlaczego bankowość potrzebuje modelu zarządzania ryzykiem dla AI-Native SDLC
5. Same wpisy audytowe muszą być wiarygodne
Rejestrowanie aktywności AI rozwiązuje połowę problemu związanego z audytem. Druga połowa polega na tym, czy taki zapis jest wiarygodny, a dziennik zdarzeń (audit log), który administrator może po cichu nadpisać, ma ograniczoną wartość dowodową.
Ponieważ zdarzenia są powiązane kryptograficznie w łańcuch, modyfikacja jednego z nich uniemożliwia weryfikację wszystkich następnych. Powstały w ten sposób ślad można zweryfikować w trybie offline przy użyciu klucza publicznego organizacji, bez konieczności obdarzania zaufaniem ze strony audytora działającej instancji Visdom. Klucz prywatny znajduje się w bankowym module HSM lub usłudze KMS; Visdom jedynie wysyła żądania złożenia podpisu i nigdy nie przechowuje samego materiału klucza – to właśnie zapewnia spójność argumentu o weryfikacji offline.
Podpisane zdarzenia są eksportowane do systemu SIEM banku poprzez Syslog, ustrukturyzowany format JSON, Splunk HEC lub Elastic Bulk, przy czym każde z nich zawiera swój numer sekwencyjny, poprzedni hash, bieżący hash oraz podpis. Czas przechowywania danych po stronie platformy jest konfigurowalny, z architektonicznym minimum wynoszącym 12 miesięcy; ustawowe okresy przechowywania, które w bankowości sięgają lat, są realizowane poprzez eksport do własnego systemu SIEM banku lub pamięci masowej WORM, a nie przez bazę danych platformy.
Odpowiada to bezpośrednio na wymogi dotyczące zarządzania ryzykiem ICT i logowania zawarte w artykułach 8–10 rozporządzenia DORA, ponieważ ten sam mechanizm generuje zarówno log operacyjny, jak i dowód na to, że log nie został naruszony.
6. Udział człowieka w pętli musi być częścią architektury
Nadzór ze strony człowieka jest zazwyczaj opisywany jako zasada z zakresu governance. W procesie AI-native SDLC musi on być również pierwotnym elementem technicznym.
Procesy w Visdom zawierają jednoznaczne węzły zatwierdzania. Polityka zatwierdzania określa, kto może zatwierdzić dany krok, jak długo to zatwierdzenie pozostaje ważne oraz co dzieje się w przypadku zatwierdzenia, odrzucenia lub wygaśnięcia. Zaangażowanie człowieka nie ogranicza się jedynie do końcowego Pull Requesta: agent może wstrzymać działanie w trakcie wykonywania, aby poprosić o wyjaśnienie, a operatorzy mogą dołączyć kontekst do uruchomionego wykonania, anulować je lub zrestartować workflow z nowymi instrukcjami.
To, jak dużą autonomię otrzymuje dana zmiana, zależy od jej klasy ryzyka, a klasyfikacja ta została opisana w sekcji 7. W przypadku zmian sklasyfikowanych jako LOW (niskie ryzyko), polityka banku może zezwalać na automatyczne połączenie (merge) po przejściu każdego deterministycznego bramki (gate). Dla klas MEDIUM (średnie ryzyko) i wyższych, zatwierdzenie przez człowieka jest egzekwowane przez platformę i nie można go wyłączyć w konfiguracji. W obu przypadkach zachowany jest podział obowiązków (separation of duties), ponieważ bramki, które zatwierdzają zmianę, są niezależne od agenta, który ją wygenerował, a zatwierdzającym nigdy nie jest sam agent.
7. Kod wygenerowany przez AI wymaga innego modelu jakości
Generatywna AI obniża koszt wytwarzania kodu w znacznie większym stopniu niż koszt ustalenia, czy ten kod jest poprawny, co przesuwa wąskie gardło na etap przeglądu. Agenci generujący zmiany szybciej, niż inżynierowie są w stanie je przeczytać, tworzą kolejkę zgłoszeń Pull Request, a dodawanie kolejnych agentów jedynie tę kolejkę wydłuża.
Visdom skaluje walidację poprzez wielowarstwowy przegląd. Wczesne etapy są deterministyczne i tanie: zebranie różnic w kodzie (diff) i kontekstu repozytorium, uruchomienie lintingu i formatowania, zbudowanie projektu, skanowanie pod kątem wycieku sekretów, uruchomienie SAST oraz analiza zależności. Zmiana jest następnie klasyfikowana pod kątem ryzyka i tylko zmiany powyżej skonfigurowanego progu trafiają do kosztownego, głębokiego przeglądu opartego na AI. W przypadku zmian o ryzyku MEDIUM i wyższym Visdom uruchamia osobne perspektywy przeglądu pod kątem Bezpieczeństwa, Poprawności oraz Jakości Testów, z opcjonalnymi wymiarami Wydajności i Łatwości Utrzymania.
Wykryte kwestie posiadają przypisane poziomy pewności, zamiast przedstawiać każdą obserwację AI jako równie pewną. Celem projektowym jest precyzja, a nie czułość, ponieważ przegląd generujący szum informacyjny jest ignorowany lub wyłączany, a ten stan rzeczy pogarsza się dokładnie w takim tempie, w jakim rośnie wolumen kodu generowanego maszynowo.
8. Testy napisane przez AI wymagają niezależnej weryfikacji
Jeśli ten sam model pisze wdrożenie (implementację), a następnie pisze do niego testy, udany proces budowania (green build) pokazuje jedynie, że model zgadza się sam ze sobą. Testy mogą zawierać to samo błędne założenie, co sam kod.
Visdom Testing dodaje walidację, która nie zależy od testów opartych na przykładach (example-based tests) wygenerowanych przez agenta kodującego:
Testy architektury egzekwują ograniczenia strukturalne – granice warstw, niedozwolone zależności, zakazane przestarzałe interfejsy API – w postaci asercji, które powodują niepowodzenie budowania projektu.
Testy oparte na właściwościach definiują niezmiennik (invariant), który musi zawsze obowiązywać, i sprawdzają go na dużej liczbie wygenerowanych danych wejściowych, zamiast polegać na zaledwie kilku przypadkach, które deweloper lub agent pomyślał, by zapisać.
Testowanie mutacyjne celowo wprowadza błędy (defekty) do zmodyfikowanego kodu i mierzy, czy zestaw testów je wyłapuje, co pozwala przetestować same testy, a nie wdrożenie. Ponieważ jest to proces kosztowny, budżet mutacyjny jest ograniczony do zmienionego kodu i skalowany według klasy ryzyka.
Testowanie kontraktów weryfikuje kompatybilność między usługami przed ich wdrożeniem, dzięki czemu zmiana u dostawcy nie doprowadzi do cichej awarii u jej odbiorców.
Visdom oblicza również wskaźnik niezawodności testów (Test Oracle Reliability Score), który identyfikuje testy, których niepowodzenia nie wskazują niezawodnie na rzeczywisty defekt. Testy poniżej progu niezawodności są poddawane kwarantannie, dzięki czemu autonomiczni agenci nie marnują kolejnych iteracji na próby naprawy niestabilnych testów.
Pytanie, na które bank musi odpowiedzieć w kontekście zmiany wygenerowanej przez AI, nie brzmi, czy testy zakończyły się sukcesem, ale ile niezależnych dowodów dostarczają te testy na to, że zmiana jest poprawna.
9. Korporacyjna AI potrzebuje kontekstu organizacyjnego, a nie tylko dostępu do repozytorium
Agent może przeszukiwać repozytorium, nie rozumiejąc organizacji, która je stworzyła. W dużym banku wiedza wymagana do bezpiecznego wprowadzania zmian w oprogramowaniu jest rozproszona: wspólna biblioteka wpływa na dziesiątki korzystających z niej usług, osoba formalnie wskazana jako właściciel komponentu często nie jest inżynierem, który go utrzymuje, dziwnie wyglądająca implementacja istnieje z powodu decyzji architektonicznej podjętej lata wcześniej, a powtarzająca się uwaga w przeglądzie kodu odzwierciedla konwencję, której nikt nigdy nie spisał.
Visdom Context Fabric przekształca te sygnały w infrastrukturę, z której mogą korzystać agenci. Agreguje kod źródłowy, historię Git, infrastrukturę jako kod (Infrastructure as Code), dyskusje w zgłoszeniach Pull Request, system Jira oraz dokumentację, taką jak Confluence, i kompiluje je w wielokrotnego użytku warstwę wiedzy, zamiast przekazywać agentowi nieustrukturyzowany zbiór dokumentów. Wyróżnia pięć poziomów:
L1, kontekst systemowy: usługi, zależności, kontrakty, granice architektoniczne.
L2, kontekst kodu: konwencje, konfiguracja budowania, zasady lintingu, powtarzające się reguły przeglądu kodu.
L3, kontekst organizacyjny: rzeczywiści właściciele modułów, doświadczeni weryfikatorzy (reviewers), ścieżki eskalacji.
L4, kontekst historyczny: dokumenty ADR (Architectural Decision Records), dyskusje w zgłoszeniach Pull Request, analizy poincydentowe, wcześniejsze decyzje architektoniczne.
L5, kontekst operacyjny: telemetria i historia incydentów.
Obok wiedzy wygenerowanej przez AI, Context Fabric utrzymuje deterministyczne struktury analityczne oparte na historii Git, grafach zależności oraz dyskusjach z Pull Requestów. Pozwalają one ustalić właścicieli modułów, promień rażenia, mapy kompetencji oraz mapy ciepła zmian w drodze obliczeń, a nie wnioskowania.
To, czego potrzebuje bank, to nie agent, który potrafi znaleźć kod powiązany z danym zgłoszeniem (ticketem). Potrzebuje agenta, który wie, co jeszcze może się zepsuć, jeśli ten kod ulegnie zmianie, kto rozumie dany obszar oraz jakie historyczne ograniczenia powinny kształtować nową implementację.
W środowisku liczącym kilka tysięcy repozytoriów jest to również problem infrastrukturalny. Context Fabric indeksuje dane przyrostowo i priorytetyzuje aktywne repozytoria, dzięki czemu koszt przetwarzania jest proporcjonalny do skali zmian, a nie do całkowitego rozmiaru środowiska.
10. Koszty AI również wymagają kontroli i zarządzania
W przypadku asystentów AI zintegrowanych ze środowiskiem IDE (copilots) wydatki na modele pozostają powiązane z bezpośrednimi działaniami człowieka. W przypadku procesów autonomicznych jedno zgłoszenie może uruchomić wielu agentów, serię wywołań modeli, iteracje przeglądu kodu, cykle generowania testów oraz próby ponowienia, z których żadne nie było zatwierdzane przez człowieka z osobna.
Visdom rejestruje wykorzystany model, liczbę tokenów, opóźnienia, status oraz koszt każdego wywołania, przypisując koszty do konkretnych sesji, autorów, zgłoszeń Pull Request, repozytoriów, zespołów oraz całych procesów workflow. Budżety mają charakter wykonawczy: wyczerpana kwota zapobiega uruchomieniu kolejnego procesu workflow, zamiast ujawniać się jako przekroczenie budżetu na koniec miesiąca. Ta różnica zyskuje na znaczeniu w momencie, gdy organizacja przechodzi od kilkudziesięciu deweloperów eksperymentujących z asystentami do setek lub tysięcy autonomicznych wykonań.
Od kodowania z AI do AI-native SDLC
Agent kodujący odpowiada na jedno pytanie: czy AI potrafi wdrożyć tę zmianę? Bank prowadzący proces w modelu AI-native SDLC musi odpowiedzieć na wszystkie pozostałe pytania, przy czym każde z nich dotyczy decyzji podejmowanej przez platformę, a nie możliwości samego modelu:
Czy agent powinien mieć w ogóle prawo do wykonania tego zadania, a jeśli tak, to z jakim poziomem autonomii dla danej klasy zmian?
Jaki kontekst organizacyjny otrzymuje agent?
Do jakich repozytoriów, interfejsów API oraz celów sieciowych może mieć dostęp?
Z jakiego modelu i w jakiej wersji może korzystać oraz gdzie przetwarzane są kod i prompty?
W jaki sposób dane uwierzytelniające (credentials) są chronione przed samym agentem?
Co dzieje się, gdy agent zakończy działanie błędem, zawiesi się lub wyczerpie swój budżet?
W jaki sposób wygenerowany kod jest niezależnie walidowany i które zmiany wymagają zatwierdzenia przez człowieka?
Ile może kosztować autonomiczne wykonanie zadania?
Jak odtworzyć przebieg zdarzeń po sześciu miesiącach i udowodnić, że materiał dowodowy nie został zmodyfikowany?
Agenci kodujący pozostają wymiennymi silnikami wykonawczymi wewnątrz platformy. Wokół nich Visdom dostarcza kontekst organizacyjny, orkiestrację workflow, izolację środowiska wykonawczego, polityki bezpieczeństwa, niezależną walidację, zatwierdzanie przez człowieka, obserwowalność (observability) oraz kryptograficznie weryfikowalny ślad audytowy, których autonomiczna inżynieria oprogramowania potrzebuje w kontrolowanym środowisku korporacyjnym.
Stanie się organizacją typu AI-native nie oznacza zatem przekazania każdemu deweloperowi potężniejszego asystenta kodowania. Oznacza zbudowanie środowiska, w którym AI może przejąć odpowiedzialność za większe części procesu inżynieryjnego: z autonomią wystarczającą do zmiany tempa i ekonomii dostarczania oprogramowania, oraz z kontekstem, weryfikacją i kontrolą wystarczającymi do tego, by ta autonomia była możliwa do wykorzystania w instytucji regulowanej.
Masz pytania dotyczące AI-native SDLC lub samej platformy Visdom? Skontaktuj się z nami.
