Agent AI do zarządzania zapasami w retail: prognozy, zamówienia i kontrola

Agent AI do zapasów nie jest magicznym buyerem, który "wie", ile zamówić. W praktyce dobry system robi coś mniej efektownego i bardziej użytecznego: czyści obraz danych, wskazuje ryzyka, przygotowuje propozycje zamówień i zatrzymuje się przed decyzją, która wiąże pieniądze albo zmienia stan w ERP.

To ważne rozróżnienie. Jeśli agent ma dostęp do POS, ERP, e-commerce, arkuszy, portali dostawców i poczty zakupowej, to nie jest już chatbot. To element procesu operacyjnego. Trzeba go projektować jak system z uprawnieniami, logami, wyjątkami i odpowiedzialnością człowieka.

McKinsey opisuje predykcyjne planowanie popytu jako obszar, w którym analityka może korzystać z wielu zmiennych, na przykład pogody, trendów i danych sprzedażowych. To nie jest jednak gwarancja wyniku dla konkretnego sklepu. W retailu najpierw trzeba sprawdzić, czy dane bazowe nadają się do modelowania.

Problem: nie tylko prognoza

W rozmowach o zapasach łatwo sprowadzić temat do "AI przewidzi popyt". To zbyt wąskie. Nawet dobry model nie naprawi procesu, w którym:

• sprzedaż z POS nie zgadza się ze stanem magazynowym,
• zwroty i anulacje są księgowane z opóźnieniem,
• warianty produktów są dublowane pod różnymi SKU,
• promocje nie mają historii i opisu mechaniki,
• lead time dostawcy jest wpisany raz i nigdy nieaktualizowany,
• buyer zamawia inaczej, niż wynika z oficjalnej polityki zapasu,
• korekty stanów nie mają powodu, autora i daty.

W takim środowisku agent będzie produkował eleganckie sugestie na krzywych danych. Dlatego pierwszy etap nie powinien brzmieć "podłączmy model", tylko "ustalmy, które dane są wiarygodne i kto odpowiada za wyjątki".

Co agent powinien robić

1. Budować roboczy obraz zapasu

Agent może codziennie zestawiać dane z POS, ERP, e-commerce i magazynu. Celem nie jest zastąpienie systemu źródłowego, tylko wykrycie niespójności:

• SKU z ujemnym stanem,
• produkty sprzedające się mimo braku dostępności w ERP,
• różnice między sklepem internetowym i magazynem,
• zamówienia dostawców bez potwierdzonego terminu,
• towary z wysokim zapasem i niską rotacją,
• produkty sezonowe bez oznaczonego sezonu,
• historyczne promocje bez daty, rabatu lub kanału.

To nudna część wdrożenia, ale bez niej prognozowanie popytu jest dekoracją. Retail potrzebuje jednego roboczego widoku decyzji: ile mamy, ile sprzedajemy, co jest już zamówione, kiedy dojedzie i gdzie model nie ufa danym.

2. Prognozować z niepewnością, nie z pewnością

Dobra prognoza nie powinna udawać jednej pewnej liczby. Przy zapasach ważne są zakresy i ryzyka:

• scenariusz bazowy,
• scenariusz ostrożny,
• scenariusz przy promocji lub nagłej zmianie popytu,
• informacja, które SKU mają zbyt mało historii,
• wyjaśnienie, jakie zmienne miały wpływ na rekomendację.

Agent może uwzględniać historię sprzedaży, sezonowość, kalendarz promocji, poziom cen, dostępność dostawcy, lokalizację sklepu i dane zewnętrzne, jeżeli są realnie dostępne. Nie powinien natomiast obiecywać stałej dokładności typu "95%". Dokładność zależy od kategorii, rotacji, promocji, braków historycznych i jakości danych.

Praktyczny wynik prognozy wygląda tak:

3. Przygotowywać propozycje zamówień

Bezpieczny wzorzec to propozycja, nie samodzielne zamówienie. Agent może przygotować koszyk zakupowy, ale finalny krok powinien należeć do osoby z odpowiednim uprawnieniem.

W propozycji zamówienia powinno być widać:

• produkt i lokalizację,
• sugerowaną ilość,
• aktualny stan i sprzedaż z ostatnich okresów,
• otwarte zamówienia i przewidywany termin dostawy,
• minimalną ilość zamówienia, opakowania zbiorcze i progi logistyczne,
• alternatywnego dostawcę, jeżeli obecny ma ryzyko opóźnienia,
• powód rekomendacji,
• poziom pewności,
• datę, autora decyzji i zmiany wprowadzone przez człowieka.

