Szanowny Czytelniku,
Szacunki branżowe konsekwentnie wskazują, że odsetek porażek projektów AI przekracza osiemdziesiąt procent — to około dwukrotnie więcej niż w przypadku standardowych projektów IT. W sierpniu 2024 roku organizacja RAND Corporation zbadała przyczyny tego stanu rzeczy, przeprowadzając ustrukturyzowane wywiady z sześćdziesięcioma pięcioma inżynierami i analitykami danych (data scientists). Zidentyfikowano pięć głównych przyczyn: błędy w komunikacji dotyczące celu projektu, nieodpowiednie dane, niewystarczającą infrastrukturę do wykonania deploymentu gotowych modeli, brak planowania integracji oraz brak odpowiedniego governance. W marcu 2026 roku raport Stanford Enterprise AI Playbook przeanalizował pięćdziesiąt jeden udanych wdrożeń w czterdziestu jeden organizacjach i dziewięciu branżach. Wniosek: absolutna większość porażek wynika z czynników organizacyjnych — nieprzygotowania zespołów, braku governance i braku zaangażowania zarządu — a nie z jakości samego modelu.
Oba te badania prowadzą do tego samego wniosku: AI działa, ale organizacja wokół niego — nie.
To wydanie dotyczy konkretnego wariantu tej porażki: co się dzieje, gdy rozwiązania AI budowane z myślą o czystych środowiskach opartych na API zderzają się z infrastrukturą korporacyjną starszą niż pojęcie API. To pułapka brownfield.
Iluzja greenfield#
Każde demo dostawcy AI działa na czystych danych, nowoczesnych API i nowej bazie danych. Proof of concept się udaje, ponieważ środowisko testowe zostało do niego specjalnie przygotowane. Następnie projekt trafia na produkcję i zespół odkrywa, jak naprawdę wygląda infrastruktura w organizacji.
Przeciętna duża korporacja utrzymuje setki oddzielnych aplikacji, z czego około dwie trzecie nie jest ze sobą zintegrowanych. Z szacunków Deloitte wynika, że pięćdziesiąt siedem procent przeciętnego budżetu IT idzie na utrzymanie obecnych operacji. Szesnaście procent trafia na innowacje.
Główne platformy bankowe w wielu dużych instytucjach mają od dwudziestu do trzydziestu lat. Na całym świecie w środowiskach produkcyjnych nadal działa dwieście czterdzieści miliardów linii kodu COBOL, przetwarzając dziewięćdziesiąt pięć procent transakcji z bankomatów i osiemdziesiąt procent transakcji realizowanych osobiście. Systemy realizacji produkcji, platformy administracji polisami ubezpieczeniowymi oraz rdzenie systemów ERP działają w przeważającej większości w modelu on-prem i pochodzą z epoki przed upowszechnieniem się API. To właśnie do takiej infrastruktury sprzedawane są produkty AI.
Dostawca zakłada obecność API. Organizacja dysponuje plikiem batch przesyłanym w nocy przez SFTP. Luka między tymi dwiema rzeczywistościami to miejsce, w którym upadają projekty AI.
Podatek integracyjny#
Planując budżet na AI, organizacje wyceniają samą sztuczną inteligencję: model, koszty wnioskowania i licencję platformy. W praktyce pokrywa to od dwudziestu do trzydziestu procent całkowitych kosztów. Pozostałe siedemdziesiąt do osiemdziesięciu procent pozostaje w ukryciu. Należą do nich: przygotowanie danych, inżynieria integracji, custom development niezbędny do połączenia modelu z istniejącymi systemami, testowanie na rzeczywistych danych produkcyjnych, change management, szkolenia oraz bieżące utrzymanie.
Samo przygotowanie danych pochłania do czterdziestu pięciu procent całkowitego nakładu pracy w projekcie AI. Badanie Deloitte wykazało, że siedemdziesiąt procent organizacji doświadczyło przekroczenia budżetu w projektach AI z powodu nieprzewidzianych trudności.
Wzorzec jest spójny: model to najtańsza część projektu. Integracja z systemami legacy jest najdroższa, a jednocześnie rzadko uwzględnia się ją w pierwotnym business case. To podatek integracyjny — i to on tłumaczy, dlaczego pilotaż wyceniany na 200–250 tys. zł zamienia się w produkcyjny deployment kosztujący 2 mln zł, nie dostarczając przy tym oczekiwanej wartości.
Luka kompetencyjna#
Sześćdziesiąt procent liderów AI przebadanych przez Deloitte w 2026 roku wskazało integrację z systemami legacy jako główne wyzwanie przy wdrażaniu sztucznej inteligencji. Z kolei siedemdziesiąt procent organizacji w ankiecie Kyndryl przyznało, że ma trudności ze znalezieniem kompetencji potrzebnych do modernizacji systemów mainframe. To nie są te same braki kadrowe. To dwa różne deficyty spotykające się w środku — tam, gdzie nie ma nikogo.
Z jednej strony mamy inżynierów ML (ML engineers), którzy znają język Python, modele transformatorowe, API w architekturze chmurowej i nowoczesne stosy danych. Z drugiej: architektów korporacyjnych i inżynierów mainframe, którzy znają COBOL, SAP ABAP, przetwarzanie batch oraz nieudokumentowaną logikę utrzymującą przy życiu trzydziestoletnie systemy.
Według danych IBM, średni wiek programisty COBOL wynosi pięćdziesiąt osiem lat. Około dziesięć procent z nich przechodzi na emeryturę każdego roku. Szacuje się, że osiemdziesiąt cztery tysiące stanowisk związanych z mainframe pozostaje nieobsadzonych. W Stanach Zjednoczonych zostało zaledwie około dwudziestu czterech tysięcy programistów COBOL. Ludzie rozumiejący infrastrukturę legacy odchodzą z rynku pracy.
Rola, której najbardziej potrzebują projekty AI — osoba rozumiejąca obie strony na tyle dobrze, by zaprojektować integrację — praktycznie nie istnieje jako zdefiniowane stanowisko. Niektóre organizacje próbowały rozwiązać ten problem za pomocą „tłumaczy”: osób osadzonych między zespołami analitycznymi a operacjami biznesowymi, które miały dbać o to, by modele odzwierciedlały potrzeby biznesowe. Brytyjski ubezpieczyciel Aviva wdrożył ten model wprost. Jednak w większości firm zespół ML buduje model, a zespół architektury korporacyjnej buduje integrację. Obie te rozmowy toczą się oddzielnie. Ta luka rozbija projekty.
Jak odnosić sukcesy w środowisku brownfield#
Firma Aviva wdrożyła ponad osiemdziesiąt modeli AI i ML w operacjach likwidacji szkód, nadbudowując je na istniejących systemach polisowych i szkodowych typu legacy. Nie wymienili rdzenia — użyli API i mikrousług jako warstwy adaptacyjnej, co pozwoliło modelom AI na jednoczesne odpytywanie istniejących systemów polisowych, historycznych danych o szkodach, usług podmiotów trzecich i baz danych o oszustwach. Efekt: czas oceny odpowiedzialności ubezpieczeniowej skrócony o dwadzieścia trzy dni, dokładność kierowania szkód wyższa o trzydzieści procent, liczba skarg mniejsza o sześćdziesiąt pięć procent, a tylko w 2024 roku zaoszczędzono 300 mln zł. McKinsey udokumentował ten przypadek w ramach swojej serii „Rewired in Action”.
Commonwealth Bank of Australia każdego dnia przetwarza pięćdziesiąt pięć milionów decyzji sterowanych przez AI, używając do tego ponad dwóch tysięcy modeli i stu pięćdziesięciu siedmiu miliardów punktów danych. Przenieśli sześćdziesiąt jeden tysięcy pipeline’ów do AWS i zmigrowali swój główny system bankowy oparty na rozwiązaniu SAP — był to projekt trwający osiemnaście miesięcy. Kluczowe jest jednak to, co zrobili podczas migracji, a nie po niej: wdrożyli AI w środowisku legacy, jednocześnie je modernizując. Nie czekali na zakończenie transformacji. Ich wewnętrzny program AI, Project Coral, skrócił czas oceny aplikacji z sześciu tygodni do mniej niż jednej godziny, a cykle modernizacji z szesnastu tygodni do jednego tygodnia. Straty wynikające z oszustw spadły o pięćdziesiąt procent. Liczba skarg klientów zmalała o trzydzieści procent.
Wzorzec obserwowany w obu tych przypadkach oraz u moich klientów jest jasny: podejście brownfield działa, gdy organizacja traktuje integrację jako główne wyzwanie inżynieryjne, a nie drugorzędny krok następujący po zbudowaniu modelu. Podejście, które sprawdza się na produkcji, ma charakter modułowy i przyrostowy: systemy legacy obudowuje się fasadami API, a AI wdraża jako overlay, który odczytuje dane z systemów legacy, ale zapisuje je w nowoczesnej warstwie danych. Kolejne use case uruchamia się pojedynczo, zamiast próbować wdrażać całe portfele projektów na raz.
Wzorce architektoniczne#
W obszarze integracji AI w środowiskach brownfield wyłaniają się trzy główne wzorce.
Strangler Fig. Nazwa pochodzi od tropikalnego figowca, który obrasta inne drzewo, aż ostatecznie je zastąpi. W inżynierii oprogramowania oznacza to kierowanie żądań przez fasadę, która stopniowo przenosi ruch z usług legacy do nowoczesnych odpowiedników. W połączeniu ze strumieniowaniem zdarzeń i techniką change data capture organizacje mogą w czasie rzeczywistym synchronizować bazy danych legacy z nowoczesnymi magazynami. Migracja przyrostowa znacznie rzadziej kończy się niepowodzeniem niż przepisywanie systemów w modelu „Big Bang”. Narzędzia generatywnej AI są obecnie używane do analizy logiki kodu legacy i przyspieszania tworzenia zastępczych mikrousług — to sprawia, że podejście Strangler Fig staje się szybsze.
Anti-Corruption Layer. Warstwa translacyjna między nowymi usługami AI a systemami legacy. Jej zadaniem jest izolacja modelu dziedzinowego AI od długu technologicznego starszych rozwiązań. System AI widzi czysty interfejs, a nie złożoność starego systemu. Z kolei system legacy otrzymuje standardowe żądania, a nie skomplikowany model dziedzinowy AI.
Overlay. Wdrożenie AI jako warstwy, która odczytuje dane z systemów legacy (przez change data capture lub wsadowo — batch), ale zapisuje je w nowoczesnej warstwie danych. System legacy pozostaje źródłem prawdy (system of record). AI działa na równoległej płaszczyźnie. Tak w praktyce wygląda wdrażanie modułowe: jest przyrostowe, bezinwazyjne i odwracalne.
Wszystkie trzy wzorce łączy jedna zasada: nie należy wymieniać systemu legacy. Należy budować wokół niego.
AI jako narzędzie brownfield#
Z pułapką brownfield wiąże się pewien paradoks. Sztuczna inteligencja to z jednej strony technologia najtrudniejsza do zintegrowania z infrastrukturą legacy, a z drugiej — najpotężniejsze dostępne narzędzie do jej zrozumienia i zarządzania nią.
Najbardziej bezpośrednim zastosowaniem jest analiza starszego kodu. Duże modele językowe (LLM) potrafią czytać i tłumaczyć nieudokumentowany kod w językach COBOL, ABAP czy PL/SQL — może nie bezbłędnie, ale wystarczająco dobrze, by umożliwić zaplanowanie integracji w systemach, które od dziesięcioleci pozbawione były dokumentacji. Gdy na emeryturę odszedł ostatni inżynier rozumiejący logikę przetwarzania batch, kod stał się czarną skrzynką. AI potrafi ją otworzyć.
Poza samym zrozumieniem kodu pojawia się bardziej systemowa korzyść: trwałe uchwycenie wiedzy. Jednym z fundamentalnych problemów środowisk brownfield jest to, że wiedza instytucjonalna o systemach legacy znajduje się w głowach pracowników, a nie w dokumentacji. Agenty AI potrafią zbudować i utrzymać trwałą warstwę wiedzy równolegle do bazy kodu: mapując zależności, rejestrując decyzje i dokumentując punkty integracji w miarę ich odkrywania. Kiedy pracownik odchodzi, wiedza zostaje. Każdy projekt dotykający infrastruktury legacy rozbudowuje tę warstwę wiedzy, zamiast zaczynać od zera. Wiedza się kumuluje.
Project Coral w banku CBA pokazuje to na masową skalę. Cykle modernizacji skrócono tam z szesnastu tygodni do zaledwie jednego, wykorzystując agenty AI do analizy kodu i generowania jego zamienników. Mechanizmem umożliwiającym ten skok wydajności jest podejście przyrostowe: każda kolejna migracja poprawia to, w jaki sposób systemy rozumieją całą architekturę. To przyspiesza kolejne etapy prac.
Jest jeszcze jedna korzyść, którą większość organizacji pomija: gdy AI wspiera modernizację kodu, potrafi w locie generować dokumentację zgodną z wymogami compliance — ścieżki audytu, rejestry zmian, mapy zależności. Dowody zgodności powstają jako produkt uboczny, a nie w wyniku wysiłków na samym końcu.
Skok prędkości wynikający ze wsparcia AI w środowiskach brownfield nie bierze się z szybszego generowania kodu. Wynika z mniejszej liczby poprawek (rework), mniejszej liczby nieporozumień oraz wiedzy, która akumuluje się w projektach zamiast ginąć pomiędzy nimi. To zadziała tylko wtedy, gdy organizacja potraktuje to jako celowy strumień prac z własnymi narzędziami i odpowiednim governance, a nie jako eksperyment prowadzony na uboczu.
O co zapytać dostawcę#
Governance ma tu istotną rolę. Większość frameworków governance dla AI projektowano z myślą o podejściu greenfield — czystych systemach, w których udokumentowano przepływy danych, jasno przypisano odpowiedzialność i zastosowano architekturę opartą na API. Aplikowanie tych samych zasad do środowisk brownfield skutkuje teatrem nadzoru: odhaczaniem wymogów compliance dla systemów, których nikt w pełni nie rozumie.
Przed podpisaniem umowy z dostawcą AI warto zadać cztery pytania demaskujące ryzyko integracyjne:
Jakie założenia przyjmuje wasz produkt wobec infrastruktury danych, z którą ma się łączyć? Jeśli odpowiedź wspomina o API, nowoczesnych jeziorach danych (data lakes) lub architekturze cloud-native, a główne systemy w Twojej firmie nie spełniają tych kryteriów, masz do czynienia z luką, która okaże się najdroższym elementem projektu.
Jakich prac integracyjnych wymaga wdrożenie i kto je wykona? Jeśli dostawca odpowiada: „wasz zespół”, a w Twoim zespole nie ma ludzi rozumiejących jednocześnie infrastrukturę legacy i stos technologiczny AI, projekt zatrzyma się na etapie integracji.
Czy ten produkt był instalowany na infrastrukturze starszej niż dziesięć lat? Jeśli referencyjni klienci dostawcy korzystają wyłącznie z nowoczesnych rozwiązań chmurowych, oznacza to, że produkt nie był testowany w środowisku takim jak Twoje.
Jaki jest całkowity koszt projektu z uwzględnieniem integracji — a nie tylko koszt licencji? Jeżeli dostawca nie jest w stanie udzielić takiej odpowiedzi, oznacza to, że nie realizował dotąd deploymentu typu brownfield.
Z rynku#
Dyrektorzy IT między nową warstwą AI a platformami legacy
23 kwietnia serwis InformationWeek poinformował, że przedsiębiorstwa coraz częściej wdrażają agenty AI (workflow agents) bezpośrednio nad systemami legacy, zamiast je zastępować. Wzorzec ten opiera się na tym, że startupy AI automatyzują procesy pojedynczo, łącząc się z systemami CRM, ERP czy systemami compliance przez API, do obsługi których te starsze platformy nigdy nie były projektowane. Większość organizacji „nie przetestowała obciążeniowo sytuacji, w której zależność od AI nagle znika”. W przypadku polskich banków i firm ubezpieczeniowych podlegających nadzorowi KNF, ten model operacyjny tworzy lukę w dowodzeniu zgodności w świetle wymogów EU AI Act Article 26. Rynek jeszcze nie nazywa tego problemu wprost: wdrożenie warstwy AI nad rdzennym systemem bankowym, którego w pełni się nie kontroluje, na infrastrukturze pozbawionej udokumentowanych przepływów danych, nie spełnia wymogów tego artykułu dotyczących monitorowania zgodnie z instrukcją użytkowania (InformationWeek, 23 kwietnia 2026 r.).
Migracja systemów legacy przy wsparciu AI staje się gotowym produktem
24 kwietnia firma Syntax wypuściła na rynek pakiet AI CodeGenie Suite. Rozwiązanie to celuje w przedsiębiorstwa korzystające z SAP Apparel and Footwear Solution przed wygaśnięciem wsparcia, które planowane jest na 2027 rok. Narzędzie analizuje stary kod SAP, wyodrębnia logikę biznesową i generuje zamienniki w S/4HANA wraz z dokumentacją i skryptami testowymi. Pierwsze udokumentowane wdrożenie: firma Peerless Clothing w zaledwie kilka dni — a nie miesięcy — zmigrowała złożoną funkcję available-to-promise, oszczędzając szacunkowo milion złotych. Pytanie, na które start produktu nie daje odpowiedzi, brzmi: kiedy to AI generuje kod migracyjny, do kogo należy ścieżka audytu? Choć system SAP AFS nie jest powszechnie stosowany w polskim przemyśle, to dylemat ten dotyczy obecnie każdej realizowanej modernizacji starszych systemów ERP (TechEdge AI, 24 kwietnia 2026 r.).
Pytania do zarządu#
Jaki procent głównych systemów operacyjnych w Twojej organizacji — tych, które przetwarzają transakcje, zarządzają polisami lub obsługują klientów — został zbudowany przed 2015 rokiem? W przypadku każdego z tych systemów: kto w firmie rozumie zarówno architekturę legacy, jak i to, czego wymagałaby integracja AI?
Kiedy zespół AI prezentuje business case, czy podane koszty obejmują integrację z istniejącymi systemami (przygotowanie danych, budowę API, testowanie z wykorzystaniem danych produkcyjnych, change management), czy uwzględniają jedynie model i licencję platformy?
Gdybyś zapytał swojego dostawcę AI już dziś: „czy ten produkt był uruchamiany na infrastrukturze starszej niż dziesięć lat?”, jaka padłaby odpowiedź? I co ta odpowiedź oznaczałaby dla Twojego harmonogramu deploymentu i budżetu?
Czy w Twojej organizacji jest konkretna osoba — pojedynczy człowiek, a nie zespół czy komitet — której zadaniem jest pełnienie roli łącznika między inżynierami AI a architektami korporacyjnymi? W instytucjach nadzorowanych przez KNF oraz innych podmiotach regulowanych brak takiej osoby to nie tylko luka operacyjna. To luka w systemie governance, która wyjdzie na jaw przy każdej weryfikacji zgodności z EU AI Act Article 26.
Pułapka#
Pułapka brownfield nie jest problemem technologicznym. Modele działają. Platformy chmurowe działają. Produkty dostawców funkcjonują bez zarzutu — w środowiskach, do których zostały zaprojektowane. Pułapką jest założenie, że infrastruktura w przedsiębiorstwie wygląda tak samo jak w środowisku demonstracyjnym. Nie wygląda. Składa się na nią dziewięćset aplikacji, z których dwie trzecie są niezintegrowane, obsługiwanych przez starzejącą się kadrę i podlegających ramom governance stworzonym dla systemów, które już nie istnieją.
Organizacje, którym udało się uniknąć tej pułapki — Aviva, Commonwealth Bank oraz garstka innych opisanych w badaniach Stanforda — mają jedną wspólną cechę: potraktowały integrację jako właściwy projekt, a nie jako zaledwie jeden z jego etapów.
Pozdrawiam,
Krzysztof Goworek