Zakupy przez asystenta AI — co to znaczy dla sklepu

Zakupy przez asystenta AI to handel, w którym część pracy zakupowej wykonuje program: interpretuje zapytanie, porównuje oferty, składa koszyk, a na niektórych powierzchniach domyka też płatność w imieniu kupującego. Sklep przestaje obsługiwać człowieka klikającego w szablon strony, a zaczyna obsługiwać oprogramowanie, które czyta ustrukturyzowane dane produktowe, wywołuje endpoint i przedstawia poświadczenie płatnicze ograniczone do jednej transakcji. Ciężar przenosi się z prezentacji na dokładność: kompletność danych, świeżość dostępności, maszynowo odczytywalne zasady dostawy i zwrotów oraz kasa, którą da się zainicjować z zewnątrz sklepu.

W skrócie

• To warstwa transakcyjna, nie taktyka widoczności. Bycie wymienionym w odpowiedzi AI i umiejętność przyjęcia zamówienia od agenta to dwa różne problemy, rozwiązywane w różnych miejscach sklepu.
• Istnieją dwa główne kształty zakupu. Agent może przekazać klienta do kasy sklepu albo — u kwalifikujących się sprzedawców i na obsługiwanych powierzchniach — poprowadzić checkout w swoim interfejsie.
• Powstają otwarte standardy, ale wdrożenia nie są identyczne. ACP opisuje integrację handlową w ekosystemie OpenAI, UCP standaryzuje szerszy cykl handlu agentowego, a AP2 zabezpiecza autoryzację i płatność wewnątrz protokołu handlowego.
• Cena i dostępność muszą przejść ponowną walidację. Feed pomaga znaleźć ofertę, lecz sklep odpowiada za aktualne sumy, stan, podatek i warunki realizacji w chwili checkoutu.
• W obecnych wdrożeniach OpenAI i Google sklep pozostaje sprzedawcą. Realizacja, zwroty, reklamacje i rozliczenia nie przechodzą automatycznie na operatora asystenta. W Polsce trzeba dodatkowo zaprojektować zgodny z prawem proces zawarcia umowy na odległość.
• Atrybucja zależy od ścieżki. Przekierowanie do sklepu może utworzyć zwykłą sesję. Natywny checkout przez API może jej nie mieć, dlatego źródło partnera trzeba zapisać na zamówieniu już podczas tworzenia checkoutu.
• Źródło danych zależy od architektury sklepu. Base (dawniej BaseLinker), ERP, WMS albo sama platforma mogą odpowiadać za różne pola. Liczy się jawny właściciel danych i kontrolowana synchronizacja.
• Blokowanie robotów nie jest właściwym narzędziem. Polityka crawlerów rządzi czytaniem, a uwierzytelnianie i limity na API rządzą transakcją.
• Awarie są operacyjne: zła cena podana przez asystenta, nieaktualna dostępność, promocje policzone tylko na froncie oraz reklamacja zamówienia, którego klient nigdy nie widział w sklepie.

Ten wpis dotyczy warstwy transakcyjnej. Warstwę nad nią — to, jak produkt trafia do porównania i cytowania w odpowiedzi AI — opisuje osobny materiał o Generative Engine Optimization i budowaniu widoczności w AI Search. Mechanikę tego, jak silniki dobierają źródła, wyjaśnia wpis o AI Overviews i cytowaniach marki, a stronę Google — tryb AI w Google. Tu zaczynamy w momencie, w którym asystent nie tylko poleca, ale prowadzi do zakupu albo kupuje.

Co się zmienia, gdy asystent kupuje, a nie poleca

Kupującym staje się program z timeoutem. Człowiek toleruje wolno ładującą się kartę produktu, wybór wariantu wymagający dwóch kliknięć i koszt dostawy pojawiający się w trzecim kroku kasy. Agent wywołuje endpoint, czeka określoną liczbę sekund i albo dostaje ustrukturyzowaną odpowiedź, albo przechodzi do sprzedawcy, który ją daje. Wszystko, co sklep dziś ukrywa za interakcją — wyliczaną dostawę, stan per magazyn, realną cenę po promocji koszykowej — musi istnieć jako dane przed interakcją.

