AI w logistyce: magazyn, trasowanie i predykcja popytu

Kierownik logistyki w średniej firmie dystrybucyjnej spędza dziś kilka godzin tygodniowo na ręcznym układaniu tras, korygowaniu stanów magazynowych i przepisywaniu danych z dokumentów papierowych do systemu WMS. Każde odchylenie od prognozy popytu kończy się albo nadmiernym zapasem blokującym kapitał, albo brakiem towaru i opóźnioną dostawą. To nie jest problem skali: dotyka firm obsługujących 50 zleceń dziennie tak samo jak tych obsługujących 5000.

AI nie rozwiązuje logistyki jako całości. Rozwiązuje konkretne, powtarzalne obliczenia, które człowiek wykonuje wolniej i z większą liczbą błędów niż algorytm wspomagany modelem. Różnica leży w szczegółach: które obliczenie, z jakimi danymi wejściowymi i z jakim nadzorem ludzkim.

Logistyka ma wiele podprocesów, ale trzy obszary przynoszą najszybszy mierzalny zwrot i są dostatecznie dojrzałe technologicznie, by wdrożyć je w polskiej firmie w 2026 roku.

Zaczynaj od jednej warstwy. Próba jednoczesnego wdrożenia trzech to najczęstszy powód, dla którego projekty AI w logistyce kończą się na etapie pilotażu.

Klasyczny problem Vehicle Routing Problem (VRP) jest NP-trudny: już przy 20 punktach dostawy przestrzeń rozwiązań jest za duża na pełne przeszukiwanie. Algorytmy heurystyczne (takie jak Google OR-Tools) dają dobre wyniki, ale nie reagują na zdarzenia bieżące: korek na trasie, zmianę okna czasowego przez klienta, awarię pojazdu.

Agent AI z dostępem do narzędzi dodaje do tego dynamiczne przeliczanie:

1. Harmonogram i punkty dostawy trafiają do agenta jako kontekst.
2. Agent odpytuje API ruchu drogowego i aktualny status floty.
3. Algorytm VRP oblicza trasę bazową; agent weryfikuje ją pod kątem ograniczeń czasowych i pojemnościowych.
4. Jeśli pojawiło się zdarzenie (korek, zmiana okna), agent przelicza trasę i wysyła kierowcy zaktualizowaną sekwencję.
5. Akcje nieodwracalne (zmiana zlecenia do klienta, przesunięcie okna dostawy) wymagają potwierdzenia dyspozytora przez human-gate.

Kluczowa zasada: agent zarządza obliczeniem, dyspozytor zatwierdza decyzję o skutkach zewnętrznych. Bez tej granicy system szybko wysyła komunikaty do klientów bez nadzoru i generuje reklamacje zamiast je redukować.

Większość firm prognozuje popyt w Excelu: bierze średnią z ostatnich N miesięcy i dodaje intuicyjną korektę sezonową. To działa przy stabilnym popycie i małej liczbie SKU. Przestaje działać, gdy SKU jest kilkaset, popyt jest sezonowy i zależy od zdarzeń zewnętrznych (kampanie, pogoda, święta).

Model predykcji popytu dla logistyki łączy kilka źródeł danych:

• Historia sprzedaży (na poziomie SKU, kanału, regionu) jako dane treningowe.
• Kalendarz sezonowości (święta, szczyty branżowe, dni tygodnia).
• Zdarzenia zewnętrzne (kampanie marketingowe, zmiany cennika, dane pogodowe jeśli popyt jest zależny od pogody).
• Dane z zaopatrzenia (terminy dostaw od dostawców, minimalne partie).

Wynik to prognoza na poziomie SKU na 4–12 tygodni do przodu z przedziałem ufności. System nie mówi: „zamów 100 sztuk". Mówi: „z 80-procentową pewnością potrzebujesz 80–120 sztuk, przy obecnym lead time zamów 90". Decyzja o zamówieniu pozostaje u kupca.

Granica, której nie przekraczać: nie automatyzuj zatwierdzania zamówień zakupowych bez human-gate. Model się myli rzadziej niż człowiek przy powtarzalnych SKU, ale przy nowych produktach, przerwach w łańcuchu dostaw i zdarzeniach jednorazowych przewidywanie historyczne nie ma podstaw.

