AI Agent Decision Boundary: Menentukan Batas Otonomi dalam Workflow Bisnis

Enterprise mulai memasuki fase berbeda dalam penggunaan artificial intelligence. Persoalannya bukan lagi hanya apakah AI dapat menjawab pertanyaan, merangkum dokumen, atau memberikan rekomendasi. AI Agent mulai memiliki kemampuan untuk mengambil data dari beberapa sistem, menjalankan tool, memperbarui record, membuat transaksi, menghubungi pihak lain, dan melanjutkan workflow tanpa setiap langkah diperintahkan secara manual.

Perubahan tersebut membuka peluang efisiensi yang jauh lebih besar dibandingkan chatbot tradisional. Microsoft dalam 2026 Work Trend Index menggambarkan perubahan peran ketika agent semakin mengambil bagian dalam execution sementara manusia bergerak lebih jauh ke arah mengarahkan pekerjaan, membuat keputusan, dan memiliki tanggung jawab terhadap outcome. Riset tersebut menggunakan survei terhadap 20.000 pekerja di 10 negara bersama analisis productivity signals Microsoft 365. (Microsoft)

Namun semakin jauh AI bergerak dari recommendation menuju execution, pertanyaan yang harus dijawab perusahaan ikut berubah. Apakah agent boleh mengirim email kepada customer tanpa pemeriksaan manusia? Bolehkah agent menyetujui purchase request? Apakah agent boleh mengubah harga, mengeluarkan refund, membuat purchase order, memblokir supplier, atau mengubah data pada ERP?

Jawabannya hampir tidak pernah sekadar “boleh” atau “tidak boleh”.

Perusahaan membutuhkan decision boundary: batas yang menentukan tindakan apa yang dapat dilakukan agent secara autonomous, tindakan apa yang cukup memberikan notification kepada manusia, tindakan apa yang membutuhkan explicit approval, dan kondisi apa yang harus menghentikan agent serta mengeskalasikan keputusan.

AWS secara eksplisit memperingatkan dua ekstrem. Jika setiap agent action harus melewati human review, approval berubah menjadi bottleneck dan berpotensi menjadi sekadar formalitas. Namun memberikan agent autonomy tanpa batas menciptakan risiko yang sulit dikendalikan. AWS karena itu merekomendasikan oversight yang mengikuti tingkat risiko tindakan. (Dokumentasi AWS)

Pertanyaan enterprise bukan lagi “seberapa pintar AI Agent yang kita bangun?”, tetapi “seberapa besar authority yang seharusnya kita berikan kepada agent untuk bertindak atas nama bisnis?”

Apa Itu AI Agent Decision Boundary?

AI Agent Decision Boundary adalah aturan yang menentukan sejauh mana sebuah agent dapat mengambil keputusan dan menjalankan tindakan secara mandiri di dalam business workflow.

Boundary tersebut berada di antara capability teknologi dan authority bisnis.

Sebuah AI Agent mungkin secara teknis mampu membaca invoice, membandingkannya dengan purchase order, memeriksa penerimaan barang, menemukan perbedaan, lalu melakukan posting transaksi. Namun kemampuan teknis tersebut tidak secara otomatis berarti seluruh tindakan tersebut harus diberikan sebagai authority kepada agent.

Perusahaan perlu memisahkan dua pertanyaan:

Can the agent do it?

dan

Should the agent be allowed to do it autonomously?

Pertanyaan pertama berkaitan dengan capability. Pertanyaan kedua berkaitan dengan governance, risk, accountability, dan business control.

IBM Research pada 2026 menggambarkan kebutuhan ini sebagai governance by construction. Ketika generalist agent memiliki kemampuan menggunakan berbagai tools, production system perlu menentukan tindakan apa yang diizinkan, kapan human oversight dibutuhkan, dan informasi apa yang boleh digunakan. Governance karena itu perlu ditempatkan pada execution path agent, bukan hanya dalam dokumen policy. (IBM Research)