Niespójna cena lub dostępność staje się ryzykiem transakcyjnym. Nieświeży feed może doprowadzić do odrzuconego koszyka, anulowania zamówienia albo różnicy między ofertą przedstawioną klientowi a sumą w checkoutcie. Dlatego feed służy do prezentacji i wyboru, a sklep ponownie waliduje cenę, stan, dostawę i podatek przed przyjęciem zamówienia. Tak dzieli odpowiedzialność dokumentacja handlowa OpenAI.

Nie każde zamówienie ma klasyczną sesję. Po przekierowaniu do kasy sklepu można zachować parametry kampanii i identyfikatory analityczne. Przy natywnym checkoutcie obsługiwanym przez API może natomiast nie istnieć przeglądarkowa wizyta w sklepie. Obu ścieżek nie wolno mierzyć tak samo — dlatego atrybucja ma niżej własną sekcję.

Zmienia się też jednostka konkurencji. Człowiek porównuje dwie, trzy karty produktu. Agent porównuje pola: identyfikator, atrybuty, dostępność, koszt i termin dostawy, warunki zwrotu. Sklep, w którym rozmiar istnieje tylko w tytule, a termin dostawy tylko w tekście regulaminu, nie przegrywa dlatego, że jest droższy. Przegrywa, bo nie da się go porównać.

Dwa kształty zakupu przez agenta

Większość wewnętrznego zamieszania bierze się z traktowania tych dwóch rzeczy jako jednej.

Sklep, który chce obsłużyć tylko pierwszy kształt, ma realną pracę do wykonania, a ta praca jest podzbiorem drugiego kształtu. Warstwy danych nie pomija nikt.

Warstwa protokołów: jak działa zakup przez agenta

Nie ma jednego protokołu obsługiwanego przez każdego asystenta i każdy sklep. W lipcu 2026 najważniejsze są trzy uzupełniające się elementy: ACP, UCP i AP2. Dokumentację trzeba czytać przed konkretnym wdrożeniem, ponieważ dostępność funkcji, programy partnerskie i zakres endpointów nadal się zmieniają.

Agentic Commerce Protocol (ACP)

ACP to otwarta specyfikacja łączenia kupujących, ich agentów i firm, rozwijana przez OpenAI i Stripe. Definiuje składane elementy, a nie jedną monolityczną integrację:

• Feed produktowy. Regularnie odświeżany feed — CSV albo JSON — z identyfikatorami, opisami, cenami, stanami, mediami i opcjami realizacji. Pola wymagane istnieją po to, żeby cena i dostępność mogły być pokazane poprawnie; atrybuty rekomendowane, jak media, opinie i sygnały skuteczności, wpływają na trafność. Mechanikę samego feedu opisuje wpis o tym, czym jest feed produktowy i jak go wykorzystać.
• Checkout agentowy. Agent wywołuje endpointy sprzedawcy, żeby utworzyć, zaktualizować i domknąć sesję checkoutu. Sprzedawca niezależnie waliduje dane, ustala opcje dostawy, liczy podatek, ocenia sygnały płatnicze i przeprowadza obciążenie.
• Płatność delegowana. Zamiast przekazywać dane karty, platforma agenta przygotowuje jednorazowe żądanie płatności ograniczone maksymalną kwotą obciążenia i terminem ważności. Shared Payment Token od Stripe jest opisywany jako pierwsza implementacja zgodna z tą specyfikacją.

Podział odpowiedzialności ma tu większe znaczenie niż format przesyłanych danych. Dokumentacja OpenAI stwierdza, że OpenAI nie jest merchant of record: sklep waliduje, obciąża, realizuje i rozlicza podatek — razem z częściami, których nikt nie lubi, czyli zwrotami i chargebackami.

Trzeba też rozdzielić specyfikację od dostępności produktu. Dokumentacja OpenAI informuje, że Instant Checkout jest obecnie udostępniany zatwierdzonym partnerom. Sklep nie uzyskuje więc natywnej sprzedaży w ChatGPT przez samo opublikowanie feedu: musi spełnić wymagania programu i przejść właściwy proces integracyjny.

Universal Commerce Protocol (UCP)

