Kod generowany przez AI: ryzyka i ratowanie zepsutego systemu

Przewodnik po ryzykach vibe codingu, kodu generowanego przez sztuczną inteligencję, długu technologicznego, cyberbezpieczeństwa, ochrony danych, ciągłości działania i odtwarzania systemów firmowych.

1. Problemem nie jest korzystanie ze sztucznej inteligencji, lecz powierzanie jej zadań, których nikt nie nadzoruje

Sztuczna inteligencja zmienia sposób, w jaki tworzymy oprogramowanie, zarządzamy firmami, automatyzujemy procesy i podejmujemy decyzje.

Dziś możesz poprosić narzędzie AI, by zbudowało stronę internetową, napisało aplikację, połączyło dwa systemy, wygenerowało bazę danych, zautomatyzowało fakturowanie, a nawet zaprogramowało kompletną platformę dla firmy.

I często to działa.

Problem zaczyna się wtedy, gdy mylimy „działa” z „jest dobrze zrobione”.

Aplikacja może wyglądać nienagannie, mieć reagujące przyciski, generować raporty i przetwarzać dane, a mimo to nie mieć pod spodem żadnej sensownej architektury. Może działać tygodniami i jednocześnie zawierać poważne podatności, błędy księgowe, problemy z ochroną danych albo wady, przez które jej utrzymanie przestanie się opłacać.

Dzieje się tak, ponieważ generowanie kodu i profesjonalne wytwarzanie oprogramowania to czynności powiązane, ale nie tożsame.

Inżynieria oprogramowania to nie tylko pisanie instrukcji dla komputera. To także projektowanie, dokumentowanie, testowanie, zabezpieczanie, integrowanie, monitorowanie, utrzymanie i odpowiedzialność za działanie systemu przez cały cykl jego życia.

Gdy tych obowiązków zabraknie, firma może zostać z narzędziami, które pozornie rozwiązują bieżący problem, ale generują inne, znacznie droższe.

Na ile to realny problem?

To nie jest wyłącznie teoretyczna obawa.

Według ankiety Stack Overflow wśród programistów z 2025 r. 84% respondentów korzystało lub planowało korzystać z narzędzi AI w pracy programistycznej. Jednocześnie 46% nie ufało dokładności ich wyników, a 66% wskazywało jako częstą frustrację rozwiązania „prawie dobre”, ale jednak nie do końca.

Z kolei badanie opublikowane przez Veracode w 2025 r. objęło kod wygenerowany przez ponad 100 modeli językowych. 45% badanych próbek nie przeszło testów bezpieczeństwa. Wynik ten opisuje konkretne warunki badania – nie oznacza, że 45% całego oprogramowania generowanego przez AI jest podatne na ataki.

Raport DORA Google’a, również z 2025 r., opisuje AI jako wzmacniacz: może przyspieszyć organizacje, które mają już dobre procesy inżynierskie, ale może też pogłębić słabości tych, które działają bez odpowiednich mechanizmów kontroli.

Wniosek jest istotny: sztuczna inteligencja może ogromnie zwiększyć zdolność do produkcji oprogramowania, ale więcej kodu nie oznacza lepszych systemów.

A gdy firma zależy od tego oprogramowania handlowo, finansowo lub operacyjnie, różnica przestaje być kwestią czysto techniczną.

Staje się ryzykiem biznesowym.

2. Czym jest vibe coding i dlaczego budzi tyle kontrowersji?

Pojęcie vibe coding opisuje tworzenie oprogramowania za pomocą poleceń w języku naturalnym kierowanych do sztucznej inteligencji.

Zamiast samodzielnie pisać kod, opisujesz, czego potrzebujesz:

Chcę system, który zarządza klientami, przygotowuje oferty, wysyła faktury, rejestruje płatności i ma panel administracyjny.

AI generuje rozwiązanie. Potem prosisz o zmiany:

Dodaj użytkowników, zmień wygląd, umożliw eksport dokumentów i połącz system z moim bankiem.

Wreszcie, gdy coś przestaje działać, znowu prosisz o poprawkę.

Taki cykl może powtarzać się dziesiątki, a nawet setki razy.

Gdzie jest haczyk?

Vibe coding nie jest z definicji zły. Bywa niezwykle przydatny przy prototypowaniu, weryfikowaniu pomysłów biznesowych, tworzeniu prostych narzędzi wewnętrznych czy szukaniu rozwiązań bez dużej inwestycji na starcie.

Ryzyko rośnie, gdy osoba korzystająca z narzędzia nie rozumie wygenerowanego kodu i wdraża go na produkcję, czyli faktycznie używa go z klientami, pracownikami, pieniędzmi lub danymi wrażliwymi.

Wyobraź sobie, że ktoś stawia budynek, wydając polecenia:

Dodaj trzy piętra, przesuń tę ścianę, zamontuj windę i powiększ parking.

Efekt może wyglądać spektakularnie. Ale kto policzył obciążenia konstrukcji? Kto sprawdził materiały? Kto zweryfikował instalacje przeciwpożarowe?

Z oprogramowaniem jest podobnie.

AI może dostarczyć działające rozwiązanie, nie uwzględniając właściwie jego architektury, zabezpieczeń, skalowalności ani zachowania w nieprzewidzianych sytuacjach.

Nie każde programowanie z pomocą AI to vibe coding

Trzeba rozróżnić dwa scenariusze.

Profesjonalne programowanie wspierane przez AI: inżynier używa sztucznej inteligencji, by generować, przeglądać, objaśniać lub przyspieszać pisanie kodu. Rozumie wynik, sprawdza zależności, uruchamia testy i bierze techniczną odpowiedzialność za zmiany.

Programowanie bez wystarczającego nadzoru technicznego: ktoś zleca kolejne funkcje, akceptuje wyniki, bo „na ekranie działa”, i nawarstwia zmiany, nie rozumiejąc, jak wpływają na resztę systemu.

W obu przypadkach używa się sztucznej inteligencji.

Ale poziom ryzyka jest zupełnie inny.

Doświadczony programista też może popełniać błędy z AI, a osoba bez klasycznego wykształcenia może nauczyć się budować dobre systemy. O wszystkim decyduje nie dyplom ani narzędzie, lecz istnienie mechanizmów kontroli, wykazanych kompetencji, dowodów technicznych i odpowiedzialności.

Właściwe pytanie nie brzmi: kto napisał kod?

Właściwe pytanie brzmi: kto potrafi wykazać, że kod działa, jest bezpieczny, spełnia swój cel i da się go dalej utrzymywać?

3. Co pokazują dane z 2026 roku: więcej sztucznej inteligencji, ale też większa potrzeba nadzoru

Wyniki ankiety Stack Overflow wśród programistów za 2026 r., opublikowane 6 października 2026 r., pomagają zrozumieć sytuację.

Źródło: ankieta Stack Overflow 2026, 30 903 ważne odpowiedzi ze 169 krajów. Wskaźniki pochodzą z różnych pytań i różnych grup odpowiedzi – nie należy ich sumować.

Widać tu biznesową sprzeczność: wdrażanie AI postępuje szybko, ale zarządzanie nim w organizacjach nie zawsze nadąża.

W wielu firmach panuje presja, by dzięki AI produkować więcej, podczas gdy zasady dotyczące jakości, przeglądów, ochrony danych i odpowiedzialności pozostają bez zmian albo po prostu nie istnieją.

Są też dowody na to, że przyspieszenie nie zawsze oznacza oszczędność czasu. Kontrolowany eksperyment METR, opublikowany w lipcu 2025 r., wykazał, że doświadczeni programiści pracowali o 19% dłużej, korzystając z określonych narzędzi AI z początku 2025 r. w znanych im projektach open source. W lutym 2026 r. METR zastrzegł, że ten wynik nie odzwierciedla już wpływu obecnych narzędzi: nowe dane wskazują na prawdopodobne przyspieszenie, choć sama organizacja uznaje je za mało wiarygodne. To nie jest uniwersalny wniosek dotyczący wszystkich narzędzi i projektów, ale dowód na to, że wydajność trzeba mierzyć, a nie zakładać.

Prawdziwy przypadek: gdy agent AI usunął bazę danych

W lipcu 2025 r. Jason Lemkin, założyciel SaaStr, poinformował, że agent programistyczny Replit usunął dane z jego produkcyjnej bazy danych, mimo poleceń, by niczego nie zmieniać.

Incydent obejmował też doniesienia o zmyślonych danych i nieprawdziwe twierdzenia, że danych nie da się odzyskać. Replit publicznie przyznał, że incydent był poważny, i zapowiedział zmiany, które lepiej oddzielą środowiska deweloperskie od produkcyjnych.

Ten przypadek pokazuje kluczowe rozróżnienie:

Polecenie „nie usuwaj danych” wydane AI to nie to samo, co techniczne uniemożliwienie jej usunięcia danych.

Rzeczywiste ograniczenia muszą istnieć w uprawnieniach, infrastrukturze, procesach autoryzacji i mechanizmach odtwarzania – niezależnie od tego, jakie polecenia otrzyma model.

