Agentic Commerce Readiness Audit B2B

Pełna nazwa: Agentic Commerce Readiness Audit B2B
Skrót: ACRA-B2B
Wersja: 1.0.0
Data referencyjna: 2 września 2026 r.
Status: Production Candidate / Audit Standard
Zakres: handel B2B, przemysł, dystrybucja, logistyka, intralogistyka, wyposażenie magazynowe, materiały eksploatacyjne, części, urządzenia, maszyny, usługi techniczne, rozwiązania konfigurowane i projektowe.

---

1. Cel standardu

Agentic Commerce Readiness Audit B2B służy do odpowiedzi na pytanie:

W jakim stopniu firma, witryna, kategoria, produkt lub usługa są przygotowane nie tylko do znalezienia i zrozumienia przez AI, ale również do kwalifikacji i wykonania kontrolowanej akcji przez człowieka, system procurement lub agenta AI?

Standard nie mierzy wyłącznie:

• SEO;
• widoczności w ChatGPT;
• schema.org;
• jakości treści;
• obecności API;
• posiadania MCP;
• liczby formularzy.

Bada cały łańcuch:

DISCOVER
↓
UNDERSTAND
↓
VERIFY
↓
QUALIFY
↓
ACT
↓
AUTHORIZE
↓
TRANSACT
↓
AUDIT

---

2. Cztery podstawowe poziomy dojrzałości

Standard definiuje cztery poziomy produkcyjne.

Level 1 — AI-Readable

Systemy AI mogą stosunkowo jednoznacznie:

• znaleźć firmę;
• znaleźć kategorię;
• zidentyfikować produkt;
• odczytać podstawowe dane;
• rozpoznać właściwą stronę;
• ustalić źródła najważniejszych informacji.

Firma posiada poprawną warstwę:

DISCOVERY + UNDERSTANDING.

---

Level 2 — Agent-Qualifiable

Oprócz powyższego system potrafi:

• porównać wymaganie z produktem;
• ustalić potencjalne dopasowanie;
• wskazać ograniczenie;
• zwrócić UNKNOWN;
• wykryć potrzebę konsultacji;
• zebrać brakujące informacje.

Firma posiada warstwę:

UNDERSTANDING + QUALIFICATION.

---

Level 3 — Action-Ready

System potrafi następnie wykonać prawidłowo opisaną akcję, np.:

• przygotować RFQ;
• wysłać RFQ;
• sprawdzić dostępność;
• zgłosić serwis;
• poprosić o próbkę;
• rozpocząć konsultację;
• zidentyfikować część;
• przygotować reorder.

Firma posiada:

ACTION CONTRACT + CONTROLLED EXECUTION.

---

Level 4 — Transaction-Ready

Dla właściwych klas produktów możliwe jest kontrolowane przejście do:

• reorder;
• order;
• reservation;
• formal quotation workflow;
• procurement workflow;
• innego działania wywołującego skutek handlowy.

System obsługuje przy tym:

• identity;
• authority;
• aktualną ofertę;
• approval;
• idempotency;
• status;
• audyt;
• bezpieczeństwo;
• wyjątki;
• human escalation.

Firma posiada:

GOVERNED AGENTIC COMMERCE.

---

3. Ważne: wynik punktowy nie wystarcza

Firma może mieć:

92/100

i nadal nie być Transaction-Ready.

Przykład:

• świetne treści;
• kompletne Product Master Data;
• schema;
• feed;
• API;
• kwalifikacja;

ale brak:

autoryzacji osoby/agenta składającego zamówienie.

Wtedy certyfikacja Transaction-Ready jest niedopuszczalna.

Dlatego ACRA-B2B wykorzystuje równolegle:

SCORE + GATES

---

4. Skala punktowa

Audit zawiera dokładnie:

100 kryteriów

podzielonych na:

Moduł	Zakres	Punkty
A	Governance i architektura	10
B	Discovery i AI visibility	10
C	Product / Service Truth	10
D	Evidence, freshness i commercial truth	10
E	Qualification	10
F	Action Architecture / Direct RFQ	10
G	Machine interfaces	10
H	Identity, authority, security	10
I	Transaction, reorder i lifecycle	10
J	Measurement, evals i operations	10
Razem		100

---

5. Punktacja pojedynczego kryterium

1,0 — PASS

Wymóg:

• istnieje;
• działa;
• można go udowodnić.

0,5 — PARTIAL

Wymóg:

• istnieje częściowo;
• dotyczy tylko części portfolio;
• jest niespójny;
• działa ręcznie;
• nie ma pełnego evidence.

0 — FAIL

Wymóg:

• nie istnieje;
• jest tylko planem;
• działa w sposób niewiarygodny;
• informacje są sprzeczne.

---

6. Evidence Levels

Każdy PASS powinien posiadać dowód.

E0 — No Evidence

Deklaracja bez dowodu.

E1 — Documented

Istnieje dokumentacja lub opis.

E2 — Observable

Można zobaczyć działanie w produkcji.

E3 — Machine Tested

Funkcja została sprawdzona automatycznie lub przez agenta.

E4 — Production Proven

Istnieją:

• logi;
• rzeczywiste RFQ;
• transakcje;
• statusy;
• audyt działania.

Dla wyższych poziomów readiness wymagane są wyższe poziomy evidence.

---

MODUŁ A — GOVERNANCE I ARCHITEKTURA

Cel

Sprawdzić, czy firma posiada kontrolowaną architekturę informacji zamiast zestawu niezależnych stron i systemów.

1. Scope Identity

Czy jasno wiadomo, co audytujemy:

• firmę;
• domenę;
• kategorię;
• produkt;
• usługę;
• proces?

2. Canonical Business Identity

Czy firma posiada jednoznaczną nazwę, identyfikatory i role:

• manufacturer;
• brand owner;
• distributor;
• seller;
• service provider;
• integrator?

3. Data Ownership

Czy wskazano właściciela danych produktowych?

4. Technical Ownership

Czy istnieje osoba/rola odpowiedzialna za poprawność techniczną?

5. Commercial Ownership

Czy wiadomo, kto odpowiada za:

• cenę;
• stock;
• lead time;
• warunki handlowe?

6. Publication Ownership

Czy wiadomo, kto odpowiada za publikację danych?

7. Correction Route

Czy istnieje procedura poprawienia błędnego parametru?

8. Versioning

Czy krytyczne rekordy, profile i schematy są wersjonowane?

9. Change Log

Czy materialne zmiany można odtworzyć?

10. [GATE] One Truth Architecture

Czy firma posiada zasadę:

One Product / Service Truth → Multiple Interfaces

zamiast ręcznie zarządzanych niezależnych kopii?

---

MODUŁ B — DISCOVERY I AI VISIBILITY

Cel

Sprawdzić, czy człowiek i system AI mogą znaleźć oraz poprawnie zidentyfikować ofertę.

11. Crawlability

Czy strategiczne treści są dostępne dla wyszukiwarek i właściwych crawlerów?

12. Indexability

Czy strony strategiczne mogą zostać indeksowane?

13. Canonical URLs

Czy produkt/kategoria posiada jednoznaczny główny URL?

14. Duplicate Control

Czy nie istnieje kilka konkurujących kart tego samego produktu?

15. Clear Information Architecture

Czy relacja:

firma → kategoria → produkt → dokument

jest czytelna?

16. Canonical Category Page

Czy strategiczna kategoria ma nadrzędną stronę wyjaśniającą problem i rozwiązania?

17. Answer-First Structure

Czy najważniejsze strony udzielają szybkiej, jednoznacznej odpowiedzi?

18. Entity Clarity

Czy można jednoznacznie ustalić:

• kto produkuje;
• kto sprzedaje;
• co jest produktem;
• co jest marką;
• co modelem?

19. Structured Web Data

Czy wykorzystywane są właściwe dane strukturalne tam, gdzie mają zastosowanie?

20. AI Visibility Measurement

Czy firma mierzy oddzielnie przynajmniej część widoczności:

• generative search;
• answer engines;
• referrals AI;
• brand/product inclusion?

---

MODUŁ C — PRODUCT / SERVICE TRUTH

Cel

Ustalić, czy system posiada wystarczająco dobrą prawdę produktową.

21. [GATE] Stable Product ID

Czy strategiczny produkt ma trwały, jednoznaczny identyfikator?

22. Product Identity

Czy wiadomo:

• manufacturer;
• brand;
• model;
• variant?

23. External Identifiers

Czy MPN, SKU, GTIN lub inne istniejące identyfikatory są poprawnie rozdzielone?

24. Lifecycle

Czy wiadomo, czy produkt jest:

• active;
• configured-to-order;
• discontinued;
• superseded;
• service-only?

25. Structured Technical Parameters

Czy kluczowe parametry są zapisane strukturalnie?

26. Units

Czy liczby mają jednoznaczne jednostki?

27. Ranges

Czy zakres:

20–50

nie został błędnie zamieniony w:

50?

28. Standard vs Option

Czy konfiguracja standardowa jest oddzielona od opcji?

29. Applications

Czy wiadomo, do jakich zastosowań produkt jest przeznaczony?

