Agentic commerce: jak agenci AI kupują i płacą (przewodnik 2026)

Agent AI, który rezerwuje hotel, dokupuje kredyty API albo zamawia części do firmowego magazynu — i sam za to płaci — przestał być demem konferencyjnym. W 2025 roku Coinbase, Google, OpenAI, Stripe, Visa i Mastercard ogłosiły konkurencyjne rozwiązania do płatności realizowanych przez agentów. To jest agentic commerce: handel, w którym stroną kupującą jest oprogramowanie działające w Twoim imieniu.

Ten przewodnik wyjaśnia, jak to działa od zlecenia do rozliczenia, jakie protokoły konkurują o standard, co na to prawo UE — i jak wdrożyć płatności agentowe, nie tracąc kontroli nad pieniędzmi.

Czym jest agentic commerce w jednym zdaniu

Agentic commerce to transakcja, w której agent AI wyszukuje, wybiera i opłaca produkt lub usługę w imieniu człowieka lub firmy, w granicach nadanych mu uprawnień i limitów.

Kluczowe słowo to granice. Użytkownik nie oddaje agentowi karty „na żywioł” — nadaje mu mandat: co wolno kupić, u kogo, do jakiej kwoty i na jak długo. Agent działa wewnątrz tej koperty, a każdy krok zostaje zapisany.

To odróżnia agentic commerce od zwykłej automatyzacji (np. cyklicznej subskrypcji). Tu decyzję co i kiedy kupić podejmuje model na podstawie celu, a nie sztywna reguła.

Jak wygląda pojedyncza transakcja

Niemal każde wdrożenie sprowadza się do pięciu kroków:

1. Zlecenie — użytkownik formułuje cel: „Kup 50 kredytów API u zaufanego dostawcy, budżet 200 zł”.
2. Mandat i budżet — agent sprawdza nadane uprawnienia: limit kwotowy, listę dozwolonych sprzedawców, zakres czasowy.
3. Autoryzacja — jeśli kwota mieści się w limicie, zgoda jest automatyczna; powyżej progu agent pyta człowieka. To tu kończy się automat, a zaczyna kontrola.
4. Płatność — środki przechodzą przez protokół: jednorazowy token, wirtualna karta jednorazowa albo płatność stablecoinem. Sprzedawca dostaje pieniądze, agent zwykle nie widzi pełnych danych karty.
5. Rozliczenie — transakcja trafia do księgi: kto, komu, ile, kiedy i na jakiej podstawie. Podpisane i audytowalne.

Rozkładamy ten cykl na czynniki pierwsze w osobnym tekście: jak agent AI płaci — 5 kroków.

Protokoły, które walczą o standard

Rynek nie ma jeszcze jednego standardu. W 2025 roku pojawiły się równolegle:

• x402 (Coinbase) — reaktywuje zapomniany kod HTTP 402 Payment Required i pozwala płacić stablecoinem (USDC) bezpośrednio w odpowiedzi na żądanie HTTP. Dobre dla płatności maszyna-do-maszyny i mikropłatności za API.
• AP2 — Agent Payments Protocol (Google) — otwarty protokół, w którym każdy zakup to trzy podpisane mandaty: intencji (czego chce użytkownik), koszyka (co złożył agent) i płatności (ile obciąży sprzedawca lub sieć). Zaprojektowany, by działać i z kartami, i ze stablecoinami, z udziałem 60+ partnerów (m.in. Mastercard, PayPal, Coinbase, American Express).
• Agentic Commerce Protocol — ACP (OpenAI + Stripe) — stoi za funkcją Instant Checkout w ChatGPT; pozwala kupić u sprzedawcy bez wychodzenia z rozmowy z agentem.
• Karty: Visa Intelligent Commerce i Mastercard Agent Pay dokładają warstwę tokenizacji i uwierzytelniania agenta na istniejących szynach kartowych.

Czym te podejścia różnią się w praktyce — tłumaczymy w tekście x402, AP2 i tokeny jednorazowe.

Co na to prawo w Unii Europejskiej

Płatność agentowa nie dzieje się w próżni prawnej. Najważniejsze punkty:

• PSD2 (dyrektywa o usługach płatniczych) wymaga silnego uwierzytelnienia klienta (SCA). Pytanie „jak agent spełnia SCA, skoro to nie człowiek klika” jest jednym z najtrudniejszych w całym temacie.
• PSD3 i rozporządzenie PSR są w toku legislacyjnym i doprecyzują m.in. odpowiedzialność za oszustwa i dostęp do danych płatniczych.
• AI Act klasyfikuje systemy AI według ryzyka i nakłada obowiązki na dostawców oraz wdrażających — agent obracający pieniędzmi to nie błahy przypadek.

To nie jest porada prawna — przed wdrożeniem skonsultuj się z prawnikiem i licencjonowanym dostawcą usług płatniczych.

