AI Agents dan Return Policy: Kenapa Kebijakan Harus Machine-Readable

Ada momen kecil yang kelihatannya sepele dalam belanja online.

User sudah hampir checkout. Produk cocok, harga masuk budget, ongkir masih masuk akal. Lalu satu pertanyaan muncul:

“Kalau ukurannya nggak pas, bisa balikin?”

Untuk manusia, pertanyaan itu bisa dijawab dengan membuka halaman return policy, membaca beberapa paragraf, lalu menebak apakah produknya termasuk pengecualian.

Untuk AI agent yang ikut membantu keputusan atau transaksi, jawaban seperti “silakan lihat syarat dan ketentuan yang berlaku” bukan informasi yang cukup.

Agent perlu tahu kondisi secara operasional.

Return diterima atau tidak?
Berapa hari?
Mulai dihitung dari order, pengiriman, atau barang diterima?
Barang diskon bisa dikembalikan?
Siapa yang membayar ongkir balik?
Refund kembali ke metode pembayaran atau store credit?
Apakah produk tertentu final sale?
Apakah exchange tersedia?
Wilayah mana yang berlaku?

Di sinilah return policy berhenti menjadi halaman legal di footer dan mulai menjadi bagian dari commerce infrastructure.

Machine-readable bukan berarti manusia tidak perlu membaca

Ada salah paham yang sering muncul ketika tim mendengar istilah machine-readable.

“Berarti kita bikin schema aja, beres?”

Tidak.

Kebijakan yang baik tetap harus punya versi human-readable yang jelas. Structured representation hanya membantu sistem memetakan elemen-elemen penting tanpa harus menebak dari prose yang panjang.

Kalau halaman manusia mengatakan satu hal dan structured data mengatakan hal lain, kita justru membuat conflict.

Prinsipnya sederhana:

human-readable adalah contract surface untuk pengguna,
machine-readable adalah structured representation dari kebijakan yang sama.

Keduanya harus berasal dari source of truth yang sama.

Google sudah memberi contoh konkret bahwa arah ini bukan teori. Dokumentasi Google Search mendukung MerchantReturnPolicy structured data. Merchant bisa mendeskripsikan kebijakan return pada level organisasi, dan untuk produk dengan kebijakan berbeda dapat menempatkan policy pada level Offer sesuai dukungan yang tersedia.

OpenAI juga sudah memasukkan return data dalam product feed Agentic Commerce. Dalam spesifikasi yang tersedia saat ini ada accepts_returns, return_deadline_in_days, accepts_exchanges, dan return_policy URL. Dokumentasinya secara eksplisit menempatkan return information sebagai cara menetapkan ekspektasi buyer dan mengurangi kebingungan pasca-pembelian.

Dua implementasi ini tidak identik. Jangan disamakan seolah satu schema universal. Tetapi arahnya jelas: commerce system membutuhkan policy yang lebih terstruktur.

Kenapa AI agent lebih sensitif terhadap policy ambiguity

Manusia punya kemampuan improvisasi tinggi.

Ketika membaca:

“Pengembalian dapat dilakukan sesuai syarat yang berlaku.”

manusia mungkin chat customer service.

Agent bisa melakukan hal yang sama jika workflow mendukung, tetapi ambiguity memperpanjang task, menambah tool calls, dan meningkatkan risiko jawaban salah.

Sekarang bayangkan user memberi instruksi:

“Cari sepatu lari di bawah dua juta. Yang bisa diretur minimal 14 hari kalau size nggak cocok.”

Return policy menjadi filter keputusan, bukan informasi tambahan.

Kalau data produk sangat bagus tetapi return policy tidak bisa dipahami secara konsisten, agent menghadapi tiga pilihan buruk:

mengabaikan constraint,
menebak,
atau mengecualikan produk karena tidak dapat memverifikasi policy.

Kita tidak bisa menjamin platform akan mengambil opsi tertentu. Tetapi dari perspektif information architecture, membuat policy ambigu jelas bukan strategi yang kuat.

Policy perlu dipecah menjadi decision fields

Cara termudah menguji apakah return policy machine-friendly adalah mengubah prose menjadi pertanyaan keputusan.

Misalnya policy asli:

“Barang dapat ditukar atau dikembalikan dalam waktu tertentu selama memenuhi syarat, kecuali produk tertentu, barang promo, dan barang yang telah digunakan.”

Kalimat ini terdengar legal-ish tetapi operasionalnya lemah.

Tim perlu memecahnya:

Accepts returns: yes/no.
Return window: berapa hari.
Window starts from: delivery date atau event lain.
Condition: unopened, unused, tag attached, atau kondisi lain.
Exclusions: kategori apa saja.
Return method: drop-off, pickup, mail.
Return fee: gratis, fixed fee, customer-paid.
Refund method: original payment, credit, replacement.
Exchange: yes/no.
Geography: berlaku di mana.
Proof required: receipt, order ID, packaging.
Policy version: kapan berlaku.

Tidak semua platform punya field untuk semua hal tersebut. Itu tidak masalah.

Internal policy model sebaiknya lebih kaya daripada schema platform. Dari internal model itu, merchant memetakan subset yang didukung masing-masing channel.

Jangan mendesain policy berdasarkan satu platform saja

Ini jebakan integrasi yang sangat umum.

Tim menemukan format dari satu provider, lalu menjadikan format itu database internal.

Enam bulan kemudian provider lain membutuhkan struktur berbeda, dan data tidak cukup.

Lebih matang jika organisasi punya canonical return policy model sendiri.

Contoh:

Policy ID: RP-ID-2026-04.
Applies to: standard physical goods.
Countries: Indonesia.
Return window: 14 days after delivery.
Exchange: allowed.
Return shipping: customer-paid except defective goods.
Refund method: original payment method.
Exceptions: personalized goods, opened hygiene items, final-sale SKUs.
Effective date: 1 April 2026.
Owner: commerce operations.
Approval: legal + operations.

Kemudian mapping dibuat ke:

website prose,
Google structured data,
OpenAI product feed,
marketplace configuration,
customer service knowledge base,
checkout system,
order confirmation.

Sekarang policy menjadi controlled data object, bukan copy yang tersebar.

“Yang di website 30 hari, tapi sistem kita 14 hari”

Ini bukan contoh hipotetis yang aneh. Organisasi besar sering punya policy drift.

Legal mengubah dokumen.
Marketing belum update landing page.
Marketplace punya konfigurasi sendiri.
Customer service masih pakai macros lama.
Product feed dibuat dari spreadsheet yang belum direvisi.

Seorang user akhirnya bertanya ke AI:

“Kalau beli hari ini, return-nya berapa lama?”

AI menemukan dua angka.

Masalahnya kemudian disebut “AI hallucination”.

Padahal sumber konfliknya datang dari organisasi sendiri.

Ini distinction yang penting.

Hallucination adalah satu kelas masalah.
Evidence conflict adalah kelas masalah lain.
Stale source adalah kelas lain lagi.

Return policy governance harus mampu membedakan ketiganya.

Product-level exception adalah tempat banyak sistem rusak

Kebijakan organisasi sering cukup sederhana sampai ada pengecualian.

Elektronik mungkin punya syarat berbeda.
Produk personal care bisa tidak dapat dikembalikan setelah dibuka.
Barang custom bisa final sale.
Fashion mungkin menerima size exchange.
Produk digital punya aturan berbeda lagi.

Kalau semua SKU mewarisi policy yang sama padahal tidak benar, data machine-readable justru mempercepat penyebaran kesalahan.

Karena itu inheritance model penting.

Default policy di level organisasi.
Override hanya ketika benar-benar diperlukan.
Setiap override punya reason dan owner.

Google sendiri membedakan organization-level return policy dan product-level policy untuk kebutuhan tertentu. OpenAI feed juga menyediakan return information di data commerce. Ini memberi tim architecture satu pelajaran: policy harus bisa diwariskan tetapi juga bisa di-override secara eksplisit.

Agentic checkout membuat policy makin dekat ke transaksi

Dalam Agentic Commerce Protocol OpenAI, merchant tetap memproses order dan payment di sistemnya sendiri. Checkout session harus mengembalikan cart state yang authoritative, termasuk items, pricing, fees, shipping, discount, totals, status, messages, dan links yang relevan.

Artinya merchant tidak bisa menganggap AI interface sebagai pihak yang mengambil alih seluruh tanggung jawab commerce.

Return, refund, chargeback, fulfillment, dan compliance tetap punya dependency besar pada sistem merchant.

Kalau return policy berubah setelah discovery tetapi sebelum checkout, sistem perlu punya mekanisme agar state terbaru yang authoritative menang.

Ini alasan lain kenapa policy membutuhkan versioning.

Jangan hanya simpan “return policy sekarang”.

Simpan:

policy version,
effective_from,
effective_to bila ada,
produk yang tercakup,
order date applicability,
channel applicability,
change reason.

Karena ketika dispute muncul dua bulan kemudian, pertanyaannya bukan “policy sekarang apa?”

Pertanyaannya: “policy apa yang berlaku saat transaksi itu terjadi?”

Machine-readable tanpa versioning bisa tetap menjadi sumber kekacauan.

Bagaimana menulis halaman return policy yang tetap manusiawi

Machine readability tidak mengharuskan halaman terlihat seperti database.