Dokument logistyczny ma strukturę (numer zlecenia, adres, waga, kod towaru), ale ta struktura różni się między partnerami, formatami i krajami. Ręczne przepisywanie danych z CMR, WZ, awizacji i faktur to praca, która nie wymaga wiedzy, ale pochłania czas i generuje błędy przy zmęczeniu.

Architektura automatyzacji dokumentów:

1. Dokument (skan, PDF, zdjęcie) trafia do pipeline przez API lub folder monitorowany przez agenta.
2. OCR zamienia obraz na tekst strukturyzowany.
3. Model ekstrakcji (instruction-tuned, nie generyczny chatbot) wyciąga pola według zdefiniowanego schematu: numer zlecenia, NIP, adres, pozycje.
4. Wynik jest walidowany schematem JSON i sprawdzany pod kątem spójności (suma linii = wartość faktury, kod pocztowy pasuje do miasta).
5. Rekord trafia do WMS/ERP automatycznie, jeśli walidacja przeszła. Jeśli nie, dokument ląduje w kolejce do ręcznej weryfikacji.

Wynik w realnych wdrożeniach: 85–95% dokumentów idzie automatycznie, 5–15% wymaga ingerencji. To zmiana z „każdy dokument jest ręczny" na „jeden na dziesięć wymaga uwagi". Przy 100 dokumentach dziennie to konkretna oszczędność czasu.

Ważne: PII w dokumentach (dane osobowe kierowców, klientów indywidualnych) należy maskować przed wysłaniem do modelu chmurowego. Dane firmowe (NIP, adres firmy) mogą iść bez maskowania, bo to dane publiczne. Przy danych szczególnie wrażliwych (umowy, dane medyczne) rozważ self-hosting modelu.

Logistyka przetwarza dane osobowe kierowców (GPS, czas pracy) i klientów indywidualnych (adresy dostawy, historia zamówień). Kilka wymagań, które muszą być rozwiązane przed wdrożeniem AI:

• Podstawa przetwarzania danych kierowców — monitoring GPS i analiza czasu pracy przez AI muszą mieć jasną podstawę prawną i być zakomunikowane pracownikom. To nie jest kwestia techniczna, to kwestia prawna.
• AI Act a systemy oceny — jeśli system AI ocenia wydajność kierowców lub decyduje o ich trasach w sposób wpływający na zatrudnienie, może kwalifikować się jako system wysokiego ryzyka wg AI Act, wymagając DPIA i dokumentacji zgodności. Szczegóły w artykule AI Act i RODO 2026.
• Dane lokalizacyjne a chmura — surowe dane GPS kierowców to dane osobowe. Przed wysłaniem do zewnętrznego modelu anonimizuj lub pseudonimizuj. Alternatywa to self-hosting modelu optymalizacji.
• Data residency — dla firm obsługujących transport ponadgraniczny sprawdź, w której jurysdykcji przetwarzasz dane i czy model jest hostowany w EU.

Zrób ocenę ryzyka przed startem, nie po. Cofanie architektury ze względu na RODO w połowie projektu kosztuje wielokrotnie więcej niż uwzględnienie tych wymagań na etapie projektowania.

Najczęstszy bloker wdrożeń AI w logistyce to nie model, lecz integracja z systemami źródłowymi. WMS sprzed 10 lat, TMS bez API REST, ERP z eksportem tylko do CSV o 2:00 w nocy. AI może tylko tyle, ile dostaje danych w czasie bliskim rzeczywistemu.

Trzy pytania, które determinują architekturę:

1. Czy system źródłowy ma API? Jeśli tak, agent może czytać dane w czasie rzeczywistym. Jeśli nie, potrzebujesz warstwy ETL lub harmonogramowanego importu.
2. Jak często zmieniają się dane referencyjne? Cenniki, tabele stref, adresy punktów dostaw. Jeśli zmieniają się często, potrzebujesz mechanizmu odświeżania indeksu.
3. Kto jest właścicielem decyzji? Nie system, nie model. Konkretna osoba, która zatwierdza trasę, zamówienie, eskalację. Bez jasnego właściciela human-gate nie działa.