Kto jest kim w transakcji agentowej

Żeby zrozumieć ryzyka i odpowiedzialność, trzeba rozdzielić role — w agentic commerce jest ich więcej niż w klasycznym zakupie:

• Mocodawca (użytkownik/firma) — wyznacza cel i nadaje mandat. To w jego imieniu i na jego rachunek działa agent.
• Agent AI — wykonawca. Wyszukuje, wybiera i inicjuje płatność w granicach mandatu. Nie jest stroną umowy — działa jak pełnomocnik o wąskim zakresie.
• Sprzedawca (merchant) — wystawia ofertę w formie czytelnej dla maszyny i przyjmuje płatność.
• Dostawca usług płatniczych — licencjonowany podmiot, który realizuje i rozlicza transakcję oraz egzekwuje limity. To on, a nie agent, „dotyka pieniędzy”.
• Sieć/protokół — warstwa uzgodnień (x402, AP2, ACP, sieci kartowe), która pozwala tym stronom bezpiecznie się dogadać.

Najczęstszy błąd myślowy to zlanie agenta z mocodawcą. Rozdzielenie tych ról jest fundamentem zarówno bezpieczeństwa (kto co może), jak i prawa (kto za co odpowiada).

Ekonomia agentowa: dlaczego to się dzieje teraz

Agentic commerce nie wziął się z mody. Składają się na niego trzy dojrzewające jednocześnie elementy:

1. Modele zdolne prowadzić wieloetapowe zadania — dopiero agent, który potrafi zaplanować i wykonać sekwencję kroków, ma sens jako kupujący.
2. Standard płatności dla maszyny — przez lata brakowało bezpiecznego sposobu, by software zapłacił bez podawania pełnych danych karty. Protokoły z 2025 roku tę lukę domykają.
3. Presja kosztowa — automatyzacja drobnych, powtarzalnych zakupów (zasoby, API, zaopatrzenie) realnie oszczędza czas i redukuje błędy.

Efektem jest „ekonomia agentowa”: rynek, w którym częścią transakcji jest software działający autonomicznie. Najwcześniej widać ją tam, gdzie płatności maszynowe już istnieją — przy zakupie mocy obliczeniowej, danych i dostępu do API.

Cztery ryzyka, o których trzeba wiedzieć

Zanim przejdziemy do wdrożenia — cztery rzeczy, które mogą pójść nie tak, i kierunek mitygacji:

• Wydatek poza intencją — agent kupuje nie to, nie tyle albo nie tam. Mitygacja: wąski mandat i twardy limit po stronie dostawcy.
• Manipulacja (prompt injection) — spreparowana treść nakłania agenta do działania wbrew użytkownikowi. Mitygacja: lista dozwolonych sprzedawców, próg na zgodę człowieka, izolacja danych wejściowych.
• Brak rozliczalności — nie wiadomo, na jakiej podstawie agent zapłacił. Mitygacja: podpisany, audytowalny log każdej transakcji.
• Niejasna odpowiedzialność — kto pokrywa błąd: użytkownik, dostawca agenta czy sprzedawca? Mitygacja: jasne reguły mandatu i umowy z dostawcą płatności, zgodne z PSD2/PSD3.

Bezpieczeństwo i autoryzację rozwijamy w osobnym tekście o mandatach i limitach.

Jak wdrożyć to bezpiecznie

Cztery zasady, które powtarzają się w każdej rozsądnej architekturze:

• Mandat zamiast pełnomocnictwa — nadawaj wąskie, konkretne uprawnienia (kwota, sprzedawca, czas), nie „dostęp do karty”.
• Twarde limity po stronie systemu — limit egzekwowany przez dostawcę płatności, nie przez „obietnicę” modelu. Więcej w tekście o mandatach i limitach.
• Człowiek w pętli powyżej progu — automat dla drobnych kwot, zatwierdzenie człowieka dla istotnych.
• Pełny ślad audytowy — każda transakcja podpisana i odtwarzalna; to Twoja obrona przy sporze i przy kontroli.

Dla kogo to jest teraz

Najwcześniej skorzystają zespoły, które już dziś płacą maszynowo: za API, dane, infrastrukturę chmurową. Kolejne fale to zakupy B2B (zaopatrzenie), subskrypcje i marketplace’y. Konsumencki „agent, który robi zakupy” jest najbardziej widowiskowy, ale i najsilniej obwarowany prawem.

Jeśli prowadzisz sklep internetowy, sprawdź checklistę gotowości na agentic commerce — to konkretne kroki po stronie sprzedawcy.

Jeśli budujesz produkt, w którym agent ma wydawać pieniądze, zacznij od pytania nie „jak zapłacić”, lecz „jak zapanować nad tym, za co i ile zapłaci”. Reszta to inżynieria.