Agent może też grupować pozycje pod jednego dostawcę, wyłapywać progi darmowej dostawy albo wskazywać konflikt między minimalnym zamówieniem a niską rotacją. To nadal nie znaczy, że powinien bez pytania wysyłać zamówienie do EDI, maila albo portalu B2B.

4. Alarmować o wyjątkach

Największa wartość często nie leży w "optymalnym" zamówieniu, tylko w szybkim wykryciu wyjątków:

• topowe SKU schodzą szybciej niż zwykle,
• dostawca opóźnia kolejne dostawy,
• towar sezonowy został zamówiony za późno,
• stan magazynowy zmienił się ręczną korektą,
• produkt ma zapas, ale nie jest dostępny online,
• termin przydatności wymaga decyzji handlowej,
• model nie ufa prognozie i prosi o ręczną ocenę.

Takie alerty powinny trafiać do konkretnych ról. Inny alert dostaje buyer, inny kierownik sklepu, inny osoba odpowiedzialna za dane produktowe.

Czego agent nie powinien robić bez akceptacji

Domyślnie zatrzymałbym automatyzację przed działaniami, które mają koszt, zmieniają kontrakt albo wpływają na klienta:

• wysłanie zamówienia do dostawcy,
• zmiana ceny sprzedaży,
• uruchomienie promocji,
• anulowanie zamówienia,
• zmiana dostawcy,
• przeniesienie dużej partii między magazynami,
• korekta stanu magazynowego,
• decyzja o utylizacji, zwrocie albo przecenie,
• eksport danych klienta do zewnętrznego modelu.

W praktyce agent może robić draft. Człowiek zatwierdza, edytuje albo odrzuca. Każda z tych decyzji zostaje w logu.

Architektura: kontrolowany przepływ pracy

Nie ma jednej technologii, która sama rozwiązuje zapasy. Sensowna architektura rozdziela model, workflow, integracje i audyt.

LangGraph / LangChain. Dobre do procesów stanowych, w których agent ma narzędzia i punkty przerwania. Dokumentacja LangGraph opisuje przerwania human-in-the-loop, gdzie wykonanie może poczekać na decyzję człowieka przed uruchomieniem wrażliwej akcji.

n8n. Przydatne jako warstwa integracyjna: harmonogramy, webhooki, pobieranie danych z API, powiadomienia i obsługa błędów. Dokumentacja n8n pokazuje historię wykonań i log streaming, ale to nie zwalnia z projektowania własnego audytu dla decyzji biznesowych.

OpenClaw albo podobny runtime agentowy. Może służyć jako orkiestrator narzędzi, ale trzeba go traktować jak konto techniczne z uprawnieniami. Jeżeli runtime może czytać pliki, wywoływać API albo wysyłać wiadomości, to jego zakres działania musi być ograniczony.

Hermes Agent. To runtime zbudowany przez Nous Research, który obsługujemy jako warstwę wykonawczą agenta. Nie jest modelem lokalnym i sam jego wybór nie zapewnia jakości prognozy, zgodności z RODO ani kontroli uprawnień.

RAG. Przydaje się do wyszukiwania w politykach zakupowych, umowach dostawców, cennikach, instrukcjach logistycznych i wyjątkach kategorii. Nie powinien być źródłem aktualnego stanu magazynowego. Stan powinien pochodzić z systemów transakcyjnych.

Uprawnienia, logi i obserwowalność

Minimalny zestaw kontroli:

• osobne konto techniczne dla integracji,
• odczyt danych tam, gdzie wystarczy odczyt,
• osobne uprawnienie na przygotowanie propozycji i osobne na zatwierdzenie zamówienia,
• limit wartości zamówienia, powyżej którego wymagane jest drugie zatwierdzenie,
• allowlista dostawców i endpointów,
• log wejść: które dane POS/ERP były użyte,
• log rekomendacji: co agent zaproponował i dlaczego,
• log decyzji: kto zatwierdził, zmienił albo odrzucił propozycję,
• log wykonania: czy zamówienie trafiło do ERP, EDI, maila lub portalu,
• alerty przy braku danych, opóźnionych integracjach i nietypowych zmianach,
• możliwość odtworzenia decyzji po kilku miesiącach.

