UCP dan ACP: Dua Jalur yang Perlu Dipantau Tim Commerce

Tim commerce 2026 punya problem baru: belum selesai memahami feed, tiba-tiba muncul protocol.

UCP. ACP. AP2. MCP. A2A.

Kalau dibaca cepat, semuanya terdengar seperti alphabet soup hasil meeting engineer yang terlalu lama. Tetapi dua nama yang sangat relevan untuk perdagangan berbasis AI adalah UCP dan ACP.

UCP adalah Universal Commerce Protocol yang didorong Google bersama ekosistem commerce. ACP adalah Agentic Commerce Protocol yang dikembangkan dalam ekosistem OpenAI dan Stripe.

Keduanya sama-sama merespons perubahan besar yang sama: AI tidak hanya mencari informasi produk. AI mulai bergerak menuju agentic commerce, di mana software agent bisa membantu discovery, comparison, checkout, dan proses transaksi lainnya.

Tetapi jangan langsung menyimpulkan UCP dan ACP adalah “dua versi teknologi yang sama persis”. Ada overlap, ada perbedaan implementasi, ada roadmap yang bergerak, dan ada konteks platform yang berbeda.

Buat tim commerce, tugas pertama bukan memilih kubu.

Tugas pertama adalah memahami kenapa protocol ini muncul.

Kenapa Commerce Butuh Protocol Baru

E-commerce tradisional dibangun dengan assumption bahwa manusia membuka website atau app merchant. Ia memilih produk, mengisi cart, checkout, membayar, lalu melihat order status.

AI agent mengubah siapa yang mengoperasikan interface.

User bisa berkata, “Cari toner printer yang kompatibel dengan model saya, maksimal Rp700 ribu, kirim ke Jakarta besok, lalu siapkan checkout.”

Untuk menjalankan intent itu secara aman, agent harus bisa bicara dengan merchant system dalam bahasa yang cukup terstruktur.

Ia perlu memahami produk, availability, checkout state, payment flow, shipping, policy, mungkin loyalty, dan post-purchase action.

Kalau setiap merchant membuat integration one-off untuk setiap AI platform, skalanya cepat menjadi kacau.

Protocol mencoba mengurangi fragmentasi itu.

UCP: Jalur Google untuk Agentic Commerce

Google mendeskripsikan Universal Commerce Protocol sebagai open standard untuk masa depan commerce yang memungkinkan AI interaction berubah menjadi transaksi. Dokumentasi resminya menyebut UCP digunakan untuk agentic actions pada AI Mode di Google Search dan Gemini, dimulai dari direct buying.

Google juga menekankan bahwa merchant tetap menjadi Merchant of Record dan mempertahankan customer data serta relationship. UCP mendukung model native checkout dan, untuk merchant tertentu, embedded checkout.

Yang menarik, roadmap UCP tidak berhenti di transaksi single-step. Dokumentasi Google menyebut arah seperti multi-item carts, account linking untuk loyalty program, serta post-purchase support untuk tracking dan returns.

Jadi UCP sebaiknya dilihat sebagai commerce interaction layer yang ingin menghubungkan AI surface dengan operasi retail yang lebih luas.

Secara desain, Google menyebut UCP modular dan extensible. Merchant dapat mendukung capability yang sesuai kebutuhan dan menggunakan communication mechanism yang cocok, termasuk REST API atau binding lain yang didukung.

ACP: Jalur OpenAI untuk Merchant dan ChatGPT

OpenAI mendeskripsikan Agentic Commerce Protocol sebagai open standard yang menjadi connective layer antara merchant dan pengguna ChatGPT. Dokumentasinya menyebut ACP memungkinkan ChatGPT menerima structured catalog data, memahami merchant inventory, dan menampilkan produk yang relevan dalam konteks.

ACP bukan sekadar nama baru untuk product feed. Feed adalah salah satu bagian penting, tetapi agentic commerce menyentuh interaction dan transaction layer yang lebih luas.

OpenAI juga menyediakan spesifikasi terkait delegated payment dan resource commerce lainnya, sementara proyek ACP open source dipelihara bersama Stripe.

Bagi merchant yang ingin berpartisipasi di shopping experience ChatGPT, ini jelas jalur yang perlu dipantau.

UCP vs ACP Bukan Pertanyaan “Mana yang Menang?”