30. Limitations

Czy jawnie opisano, czego produkt:

• nie robi;
• nie obsługuje;
• nie powinien być używany?

---

MODUŁ D — EVIDENCE, FRESHNESS I COMMERCIAL TRUTH

Cel

Sprawdzić, czy dane są nie tylko obecne, ale także wiarygodne i aktualne.

31. Claim-to-Source Mapping

Czy kluczowe claimy można powiązać ze źródłem?

32. Manufacturer Evidence

Czy krytyczne parametry bazują przede wszystkim na źródłach pierwotnych?

33. Evidence Type

Czy system odróżnia:

• dokument producenta;
• test własny;
• dane własne;
• źródło wtórne?

34. Confidence

Czy dane o różnej jakości nie są traktowane jednakowo?

35. Source Date

Czy wiadomo, z kiedy pochodzi dowód?

36. VerifiedAt

Czy wiadomo, kiedy informacja została ostatnio sprawdzona?

37. Freshness Classification

Czy dane mają LOW / MEDIUM / HIGH freshness risk lub podobną klasyfikację?

38. Product vs Offer

Czy właściwości produktu są oddzielone od aktualnej oferty?

39. Offer Validity

Czy cena dynamiczna posiada:

• walutę;
• seller;
• zakres;
• verifiedAt/validFrom;
• validThrough, gdy właściwe?

40. [GATE] No Stale Commercial Truth

Czy system uniemożliwia przedstawianie wygasłej ceny, stocku lub terminu jako aktualnego?

---

MODUŁ E — QUALIFICATION

Cel

Sprawdzić, czy system potrafi ocenić produkt wobec potrzeb kupującego.

41. Qualification Inputs

Czy wiadomo, jakie informacje są potrzebne do kwalifikacji?

42. MATCH

Czy istnieją jawne warunki potencjalnego dopasowania?

43. MISMATCH

Czy istnieją warunki wykluczające?

44. [GATE] UNKNOWN

Czy brak informacji prowadzi do UNKNOWN, a nie do zgadywania?

45. REVIEW

Czy istnieje status dla przypadków wymagających eksperta?

46. Boundary Rules

Czy wartości graniczne są prawidłowo interpretowane?

47. Cross-Field Rules

Czy system potrafi uwzględnić zależności pomiędzy polami?

48. Alternative Configuration

Czy MISMATCH pojedynczej konfiguracji może prowadzić do alternatywnej wersji?

49. Alternative Product

Czy system potrafi przejść do innego produktu zamiast kończyć ścieżkę?

50. Qualification Resolution

Czy wynik posiada właściwy następny krok, np.:

ASK_MISSING_DATA
CONTINUE
REVIEW
ALTERNATIVE_CONFIGURATION
ALTERNATIVE_PRODUCT
STOP

---

MODUŁ F — ACTION ARCHITECTURE / DIRECT RFQ

Cel

Sprawdzić, czy po rekomendacji istnieje strukturalna następna akcja.

51. Defined Action Types

Czy dla produktu wiadomo, jaki action type ma zastosowanie?

Np.:

• CONTACT;
• RFQ;
• SAMPLE;
• TEST;
• SERVICE;
• REORDER;
• ORDER.

52. Standard Human CTA

Czy użytkownik może zawsze:

• zadzwonić;
• napisać;
• wysłać krótki formularz?

53. Structured RFQ

Czy techniczne zapytanie jest czymś więcej niż polem „wiadomość”?

54. RFQ Profile

Czy dana kategoria posiada zdefiniowany zestaw wymaganych informacji?

55. Typed Fields

Czy RFQ używa:

• number;
• boolean;
• enum;
• quantity;
• range;

zamiast samego free text?

56. Conditional Logic

Czy kolejne pytania zależą od wcześniejszych odpowiedzi?

57. Progressive Qualification

Czy system pyta tylko o dane potrzebne na danym etapie?

58. requiredAtStage

Czy rozróżniono dane wymagane przy:

• discovery;
• qualification;
• submission;
• review;
• quote?

59. [GATE] Actual Action Route

Czy akcja naprawdę istnieje produkcyjnie, a nie wyłącznie w dokumentacji?

60. [GATE] Human Fallback

Czy każdą złożoną ścieżkę można przekazać człowiekowi?

---

MODUŁ G — MACHINE INTERFACES

Cel

Sprawdzić, czy system posiada interfejs możliwy do użycia bez odgadywania GUI.

61. Canonical Machine Representation

Czy istnieje strukturalna reprezentacja danych?

62. HTML/Data Consistency

Czy HTML i dane maszynowe mówią to samo?