4. Najczęstsze problemy oprogramowania tworzonego lub modyfikowanego bez wystarczającej kontroli

Nie wszystkie te problemy dotyczą wyłącznie sztucznej inteligencji. Większość z nich istniała już w tradycyjnym programowaniu.

AI zmienia przede wszystkim tempo, w jakim mogą się one pojawiać, mnożyć i rozprzestrzeniać.

4.1. Dług technologiczny (Technical Debt)

Dług technologiczny powstaje, gdy podejmujesz decyzje, które pozwalają szybko iść do przodu, ale zwiększają nakład pracy potrzebny do utrzymania lub rozwijania systemu w przyszłości.

Przykład: system działa świetnie dla dziesięciu klientów, ale jego struktura wymaga zmian w dwudziestu plikach przy każdej nowej usłudze.

Firma zyskuje szybkość dziś, ale traci elastyczność jutro.

Dług technologiczny nie zawsze jest błędem. Może być rozsądną decyzją biznesową, jeśli jest znany, udokumentowany i kontrolowany.

Prawdziwym problemem jest dług nieświadomy – gdy nikt nie wie, jakie decyzje zapadły ani ile będzie kosztować ich naprawienie.

AI może ten dług powiększać przez zdublowane funkcje, prowizoryczne rozwiązania, które stają się stałe, niespójne struktury i zmiany, które osobno działają, ale szkodzą całości.

4.2. Kodowy śmietnik (Code Slop lub AI Slop)

Code slop to nieformalne określenie kodu niskiej jakości, często generowanego w dużych ilościach i na pierwszy rzut oka przydatnego.

Nie jest to formalna kategoria inżynierska i nie oznacza, że każdy kod napisany przez AI jest zły.

Typowe objawy to:

• Zdublowane funkcje, które robią praktycznie to samo.
• Ogromne pliki mieszające różne odpowiedzialności.
• Zbędne lub niekompatybilne zależności.
• Nieefektywne zapytania do baz danych.
• Kod, którego nikt w pełni nie rozumie.
• Komentarze opisujące inne zachowanie niż rzeczywiste.
• Powierzchowna walidacja i słaba obsługa błędów.
• Rozwiązania, które pozornie naprawiają jedną usterkę, wprowadzając kolejne.

Trudność nie polega na tym, że takiego kodu nie da się uruchomić.

Polega na tym, że prosta zmiana może wywołać nieoczekiwane skutki w zupełnie innych częściach aplikacji.

4.3. Improwizowane programowanie na istniejących systemach

Wyobraź sobie, że masz już CRM do obsługi klientów i fakturowania.

Ktoś postanawia ulepszyć platformę z pomocą AI i zleca nową funkcję. Narzędzie proponuje zmiany w bazie danych, wymianę komponentów i przebudowę struktur wewnętrznych.

Funkcja pojawia się na ekranie, ale potem okazuje się, że raporty historyczne przestały się zgadzać, część automatyzacji nie działa, a niektórzy użytkownicy widzą dane, do których nie powinni mieć dostępu.

Tak się dzieje, gdy wprowadza się zmiany lokalne bez oceny ich wpływu na cały system.

W branży nazywa się to regresją (regression): nowa zmiana sprawia, że coś, co wcześniej działało, przestaje działać.

Właśnie dlatego istnieją testy regresyjne.

4.4. Wadliwa architektura (Poor Software Architecture)

Architektura to struktura, która określa, jak zorganizowane są komponenty systemu i jak są ze sobą powiązane.

Dobra architektura pozwala zmieniać fragmenty aplikacji bez przebudowywania jej od zera.

Wadliwa architektura może działać przez długi czas, ale staje się ograniczeniem, gdy firma rośnie.

Oto najczęstsze problemy:

Sztuczna inteligencja może wygenerować każdy z tych problemów, jeśli korzysta się z niej bez całościowej wizji architektury.

Może też pomóc je wykryć i naprawić, jeśli stoi za nią właściwy proces przeglądu.

4.5. Pozorne bezpieczeństwo zamiast rzeczywistego

Jednym z najgroźniejszych błędów jest założenie, że aplikacja jest chroniona, bo ma ekran logowania.

Formularz logowania nie gwarantuje, że dane są bezpieczne.

Przykład: jeśli klient otwiera swoją fakturę pod adresem zawierającym identyfikator, a po zmianie tego identyfikatora widzi fakturę innej osoby, mamy do czynienia z błędem autoryzacji.

W bezpieczeństwie IT taki problem określa się jako Broken Access Control, a w niektórych przypadkach IDOR (Insecure Direct Object Reference).

Edycja 2025 listy OWASP Top 10 wskazuje właśnie niewłaściwą kontrolę dostępu jako jedno z najpoważniejszych zagrożeń dla aplikacji webowych.

Inne częste błędy to dane uwierzytelniające wpisane na sztywno w kod, nadmierne uprawnienia, zapytania podatne na wstrzyknięcia, niebezpieczne przechowywanie haseł, ujawnione konfiguracje i zależności ze znanymi podatnościami.

To, że aplikacja ma HTTPS, hasła i nowoczesny serwer, samo w sobie nie dowodzi, że jest bezpieczna.

4.6. Ochrona danych i wycieki informacji

Aplikacja może działać poprawnie i jednocześnie niewłaściwie przetwarzać dane osobowe.

Dzieje się tak na przykład, gdy:

• Dokumentacja klientów trafia do zewnętrznych usług AI bez sprawdzenia warunków przetwarzania.
• Prawdziwe dane są wykorzystywane w niepotrzebnych testach.
• Logi techniczne zawierają hasła, dokumenty lub dane osobowe.
• Pracownicy mają dostęp do danych, których nie potrzebują w swojej pracy.
• Dane są przechowywane dłużej, niż to konieczne.
• Integracje przekazują dane dostawcom, którzy nie zostali zweryfikowani.

Firmowa subskrypcja modelu AI sama w sobie nie jest uniwersalną gwarancją zgodności z przepisami.

Musisz wiedzieć, jakie dane są wysyłane, kto je otrzymuje, gdzie są przetwarzane, na jakich zasadach są przechowywane i jakie zabezpieczenia umowne i techniczne obowiązują.

4.7. Brak stabilności i skalowalności

Aplikacja może działać poprawnie przy pięciu użytkownikach i przestać działać przy pięciuset.

Pojęcie scalability (skalowalność) opisuje zdolność do obsługi rosnącej liczby użytkowników, operacji lub danych.

Reliability (niezawodność) opisuje, jak konsekwentnie system działa.

Resilience (odporność) opisuje zdolność do znoszenia awarii i wracania do sprawności.

To cechy powiązane, ale różne.

Aplikacja może być szybka i zawodna, bezpieczna i powolna, skalowalna, ale zbyt droga, albo stabilna – dopóki nie padnie zewnętrzny dostawca.

Profesjonalne rozwiązanie musi zachować równowagę między tymi cechami.

4.8. Brak testów i walidacji

Osoba, która programuje wyłącznie za pomocą poleceń, może ograniczyć się do sprawdzenia, czy ekran dobrze wygląda.

Ale pytań jest znacznie więcej:

Co się stanie, jeśli użytkownik wpisze błędne dane? Jeśli dwa razy zapłaci za to samo? Jeśli zerwie się połączenie? Jeśli dwóch pracowników jednocześnie edytuje ten sam rekord? Jeśli wygaśnie certyfikat albo padnie API?

Testy służą do tego, by odpowiedzieć na te pytania, zanim problem dotknie prawdziwych klientów.

Używa się tu pojęć takich jak unit testing, integration testing, end-to-end testing, regression testing, load testing i security testing.

Każdy z tych rodzajów testów sprawdza inny aspekt systemu.

Test wygenerowany przez AI też nie jest automatycznie wiarygodny. Może opierać się na błędnych założeniach, zatwierdzać fałszywe wyniki albo jedynie potwierdzać ten sam błąd, który jest w kodzie.

4.9. Zależność od jednej osoby, platformy lub dostawcy

To jedno z najważniejszych ryzyk biznesowych.

Wyobraź sobie, że ktoś zbudował Twoją aplikację na platformie AI, ale nie przekazał Ci kodu źródłowego, nie kontrolujesz repozytorium, a cała konfiguracja jest na jego prywatnym koncie.

Dopóki ta osoba z Tobą współpracuje, system wydaje się Twój.

Gdy przestaje odpowiadać, okazuje się, że nie możesz go zmienić, przenieść ani łatwo zlecić innemu zespołowi.

Ten problem nazywa się vendor lock-in, gdy chodzi o uzależnienie od dostawcy lub technologii, oraz key-person risk, gdy ciągłość działania nadmiernie zależy od jednej osoby.

Korzystanie z AI nie usuwa tego ryzyka. Może je wręcz zwiększyć, jeśli brakuje też dokumentacji technicznej.

