Trzy use cases AI w e-commerce, które realnie działają

Zapytaj dziesięciu dostawców o „AI w e-commerce”, a dziewięciu pokaże Ci chatbota, który odpowiada na pytania z FAQ. To najczęstsze, najtańsze i najmniej wartościowe zastosowanie sztucznej inteligencji w sklepie — wdrożone po to, żeby na stronie pojawił się znaczek „AI-powered”, a nie po to, żeby cokolwiek zmieniło się w wyniku finansowym.

Ten artykuł jest o czymś innym. Pokazujemy trzy use cases, które wdrożyliśmy produkcyjnie i które codziennie pracują w realnych sklepach. Dla każdego opisujemy to samo: jaki problem biznesowy rozwiązuje, jak naprawdę działa pod spodem (mechanizm, potrzebne dane, punkty integracji), skąd bierze się zwrot z inwestycji — i, równie ważne, kiedy nie warto go wdrażać. Bo najuczciwsza rekomendacja dotycząca AI brzmi często: „w Waszym przypadku to się nie zwróci”.

Dlaczego większość „AI w e-commerce” to teatr

Chatbot FAQ jest teatrem, bo nie ma dostępu do niczego, co ma znaczenie. Nie zna stanu magazynu, nie widzi statusu zamówienia klienta, nie zna reguł promocji, nie potrafi policzyć rabatu. Odpowiada na pytania ogólne, których klient i tak nie zadaje — a przy pierwszym konkretnym pytaniu odsyła do formularza kontaktowego. Wdrożenie zajmuje tydzień, kosztuje niewiele i nie rusza żadnej metryki, bo nie zostało podłączone do żadnego procesu, który tę metrykę tworzy.

Nieudane projekty AI zawodzą zwykle na jeden z trzech sposobów, i warto je rozpoznawać, zanim podpiszesz umowę. Pierwszy: model nie jest podłączony do żywych danych, więc odpowiada ogólnikami zamiast faktami z Twojego systemu. Drugi: rozwiązuje problem, którego nie masz — buduje asystenta tam, gdzie wystarczyłby dobry filtr. Trzeci: nikt nie zdefiniował, co ma się zmienić, więc po wdrożeniu nie da się powiedzieć, czy cokolwiek działa. Każdy z tych trzech błędów jest do uniknięcia — ale tylko przed startem, nie po.

Nasza zasada jest odwrotna: zaczynamy od problemu biznesowego, nie od technologii. Pytanie nie brzmi „gdzie wcisnąć AI”, tylko „czy AI rozwiązuje ten konkretny problem lepiej i taniej niż alternatywy, które już istnieją”. Jeśli dobra wyszukiwarka z filtrami załatwia sprawę — odradzamy AI. Jeśli trzy dashboardy odpowiadają na 90% pytań zarządu — odradzamy asystenta analitycznego. AI ma sens wyłącznie tam, gdzie realnie zdejmuje pracę, skraca czas decyzji albo domyka sprzedaż, której inaczej byś nie domknął.

Chatbot, który nie ma dostępu do Twojego magazynu, cennika i statusu zamówień, nie jest „AI w e-commerce”. To widżet. Wartość zaczyna się dopiero tam, gdzie model dostaje dostęp do Twoich prawdziwych danych i prawdziwych procesów.

Wszystkie trzy use cases poniżej łączy jedno: model jest podłączony do żywych danych sklepu i wykonuje konkretną pracę w konkretnym procesie. To jedyny rodzaj AI, który przynosi mierzalny zwrot — i jedyny, który wdrażamy.

Use case 1: Asystent zakupowy i kasa samoobsługowa

Ten sam silnik obsługuje dwa kanały: ekran kasy samoobsługowej w sklepie stacjonarnym i widżet w sklepie online. Wdrożyliśmy go produkcyjnie u klienta retail.

Problem biznesowy

Klient stoi przy kasie samoobsługowej albo przegląda katalog online i utyka: nie znajduje produktu, nie wie, czy obejmuje go promocja, nie umie zeskanować kodu, nie jest pewny, czy dany wariant jest dostępny. W sklepie stacjonarnym woła pracownika — jeśli akurat któryś jest wolny. Online po prostu wychodzi. Każda z tych sytuacji to albo zajęty czas obsługi, albo porzucony koszyk.

Jak to naprawdę działa