Decision boundary adalah cara membuat prinsip tersebut operasional.

Mengapa Agent Membutuhkan Boundary yang Lebih Jelas daripada Software Tradisional?

Traditional software biasanya memiliki behavior yang relatif deterministic. Jika kondisi A terjadi, sistem menjalankan rule B. Developer menentukan logic lebih awal dan application mengeksekusi logic tersebut.

AI Agent memiliki karakter berbeda.

Agent dapat menerima goal, memahami context, memilih tool, menentukan urutan tindakan, menyesuaikan rencana ketika kondisi berubah, dan menghasilkan keputusan berdasarkan informasi yang ditemukannya selama execution. Semakin agentic sebuah system, semakin banyak discretion yang berpindah dari code path yang ditentukan developer menuju runtime decision.

Perubahan ini memberikan flexibility, tetapi juga menciptakan uncertainty baru.

Microsoft Security menyebut unmanaged autonomy sebagai salah satu risiko utama agentic AI dan menekankan bahwa organisasi perlu menentukan acceptable use, accountability, human-oversight requirement, assurance criteria, serta response process sepanjang lifecycle. (Microsoft Learn)

Bayangkan sebuah agent diberikan objective:

“Pastikan seluruh invoice supplier minggu ini diproses tepat waktu.”

Untuk memenuhi objective tersebut, agent mungkin perlu membaca invoice, mencocokkannya dengan purchase order, mencari receiving record, menghubungi procurement jika ada ketidaksesuaian, membuat reminder, atau memulai payment workflow.

Tetapi beberapa keputusan memiliki konsekuensi yang sangat berbeda.

Mengirim reminder mungkin memiliki risiko rendah.

Mengubah supplier bank account memiliki risiko sangat tinggi.

Menyetujui invoice Rp2 juta mungkin berada dalam boundary tertentu, sementara invoice Rp2 miliar membutuhkan authority manusia.

Karena itu, perusahaan tidak dapat memberikan autonomy hanya berdasarkan jenis agent. Autonomy perlu ditentukan sampai ke jenis tindakan, kondisi, nilai transaksi, data yang terlibat, dan konsekuensi apabila keputusan salah.

Automation dan Autonomy Bukan Hal yang Sama

Perbedaan antara automation dan autonomy penting ketika enterprise mulai menerapkan agentic AI.

Automation menjalankan workflow yang telah ditentukan. Agentic autonomy memberikan system ruang untuk menentukan sebagian dari cara workflow tersebut diselesaikan.

Misalnya, traditional automation dapat memiliki rule:

Jika invoice, PO, dan goods receipt identik → tandai sebagai matched.

Agent dapat bekerja dengan kondisi yang lebih kompleks:

Periksa invoice, identifikasi discrepancy, cari konteks pada purchase order dan communication history, lalu tentukan apakah discrepancy cukup kecil untuk diteruskan atau membutuhkan investigasi.

Pada contoh kedua, agent tidak sekadar menjalankan rule. Ia melakukan interpretation dan decision.

Karena itu, perjalanan dari [Business Process Automation Enterprise]Business Process Automation Enterprise menuju agentic AI bukan hanya peningkatan intelligence. Perusahaan sedang meningkatkan decision authority yang diberikan kepada software.

Semakin besar authority, semakin penting decision boundary.

Tidak Semua Keputusan Membutuhkan Human Approval

Salah satu respons paling mudah terhadap risiko AI adalah mewajibkan manusia memeriksa seluruh tindakan. Pendekatan tersebut terlihat aman tetapi dapat menghilangkan sebagian besar nilai automation.

Bayangkan agent menghasilkan 500 actions per hari dan seluruhnya membutuhkan approval. Operator pada akhirnya menghadapi ratusan notification dan mulai melakukan approval tanpa evaluasi mendalam.

Dalam kondisi tersebut, human-in-the-loop berubah menjadi human bottleneck atau bahkan rubber stamp.