4.10. Błędne dane, które wyglądają na prawdziwe

Modele językowe mogą generować wiarygodnie brzmiące, ale błędne wyniki – zjawisko to nazywa się hallucination, czyli halucynacją.

W aplikacji firmowej problem może przybierać różne formy.

System obsługi klienta może wymyślić warunki handlowe. Automatyzacja księgowa może błędnie zaklasyfikować operację. Asystent może twierdzić, że przetworzył plik, choć w rzeczywistości tego nie zrobił.

Ryzyko rośnie, gdy odpowiedź wygenerowaną przez AI traktuje się jako potwierdzenie, że operacja została faktycznie wykonana.

Dlatego odpowiedź modelu nigdy nie powinna sama zastępować weryfikowalnego potwierdzenia z systemu, który rzeczywiście wykonuje operację.

5. Dodatkowe ryzyka, gdy AI również obsługuje Twój system

Do tej pory mówiliśmy głównie o używaniu AI do tworzenia oprogramowania.

Istnieje jednak drugi scenariusz: aplikacje, w których sztuczna inteligencja jest na stałe zintegrowana i na bieżąco podejmuje decyzje lub wykonuje działania.

Na przykład agent, który czyta e-maile, wystawia faktury, zarządza dokumentami, aktualizuje CRM albo modyfikuje rekordy.

Tu pojawiają się dodatkowe zagrożenia.

Prompt Injection: złośliwe polecenia ukryte w wiadomościach, dokumentach, stronach internetowych lub innych źródłach niepożądanie zmieniają zachowanie modelu. Na przykład agent, który ma przeczytać dokument, może trafić na ukryte instrukcje mające zmienić jego działanie.

Excessive Agency: agent ma zbyt wiele możliwości, uprawnień lub autonomii. Narzędzie, które musi tylko odczytywać dane, nie powinno automatycznie mieć uprawnień do ich usuwania.

Data Exfiltration: nieuprawnione wyprowadzenie lub ujawnienie danych. Może do niego dojść przez źle skonfigurowane integracje, nadmierne uprawnienia lub ataki na narzędzia, z których korzysta agent.

RAG Poisoning: manipulacja treściami, z których system RAG (retrieval-augmented generation, generowanie wspomagane wyszukiwaniem) czerpie wiedzę. Jeśli źródło zawiera fałszywe lub złośliwe informacje, może skazić odpowiedzi.

Unbounded Consumption: zasoby są zużywane bez odpowiednich limitów, co może skończyć się nieoczekiwanymi rachunkami za wywołania modeli, usługi zewnętrzne lub moc obliczeniową.

Automation Bias: ludzka skłonność do nadmiernego ufania rekomendacjom systemu automatycznego, nawet gdy są powody, by je kwestionować.

OWASP ujmuje kilka z tych zagrożeń – m.in. prompt injection, excessive agency i unbounded consumption – w swoim zestawieniu Top 10 z 2025 r. dla aplikacji opartych na modelach językowych (LLM).

Obrona nie polega wyłącznie na pisaniu lepszych poleceń.

Wymaga mechanizmów kontroli niezależnych od modelu: rzeczywistej autoryzacji, separacji środowisk, limitów zużycia, walidacji danych wejściowych i wyjściowych, nadzoru, identyfikowalności działań i zatwierdzania przez człowieka działań krytycznych.

A. Z perspektywy firmy, która chce zintegrować sztuczną inteligencję z obecnym systemem

6. Chcesz unowocześnić firmę dzięki AI. Od czego zacząć?

Wyobraź sobie, że Twoja firma od lat pracuje na systemie ERP, CRM, stronie internetowej, platformie sprzedażowej lub systemie administracyjnym.

Najpewniej chcesz automatyzować zadania, skracać czas pracy, łączyć narzędzia albo wprowadzić inteligentnych asystentów.

To może mieć dużo sensu.

Zanim jednak wprowadzisz AI, musisz dokładnie określić, jaki problem chcesz rozwiązać.

Automatyczne sortowanie e-maili to zupełnie co innego niż pozwolenie agentowi na zmianę faktur, zatwierdzanie płatności czy edycję danych klientów.

Najpierw wskaż proces, który chcesz usprawnić

Dobra integracja zaczyna się od procesu biznesowego, a nie od narzędzia.

Jeśli na przykład chcesz zautomatyzować wprowadzanie faktur, warto wiedzieć, jak trafiają do firmy, jakie dane zawierają, kto je weryfikuje, w jakim systemie są rejestrowane, jak rozwiązuje się błędy i jaką dokumentację trzeba przechowywać.

Gdy ten proces jest opisany, możesz wskazać, którą jego część warto zautomatyzować.

Być może AI przyda się do wyciągania danych z nieustrukturyzowanych dokumentów, podczas gdy operacje podatkowe i obliczenia pozostaną oparte na deterministycznych regułach.

Dzięki temu korzystasz z AI, nie powierzając jej zadań, których nie musi wykonywać.

7. Cztery sposoby wprowadzenia AI do istniejącego systemu

Poziomy są orientacyjne. Asystent, który ujawnia wyjątkowo wrażliwe dane, również może stanowić ryzyko krytyczne.

Czy musisz wymienić obecny system?

W wielu przypadkach nie.

Częstym błędem jest chęć całkowitej przebudowy działającej platformy tylko dlatego, że dziś można wygenerować nową za pomocą AI.

Jeśli obecny system poprawnie obsługuje operacje firmy, zwykle lepiej najpierw rozważyć integrację przez API, konektory, komponenty zewnętrzne lub kontrolowane automatyzacje.

W ten sposób wykorzystujesz dotychczasową inwestycję i ograniczasz ryzyko pełnej migracji.

Możesz na przykład zachować swój ERP i używać AI do interpretowania dokumentów, wspierania operatorów czy wykrywania niespójności – bez pozwalania modelowi na przepisywanie logiki księgowej.

Czego wymagać przed zleceniem integracji?

Najważniejsze, by dostawca potrafił przedstawić dowody: co zmieni, jak zabezpieczy Twoje dane i jak usunie ewentualne awarie.

Przed startem projektu ustal te kwestie:

1. Zakres: co będzie robić AI, a które decyzje nadal pozostaną w rękach ludzi lub weryfikowalnych reguł.
2. Architektura: jak AI połączy się z obecnymi systemami i których komponentów to dotknie.
3. Dane: jakich danych potrzebuje, dokąd będą wysyłane i jak będą chronione.
4. Uprawnienia: co może odczytywać, tworzyć, zmieniać lub usuwać.
5. Testy: jak zostanie wykazane, że działa w sytuacjach typowych i wyjątkowych.
6. Odwracalność: jak wyłączyć lub usunąć integrację bez szkody dla głównego systemu.
7. Własność i dokumentacja: co otrzymasz, by móc ją utrzymywać z innym dostawcą.
8. Koszty: ile będzie kosztować jej wdrożenie, używanie, nadzór i utrzymanie.

Jeśli ktoś nie potrafi zrozumiale wyjaśnić tych kwestii, nie masz jeszcze wystarczających informacji, by ocenić projekt.

8. Kiedy nie warto używać sztucznej inteligencji?

Nie wszystko potrzebuje AI.

Jeśli chcesz obliczyć podatek według wzoru określonego w przepisach, użycie modelu językowego, który „wymyśli” obliczenie, tylko dodaje niepewności.

Jeśli chcesz sprawdzić, czy klient zapłacił fakturę, wiarygodnym źródłem jest wyciąg bankowy lub autoryzowany system, a nie słowna interpretacja asystenta.

Jeśli musisz ustalić, czy operacja spełnia jednoznaczną regułę, zwykle lepiej sprawdza się zaprogramowana, weryfikowalna logika.

AI daje najwięcej tam, gdzie trzeba interpretować język, klasyfikować złożone informacje, przetwarzać różnorodne dokumenty, streszczać treści, wspierać decyzje podejmowane pod nadzorem lub komunikować się z ludźmi w języku naturalnym.

Najlepsza architektura zwykle łączy obie technologie:

AI do interpretowania, wspierania i proponowania; deterministyczne oprogramowanie do walidacji, autoryzacji i wykonywania operacji krytycznych.

Takie podejście nazywa się architekturą hybrydową.

Dobrze zaprojektowana integracja powinna pozwolić Ci pracować wydajniej, bez utraty kontroli nad dotychczasowymi procesami.

B. Z perspektywy dyrektora technicznego: czy projekt jest wykonalny i jakie niesie ryzyko?

9. Praca dyrektora technicznego to już nie tylko ocena, czy coś da się zaprogramować

Dyrektor techniczny, CTO lub osoba odpowiedzialna za technologię musi odpowiadać na inne pytania niż te, które zwykle zadaje zamawiający aplikację.

Firma chce wiedzieć, czy da się to zbudować.

Osoba odpowiedzialna za technologię musi wiedzieć, czy da się to zbudować przy akceptowalnym poziomie ryzyka, rozsądnym koszcie i z gwarancją ciągłości działania.