To nie jest chatbot doklejony do strony. To model klasy GPT-4 osadzony w architekturze RAG (retrieval-augmented generation): pytanie klienta trafia najpierw do wyszukiwania po zwektoryzowanym katalogu produktów, a model formułuje odpowiedź wyłącznie na podstawie tego, co realnie znajdzie w Twoich danych. Do tego dochodzą wywołania funkcji do żywych systemów — sprawdzenie stanu magazynowego, statusu zamówienia, reguł promocji. Dzięki temu asystent nie „zmyśla” ceny: albo zna ją z systemu, albo mówi, że nie wie i kieruje do obsługi. Ta jedna różnica — odpowiedź pobrana z systemu zamiast wygenerowana przez model — jest tym, co odróżnia asystenta produkcyjnego od ozdobnego chatbota. Klient przy kasie nie może dostać ceny, której nie zaakceptuje paragon, ani obietnicy dostępności, której nie potwierdza magazyn. Cała inżynieria tego use case'u sprowadza się do trzymania modelu na krótkiej smyczy Twoich prawdziwych danych.

Czego potrzebuje takie wdrożenie:

• Czystego katalogu produktów — nazwy, atrybuty, warianty, ceny, dostępność. To fundament; o jego jakości piszemy niżej i to on decyduje o wszystkim.
• API cennika i promocji — żeby odpowiedź o rabacie była zgodna z tym, co naliczy kasa. Rozbieżność tu jest gorsza niż brak asystenta.
• Statusu magazynu i zamówień — dostępność konkretnego wariantu, śledzenie przesyłki.
• Punktu styku — ekranu kasy samoobsługowej lub widżetu w sklepie online. Logika jest wspólna dla obu kanałów (omnichannel), różni się tylko interfejs.

Skąd bierze się ROI

W naszym wdrożeniu retailowym asystent zdjął z obsługi rzędu 60% czasu, który pracownicy poświęcali wcześniej na wsparcie przy kasach w pierwszych miesiącach. To są realne godziny etatów przesunięte do zadań o wyższej wartości — nie „usprawnienie”, tylko policzalna pojemność zespołu. Online ten sam mechanizm domyka koszyki, które inaczej zniknęłyby przy pierwszym „nie wiem, czy to pasuje”. Zwrot jest mierzalny, bo metrykę — czas obsługi, wskaźnik porzuceń — definiujemy przed startem, a nie dorabiamy do wyniku.

Kiedy nie warto

Jeśli masz mały katalog, niski ruch przy kasach i sprawne wyszukiwanie z filtrami, asystent nie zwróci kosztu — bo nie ma z czego. Jeśli Twoje dane produktowe są w nieładzie, najpierw uporządkuj dane: asystent oparty na śmieciowym katalogu będzie pewnie i elegancko podawał błędne odpowiedzi, a to jest gorsze niż brak asystenta w ogóle.

Use case 2: Wyszukiwanie wizualne (visual search)

Klient wyszukuje produkty, robiąc im zdjęcie zamiast opisywać je słowami. Ten use case wdrożyliśmy u klientów D2C z bogatym katalogiem wizualnym.

Problem biznesowy

Klient widział produkt — mebel u znajomego, kurtkę na zdjęciu, lampę w kawiarni — i chce go kupić, ale nie umie go opisać. Wpisuje „taka drewniana lampa w stylu retro” i wyszukiwarka tekstowa zwraca albo za dużo, albo nic. Intencja zakupowa jest wysoka, a bariera opisu ją zabija. To sprzedaż, którą tracisz nie na cenie ani na dostępności, tylko na tym, że klient nie potrafi nazwać tego, czego chce.

Jak to naprawdę działa

Klient robi zdjęcie. Model wizyjny (klasy CLIP) koduje to zdjęcie do wektora w tej samej przestrzeni, w której wcześniej osadziliśmy zdjęcia całego Twojego katalogu; wyszukiwanie najbliższych sąsiadów zwraca produkty najbardziej podobne wizualnie. Wcześniejsza detekcja obiektu pozwala rozpoznać i zawęzić kategorię, żeby nie mieszać krzeseł z lampami. Katalog wektoryzujemy raz, a potem doindeksowujemy przy każdej zmianie asortymentu — inaczej nowości nie da się znaleźć.

Co jest tu krytyczne:

• Spójna, dobrej jakości fotografia produktowa — to jest paliwo tego use case'u. Im bogatszy i bardziej „wizualny” katalog, tym trafniejsze dopasowania.
• Indeks wektorowy nad zdjęciami katalogu, aktualizowany razem z asortymentem.
• Taksonomia kategorii — do zawężania i sensownego sortowania wyników.
• Wygodny upload, zwłaszcza mobilny — to na telefonie klient robi zdjęcie, więc tam musi być bezproblemowo.

Skąd bierze się ROI

W kategoriach napędzanych wyglądem — moda, meble, wystrój wnętrz, akcesoria — wyszukiwanie po zdjęciu podnosi konwersję zwykle o kilkanaście procent (w naszych wdrożeniach rzędu 12–18% w sklepach z bogatym katalogiem wizualnym). Mechanizm jest prosty: odzyskujesz intencję „widziałem to gdzieś”, której wyszukiwarka tekstowa nie obsłuży, i skracasz drogę od zdjęcia do koszyka do kilku sekund.

Kiedy nie warto

Przy katalogach opartych na specyfikacji, a nie na wyglądzie — śruby, kable, komponenty B2B — wyszukiwanie parametryczne po tekście jest po prostu lepsze; zdjęcie niczego nie rozróżni między dwiema niemal identycznymi częściami. Jeśli fotografia jest uboga albo niespójna, albo katalog jest mały, visual search będzie gadżetem, nie narzędziem sprzedaży. A jeśli klienci sprawnie znajdują produkty po nazwie lub kodzie SKU — nie masz problemu do rozwiązania.

Use case 3: Asystent analityczny nad danymi sklepu

Osoba zarządzająca sklepem pyta o dane po polsku, zamiast pisać zapytania albo czekać na raport. Ten use case wdrożyliśmy u klienta B2B.

Problem biznesowy

Właściciel albo dyrektor chce zapytać po polsku: „Pokaż 10 najbardziej rentownych produktów z ostatnich 30 dni z trendem rok do roku”. Dziś oznacza to albo napisanie zapytania SQL, albo przeklikanie czterech raportów, albo — najczęściej — zgłoszenie do działu IT i czekanie dwa dni. Wiedza jest w danych, ale dostęp do niej jest wąskim gardłem, a przez to część decyzji zapada „na czuja”, mimo że liczby leżą w bazie.

Jak to naprawdę działa

LLM (Claude lub GPT-4) pełni rolę warstwy tłumaczącej język naturalny na zapytanie do Twoich danych. Pytanie po polsku zamieniane jest na zapytanie do bazy zamówień, klientów i produktów, wykonywane na realnych danych, a wynik wraca jako liczby plus zwięzły opis. Rzecz kluczowa: model nie „zna” Twojej sprzedaży z treningu — on odpytuje Twoją bazę na żywo. Nad bazą kładziemy warstwę semantyczną z definicjami metryk (co dokładnie znaczy „rentowność”), kontrolę dostępu (kto może pytać o co) i logowanie wszystkich zapytań.

Warunki, bez których to nie zadziała:

• Wiarygodne, dobrze zamodelowane dane sprzedażowe — spójny schemat albo hurtownia. Bez tego odpowiedzi będą jednocześnie pewne i błędne.
• Przypięte definicje metryk — inaczej „marża” znaczy co innego w każdej odpowiedzi i nikt nie zaufa narzędziu.
• Kontrola dostępu i audyt zapytań — bo to warstwa nad wrażliwymi danymi finansowymi, nie nad opisami produktów.

Skąd bierze się ROI

Tu zwrot jest inny niż w dwóch poprzednich — to demokratyzacja danych. Osoby decyzyjne dostają odpowiedzi bez pośrednictwa IT i bez kolejki do analityka. Wartość leży w skróconym czasie decyzji, nie w jednym efektownym procencie; jest trudniejsza do przypisania do konkretnej liczby, ale w praktyce oznacza decyzje szybsze, częstsze i lepiej ugruntowane w danych. Dla sklepu, w którym co tydzień ktoś czeka na raport, to realna zmiana tempa pracy zarządu.

Kiedy nie warto

To najbardziej wymagający z trzech use case'ów — i najłatwiej go zepsuć. Jeśli Twoje dane są w nieładzie, dostaniesz najgorszą możliwą rzecz: model, który z pełnym przekonaniem poda błędną liczbę, a ta trafi do prezentacji zarządu. Jeśli masz trzy raporty odpowiadające na 90% pytań i nikt realnie nie zadaje pytań ad hoc — nie buduj tego. Halucynacja liczby w decyzji biznesowej jest droższa niż brak narzędzia.