AWS Agentic AI Lens secara khusus menyebut problem ini. Menurut guidance tersebut, uniform oversight dapat membuat tindakan rutin berjalan sangat lambat atau justru membuat tindakan berkonsekuensi tinggi lolos tanpa evaluasi yang tepat. AWS merekomendasikan klasifikasi tindakan ke beberapa tingkat berdasarkan impact dan reversibility. (Dokumentasi AWS)

Artinya, objective yang lebih baik bukan:

“Pastikan manusia menyetujui semua tindakan AI.”

Melainkan:

“Pastikan manusia terlibat pada keputusan di mana human judgment benar-benar mengubah risk profile.”

Perbedaan tersebut menjadi fondasi decision-boundary design.

Crocodic Agent Decision Boundary Framework

Untuk membuat autonomy dapat diterapkan secara operasional, Crocodic dapat memetakan agent actions ke dalam lima tingkat:

Observe → Recommend → Notify & Execute → Request Approval → Escalate

Lima tingkat tersebut bukan sekadar maturity level. Setiap level merupakan decision authority yang berbeda.

Level 1 — Observe

Agent hanya membaca, mengumpulkan, mengklasifikasikan, atau menganalisis informasi tanpa mengubah state dari business system.

Contohnya adalah membaca sales data, mengidentifikasi order yang tertunda, menemukan invoice duplicate, atau mendeteksi inventory anomaly.

Pada level ini, agent memiliki access tetapi belum memiliki execution authority.

Risiko umumnya relatif lebih rendah, meskipun data access tetap perlu dikontrol karena agent dapat berinteraksi dengan sensitive information.

Level 2 — Recommend

Agent diperbolehkan melakukan analysis dan memberikan rekomendasi kepada manusia, tetapi keputusan akhir masih dibuat oleh user.

Contohnya agent menganalisis supplier quotation lalu merekomendasikan vendor, melakukan credit analysis dan merekomendasikan limit customer, atau mengidentifikasi anomaly lalu mengusulkan tindakan.

Model ini cocok ketika judgment memiliki business impact yang tinggi tetapi AI dapat mempercepat information processing.

Level 3 — Notify & Execute

Agent diperbolehkan menjalankan tindakan secara otomatis, tetapi tindakan tersebut dicatat dan pihak terkait mendapatkan notification.

Contohnya agent mengirim reminder terhadap overdue document, memperbarui internal task status, melakukan classification, atau menjalankan routine reconciliation pada kondisi yang telah memenuhi predefined boundary.

Pada level ini, organisasi menerima autonomy karena tindakan relatif rendah risiko atau mudah dibalik.

Level 4 — Request Approval

Agent melakukan seluruh analysis dan menyiapkan action, tetapi execution menunggu explicit human approval.

Contohnya agent mempersiapkan purchase order, menyarankan refund di atas threshold tertentu, menyiapkan perubahan pricing, atau mengidentifikasi transaction yang perlu diblokir.

Human tidak perlu mengulang seluruh pekerjaan agent. Sistem harus memberikan context yang cukup agar reviewer dapat menentukan apakah action boleh dilanjutkan.

Level 5 — Escalate

Agent berhenti mengambil keputusan ketika menemukan kondisi yang berada di luar authority atau confidence boundary.

Kondisi tersebut dapat berupa nilai transaksi yang sangat tinggi, conflicting policies, missing data, security anomaly, regulatory issue, atau scenario yang belum pernah dipetakan.

Pada level ini, keberhasilan agent justru ditunjukkan oleh kemampuannya tidak mengambil keputusan ketika tidak seharusnya mengambil keputusan.

Framework tersebut dapat diringkas menjadi satu prinsip:

Semakin besar consequence dan semakin sulit tindakan dibalik, semakin kecil autonomy yang seharusnya diberikan kepada AI Agent.

Risk dan Reversibility Menjadi Dua Dimensi Utama

Boundary tidak sebaiknya ditentukan berdasarkan tingkat confidence model saja.

