Architektura AI-native a przyszłość oprogramowania biznesowego: jak połączyć elastyczność AI z niezawodnością ERP i WMS, wskazuje Marcin Smereka, CTO Sente i Architekt Teneum WMS.
Część I: Rynek oprogramowania biznesowego i spór o AI
O sztucznej inteligencji w biznesie słyszymy dziś z każdej strony. Według danych Gartnera z 2025 roku do końca 2026 r. aż 40% aplikacji enterprise ma mieć wbudowanych agentów AI. Jednocześnie ten sam Gartner ostrzega, że ponad 40% projektów agentowej AI zostanie anulowanych do końca 2027 roku. Z czego wynika ten rozdźwięk między entuzjazmem a rozczarowaniem?
Z pomylenia pojęć i powszechnego zjawiska, które analitycy Gartnera nazywają AI washing – czyli przemianowywania chatbotów i starych automatyzacji na „agentów AI”.
Większość tego, co widzimy dziś na rynku systemów ERP czy WMS, to „AI doklejone”. Do istniejącego systemu dodaje się pojedyncze funkcje – na przykład chatbota w rogu ekranu czy automatyczną kategoryzację danych w pewnej kartotece. To przydatne funkcje, ale nie zmieniają sposobu, w jaki firma pracuje z systemem. Chatbot działa obok systemu, a nie wewnątrz niego.
Rozczarowanie pojawia się w momencie, gdy firmy zderzają się z rosnącymi kosztami i niejasną wartością biznesową takich projektów. W systemach krytycznych dla firmy, takich jak ERP czy WMS, liczą się stabilność, niezawodność i pełna spójność danych. Doklejona funkcja nie zmienia architektury i fundamentów systemu.
Po czym klient ma poznać, że AI w oferowanym mu systemie jest tylko taką wizualną nakładką?
Różnicę widać w tym, co sztuczna inteligencja naprawdę potrafi zrobić. Doklejony chatbot w rogu ekranu czy pojedyncza automatyzacja wykonują tylko jedną zaprogramowaną czynność, przewidzianą przez producenta. Nie zmienia to sposobu, w jaki firma pracuje z systemem. Nakładka nie ma dostępu do wiedzy o systemie, nie widzi kontekstu pracy użytkownika i nie działa w ramach jego uprawnień. Asystent AI-native realizuje wszelkie potrzeby, które pojawiają się dynamicznie w trakcie rozmowy – ponieważ zna system od środka, widzi ekran, ma uprawnienia użytkownika i potrafi go rozbudowywać.
Czy starsze systemy, tak zwane systemy legacy, da się przebudować do modelu AI-native, czy trzeba zmienić ich fundamenty? Gdzie przebiega granica?
To zależy od architektury danego systemu. Rzeczywista różnica leży w tym, czy AI ma dostęp do wiedzy o systemie, jego wszystkich funkcji, do kontekstu pracy użytkownika i jego uprawnień. Tych warunków nie da się dodać jak nowej zakładki w menu – trzeba je zaprojektować w fundamentach.
Nie oznacza to jednak, że każdy system typu legacy jest skazany na porażkę – wiele z nich spełnia swoje zadania. Natomiast na rynku systemów biznesowych zaczyna się podział podobny do tego, który kiedyś oddzielił oprogramowanie instalowane na serwerach stacjonarnych od rozwiązań budowanych od początku dla chmury. Tworzy się kategoria rozwiązań AI-native.
Jakie decyzje technologiczne podjęto w Sente, ile czasu zajęła ta zmiana i co było w niej najtrudniejsze?
Przejście na model AI-native wymagało spełnienia konkretnych warunków w architekturze systemu. Kluczowym wyzwaniem było stworzenie mechanizmu, w którym dokumentacja powstaje bezpośrednio z kodu źródłowego i jest generowana oraz aktualizowana przy każdym wydaniu nowej wersji. Drugim fundamentem było wymuszenie, by asystent prawidłowo orientował się we wszystkich funkcjach systemu, których są setki i wchodził do systemu dokładnie tymi samymi drzwiami co użytkownik – bez budowania osobnego „API dla AI” czy tworzenia oddzielnego dostępu technicznego.
Część II: Bezpieczeństwo, uprawnienia i kontrola ryzyka
Przejdźmy do kwestii bezpieczeństwa. Zarządy obawiają się wpuszczenia AI do systemów transakcyjnych. Jaka jest główna zasada AI-native w tym zakresie i jak to wygląda od strony technicznej?
Zasada jest jedna: AI w systemie nie powinna mieć ani jednego uprawnienia więcej niż człowiek, z którym pracuje. Wielu dostawców tworzy osobny dostęp techniczny dla AI, co rodzi obawy przed niewystarczającą kontrolą ryzyka. W podejściu AI-native asystent nie ma własnego, szerszego dostępu. Nie budowaliśmy osobnego API – asystent wchodzi w ten sam sposób co użytkownik i wykonuje wyłącznie te komendy oraz zapytania, które ma prawo wykonać zalogowana osoba, korzystając z istniejącego, sprawdzonego modelu uprawnień.
Bezpieczeństwo nie jest tu więc dodatkową warstwą nałożoną na AI, lecz bezpośrednią konsekwencją architektonicznej spójności. Jeśli dany pracownik nie ma prawa zmienić konfiguracji czy polityki zbiórki, asystent również tego za niego nie zrobi, choćby użytkownik poprosił o to własnymi słowami.
Co w sytuacji, gdy AI źle zrozumie polecenie użytkownika? Jakie bezpieczniki działają po drodze?
Kluczem jest zasada human-in-the-loop oraz rozróżnienie roli asystenta od autonomicznego agenta. Autonomiczny agent sam podejmuje decyzje, natomiast w Teneum WMS świadomie realizujemy model asystenta pod prąd modzie na pełną autonomię. Gdy użytkownik chce zmienić politykę zbiórki i pisze własnymi słowami „pierwsze weszło, pierwsze wyszło”, asystent dobiera FIFO, dopytuje o szczegóły – czy chodzi o zbiórkę czy alokację oraz czy zmiana ma dotyczyć wszystkich towarów – po czym przedstawia propozycję. Trwałe zmiany w systemie wykonuje tylko wtedy, gdy człowiek je zatwierdzi, i o ile sam użytkownik ma prawo taką zmianę przeprowadzić.
Kto w takim razie odpowiada za błąd: dostawca, AI czy pracownik?
Z prawnego i operacyjnego punktu widzenia odpowiedzialność pozostaje po stronie człowieka, który zmianę zlecił i zatwierdził – i to jest największa zaleta spójnego modelu uprawnień. Eliminujemy w ten sposób sytuację braku rozliczalności.
Jak utrzymać kontrolę nad kodem generowanym przez asystenta i jak takie podejście wpisuje się w wymogi prawne, np. europejski AI Act?
W podejściu AI-native kluczowe jest to, że asystent rozbudowuje system kodem, a nie konfiguratorem, ale wszelkie trwałe zmiany oraz decyzje procesowe pozostają pod pełną kontrolą człowieka. Jeśli chodzi o AI Act, kluczowe są lokalizacja i przetwarzanie danych. W Teneum WMS wszystkie dane aplikacji pozostają w infrastrukturze klienta. Do chmury dostawców modeli (Anthropic, OpenAI, Google, za pośrednictwem platformy OpenRouter) trafia tymczasowo tylko kontekst rozmowy z asystentem. Dostawcy deklarują retencję tych danych do 30 dni i nie wykorzystują ich do trenowania modeli. Firma sama decyduje, ile danych wysyła do AI: może to ustawić dla pojedynczego użytkownika albo dla całej organizacji. Może też zostawić wyłącznie tryb dokumentacyjny, w którym do modelu trafiają tylko pytania i fragmenty dokumentacji, albo całkowicie wyłączyć AI. Kontrolę nad działaniem AI zapewnia system uprawnień.
Część III: Nowa ekonomia oprogramowania
Tradycyjny model utrzymania systemów ERP i WMS opiera się na zgłoszeniach modyfikacji, które trwają tygodniami i słono kosztują. Jak podejście AI-native zmienia te koszty?
Otwieramy dyskusję o nowej ekonomii oprogramowania biznesowego. W tradycyjnym modelu nawet prosty raport czy nowy widok przechodzi długą ścieżkę: zgłoszenie – analiza – specyfikacja – wycena – programista – testy – wdrożenie. Koszt jest często nieproporcjonalny do skali zmiany, a to zmienia całkowity koszt posiadania systemu i to, za co firma płaci dostawcy.
Gdy użytkownik potrafi wygenerować potrzebny widok czy wskaźnik samodzielnie, opisując go zwykłym zdaniem, eliminujemy długą i kosztowną ścieżkę zgłoszeń IT. Zmiana, która wcześniej wymagała analizy, wyceny i tygodni oczekiwania na programistę, staje się gotowa w kilka minut, a koszt jej wykonania drastycznie spada.
Które zmiany użytkownik może wykonać sam w rozmowie z asystentem, a które zadania bezwzględnie pozostają po stronie specjalistów IT?
Użytkownik biznesowy może samodzielnie zrealizować część drobnych zmian, opisując potrzebę własnymi słowami – na przykład przygotować nowy widok, prosty raport czy interaktywny pulpit wydajności na podstawie komunikatu lub odręcznego szkicu.
Nie oznacza to jednak, że każdą modyfikację da się wykonać w ten sposób. Bardziej złożone zadania – wymagające wiedzy o architekturze, bezpieczeństwie czy integracji systemów – nadal pozostają po stronie specjalistów i inżynierów. Rola dostawcy i konsultanta przesuwa się z rutynowego klikania i wykonywania drobnych zgłoszeń w stronę doradztwa i architektury.
Jak rzetelnie policzyć oszczędności wynikające z tego podejścia?
Kluczowe oszczędności wynikają z czasu, kosztów i wyeliminowania obejść w systemie. W tradycyjnym modelu długa ścieżka realizacji i koszt nieproporcjonalny do skali zmiany powodują, że wiele potrzeb biznesowych nigdy nie trafia do realizacji, a firmy zaczynają obchodzić ERP czy WMS arkuszami kalkulacyjnymi. Gdy część drobnych zmian użytkownik może zrealizować sam, opisując potrzebę własnymi słowami, znikają bariery i długi czas oczekiwania, a firmy nie muszą budować równoległych rozwiązań w Excelu obok systemu.
Czy większa samodzielność użytkowników nie doprowadzi do chaosu – sytuacji, w której w firmie powstaną setki niestandardowych raportów i pulpitów, których nikt nie potrafi utrzymać?
Chaos pojawia się przede wszystkim wtedy, gdy firmy obchodzą system i tworzą arkusze kalkulacyjne obok ERP czy WMS. W podejściu AI-native zmiana nie powstaje poza systemem – asystent tworzy widoki i raporty bezpośrednio wewnątrz architektury systemu, Wie jakie
raporty, widoki i pulpity powstały już wcześniej i często proponuje ich ponowne użycie lub modyfikację niż stworzenie nowego.
Część IV: Obsługa systemu w języku naturalnym i elastyczność procesowa
Czym taka praca różni się od klasycznej automatyzacji procesowej, którą znamy od lat?
Klasyczna automatyzacja wykonuje jedną zaprogramowaną czynność, do której została stworzona, realizując gotowe scenariusze przewidziane przez producenta. Asystent AI-native nie ogranicza się do z góry założonych schematów – realizuje potrzeby, które pojawiają się dynamicznie w trakcie rozmowy.
Przykład z Teneum WMS: gdy stare awiza zalegają, bo magazynierzy biorą tylko nowe, kierownik mówi: „spójrz na ekran, jak to wygląda – pomóż”. Asystent czyta tabelę z ekranu, bada logikę priorytetów i stawia diagnozę: priorytet ustawiony jest tylko według godziny kuriera, bez bonusu za wiek zlecenia. Od razu proponuje konkretną zmianę konfiguracji, a decyzja o jej zatwierdzeniu zawsze należy do człowieka.
Gdzie AI w systemach biznesowych dochodzi dzisiaj do ściany? Czego asystent nie zrobi?
AI dochodzi do ściany wszędzie tam, gdzie kończy się rola asystenta, a wymagana jest autonomia lub zatwierdzenie decyzji przez człowieka.
Świadomie zrezygnowaliśmy z modelu autonomicznego agenta na rzecz asystenta, który analizuje problem, stawia diagnozę i przedstawia propozycje zmian.
Asystent nie podejmuje samodzielnie decyzji procesowych ani nie wprowadza samodzielnie trwałych zmian w systemie – ostateczne słowo i zatwierdzenie modyfikacji zawsze należy do człowieka.
Część V: Transformacja rynku IT, rola konsultantów i dostawców
Jak ten rozwój zmieni pracę firm technologicznych? Czy AI odbierze pracę wdrożeniowcom i konsultantom ERP?
Praca zespołów IT i wdrożeniowców nie zniknie, ale przesunie się w stronę architektury, bezpieczeństwa, integracji i złożonych procesów. Konsultant spędzi mniej czasu na wyklikiwaniu ustawień i rutynowych konfiguracjach, a więcej na doradzaniu, jak zorganizować procesy w firmie. Zmienia się także relacja z klientem – dostawca przestaje być wyłącznie wykonawcą zgłoszeń, a staje się partnerem odpowiedzialnym za efekt biznesowy.
Co ta zmiana oznacza dla samych firm wdrażających takie systemy – jakich nowych kompetencji będą potrzebować zarządy i pracownicy?
Zmiana sposobu pracy z systemami wymusi rozwój zupełnie nowych umiejętności. Jak przewiduje Gartner, do 2029 roku co najmniej połowa
pracowników umysłowych będzie rozwijać kompetencje potrzebne do pracy z agentami AI i ich tworzenia. Kluczową zmianą jest to, że użytkownik nie musi już znać specyfikacji technicznej, ścieżek w menu ani technicznego żargonu – operuje językiem biznesowym, mówiąc własnymi słowami, czego potrzebuje. Nazewnictwo techniczne i egzekucję w systemie pamięta asystent, a nie człowiek.
CZĘŚĆ VI: Polska na tle Europy – szansa na cyfrowy skok
Spójrzmy na kontekst gospodarczy. Z danych Eurostatu opublikowanych pod koniec 2025 roku wynika, że zaledwie 8,4% polskich firm zatrudniających pow. 10 osób korzysta z AI, przy średniej unijnej wynoszącej 20%. Daje nam to przedostatnie miejsce w UE. Co najbardziej hamuje polskie przedsiębiorstwa?
Jedną z głównych barier jest przekonanie, że AI to osobny, kosztowny projekt wymagający specjalistów od danych. Drugim czynnikiem są obawy zarządów przed utratą kontroli i niewystarczającą kontrolą ryzyka – stąd pytania o to, co się stanie, jeśli AI w systemie krytycznym zrobi coś nieprzewidzianego. Ale to się zmienia dynamicznie.
Czy wbudowanie AI bezpośrednio w systemy ERP czy WMS to droga do przełamania tego zastoju?
Jeśli AI przychodzi jako część systemu biznesowego, z którego firma i tak korzysta na co dzień, a komunikacja odbywa się w zwykłym języku, próg wejścia wyraźnie spada. Użytkownik nie musi posiadać znajomości AI ani języka technicznego – wystarczy opisać swoją potrzebę.
Przed polskimi przedsiębiorstwami stoi pytanie o możliwość przeskoczenia etapu rozwoju. Zamiast wdrażać rozwiązania z AI doklejonym, firmy wybierające nowe systemy mogą od razu sięgnąć po nową generację rozwiązań AI-native – podobnie jak polska bankowość w wielu obszarach przeskoczyła rozwiązania popularne na Zachodzie.