UCP to otwarty standard opisujący szerszy cykl handlu agentowego: od wyszukania i prezentacji katalogu, przez koszyk, powiązanie tożsamości i checkout, po obsługę zamówienia po zakupie. Google wykorzystuje go do funkcji bezpośredniego zakupu w AI Mode i Gemini, a dokumentacja Merchant Center przewiduje zarówno natywny checkout, jak i osadzoną kasę sprzedawcy.

UCP może korzystać z istniejących danych Merchant Center i współpracować z AP2, A2A oraz MCP. Nadal nie oznacza to automatycznej dostępności dla każdego sklepu: Google prowadzi proces zgłoszeniowy, a część funkcji — między innymi rozbudowane koszyki, powiązanie kont i obsługa po zakupie — jest wdrażana etapami. Także w tym modelu sprzedawca pozostaje merchant of record.

Agent Payments Protocol (AP2)

AP2 to otwarty protokół Google dla warstwy autoryzacji i bezpieczeństwa płatności: pozwala udokumentować, że agent miał zgodę na konkretny zakup i użycie określonego instrumentu płatniczego. Specyfikacja opisuje podpisane mandaty — między innymi Checkout Mandate utrwalający uzgodnione pozycje i warunki oraz Payment Mandate autoryzujący płatność.

AP2 nie zastępuje katalogu, koszyka ani API checkoutu. Dokumentacja określa go jako mechanizm bezpieczeństwa działający wewnątrz protokołu handlowego i wskazuje zgodność z UCP. Praktyczny wniosek jest prosty: protokół handlowy prowadzi proces zakupu, a AP2 tworzy możliwy do zweryfikowania ślad zgody. Taki zapis pomaga przy rozliczeniach i sporach, ale nie zwalnia sklepu z poprawnej walidacji zamówienia ani z obowiązków konsumenckich.

Szczegóły po stronie dostawców zmieniają się szybko. To stan na lipiec 2026 — wersje protokołów, kształty endpointów, nazwy agentów i programy dla sprzedawców są regularnie zmieniane, więc przed wdrożeniem należy sprawdzić dokumentację dostawcy z listy źródeł na końcu.

Gdzie w tym są asystenci

W przypadku zakupów w ChatGPT dokumentacja pomocy OpenAI opisuje wyniki produktowe pokazywane przy zapytaniach o intencji zakupowej, wybierane niezależnie, a nie sprzedawane jako reklamy, na podstawie ustrukturyzowanych metadanych od dostawców własnych i zewnętrznych oraz szczegółów takich jak cena i opinie. Wybór sprzedawcy może brać pod uwagę dostępność, cenę, jakość oraz to, czy sprzedawca jest producentem lub głównym sprzedawcą — co jest osobnym tematem strategicznym dla marek sprzedających przez resellerów i dla resellerów sprzedających marki obce.

W przypadku Perplexity i innych silników odpowiedzi zachowanie trzeba mierzyć, a nie odczytywać ze specyfikacji: odpowiedzi zakupowe, karty produktów i programy dla sprzedawców zmieniają kształt w czasie. Zamiast zakładać, że jedno ustawienie tym rządzi, lepiej utrzymywać reprezentatywny zestaw zapytań i przeglądać logi serwera. W przypadku Google widoczność produktu nadal opiera się między innymi na poprawnych danych Merchant Center i kwalifikowalności powierzchni Google. UCP dodaje warstwę transakcyjną dla obsługiwanych programów; nie jest znacznikiem SEO, który sam zwiększa widoczność w odpowiedziach AI.

Osobna sprawa to reklama na tych powierzchniach — to inny mechanizm niż zakup przez agenta i opisuje go wpis o reklamach w ChatGPT.

Słowniczek

