AI w zespołach programistycznych branż regulowanych: jak przyspieszyć pracę i zachować zgodność z przepisami

W skrócie Banki, ubezpieczyciele, instytucje płatnicze, firmy z branży medtech i przedsiębiorstwa przemysłowe, tak jak wszyscy, muszą coraz szybciej rozwijać swoje oprogramowanie. Wiele z nich wstrzymuje się jednak z wykorzystaniem AI w pracy zespołów programistycznych, bo obawia się utraty kontroli nad tym, co trafia na produkcję, i nad tym, jak wytłumaczyć to audytorom. Te obawy są uzasadnione, ale wyciągany z nich wniosek często już nie. Nadzór rzadko zakazuje korzystania z AI przy tworzeniu oprogramowania. Oczekuje natomiast jasnej odpowiedzialności, możliwości odtworzenia każdej zmiany i dowodów na to, że procesy działają. Proces oparty na tych zasadach pozwala bezpiecznie korzystać z AI i jednocześnie przechodzić audyty. W tym artykule wyjaśniamy, na czym naprawdę zależy regulatorom, gdzie AI można stosować przy niskim ryzyku, jakie mechanizmy kontrolne sprawiają, że praca z AI jest gotowa na audyt, i jakich efektów regulowana firma może realnie oczekiwać.

Dlaczego firmy z branż regulowanych się wahają

W większości regulowanych organizacji rozmowa o AI w pracy programistów zaczyna się od listy obaw. Czy kod wygenerowany przez AI nie prześlizgnie się przez code review? Czy będziemy w stanie wykazać, kto zatwierdził zmianę? Czy zastrzeżony kod albo dane klientów nie wyjdą poza firmę? Co powie audytor?

To zasadne pytania. W praktyce największym ryzykiem często nie jest jednak sama AI, lecz korzystanie z niej bez żadnej kontroli. Gdy firma całkowicie zakazuje narzędzi AI, programiści nierzadko i tak po nie sięgają, korzystając z prywatnych kont w przeglądarce. Efekt jest najgorszy z możliwych: organizacja nie zyskuje na produktywności, a jednocześnie traci jakąkolwiek kontrolę.

Znacznie bardziej produktywne jest więc pytanie nie o to, czy korzystać z AI, lecz jak z niej korzystać, aby każdą zmianę dało się wyjaśnić, zweryfikować i przypisać konkretnej, odpowiedzialnej osobie.

Na czym naprawdę zależy regulatorom

Ramy regulacyjne różnią się w zależności od branży i kraju, ale ich wymagania wobec tworzenia oprogramowania opierają się na kilku powtarzających się zasadach.

Odpowiedzialność. Za każdą zmianę, która trafia na produkcję, odpowiada konkretna osoba. AI może wspierać pracę, ale nie może ponosić odpowiedzialności.

Możliwość odtworzenia zmian. Musi dać się ustalić, kto co zmienił, dlaczego, na podstawie jakiego wymagania oraz kto zmianę sprawdził i zatwierdził.

Rozdzielenie obowiązków. Osoba, która przygotowuje zmianę, nie powinna być jedyną osobą, która ją zatwierdza. Zasada czterech oczu obowiązuje niezależnie od tego, czy kod powstał ręcznie, czy z pomocą AI.

Zarządzanie ryzykiem dostawców zewnętrznych. Zewnętrzne narzędzia i usługodawcy, którzy przetwarzają kod lub dane firmy, są częścią obszaru ryzyka i wymagają odpowiedniej oceny.

Ochrona danych i poufność. Dane osobowe, dane klientów i tajemnice przedsiębiorstwa nie mogą trafiać do systemów, nad których wykorzystaniem firma nie ma kontroli.

Dowody. Mechanizmy kontrolne liczą się tylko wtedy, gdy można je wykazać. Audytorzy szukają zapisów, a nie deklaracji.

Kilka regulacji przekłada te zasady na konkretne wymagania. W unijnym sektorze finansowym od stycznia 2025 roku stosuje się rozporządzenie DORA (Digital Operational Resilience Act) dotyczące operacyjnej odporności cyfrowej. Określa ono wymagania wobec zarządzania ryzykiem ICT, zgłaszania incydentów i zarządzania zewnętrznymi dostawcami usług ICT, a w Polsce nadzór nad jego stosowaniem sprawuje KNF. (Nie należy go mylić z metrykami DORA, służącymi do mierzenia efektywności pracy zespołów programistycznych, o których piszemy w dalszej części artykułu). Unijny akt w sprawie sztucznej inteligencji (AI Act) od lutego 2025 roku zobowiązuje organizacje korzystające z systemów AI do zapewnienia odpowiedniego poziomu kompetencji w zakresie AI wśród pracowników. RODO reguluje każde przetwarzanie danych osobowych. W technologiach medycznych wymagania dotyczące cyklu życia oprogramowania wyrobów medycznych określa norma IEC 62304, a w branży motoryzacyjnej podobną rolę pełnią m.in. ISO 26262 i Automotive SPICE.

