Siapa yang Bertanggung Jawab Saat AI Agent Melakukan Transaksi yang Salah?

Bayangin perusahaan memberi AI agent akses procurement.

Agent punya objective: “beli kebutuhan kantor kalau stok turun.”

Awalnya aman.

Kertas. Tinta printer. ATK.

Lalu suatu hari agent salah membaca spreadsheet.

Bukan pesan 20 box.

Pesan 2.000.

Invoice keluar.

Vendor proses.

Siapa bertanggung jawab?

AI?

Developer?

Perusahaan?

Pegawai yang memberi prompt?

Vendor model?

Ini salah satu problem hukum paling menarik di era agentic AI.

Karena AI sekarang bukan cuma menjawab.

Ia bisa bertindak.

Indonesia sebenarnya sudah punya konsep hukum yang surprisingly relevan jauh sebelum LLM modern muncul, yaitu “Agen Elektronik” dalam UU ITE dan PP 71 Tahun 2019.

UU ITE mengatur bahwa pengirim atau penerima dapat melakukan transaksi elektronik sendiri, melalui pihak yang dikuasakan, atau melalui Agen Elektronik. Dalam struktur itu, jika transaksi dilakukan melalui Agen Elektronik, akibat hukum dalam pelaksanaan transaksi pada prinsipnya dikaitkan dengan penyelenggara Agen Elektronik, dengan pengecualian dan pembagian tanggung jawab tertentu.

Tapi jangan lompat kesimpulan.

Tidak semua AI agent otomatis bisa diperlakukan identik dengan konsep Agen Elektronik tanpa melihat fungsi dan konstruksi hukumnya.

Teknologi generative AI 2026 jauh lebih kompleks daripada software transaksi otomatis era awal UU ITE.

Namun kerangka yang sudah ada memberi satu pelajaran penting:

automation tidak membuat tanggung jawab hilang.

AI tidak punya kantong untuk bayar kerugian

Ini baseline.

AI agent bukan manusia atau badan hukum.

Kalau salah transaksi, kita tetap mencari pihak yang mengoperasikan, menyediakan, atau menggunakan sistem.

Perusahaan tidak bisa bilang: “agent kami punya autonomy.”

Autonomy teknis bukan legal personality.

Kalau perusahaan memberi agent akses purchasing, perusahaan mengambil keputusan governance.

Permission.

Limit.

Vendor.

Approval.

Jadi tanggung jawab akan dilihat melalui struktur manusia dan organisasi.

Bukan model sebagai pihak independen.

Pertanyaan pertama: siapa penyelenggara sistem?

Kalau perusahaan sendiri membangun agent dan mengoperasikan infrastructure, posisi responsibility kuat.

Kalau menggunakan SaaS vendor, relation lebih kompleks.

Vendor menyediakan platform.

Company configure.

Employee instruct.

Model provider upstream.

Kontrak menentukan sebagian risk allocation.

Tapi kontrak tidak otomatis memindahkan semua tanggung jawab terhadap pihak ketiga.

Kalau customer dirugikan oleh service perusahaan, customer tidak selalu harus mengejar model provider global.

Company tetap punya relationship.

Supply chain risk harus dipetakan.

Pertanyaan kedua: apakah user salah memberi instruksi?

Misalnya employee mengetik: “beli 2.000 unit.”

Agent melakukan persis.

Ini bukan model error.

Human input error.

Responsibility berbeda.

UU ITE sendiri sudah mengenal perbedaan ketika kerugian timbul akibat kelalaian pengguna layanan dalam konteks Agen Elektronik.

Intinya: causation matters.

Siapa melakukan kesalahan?

Sistem? User? Third party? Force majeure?

Jangan semua incident disebut “AI error”.

Root cause harus jelas.

Pertanyaan ketiga: apakah agent diberi permission terlalu besar?

Misalnya task seharusnya hanya recommend purchase.

Tapi company memberi permission direct payment sampai Rp1 miliar.

Agent salah.

Ini governance failure.

Model mungkin melakukan kesalahan probabilistik yang sebenarnya expected.

Company memilih tidak memasang approval.

Dalam incident analysis, control design akan dipertanyakan.

Kenapa tidak ada transaction limit?

Kenapa tidak ada confirmation?

Kenapa tidak ada human approval?