• Zakupy przez asystenta AI (agentic commerce) — handel, w którym agent AI wykonuje kroki zakupowe w imieniu kupującego, aż do domknięcia kasy włącznie.
• Checkout agentowy — przepływ kasy tworzony i prowadzony wywołaniami API z zewnątrz sklepu, a nie przez człowieka na froncie.
• Sesja checkoutu — obiekt po stronie serwera przechowujący koszyk, dane kupującego, opcje dostawy, podatek i sumy dla jednej próby zakupu prowadzonej przez agenta.
• Token płatności delegowanej — jednorazowe poświadczenie płatnicze ograniczone maksymalną kwotą i terminem ważności, przekazywane sprzedawcy lub jego operatorowi płatności zamiast danych karty.
• Mandat — w AP2 podpisany zapis tego, co zostało ustalone: które pozycje i szczegóły zakupu oraz który instrument płatniczy jest autoryzowany.
• Merchant of record — podmiot rozliczający sprzedaż i odpowiadający za elementy transakcji wskazane w umowie i przepisach; w opisanych wdrożeniach OpenAI i Google pozostaje nim sprzedawca.
• Klucz idempotencji — identyfikator przekazany przez klienta API, który pozwala rozpoznać ponowione wywołanie jako to samo żądanie, więc awaria sieci nie tworzy dwóch zamówień.
• Maszynowo odczytywalne zasady — reguły dostawy, zwrotów i gwarancji wyrażone jako pola strukturalne, które agent potrafi ocenić, a nie jako proza na podstronie.

Co sklep musi mieć, żeby agent mógł złożyć zamówienie

Każdy wiersz to zdolność operacyjna, nie zakup narzędzia.

Kompletność danych produktowych jest bramką

Większość sklepów przewraca się tu pierwsza i rzadko wygląda to na problem z danymi. Wygląda na produkt, którego rozmiar żyje tylko w tytule, wariant, którego kolor istnieje na froncie, ale nie w feedzie, albo zestaw, który istnieje wyłącznie jako reguła front-endu. Agent nie wywnioskuje żadnej z tych rzeczy: jeżeli atrybut nie jest polem, produkt nie jest porównywalny, a produkt, który nie jest porównywalny, nie zostaje wybrany. Szerszy przegląd tego, co jeszcze w sklepie się rozjeżdża, jest we wpisie o tym, jak wykonać audyt sklepu internetowego.

Świeżość potrzebuje liczby i właściciela

„Prawie w czasie rzeczywistym” nie jest specyfikacją. O gotowości decydują dwa pytania: jakie maksymalne opóźnienie jest dopuszczalne między systemem nadrzędnym a wartością udostępnianą agentowi oraz kto odpowiada za każde pole. Agent może czytać dane z prawidłowo synchronizowanego feedu, pamięci podręcznej albo warstwy API — nie musi odpytywać bezpośrednio systemu zapisującego — ale opóźnienie i błędy synchronizacji muszą być mierzone.

Checkout inicjowany z zewnątrz to zobowiązanie inżynierskie

Utworzenie zamówienia z uwierzytelnionego wywołania z zewnątrz oznacza obsługę podatku, dostawy, promocji, rezerwacji stanu, idempotentnych ponowień, anulowania i zwrotów zgodnie z tymi samymi regułami domenowymi, z których korzysta front. Inaczej sklep prowadzi dwa przepływy i dwa zestawy błędów. Przy projektowaniu dedykowanego sklepu internetowego warto więc od początku oddzielić reguły handlowe od interfejsu. Nie znaczy to jednak, że każda firma potrzebuje systemu pisanego od zera — liczą się możliwości integracyjne, własność danych i kontrola nad checkoutem.

Polski kontekst operacyjny: Base, punkty odbioru i zwroty

Specyfikacje są międzynarodowe, ale pola, których agent nie znajdzie, są bardzo lokalne.

Base, ERP i platforma sklepu muszą mieć jasno podzielone role

W polskim e-commerce stan i cena mogą być utrzymywane w platformie sklepowej, systemie ERP, WMS albo Base (dawniej BaseLinker). Nie ma jednego poprawnego układu dla wszystkich firm. Problem zaczyna się wtedy, gdy agent czyta cenę z feedu odświeżanego według jednego harmonogramu, sklep wylicza promocję wyłącznie na froncie, a system integracyjny ma trzecią wartość po synchronizacji z hurtownią. Jak podzielić role systemów, opisuje osobny wpis o integracji Base ze sklepem i ERP.

Praktyczna konsekwencja jest jedna: każde pole potrzebuje wskazanego systemu nadrzędnego, a wszystkie warstwy odczytowe muszą mieć monitorowaną świeżość. Checkout powinien ponownie sprawdzić cenę i dostępność przed przyjęciem zamówienia.

Dostawa: paczkomaty i punkty odbioru to dane, nie akapit