63. Schema Consistency

Czy JSON-LD nie posiada danych sprzecznych ze stroną?

64. Product Feed Consistency

Czy feed wykorzystuje tę samą prawdę produktową?

65. Action Schema

Czy akcja posiada jawny input schema?

66. Validation Response

Czy błędne pole zwraca jednoznaczny błąd?

67. Structured Result

Czy wynik akcji może być odczytany maszynowo?

68. Interface Declaration

Czy system nie deklaruje:

MCP/A2A/API available

jeżeli funkcja nie istnieje?

69. Agent Tool Surface

Czy istnieje lub jest poprawnie zaprojektowana funkcja typu:

product.get
product.compare
availability.check
rfq.prepare

70. Interface Adapter Architecture

Czy WebMCP/MCP/A2A/feed są adapterami do wspólnego backendu zamiast osobnymi bazami?

---

MODUŁ H — IDENTITY, AUTHORITY, SECURITY, PRIVACY

Cel

Sprawdzić, czy agent może działać tylko w zakresie rzeczywiście przyznanych uprawnień.

71. Requester Identity

Czy wiadomo, kto technicznie wykonuje akcję?

72. Principal Identity

Czy wiadomo, w czyim imieniu działa agent?

73. Buyer Organization

Czy organizacja kupująca jest osobnym obiektem?

74. Recipient Identity

Czy wiadomo, do kogo dokładnie trafia RFQ/order?

75. [GATE] Authority Model

Czy system rozróżnia uprawnienia:

READ
COMPARE
PREPARE
SUBMIT
ACCEPT
ORDER
PAY

76. [GATE] Approval Boundary

Czy krytyczna akcja wymaga właściwego zatwierdzenia?

77. Authentication

Czy akcje wymagające identyfikacji używają właściwego uwierzytelnienia?

78. Authorization

Czy użytkownik/agent nie może wykonać akcji poza swoim zakresem?

79. Information Classification

Czy dane są klasyfikowane np.:

PUBLIC
CUSTOMER
PARTNER
INTERNAL
CONFIDENTIAL

80. [GATE] Security / Privacy Baseline

Czy istnieją odpowiednie zabezpieczenia dla:

• danych osobowych;
• plików;
• tokenów;
• API;
• uploadów;
• sekretów;
• danych klientów?

---

MODUŁ I — TRANSACTION, REORDER I LIFECYCLE

Cel

Sprawdzić prawdziwą gotowość do Agentic Commerce.

81. Transaction Eligibility

Czy wiadomo, które produkty można kupować autonomiczniej, a które wymagają RFQ?

82. Current Offer Check

Czy przed order/reorder następuje ponowne potwierdzenie aktualnej oferty?

83. Product Version Check

Czy reorder potwierdza, że produkt nadal odpowiada wcześniejszemu SKU/specyfikacji?

84. Availability Check

Czy aktualna dostępność pochodzi ze źródła operacyjnego?

85. Price Check

Czy aktualna cena nie pochodzi ze starej strony lub cache bez kontroli?

86. Order Semantics

Czy system jednoznacznie rozróżnia:

RFQ
QUOTE
ORDER
CONTRACT

87. [GATE] Idempotency

Czy ponowione żądanie nie tworzy przypadkowo kilku zamówień/RFQ?

88. [GATE] Transaction Lifecycle

Czy system posiada jednoznaczne statusy?

Np.:

PREPARED
APPROVED
SUBMITTED
RECEIVED
CONFIRMED
FAILED
CANCELLED

89. Quote / Order Handoff

Czy przejście pomiędzy RFQ, ofertą i zamówieniem jest kontrolowane?

90. [GATE] Audit Trail

Czy można odtworzyć:

• kto;
• co;
• kiedy;
• w czyim imieniu;
• z jaką wersją danych;
• wykonał?

---

MODUŁ J — MEASUREMENT, EVALS I OPERATIONS

Cel

Sprawdzić, czy system jest rzeczywiście zarządzany, a nie tylko wdrożony.

91. AI Discovery Monitoring

Czy firma mierzy, jak produkty są odnajdywane w AI?

92. Product Understanding Tests

Czy testuje się poprawność interpretacji produktu?

93. Qualification Accuracy

Czy system porównuje wynik AI z oceną eksperta?

94. Action Success Rate

Czy mierzymy poprawność wykonania actions?

95. RFQ Quality

Czy mierzymy kompletność i jakość RFQ?

96. Clarification Rate

Czy wiadomo, jak często handlowiec musi dopytywać?

97. Mismatch Analysis

Czy MISMATCH staje się źródłem wiedzy produktowej?