AI dapat sangat confident tetapi tetap salah. Sebaliknya, keputusan dengan confidence yang sedikit lebih rendah mungkin tetap aman jika action mudah dibalik dan konsekuensinya rendah.

Karena itu, dua dimensi pertama yang perlu dilihat adalah business impact dan reversibility.

AWS menggunakan konsep serupa pada tiered oversight. Low-risk dan reversible action dapat berjalan autonomous. Medium-risk action dapat berjalan dengan notification. High-risk atau irreversible action membutuhkan explicit approval. (Dokumentasi AWS)

Misalnya, agent yang salah menambahkan tag pada support ticket mungkin mudah diperbaiki. Agent yang salah melakukan bank transfer memiliki konsekuensi yang jauh lebih besar.

Kesalahan yang sama-sama memiliki probabilitas 1% menghasilkan risk profile yang sangat berbeda ketika impact berbeda.

Decision boundary karena itu tidak boleh dibangun hanya dari:

“Seberapa akurat AI kita?”

Pertanyaan yang lebih tepat adalah:

“Apa yang terjadi jika AI salah pada tindakan ini?”

Lima Faktor untuk Menentukan Autonomy

Selain risk dan reversibility, enterprise dapat menggunakan lima faktor untuk menentukan authority agent.

Kelima faktor tersebut dapat menghasilkan decision boundary yang jauh lebih realistis dibandingkan aturan sederhana “AI boleh” atau “AI tidak boleh”.

Sebagai contoh, agent mungkin boleh secara autonomous memberikan discount maksimal 3% untuk customer tertentu jika seluruh rule terpenuhi. Discount 3–10% membutuhkan approval sales manager. Discount lebih dari 10% langsung dieskalasikan ke commercial director.

Sistem yang sama memiliki tiga level autonomy berdasarkan business consequence.

Decision Boundary Sebaiknya Ditanamkan pada Workflow, Bukan Ditulis di SOP Saja

Kesalahan penting dalam AI governance adalah menganggap policy document sudah cukup untuk mengendalikan agent.

Agent bekerja pada runtime.

Karena itu, boundary juga perlu dapat ditegakkan pada runtime.

IBM Research menunjukkan pendekatan governance-by-construction dengan checkpoint seperti intent guard, tool guidance, human approval gate, dan output control. Tujuannya adalah memastikan policy mengintervensi agent pada tahap execution yang relevan, bukan hanya menjadi aturan di luar system. (IBM Research)

Misalnya, policy menyatakan:

AI Agent tidak boleh mengeluarkan refund di atas Rp5 juta tanpa approval Finance Manager.

Aturan tersebut sebaiknya tidak hanya berada pada handbook.

Workflow harus secara teknis memastikan tool issue_refund tidak dapat dieksekusi ketika nilai melebihi boundary sampai approval token diterima.

Dengan demikian, governance berubah dari instruction menjadi enforcement.

Ini juga menjelaskan mengapa enterprise membutuhkan architecture yang berbeda ketika agent mulai berinteraksi langsung dengan ERP, CRM, database, dan system internal. Pembahasan mengenai bagaimana koneksi tersebut dibangun telah dibahas dalam [AI Agent Integration]AI Agent Integration. Decision boundary melengkapi layer tersebut dengan menjawab pertanyaan: setelah agent terhubung ke sistem, tindakan apa yang sebenarnya boleh dijalankan?

Permission Tidak Sama dengan Decision Authority

Enterprise juga perlu membedakan technical permission dari business authority.

Sebuah agent mungkin memiliki API credential yang secara teknis dapat membuat purchase order sampai nilai berapa pun. Namun business authority agent mungkin hanya sampai Rp10 juta.

Jika organisasi hanya bergantung pada technical permission, agent berpotensi melakukan tindakan yang secara sistem diizinkan tetapi secara bisnis seharusnya tidak dilakukan.

Karena itu, architecture agent membutuhkan beberapa lapisan:

Identity → Permission → Policy → Decision Boundary → Execution

Identity menentukan siapa agent tersebut.