Ini relevan karena PP 71/2019 untuk Agen Elektronik sudah mengatur fitur perlindungan pengguna seperti koreksi, pembatalan perintah, konfirmasi atau rekonfirmasi, memilih meneruskan atau berhenti, mengecek status transaksi, dan membaca perjanjian sebelum transaksi.

Prinsip ini sangat cocok untuk AI agent.

Agent tidak seharusnya menjadi one-way action machine.

Harus ada checkpoint.

Transaction limit adalah rem

Kalau agent hanya boleh transaksi maksimal Rp1 juta, salahnya terbatas.

Kalau limit Rp1 miliar, blast radius besar.

Autonomy harus punya budget.

Per hari.

Per transaksi.

Per vendor.

Per kategori.

Ini basic control.

High value: human approval.

Unusual pattern: pause.

New vendor: review.

Agent bisa cepat.

Governance harus menjaga radius.

Jangan memberi kartu kredit unlimited ke software probabilistik.

Confirmation juga penting

Bayangin agent menyusun action:

“Order 2.000 unit, total Rp480 juta.”

Sebelum execute, user melihat.

Confirm.

Simple.

Friksi sedikit.

Risk turun besar.

Untuk low-value repetitive transaction, confirm bisa otomatis berdasarkan rule.

High-value manual.

Dynamic approval.

AI membantu.

Rule menjaga.

Human memegang material decision.

Contract dengan vendor harus jelas

Kalau agent vendor bug dan menyebabkan transaksi salah, perusahaan perlu tahu remedy.

SLA.

Liability.

Indemnity.

Audit.

Incident notice.

Model change.

Kalau terms vendor bilang: “use at your own risk, liability capped USD 100,” untuk procurement kritis itu mungkin unacceptable.

Enterprise contract perlu negotiate.

Jangan menjalankan core financial action dengan consumer terms.

Cheap subscription bisa menghasilkan expensive liability.

Model provider upstream bisa berbeda dengan agent vendor

Misalnya vendor agent memakai model OpenAI atau Google.

Customer contract dengan vendor agent.

Vendor contract dengan model provider.

Kalau model hallucinate, siapa bertanggung jawab?

Dari perspektif customer, biasanya pertama lihat kontrak dengan vendor agent.

Vendor bisa punya recourse upstream.

Jangan membuat customer memecahkan supply chain.

Good architecture legal punya clear responsible party.

Jangan semua pihak menunjuk pihak berikutnya.

Agent perlu identity sendiri

Kalau agent login memakai akun CFO, audit kacau.

Action terlihat dilakukan CFO.

Padahal software.

Agent perlu service identity.

Log: agent A. Initiated by user B. Approved by C. Tool D.

Ini penting untuk forensic.

Siapa memulai.

Siapa approve.

Siapa execute.

Without identity, liability investigation susah.

Security juga lebih buruk.

Credential sharing.

No trace.

Enterprise agent harus diperlakukan seperti digital actor dengan identity, walaupun bukan legal person.

Rollback harus dipikirkan sebelum transaksi

Banyak action irreversible.

Bank transfer.

Order shipped.

Contract sent.

Untuk reversible action, agent bisa lebih autonomous.

Draft. Cart. Pending transaction.

Untuk irreversible, approval higher.

Design autonomy berdasarkan reversibility.

Ini principle powerful.

Kalau salah bisa undo dalam satu klik, risk rendah.

Kalau salah menyebabkan uang keluar, higher.

AI agent harus tahu stop condition

Kalau data ambiguous: stop.

Kalau amount extreme: stop.

Kalau new vendor: stop.

Kalau model confidence rendah: stop.

Kalau policy conflict: stop.

Agent yang selalu harus menyelesaikan task berbahaya.

Success metric jangan: “task completion 100%.”

Kadang success adalah refusal.

Escalate.

Ask human.

Safety means knowing when not to act.

Perusahaan perlu agent transaction policy

Satu halaman saja bisa mulai.

Agent boleh: buat draft PO.

Agent boleh otomatis: order recurring item di bawah Rp2 juta dari vendor approved.

Agent wajib approval: new vendor, amount besar, payment.

Agent dilarang: ubah bank account vendor tanpa verification.

Policy kemudian diterjemahkan ke technical control.

Bukan PDF doang.

System enforce.

Ini membuat governance concrete.