98. [GATE] Agent Evals

Czy przed produkcyjnym użyciem action tools testowane są przynajmniej:

• happy path;
• UNKNOWN;
• MISMATCH;
• REVIEW;
• boundary;
• expired data;
• duplicate;
• unauthorized action?

99. Incident / Correction Process

Czy wiadomo, co zrobić, kiedy agent popełni błąd?

100. Continuous Improvement Loop

Czy dane z:

SEARCH
AI
RFQ
QUOTE
ORDER
SERVICE

wracają do:

CONTENT
PRODUCT MASTER
QUALIFICATION
PORTFOLIO

?

---

7. Oficjalne progi punktowe

<25 punktów — PRE-READY

Nie jest to formalny poziom ACRA.

Charakterystyka:

• informacje rozproszone;
• brak Product Truth;
• duża zależność od człowieka;
• AI może znaleźć stronę, ale nie należy ufać automatycznej interpretacji.

---

25–44 — AI-READABLE

Firma może uzyskać status:

AI-Readable

jeżeli:

• wynik ≥25;
• Module B ≥5/10;
• Module C ≥5/10;
• Gate 10 PASS;
• Gate 21 PASS.

---

45–64 — AGENT-QUALIFIABLE

Wymagane:

• wynik ≥45;
• wcześniejszy poziom spełniony;
• Module C ≥6;
• Module D ≥5;
• Module E ≥7;
• UNKNOWN = PASS;
• istnieją MATCH/MISMATCH/REVIEW;
• system nie zgaduje brakujących danych.

---

65–84 — ACTION-READY

Wymagane:

• wynik ≥65;
• Agent-Qualifiable;
• Module F ≥7;
• Module G ≥6;
• Module H ≥6;
• Gate 59 PASS;
• Gate 60 PASS;
• Gate 75 PASS;
• Gate 76 PASS.

Oznacza to:

istnieje rzeczywista, kontrolowana Action Route.

---

85–100 — TRANSACTION-READY

Wymagane:

• wynik ≥85;
• Action-Ready;
• Module H ≥8;
• Module I ≥8;
• Module J ≥7;
• Gate 40 PASS;
• Gate 75 PASS;
• Gate 76 PASS;
• Gate 80 PASS;
• Gate 87 PASS;
• Gate 88 PASS;
• Gate 90 PASS;
• Gate 98 PASS.

Dodatkowo wymagany:

przynajmniej jeden rzeczywisty end-to-end test produkcyjny.

---

8. Transaction-Ready nie oznacza autonomii wszędzie

Firma może być:

Transaction-Ready dla materiałów eksploatacyjnych

i równocześnie:

Action-Ready dla maszyn

oraz:

Agent-Qualifiable dla projektów integracyjnych.

To jest prawidłowy wynik.

Nie należy przypisywać całej firmie jednego poziomu bez podania kontekstu.

---

9. Cztery tryby audytu

COMPANY MODE

Badamy całą organizację.

Pytanie:

czy firma posiada architekturę pozwalającą rozwijać Agentic Commerce?

---

DOMAIN MODE

Badamy domenę WWW.

Pytanie:

czy witryna prawidłowo reprezentuje firmę, produkty i actions?

---

CATEGORY MODE

Badamy np.:

urządzenia magazynowe;

materiały opakowaniowe;

automatyzację;

części.

Pytanie:

czy dana kategoria może przejść cały Search-to-Action flow?

---

PRODUCT MODE

Najbardziej precyzyjny audyt.

Pytanie:

czy konkretny produkt jest AI-readable, qualifiable, actionable lub transactional?

---

10. Portfolio Mode

Przy audycie większego portfolio należy podzielić produkty przynajmniej na:

Strategic Products

Najważniejsze handlowo.

High-volume Products

Najczęściej kupowane.

High-complexity Products

Najtrudniejsze do dobrania.

Repeat Purchase Products

Najlepsze dla reorder.

Legacy Products

Produkty starsze lub wycofane.

Nie należy liczyć:

500 poprawnych prostych SKU

jako kompensacji dla:

5 strategicznych produktów z błędnymi parametrami.

---

11. N/A — zasady

Kryterium może otrzymać:

N/A

tylko jeżeli rzeczywiście nie dotyczy badanego przypadku.

Przykład:

reorder dla jednorazowej usługi projektowej.

Wtedy wynik:

SCORE =
earned points
÷
applicable points
×
100

Ale:

GATE nie może zostać pominięty przy certyfikacji poziomu, którego dotyczy.

---

12. Minimalny Evidence Pack audytu

Audyt powinien zebrać:

Business evidence

• Organization pages;
• dane firmy;
• role;
• kontakty.

Product evidence

• Product Master;
• strony;
• PDF;
• instrukcje;
• cenniki;
• dokumenty producenta.

Search evidence

• Search Console;
• indeksacja;
• canonical;
• structured data.

Commercial evidence

• ceny;
• stock;
• lead time;
• warunki.

Action evidence

• formularze;
• Direct RFQ;
• API;
• route descriptors.

Agent evidence

• WebMCP;
• MCP;
• API;
• A2A, jeśli istnieje.

Transaction evidence

• order;
• reorder;
• status;
• acknowledgement.

Operational evidence

• CRM;
• ERP;
• logi;
• evals.

---

13. Obowiązkowy Consistency Matrix

Audyt powinien porównać:

Fakt	HTML	PDF	JSON	Schema	Feed	RFQ	ERP/PIM
Product ID
Model
parametr A
parametr B
cena
dostępność

Każda krytyczna sprzeczność powinna stać się:

P0.

---

14. Obowiązkowy Qualification Test

Dla produktu technicznego należy przygotować minimum pięć przypadków.

Test 1 — CLEAR MATCH

Wszystkie dane pasują.

Test 2 — CLEAR MISMATCH

Jedna wartość przekracza limit.

Test 3 — UNKNOWN

Brakuje krytycznej wartości.

Test 4 — REVIEW

Nie można podjąć bezpiecznej decyzji automatycznie.

Test 5 — ALTERNATIVE

Standardowa konfiguracja nie pasuje, ale inna może pasować.

---

15. Minimalny Agent Eval Pack

Dla Action-Ready minimum:

EVAL-01

Prawidłowy wybór tool.

EVAL-02

Tool nie jest uruchamiany przy niewłaściwej intencji.

EVAL-03

Poprawne mapowanie liczb i jednostek.

EVAL-04

UNKNOWN nie jest uzupełniane zmyśloną wartością.

EVAL-05

MISMATCH zatrzymuje lub przekierowuje workflow.

EVAL-06

REVIEW trafia do człowieka.

EVAL-07

Nieaktualna cena nie zostaje uznana za obowiązującą.

EVAL-08

Nieautoryzowany agent nie może wykonać SUBMIT/ORDER.

EVAL-09

Brak approval zatrzymuje akcję.

EVAL-10

Powtórzony request nie tworzy duplikatu.

EVAL-11

Błąd backendu zwraca kontrolowany status.

EVAL-12

Prompt injection w danych zewnętrznych nie zmienia zakresu uprawnień.

---

16. Action Classification Matrix

Przy audycie każdy produkt powinien otrzymać Action Class.

Klasa	Typ produktu	Typowy następny krok
AC-0	informacyjny	CONTACT
AC-1	techniczny	DIRECT RFQ
AC-2	wymagający testów	TEST / SAMPLE / RFQ
AC-3	powtarzalne SKU	REORDER
AC-4	standardowe SKU	ORDER
AC-5	rozwiązanie projektowe	PROJECT DISCOVERY

Nie każdy produkt powinien dążyć do AC-4.

---

17. Transaction Suitability

Przed budową pełnej transakcyjności oceń produkt w pięciu wymiarach.

Identity Certainty

Czy dokładnie wiadomo, co jest kupowane?

Configuration Risk

Czy istnieje duże ryzyko złej konfiguracji?

Financial Risk

Jak wysoka jest wartość transakcji?

Safety / Technical Risk

Czy błąd może powodować konsekwencje techniczne?

Repeatability

Czy klient kupował już dokładnie ten sam produkt?

Najlepszy kandydat do pierwszego Agentic Commerce:

wysoka jednoznaczność + niskie ryzyko konfiguracji + powtarzalność.

---

18. Recommended Pilot Matrix

PILOT A — PRODUCT QUALIFICATION

Standardowy produkt techniczny.

Cel:

DISCOVER
→ UNDERSTAND
→ MATCH
→ DIRECT RFQ

---

PILOT B — CONFIGURED PRODUCT

Produkt wymagający wielu danych.

Cel:

UNKNOWN
→ ASK
→ REVIEW
→ HUMAN HANDOFF

---

PILOT C — REPEATABLE SKU

Materiał lub część.

Cel:

IDENTIFY
→ CURRENT OFFER
→ AUTHORITY
→ APPROVAL
→ REORDER

Dopiero komplet tych trzech testów dobrze bada architekturę.

---

19. P0–P3 Backlog

Po audycie każda luka powinna otrzymać priorytet.

P0 — BLOCKERS

