Produkcyjna implementacja AI w logistyce w 2026 | Vibe coding, guardrails i koniec świata ticketów.

AI w logistyce przez długi czas funkcjonowało w dwóch trybach. Pierwszy to tryb marketingowy: dopinanie etykiety „AI” do rozwiązań, które były po prostu klasyczną algorytmiką. Drugi to tryb eksperymentalny: prototypy, demo, proof of concept, które dobrze wyglądały na slajdach, ale rzadko przekładały się na stabilną pracę operacji. W 2026 zaczyna się trzeci tryb: produkcyjna implementacja AI w logistyce, czyli taka, która dotyka fundamentów efektywności – czasu reakcji, kosztu zmiany i jakości decyzji.

Kluczowe jest to, że ta zmiana nie wynika wyłącznie z „lepszych modeli”. Wynika z przetasowania ról w firmie i ze spadku bariery wytwarzania oprogramowania. Przez lata logistyka żyła w modelu, w którym niemal każde usprawnienie kończyło się w kolejce: „zgłoś ticket”. Niezależnie czy chodziło o drobną zmianę w raporcie WMS, automatyzację prostej czynności, integrację z zewnętrznym źródłem danych czy dashboard dla kierownika – w praktyce trafiało to do backlogu firmy IT (wewnętrznej lub zewnętrznej), gdzie priorytety ustalał ktoś inny, a ty czekałeś.

To czekanie ma realny koszt. Po pierwsze, koszt pracy ludzi, którzy obchodzą system (excel, ręczne korekty, obejścia). Po drugie, koszt błędów, które wynikają z manualnych kroków. Po trzecie, koszt utraconych okazji: jeśli nie potrafisz szybko zmienić narzędzia, nie potrafisz szybko zmienić procesu.

W tym miejscu pojawia się vibe coding – kodowanie za pomocą promptów i języka naturalnego. W praktyce oznacza to, że osoba rozumiejąca proces może w iteracjach budować narzędzia: od prostych aplikacji wewnętrznych po warstwy analityczno-decyzyjne. Z perspektywy logistyki to jest rewolucja podobna do tej, którą kiedyś zrobiły arkusze kalkulacyjne, tylko o poziom wyżej: zamiast liczyć, zaczynasz „budować”.

Tyle że vibe coding ma swoją granicę. Tą granicą nie jest „brak umiejętności programowania” w sensie liter. Granicą jest brak rozumienia biznesu. Jeśli nie potrafisz opisać problemu, zdefiniować kryterium sukcesu, wskazać danych wejściowych, ograniczeń procesu i ryzyk – to narzędzie AI będzie produkowało pozorną treść, a nie działający produkt. Dlatego mówię wprost: AI nie robi z człowieka bez kontekstu eksperta od operacji. Natomiast dramatycznie wzmacnia eksperta od operacji, który potrafi zadać dobre pytanie i poprowadzić iterację rozwiązania.

Druga sprawa to guardrails. W logistyce nie ma miejsca na romantyzm technologiczny. Dane są wrażliwe, procesy są krytyczne, a błędy kosztują. Guardrails to zestaw zabezpieczeń, które powinny być projektowane od początku. Na poziomie technicznym to może być kontrola dostępu, segmentacja środowisk, zamknięte porty, autoryzacja, logowanie działań, wersjonowanie. Na poziomie procesowym: szkolenie ludzi, zasady użycia narzędzi, walidacja wyników, testy na danych historycznych, mechanizmy odcięcia automatu. Na poziomie prawnym: NDA, ograniczenia przetwarzania danych, zasady retencji, odpowiedzialność.

Warto też rozróżnić narzędzie „dla siebie” od produktu „dla rynku”. Narzędzie wewnętrzne można często zamknąć w kontrolowanym środowisku, gdzie właściciel procesu ma pełną świadomość, co zasila model i jakie są ryzyka. Produkt rynkowy wymaga pełnego profesjonalizmu: SLA, obsługi incydentów, planu utrzymania, testów, audytu, dokumentacji. I to jest punkt, w którym część argumentów „starego IT” jest zasadna. Problem polega na tym, że te argumenty są często używane jako pałka do blokowania nawet tych przypadków, które spokojnie powinny powstać w trybie narzędziowym, szybko i pragmatycznie.