Permission menentukan resource yang dapat diakses.

Policy menentukan rule organisasi.

Decision boundary menentukan kapan authority digunakan.

Execution menjalankan tindakan setelah seluruh control terpenuhi.

Microsoft menekankan konsep serupa dalam guidance untuk autonomous agentic AI: organisasi perlu menerapkan minimum necessary tools, data, dan operation, require approval untuk high-risk atau irreversible action, serta menyediakan mekanisme yang memungkinkan pengguna menghentikan agent dengan aman. (Microsoft Learn)

Inilah alasan autonomy tidak sebaiknya dikelola hanya melalui prompt.

Boundary yang kritis perlu memiliki system-level enforcement.

Jangan Gunakan Confidence Score sebagai Satu-Satunya Approval Trigger

Salah satu pendekatan yang terlihat logis adalah menggunakan confidence score:

Jika confidence >95%, agent dapat menjalankan action. Jika di bawahnya, minta manusia.

Namun confidence tidak selalu menggambarkan business risk.

Agent dapat memiliki confidence 99% bahwa invoice cocok, tetapi invoice tersebut bernilai Rp50 miliar. Sebaliknya, agent mungkin memiliki confidence 85% untuk mengklasifikasikan internal support ticket yang sangat mudah diperbaiki jika salah.

Karena itu, decision boundary sebaiknya menggunakan kombinasi:

Risk + Impact + Reversibility + Context + Confidence.

Confidence merupakan satu signal, bukan authority.

Microsoft Research pada ICLR 2026 bahkan memperkenalkan autonomy metrics yang melihat proporsi consequential actions yang dapat dilakukan agent tanpa human-in-the-loop sambil tetap mempertahankan security. Riset tersebut menunjukkan bahwa autonomy sebaiknya dianalisis bersama control yang menjaga confidentiality dan integrity, bukan dipandang sebagai tujuan mandiri. (Microsoft)

Autonomy bukan semakin tinggi semakin baik.

Autonomy yang baik adalah maximum useful autonomy within acceptable risk.

Contoh Decision Boundary pada Procurement

Procurement merupakan contoh yang baik karena satu workflow mengandung berbagai tingkat keputusan.

Agent dapat membaca purchase request, mengecek budget, membandingkan supplier, memeriksa historical price, dan mendeteksi duplicate request.

Sebagian tindakan dapat berjalan otomatis.

Observe: membaca quotation dan procurement history.

Recommend: menyarankan supplier berdasarkan price, SLA, dan performance.

Notify & Execute: mengirim reminder kepada supplier yang belum mengirim dokumen.

Request Approval: membuat PO di atas threshold tertentu.

Escalate: menghentikan workflow jika supplier memiliki compliance issue atau terjadi perubahan rekening bank.

Model tersebut memungkinkan perusahaan memperoleh automation benefit tanpa memberikan seluruh procurement authority kepada agent.

Boundary juga dapat berubah berdasarkan maturity. Setelah performance agent dipantau selama beberapa bulan dan false decision rendah, sebagian action yang sebelumnya membutuhkan approval dapat berpindah ke notify-and-execute.

Dengan kata lain, autonomy dapat earned progressively, bukan diberikan sekaligus.

Contoh Decision Boundary pada Finance

Finance memiliki risk profile yang berbeda.

Agent dapat melakukan reconciliation, menemukan anomaly, mempersiapkan journal entry, atau mengidentifikasi overdue receivable.

Namun membaca laporan keuangan tidak memiliki consequence yang sama dengan melakukan payment.

Contoh boundary:

Agent boleh melakukan reconciliation otomatis ketika nominal dan reference match.

Agent boleh mengidentifikasi potential duplicate invoice tetapi tidak menghapus transaksi.

Agent dapat menyiapkan payment recommendation.

Payment di bawah threshold tertentu dapat mengikuti rule tambahan.

Payment besar membutuhkan approval.

Perubahan bank account selalu membutuhkan independent verification.