To nie model jest wąskim gardłem, tylko Twoje dane

Jeśli z trzech powyższych sekcji przebija się jeden wzorzec, to ten: za każdym razem, gdy AI zawodzi, przyczyną są dane, nie model. Asystent zakupowy jest tak dobry, jak czysty jest katalog. Visual search jest tak dobry, jak spójna jest fotografia. Asystent analityczny jest tak dobry, jak wiarygodna jest hurtownia. Modele klasy GPT-4 czy Claude są już dziś wystarczająco dobre dla e-commerce — to nie one są ograniczeniem.

Nie budujemy modeli od zera dla typowych zastosowań e-commerce. Foundation models plus fine-tuning albo RAG są tańsze i lepsze niż własny trening. Prawdziwa praca — i prawdziwy budżet — idą w uporządkowanie danych, nie w model.

Dlatego zanim policzymy ROI z AI, często rekomendujemy najpierw uporządkowanie danych produktowych — to jest dokładnie ta praca, którą wykonujemy przy wdrożeniach PIM. Bez czystego, kompletnego katalogu każdy z tych use case'ów startuje z ujemnego pułapu, a Ty płacisz za model, który nie ma z czego korzystać.

Druga rzecz, która odróżnia wdrożenie produkcyjne od efektownego demo, to inżynieria wokół modelu:

• Monitoring i fallbacki — gdy model albo API dostawcy nie odpowiada, proces sprzedażowy nie może się zatrzymać. Musi być plan B.
• Kontrola kosztów API — cache'owanie odpowiedzi, dobór modelu do zadania (tańszy, mniejszy model często wystarcza), twarde limity zużycia.
• Bezpieczeństwo i RODO — konfiguracja zerowej retencji danych po stronie dostawcy (OpenAI Enterprise, Anthropic z BAA), anonimizacja danych wrażliwych przed wysłaniem do modelu, audyt RODO przed wejściem na produkcję.

Który use case pasuje do Twojego sklepu

Skrócona mapa decyzyjna — od czego zależy, czy dany use case się zwróci, i kiedy lepiej odpuścić:

Ile to kosztuje

Nie podajemy tu sztywnej ceny i robimy to celowo. Koszt wdrożenia AI zależy od trzech rzeczy: złożoności use case'u, liczby integracji i wymaganego poziomu bezpieczeństwa danych. Z grubsza rośnie w kolejności, w jakiej opisaliśmy use cases — asystent zakupowy jest zwykle najprostszy, a asystent analityczny nad wrażliwą bazą finansową najbardziej wymagający, bo dochodzą kontrola dostępu i audyt. Do jednorazowego wdrożenia trzeba doliczyć stały, przewidywalny koszt wywołań API — rzędu miesięcznego kosztu jednego narzędzia w firmowym stacku, nie osobnego etatu.

Zamiast obietnic definiujemy KPI biznesowe przed startem i mierzymy je w oknie 90 dni. Jeśli po tym czasie cel nie jest osiągnięty, najpierw szukamy przyczyny — zwykle leży ona w danych, nie w modelu — i poprawiamy bez dodatkowych kosztów. Jeśli okaże się, że AI po prostu nie pasuje do tego problemu, w naszych umowach zwracamy część wartości projektu. To jest robocza definicja „mierzalnego ROI”, a nie slogan na landing page.

Podsumowanie

AI w e-commerce działa dokładnie wtedy, gdy przestaje być ozdobą, a zaczyna być podłączone do Twoich danych i Twoich procesów. Trzy use cases powyżej — asystent zakupowy, wyszukiwanie wizualne i asystent analityczny — łączy to, że każdy zdejmuje konkretną pracę albo domyka konkretną sprzedaż, a ich sukces zależy bardziej od jakości Twoich danych niż od wyboru modelu. Najczęściej najlepszą rekomendacją jest zawężenie: jeden use case, jeden zdefiniowany KPI, jedno okno 90 dni.

Jeśli chcesz sprawdzić, który z nich — jeśli którykolwiek — zwróci się w Twoim sklepie, szerzej opisaliśmy nasze podejście na stronie AI w e-commerce. A jeśli wolisz od razu porozmawiać o konkretnym problemie i danych, które masz — napisz do nas. Zaczniemy od pytania, czy AI jest tu w ogóle właściwym narzędziem.