Polski koszyk rzadko kończy się jednym adresem. Kończy się wyborem między kurierem, paczkomatem i punktem odbioru, a każda z tych opcji ma inny koszt, inny termin i inne ograniczenie gabarytu. Agent, który ma zwrócić kupującemu koszt i termin dostawy, potrzebuje tych reguł jako pól: dostępne metody, koszt per metoda i próg darmowej dostawy, godzina cut-off, ograniczenia wymiarów i wagi, obsługa dostawy do punktu jako osobnej metody z własnym identyfikatorem lokalizacji. Zapis „wysyłamy zwykle w 24 godziny, szczegóły w regulaminie” jest dla agenta pustym polem. Strategiczną stronę samego progu opisuje wpis o darmowej dostawie w sklepie internetowym.

Zwroty i prawo odstąpienia

W sprzedaży na odległość konsumentowi co do zasady przysługuje prawo odstąpienia od umowy w ciągu 14 dni, z ustawowymi wyjątkami. Sprzedawca ma też obowiązki informacyjne, a interfejs składający odpłatne zamówienie musi jednoznacznie komunikować obowiązek zapłaty. Integracja agentowa powinna zatem przekazywać wymagane informacje przed zawarciem umowy, utrwalać potwierdzenie na trwałym nośniku i zachowywać dowód tego, co klient zaakceptował. Zakres zależy od produktu, rynku i przebiegu transakcji, więc przed uruchomieniem potrzebna jest weryfikacja prawna — sam standard techniczny nie zapewnia zgodności z polskim prawem.

Allegro i inne marketplace to osobna powierzchnia

Sprzedaż przez marketplace nie znika, a dla wielu polskich sklepów to nadal największy kanał. Warto rozdzielać dwie rzeczy: ofertę wystawioną na Allegro rządzi regulamin i API tej platformy, a nie protokół agentowy, natomiast dane produktowe, które trafiają na marketplace i do feedu dla asystenta, zwykle wychodzą z tego samego miejsca. Porządek w atrybutach i identyfikatorach opłaca się dwa razy. Stronę reklamową samego kanału opisuje przewodnik po Allegro Ads.

Atrybucja zamówień agentowych: GA4 to tylko część obrazu

Najpierw trzeba rozpoznać ścieżkę zakupu. Jeżeli asystent przekierowuje użytkownika do sklepu, parametry kampanii i sesja mogą powstać normalnie. Jeżeli natywny checkout odbywa się przez API, w domenie sklepu może nie być wizyty, referrera ani identyfikatora przeglądarki. Sama zmiana konwencji UTM nie naprawi braku sesji. Jak GA4 przypisuje ruch, kiedy sesja istnieje, opisuje wpis o źródle, medium i źródłach ruchu w GA4.

GA4 Measurement Protocol pozwala wysłać zdarzenie zakupu z serwera, ale służy do uzupełniania pomiaru. Aby wiarygodnie połączyć zdarzenie z istniejącym użytkownikiem lub sesją, potrzebne są prawdziwe identyfikatory, takie jak client_id i — w odpowiednim scenariuszu — session_id. Gdy partner ich nie przekazał albo zgoda nie pozwala ich wykorzystać, nie należy ich wymyślać. Zdarzenie może wtedy wspierać raportowanie techniczne, lecz źródłem prawdy o kanale i przychodzie pozostaje system zamówień.

Podejście, które działa, polega na tym, żeby przestać oczekiwać od analityki odkrycia kanału i zamiast tego zapisać go u źródła:

• Etykietować zamówienie w momencie tworzenia sesji checkoutu. Sklep wie, które poświadczenie wykonało wywołanie; z uwierzytelnionego wywołującego wyprowadza się wartość kanału i zapisuje ją na zamówieniu jako pełnoprawne pole.
• Trzymać jedno zamówienie na jeden zakup agenta, kluczowane idempotentnie. Ponowienia są w handlu przez API normalne, a duplikaty niszczą każdą liczbę w dół strumienia.
• Uzgadniać w systemie zamówień. Przychód per partner dla checkoutów natywnych jest przede wszystkim pytaniem do bazy handlowej; GA4 może być warstwą dodatkową.
• Nie fabrykować identyfikatorów. Sztuczny client_id albo session_id nie odtwarza prawdziwej wizyty i zniekształca raporty.
• Oddzielać sygnał od hipotezy. Zmiany w ruchu brandowym lub bezpośrednim mogą współwystępować z ekspozycją w AI, ale same nie dowodzą jej wpływu.