Model tersebut menjaga agar AI mengurangi repetitive work tanpa menghilangkan segregation of duties yang menjadi bagian penting dari financial control.

Agent Harus Tahu Kapan Berhenti

Kecerdasan agent sering diukur melalui kemampuan menyelesaikan task.

Dalam enterprise, ada kemampuan lain yang sama pentingnya:

kemampuan mengenali ketika task tidak boleh diselesaikan secara autonomous.

Agent harus dapat berhenti ketika context tidak lengkap, conflicting data muncul, policy tidak jelas, action berada di luar authority, atau risk meningkat di tengah workflow.

Microsoft menyebut human oversight sebagai kemampuan memberikan manusia meaningful control untuk mengarahkan, mengoreksi, dan menghentikan autonomous behavior, terutama pada ambiguous input dan high-impact actions. (Microsoft Learn)

Karena itu, escalation bukan kegagalan automation.

Escalation adalah bagian dari desain automation.

Enterprise agent yang matang bukan agent yang menyelesaikan 100% task tanpa manusia. Agent yang matang adalah agent yang dapat membedakan dengan baik mana yang harus diselesaikan sendiri dan mana yang harus diserahkan kepada manusia.

Approval Harus Memiliki Context, Bukan Sekadar Tombol Yes/No

Human approval juga dapat gagal apabila reviewer tidak mendapatkan informasi yang cukup.

Bayangkan manager menerima notification:

“AI meminta approval PO Rp180 juta. Approve / Reject?”

Informasi tersebut tidak cukup untuk mengambil keputusan.

Approval request yang baik seharusnya memberikan relevant context, misalnya supplier, budget availability, historical price, alasan pemilihan supplier, deviation dari benchmark, risk flag, serta tindakan yang akan dilakukan agent setelah approval.

AWS merekomendasikan approval request berisi action description, reasoning, impact assessment, dan execution history sehingga reviewer dapat mengambil keputusan secara cepat. Guidance tersebut juga menyarankan timeout, escalation path, serta safe fallback apabila reviewer tidak tersedia. (Dokumentasi AWS)

Jadi human-in-the-loop tidak cukup hanya dengan “menambahkan manusia”.

Human oversight harus dirancang agar keputusan manusia benar-benar meaningful.

IBM juga mengingatkan bahwa human-in-the-loop yang hanya menjadi rubber stamp bukan governance yang efektif. Oversight harus menjaga real decision-making authority, bukan sekadar menambahkan signature setelah proses otomatis selesai. (IBM)

Audit Trail Menjadi Bagian dari Decision Boundary

Ketika manusia dan agent berbagi authority, perusahaan perlu mengetahui siapa yang sebenarnya membuat keputusan.

Setiap high-impact action idealnya dapat menjawab:

Agent mana yang mengusulkan tindakan?

Data apa yang digunakan?

Tool apa yang dipanggil?

Policy apa yang berlaku?

Apakah human approval diperlukan?

Siapa yang memberikan approval?

Apa outcome akhirnya?

Tanpa audit trail, accountability menjadi kabur.

AWS merekomendasikan logging approval decision bersama reviewer identity, rationale, dan timestamp. Microsoft juga menekankan observability, logs, telemetry, dan review mechanism sebagai bagian dari agent governance yang matang. (Microsoft Learn)

Ketika jumlah agent meningkat, fungsi tersebut mulai membutuhkan centralized visibility. Crocodic sebelumnya membahas persoalan tersebut melalui [Agent Control Plane untuk Enterprise]Agent Control Plane untuk Enterprise.

Decision boundary menjelaskan authority pada level individual action. Control plane membantu organisasi mengelola authority tersebut ketika jumlah agent, tool, permission, model, dan workflow bertambah.

Decision Boundary Bukan Pengganti AI Governance

Artikel ini juga perlu dibedakan dari broader AI Governance.

[AI Governance di Perusahaan]AI Governance di Perusahaan membahas bagaimana organisasi mengontrol AI secara lebih luas melalui policy, risk management, ownership, monitoring, dan governance mechanism.