Obserwowalność jest tu częścią produktu, nie dodatkiem technicznym. Bez niej nie wiadomo, czy problem wynikał z modelu, złego stanu w ERP, opóźnionego importu POS, ręcznej korekty czy decyzji człowieka.

RODO: tylko jeśli pojawiają się dane osobowe

Wiele wdrożeń do zapasów może działać na danych zagregowanych: SKU, lokalizacja, sprzedaż dzienna, stan, dostawca, zamówienie. Wtedy RODO może mieć ograniczone znaczenie.

Sytuacja zmienia się, gdy system używa danych klienta:

• koszyków przypisanych do konta,
• historii zakupów z programu lojalnościowego,
• reklamacji,
• adresów dostawy,
• danych z CRM,
• segmentów klientów albo predykcji zachowania konkretnych osób.

Wtedy trzeba opisać cel, podstawę prawną, zakres danych, retencję, role administratora i procesora, transfery, prawa osób oraz zabezpieczenia. RODO wymaga między innymi minimalizacji danych, ograniczenia celu i rozliczalności. Jeżeli system miałby podejmować zautomatyzowane decyzje dotyczące konkretnej osoby, trzeba dodatkowo sprawdzić ryzyka związane z profilowaniem i automatycznym podejmowaniem decyzji.

Dla agenta zapasów najprostsza zasada brzmi: używaj danych SKU i lokalizacji, jeśli wystarczą. Nie przenoś danych klienta do modelu tylko dlatego, że są dostępne.

Wdrożenie krok po kroku

Faza 1: Audyt danych

• Lista źródeł: POS, ERP, e-commerce, WMS, arkusze, portale dostawców.
• Mapowanie SKU, wariantów, kodów EAN i lokalizacji.
• Sprawdzenie historii sprzedaży, zwrotów, anulacji i korekt.
• Oznaczenie promocji i zdarzeń nietypowych.
• Sprawdzenie lead time, MOQ, opakowań zbiorczych i progów logistycznych.
• Ustalenie, które dane są źródłem prawdy.

Faza 2: Reguły procesu

• Kto może zatwierdzać zamówienia.
• Kiedy potrzebna jest druga akceptacja.
• Jak traktować nowe produkty bez historii.
• Kiedy model ma milczeć i poprosić o decyzję.
• Jak wygląda obsługa błędnego stanu magazynowego.
• Jak długo przechowujemy rekomendacje, decyzje i logi.

Faza 3: Shadow mode

Agent generuje propozycje obok istniejącego procesu. Buyer widzi rekomendację, ale zamawia po staremu. Celem nie jest udowodnienie, że "agent wygrywa", tylko sprawdzenie:

• które kategorie mają wystarczające dane,
• gdzie rekomendacje są ignorowane i dlaczego,
• które alerty są przydatne,
• ile propozycji wymaga ręcznej korekty,
• czy system tłumaczy decyzje w sposób użyteczny dla zespołu.

Faza 4: Akceptacja człowieka

Po pilotażu agent może przygotowywać propozycje zamówień do zatwierdzenia. Nadal warto zacząć konserwatywnie:

• małe limity wartości,
• wybrane kategorie,
• wybrani dostawcy,
• brak automatycznego wysyłania do dostawcy,
• codzienny przegląd wyjątków,
• tygodniowy przegląd błędów i zmian reguł.

Faza 5: Ograniczona automatyzacja

Dopiero po stabilnym okresie można rozważyć automatyczne wykonanie najbezpieczniejszych działań, na przykład wygenerowanie draftu w ERP albo wysłanie wewnętrznego powiadomienia. Wysyłka zamówienia do dostawcy bez akceptacji powinna być wyjątkiem, nie punktem startowym.

Jak mierzyć pilotaż

Nie zaczynaj od ROI z prezentacji. Zacznij od metryk, które da się policzyć przed i po wdrożeniu:

Realistyczny pilotaż nie musi obiecywać spektakularnej redukcji zapasu. Ma odpowiedzieć na pytanie, czy system pomaga zespołowi podejmować lepsze decyzje szybciej i z mniejszą liczbą wyjątków bez właściciela.

Kiedy agent nie pomoże