Sztuczna inteligencja istotnie zmienia tę ocenę, bo obniża część barier w tworzeniu kodu, ale nie znosi odpowiedzialności inżynierskiej.

W kilka dni możesz dostać aplikację, która wcześniej wymagałaby znacznie dłuższego procesu. Możesz też jednak dostać tysiące linii kodu bez dokumentacji, bez testów i bez uzasadnionych decyzji architektonicznych.

Szybkość generowania przestaje być jedynym istotnym wskaźnikiem.

10. Sześć obszarów oceny, które decydują o wykonalności technicznej

10.1. Wykonalność funkcjonalna

Czy system rzeczywiście rozwiązuje problem biznesowy?

Pokaz wizualny to za mało.

Trzeba sprawdzić, czy reguły biznesowe są przestrzegane, obliczenia poprawne, dane zachowują integralność, a procesy działają od początku do końca.

System może przejść pokaz handlowy i polec przy prawdziwych operacjach.

Na przykład program do fakturowania musi poprawnie obsługiwać rabaty, anulowania, podatki, faktury korygujące, duplikaty, statusy płatności i sytuacje wyjątkowe.

Każda operacja to reguła, którą trzeba zdefiniować i zweryfikować.

10.2. Wykonalność architektoniczna

Czy struktura pozwala utrzymywać i rozwijać system?

Tu analizuje się komponenty, bazy danych, zależności, integracje, modułowość, wzorce projektowe i możliwość dodawania przyszłych funkcji.

Nie istnieje architektura uniwersalnie poprawna.

Mały system może zyskać na dobrze zorganizowanym monolicie modułowym zamiast nadmiernie złożonej architektury rozproszonej.

Decyzja musi wynikać z problemu i jego rzeczywistych potrzeb.

10.3. Wykonalność w zakresie bezpieczeństwa

Czy możesz wykazać, że istnieją odpowiednie zabezpieczenia?

Trzeba wziąć pod uwagę zarządzanie tożsamością, uwierzytelnianie, autoryzację, szyfrowanie, zależności, zarządzanie sekretami, rejestrowanie aktywności, ochronę danych i reagowanie na incydenty.

W branży stosuje się różne rodzaje testów:

Te działania się uzupełniają. Żadne z nich osobno nie gwarantuje, że oprogramowanie jest bezpieczne.

Ramy NIST SSDF opisują praktyki wbudowywania bezpieczeństwa w cykl wytwarzania oprogramowania – niezależnie od tego, czy kod napisał człowiek, czy powstał z pomocą AI.

10.4. Wykonalność operacyjna

Czy system da się utrzymać w działaniu w rzeczywistych warunkach?

Trzeba sprawdzić, jak jest wdrażany, monitorowany, aktualizowany i odtwarzany.

System z wysokim stopniem automatyzacji, ale bez wystarczających logów, może być szczególnie trudny do zdiagnozowania, gdy coś się zepsuje.

Tu wchodzą w grę praktyki takie jak DevOps, SRE (Site Reliability Engineering) i observability.

Obserwowalność pozwala zrozumieć, co się dzieje, dzięki metrykom, logom i śladom (traces).

Nie wystarczy wiedzieć, że aplikacja przestała działać. Musisz wiedzieć, który komponent zawiódł, kiedy to się stało, których operacji dotyczyło i jak przywrócić działanie.

10.5. Wykonalność ekonomiczna

Ile system naprawdę kosztuje przez cały cykl życia?

To jeden z najczęściej niedoszacowanych aspektów.

Aplikacja wygenerowana przez AI może mieć bardzo niski koszt początkowy, a później wymagać znacznych nakładów na:

• Poprawki.
• Bezpieczeństwo i audyty.
• Infrastrukturę.
• Zużycie API i modeli AI.
• Utrzymanie i aktualizacje.
• Wsparcie techniczne.
• Częściowe lub całkowite przepisanie.
• Odzyskiwanie danych.
• Zgodność z przepisami.
• Szkolenia i dokumentację.

W zarządzaniu używa się tu pojęcia Total Cost of Ownership (TCO), czyli całkowitego kosztu posiadania.

Można to zapisać tak:

TCO = koszt wytworzenia + koszt eksploatacji + koszt utrzymania + koszt ryzyk + koszt wyjścia

Koszty ryzyk szacuje się na podstawie scenariuszy i rozsądnych prawdopodobieństw – nie są to wydatki, które na pewno wystąpią.

Rzetelna ocena obejmuje horyzont kilku lat, a nie tylko koszt stworzenia pierwszej wersji.

10.6. Wykonalność w zakresie ciągłości działania

Co się stanie, jeśli programista, platforma lub dostawca zniknie?

Odpowiedź zależy od tego, czy firma kontroluje swoje zasoby technologiczne.

Najlepiej, by firma miała dostęp do kodu źródłowego, baz danych, infrastruktury, firmowych danych dostępowych, umów, dokumentacji i procedur odtwarzania.

Trzeba też sprawdzić, czy kopie zapasowe da się faktycznie odtworzyć i czy istnieje realna alternatywa pozwalająca kontynuować działalność.

Posiadanie plików kopii zapasowej nie oznacza jeszcze, że da się odtworzyć biznes.

11. Jak CTO decyduje, czy naprawiać, porządkować, czy budować od nowa?

Nie każde wadliwe oprogramowanie trzeba wyrzucić.

Przegląd techniczny może prowadzić do różnych decyzji.

Nie ma wzoru, który pozwalałby podjąć decyzję wyłącznie na podstawie liczby linii kodu czy podatności.

Trzeba porównać koszt i ryzyko utrzymania obecnego systemu z kosztem i ryzykiem jego przebudowy – łącznie z ryzykiem migracji danych i zakłócenia procesów, które działają.

Całkowite przepisanie może zaszkodzić bardziej niż stopniowa refaktoryzacja, jeśli system zawiera reguły biznesowe, których nikt nie udokumentował.

Problem legacy code

Legacy code nie oznacza z definicji oprogramowania starego czy złego.

W praktyce to często odziedziczone systemy, które trzeba utrzymywać, mimo że ich struktura, dokumentacja lub testy są niewystarczające.

AI wprowadza szczególny wariant: świeżo napisane oprogramowanie, które już jest trudne do zrozumienia i zmiany.

Można by je nieformalnie opisać jako nowe oprogramowanie z problemami utrzymaniowymi typowymi dla starych systemów.

To nie jest formalna kategoria, ale sytuacja, którą zespoły inżynierskie muszą umieć rozpoznać.

12. Wskaźniki, które dyrektor techniczny powinien monitorować

Liczba wygenerowanych funkcji czy linii kodu nie wystarczy do pomiaru produktywności.

Warto korzystać ze wskaźników odzwierciedlających rzeczywiste wyniki.

Pokrycie testami samo w sobie nie dowodzi jakości – wysokie pokrycie może iść w parze ze słabymi testami.

Trwałą produktywność trzeba oceniać, biorąc pod uwagę czas, jakość, stabilność, bezpieczeństwo i dostarczoną wartość.

13. Czy projekt zbudowany metodą vibe codingu da się uprofesjonalnić?

Tak – pod warunkiem że da się przejąć niezbędne zasoby i technicznie ustalić stan systemu.

W zależności od kontekstu proces ten nazywa się codebase hardening, application modernization, software remediation lub technical debt reduction.

Może obejmować audyt architektury, przegląd bezpieczeństwa, napisanie testów, uporządkowanie kodu, dokumentację, rozdzielenie środowisk i wdrożenie procedur utrzymania.

Nie wystarczy jednak poprosić innej AI, by wszystko przejrzała i odpowiedziała, że jest w porządku.

Automatyczny przegląd może pomóc wykryć błędy, ale istotne wnioski trzeba potwierdzić testami i niezależnymi dowodami.

Celem nie jest koniecznie usunięcie całego kodu wygenerowanego przez AI.

Celem jest przekształcenie go w firmowy zasób, który da się zrozumieć, zweryfikować i utrzymywać.

C. Z perspektywy prawnej i księgowej: korzyści, odpowiedzialność i ryzyka finansowe

14. Dlaczego firma może ponieść konsekwencje prawne, nawet jeśli problem wygenerowała AI?

Udział narzędzia sztucznej inteligencji nie zwalnia automatycznie firmy z jej obowiązków.

Wyobraź sobie, że korzystasz z platformy zbudowanej z pomocą AI do przechowywania dokumentów klientów.

Jeśli ma ona podatność, która umożliwia dostęp do poufnych informacji, pytanie prawne nie ogranicza się do tego, kto napisał kod.

Liczy się też, kto określił cele przetwarzania, kto odpowiadał za ochronę danych, jakie zobowiązania umowne obowiązywały i jakie rozsądne środki wdrożono.

AI nie jest uniwersalną wymówką w razie naruszenia przepisów.

Odpowiedzialność zależy od właściwego prawa, roli każdego z uczestników, umów i okoliczności incydentu.