Przykłady:

• błędny Product ID;
• sprzeczne parametry;
• wygasła cena przedstawiana jako aktualna;
• brak authority;
• order bez approval;
• brak security;
• brak idempotency przy transakcji.

Naprawić przed dalszą automatyzacją.

---

P1 — AGENT-QUALIFIABLE

Przykłady:

• Product Master;
• evidence;
• ograniczenia;
• MATCH;
• MISMATCH;
• UNKNOWN;
• REVIEW;
• required inputs.

---

P2 — ACTION-READY

Przykłady:

• Direct RFQ;
• Route Descriptor;
• structured form;
• API;
• WebMCP;
• machine response;
• CRM mapping.

---

P3 — TRANSACTION-READY

Przykłady:

• reorder;
• order;
• identity;
• mandate;
• approval;
• lifecycle;
• idempotency;
• transaction log;
• ERP integration.

---

20. Raport końcowy audytu

Każdy audit ACRA-B2B powinien kończyć się jednym standardowym dashboardem.

Overall Score

XX/100

Current Level

AI-Readable / Agent-Qualifiable / Action-Ready / Transaction-Ready

Target Level

…

Gates

Gate	Wynik
One Product Truth	PASS/FAIL
Stable Product Identity	PASS/FAIL
Fresh Commercial Data	PASS/FAIL
UNKNOWN	PASS/FAIL
Actual Action Route	PASS/FAIL
Human Fallback	PASS/FAIL
Authority	PASS/FAIL
Approval	PASS/FAIL
Security	PASS/FAIL
Idempotency	PASS/FAIL
Lifecycle	PASS/FAIL
Audit Trail	PASS/FAIL
Agent Evals	PASS/FAIL

---

21. Module Scorecard

Moduł	Score
Governance	/10
Discovery	/10
Product Truth	/10
Evidence / Freshness	/10
Qualification	/10
Action Architecture	/10
Machine Interfaces	/10
Identity / Security	/10
Transaction	/10
Evals / Operations	/10
TOTAL	/100

---

22. Najważniejsze ryzyka

Raport powinien wymienić maksimum:

5 Critical Risks

oraz:

5 Highest-Leverage Opportunities.

Nie chodzi o wyprodukowanie listy 100 problemów bez priorytetów.

---

23. Roadmapa audytowanego podmiotu

Standardowy wynik:

NOW

P0 — co blokuje bezpieczne użycie.

NEXT

P1 — co pozwoli osiągnąć kolejny readiness level.

LATER

P2/P3 — czego nie warto jeszcze wdrażać.

---

24. Zasada „Protocol Last”

ACRA-B2B celowo nie przyznaje wysokiej oceny tylko za:

• MCP;
• WebMCP;
• A2A;
• API;
• JSON.

Przykład:

MCP = YES
Product Truth = NO
Qualification = NO

nie oznacza:

Agent-Ready.

Oznacza:

agent otrzyma szybszy dostęp do złych danych.

Prawidłowa kolejność:

BUSINESS TRUTH
↓
PRODUCT TRUTH
↓
EVIDENCE
↓
QUALIFICATION
↓
ACTION SEMANTICS
↓
AUTHORITY
↓
INTERFACE
↓
AGENT

---

25. Zasada „Human Control Where It Matters”

Agentic Commerce Readiness nie oznacza maksymalizacji autonomii.

Celem jest:

maksymalizacja użytecznej automatyzacji przy zachowaniu właściwych granic odpowiedzialności.

Dla prostego reorder:

AGENT
→ APPROVAL
→ ORDER

może być właściwy.

Dla systemu projektowego:

AGENT
→ PREQUALIFICATION
→ DIRECT RFQ
→ ENGINEER

może być optymalnym końcem automatyzacji.

Oba przypadki mogą być oznaką bardzo wysokiej dojrzałości.

---

26. Zasada „Correct Unknown”

Jednym z najważniejszych KPI przyszłego systemu nie jest:

jak często AI udziela odpowiedzi.

Tylko:

jak często poprawnie wie, że odpowiedzi jeszcze nie można udzielić.

Poprawne:

UNKNOWN

jest lepsze niż:

fałszywe MATCH.

---

27. Zasada „Evidence Before Autonomy”

Im większy wpływ decyzji agenta, tym większy musi być wymagany poziom evidence.

Przykład:

opis kategorii

może korzystać z wielu źródeł.

maksymalna masa urządzenia

powinna mieć mocny dowód techniczny.

aktualna cena

musi pochodzić z aktualnego źródła handlowego.

ORDER

powinien wykorzystywać aktualny stan systemu operacyjnego, a nie tekst na stronie.