Teknologi commerce sering membuat orang ingin memilih winner terlalu cepat.

“Apakah nanti semua pakai UCP?”

“ACP bakal menggantikan yang lain?”

“Kalau sudah integrasi satu, perlu yang kedua?”

Agustus 2026 masih terlalu dini untuk menjawab pertanyaan itu secara absolut.

Kedua standard terus berkembang. Ecosystem adoption bisa berubah. Feature coverage bisa bergeser. Bahkan cara merchant berintegrasi bisa mengalami perubahan.

Strategi yang lebih waras adalah protocol-aware, bukan protocol-fanatic.

Artinya perusahaan memahami interface dan data requirement masing-masing, menjaga core commerce system tetap canonical, lalu membuat adapter atau integration layer sehingga tidak mengikat seluruh bisnis logic ke satu platform.

Core Commerce Harus Tetap Milik Merchant

Ini prinsip arsitektur yang penting.

Jangan membuat rule stock, pricing, eligibility, tax, shipping, dan order state hidup hanya di adapter UCP atau ACP.

Core business logic sebaiknya tetap berada di sistem merchant yang authoritative.

Protocol layer bertugas menerjemahkan atau mengekspos capability secara aman ke external agent.

Kalau besok ada protocol baru, perusahaan menambah adapter. Bukan menulis ulang ERP.

Model seperti ini juga memudahkan governance. Merchant punya satu source of truth dan bisa menjelaskan kenapa satu transaksi valid atau tidak.

Data Model Lebih Penting daripada Pilihan Protocol

Perusahaan dengan katalog kacau tidak otomatis menjadi agentic-ready hanya karena berhasil memasang endpoint UCP atau ACP.

Kalau product IDs tidak stable, variant tidak jelas, stock tidak fresh, return policy ambigu, dan seller identity tidak konsisten, protocol hanya mempercepat distribusi kekacauan.

Sebelum implementation, tim commerce perlu audit fondasi:

product identity,

variant model,

pricing source,

inventory source,

promotion logic,

checkout state,

payment authorization,

shipping promises,

return policy,

customer identity,

order lifecycle.

Kalau sepuluh area ini masih punya multiple source of truth, protocol integration akan mengungkap hutang teknis yang selama ini tersembunyi.

Security dan Authorization Tidak Boleh Jadi Afterthought

Agentic commerce berbeda dari katalog pasif karena agent dapat bergerak mendekati aksi.

Semakin dekat ke checkout dan payment, semakin tinggi kebutuhan authorization yang eksplisit.

Siapa yang boleh membuat cart? Siapa boleh mengubah quantity? Kapan user harus confirm? Data apa yang boleh dibagikan? Bagaimana payment credential diproses? Apa yang terjadi kalau price berubah setelah recommendation tetapi sebelum checkout?

Pertanyaan ini harus dijawab di arsitektur, bukan setelah incident.

Google menekankan accountability trail dan secure transaction design pada UCP. OpenAI juga punya spesifikasi commerce yang membahas delegated payment. Detail implementasi berbeda, tetapi prinsipnya sama: agentic action membutuhkan boundary.

“Agent Bisa Beli Sendiri” Itu Narasi yang Terlalu Sederhana

Media sering menggambarkan agentic commerce seolah AI akan segera keliling internet belanja tanpa manusia.

Realitanya lebih nuanced.

Ada spectrum autonomy. Agent bisa hanya research. Bisa membuat shortlist. Bisa menyiapkan cart. Bisa meminta confirmation. Bisa melakukan action terbatas berdasarkan mandate. Bisa mengurus post-purchase tertentu.

Merchant harus mendefinisikan batas berdasarkan risk level.

Beli kabel USB Rp80 ribu dan membuat kontrak software enterprise Rp800 juta jelas tidak bisa memakai governance yang sama.

Protocol memberi mekanisme. Governance menentukan apa yang seharusnya diizinkan.

Tim Commerce, Engineering, Legal, dan Risk Harus Duduk Bareng

Implementasi protocol bukan proyek marketing saja.

Commerce memahami customer journey dan merchandising. Engineering memahami API dan state. Security memahami threat model. Legal memahami contractual obligation. Finance memahami payment dan reconciliation. Customer service memahami exception dan post-purchase reality.

Kalau satu fungsi bekerja sendiri, blind spot mudah muncul.