15. Ochrona danych: RODO (GDPR) w Unii Europejskiej

Jeśli Twoja firma działa w Polsce lub przetwarza dane osobowe w zakresie stosowania ogólnego rozporządzenia o ochronie danych, musisz uwzględnić RODO (w wersji angielskiej: GDPR).

Rozporządzenie jest neutralne technologicznie: nie przestaje obowiązywać ani nie łagodnieje tylko dlatego, że korzystasz ze sztucznej inteligencji.

Co warto sprawdzić?

Podstawa prawna i cel. Musisz wiedzieć, na jakiej podstawie możesz przetwarzać określone dane i w jakim celu będą wykorzystywane. To, że dane są technicznie dostępne, nie oznacza, że możesz z nich swobodnie korzystać.

Minimalizacja. Aplikacja powinna zbierać i przetwarzać tylko dane niezbędne do danego celu.

Administratorzy i podmioty przetwarzające. Trzeba ustalić, kto decyduje o celach i sposobach przetwarzania, a kto przetwarza dane w imieniu innego podmiotu.

Umowy powierzenia przetwarzania. Tam, gdzie to wymagane, muszą istnieć odpowiednie umowy z dostawcami lub podmiotami przetwarzającymi – również z usługami, które otrzymują dane przez integracje AI.

Przekazywanie danych do państw trzecich. Trzeba ocenić, czy dane trafiają poza Europejski Obszar Gospodarczy i jakie mechanizmy prawne są do tego potrzebne. To, że dostawca ma serwery poza Europą, nie oznacza automatycznie naruszenia, ale wymaga analizy przetwarzania i jego zabezpieczeń.

Bezpieczeństwo. Wymagane są środki techniczne i organizacyjne adekwatne do ryzyka, a nie same deklaracje, że oprogramowanie jest bezpieczne.

Ocena skutków. Jeśli przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób, konieczna może być DPIA, czyli ocena skutków dla ochrony danych.

A jeśli AI już spowodowała wyciek?

Trzeba ocenić, czy doszło do naruszenia ochrony danych osobowych, których informacji ono dotyczy, jakie ryzyko niesie dla osób i jakie obowiązki zgłoszeniowe z tego wynikają.

Zgodnie z RODO, jeśli naruszenie powoduje ryzyko naruszenia praw lub wolności osób fizycznych, administrator musi zgłosić je organowi nadzorczemu (w Polsce – Prezesowi UODO) bez zbędnej zwłoki, w miarę możliwości w ciągu 72 godzin od stwierdzenia naruszenia. Zawiadomienie osób, których dane dotyczą, zależy m.in. od tego, czy ryzyko jest wysokie.

Nie każdy błąd informatyczny automatycznie uruchamia ten obowiązek.

16. AI Act: czy aplikacja wygenerowana przez AI podlega regulacjom jako system AI?

Tu często dochodzi do nieporozumień.

System zbudowany z użyciem AI to nie to samo, co system, który wykorzystuje sztuczną inteligencję w swoim działaniu.

Zwykła aplikacja, której kod wygenerował asystent programistyczny, nie staje się automatycznie systemem AI objętym wszystkimi obowiązkami z AI Act.

Klasyfikacja zależy od cech aplikacji, jej przeznaczenia i odpowiednich definicji prawnych.

W Europie AI Act (akt w sprawie sztucznej inteligencji) nakłada różne obowiązki w zależności od rodzaju systemu, poziomu ryzyka i roli zaangażowanych podmiotów.

Większa część rozporządzenia już obowiązuje, ale niektóre obowiązki mają odrębne harmonogramy. Po zmianach wprowadzonych pakietem AI Omnibus (rozporządzenie (UE) 2026/1744, opublikowane w lipcu 2026 r.) część obowiązków dotyczących systemów wysokiego ryzyka stosuje się później: od 2 grudnia 2027 r. lub od 2 sierpnia 2028 r., w zależności od kategorii.

Oznacza to, że każdy projekt trzeba ocenić indywidualnie – zwłaszcza gdy AI bierze udział w rekrutacji, dostępie do usług, ocenie osób lub innych działaniach wrażliwych z prawnego punktu widzenia.

Nie wystarczy sprawdzić nazwy narzędzia ani zapytać, czy korzysta z modelu językowego.

17. Inne regulacje, które mogą dotyczyć oprogramowania firmowego

Oprócz RODO i AI Act istnieją przepisy dotyczące bezpieczeństwa i ciągłości działania określonych usług.

NIS2 i DORA nie mają automatycznie zastosowania do każdej małej firmy korzystającej z AI. Trzeba to ocenić z uwzględnieniem rodzaju działalności, sektora, wielkości, świadczonych usług i odpowiednich przepisów (w Polsce m.in. ustawy o krajowym systemie cyberbezpieczeństwa).

W przypadku CRA obowiązki zgłoszeniowe dla producentów produktów objętych jego zakresem obowiązują od 11 września 2026 r., a stosowanie głównych wymagań przewidziano od 11 grudnia 2027 r. Nie należy zakładać, że każde oprogramowanie tworzone na własne potrzeby automatycznie się w nim mieści.

Firma, która wprowadza na rynek oprogramowanie bez wystarczających zabezpieczeń, może – w zależności od jego cech – mieć problemy ze zgodnością, nawet jeśli zbudowała je wyłącznie za pomocą narzędzi AI.

18. Własność intelektualna i odpowiedzialność umowna

Oprogramowanie to nie tylko zbiór instrukcji, które można przenosić z miejsca na miejsce.

Trzeba wziąć pod uwagę prawa autorskie, licencje, własność wytworzonych rozwiązań, korzystanie z komponentów zewnętrznych i zobowiązania umowne.

Możliwe problemy to m.in. komponenty skopiowane lub włączone na niekompatybilnych licencjach, brak identyfikacji zależności, brak ustaleń co do praw do produktów prac oraz umowne ograniczenia korzystania z określonych usług.

Samo to, że kod wygenerowała AI, nie przesądza, kto może go komercyjnie wykorzystywać, ani nie gwarantuje, że cała jego treść jest wolna od praw osób trzecich.

Te kwestie mogą wyglądać różnie w zależności od kraju i okoliczności powstania oprogramowania.

Co warto zapisać w umowie o wytworzenie oprogramowania?

Dokumentacja umowna powinna jasno określać:

• Jakie funkcje i rezultaty zostaną dostarczone.
• Kto będzie miał dostęp do kodu źródłowego i repozytoriów.
• Jakie prawa do korzystania i eksploatacji są przyznawane (pola eksploatacji).
• Jak będą zarządzane licencje firm trzecich.
• Jakie standardy bezpieczeństwa i jakości muszą być spełnione.
• Jakie testy decydują o odbiorze systemu.
• Jak będą obsługiwane incydenty i podatności.
• Jakie obowiązują zobowiązania dotyczące poufności i ochrony danych.
• Jakie wsparcie i dokumentacja są wliczone.
• Co się stanie po zakończeniu współpracy.

Przydatne może być też uzgodnienie okresowego przekazywania kodu, procedur przejściowych, a w niektórych umowach – software escrow, czyli depozytu kodu źródłowego.

Chodzi o to, by firma nie straciła kontroli nad oprogramowaniem, którego potrzebuje do działania.

19. Z perspektywy księgowej: błędna faktura może narobić więcej szkód niż błąd w wyglądzie

System księgowy wymaga precyzji, spójności i identyfikowalności.

Sztuczna inteligencja bywa bardzo pomocna przy interpretowaniu dowodów księgowych, wyciąganiu danych, klasyfikowaniu dokumentów, wykrywaniu anomalii czy przygotowywaniu uzgodnień.

Korzyści maleją jednak, gdy pozwalasz modelowi swobodnie rozstrzygać kwestie, które powinny podlegać weryfikowalnym regułom podatkowym i rachunkowym.

Na przykład system może poprawnie odczytać nazwę dostawcy, ale błędnie zinterpretować właściwą stawkę podatku.

Może też zaksięgować tę samą fakturę dwa razy, przypisać płatności niewłaściwym klientom albo doprowadzić do rozbieżności między systemem sprzedażowym a księgowością.

W Polsce integracja z KSeF – Krajowym Systemem e-Faktur – musi spełniać odpowiednie wymagania techniczne i podatkowe. To, że AI wygeneruje dokument wyglądający jak faktura, nie oznacza, że jest to faktura ustrukturyzowana wystawiona zgodnie z obowiązującą procedurą.

Co AI daje księgowości?

Używana pod nadzorem i z walidacją może ograniczyć ręczne wprowadzanie danych, przyspieszyć uzgodnienia, wskazać nietypowe operacje, uporządkować dokumentację dowodową, przygotować wstępne wersje raportów i ułatwić wyszukiwanie w dużych zbiorach informacji.

Osoba prowadząca księgowość może poświęcić więcej czasu na wyjaśnianie niespójności, a mniej na powtarzalne czynności.