Decision boundary berada satu tingkat lebih operasional.

AI Governance bertanya:

“Bagaimana organisasi memastikan AI digunakan secara bertanggung jawab?”

AI Agent Decision Boundary bertanya:

“Pada action ini, apakah agent boleh bertindak sendiri?”

Hubungan keduanya penting karena agentic AI menggeser governance dari model output menuju action execution.

IBM dalam Agentic AI Governance Playbook tahun 2026 menggambarkan pergeseran tersebut sebagai perubahan fokus dari sekadar memvalidasi jawaban menuju mengontrol tindakan. Ketika agent bergerak dari recommendation menuju execution, organisasi perlu mendefinisikan action, monitoring, accountability, ownership, authority, dan boundary yang jelas. (IBM)

Autonomy Sebaiknya Bertambah Secara Bertahap

Enterprise tidak harus menentukan autonomy sebagai keputusan permanen pada hari pertama.

Pendekatan yang lebih aman adalah progressive autonomy.

Agent dapat memulai dari Observe.

Setelah quality cukup baik, bergerak menjadi Recommend.

Kemudian sebagian low-risk action dapat menjadi Notify & Execute.

Setelah audit trail menunjukkan konsistensi, boundary dapat diperluas untuk kondisi tertentu.

High-impact action tetap berada pada Request Approval atau Escalate.

Pendekatan tersebut memungkinkan perusahaan mengumpulkan evidence sebelum menambah authority.

Microsoft Agentic AI Maturity Model juga mengaitkan meningkatnya autonomy dengan kebutuhan decision rights, lifecycle oversight, monitoring, human oversight, dan escalation path yang semakin jelas. (Microsoft Learn)

Artinya, maturity agent tidak hanya berarti agent mampu mengerjakan lebih banyak hal.

Maturity berarti organisasi mampu memberikan lebih banyak autonomy dengan kontrol yang tetap proporsional.

Bagaimana Mengetahui Boundary Terlalu Ketat?

Boundary yang terlalu longgar menghasilkan excessive risk.

Boundary yang terlalu ketat menghasilkan automation yang tidak memberikan business value.

Beberapa tanda boundary terlalu ketat antara lain approval queue terus bertambah, manusia menyetujui hampir seluruh request tanpa perubahan, low-risk action memiliki review process yang panjang, dan cycle time workflow tidak jauh berbeda sebelum dan sesudah agent diterapkan.

Jika 99% approval selalu disetujui, organisasi perlu mengevaluasi apakah human review masih memberikan value atau hanya menjadi ceremonial control.

Beberapa action mungkin dapat dipindahkan ke Notify & Execute dengan monitoring.

AWS juga menggunakan prinsip ini: review harus mengikuti risk dan reversibility sehingga routine action tidak dibebani control yang sama dengan high-consequence decision. (Dokumentasi AWS)

Bagaimana Mengetahui Boundary Terlalu Longgar?

Boundary terlalu longgar ketika agent dapat mengambil tindakan yang consequence-nya lebih besar daripada kemampuan organisasi untuk mendeteksi dan memulihkannya.

Tandanya dapat berupa action yang sulit ditelusuri, permission sangat luas, agent dapat melakukan irreversible action tanpa confirmation, escalation jarang terjadi meskipun scenario kompleks, atau bisnis tidak dapat menjawab siapa pemilik keputusan ketika kesalahan terjadi.

Microsoft menyarankan principle of least privilege untuk autonomous agents: berikan hanya tool, data, dan operation minimum yang dibutuhkan dan default-deny access di luar kebutuhan tersebut. (Microsoft Learn)

Autonomy seharusnya mengikuti kebutuhan workflow, bukan mengikuti maximum capability teknologi.

Hanya karena agent bisa mengakses seluruh ERP bukan berarti agent harus mendapatkannya.

Dari Use Case AI Menuju Authority Design

Crocodic sebelumnya membahas pentingnya memilih use case melalui [AI Business Case]AI Business Case.