Contoh sederhana: engineering sukses membuat checkout endpoint, tetapi customer service tidak punya cara melihat order yang dibuat melalui agentic flow. Ketika user komplain, agent mengatakan satu hal dan CS mengatakan hal lain.

Secara API sukses. Secara customer experience gagal.

Buat Capability Matrix

Daripada debat protocol secara abstrak, buat matrix.

Barisnya adalah capability: discovery, product detail, inventory, cart, checkout, payment, loyalty, order tracking, cancellation, return.

Kolomnya: current internal readiness, UCP support yang relevan, ACP support yang relevan, risk level, owner, target phase.

Dengan begitu tim bisa melihat gap nyata.

Mungkin discovery sudah siap tetapi checkout belum. Mungkin inventory bagus tetapi return policy tidak machine-consumable. Mungkin loyalty belum perlu tahun ini.

Roadmap menjadi grounded ke capability, bukan hype.

Jangan Integrasi Karena FOMO

Ada tekanan untuk bisa bilang, “Brand kami sudah agentic commerce ready.”

Kalau alasan utama implementation cuma badge, hati-hati.

Protocol integration memerlukan maintenance. Spec bisa berubah. Security perlu dipantau. Observability perlu dibuat. Incident response perlu disiapkan.

Merchant sebaiknya punya business case: apakah channel relevan dengan customer, apakah volume potensial masuk akal, apakah integration memberi learning strategis, apakah existing stack cukup matang.

Eksperimen boleh kecil. Bahkan sebaiknya kecil.

Mulai dari catalog visibility dan low-risk action. Ukur. Pelajari exception. Baru tambah autonomy.

Indonesia Perlu Memantau, Bukan Menunggu Sempurna

Banyak merchant Indonesia mungkin belum punya akses langsung ke semua capability yang diumumkan global. Rollout platform sering bertahap per negara, partner, atau eligibility.

Namun menunggu sampai semua feature resmi tersedia di Indonesia baru mulai merapikan data adalah langkah terlambat.

Fondasi seperti stable IDs, inventory freshness, policy clarity, API hygiene, customer consent, dan event logging berguna di banyak channel, bukan hanya UCP atau ACP.

Jadi readiness work tetap punya nilai meski rollout lokal belum penuh.

Monitor Empat Hal

Pertama, spec evolution. Baca dokumentasi resmi, bukan hanya thread sosial.

Kedua, market availability. Feature yang live di Amerika belum tentu live di Indonesia.

Ketiga, partner ecosystem. Lihat platform commerce, payment provider, marketplace, dan SaaS yang mulai menyediakan integration native.

Keempat, merchant control. Perhatikan siapa Merchant of Record, siapa memegang customer relationship, bagaimana attribution bekerja, dan bagaimana dispute ditangani.

Ini faktor bisnis, bukan hanya teknis.

Jalur Boleh Dua, Fondasi Sebaiknya Satu

UCP dan ACP pantas dipantau karena keduanya mewakili pergeseran commerce dari human-operated interface menuju agent-compatible infrastructure.

Tidak perlu buru-buru memilih satu sebagai masa depan tunggal.

Yang lebih penting adalah membuat bisnis mampu berbicara dengan lebih dari satu ekosistem tanpa kehilangan kontrol atas identitas produk, inventory, pricing, policy, dan transaksi.

Kalau core system kuat, protocol adalah konektor.

Kalau core system berantakan, protocol menjadi pengeras suara untuk kekacauan.

Jadi pertanyaan terbaik bagi tim commerce bukan, “Kita pilih UCP atau ACP?”

Pertanyaannya adalah, “Kalau besok AI agent datang membawa intent pembelian yang valid, apakah sistem kita cukup jelas, cukup fresh, dan cukup aman untuk menjawabnya?”

Kalau jawabannya belum, pekerjaan sebenarnya dimulai dari sana.

Dan satu catatan terakhir: jangan membangun roadmap berdasarkan singkatan. Bangun berdasarkan capability dan risiko. Kalau minggu depan nama protocol berubah tetapi bisnis tetap membutuhkan inventory yang fresh, checkout yang aman, consent yang jelas, dan order state yang bisa diaudit, fondasi itu tetap berguna. Itulah alasan pendekatan protocol-agnostic di core system lebih sehat daripada menjadikan satu standard sebagai pusat seluruh arsitektur.