Żadna z tych regulacji nie zakazuje tworzenia oprogramowania z pomocą AI. Wszystkie wymagają natomiast, aby proces tworzenia oprogramowania pozostawał kontrolowany i udokumentowany.

Gdzie AI można stosować przy niskim ryzyku

Nie każde zastosowanie AI wiąże się z takim samym ryzykiem. Rozsądne podejście zaczyna się tam, gdzie korzyści są duże, a wpływ na zgodność z przepisami niewielki, i stopniowo obejmuje kolejne obszary.

Im większe znaczenie regulacyjne ma dany fragment kodu, tym silniejsza musi być kontrola człowieka. Nie oznacza to, że AI jest całkowicie wykluczona z obszarów krytycznych, ale jej rola zmienia się z autora w asystenta, który na przykład objaśnia kod, proponuje testy lub wskazuje potencjalne problemy.

Jak zbudować proces z AI zgodny z wymaganiami

Proces tworzenia oprogramowania, który korzysta z AI i nadal jest gotowy na audyt, opiera się na kilku mechanizmach kontrolnych. Większość z nich rozszerza praktyki, które firmy z branż regulowanych już stosują.

1. Zatwierdzenie narzędzi i ocena dostawców. Warto korzystać wyłącznie z narzędzi AI objętych warunkami korporacyjnymi, które określają prawa do generowanych treści, wykluczają wykorzystanie danych firmy do trenowania modeli i wskazują, gdzie dane są przetwarzane. W przypadku instytucji finansowych objętych DORA takich dostawców zwykle trzeba ocenić w ramach istniejącego procesu zarządzania ryzykiem związanym z zewnętrznymi dostawcami ICT.

2. Jasne zasady dotyczące danych. Należy określić, jaki kod i jakie informacje można udostępniać narzędziom AI. Dane produkcyjne, dane klientów i dane uwierzytelniające powinny być wyłączone zarówno na poziomie polityki, jak i, tam gdzie to możliwe, za pomocą zabezpieczeń technicznych. Takie zasady dobrze wpisują się w szersze podejście do AI i zarządzania danymi.

3. Te same standardy code review. Kod powstały z pomocą AI przechodzi dokładnie ten sam proces przeglądu i zatwierdzania co kod pisany ręcznie. Zmianę zatwierdza osoba sprawdzająca, a nie narzędzie, które pomogło ją przygotować, i to ta osoba za nią odpowiada.

4. Oznaczanie zmian przygotowanych z pomocą AI. Każdą zmianę należy powiązać ze zgłoszeniem lub wymaganiem, co w regulowanych zespołach i tak jest standardem. Dodatkowo warto konsekwentnie oznaczać zmiany przygotowane z pomocą AI, na przykład etykietami w pull requestach lub ustaloną konwencją opisów commitów, aby audytorzy i osoby odpowiedzialne za wewnętrzne przeglądy widzieli, gdzie AI była wykorzystywana.

5. Egzekwowanie kontroli w pipeline’ie. Zasady są tylko tak skuteczne, jak ich egzekwowanie. Statyczna analiza kodu, skanowanie zależności i licencji, wykrywanie danych uwierzytelniających w kodzie oraz testy automatyczne powinny uruchamiać się przy każdej zmianie i blokować wydania, które nie spełniają wymagań. Dojrzałe praktyki DevOps i bezpieczeństwa chmury sprawiają, że takie kontrole stają się stałym elementem każdego wdrożenia, a nie ręcznym dodatkiem na końcu.

6. Szkolenie zespołu. Programiści powinni wiedzieć nie tylko, jak skutecznie korzystać z narzędzi AI, ale też gdzie leżą ich ograniczenia i jakie zasady obowiązują. Pomaga to jednocześnie spełnić wymogi AI Act dotyczące kompetencji w zakresie AI.

7. Mierzenie efektów. Warto śledzić wskaźniki pracy zespołu, takie jak częstotliwość wdrożeń, czas realizacji zmian i odsetek wdrożeń kończących się awarią, a obok nich wskaźniki zgodności, na przykład odsetek zmian zatwierdzonych w procesie przeglądu i liczbę ustaleń audytowych. Pomiar dowodzi, że szybsza praca zespołu nie odbywa się kosztem kontroli. Wskaźniki najlepiej analizować na poziomie zespołów, a nie poszczególnych osób, co pomaga utrzymać zaufanie w zespole.