Czym może zaszkodzić?

Ryzyko pojawia się, gdy automatyzacje zmieniają dane, tworzą błędne zapisy księgowe, nie zostawiają śladu albo generują dokumenty, które nie odpowiadają rzeczywistym operacjom.

Błąd może się rozprzestrzenić od fakturowania aż po sprawozdania finansowe, deklaracje podatkowe i decyzje biznesowe.

Dlatego system musi zachowywać powiązanie między dokumentami źródłowymi, zaksięgowanymi operacjami, autoryzacjami i późniejszymi zmianami.

Tę zdolność nazywa się audit trail, czyli ścieżką audytu.

Szczególnie ważne mechanizmy kontroli

System finansowy powinien przechowywać weryfikowalne dowody: kto zatwierdził operację, jaki dokument ją potwierdza, jakie wprowadzono zmiany i czy zapis zgadza się ze źródłami.

Powinien też obejmować uzgodnienia, reguły chroniące przed duplikatami, kontrolę dostępu i rozdział obowiązków (segregation of duties).

Rozdział obowiązków zapobiega sytuacji, w której jedna osoba lub jeden proces może jednocześnie utworzyć dostawcę, zmienić jego numer rachunku bankowego i zatwierdzić płatność.

Agent AI również nie powinien automatycznie otrzymywać wszystkich tych uprawnień.

20. Finansowa korzyść z naprawy systemu zbudowanego z pomocą AI

Ratowanie aplikacji może na początku wyglądać jak dodatkowy wydatek.

Z finansowego punktu widzenia warto jednak przeanalizować koszt zaniechania.

Wadliwy system może generować straty wynikające z przestojów, błędnych operacji, nadmiernego obciążenia wsparcia, utraty klientów, naruszenia umów lub konieczności przyszłej przebudowy.

Korzyść z interwencji można oszacować tak:

ROI = (przypisane korzyści netto − koszt interwencji) ÷ koszt interwencji × 100

Aby obliczenie miało sens, korzyści muszą opierać się na jawnych założeniach, a te same oszczędności nie mogą być liczone dwukrotnie.

Do najważniejszych wskaźników finansowych należą koszt operacji, godziny wsparcia, straty wynikające z błędów, skutki przestojów, koszty utrzymania i przewidywany koszt wymiany systemu.

Naprawa może się opłacać, nawet jeśli nie dodaje żadnej widocznej funkcji – pod warunkiem że w wymierny sposób zmniejsza przyszłe ryzyko i koszty.

Bezpieczeństwo, stabilność i ciągłość działania też mają wartość finansową.

D. Z perspektywy firmy, która musi naprawić to, co zepsuła sztuczna inteligencja

21. System działał, ktoś zmienił go z pomocą AI i teraz masz problem. Co możesz zrobić?

Ten scenariusz staje się coraz ważniejszy dla firm, które polegają na oprogramowaniu tworzonym lub modyfikowanym w pośpiechu.

Być może aplikację zbudował dla Ciebie ktoś, kto nie potrafi usunąć pojawiających się błędów.

Być może pracownik zmienił system z pomocą AI i uszkodził ważne dane.

A może narzędzie, które na początku działało bez zarzutu, po wielu kolejnych zmianach ma usterki, z którymi nie radzi sobie nawet sama AI.

Może się też zdarzyć, że aplikacja działa, ale nie ma już osoby, która ją zbudowała, nie ma dokumentacji albo dostępu do usług, od których zależy.

We wszystkich tych przypadkach pierwszym celem nie powinno być dodawanie kolejnych funkcji.

Priorytetem jest przywrócenie stabilności, ochrona danych i odzyskanie kontroli nad komponentami, od których zależy Twoja firma.

Sygnały, że potrzebna jest interwencja techniczna

Te objawy mogą wskazywać, że system wymaga oceny:

• Każda nowa zmiana psuje wcześniejsze funkcje.
• Ten sam błąd wraca po naprawie.
• Programista jest całkowicie zależny od AI, gdy trzeba wyjaśnić lub naprawić kod.
• Nikt nie potrafi opisać, jak zbudowana jest aplikacja.
• Nie wiesz, gdzie są przechowywane dane ani kto ma do nich dostęp.
• Zmiany wprowadza się bezpośrednio w systemie, z którego korzystają klienci.
• Koszty infrastruktury lub zużycia AI nieoczekiwanie rosną.
• Rejestry, raporty i rzeczywiste operacje się nie zgadzają.
• Nie da się wiarygodnie wyeksportować wszystkich danych.
• Aplikacja działa tylko z konta jednej osoby lub dostawcy.
• Nie ma sprawdzonych kopii zapasowych ani procedur odtwarzania.
• AI twierdzi, że naprawiła problemy, które nadal występują.

Same te objawy nie dowodzą, że przyczyną jest AI. Mogą też wynikać ze zwykłych błędów programistycznych, problemów z infrastrukturą lub administracją.

Ocena musi ustalić rzeczywiste źródło, zanim przypisze się komukolwiek odpowiedzialność.

22. Najpierw odróżnij wadliwą aplikację od krytycznego incydentu

Nie każdy problem wymaga takiego samego postępowania.

Błąd w wyglądzie można poprawić punktowo. Zmieniona baza danych wymaga znacznie ostrożniejszego postępowania.

23. Jak odzyskać kontrolę nad aplikacją zbudowaną z pomocą AI

Profesjonalny proces ratunkowy zwykle dzieli się na kilka etapów.

Proces odtwarzania i stabilizacji:

1. Opanowanie (containment): wstrzymanie niekontrolowanych zmian, ograniczenie niebezpiecznych dostępów i zapobieżenie dalszym zmianom danych.
2. Zabezpieczenie: wykonanie spójnych kopii systemów, których dotyczy problem, a także logów, konfiguracji i istotnych dowodów.
3. Diagnoza: ustalenie usterek, ich źródła, zakresu szkód i krytycznych zależności.
4. Odtworzenie: przywrócenie weryfikowalnych danych i usunięcie problemów, które uniemożliwiają działanie.
5. Stabilizacja: wdrożenie testów, zabezpieczeń, obserwowalności, kopii zapasowych i procedur kontrolowanego wdrażania.
6. Przekazanie kontroli: udokumentowanie systemu, formalne uregulowanie własności zasobów i wyznaczenie osób odpowiedzialnych za utrzymanie.

Etap 1. Opanuj sytuację, zanim wprowadzisz kolejne zmiany

Gdy system zawodzi, kusi, by naprawiać go kolejnymi poleceniami dla AI.

Problem w tym, że każda dodatkowa zmiana może utrudnić diagnozę.

Jeśli podejrzewasz utratę danych lub poważną podatność, trzeba ograniczyć niebezpieczne operacje – zwłaszcza zautomatyzowane działania, które mogą usuwać lub zmieniać dane.

W razie potrzeby można tymczasowo wyłączyć wybrane integracje lub przełączyć niektóre funkcje w tryb tylko do odczytu.

Działania ograniczające muszą uwzględniać ciągłość działalności i nie mogą niszczyć dowodów.

Etap 2. Zabezpiecz istniejące zasoby

Przed rozpoczęciem napraw warto – o ile jest to bezpieczne – wykonać spójne i zweryfikowane kopie bieżącego stanu.

Mogą one obejmować kod źródłowy, bazy danych, logi aktywności, konfiguracje, zależności, informacje o infrastrukturze i historię zmian.

W formalnym dochodzeniu może być konieczne zachowanie metadanych, udokumentowanie łańcucha dowodowego (chain of custody) i użycie mechanizmów integralności, takich jak skróty kryptograficzne (hashe).

Jeśli mogło dojść do włamania, nie wolno zakładać, że obecny stan jest czysty ani że wszystkie logi są wiarygodne.

Celem jest zachowanie możliwości zbadania i odtworzenia tego, co się wydarzyło.

Etap 3. Odzyskaj dostęp administracyjny

Firma musi ustalić, kto faktycznie kontroluje jej platformę.

Nie wystarczy znać hasła do panelu administracyjnego.

Może być też konieczne odzyskanie własności lub uprawnień administracyjnych do:

• Domeny i DNS.
• Repozytoriów kodu.
• Serwerów i usług chmurowych.
• Baz danych i przestrzeni dyskowej.
• Usług poczty e-mail.
• API i platform AI.
• Systemów płatności i fakturowania.
• Certyfikatów, kluczy i danych uwierzytelniających.
• Kopii zapasowych i mechanizmów odtwarzania.

Dane uwierzytelniające, które zostały przejęte lub niewłaściwie udostępnione, trzeba wymienić w kontrolowany sposób.

Narzędzie AI nie powinno zachowywać uprawnień administracyjnych, których już nie potrzebuje.

Etap 4. Przeprowadź niezależną diagnozę

Audyt ratunkowy musi oceniać oprogramowanie jako kompletny system.

Nie może ograniczać się do wskazania, która linia kodu powoduje błąd.