Ostatni wiersz projektuje się przed tym, jak stanie się potrzebny. Spór sześć tygodni po zakupie przez agenta da się rozstrzygnąć tylko wtedy, gdy sklep zachował to, co podał, kiedy to podał i przy jakim stanie magazynowym.

Gdzie to się psuje

Cena, którą asystent podał źle. Wycena może pochodzić z zbuforowanego feedu, nieaktualnej ceny kategorii albo promocji, którą front liczy, a API nie. Sklep wybiera wtedy między honorowaniem kwoty, której nie ustalił, a odrzuceniem zakupu, który kupujący uważa za zakończony. Środkiem zaradczym jest jedno źródło ceny, promocje liczone po stronie serwera i zdefiniowana reguła na wypadek, gdy suma sesji nie zgadza się z ceną z feedu.

Dostępność, która była prawdziwa godzinę temu. Nadsprzedaż w normalnym sklepie kończy się mailem z przepraszam. Nadsprzedaż wobec agenta kończy się anulowanym zamówieniem agentowym, a dostępność jest wprost wymieniana wśród okoliczności branych pod uwagę przy wyborze sprzedawcy w dokumentacji OpenAI. Dokładność stanów przestaje być sprawą magazynu i staje się sprawą dystrybucji.

Reklamacja zakupu, którego klient nigdy nie zobaczył w sklepie. Kupujący pamięta asystenta, nie sklep. Może nie mieć konta, może nie rozpoznać nazwy sklepu na wyciągu i może najpierw napisać do platformy asystenta. Obsługa potrzebuje sposobu na znalezienie zamówienia bez zwykłego śladu sesji i konta, a zespół musi wiedzieć, że sklep odpowiada za zwrot, reklamację i odstąpienie niezależnie od tego, gdzie zakup się zaczął. Warto z góry ustalić, jak brzmi opis na wyciągu bankowym i jaki jest tryb kontaktu z platformą.

Promocje, które istnieją tylko na froncie. Reguła koszykowa policzona w JavaScripcie nie istnieje dla sesji API. Efektem jest cena wyższa niż ta, którą zobaczyłby człowiek, albo — co gorsze — cena niższa, której sklep nie chciał dać.

Nadużycia wchodzące legalnymi drzwiami. Zautomatyzowane wykupywanie, testowanie kart i scalping wyglądają jak ruch agentowy. Narzędziem są poświadczenia per partner z limitami zapytań i pułapami kwotowymi oraz monitoring odsetka odrzuceń, a nie reguła w robots.txt.

Blokowanie robotów jako polityka handlowa. Zablokowanie wszystkich agentów AI usuwa widoczność, ale nie ogranicza możliwości wywołania endpointu transakcyjnego, bo to inna warstwa. Odmowa zakupów agentowych jest decyzją o uwierzytelnianiu na API.

Jak podchodzimy do tego w Space Ads

W Space Ads zaczęlibyśmy od mapy systemów sklepu: właściciela ceny, stanu, atrybutów, promocji i statusu zamówienia oraz dopuszczalnego opóźnienia każdej synchronizacji. Następnie porównalibyśmy feed, kartę produktu i wartości obliczone w checkoutcie, a także sprawdzili jedną ścieżkę reguł handlowych dla frontu i API. Dopiero po uporządkowaniu danych ma sens integracja z wybranym programem partnerskim oraz praca nad widocznością — encją marki, treścią nadającą się do cytowania, dostępem robotów i pomiarem cytowań, opisana na stronie usługi AI SEO i widoczności marki w wyszukiwaniu AI. Kanał i identyfikator partnera zapisujemy na zamówieniu; zdarzenie GA4 dodajemy tylko wtedy, gdy można je wysłać zgodnie z dokumentacją i stanem zgód.

Plan przygotowania sklepu