---

28. Zasada „Action Before Transaction”

Nie przechodzimy:

AI-readable
→ autonomous purchasing

w jednym kroku.

Prawidłowa ewolucja:

AI-READABLE
↓
AGENT-QUALIFIABLE
↓
ACTION-READY
↓
TRANSACTION-READY

Każdy poziom uczy system czegoś nowego.

---

29. Zasada „Reorder Before Autonomous First Purchase”

Dla wielu firm B2B pierwszym sensownym use case’em nie będzie:

agent sam wybiera nowy produkt.

Tylko:

agent ponawia znane zamówienie po sprawdzeniu aktualnych warunków.

Reorder posiada:

• znanego kupującego;
• znany SKU;
• wcześniejszą relację;
• znany adres;
• znaną kategorię.

Pozostaje potwierdzić:

• dostępność;
• cenę;
• ilość;
• uprawnienie;
• approval.

To bardzo dobry pierwszy test Transaction-Ready.

---

30. Definicja końcowa

AI-Readable

AI potrafi poprawnie znaleźć i zrozumieć ofertę.

Agent-Qualifiable

Agent potrafi dodatkowo ustalić, czy oferta może odpowiadać wymaganiom i jakie informacje są jeszcze potrzebne.

Action-Ready

Agent może wykorzystać jawnie zdefiniowaną i kontrolowaną funkcję biznesową.

Transaction-Ready

Agent może przeprowadzić autoryzowane działanie handlowe z zachowaniem aktualności danych, approval, bezpieczeństwa, lifecycle i audytu.

---

31. Final Architecture

SEARCH / AI / AGENT
        ↓
DISCOVERY
        ↓
CANONICAL ANSWER
        ↓
PRODUCT / SERVICE MASTER
        ↓
EVIDENCE
        ↓
QUALIFICATION
        │
        ├── MATCH
        ├── MISMATCH
        ├── UNKNOWN
        └── REVIEW
        ↓
RESOLUTION
        ↓
ACTION ROUTE
        │
        ├── CONTACT
        ├── RFQ
        ├── SAMPLE
        ├── TEST
        ├── SERVICE
        ├── REORDER
        └── ORDER
        ↓
AUTHORITY
        ↓
APPROVAL
        ↓
EXECUTION
        ↓
CRM / ERP / PIM / CPQ
        ↓
STATUS / HUMAN REVIEW
        ↓
QUOTE / ORDER
        ↓
DELIVERY / SERVICE
        ↓
REORDER
        ↓
STRUCTURED MARKET SIGNALS
        ↓
PRODUCT DEVELOPMENT

---

32. Ostateczna zasada ACRA-B2B v1.0

Najważniejsze pytanie audytu nie brzmi:

Czy AI widzi tę firmę?

Ani nawet:

Czy AI zna jej produkty?

Prawidłowe pytanie brzmi:

Czy niezależny agent może znaleźć ofertę, poprawnie ją zrozumieć, zweryfikować najważniejsze fakty, ustalić dopasowanie i braki, wybrać właściwą następną akcję, wykonać ją wyłącznie w zakresie posiadanych uprawnień oraz pozostawić po sobie jednoznaczny, możliwy do odtworzenia ślad biznesowy?

Jeżeli odpowiedź brzmi:

tak

firma nie jest już tylko:

AI-visible.

Zaczyna posiadać:

Agentic Commerce Infrastructure.

---

Szybki kontakt z Warehouser™ — rozwiązania dla magazynów.

Opisz, czego potrzebuje Twój magazyn. Wybierz obszar i opisz potrzebę własnymi słowami. Jeżeli nie masz wszystkich parametrów, podaj to, co już wiesz: proces, problem, skalę, lokalizację i oczekiwany termin. Brakujące informacje możemy uporządkować przed skierowaniem zapytania dalej.

Materiały do pakowania • Maszyny i urządzenia • Wyposażenie magazynu • Automatyzacja i technologie magazynowe

Zadzwoń: 691 669 192
Napisz: kontakt@warehouser.pl

Administratorem danych jest Warehouser™. Dane wykorzystamy w celu przyjęcia i obsługi Twojej wiadomości oraz udzielenia odpowiedzi. Szczegóły dotyczące podstaw prawnych, okresu przechowywania danych, odbiorców i Twoich praw znajdziesz w Polityce prywatności.

Warehouser™ pomaga uporządkować potrzeby i zapytania. W rozwiązaniach partnerskich dobór techniczny, wycenę, sprzedaż, dostawę, gwarancję i serwis prowadzi partner wskazany w konkretnej ofercie.