Insurance mungkin ikut berkembang

Kalau AI agent melakukan transaksi, insurer akan melihat risk control.

Logging.

Limits.

Human approval.

Vendor.

Cybersecurity.

Seperti cyber insurance.

Perusahaan dengan governance bagus mungkin mendapat pricing lebih baik.

Belum tentu market Indonesia langsung besar.

Tapi direction masuk akal.

AI liability akan menjadi financial risk category.

Incident pertama akan mengajari market.

Regulator juga perlu memperbarui konsep Agen Elektronik

Ini area yang menarik untuk UU AI atau aturan turunan ITE.

Konsep Agen Elektronik sudah ada.

Tapi generative agent membawa capability baru.

Dulu system biasanya deterministic.

Sekarang agent bisa reasoning, memilih tool, dan menjalankan langkah berbeda.

Apakah definisi dan liability yang ada cukup?

Mungkin perlu clarification.

Jangan buru-buru buang framework lama.

Bisa dikembangkan.

Hukum sebaiknya technology-neutral.

Kalau fungsi sama: software melakukan transaksi otomatis.

Prinsip responsibility tetap.

Tapi autonomy modern membutuhkan control baru.

Prompt injection misalnya.

Kalau agent membaca email berbahaya dan melakukan transaksi karena hidden instruction, siapa salah?

Security architecture matters.

Vendor. Deployer. User.

Liability bisa shared.

Tidak ada satu jawaban untuk semua.

Itu sebabnya logs penting.

Transaction yang salah juga bisa menjadi consumer issue

Kalau agent perusahaan salah charge customer, customer rights tetap berlaku.

Refund.

Complaint.

Compensation sesuai hukum dan fakta.

Perusahaan tidak boleh meminta customer memahami chain AI.

“Model provider kami error.”

Bukan problem customer.

Customer bertransaksi dengan company.

Company resolve.

Internal liability bisa diurus belakangan.

Ini prinsip customer experience juga.

Jangan technical complexity dibebankan ke korban.

Siapa yang bertanggung jawab saat AI Agent melakukan transaksi yang salah?

Jawabannya tergantung root cause, kontrak, architecture, dan siapa mengendalikan sistem.

Tapi satu hal cukup jelas: bukan AI yang berdiri sendiri.

Tanggung jawab kembali ke manusia dan organisasi yang memberi authority, menyediakan sistem, mengoperasikan, dan mengambil manfaat dari automation.

Indonesia sudah punya konsep Agen Elektronik yang menunjukkan automated transaction tidak berada di luar hukum.

Sekarang tantangannya adalah memperbarui governance untuk agent yang lebih autonomous.

Permission.

Limit.

Confirmation.

Identity.

Audit.

Rollback.

Perusahaan juga perlu memikirkan konsep dual control untuk transaksi tertentu. Sama seperti pembayaran besar kadang membutuhkan dua otorisasi manusia, agent bisa menjadi satu pihak yang menyiapkan action tetapi eksekusi final membutuhkan approver terpisah.

Ini sangat berguna untuk perubahan rekening vendor, refund besar, atau kontrak material.

Agent juga sebaiknya punya daftar vendor approved. Kalau diminta membeli dari domain baru, jangan langsung execute. Masuk review.

Control sederhana seperti ini memblok banyak failure tanpa harus membuat model lebih pintar.

Dan ketika incident terjadi, jangan hanya memperbaiki satu prompt. Cari systemic cause. Kalau masalahnya permission terlalu luas, ubah permission. Kalau data input buruk, perbaiki pipeline. Kalau vendor model tidak stabil, lakukan re-evaluation.

Prompt patch saja sering cuma menutupi gejala.

Liability management yang matang selalu mencari control yang membuat error serupa lebih sulit terjadi lagi.

Intinya, autonomy harus bertambah seiring bukti reliability, bukan diberikan penuh sejak hari pertama.

Semakin besar nilai transaksi dan semakin sulit dibatalkan, semakin kuat approval dan logging yang dibutuhkan.

Itu garis kontrol yang sehat.

Kalau lima hal ini tidak ada, perusahaan sebenarnya sedang memberi kuasa finansial ke software tanpa rem.

Dan ketika salah, pertanyaan “siapa yang bertanggung jawab?” akan jauh lebih mahal daripada biaya membangun control sejak awal.