Wzorzec integracji, który redukuje ryzyko: zacznij od trybu read-only. AI czyta dane z WMS/TMS i rekomenduje, dyspozytor zatwierdza w systemie źródłowym. Dopiero gdy jakość rekomendacji jest potwierdzona przez 4–6 tygodni, rozważ write-back z human-gate dla konkretnych akcji.

Nie ma jednej liczby. Reguła kciuka dla logistyki:

Jeśli Wasz miesięczny koszt paliwa i czasu kierowców przekracza 50 tys. zł, a trasy nie są optymalizowane algorytmicznie, optymalizacja tras zwraca się w 6–12 miesięcy. Jeśli przetwarzacie powyżej 50 dokumentów dziennie ręcznie, automatyzacja dokumentów zwraca się w podobnym czasie. Predykcja popytu zwraca się dłużej (12–18 miesięcy), ale zmniejsza zamrożony kapitał w zapasach, co jest efektem poza P&L.

Policz to na swoich liczbach w kalkulatorze ROI. Wpisz realne wolumeny, stawki i szacowany zakres automatyzacji. Koszt pilotażu jednej warstwy ustalamy indywidualnie przez formularz kontaktowy.

Zacznij od oceny gotowości: formularz pyta o jakość danych, integracje i dojrzałość procesów. Wynik wskazuje, którą warstwę wdrożyć najpierw i gdzie są techniczne braki.

Opisz jeden logistyczny proces, który zajmuje Twój zespół nieproporcjonalnie dużo czasu, a model rozpisze architekturę AI dla tego przypadku: dane wejściowe, typ modelu, human-gate i mierzalny wynik (playground: PII maskowane, zero retencji).

Nie. Algorytm oblicza optymalne trasy szybciej i bardziej systematycznie niż człowiek, ale dyspozytor zna kontekst: preferencje klienta, specyfikę pojazdu, relacje z kierowcami. Rola dyspozytora przesuwa się z ręcznego układania tras na zatwierdzanie i obsługę wyjątków. Decyzje o skutkach zewnętrznych (zmiana okna dostawy do klienta, renegocjacja zlecenia) zawsze wymagają człowieka.

Minimum to 12 miesięcy historii sprzedaży per SKU, żeby model mógł nauczyć się sezonowości. Przy 18–24 miesiącach jakość prognozy wyraźnie rośnie. Jeśli masz mniej danych lub nowe produkty bez historii, model prognozuje słabiej i potrzebujesz szerszego przedziału ufności oraz ściślejszego nadzoru kupca. Sprawdź jakość i kompletność danych w ocenie gotowości przed startem.

Dane GPS kierowcy to dane osobowe. Przed wysłaniem do zewnętrznego modelu anonimizuj je: usuń identyfikator kierowcy, zastąp lokalizację startową/końcową pseudonimem i zachowaj tylko dane niezbędne do optymalizacji (sekwencja punktów, okna czasowe). Surowe dane GPS przechowuj lokalnie z określonym TTL. Szczegóły obowiązków firmowych opisuje artykuł AI Act i RODO 2026.

Może, ale powinien to robić tylko po walidacji i z mechanizmem cofnięcia. Wzorzec produkcyjny: AI rekomenduje zmianę, użytkownik zatwierdza jednym kliknięciem, system zapisuje i loguje. Dla akcji o dużej wartości (zamówienie powyżej określonego progu, zmiana umowy z dostawcą) zawsze stosuj human-gate niezależnie od pewności modelu. Zacznij od trybu read-only i włączaj write-back stopniowo po weryfikacji jakości.

Jedna warstwa (np. automatyzacja dokumentów lub optymalizacja tras dla stałej floty) zwykle zajmuje 3–6 tygodni: tydzień analizy danych i integracji, tydzień budowy pipeline, tydzień testów i kalibracji guardrails, tydzień pilotażu na realnych zleceniach z nadzorem. Czas zależy głównie od jakości danych i dostępności API systemów źródłowych. Sprawdź jak zacząć wdrożenie AI dla ogólnych zasad projektowania pilotażu.