• Dane sprzedażowe są zbyt krótkie albo niespójne.
• Stany magazynowe są korygowane ręcznie bez powodu w systemie.
• Firma ma mało SKU i proces działa dobrze w prostym arkuszu.
• Produkty są unikatowe i nie mają porównywalnej historii.
• Organizacja nie chce ustalić reguł zatwierdzania.
• Dostawcy nie potwierdzają terminów albo robią to poza systemem.
• Zespół oczekuje pełnej autonomii bez odpowiedzialności za błędy.

W takich przypadkach lepiej zacząć od porządku w danych i procesie zakupowym. Agent może ujawnić problem, ale go nie zastąpi.

FAQ

Czy agent działa z moim systemem POS albo ERP?

To zależy od dostępu do danych. Najlepsze jest API, ale często wystarczy cykliczny eksport CSV, raport z hurtowni danych albo integracja przez warstwę pośrednią. Przed obietnicą integracji trzeba sprawdzić zakres pól, częstotliwość odświeżania, identyfikatory SKU i sposób zapisu zwrotów oraz korekt.

Czy agent może automatycznie zamawiać u dostawców?

Technicznie często tak. Operacyjnie lepszy start to propozycja zamówienia do zatwierdzenia. Pełna automatyzacja ma sens dopiero dla wąskich, dobrze opisanych przypadków, z limitami wartości, logiem, możliwością zatrzymania i jasną odpowiedzialnością.

Jak dokładne są prognozy?

Nie ma jednej uczciwej liczby dla każdej firmy. Dokładność zależy od kategorii, sezonowości, jakości historii, promocji, braków w danych i zmian asortymentu. Dlatego mierzy się pilotaż na własnych danych, a nie na cudzym benchmarku.

Co z nowymi produktami bez historii sprzedaży?

Można używać podobnych produktów, kategorii, sezonu i planu promocji, ale wynik powinien mieć wyraźnie oznaczoną niepewność. Nowe produkty są dobrym miejscem na akceptację człowieka, nie na automatyczne zamówienia bez kontroli.

Czy RAG rozwiąże problem wiedzy o dostawcach?

RAG pomoże znaleźć zapis w umowie, polityce zakupowej albo instrukcji logistycznej. Nie zastąpi aktualnych danych transakcyjnych. Jeśli system pyta "ile mamy na stanie", odpowiedź powinna pochodzić z ERP/WMS/POS, nie z dokumentu w bazie wiedzy.

Czy lokalny model wystarczy, żeby było bezpiecznie?

Nie. Lokalny model może ograniczyć transfer danych do zewnętrznego dostawcy, ale nadal trzeba kontrolować uprawnienia, logi, retencję, jakość danych i decyzje człowieka. Bezpieczny proces wynika z architektury, nie z samego miejsca uruchomienia modelu.

Przed wdrożeniem

Przygotuj pięć rzeczy:

1. Listę źródeł danych i właścicieli każdego źródła.
2. Eksport historii sprzedaży, stanów, zamówień i dostaw.
3. Reguły zatwierdzania zamówień i limity wartości.
4. Listę kategorii, które nadają się do pilotażu.
5. Metryki bazowe: stockouty, zapas wolno rotujący, czas pracy buyera i błędy danych.

Umów bezpłatny skan procesów. To 30 minut z inżynierem i pisemne podsumowanie w 2 dni robocze. Przejdziemy przez dane, proces zakupowy i miejsca, w których agent powinien się zatrzymać przed decyzją.

Źródła i punkty kontrolne

• McKinsey: Supply Chain 4.0 - kontekst dla predykcyjnego planowania popytu i pracy na wielu zmiennych.
• LangGraph: human-in-the-loop - przerwania, zatwierdzanie, edycja i odrzucanie wywołań narzędzi.
• n8n: executions - historia wykonań workflow, filtrowanie i ponawianie błędnych wykonań.
• n8n: log streaming - zdarzenia i logi jako element obserwowalności.
• OpenClaw: agent runtime - runtime agentowy jako proces z własnym workspace i sesjami.
• Hermes Agent: dokumentacja Nous Research - runtime zbudowany przez Nous Research, który obsługujemy jako warstwę wykonawczą, nie model ani gwarancja poprawności procesu.
• RODO / GDPR, rozporządzenie 2016/679 - zasady przetwarzania, rozliczalność, bezpieczeństwo i zautomatyzowane decyzje.

Sprawdź też: Agent AI do raportowania finansowego | Agenci AI dla firm - automatyzacja procesów | Agent AI - ile kosztuje?