Jakie efekty są realne: przykład z branży fintech

Firma fintech z Europy Środkowo-Wschodniej chciała szybciej wprowadzać nowe funkcje, nie rezygnując z jakości kodu ani z pełnego śladu audytowego w swoich zespołach programistycznych. Wspólnie z klientem przeanalizowaliśmy proces tworzenia oprogramowania pod kątem wdrożenia narzędzi AI w sposób zgodny z wymaganiami regulacyjnymi, zorganizowaliśmy warsztaty dotyczące kontrolowanej pracy z AI i przygotowaliśmy 30-dniowy plan działania dopasowany do etapów zatwierdzania wymaganych przez regulacje.

Efekty, szerzej opisane na naszej stronie poświęconej wykorzystaniu AI w pracy zespołów programistycznych, obejmowały:

• wzrost efektywności netto o około 10–15 procent w całym procesie tworzenia oprogramowania,
• niższy odsetek wdrożeń kończących się awarią przy zachowaniu pełnego śladu audytowego,
• zatwierdzenie w procesie compliance 100 procent zmian w kodzie przygotowanych z pomocą AI,
• lepszy wgląd w efektywność pracy wszystkich zespołów dzięki dashboardom z metrykami DORA.

Wzrost efektywności jest celowo umiarkowany. Odpowiada temu, co zwykle przynosi uporządkowane wdrożenie AI w kontrolowanym środowisku, a nie dwukrotnemu wzrostowi produktywności, który często obiecują materiały marketingowe. Dla firmy z branży regulowanej trwały, dwucyfrowy wzrost bez utraty kontroli to bardzo dobry wynik.

Najczęstsze błędy

Całkowity zakaz korzystania z AI. Zakaz rzadko powstrzymuje ludzi przed korzystaniem z tych narzędzi. Zwykle przenosi je jedynie poza jakąkolwiek kontrolę. Kontrolowane wdrożenie jest bezpieczniejsze niż zakaz, którego nikt nie egzekwuje.

Brak jakichkolwiek ograniczeń. Błąd odwrotny jest równie ryzykowny. Bez zatwierdzonych narzędzi, zasad dotyczących danych i standardów code review firma nie jest w stanie wykazać, że panuje nad procesem.

Traktowanie wyników AI jak już sprawdzonych. Nawet kod, który wygląda czysto i wiarygodnie, wymaga starannego przeglądu przez człowieka. Dobrze sformatowany kod może ukrywać subtelne błędy.

Polityki, których nikt nie egzekwuje. Zasady istniejące wyłącznie na papierze nie przekonają audytora. Mechanizmy kontrolne muszą być wbudowane w pipeline i w codzienną pracę zespołu.

Brak pomiaru. Bez punktu wyjścia i bieżących wskaźników firma nie jest w stanie ani wykazać korzyści z AI, ani udowodnić, że jakość i stabilność zostały zachowane.

Kontrola jest warunkiem szybkości

W branżach regulowanych pytanie nigdy nie brzmi po prostu, jak szybko można rozwijać oprogramowanie, lecz jak szybko można to robić, zachowując możliwość wyjaśnienia i obrony każdej decyzji. AI nie zmienia tego rachunku, ale sprawia, że dobrze zaprojektowany proces staje się jeszcze ważniejszy. Firmy, które wbudują odpowiedzialność, możliwość odtworzenia zmian i dowody w pracę z AI, mogą działać szybciej i jednocześnie pewniej.

Tę dojrzałość coraz wyraźniej dostrzegają również inwestorzy. Podczas technicznego due diligence kontrolowane i mierzalne wykorzystanie AI w pracy zespołów programistycznych jest wyraźnym sygnałem jakości inżynierskiej, a korzystanie z AI bez żadnych zasad traktowane jest jako czynnik ryzyka. Jeśli Twoja organizacja chce wprowadzić AI do pracy zespołów programistycznych bez kompromisów w zakresie zgodności z przepisami, porozmawiajmy o tym, jak nasz program wdrażania AI w pracy zespołów programistycznych może zacząć się od krótkiego, mierzalnego pilotażu.

Artykuł ma charakter wyłącznie informacyjny i nie stanowi porady prawnej ani regulacyjnej. Konkretne wymagania wobec Twojej organizacji zależą od branży, jurysdykcji i właściwego organu nadzoru.

‍