Untuk pengguna, halaman bisa dimulai sangat sederhana:

“Kamu punya 14 hari sejak barang diterima untuk mengajukan return pada sebagian besar produk. Produk harus belum digunakan dan tetap dalam kondisi yang dipersyaratkan. Beberapa kategori punya pengecualian.”

Lalu tampilkan section yang jelas:

Produk yang bisa diretur.
Produk yang tidak bisa diretur.
Batas waktu.
Cara mengajukan.
Biaya pengiriman balik.
Waktu refund.
Exchange.
Produk rusak atau salah kirim.
Kontak bantuan.
Tanggal berlaku kebijakan.

Prose-nya tetap natural.

Di belakangnya, data yang sama punya structured representation.

Humanis bukan berarti vague.

Justru policy yang humanis mengurangi cognitive load.

Apa yang harus divalidasi sebelum publish

Tim commerce bisa memakai checklist kecil.

Pertama, semantic consistency.

Apakah angka hari sama di semua channel?

Kedua, scope consistency.

Apakah produk yang excluded benar-benar ditandai excluded di sistem?

Ketiga, transaction consistency.

Apakah checkout dan post-purchase flow menjalankan policy yang sama?

Keempat, machine mapping.

Apakah field structured data sesuai dengan halaman publik?

Kelima, freshness.

Apakah policy punya effective date dan owner?

Keenam, edge cases.

Bagaimana defective goods, wrong item, partial return, bundle, gift, promo, atau cross-border order diperlakukan?

Ketujuh, evidence.

Bisakah tim menunjukkan versi policy yang berlaku untuk order tertentu?

Ini lebih penting daripada sekadar “schema valid”.

Jangan klaim terlalu jauh

Ada godaan setelah menerapkan MerchantReturnPolicy atau return fields dalam product feed untuk mengatakan:

“Sekarang produk kita akan lebih direkomendasikan AI.”

Itu tidak defensible tanpa evidence.

Yang bisa kita katakan:

structured policy mengurangi ambiguity,
memudahkan platform yang mendukung field tersebut memahami kebijakan,
memberi user informasi lebih konsisten,
dan membantu agent melakukan filtering atau checkout dengan context yang lebih jelas ketika sistem memanfaatkan data itu.

Apakah itu meningkatkan ranking atau recommendation probability pada platform tertentu?

Harus diuji atau menunggu dokumentasi resmi.

Machine-readable policy adalah governance problem

Bagian paling sulit sebenarnya bukan menulis JSON-LD atau menambah kolom feed.

Bagian sulitnya adalah menentukan siapa yang boleh mengubah policy.

Legal?
Commerce?
Customer experience?
Finance?
Marketplace team?

Kalau semua bisa mengubah tanpa approval dan version log, representation akan kembali drift.

Model yang lebih aman:

Legal menetapkan constraint.
Commerce operations mendefinisikan implementasi.
Engineering memelihara canonical data model.
Channel owners memetakan ke platform.
QA melakukan cross-channel validation.
Customer service menerima change notification.

Setiap perubahan tercatat.

Di situlah return policy menjadi infrastructure.

Bukan karena policy harus dibaca robot.

Karena sekarang keputusan belanja bisa dibantu sistem yang membutuhkan fakta eksplisit, dan fakta eksplisit hanya reliable jika organisasinya punya source of truth.

AI agents membuat kelemahan lama menjadi lebih mahal

Dulu policy yang ambigu mungkin hanya menghasilkan beberapa chat ke customer service.

Dalam agentic commerce, ambiguity bisa terjadi lebih awal di funnel.

Produk mungkin gagal masuk shortlist karena constraint tidak dapat diverifikasi.
Agent mungkin harus meminta klarifikasi.
Checkout mungkin berhenti.
User bisa menyetujui transaksi dengan expectation yang salah.
Dispute bisa muncul setelah barang diterima.

Jadi return policy bukan aksesori setelah conversion.

Ia bagian dari product decision.

Pada akhirnya, alasan kebijakan harus machine-readable bukan karena kita ingin website bicara “bahasa robot”.

Justru sebaliknya.

Kita ingin bisnis berhenti menyimpan aturan penting dalam kalimat kabur yang bahkan manusia internal sering menafsirkannya berbeda.

Policy yang baik punya arti yang sama ketika dibaca user, customer service, marketplace, search system, dan AI agent.

Kalau semua pihak membaca hal yang sama dan mengambil kesimpulan yang berbeda, kita punya problem desain.

Kalau semua pihak membaca data yang berbeda, kita punya problem governance.

Machine-readable return policy membantu mengurangi keduanya, selama representasinya tetap setia pada kebijakan nyata yang berlaku.