Dlatego proponuję myśleć o architekturze firmowych narzędzi jako o „cebuli” warstw.

Warstwa 1: core transakcyjny. ERP/WMS/OMS/TMS w wersji stabilnej, przewidywalnej, objętej utrzymaniem. To fundament.

Warstwa 2: dane i integracje. Bez higieny danych (master data, spójne słowniki, sensowne identyfikatory, walidacja) AI nie ma na czym pracować. W tej warstwie mieszczą się szyny danych, konektory, ekstrakcja, standaryzacja.

Warstwa 3: interfejs analityczno-decyzyjny. Tu wchodzą narzędzia, które pozwalają zadawać pytania językiem naturalnym i budować dashboardy, heatmapy, alerty, analizy ad hoc bez długiego cyklu w IT. Przykładem klasy funkcji jest choćby mapa ciepła magazynu: obciążenie stref, przeciążenia, korelacja z błędami, piki.

Warstwa 4: workflow i task management. Sama analityka nie zmienia firmy. Zmienia ją dopiero przełożenie wniosków na zadania: kto ma zrobić co, do kiedy, jak mierzymy rezultat. AI może tu działać jako tłumacz: z obserwacji → do listy działań → do podziału na zadania dla ludzi i automaty.

Warstwa 5: automaty i agenci. Część działań może być wykonywana automatycznie: monitoring, raporty, przypomnienia, korekty parametrów, przygotowanie wariantów planu, wstępna analiza kosztów capex/opex.

W takim modelu widać, dlaczego ticketing zaczyna umierać jako jedyny kanał zmiany. Jeśli kierownik operacji może „dopisać” warstwę 3–4 bez dotykania core, to większość codziennych problemów przestaje być zakładnikiem backlogu IT.

W tym kontekście dwa case’y, które przewijają się w moim materiale, są ważne.

Open Mercato pokazuje, że open source w świecie ERP/RP nie jest już akademicką ciekawostką. Może być sposobem na odzyskanie sterowności: masz silnik, masz dokumentację, masz roadmapę, a płatne są wdrożenia i dodatki. Nie chodzi o to, żeby wszystko robić samemu. Chodzi o to, że zmienia się relacja zależności: vendor lock-in przestaje być defaultem.

Blueclip.ai (w ujęciu funkcjonalnym) pokazuje inny kierunek: „mózg” ponad systemami, który łączy dane z wielu źródeł i pozwala na pracę językiem naturalnym. To ma konsekwencje praktyczne. Skoro mogę w kilka minut uzyskać wizualizację obciążenia magazynu, a potem zamienić ją w taski optymalizacyjne, to skracam pętlę decyzyjną. A w logistyce pętla decyzyjna jest często ważniejsza niż „idealny algorytm”.

Na koniec zostaje temat ludzi i ról. Moja teza jest prosta: w szeroko rozumianym IT zostaną ci, którzy rozumieją technologię naprawdę dobrze i potrafią zarządzać agentami, bezpieczeństwem, jakością oraz architekturą. Natomiast rola polegająca wyłącznie na „klepaniu kodu” będzie traciła wartość, bo produkcję kodu przejmą modele. W logistyce natomiast zyskają ci, którzy potrafią łączyć proces, dane i ryzyko, oraz umieją zamieniać obserwacje w działające narzędzia.

Jeżeli chcesz podejść do produkcyjnej implementacji AI w logistyce pragmatycznie, zacznij od trzech pytań:

• Jakie tarcia operacyjne dzisiaj kosztują nas najwięcej czasu i nerwów?

• Jakie dane mamy, żeby to mierzyć i walidować?

• Jakie guardrails muszą być od razu wbudowane, żeby nie wywołać kryzysu bezpieczeństwa?

Dopiero potem wybieraj narzędzia. Nie odwrotnie.

Piotr Susz

Kontakt: https://locura.pl