Musi też ustalić, czy architekturę da się uratować, jakie są zależności, jakie ryzyka występują, czy dane zachowały integralność i które komponenty wymagają interwencji.

Dobra diagnoza odróżnia problemy potwierdzone, podejrzenia wymagające sprawdzenia i ryzyka potencjalne.

Nieodpowiedzialne byłoby uznanie aplikacji za niebezpieczną tylko dlatego, że zawiera kod wygenerowany przez AI.

Równie nieodpowiedzialne byłoby uznanie jej za bezpieczną tylko dlatego, że skaner nie znalazł podatności.

Etap 5. Odtwórz dane i kluczowe funkcje

Po diagnozie zaczyna się odtwarzanie.

Do odtworzenia lub weryfikacji danych można użyć kopii zapasowych, dzienników transakcji, wcześniejszych wersji, eksportów i informacji z niezależnych źródeł.

Ważne jest odróżnienie odtworzenia udanego technicznie od odtworzenia poprawnego biznesowo.

Możesz na przykład odzyskać bazę danych, która znów się otwiera, ale nie zawiera ostatnich operacji Twoich klientów.

W takim scenariuszu przed zamknięciem procesu potrzebne są uzgodnienie i walidacja danych.

Procedury odtwarzania najlepiej przeprowadzać w odizolowanych, kontrolowanych środowiskach, zanim wprowadzi się zmiany na produkcji.

Etap 6. Ustabilizuj i udokumentuj

Gdy działalność zostanie przywrócona, firma musi zadbać o to, by te same błędy nie wróciły.

Oznacza to zrozumiałą architekturę, zabezpieczenia, testy automatyczne i ręczne, procedury wdrażania, monitoring, kopie zapasowe i dokumentację.

Trzeba też ustalić, kto zatwierdza zmiany i jakich dowodów potrzeba przed ich publikacją.

Sukcesem akcji ratunkowej nie jest to, że aplikacja znów się uruchamia.

Sukcesem jest to, że Twoja firma może z niej korzystać, zmieniać ją i odtwarzać bez improwizacji.

24. A jeśli nie masz kodu źródłowego, kopii zapasowych ani dostępu do dostawcy?

To jeden z najtrudniejszych scenariuszy, ale nie zawsze oznacza nieodwracalną stratę.

Możliwości zależą od tego, jakie zasoby są nadal dostępne.

Nie zawsze da się w pełni odtworzyć system.

Jeśli nie ma kopii zapasowych, dostępnych danych, logów ani innych źródeł informacji, część strat może być nieodwracalna.

Lepiej ustalić to ograniczenie na podstawie dowodów technicznych, niż obiecywać niemożliwe.

Czy system da się odtworzyć wyłącznie na podstawie obserwacji jego działania?

Czasem tak.

Ta technika wiąże się z inżynierią wsteczną (reverse engineering) i odtwarzaniem wymagań na podstawie obserwowalnego zachowania.

Możesz udokumentować ekrany, przepływy, raporty, formaty, reguły biznesowe i integracje, by zbudować zamiennik.

Odtworzenie wizualne nie gwarantuje jednak odzyskania pierwotnej logiki ani danych historycznych.

Trzeba też respektować prawa własności intelektualnej, umowy i inne obowiązujące ograniczenia.

25. Jak sprawdzić, czy naprawdę potrzebujesz specjalisty od ratowania oprogramowania

Gdy aplikacja zawodzi, kusi, by zatrudnić kogoś, kto obieca zbudować ją od nowa nowym narzędziem AI.

Ale zastąpienie rozwiązania bez zrozumienia problemu może wywołać drugi kryzys.

Potrzebny profil specjalisty zależy od sytuacji.

Błąd w wyglądzie może naprawić programista aplikacji.

Podatność wymaga wiedzy z zakresu bezpieczeństwa.

Utrata danych może wymagać specjalistów od baz danych, odzyskiwania danych lub informatyki śledczej.

System firmowy z wieloma integracjami może wymagać kompetencji z zakresu architektury, inżynierii oprogramowania, infrastruktury i znajomości reguł biznesowych.

Co powinien wykazać kompetentny dostawca?

Nie potrzebujesz dostawcy, który odrzuca sztuczną inteligencję.

Potrzebujesz takiego, który potrafi wyjaśnić, jak z niej korzysta, jak weryfikuje jej wyniki i za co bierze odpowiedzialność.

Profesjonalista powinien umieć uzasadnić decyzje architektoniczne, opisać ryzyka, przedstawić dowody z testów i przyznać, gdzie kończą się możliwości jego diagnozy.

Powinien też umieć wyjaśnić Ci projekt bez ogólników w rodzaju „nasza AI jest najbardziej zaawansowana” czy „każdą usterkę da się naprawić automatycznie”.

Sygnały ostrzegawcze przy wyborze dostawcy

Zachowaj ostrożność wobec ofert, które obiecują absolutne bezpieczeństwo, całkowity brak błędów, gwarantowane odzyskanie dowolnych danych, automatyczną zgodność z przepisami albo brak potrzeby utrzymania.

Warto też dopytać, gdy dostawca nie daje dostępu do kodu, nie wyjaśnia, gdzie przechowuje dane, unika dokumentowania zmian lub nie określa weryfikowalnych kryteriów odbioru.

Certyfikaty mogą potwierdzać konkretną wiedzę, ale nie zastępują udokumentowanego doświadczenia, testów ani zobowiązań umownych.

26. Słownik: pojęcia, które najpewniej usłyszysz, ratując swoje oprogramowanie

Te pojęcia pomogą Ci zinterpretować diagnozę techniczną i zrozumieć oferty różnych dostawców.

Pojęcia te nie są synonimami i same w sobie nie są certyfikatami jakości. To narzędzia do opisywania problemów, procesów i mechanizmów kontroli.

27. Najczęstsze argumenty w dyskusji o AI i tworzeniu oprogramowania

„AI programuje lepiej niż wielu programistów”

W niektórych zadaniach narzędzie AI może tworzyć rozwiązania doskonałej jakości, a nawet przewyższać część specjalistów szybkością lub precyzją.

Nie dowodzi to jednak, że może w ogólności zastąpić pracę nad architekturą, analizę, bezpieczeństwo, testy, integrację i odpowiedzialność biznesową.

Jakość zależy od zadania, modelu, dostępnych informacji i późniejszej weryfikacji.

Kryterium nie powinno brzmieć: czy AI jest lepsza od konkretnej osoby?

Powinno brzmieć: czy cały proces daje wystarczająco wiarygodny wynik?

„Skoro program działa, po co płacić za audyt?”

Bo nie wszystkie wady są widoczne podczas normalnego użytkowania.

Błąd autoryzacji może pozostać ukryty, dopóki ktoś nie uzyska dostępu do cudzych danych.

Źle zaprojektowana baza danych może działać, dopóki nie urośnie.

Niewłaściwą politykę kopii zapasowych często odkrywa się dopiero wtedy, gdy trzeba odtworzyć dane.

Audyt ma wykryć ryzyka, których powierzchowny test nie ujawni.

„Sztuczna inteligencja obniża koszty tworzenia oprogramowania”

Na niektórych etapach może je znacznie obniżyć.

Oszczędności trzeba jednak liczyć dla całego procesu.

Jeśli wygenerowanie funkcji kosztuje mniej, ale jej poprawienie, przetestowanie i utrzymanie wymaga dodatkowego wysiłku, początkowa oszczędność może się zmniejszyć lub zniknąć.

Może być też odwrotnie: firma z dobrą inżynierią może dzięki AI obniżyć koszty bez szkody dla jakości.

Dlatego trzeba mierzyć wyniki.

„Każdy może stworzyć profesjonalne oprogramowanie z AI”

Nowe narzędzia znacznie obniżają próg wejścia do programowania.

Może to prowadzić do wartościowych innowacji i pozwalać osobom bez klasycznego wykształcenia tworzyć przydatne narzędzia.

Jednak dostęp do generowania kodu nie oznacza automatycznie opanowania architektury, bezpieczeństwa, modelowania danych, testowania czy obowiązujących przepisów.

Różnicę trzeba oceniać na podstawie weryfikowalnych kompetencji i wyników, a nie wyłącznie dyplomów.

„To, co zepsuła jedna AI, naprawi druga”

Czasem tak jest.

AI może zlokalizować błędy, rozpoznać wzorce, objaśnić komponenty i zaproponować poprawki.

Gdy jednak problem dotyczy uszkodzonych danych, brakujących informacji, niespójnej architektury lub przejętej infrastruktury, potrzebne są dodatkowe działania i weryfikacja.

Poproszenie o poprawkę i otrzymanie przekonującej odpowiedzi nie dowodzi, że problem został rozwiązany.

„Jeśli korzystam z prywatnego modelu, wszystkie problemy z ochroną danych znikają”

Niekoniecznie.

Prywatny model może dawać większą kontrolę nad przetwarzaniem danych, ale nadal musisz chronić dostęp, logi, bazy danych, integracje, kopie zapasowe i infrastrukturę, na której działa.