1. Ustalić właścicieli pól. Dla ceny, stanu, atrybutów, statusu zamówienia i zwrotów wskazać jeden system nadrzędny per pole i zapisać to na papierze. Niejasność w tym punkcie unieważnia każdy dalszy krok.
2. Zmierzyć świeżość. Sprawdzić realne opóźnienie między prawdziwą wartością a wartością wystawioną na zewnątrz, ustawić próg i traktować jego przekroczenie jak incydent.
3. Domknąć luki w danych. Uzupełnić identyfikatory, wyprowadzić atrybuty z tytułów do pól, dopełnić macierz wariantów, wyrazić zasady dostawy i zwrotów jako pola strukturalne.
4. Opisać zasady per kategoria. Tam, gdzie terminy zwrotu albo ograniczenia dostawy różnią się w zależności od typu produktu, muszą różnić się także w danych.
5. Przejrzeć powierzchnię kasy. Czy zamówienie da się utworzyć, opodatkować, zsumować i anulować z uwierzytelnionego wywołania z zewnątrz, tą samą ścieżką kodu, którą używa front.
6. Dodać poświadczenia, limity i idempotencję. Jedno poświadczenie per partner, limity zapytań, pułapy kwotowe, ochrona przed powtórzeniem i logowanie zachowujące to, co zostało podane.
7. Zapisywać kanał przy tworzeniu sesji. Atrybucja na poziomie zamówienia zamiast archeologii w analityce.
8. Przygotować obsługę klienta i finanse. Kto odpowiada za zwrot, jak znaleźć zamówienie agentowe, co widnieje na wyciągu i jaka jest ścieżka eskalacji do platformy.
9. Monitorować reprezentatywny zestaw zapytań. Częstotliwość dopasować do tempa zmian oferty i sezonowości; wyniki czytać jako próbę i trend, nie pełny pomiar ekspozycji.

Częsty błąd → co zrobić zamiast tego

Najczęstsze pytania

Czym są zakupy przez asystenta AI?

Zakupy przez asystenta AI to handel, w którym agent AI wykonuje kroki zakupowe w imieniu kupującego — interpretuje zapytanie, porównuje opcje, składa koszyk, a na niektórych powierzchniach domyka kasę. Cechą wyróżniającą jest to, że transakcję inicjuje oprogramowanie przez interfejs maszynowy, a nie człowiek na froncie sklepu.

Czy to to samo co bycie polecanym przez asystenta zakupowego?

Nie. Polecenie to wynik widoczności: asystent wymienia produkt albo sprzedawcę w odpowiedzi. Zakupy przez asystenta to wynik transakcyjny: asystent albo przekazuje kupującego do kasy, albo sam domyka zakup. Sklep może być bardzo widoczny w odpowiedziach AI i jednocześnie nie być w stanie przyjąć zamówienia zainicjowanego przez agenta.

Czy do sprzedaży przez asystenta potrzebny jest ACP albo UCP?

Nie zawsze. Jeżeli asystent poleca produkt i odsyła klienta do sklepu, potrzebne są przede wszystkim poprawne dane produktowe, aktualny feed i działające linki. Integracja z ACP, UCP albo interfejsem konkretnego partnera staje się istotna wtedy, gdy checkout ma być prowadzony poza standardowym frontem sklepu. Wybór zależy od platformy i dostępności jej programu dla sprzedawców.

Kto jest sprzedawcą przy zakupie zrobionym przez agenta?

W opisanych wdrożeniach OpenAI i Google merchant of record pozostaje sprzedawca. To on waliduje zamówienie, realizuje dostawę oraz obsługuje zwroty i reklamacje w zakresie wynikającym z umowy i prawa. Nie należy jednak przenosić tej zasady automatycznie na każdy przyszły marketplace lub model pośrednictwa — odpowiedzialność trzeba sprawdzić w warunkach konkretnej integracji.

Czy sprzedaż przez agenty da się śledzić w GA4?

To zależy od ścieżki. Przekierowanie do kasy sklepu można mierzyć jak zwykłą wizytę, jeżeli partner przekazuje identyfikatory i parametry kampanii. Natywny checkout API może nie tworzyć sesji w domenie sklepu. GA4 Measurement Protocol pozwala wysłać zdarzenie serwerowe, ale nie wolno wymyślać client_id ani session_id. Kanał i partner powinny być zapisane na zamówieniu, a baza handlowa pozostaje podstawą raportowania przychodu.

Czy sklep powinien blokować roboty AI, jeżeli nie chce zakupów agentowych?