Setelah use case dipilih, enterprise membutuhkan pertanyaan tahap berikutnya:

Apa authority yang dibutuhkan agent agar business case tersebut benar-benar bekerja?

Jika authority terlalu kecil, agent hanya menghasilkan rekomendasi tetapi manusia tetap menjalankan hampir seluruh pekerjaan.

Jika authority terlalu besar, perusahaan mendapatkan efficiency tetapi meningkatkan operational risk.

Karena itu, AI Agent design perlu menghubungkan:

Business Value → Workflow → Agent Capability → Decision Authority → Control → Measurement

Authority berada di tengah hubungan antara value dan risk.

Crocodic Perspective: Jangan Otomatisasi Keputusan Sebelum Menentukan Siapa yang Memiliki Risikonya

Dari perspektif enterprise system, keputusan untuk memberikan autonomy sebaiknya tidak dimulai dari kemampuan model.

Mulailah dari business consequence.

Pertama, identifikasi keputusan yang terjadi di dalam workflow. Kedua, tentukan consequence apabila keputusan salah. Ketiga, tentukan apakah action dapat dibalik. Keempat, tentukan data, permission, dan policy yang dibutuhkan. Setelah itu baru tetapkan authority agent.

Urutan tersebut menghasilkan:

Business Process → Decision → Risk → Authority → Agent Action → Measurement

Bukan:

AI Capability → Feature → Deployment.

Perbedaan ini penting karena AI Agent bukan hanya user interface baru. Ketika agent dapat mengubah state pada ERP, CRM, procurement, finance, atau system operasional, perusahaan sedang memberikan software kemampuan untuk bertindak atas nama organisasi.

Authority tersebut perlu didesain seperti authority pada organisasi manusia: ada limit, approval, escalation, accountability, dan audit trail.

AI Agent yang baik bukan agent yang diberi kebebasan sebesar mungkin. AI Agent yang baik adalah agent yang memiliki kebebasan yang tepat untuk mencapai outcome bisnis tanpa melampaui risk appetite perusahaan.

Kesimpulan

Agentic AI menciptakan peluang besar karena software tidak lagi hanya menunggu manusia memberikan setiap instruksi. Agent dapat membaca context, menentukan langkah berikutnya, menggunakan tools, dan menyelesaikan sebagian workflow secara mandiri.

Namun value tersebut hanya dapat berkembang jika autonomy memiliki boundary yang jelas.

Tidak seluruh tindakan perlu approval manusia. Tidak seluruh tindakan juga layak diberikan kepada agent secara autonomous.

Enterprise perlu membedakan kapan agent hanya mengobservasi, kapan memberikan recommendation, kapan dapat melakukan execution dengan notification, kapan membutuhkan approval, dan kapan harus berhenti serta mengeskalasikan keputusan.

AWS, Microsoft, dan IBM sama-sama menunjukkan arah yang konsisten: autonomous agent membutuhkan risk-tiered human oversight, explicit authority boundary, runtime policy enforcement, auditability, dan clear escalation. (Microsoft Learn)

Karena itu, sebelum meningkatkan autonomy AI Agent, perusahaan sebaiknya tidak hanya melakukan assessment terhadap model yang digunakan. Evaluasi juga perlu mencakup workflow, business impact, system integration, permission, approval structure, reversibility, dan accountability.

Ketika perusahaan mulai menghubungkan agent dengan sistem existing, [AI Agent Integration]AI Agent Integration dapat menjadi foundation teknis. Namun integrasi baru menghasilkan enterprise value ketika perusahaan juga menentukan apa yang boleh dilakukan agent setelah memperoleh akses tersebut.

Pada akhirnya, tantangan terbesar Agentic AI bukan membuat agent mampu melakukan lebih banyak tindakan.

Tantangannya adalah memberikan autonomy yang cukup untuk menghasilkan business value, tanpa memberikan authority yang lebih besar daripada risiko yang siap ditanggung perusahaan.