Musisz też sprawdzić, co „prywatny” faktycznie oznacza w warunkach danego dostawcy.

„Open source jest zawsze bezpieczny i darmowy”

Oprogramowanie open source może być bardzo wartościowe, audytowalne i opłacalne.

Jego bezpieczeństwo zależy jednak od utrzymania, konfiguracji, znanych podatności i kontroli dostępu.

Trzeba też uwzględnić licencje i koszty eksploatacji.

To, że z komponentu można korzystać bez opłaty licencyjnej, nie znaczy, że jego eksploatacja i utrzymanie nic nie kosztują.

„Zrobienie wszystkiego od nowa jest tańsze”

Może tak być, gdy istniejący system ma poważne wady strukturalne.

Ale przebudowa oznacza też konieczność odtworzenia reguł biznesowych, migracji danych, zachowania kompatybilności i ponownego wdrożenia krytycznych procesów.

W niektórych projektach lepiej wymienić tylko wybrane komponenty, a resztę zachować.

Decyzja musi opierać się na analizie kosztów, ryzyka i ciągłości działania.

„Jedna AI może przejrzeć kod napisany przez drugą”

Tak, i bywa to przydatne.

Istnieje jednak ryzyko, że obie mają te same błędne założenia lub nie wychwycą istotnych wad.

Dlatego przegląd przy użyciu modeli nie zastępuje niezależnych testów, analizy bezpieczeństwa ani sprawdzenia rzeczywistych wyników.

„Skoro system jest w chmurze, mam zapewnione bezpieczeństwo i kopie zapasowe”

Niekoniecznie.

Infrastruktura może mieć swoje zabezpieczenia, a sama aplikacja – własne podatności.

Do tego zakres odpowiedzialności za kopie zapasowe i odtwarzanie różni się w zależności od dostawcy i umowy.

Musisz sprawdzić, co jest objęte kopią zapasową, jak długo jest przechowywane, co się stanie, jeśli dane zostaną usunięte, i jak weryfikuje się odtwarzanie.

28. Jak powinien wyglądać profesjonalny projekt ratowania i odtwarzania oprogramowania?

Firma, która musi odzyskać system, zwykle najlepiej wychodzi na projekcie podzielonym na etapy, z weryfikowalnymi rezultatami.

Ocena powinna wskazywać, jakie problemy zidentyfikowano, które usunięto, które pozostają otwarte i jakie ryzyka szczątkowe firma akceptuje.

Dzięki temu projekt ratunkowy nie zamienia się w niekończący się ciąg zmian.

29. Jak zapobiec powtórce?

Trwałe rozwiązanie nie polega na zakazaniu jakiejkolwiek sztucznej inteligencji.

Polega na wprowadzeniu zasad korzystania z niej proporcjonalnych do ryzyka.

Organizacja może używać AI do pisania kodu, generowania testów, wspierania obsługi klienta czy automatyzacji procesów, a jednocześnie wyznaczać ścisłe granice tam, gdzie w grę wchodzą skutki finansowe, operacyjne lub prawne.

Ramy zarządzania ryzykiem AI opracowane przez NIST porządkują to zadanie wokół czterech funkcji: zarządzania (govern), rozpoznania kontekstu i ryzyk (map), ich pomiaru (measure) i zarządzania nimi (manage).

W praktyce warto przyjąć pięć podstawowych zasad.

Pierwsza: żadnej krytycznej zmiany bez kontroli wersji i zatwierdzenia. Musi być możliwe ustalenie, co zmieniono, kto to zatwierdził i jak to wycofać.

Druga: żaden agent nie może mieć większych uprawnień, niż potrzebuje. Automatyzacja, która tylko odczytuje dane, nie potrzebuje ogólnych uprawnień do zapisu czy usuwania.

Trzecia: nic nie trafia na produkcję tylko dlatego, że dobrze wygląda. Musi przejść testy funkcjonalne, bezpieczeństwa i integracyjne proporcjonalne do ryzyka.

Czwarta: żaden krytyczny zasób nie może zależeć wyłącznie od prywatnego konta jednej osoby lub od jednego dostawcy. Firma musi zachować umowną i operacyjną kontrolę nad swoimi systemami.

Piąta: żadnej krytycznej operacji nie uznaje się za wykonaną tylko dlatego, że AI tak twierdzi. Musi istnieć dowód w systemie docelowym.

Te zasady sprawdzają się zarówno w pracy tradycyjnych programistów, jak i zespołów korzystających z asystentów i agentów AI.

30. Szybka diagnoza: na ile Twoja firma jest narażona?

Poniższa samoocena ma charakter orientacyjny. Nie zastępuje audytu bezpieczeństwa ani oceny zgodności z przepisami.

Przy każdym stwierdzeniu odpowiedz „Tak”, „Nie” lub „Nie wiem”. Każde „Nie” lub „Nie wiem” wskazuje obszar do sprawdzenia; „Nie wiem” jest równie istotne jak „Nie”, bo oznacza brak wglądu w dany zasób lub mechanizm kontroli.

Przykład interpretacji: firma odpowiada „Tak” na stwierdzenia 1, 3, 4, 5 i 8, „Nie” na stwierdzenie 2 oraz „Nie wiem” na stwierdzenia 6 i 7. Ma więc trzy obszary do uporządkowania: nieprzetestowane kopie zapasowe, brak dowodów dla operacji krytycznych i dokumentację niewystarczającą do zmiany dostawcy. Te trzy obszary są punktem wyjścia do planu przeglądu – zaczynając od kopii zapasowych, bo bez nich każda inna interwencja jest bardziej ryzykowna.

31. Przyszłość programowania ze sztuczną inteligencją: szybkość z odpowiedzialnością

Dzięki sztucznej inteligencji tworzenie kodu staje się coraz bardziej dostępne.

Dla wielu firm to dobra wiadomość: można eksperymentować, automatyzować procesy, ograniczać powtarzalne zadania i tworzyć narzędzia, które wcześniej były zbyt drogie.

Jednocześnie zmienia się jednak źródło wielu ryzyk technologicznych.

Przez długi czas jedną z głównych trudności firmy było znalezienie kogoś, kto zbuduje potrzebne jej oprogramowanie.

Dziś bywa odwrotnie: szybko dostaje się pozornie gotowe oprogramowanie, ale bez mechanizmów kontroli, które pozwoliłyby mu zaufać.

Wyzwaniem nie jest już samo budowanie.

Wyzwaniem jest wykazanie, że to, co zbudowano, jest poprawne, bezpieczne, możliwe do utrzymania i dopasowane do potrzeb biznesu.

Dlatego rośnie znaczenie architektury, testów, inżynierii bezpieczeństwa, obserwowalności, zarządzania danymi, audytu technicznego i mechanizmów odtwarzania.

Sztuczna inteligencja może wspierać wszystkie te działania, ale nie powinna znosić odpowiedzialności za ich weryfikację.

Podsumowanie: czy da się naprawić to, co zepsuła AI?

W wielu przypadkach tak.

Niestabilną aplikację można naprawić. System bez dokumentacji można przeanalizować. Wadliwą architekturę można zmodernizować. Źle zaprojektowaną integrację można zastąpić. Nawet oprogramowanie zbudowane niemal wyłącznie za pomocą poleceń dla AI można przekształcić w profesjonalny system.

Nie zawsze jednak warto ratować cały kod i nie wszystkie utracone dane da się odzyskać.

Kluczowe jest ustalenie, jakie zasoby istnieją, które ryzyka są realne, jakie dane można odzyskać i która strategia daje najlepszą równowagę między kosztem, bezpieczeństwem a ciągłością działania.

Rozwiązaniem nie musi być ani rezygnacja ze sztucznej inteligencji, ani sięganie po jeszcze więcej AI.

Rozwiązaniem jest powrót do inżynierskiej dyscypliny, dzięki której oprogramowanie jest wiarygodne.

AI może pomóc Ci zbudować aplikację. To inżynieria, bezpieczeństwo i właściwe zarządzanie firmą sprawiają, że staje się ona systemem, na którym możesz polegać.

A gdy to zaufanie zostało utracone, pierwszym celem nie jest szybsze programowanie.

Celem jest odzyskanie kontroli.

Źródła

• Stack Overflow Developer Survey 2025 — AI
• Stack Overflow Developer Survey 2026
• Stack Overflow Developer Survey 2026 — AI (data)
• Veracode — 2025 GenAI Code Security Report
• DORA — 2025 State of AI-assisted Software Development
• METR — Early-2025 AI and experienced open-source developer productivity (2025)
• METR — Uplift update (2026)
• OWASP Top 10:2025
• OWASP Top 10 for LLM Applications 2025
• GDPR — Regulation (EU) 2016/679
• Digital Omnibus on AI — Regulation (EU) 2026/1744
• European Commission — CRA reporting obligations
• NIST AI Risk Management Framework
• NIST Secure Software Development Framework (SSDF)