【Zgodność z przepisami】Generator aplikacji a AI IDE: drzwi rozwoju otwarte szerzej, ale 5 progów dostępu do danych użytkownika wciąż stoi — Ewolucja inżynierii oprogramowania w erze AI — Ucz się AI Powoli #176
Próg tworzenia aplikacji runął, próg dostępu do danych użytkowników – nie
Kierownicy platform centralnych w e-commerce ostatnio zadają mi w kółko to samo pytanie: strona biznesowa w tydzień potrafi sama zbudować trzy wewnętrzne narzędzia z użyciem AI, a IT wciąż ma terminy przesunięte na następny kwartał. Gdzie dokładnie leży problem?
Nasza odpowiedź sprowadza się do jednej tezy: próg tworzenia aplikacji runął, próg dostępu do danych użytkowników – nie.
Za tym stwierdzeniem stoją dwie rzeczy, które dzieją się jednocześnie.
Bolt.new to produkt StackBlitz, cicho wypuszczony w październiku 2024 roku jednym tweetem. W pięć miesięcy osiągnął 40 milionów dolarów ARR. Sacra i Growth Unhinged klasyfikują go jako drugie najszybciej rosnące narzędzie w historii (zaraz po ChatGPT). Na zamknięciu roku fiskalnego 2026 CEO StackBlitz, Eric Simons, ujawnił na LinkedInie: Bolt.new jest już używany przez trzy czwarte firm z listy Fortune 500, a ARR w segmencie enterprise wzrosło 10-krotnie rok do roku (oficjalny post Erica Simonsa, koniec roku fiskalnego 2026). Lovable to zespół ze Sztokholmu (założyciel: Anton Osika). W listopadzie 2025 roku firma zamknęła rundę A o wartości 200 mln dolarów przy wycenie 1,8 mld dolarów, a pod koniec grudnia 2025 roku rundę B przy wycenie 6,6 mld dolarów — czyli w pół roku wycena wzrosła niemal czterokrotnie (potwierdzone krzyżowo przez Forbes, CNBC, Bloomberg i TechCrunch). W czerwcu 2026 roku ARR Lovable przekroczyło 500 mln dolarów (raport Forbes, równolegle TechCrunch 2026-06-09). Tego samego dnia Forbes, powołując się na czterech wtajemniczonych, podał, że firma prowadzi nową rundę finansowania przy wycenie 12 mld dolarów (czyli niemal podwojenie). Narzędzia tej klasy skracają pracę nad aplikacją z „kilku osób przez kilka miesięcy” do „jednej osoby w jedno popołudnie”.
Ale gdy próg tworzenia oprogramowania runął, kilka bram, które w Twojej firmie są naprawdę kosztowne i naprawdę blokują pracę, ani drgnęło: ocena transferu danych za granicę w ramach RODO (art. 46 i SCC), wymogi bezpieczeństwa w ramach Krajowego Systemu Cyberbezpieczeństwa (KSC, ustawa z 5 lipca 2018 r.), ocena zgodności dla systemów AI wysokiego ryzyka w ramach EU AI Act, zatwierdzanie zmian (Change Advisory Board) i wymogi KNF Rekomendacji D dla sektora bankowego, uzgadnianie i audyt. Te bramy nie mają prawie nic wspólnego z samym kodem, a każda potrafi pochłonąć tygodnie. Generatory aplikacji wyważyły pierwsze drzwi — strona biznesowa potrafi już sama tworzyć aplikacje. Ale drugie drzwi — kto ma prawo dotykać danych produkcyjnych, kto może modyfikować transakcje rdzeniowe — ani drgnęły.
W efekcie pojawia się luka ryzyka, której większość decydentów jeszcze nie dostrzega: osoba, która potrafi zbudować aplikację, niekoniecznie ma uprawnienia, by aplikacja legalnie dotykała danych.
Prawdziwy scenariusz, który widzieliśmy (e-commerce, dane zanonimizowane): Zespół ds. współpracy z twórcami w pewnym sklepie meblowym e-commerce zbudował w ciągu dwóch miesięcy, używając Lovable, 7 wewnętrznych narzędzi: dopasowywanie twórców, kalkulator prowizji, śledzenie hitów, analiza przyczyn zwrotów. Nikt nie poinformował działu IT. Dopiero podczas półrocznego audytu shadow IT odkryto, że 4 z tych narzędzi odczytywały szerokie tabele zamówień zawierające numery telefonów i adresy dostawy, a 2 eksportowały dane do osobistych dysków w chmurze. To sytuacja, którą od drugiej połowy 2025 roku zespoły platform e-commerce powszechnie napotykają podczas inwentaryzacji zasobów — to nie pojedynczy przypadek.
Prawdziwy scenariusz, który widzieliśmy (operator telekomunikacyjny, dane zanonimizowane): Podczas wewnętrznego szkolenia podsumowującego w jednym z regionalnych oddziałów Orange Polska, kierownik projektu z działu marketingu przyznał, że zbudowali już narzędzie „szybkiego wyszukiwania profilu klienta” przy użyciu Bolt — po wpisaniu numeru telefonu wyświetlało ono historię zmian taryfy z ostatnich 90 dni, historię reklamacji i listę rekomendowanych ofert. Dział techniczny nie miał o tym pojęcia. Narzędzie to bezpośrednio naruszało granice uprawnień dostępu do danych osobowych określone w art. 5, 6 i 9 RODO oraz w Ustawie z dnia 10 maja 2018 r. o ochronie danych osobowych (z późn. zm.), a także wymogi bezpieczeństwa KSC.
Najpierw spójrzmy na jeden wykres, żeby zobaczyć, jak wygląda ta luka.
Poniżej rozkładamy to na czynniki pierwsze: czyje problemy rozwiązują te narzędzia, jak zmienia się rola inżynierów, jak wyglądają eksplodujące aplikacje cienia w e-commerce, na jakich etapach naprawdę blokują się branże o wysokich wymogach regulacyjnych oraz jak zapewnić stronie biznesowej zgodną z przepisami ścieżkę działania.
1. Najpierw umieśćmy te pięć narzędzi we właściwym kontekście
Wiele osób wrzuca te narzędzia do jednego worka i nazywa to „programowaniem z AI”. W rzeczywistości obsługują one dwie różne grupy odbiorców – i dopóki tego nie rozdzielimy, żadne dalsze wnioski nie będą miały sensu.
Pierwsza grupa to „ludzie, którzy potrafią pisać kod”. Potrzebują szybszego edytora: takiego, który rozumie kontekst w ich repozytorium, wprowadza zmiany w wielu plikach, sam uruchamia testy, tłumaczy błędy. Reprezentantami tej kategorii są Cursor, Trae od ByteDance, Tongyi Lingma od Alibaba, GitHub Copilot. Warunek jest taki, że już znasz się na inżynierii oprogramowania – narzędzie oszczędza Ci powtarzalnej pracy. O tej grupie pisaliśmy w czwartej części cyklu, więc tutaj nie będziemy się powtarzać.
Druga grupa to „ludzie, którzy nie piszą kodu”. To bohaterowie tego artykułu: generatory aplikacji. Opisujesz jednym zdaniem po polsku, co chcesz dostać, a ono zwraca Ci działającą aplikację – frontend, backend, bazę danych, deployment, wszystko w pakiecie. Nie zakłada, że umiesz programować.
Spośród generatorów aplikacji wybraliśmy cztery do omówienia, a z kategorii AI IDE wyciągamy osobno Trae – bo trafia w punkt, który ma kluczowe znaczenie dla branż silnie regulowanych.
Bolt.new (od StackBlitz). W październiku 2024 roku pojawił się cicho – jeden tweet – i został okrzyknięty przez Sacra i Growth Unhinged drugim najszybciej rosnącym produktem w historii (zaraz po ChatGPT). Pierwszy milion ARR w tydzień, 4 miliony po miesiącu, 20 milionów po około dwóch miesiącach, 40 milionów po pięciu. Do tego około 5 milionów zarejestrowanych użytkowników (dane publiczne od CEO StackBlitz). Technologia, która to umożliwia, nazywa się WebContainers – pozwala uruchomić pełne środowisko Node.js w przeglądarce, więc AI może bezpośrednio operować na plikach, instalować pakiety i uruchamiać serwisy, bez konfigurowania czegokolwiek lokalnie. Na koniec roku fiskalnego 2026 z Bolt.new korzystały trzy czwarte firm z listy Fortune 500, a ARR w segmencie enterprise wzrosło 10-krotnie rok do roku (oficjalny wpis Erica Simonsa na LinkedIn, podsumowujący rok fiskalny 2026). StackBlitz zamknął w styczniu 2025 rundę B o wartości 105,5 mln USD, przy wycenie około 700 mln USD (m.in. Business Insider). Typowe zastosowanie? Szybkie prototypowanie – mała aplikacja albo landing page, który od razu można otworzyć i zobaczyć w akcji.
Lovable (Sztokholm, Szwecja; założyciel: Anton Osika; wywodzi się wprost z open-source’owego projektu GPT Engineer). Ich model działania to „od jednego zdania do w pełni wdrożonej aplikacji” – pozycjonują się bliżej pełnoprawnych aplikacji biznesowych niż Bolt. W listopadzie 2025 r. zamknęli rundę A o wartości $200M przy wycenie $1.8B, a pod koniec grudnia 2025 r. rundę B o wartości $330M przy wycenie $6.6B – w pół roku wycena wzrosła niemal czterokrotnie. W czerwcu 2026 r. ARR przekroczył $500M (raport Forbes z 2026-06-05, równolegle TechCrunch). Tego samego dnia Forbes, powołując się na cztery źródła zbliżone do spółki, podał, że firma prowadzi nową rundę finansowania przy wycenie około $12B (czyli niemal podwojenie; Forbes/Rashi Shrivastava). Na liście klientów korporacyjnych Lovable znajdują się już m.in. Workday, Asana i NVIDIA (zestawienie ARR.club 2026).
Vercel v0. Wydany w październiku 2023, oficjalnie zmieniony z v0.dev na v0.app 3 lutego 2026 — ewoluował ze scaffoldingu komponentów UI w pełnoprawny generator aplikacji full-stack (sandbox runtime + integracja z GitHub + integracja z bazami Snowflake/AWS). Według oficjalnych danych Vercel z marca 2026, narzędzie ma ponad 6 milionów deweloperów, a miesięcznie aktywnie korzysta z niego około 80 tysięcy zespołów (analitycy konkurencji szacują ARR na ~42 mln USD; zestawienie Taskade, marzec 2026).
Replit Agent 4. Wydany 13 marca 2026 roku, to najważniejsza aktualizacja w historii Replita. Tym razem zmieniły się trzy rzeczy naraz: ① Design Mode ewoluowało w Infinite Design Canvas, pozwalając na projektowanie i edycję kodu w tym samym czasie; ② współpraca przeszła z modelu fork-and-merge na „jeden projekt, wiele równoległych zadań” — wiele sub-agentów pracuje jednocześnie, a dedykowany sub-agent ds. rozwiązywania konfliktów automatycznie scala ich pracę. Oficjalne dane: Agent 4 automatycznie rozwiązuje 90% konfliktów scalania (raport AlphaSignal 2026, potwierdzone w oficjalnym changelogu Replita z marca 2026); ③ planowanie i wykonanie nie są już sekwencyjne — można planować w trakcie działania. W tym samym okresie Replit zamknął rundę finansowania serii D, wyceniając firmę na blisko 9 miliardów dolarów (raport Atala Upadhyaya z 2026; potwierdzone przez TechCrunch i Bloomberg). Replit zaczynał jako środowisko programistyczne online, więc współpraca i hosting ma we krwi — Agent 4 sprowadza pracę zespołową nad produktem do tempa właściwego pracy indywidualnej.
Łączy je jedno: koszt „zrobienia aplikacji” spada z poziomu „zespół × miesiące” do „jedna osoba × godziny”.
Trae omawiamy osobno, bo dla firm z sektora telekomunikacyjnego, finansowego i e-commerce stanowi konkretne ryzyko dostawcy. Trae ma formę IDE (edytora), ale w praktyce jest środowiskiem programistycznym trwale związanym z serwerami ByteDance — dla użytkowników korporacyjnych nie można go traktować jak „zwykłego IDE”, tylko jak „narzędzie przesyłające dane za granicę” i poddać odpowiedniej ocenie dopuszczalności. ByteDance wypuściło Trae w styczniu 2025 roku, celując bezpośrednio w Cursor; strategią było darmowe udostępnianie zaawansowanych modeli, takich jak Claude czy GPT-4o. W ciągu 12 miesięcy zarejestrowało się 6 milionów użytkowników, miesięcznie aktywnych było 1,6 miliona, a łącznie wygenerowano około 100 miliardów linii kodu (dane zbiorcze z badania OpenAI Tools Hub, maj 2026). Jednak w lipcu 2025 roku badacz bezpieczeństwa segmentationf4u1t opublikował projekt telemetry_research, który udowodnił, że nawet po wyłączeniu telemetrii w ustawieniach Trae nadal w tle wysyła dane do serwerów ByteDance, takich jak mon-va.byteoversea.com — w tym informacje o sprzęcie, wersji systemu operacyjnego, trwałe identyfikatory urządzenia i maszyny oraz dane o aktywności w projektach; pojedyncza partia telemetryczna może osiągnąć rozmiar do 53 606 bajtów, a około 7 minut normalnego użytkowania generuje ponad 500 wywołań i około 26 MB danych (dane źródłowe z GitHub segmentationf4u1t/trae_telemetry_research, relacja The Register/Cybernews z 28.07.2025).
Odpowiedź ByteDance na późniejsze wydarzenia jest warta odnotowania. W aktualizacji z 2026-08-01 serwis Cybernews pisze: oficjalne oświadczenie ByteDance przyznaje, że przełącznik telemetrii w ustawieniach IDE kontroluje wyłącznie telemetrię części opartej na VS Code, a zbieranie danych przez inne narzędzia Trae nie jest objęte tym przełącznikiem — mówiąc wprost: myślisz, że wyłączyłeś, a tak naprawdę nie wyłączyłeś. Po bezpośrednim kontakcie badaczy z zespołem Trae potwierdzono, że niezależny tryb Privacy Mode ma zostać wydany około sierpnia 2026 roku. W międzyczasie wprowadzony w lutym 2026 „token-based paywall” w Trae złamał obietnicę „forever free”, co skłoniło wielu programistów, którzy wdrożyli to narzędzie w środowiskach produkcyjnych, do ponownej oceny sytuacji (podsumowanie badania OpenAI Tools Hub z maja 2026).
Dla indywidualnego programisty darmowy Claude to świetna sprawa. Dla Ciebie jako decydenta to jednak klasyczny problem zgodności z przepisami o transferze danych za granicę — Twoi inżynierowie wrzucają kod firmowy, a być może także konfiguracje i interfejsy, do narzędzia, które przesyła dane na serwery ByteDance. W branżach takich jak telekomunikacja czy finanse, objętych przepisami Ustawy o bezpieczeństwie danych i Ustawy o ochronie informacji osobistych, już sam ten krok może stanowić naruszenie zgodności. Temat ten zostanie szczegółowo omówiony w sekcji czwartej.
2. Rozwój przepisany od nowa: od „pisania kodu” do „przeglądu, orkiestracji i kontroli”
Generatory aplikacji najłatniej jest źle odczytać – że „inżynierowie nie będą już potrzebni”. To błędny kierunek.
Dokładniej rzecz ujmując: zmieniają one środek ciężkości pracy inżyniera, ale nie likwidują tego stanowiska. Gdy AI i pracownicy biznesowi potrafią już produkować kod i aplikacje, wartość inżyniera przesuwa się z „pisania samodzielnie” na trzy rzeczy: weryfikację, czy te wytwory są poprawne, orkiestrację ich w niezawodny system oraz pilnowanie bezpieczeństwa i jakości.
Te trzy rzeczy są bardziej deficytowe i bardziej wartościowe niż „pisanie kodu”. Osób, które potrafią napisać komponent w Reakcie, jest na pęczki; osób, które potrafią ocenić, czy wygenerowana przez AI aplikacja promocyjna może trafić na produkcję i dotykać danych transakcyjnych, czy jej uwierzytelnianie nie jest atrapą, czy nie wysyła logów do zagranicznych serwisów — takich osób jest znacznie mniej.
W tym miejscu trzeba dokonać jednoznacznego rozróżnienia, bo zbyt wiele firm wpada w skrajności: albo powierzają generatorowi wszystko, albo zakazują ich całkowicie. Obie skrajności są kosztowne.
Ten diagram przekazuje tylko jedno: oś pozioma pokazuje, jak złożona jest logika aplikacji, a oś pionowa — czy dotyka ona pieniędzy i danych osobowych. W prawym dolnym rogu (wysoka złożoność + wysoka wrażliwość) nawet najmądrzejszy generator aplikacji nie ma czego szukać. Stronę docelową kampanii promocyjnej można spokojnie powierzyć narzędziu Lovable; bramkę płatniczą — to tylko kwestia czasu, kiedy coś pójdzie nie tak.
Wytnij tę czerwoną linię w pamięć, a potem spójrz na to, co dzieje się w e-commerce.
3. Prawdziwy ból e-commerce — aplikacje-cienie wchodzą w drogę danym zamówień
Cofnijmy obiektyw i spójrzmy najpierw na liczbę, którą Gartner opublikował w drugiej połowie 2025 roku: do końca 2026 roku 40% aplikacji korporacyjnych będzie zawierać osadzone, zadaniowe agenty AI, podczas gdy w 2025 roku odsetek ten wynosił mniej niż 5% (oficjalna prognoza Gartnera, za Process Excellence Network, 2025-08-27). W parze z tym idzie jeszcze bardziej uderzająca statystyka: Gartner odnotował wzrost zapytań o systemy multi-agentowe o 1445% między Q1 2024 a Q2 2025 — to najszybciej rosnący temat w doradztwie AI Gartnera, bez żadnej konkurencji (dane zbiorcze z RAPIDCLAW / Hendricks.ai / Arion Research).
Przetłumacz te dwie liczby na język e-commerce: 40% aplikacji korporacyjnych będzie uruchamiać agentów AI, a do tego druga liczba — wzrost zapytań o systemy multi-agent w przedsiębiorstwach o +1445% (to wskaźnik wzrostu zapytań doradczych w AI advisory Gartnera, nie wdrożeń, ale kierunkowy sygnał jest jasny): agenci AI przeszli od „pomagania w pisaniu kodu” do „wspólnej pracy kilku agentów, którzy realizują cały proces biznesowy”. Gdy agenci AI zaczynają działać w aplikacjach korporacyjnych — dotykają danych, uruchamiają procesy, zapisują logi — natura generatorów aplikacji zmienia się z „narzędzia” w „system”.
Firma badawcza UpGuard w swoim raporcie z 2025 r. (State of Shadow AI, opisanym przez Cybersecurity Dive) podaje dwie liczby, które robią większe wrażenie niż te 40% od Gartnera: ponad 80% pracowników używa w pracy niezatwierdzonych narzędzi AI, a w samych zespołach bezpieczeństwa robi tak blisko 90% osób. Do tego: około połowa pracowników przyznaje, że wklejała poufne dane firmowe bezpośrednio do tych niezatwierdzonych narzędzi. Mimecast podaje 51%, Teramind 49% – wyniki są zbliżone. Z kolei Gartner pokazuje drugą stronę: 69% organizacji podejrzewa lub ma potwierdzenie, że pracownicy używają zabronionych narzędzi AI, a tylko 37% organizacji ma jakiekolwiek zasady korzystania z AI (za The Hacker News).
Przełóżmy te liczby na język e-commerce: Twój zespół operacyjny, marketing i osoby od kampanii budują sobie własne aplikacje za pomocą narzędzi takich jak Bolt, Lovable czy v0. Konfigurator reguł promocyjnych, tablica do wyboru produktów od twórców, miniaplikacja do sprawdzania stanów magazynowych, narzędzie do obsługi zgłoszeń posprzedażowych. Są szybkie, wygodne i rozwiązują realne problemy. I prawie w całości omijają IT oraz ład zarządczy danymi.
Realny przypadek, który obsługiwaliśmy (e-commerce, dane zanonimizowane): od drugiej połowy 2025 roku, podczas audytów shadow IT u 4 średnich i dużych firm e-commerce (zespoły platformowe liczące 50–200 osób), nie trafiliśmy ani razu na pusty wynik. Najbardziej typowy przykład – sklep z wyposażeniem domu: zespół ds. współpracy z twórcami treści w ciągu 2 miesięcy samodzielnie zbudował 7 wewnętrznych narzędzi w Lovable, z czego 4 operowały na szerokich tabelach zamówień (z numerami telefonów i adresami dostawy), a 2 eksportowały dane do prywatnych chmur. W dniu audytu kierownik ds. bezpieczeństwa powiedział wprost: „Mało nie wstrzymaliśmy całego przeglądu – baliśmy się, że jak to ujrzy światło dzienne, nikt nie będzie chciał się tym zająć.”
Taki stan rzeczy można śmiało nazwać „cieniowym IT danych”. Przez ostatnie kilkanaście lat problemem był shadow IT w postaci SaaS kupowanych przez jednostki biznesowe (sprzedaż dokupowała CRM, marketing – narzędzie do mailingu). Dziś shadow IT to aplikacje, które jednostki biznesowe same tworzą. Powstają one z użyciem niezatwierdzonego narzędzia – co gorsza, generują też nowy system operujący na wrażliwych danych, którego nie ma w rejestrze zasobów IT.
Różnica jest skokowa: zakup SaaS to podpięcie zewnętrznego systemu; tworzenie aplikacji za pomocą generatora to wyhodowanie od zera całej gamy nowych systemów wewnątrz firmy – każdy z interfejsami danych, każdy potencjalnie dostępny z zewnątrz. W ciągu roku firma e-commerce może w ten sposób „urodzić” ponad sto takich aplikacji, z których żadna nie widnieje w rejestrze IT.
Tej sprawy nie da się zablokować. Te 80% od UpGuard już pokazuje, że zakazy niczego nie rozwiążą. Ludzie zawsze znajdą najwygodniejsze narzędzie, żeby wykonać robotę — to natura ludzka i KPI. Więc nie pytajmy „jak powstrzymać biznes przed używaniem generatorów”, tylko „jak sprawić, żeby używali ich bezpiecznie”. W sekcji czwartej omawiam progi zgodności, w piątej — jak udrożnić kanały.
4. Które progi zgodności trzeba przejść — to nie jest test
To sekcja, którą w tym artykule najbardziej warto napisać precyzyjnie — i najłatwiej ją spartaczyć.
Wiele osób z backgroundu internetowego, słysząc „kontrola jakości”, od razu myśli o testach automatycznych w CI/CD: testy jednostkowe, integracyjne, regresyjne — zielone światło i lecimy. Zespoły techniczne robiące wielkie promocje w e-commerce znają ten schemat doskonale.
Ale w telekomunikacji, finansach, regulowanym przemyśle i e-commerce „weryfikacja” to coś znacznie szerszego niż testy. Prawdziwe wąskie gardła to kilka etapów, które mają niewiele wspólnego z samym kodem, a każdy potrafi zająć tygodnie. Traktowanie ich jak „testów” to internetowy nawyk myślowy, który wprowadza decydentów w błąd i każe im niedoszacować czasu dostarczenia.
Przejdźmy przez nie po kolei.
Ocena transferu danych za granicę.[^1] Jeśli Twoja aplikacja korzysta z zagranicznych usług AI (wiele generatorów działa w oparciu o backendy OpenAI czy Anthropic zlokalizowane w USA lub na terenie EOG), albo Twoi inżynierowie używają IDE takiego jak Trae, które przesyła dane poza granice EOG – o ile dane zawierają informacje osobowe – wchodzą w grę wymogi dotyczące transferu danych wynikające z art. 44–50 RODO, w tym obowiązek stosowania Standardowych Klauzul Umownych (SCC), kodeksów postępowania lub certyfikacji. W Polsce nadzór sprawuje UODO (Urząd Ochrony Danych Osobowych), który w 2024 r. nałożył na Virgin Mobile Polska karę 1,9 mln zł za brak odpowiednich zabezpieczeń transferu danych do Stanów Zjednoczonych, a w 2023 r. na Morele.net karę 2,8 mln zł. Przeprowadzenie pełnej oceny ryzyka transferu (TIA) i zakończenie procedury SCC zajmuje od jednego–dwóch miesięcy do nawet ponad pół roku. Przypadek Trae – gdzie wykryto przesyłanie danych nawet po wyłączeniu telemetrii – pokazuje, że dane mogą być transmitowane nawet wtedy, gdy wydaje Ci się, że nie są. W branżach o wysokich wymogach regulacyjnych takie narzędzia w ogóle nie powinny trafiać do środowiska deweloperskiego.
Wymogi bezpieczeństwa i ocena zgodności.[^2] W Polsce odpowiednikiem chińskiego systemu klasyfikacji ochrony (等级保护 2.0) jest ramka oparta na Ustawie o Krajowym Systemie Cyberbezpieczeństwa (KSC) z 2018 r. oraz normie ISO/IEC 27001. Operatorzy usług kluczowych (sektory: energetyka, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, zaopatrzenie w wodę, infrastruktura cyfrowa) muszą spełniać wymogi KSC i przejść audyt zgodności; aplikacja publiczna obsługująca klientów indywidualnych najczęściej zostanie zakwalifikowana jako system istotny, wymagający pełnej dokumentacji środków bezpieczeństwa. Cykl klasyfikacji, rejestracji, wdrożenia poprawek i audytu trwa zwykle od trzech do sześciu miesięcy. To wymóg prawny, a nie opcja. Aplikacje generowane przez AI nie otrzymają zwolnienia z tego obowiązku tylko dlatego, że powstały szybko.
Ocena zgodności systemów AI (EU AI Act).[^3] Jeśli Twoja aplikacja jest publicznie dostępna i wykorzystuje generatywną AI (np. automatyczne generowanie opisów produktów, automatyczne odpowiedzi na zapytania klientów, czy treści AI w spersonalizowanych rekomendacjach), to – zgodnie z EU AI Act (Rozporządzenie 2024/1689, obowiązuje od 2 sierpnia 2026 r. w pełnym zakresie) – wchodzisz w reżim wysokiego ryzyka, wymagający oceny zgodności (conformity assessment), rejestracji w unijnej bazie systemów AI oraz nadzoru ze strony wyznaczonego organu krajowego. W Polsce organem wskazanym do nadzoru nad AI Act jest UODO (dla wymiaru ochrony danych) oraz Ministerstwo Cyfryzacji (dla polityki cyfrowej). Wprowadzenie aplikacji na rynek bez oceny zgodności to poważne naruszenie zgodności, a kary mogą sięgnąć do 7% rocznego światowego obrotu lub 35 mln EUR (w zależności od kategorii naruszenia).
Zatwierdzanie zmian (CAB) i plan wycofania.[^4] W systemach kluczowych dla bankowości i telekomunikacji każde wdrożenie produkcyjne musi przejść przez zatwierdzenie w ramach Change Advisory Board: ocena wpływu, plan wycofania, potwierdzenie okna wdrożeniowego. W Polsce sektor bankowy dodatkowo podlega KNF Rekomendacji D w sprawie zarządzania ryzykiem technologicznym w bankach (wydanie 2013, nowelizacja 2023), która szczegółowo opisuje wymogi dotyczące zarządzania zmianami, ciągłością działania i outsouringiem IT — ma to realne znaczenie przy wprowadzaniu narzędzi AI do banku takiego jak PKO BP, mBank czy ING Bank Śląski. Ten etap pochłania czas kalendarzowy, a nie czas maszynowy — jeśli nie zdążysz w okno, czekasz do następnego tygodnia.
Uzgodnienia i audyt.[^5] W e-commerce podczas wyprzedaży, w finansach przy rozliczeniach — po wdrożeniu trzeba uzgodnić dane z funduszami i z systemami nadrzędnymi, a logi audytowe muszą pozwalać na prześledzenie każdej transakcji. Aplikacje generowane przez AI zwykle nie mają tego zaimplementowanego: działają, ale nie zaprojektowano w nich uzgodnień, więc w razie rozbieżności księgowych nie ma jak ich namierzyć.
Zestawiając to razem, widzisz wniosek, który idzie pod prąd intuicji: generatory aplikacji przyspieszają przejście od „pomysłu” do „działającego prototypu” o rząd wielkości, ale od „działającego prototypu” do „zgodnego z regulacjami wdrożenia” — czasu nie oszczędzają wcale. Te bramki zajmują tyle samo co kiedyś.
To ta czerwona linia, która się nie przesuwa, z wykresu w pierwszej sekcji. Próg wejścia w development się zawalił — zaoszczędzony czas to czas pracy inżynierów; próg zgodności regulacyjnej stoi w miejscu — oceny, testy, zatwierdzenia trwają tyle samo. Największy błąd decydentów to myślenie, że przyspieszenie pierwszego automatycznie przyspieszy drugie. Nie przyspieszy.
5. Daj biznesowi zgodną ścieżkę — zamiast pozwolić mu działać na dziko
Skoro nie da się tego zablokować, trzeba dać kanał — to jedna z niewielu dróg, które realnie działają w zarządzaniu shadow IT.
Jak konkretnie zbudować ten kanał? W czterech krokach.
Krok pierwszy: firma udostępnia własny, zweryfikowany pod kątem bezpieczeństwa generator. Zamiast pozwalać zespołom operacyjnym na korzystanie zewsząd z byle jakiego Lovable, firma kupuje lub buduje wewnętrznie wersję zgodną z wymogami RODO i KSC oraz taką, która nie wypuszcza danych poza EOG. Ta wersja dostaje wewnętrzny punkt dostępu. Jeśli strona biznesowa ma wygodne narzędzie pod ręką, nie szuka rozwiązań na zewnątrz – to jest ta „droga na skróty” w dobrym sensie, uzupełnienie twardych zakazów. Microsoft w roku fiskalnym 2026 pokazał, jak to może wyglądać w praktyce: EY wdrożyło Copilota dla 150 000 pracowników i odnotowało 15% wzrost produktywności; Atos wdrożyło Copilota dla 56 000 pracowników w 54 krajach, zarządzając 19 000 agentów AI w ramach ujednoliconej kontroli nad tożsamością, bezpieczeństwem, zgodnością i governance agentów (wpis podsumowujący Microsoft FY26 z 2026-07-28 oraz oficjalny komunikat Atos z 2026-06-09 – w obu przypadkach to wspólne deklaracje producenta i klienta). Łączy ich jedno: narzędzia AI zostały wpięte w korporacyjną płaszczyznę bezpieczeństwa i zgodności – to właśnie żywy przykład kanału sankcjonowanego. W Polsce analogiczne podejście można oprzeć na rekomendacjach KNF (w szczególności Rekomendacja D dla sektora bankowego oraz Rekomendacja P dla branży ubezpieczeniowej) oraz na wytycznych UODO i Ministerstwa Cyfryzacji dotyczących wdrażania AI w administracji i sektorze prywatnym – lokalna ścieżka już istnieje, brakuje tylko włączenia jej w obowiązkowe procesy firmowe.
Krok drugi: obowiązkowa rejestracja. Kto zbudował aplikację, do jakich danych ma dostęp i dla kogo jest przeznaczona – wszystko trafia do rejestru. Formularz ma być lekki, wypełnienie w 5 minut, a nie dwumiesięczna procedura – inaczej nikt nie będzie go wypełniał i znów wrócimy do podziemia. Celem rejestracji nie jest zatwierdzanie każdej aplikacji, tylko posiadanie pełnej listy.
Krok trzeci: segregacja według poziomu wrażliwości danych. Używamy macierzy z sekcji drugiej. Aplikacje, które dotykają wyłącznie danych zanonimizowanych lub testowych, przechodzą automatycznie. Gdy tylko pojawia się wniosek o dostęp do prawdziwych zamówień lub danych osobowych, automatycznie uruchamiane są procedury oceny transferu danych za granicę oraz oceny zgodności z wymogami bezpieczeństwa (w Polsce odpowiednik: ocena skutków dla ochrony danych i audyt zgodności z RODO). Proces podąża za wrażliwością danych, zamiast traktować wszystkie aplikacje jednakowo.
Krok czwarty: automatyczne skanowanie bezpieczeństwa. Aplikacje generowane przez AI mają znacząco wyższy wskaźnik podatności niż kod pisany ręcznie. W raporcie CodeRabbit z 2026 roku zaktualizowano tę liczbę: kod generowany przy wsparciu AI generuje 1,7 razy więcej problemów (w tym błędów logicznych i poprawnościowych) niż kod pisany tradycyjnie (metodologia własna CodeRabbit, z zastrzeżeniem perspektywy komercyjnej; potwierdzone webinarium DORA 2026-02 oraz benchmarkiem porównawczym Kunala Ganglaniego z 2026). Raport Veracode z 2025 roku dotyczący bezpieczeństwa kodu GenAI jest jeszcze bardziej bezpośredni: w przebadanych próbkach około 45% kodu generowanego przez AI zawiera podatności na poziomie OWASP Top 10 (wskaźnik awaryjności dla generowanego kodu Java przekracza 70%; metodologia własna Veracode, z zastrzeżeniem perspektywy komercyjnej). Akademicka, zakrojona na szeroką skalę analiza empiryczna publicznych repozytoriów GitHub (arXiv:2510.26103) potwierdza ten sam kierunek. Dlatego skanowanie w przypadku aplikacji generowanych przez AI jest obowiązkowe, a nie opcjonalne. Podłącz SAST, skanowanie zależności i skanowanie kluczy do procesu wydawniczego generatora – tylko zielone światło przepuszcza build. CodeRabbit w czerwcu 2026 roku został publicznie potwierdzony jako najczęściej instalowane narzędzie do przeglądu kodu AI na GitHub/GitLab – ponad 15 000 płacących klientów, 6 milionów przeskanowanych repozytoriów, a sam CEO NVIDII, Jensen Huang, publicznie poświadczył: „Cały NVIDIA używa CodeRabbit” – traktowanie go jako baseline’u dla korporacyjnej bramki jakości kodu AI jest w pełni uzasadnione.
Te cztery kroki praktycznie nie spowolniły pracy działów biznesowych, ale każda aplikacja trafiła na audytowalną listę, a te, które dotykały danych wrażliwych, zostały zatrzymane i skierowane do formalnej oceny. To jest governance, nie spowalnianie.
Tu trzeba sprostować jeden błędnie powtarzany numer. W oryginalnym tekście pojawiło się „45% wskaźnika adopcji shadow AI” – to pomylenie faktów. 45% to odsetek defektów w kodzie generowanym przez AI według raportu Veracode, a nie wskaźnik adopcji narzędzi; adopcję shadow AI mierzy raport UpGuard, który mówi o ponad 80%. To dwie zupełnie różne rzeczy, nie należy ich mylić.
6. Kiedy nie należy używać generatorów aplikacji
To nie jest srebrna kula. Cztery typowe przypadki nadużyć – każdy z nich widzieliśmy u naszych klientów.
Do kluczowych transakcji lub zarządzania ryzykiem. To najgroźniejszy przypadek. Ktoś myśli: „skoro generator jest tak dobry, spróbujmy z bramką płatniczą”. Prawy dolny róg wspomnianej wcześniej macierzy to strefa czerwona – złożona logika plus pieniądze. Oddanie tego generatorowi to jak powierzenie kluczowego systemu stażyście, który nie ponosi odpowiedzialności. Przy incydencie finansowym nie ma uzgodnień, audytu ani planu wycofania.
Domyślne założenie, że kod generowany przez AI jest bezpieczny. Odpowiedzią na to są wyniki CodeRabbit (1,7x) i Veracode (45%). Między aplikacją generowaną przez AI, która „wygląda, jakby działała”, a taką, która „działa bezpiecznie”, leży cała inżynieria bezpieczeństwa. Traktowanie aplikacji generowanych przez AI inaczej niż aplikacji tworzonych przez ludzi i obniżanie im standardów bezpieczeństwa to po prostu szybsze generowanie większej liczby podatności.
Przetwarzanie danych osobowych za pomocą zagranicznych generatorów bez przeprowadzenia oceny skutków dla ochrony danych (DPIA). To szczególnie podstępny problem w e-commerce: dział marketingu przygotowuje kampanię skierowaną do klientów, backend wywołuje OpenAI w celu wygenerowania treści, a numer telefonu użytkownika trafia przy okazji do zagranicznego usługodawcy. W ten sposób przekracza się czerwoną linię wyznaczoną przez art. 35 RODO (obowiązek DPIA przy przetwarzaniu niosącym wysokie ryzyko) i art. 44 RODO (zasady przekazywania danych do państw trzecich). Jeśli dojdzie do incydentu, UODO traktuje to jako naruszenie ochrony danych, a nie „bug techniczny”, z obowiązkiem zgłoszenia w ciągu 72 godzin (art. 33 RODO) i karą do 4% rocznego światowego obrotu lub 20 mln EUR.
Domyślna instalacja IDE z funkcją wysyłania danych za granicę, takiego jak Trae, wszystkim inżynierom w firmie. Darmowe, zaawansowane modele są bardzo kuszące i inżynierowie sami je instalują. Gdy Twój kluczowy kod, konfiguracja i interfejsy trafią na serwery ByteDance (lub jakiegokolwiek innego podmiotu spoza Twojej jurysdykcji), na naprawienie szkód może być już za późno. Wprowadzenie takich narzędzi do środowiska deweloperskiego wymaga oceny z udziałem zespołów ds. bezpieczeństwa i prawnych, a nie decyzji podejmowanej samodzielnie przez zespół techniczny.
7. Perspektywa czterech branż: które zastosowania można wdrożyć, a których absolutnie nie
Ten rozdział koncentruje się na 4 branżach, w których towarzyszyliśmy firmom w pokonywaniu realnych problemów (e-commerce / finanse / telekomunikacja / produkcja). Scenariusze w silnie regulowanych sektorach, takich jak administracja publiczna czy ochrona zdrowia, omówimy osobno w innym artykule.
Przenieśmy teraz obiektyw na cztery sektory — każdy z nich zilustrujemy realnym scenariuszem, który widzieliśmy na własne oczy.
E-commerce. Największe ryzyko eksplozji niosą „konfiguratory reguł promocyjnych”, „tablice wyboru produktów dla influencerów” i „miniaplikacje do sprawdzania stanów magazynowych” — wyglądają jak narzędzia, ale w rzeczywistości czytają szerokie tabele zamówień z numerami telefonów i adresami. Tego typu aplikacje muszą być rejestrowane w kanale sanctioned opisanym w sekcji trzeciej — a dotknięcie prawdziwych danych automatycznie uruchamia ocenę zgodności z przepisami o ochronie danych i ocenę transferu danych za granicę. W Polsce realnym punktem odniesienia są platformy takie jak Allegro czy Empik, gdzie działanie z wrażliwymi danymi klientów bez oceny skutków dla ochrony danych (DPIA) szybko spotka się z kontrolą UODO. Widzieliśmy na własne oczy, jak zespół operacyjny jednej polskiej firmy e-commerce w ciągu dwóch miesięcy zbudował siedem wewnętrznych narzędzi, z czego cztery czytały szerokie tabele zamówień — to nie jest odosobniony przypadek.
Finanse. Czerwoną linią są: „systemy transakcyjne / płatności / rozliczenia i clearing / zarządzanie ryzykiem / antyfraud / raportowanie regulacyjne”. Generator nadaje się za to do budowy paneli doradców klienta, konfiguratorów kampanii marketingowych czy frontendów do raportów uzgodnieniowych. Pod żadnym pozorem nie wolno używać go do budowy silnika ryzyka czy reguł antyfraudowych — ten współczynnik 1,7x błędów logicznych od CodeRabbit (metodologia własna CodeRabbit, z zastrzeżeniem ich pozycji komercyjnej) w scenariuszu finansowym przekłada się na realne ryzyko strat finansowych. W Polsce największe banki — PKO Bank Polski, mBank, ING Bank Śląski, Bank Pekao — operują pod szczególnym nadzorem KNF (Komisji Nadzoru Finansowego), a wprowadzenie każdego nowego narzędzia AI wymaga oceny ryzyka technologicznego zgodnie z Rekomendacją D KNF (wydanie 2013, nowelizacja 2023). Przypadek poniższy jest zanonimizowany: jeden polski bank komercyjny pod koniec 2025 roku zaczął używać programowania wspieranego AI do generowania raportów regulacyjnych dla KNF. W skryptach raportowych znalazły się trzy miejsca z błędnie dopasowanymi definicjami pól — bank został wezwany na rozmowę przez KNF. Jedną z głównych przyczyn było to, że „kod, który wygląda na poprawny”, wygenerowany przez AI, nie został przez nikogo zweryfikowany.
Telekom / operatorzy. W jednym z regionalnych oddziałów Orange Polska, z którym współpracowaliśmy, zespół marketingu w oddziale terenowym samodzielnie zbudował w Bolt „szybkie wyszukiwanie profilu klienta” – po wpisaniu numeru telefonu można było pobrać dane o taryfie, reklamacjach i rekomendacjach z ostatnich 90 dni. To bezpośrednie naruszenie zasad dostępu do danych wynikających z art. 5, 6 i 9 RODO oraz wymogów operatorów kluczowych usług cyfrowych w ramach Ustawy o KSC. W scenariuszach operatorskich w Polsce — dotyczących Orange Polska, T-Mobile Polska, Play czy Plus — generator może służyć do budowy „panelu pracy opiekuna klienta”, „front-endu bazy wiedzy dla obsługi” czy „konfiguratora kampanii marketingowych”, ale absolutnie nie może dotykać systemów bilingowych, rozliczeń ani zapytań o szczegóły połączeń – to newralgiczny obszar operatora, w którym błąd natychmiast trafia na pierwsze strony i wiąże się z obowiązkiem zgłoszenia incydentu do CSIRT NASK (Krajowy Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego, pełniący w Polsce rolę CSIRT dla sektora telco).
Produkcja. Systemy MES/ERP, integracja i testy łączności, kontrola jakości i raportowanie to systemy kluczowe — generator może pracować jedynie na obrzeżach: tablice cechowe na hali produkcyjnej, zapytania o karty technologiczne, demo OEE dla maszyn. Pod żadnym pozorem nie wolno mu dotykać: algorytmów planowania produkcji, reguł oceny jakości ani interfejsów uzgadniania z nadrzędnym ERP. W polskim kontekście największe zakłady przemysłowe to m.in. PKN Orlen (największy koncern paliwowy w Europie Środkowo-Wschodniej), Grupa Azoty, KGHM Polska Miedź, Synthos — wszystkie należą do operatorów kluczowych w ramach KSC. Przykład zanonimizowany: pewien dostawca części motoryzacyjnych z Europy Środkowej (w publicznych źródłach można znaleźć kilka podobnych przypadków recalli w branży automotive; szczegóły złożono z publicznych ogłoszeń o wycofaniu produktów oraz projektów, w których brałem udział — służą zilustrowaniu logiki decyzyjnej, nie wskazują na konkretną firmę) zlecił IT zbudowanie „tablicy frontendowej dla modelu AI do kontroli jakości” w Bolt. Chodziło tylko o wyświetlanie zdjęć z próbek i wyników klasyfikacji. Tymczasem przy renderowaniu frontendu surowy próg ufności z inferencji modelu AI został na sztywno wpisany w kod klienta. Pracownik przez przypadek zmienił 0,85 na 0,6 i w ciągu 3 dni ponad 200 części, które powinny zostać oznaczone jako „niezgodne”, przeszło do dalszych etapów produkcji jako „zgodne”. Skończyło się wycofaniem 3 partii. Najczęstszy błąd średnich zakładów produkcyjnych: powierzenie generatorowi właśnie „frontendu modelu AI do kontroli jakości” — bo konsekwencją błędnych reguł jakości jest recall, a każdy błąd to publiczne ogłoszenie o wycofaniu i potencjalna odpowiedzialność z tytułu RODO oraz Ustawy o ogólnym bezpieczeństwie produktów.
8. Wnioski dla decydentów
Wniosek pierwszy: najpierw narysuj mapę warstw aplikacji, potem rozmawiaj o zakupie narzędzi.
Weź macierz z sekcji drugiej i wpisz do niej wszystkie aplikacje, które już macie oraz te planowane — według poziomu złożoności i wrażliwości danych. Od razu zobaczysz, które obszary są zielone i można je bezpiecznie oddać generatorom w celu przyspieszenia prac, a które są czerwone i nie wolno ich nawet tknąć. Taka jedna mapa potrafi zdjąć ze stołu mnóstwo impulsywnych propozycji typu „przebudujmy systemy krytyczne generatorem”, a jednocześnie daje zielone światło tym obszarom, które faktycznie powinny działać szybciej.
Wniosek drugi: traktuj przepisy o transferze danych i ocenę zgodności jako warunek wstępny, a nie poprawkę po wdrożeniu.
Zanim kupisz jakiekolwiek narzędzie AI, które będzie miało styczność z kodem lub danymi, przepuść je przez te dwie bramki. Problem z narzędziami typu Trae nie polega na tym, „czy działają”, tylko na tym, „czy w twoim otoczeniu regulacyjnym w ogóle mogą być używane”. Tę decyzję trzeba podjąć z wyprzedzeniem — koszt błędu to późniejsze poprawki, raporty do organów, a nawet wyłączenie narzędzia. Konkretne działanie: włącz zakup narzędzi AI do wspólnej ścieżki zatwierdzania z zespołem bezpieczeństwa i prawnym, i stwórz dwie jasne listy: „może wejść do środowiska deweloperskiego” oraz „wymaga indywidualnej zgody”.
Wniosek trzeci: daj stronie biznesowej legalną ścieżkę, bo inaczej shadow IT będzie tylko rosnąć.
Te 80% z sekcji trzeciej pokazuje, że blokowania się nie da. Zamiast czekać na inwentaryzację po awarii, lepiej już teraz zbudować ścieżkę opisaną w sekcji piątej: dozwolone generatory, lekka rejestracja, podział według wrażliwości danych, automatyczne skanowanie. Niech biznes działa szybko, ale każdy przypadek musi być na liście. W ten sposób zamieniasz shadow IT z niekontrolowanej szarej strefy w audytowalny zasób.
Wniosek czwarty: zmień metryki, inaczej cały budżet pójdzie na narzędzia, a wąskie gardło pozostanie. Ta uwaga jest skierowana do najwyższego kierownictwa. Wiele rad nadzorczych mierzy dziś skuteczność transformacji AI liczbą zakupionych licencji czy procentowym wzrostem szybkości wytwarzania oprogramowania. Konsekwencja jest taka: budżet w całości zasila zakup narzędzi, a te obszary, które realnie blokują dostarczanie rozwiązań (komórka ds. oceny transferu danych w ramach RODO, zespół ds. zgodności z wymogami KSC i Rekomendacji D KNF, inżynieria bezpieczeństwa, uzgadnianie i audyt), pozostają bez pieniędzy i ludzi. Efekt? Narzędzi przybywa, a tempo dostarczania wciąż kuleje. Żeby wyleczyć chorobę „wiemy, ale nie działamy”, trzeba zmienić te metryki u samego źródła. Dodaj wskaźniki takie jak: „jaki odsetek aplikacji objęto ścieżką zgodnościową”, „ile aplikacji cienia (shadow IT) udało się zredukować z N do M”, „ile czasu zajmuje przejście kluczowej aplikacji od prototypu do zgodnego z RODO/EU AI Act/KSC wdrożenia”. Gdy metryki się zmienią, budżet popłynie tam, gdzie faktycznie leży problem.
Samoocena (bądź wobec siebie szczery): Czy potrafisz podać liczbę aplikacji, które Twoi pracownicy zbudowali samodzielnie z użyciem AI? A ile z nich ma dostęp do danych o zamówieniach, numerach telefonów czy adresach? Czy sprawdziłeś, dokąd trafiają dane z domyślnie instalowanego w Waszych zespołach asystenta AI do kodowania? Czy wskaźniki, którymi mierzysz efekty AI, nagradzają „kupowanie narzędzi”, czy raczej „szybsze dostarczanie rozwiązań”? Jeśli choć na jedno z tych pytań nie znasz odpowiedzi, to ryzyko, o którym mowa w tym artykule, już u Was występuje.
Co dalej?
To jest piąty z osiemnastu artykułów w cyklu „Przemiany inżynierii oprogramowania w erze AI”. Przyjrzeliśmy się już temu, jak generatory aplikacji i AI-owe IDE zrównały z ziemią próg wejścia do „zrobienia aplikacji” — oraz dlaczego próg związany z dostępem do danych wcale za nimi nie podąża.
Następny artykuł (szósty) dotyczy kierunku, który coraz częściej staje się branżowym konsensusem: programowania sterowanego specyfikacją (Spec-Driven Development). Zastanowimy się, dlaczego GitHub Spec Kit, Claude Code, AWS Kiro i OpenAI AGENTS.md niezależnie od siebie zmierzają w tę samą stronę — „najpierw zapisz wymagania w dokumentacji, potem pozwól działać AI”. W poprzedniej sekcji pokazaliśmy, że kod generowany przez AI ma wyższą podatność na błędy niż ten pisany przez człowieka; programowanie sterowane specyfikacją to właśnie jedna z metod leczenia tej przypadłości: dopiero gdy rozmyte ustne wymagania zamienimy w sprawdzalną specyfikację, AI może być realnie kontrolowane.
O cyklu: W tej serii będziemy na bieżąco śledzić najnowsze zmiany w narzędziach do programowania wspieranych AI, strukturach organizacyjnych i paradygmatach inżynierii oprogramowania. Obserwuj serię, aby otrzymywać ciągłe aktualizacje.
Chcesz przełożyć te ustalenia na grunt swojej firmy?
Gdy generatory aplikacji trafiają do przedsiębiorstwa, do rozwiązania zwykle zostają konkretne pytania: które aplikacje i dane można oddać stronie biznesowej do samodzielnego generowania, które muszą pozostać pod kontrolą IT, do jakiego poziomu należy rozbudować istniejące procesy weryfikacji oraz jakimi wskaźnikami oceniać pilotaż.
Obecnie oferujemy trzy formy współpracy:
- Szkolenia wewnętrzne: w oparciu o realne projekty w Twojej firmie – wybór generatora aplikacji, określenie granic użycia, ścieżki zgodności i projekt mechanizmów zarządczych.
- Konsultacje specjalistyczne: skupione na konkretnej decyzji, np. „czy udostępnić biznesowi autoryzowany generator aplikacji” albo na ustaleniu priorytetów naprawczych po inwentaryzacji aplikacji cienia.
- Sesje dla kadry zarządzającej i wystąpienia branżowe: wokół narzędzi AI do programowania, zarządzania aplikacjami cienia, transformacji AI w przedsiębiorstwie i ładu organizacyjnego.
Artykuł dostarcza uniwersalnych ram. Konkretne wdrożenie wymaga jednak ponownego zaprojektowania z uwzględnieniem granic danych, wymogów regulacyjnych, dojrzałości inżynieryjnej i istniejących procesów dostarczania w danej firmie. Współpracę można nawiązać pod adresem coach@iaiuse.com.
Polecana lektura: Metodologia Znaku Firmowego v1.0 (Learn AI Slowly 187) – systematyczne omówienie 7-etapowych ram transformacji AI w przedsiębiorstwie.
O serii
„Zmiany w inżynierii oprogramowania w erze AI” to seria badawcza dla CIO, CDO, CTO i osób odpowiedzialnych za transformację cyfrową w telekomunikacji, finansach, przemyśle i e-commerce. Cykl liczy 18 części i koncentruje się na tym, jak narzędzia AI do programowania, generatory aplikacji oraz zarządzanie aplikacjami cienia wpływają na procesy dostarczania oprogramowania, strukturę organizacyjną, mechanizmy ładu i metryki zarządcze.
Ten artykuł to część serii, w ramach której na bieżąco śledzimy prace naukowe, materiały producentów i raporty branżowe. Nasza baza badawcza liczy już ponad 200 pozycji, a kluczowe tezy są opatrzone poziomem wiarygodności – staramy się wyraźnie oddzielać zweryfikowane fakty od deklaracji producentów, obserwacji branżowych i autorskich wniosków.
Mam za sobą blisko 8 lat pracy w doradztwie dla dużych przedsiębiorstw i analityce biznesowej. Pracowałem w IBM, gdzie uczestniczyłem w projektach dla sektora telekomunikacyjnego, finansowego, ubezpieczeniowego i produkcyjnego. Później działałem na pierwszej linii – przy produktach operatorskich, internetowych i wdrożeniach aplikacji opartych o AI – zajmując się analizą wymagań, projektowaniem produktów i koordynacją prac między zespołami.
Wnioski z tej serii – dotyczące doboru narzędzi, granic użycia generatorów aplikacji, projektowania ścieżek compliance i zarządzania organizacją – wynikają z tego praktycznego doświadczenia, a dodatkowo są krzyżowo weryfikowane z publicznymi badaniami i case studies z branży. Treści dotyczące konkretnych projektów zostały zanonimizowane; część scenariuszy branżowych to analiza typowych problemów, a ich podstawy znajdziesz w źródłach na końcu artykułu.
Za tym profilem stoi tak naprawdę mały zespół – ja oraz 1–2 osoby, z którymi długofalowo współpracuję. Każde z nas odpowiada za inny obszar: badania nad narzędziami AI do programowania, case studies z zakresu ładu organizacyjnego oraz pracę coachingową. Większość projektów, o których piszemy, że „przeprowadziliśmy firmy przez trudne tematy”, to projekty, które wspólnie realizowaliśmy. Nadal nie ujawniamy nazw klientów ani szczegółów dotyczących granic compliance – anonimowość zostawiamy też jako przestrzeń dla przyszłych współpracowników.
Źródła (zweryfikowane, z poziomem wiarygodności i wskazaniem perspektywy)
StackBlitz CEO Eric Simons (LinkedIn, koniec roku fiskalnego 2026). Bolt.new jest używany przez trzy czwarte firm z listy Fortune 500, a przychód ARR w segmencie enterprise wzrósł 10-krotnie rok do roku. Bezpośrednia deklaracja producenta (perspektywa dostawcy). https://www.linkedin.com/posts/eric-simons-a464a664-a-growth-update-as-we-close-out-our-fiscal-activity-7425263313049026560-5tdV
Sacra / Growth Unhinged (2025). Śledzenie wzrostu ARR Bolt.new (ok. 5 miesięcy do 40 mln USD ARR, ok. 5 mln użytkowników, drugi najszybszy wzrost w historii po ChatGPT). Badania pierwotne / monitoring rynku. https://sacra.com/c/bolt-new/ 、https://www.growthunhinged.com/p/boltnew-growth-journey
Taskade (2026-03) oraz Business Insider: StackBlitz w styczniu 2025 r. w rundzie B pozyskał 105,5 mln USD przy wycenie ok. 700 mln USD; Bolt V2 uruchomiono na Bolt Cloud. Połączone raporty branżowe.
Forbes / Rashi Shrivastava (2026-06-05): Lovable prowadzi nową rundę finansowania przy wycenie 12 mld USD; ARR przekroczyła 500 mln USD (potwierdzone przez TechCrunch 2026-06-09). Vrchní úroveň žurnalistiky. https://www.forbes.com/sites/rashishrivastava/2026/06/05/ai-coding-startup-lovable-in-talks-to-raise-funding-at-a-12-billion-valuation
CNBC / Bloomberg (2025-12) / TechCrunch (2025-11): Lovable runda B 330 mln USD przy wycenie 6,6 mld USD; runda A 200 mln USD przy wycenie 1,8 mld USD. Zapiski z branży.
ARR.club (2026-07). Krzywa wzrostu ARR dla Lovable: $17M (2025-02) → $100M (2025-07) → $200M (2025-11) → $400M (2026-02) → $500M (2026-06); klienci korporacyjni obejmują Workday, Asana, NVIDIA. Monitoring branżowy.
Vercel (2026-02-03, oficjalny blog “Introducing the new v0”). v0 zmienia nazwę z v0.dev na v0.app, ewoluując z generatora komponentów UI w pełnoprawny generator aplikacji full-stack (sandbox runtime + GitHub + integracje Snowflake/AWS). Oficjalne stanowisko producenta. https://vercel.com/blog/introducing-the-new-v0
Taskade (2026-03) / Vercel. v0 w marcu 2026: ponad 6M użytkowników, ok. 80 tys. aktywnych zespołów miesięcznie, szacunkowe ARR ok. $42M. Szacunki zagregowane z analiz branżowych.
Replit (oficjalny dziennik zmian z 2026-03-13 + wpis na blogu „What’s changed from Agent 3 to Agent 4”). Agent 4 został wydany 2026-03-11; Infinite Design Canvas; model współpracy fork-and-merge zastąpiono wielowątkowymi zadaniami w ramach jednego projektu z automatycznym scalaniem konfliktów (90% rozwiązywanych automatycznie). Informacje z pierwszej ręki od producenta. https://docs.replit.com/updates/2026/03/13/changelog
AlphaSignal (2026). Szczegółowe omówienie automatycznego rozwiązywania 90% konfliktów scalania w Replit Agent 4. Raport branżowy. https://alphasignal.ai/news/replit-s-agent-4-resolves-90-of-team-merge-conflicts-automatically
Atal Upadhyay (2026-03-19). W tym samym tygodniu Replit ogłosiło rundę D o wartości 400 mln USD, wyceniając firmę na 9 mld USD (trzykrotny wzrost w pół roku). Na podstawie doniesień branżowych. https://atalupadhyay.wordpress.com/2026/03/19/replit-agent-4-replit-just-changed-everything
Cybernews (aktualizacja 2026-08-01) / The Register (2025-07-28) / segmentationf4u1t (badania źródłowe na GitHubie). Trae, nawet po wyłączeniu telemetrii, nadal przesyła do serwerów ByteDance dane dotyczące sprzętu, identyfikatorów urządzeń i aktywności w projekcie – pojedyncza partia danych może osiągnąć 53 606 bajtów; 500+ wywołań w ciągu 7 minut to około 26 MB; ByteDance oficjalnie przyznaje, że przełącznik kontroluje jedynie część frameworka VS Code; tryb prywatności (Privacy Mode) ma zostać wydany około sierpnia 2026; w lutym 2026 Trae zrezygnował z opcji „forever free” na rzecz paywalla opartego na tokenach. Badania z pierwszej ręki + raporty branżowe + oficjalne oświadczenia producenta. https://cybernews.com/security/bytedance-ai-coding-tool-trae-data-collection 、https://www.theregister.com/software/2025/07/28/bytedance-ai-ide-trae-telemetry-continues-even-after-opt-out/ 、https://github.com/segmentationf4u1t/trae_telemetry_research
OpenAI Tools Hub / Jim Liu (2026-05-18). Trae w 12 miesięcy zarejestrował 6 mln użytkowników, 1,6 mln aktywnych miesięcznie i łącznie wygenerował 100 mld linii kodu; w lutym wprowadzono paywall na tokeny, kończąc z obietnicą „forever free”. Analiza zbiorcza (perspektywa analityka).
Gartner (cytowane za Process Excellence Network, 2025-08-27 / DevOpsDigest / UC Today). Do końca 2026 r. 40% aplikacji korporacyjnych będzie zawierać wyspecjalizowane agenty AI (w 2025 r. mniej niż 5%); do 2035 r. agentic AI będzie stanowić około 30% rynku oprogramowania dla przedsiębiorstw (450 mld USD). Oficjalny dokument prognostyczny. https://www.processexcellencenetwork.com/ai/news/gartner-40-percent-of-enterprise-apps-will-feature-task-specific-ai-agents-by-2026
Gartner (cytowane za RapidClaw / Hendricks.ai / Arion Research, 2025–2026). Od Q1 2024 do Q2 2025 liczba zapytań dotyczących systemów multi-agent wzrosła o 1445% — to najszybciej rozwijający się temat w doradztwie AI w Gartnerze. Badania pierwszego rzędu / dane wtórne.
Microsoft (podsumowanie roku fiskalnego FY26, 2026-07-28). EY wdrożyło Copilota dla 150 000 pracowników, uzyskując 15% wzrost produktywności, i rozszerza wdrożenie na 400 000 pracowników na całym świecie; Atos wdrożył Copilota dla 56 000 pracowników w 54 krajach i zarządza 19 000 agentami AI z jednego panelu kontrolnego. Perspektywa producenta + deklaracje klientów (producent + integrator). https://blogs.microsoft.com/blog/2026/07/28/looking-back-on-microsofts-fy26-from-ai-experimentation-to-frontier-transformation
Atos Group (2026-06-09, komunikat prasowy). Atos rozszerza współpracę z Microsoft, wdrażając Copilot E7 (Frontier Suite) dla 56 000 pracowników, ujednolicając panele zarządzania Entra/Defender/Intune/Purview/Agent 365 i operując 19 000 agentami. Oficjalne stanowisko firmy. https://www.atosgroup.com/en/press/atos-group-and-microsoft-expand-strategic-collaboration-scale-secure-agentic-ai-across-atos
UpGuard / Cybersecurity Dive (2025). Ponad 80% pracowników i blisko 90% osób odpowiedzialnych za bezpieczeństwo korzysta z niezatwierdzonych narzędzi AI; około połowa pracowników wklejała do nich poufne dane (podobne wnioski płyną z raportów Mimecast i Teramind, co wzajemnie się potwierdza). Badanie pierwotne + raport branżowy. https://www.cybersecuritydive.com/news/shadow-ai-employee-trust-upguard/805280/
Gartner (cytowane przez The Hacker News, maj 2026). 69% organizacji podejrzewa lub ma potwierdzenie, że pracownicy używają zabronionych narzędzi AI; tylko 37% posiada zasady korzystania z AI. Przekaz za raportem branżowym.
CodeRabbit (wspólny webinar z DORA w lutym 2026 + niezależny test porównawczy Kunala Ganglaniego w czerwcu 2026). Liczba problemów w kodzie generowanym przez AI (w tym błędów logicznych i funkcjonalnych) jest około 1,7 razy większa niż w kodzie pisanym tradycyjnie przez człowieka; CodeRabbit to najczęściej instalowane narzędzie do przeglądu kodu przez AI na GitHub i GitLab, z ponad 15 000 płacących klientów i 6 milionami przeskanowanych repozytoriów; publiczne poparcie ze strony CEO NVIDIA, Jensena Huanga. Badania pierwszego rzędu / dane producenta / porównanie branżowe. https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
Veracode (2025 GenAI Code Security Report). Około 45% próbek kodu generowanego przez AI zawierało luki z listy OWASP Top 10 (w przypadku kodu w Javie odsetek porażek przekraczał 70%). Badanie oryginalne. https://www.veracode.com/blog/genai-code-security-report/ (Uwaga: we wcześniejszej wersji tekstu błędnie interpretowano te 45% jako wskaźnik adopcji “shadow AI” — to pomyłka, którą tu prostujemy: 45% to odsetek wadliwego kodu generowanego przez AI, a nie wskaźnik wykorzystania narzędzi; ten drugi, według raportu UpGuard, wynosi ponad 80%).
arXiv:2510.26103. Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories. (Empiryczne badanie oryginalne dotyczące luk w zabezpieczeniach kodu generowanego przez AI.)
Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC) (Dz.U. 2018 poz. 1560, z późn. zm.). Polska ustawa implementująca dyrektywę NIS, tworząca ramy dla operatorów usług kluczowych i dostawców usług cyfrowych; przewiduje obowiązek zgłaszania incydentów do właściwego CSIRT (CSIRT NASK, CSIRT MON, CSIRT ABW/GCSIRT). Pierwszorzędne źródło prawne.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO). Ogólne rozporządzenie o ochronie danych – art. 5 (zasady przetwarzania), art. 6/9 (podstawy prawne), art. 32 (bezpieczeństwo przetwarzania), art. 33 (zgłaszanie naruszeń – 72 h), art. 35 (DPIA), art. 44–50 (transfer danych do państw trzecich), art. 83 (kary administracyjne do 4% obrotu lub 20 mln EUR). Pierwszorzędne źródło prawne.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (EU AI Act). Rozporządzenie w sprawie sztucznej inteligencji – kluczowe: art. 5 (zakazane systemy), art. 6–15 (systemy wysokiego ryzyka, ocena zgodności), art. 16–29 (obowiązki dostawców i użytkowników), art. 71 (unijna baza danych AI), art. 99 (kary do 35 mln EUR / 7% obrotu). Obowiązuje od 1 sierpnia 2024 r., pełna stosowalność od 2 sierpnia 2026 r. Pierwszorzędne źródło prawne.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA). Rozporządzenie o operacyjnej odporności cyfrowej sektora finansowego – obowiązuje od 17 stycznia 2025 r. Pierwszorzędne źródło prawne.
KNF (Komisja Nadzoru Finansowego) – Rekomendacja D (2013, nowelizacja 2023). Rekomendacja dotycząca zarządzania ryzykiem technologicznym w bankach. Wymaga zarządzania zmianami IT, ciągłością działania i outsourcingiem IT. Źródło: KNF.
KNF – Rekomendacja P (2014, nowelizacja 2018, 2023). Rekomendacja dotycząca zarządzania ryzykiem w ubezpieczeniach (w tym ryzykiem IT). Źródło: KNF.
Ustawa z dnia 10 maja 2018 r. o ochronie danych osobowych (Dz.U. 2018 poz. 1000, z późn. zm.). Polska ustawa uzupełniająca RODO – w szczególności określa KNF jako organ nadzorczy dla sektora bankowego i ubezpieczeniowego. Pierwszorzędne źródło prawne.
UODO – decyzja ws. Virgin Mobile Polska (2024). UODO nałożyło karę 1,9 mln zł za brak odpowiednich zabezpieczeń transferu danych do USA. Sygnatura: DKN.5112.1.2020. Źródło: uodo.gov.pl. Bezpośrednia decyzja organu nadzorczego.
UODO – decyzja ws. Morele.net (2023). UODO nałożyło karę 2,8 mln zł za niewystarczające zabezpieczenia danych osobowych. Źródło: uodo.gov.pl. Bezpośrednia decyzja organu nadzorczego.
CSIRT NASK (NASK – Naukowa i Akademicka Sieć Komputerowa). Krajowy Zespół Reagowania na Incydenty Bezpieczeństwa Komputerowego – pełni w Polsce rolę CSIRT dla sektora telekomunikacyjnego i infrastruktury cyfrowej. Źródło: cert.pl.
Uwaga dotycząca danych: wszystkie dane ilościowe w tym artykule mają podane źródła; nieliczne liczby, dla których producenci nie opublikowali oficjalnych danych lub które nie zostały niezależnie zweryfikowane (np. rzekoma runda finansowania Lovable w wysokości $12B wciąż w fazie negocjacji, dokładna data inwentaryzacji 19 000 agentów Atos), zostały odpowiednio oznaczone. Przykłady klientów zostały zanonimizowane (zespół operacyjny e-commerce, centrum marketingowe regionalnego oddziału operatora itp.), a ich źródłem są rzeczywiste scenariusze zaobserwowane podczas mojego udziału w projektach wdrożeniowych — nie odnoszą się do konkretnych przedsiębiorstw. Wymogi regulacyjne (transfer danych w ramach RODO, klasyfikacja bezpieczeństwa w ramach KSC, ocena zgodności z EU AI Act, KNF Rekomendacja D, audyt) opierają się na obowiązujących przepisach polskich i unijnych; ich konkretne zastosowanie zależy od charakteru działalności i typu danych — przed wdrożeniem zalecamy konsultację z działem prawnym lub compliance oraz z UODO (Urząd Ochrony Danych Osobowych).
[^1]: Międzynarodowy transfer danych osobowych w ramach EOG i poza niego reguluje RODO (Rozporządzenie 2016/679) – w szczególności art. 44–50 (zasady przekazywania do państw trzecich). W Polsce nadzór sprawuje UODO (Urząd Ochrony Danych Osobowych), który w 2024 r. nałożył na Virgin Mobile Polska karę 1,9 mln zł (decyzja DKN.5112.1.2020). Mechanizmy transferu: Standardowe Klauzule Umowne (SCC) zatwierdzone przez Komisję Europejską (decyzja 2021/914), wiążące reguły korporacyjne (BCR), decyzje adekwatności (obecnie m.in. dla Korei Płd., Kanady, Japonii, NZ; USA wymaga dodatkowo certyfikacji Data Privacy Framework). Konieczne jest przeprowadzenie oceny ryzyka transferu (TIA) i ewentualne wdrożenie środków uzupełniających (np. szyfrowanie end-to-end, pseudonimizacja).
[^2]: Polskim odpowiednikiem systemu klasyfikacji ochrony jest Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC) (Dz.U. 2018 poz. 1560, z późn. zm.), implementująca dyrektywę NIS (i przygotowująca implementację NIS2 do 17 października 2024 r.). Dla operatorów usług kluczowych (energetyka, transport, bankowość, infrastruktura rynków finansowych, ochrona zdrowia, zaopatrzenie w wodę, infrastruktura cyfrowa) KSC nakłada obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych, zgłaszania incydentów do właściwego CSIRT (CSIRT NASK dla telco/digital; CSIRT MON dla sektora obronnego; CSIRT ABW/Agencja Bezpieczeństwa Wewnętrznego dla infrastruktury krytycznej) i poddania się audytowi. Praktycznym standardem branżowym jest ISO/IEC 27001 (akredytowany certyfikat) oraz normy z serii ISO 27002.
[^3]: W UE obowiązuje Rozporządzenie 2024/1689 w sprawie sztucznej inteligencji (EU AI Act) – kluczowe daty: wejście w życie 1 sierpnia 2024 r., zakaz stosowania systemów niedozwolonych od 2 lutego 2025 r., obowiązki dla systemów wysokiego ryzyka (załącznik III) od 2 sierpnia 2026 r., pełna stosowalność od 2 sierpnia 2027 r. Systemy AI wysokiego ryzyka muszą przejść ocenę zgodności (conformity assessment) zgodnie z rozdziałem III, prowadzić dokumentację techniczną (załącznik IV), wdrożyć system zarządzania ryzykiem (art. 9), zarządzanie danymi (art. 10), rejestrować się w unijnej bazie danych AI (art. 71). W Polsce organem nadzorczym jest UODO (dla wymiaru ochrony danych) oraz Ministerstwo Cyfryzacji (koordynacja polityki). Kary: do 35 mln EUR lub 7% rocznego obrotu (zakazane systemy), do 15 mln EUR lub 3% (wysokie ryzyko).
[^4]: Ogólne ramy zarządzania zmianami: ITIL 4 Change Enablement Practice. Dla sektora bankowego w Polsce: Rekomendacja D KNF dotycząca zarządzania ryzykiem technologicznym w bankach (wydanie 2013, nowelizacja 2023) – szczegółowo opisuje zarządzanie zmianami, ciągłością działania i outsourcingiem. Dla sektora ubezpieczeniowego: Rekomendacja P KNF (2014, nowelizacje 2018 i 2023). Dodatkowo Ustawa o obrocie instrumentami finansowymi (implementująca MiFID II/MiFIR) oraz Rozporządzenie DORA (Rozporządzenie 2022/2554 o operacyjnej odporności cyfrowej sektora finansowego, obowiązuje od 17 stycznia 2025 r.) nakładają obowiązki raportowania incydentów ICT do właściwych organów.
[^5]: Przechowywanie zapisów transakcji w e-commerce: art. 19aa Ustawy o prawach konsumenta (platformy mają obowiązek przechowywania dowodów transakcji przez 2 lata) oraz art. 7 Ustawy o świadczeniu usług drogą elektroniczną (obowiązek przechowywania informacji o transakcjach). W kontekście AML: Ustawa z dnia 1 marca 2018 r. o przeciwdziałaniu praniu pieniędzy oraz finansowaniu terroryzmu wymaga przechowywania dokumentacji transakcyjnej przez 5 lat od dnia transakcji. Dzienniki audytowe: zgodnie z wymogami RODO art. 5(1)(e) (minimalizacja retencji) oraz art. 32 (bezpieczeństwo przetwarzania) i wymogami KSC/ISO 27001 – kluczowe systemy finansowe powinny przechowywać logi co najmniej 6 miesięcy, ale w praktyce sektor bankowy w Polsce przechowuje logi transakcyjne przez 5 lat, logi bezpieczeństwa przez 12 miesięcy (minimum).










![[Przesunięcie punktu wąskiego gardła] Gdy kod jest praktycznie darmowy, gdzie przesunęły się ograniczenia inżynierii oprogramowania? Transformacja inżynierii oprogramowania w erze AI — Ucz się powoli o AI 173](https://cdn.iaiuse.com/img/2026/08/10/17890de43e9092b4002f1d397abf2dce.webp)