Blokowanie robotów to niewłaściwa kontrola. Dyrektywy dla crawlerów rządzą tym, czy treść może być czytana pod wyszukiwanie i trenowanie; nie rządzą tym, czy można wywołać endpoint transakcyjny. Odmowa zakupów agentowych jest decyzją o uwierzytelnianiu na API, a nie wpisem w robots.txt.

Co zwykle psuje się pierwsze, gdy sklep nie jest gotowy?

Dokładność dostępności i ceny. Pierwsze widoczne objawy to zamówienia agentowe do anulowania i sumy niezgodne z tym, co kupujący usłyszał, ponieważ feed albo cache rozjechały się z systemem, który jest właścicielem liczby.

Jak w tym układzie mieści się Base?

Base (dawniej BaseLinker) może synchronizować zamówienia, stany i ceny między sklepem, ERP, magazynem i marketplace'ami. Nie musi jednak być systemem nadrzędnym dla każdego pola. Przed integracją agentową trzeba ustalić właściciela danych, zmierzyć opóźnienia synchronizacji i ponownie walidować cenę oraz dostępność w checkoutcie.

Czy trzeba budować checkout agentowy już teraz?

Decyzja zależy od stanu warstwy danych, nie od terminu w kalendarzu. Sklep, który nie ma jednego właściciela ceny i stanu, kompletnych atrybutów i zasad dostawy w polach, przez wdrożenie checkoutu agentowego zwiększy tylko liczbę anulowanych zamówień. Kolejność jest odwrotna: najpierw dane i jedna ścieżka zamówienia, potem powierzchnia transakcyjna.

Najważniejsze

• Zakupy przez asystenta AI dotyczą transakcji, nie polecania; gotowość jest problemem operacyjnym i inżynierskim.
• Liczą się dwa kształty: przekazanie kupującego do kasy sklepu oraz checkout prowadzony w interfejsie agenta.
• ACP i UCP opisują proces handlowy w różnych ekosystemach, a AP2 stanowi warstwę autoryzacji i bezpieczeństwa płatności.
• W obecnych wdrożeniach OpenAI i Google sklep pozostaje merchant of record, dlatego integracja musi uwzględniać obsługę zamówień oraz obowiązki konsumenckie.
• Każde pole potrzebuje systemu nadrzędnego, monitorowanej synchronizacji i ponownej walidacji w checkoutcie.
• W polskim sklepie ważne są role Base, ERP, WMS i platformy sklepowej oraz dostawa do punktu opisana jako osobna metoda z kosztem i ograniczeniami.
• Checkout API może nie mieć sesji przeglądarkowej. Partnera zapisuje się na zamówieniu, a GA4 uzupełnia pomiar tylko wtedy, gdy istnieją prawidłowe identyfikatory i podstawy do ich użycia.

Źródła i dalsza lektura

• OpenAI Developers — Agentic Commerce: key concepts
• OpenAI Developers — Delegated Payment Spec
• Agentic Commerce Protocol — repozytorium specyfikacji
• Stripe Docs — Agentic Commerce Protocol
• Google for Developers — Universal Commerce Protocol
• Universal Commerce Protocol — specyfikacja UCP
• Google — dokumentacja Agent Payments Protocol (AP2)
• OpenAI Help Center — Shopping with ChatGPT Search
• Google Search Central — funkcje AI w wyszukiwarce a witryna
• Google Analytics — Measurement Protocol
• Base — dokumentacja API
• UOKiK — prawo do informacji przy sprzedaży na odległość
• UOKiK — odstąpienie od umowy

Nazwy agentów, wersje protokołów i programy dla sprzedawców to stan na lipiec 2026 — dostawcy zmieniają nazwy agentów, więc przed wdrożeniem należy sprawdzić aktualną dokumentację z linków powyżej.

Czytaj dalej

• Generative Engine Optimization — jak budować widoczność w AI Search
• AI Overviews, GEO i cytowania marki w wyszukiwaniu AI
• Integracja Base ze sklepem i ERP
• Czym jest feed produktowy i jak go wykorzystać
• Jak wykonać audyt sklepu internetowego
• Dedykowane sklepy internetowe
• AI SEO i widoczność marki w wyszukiwaniu AI