Banyak tim tergoda memberi AI agent akses luas setelah melihat demo yang berjalan mulus. Masalahnya, kondisi production jauh lebih beragam.
Pengguna memberikan instruksi ambigu, API bisa gagal, data terkadang tidak lengkap, dan agent dapat menghadapi situasi yang tidak pernah muncul saat pengujian.
Karena itu, Cara Menentukan Batas Otonomi Agent sebaiknya diperlakukan sebagai proses bertahap. Agent tidak harus langsung dipercaya menjalankan workflow end-to-end.
Mulai dari observasi, rekomendasi, tindakan terbatas, lalu perluas kewenangan hanya setelah data menunjukkan performanya cukup konsisten dan dapat dikendalikan.
1. Gunakan Konsep Graduated Autonomy
Otonomi agent tidak harus statis.
Agent baru dapat memulai sebagai advisor yang hanya memberi rekomendasi. Setelah performanya stabil, agent mulai membuat draft. Tahap selanjutnya agent diperbolehkan mengeksekusi tindakan tertentu yang risikonya rendah.
Microsoft menyarankan tanggung jawab agent diperluas secara incremental setelah reliability terbukti, dibanding memberikan terlalu banyak otonomi sekaligus.
Misalnya sebuah sales agent melewati tahapan berikut:
Bulan pertama, AI hanya menyarankan follow-up. Setelah acceptance rate tinggi, AI boleh membuat draft email. Setelah kualitas draft stabil, agent boleh mengirim email internal tertentu secara otomatis.
Namun untuk penawaran kontrak bernilai besar, approval manusia tetap diwajibkan.
Konsep ini membuat otonomi menjadi sesuatu yang “diperoleh”, bukan diberikan sejak awal.
2. Tentukan Siapa yang Boleh Membuat Keputusan
Pada setiap langkah workflow, tanyakan: siapa yang paling tepat menentukan tindakan berikutnya-kode, model, atau manusia?
Microsoft Agent Framework menggunakan pertanyaan serupa untuk membedakan workflow deterministik, model-driven decision, serta human-in-the-loop gate.
Jika keputusan seharusnya ditentukan aturan bisnis, kode biasa lebih tepat. Jika membutuhkan judgement manusia, buat checkpoint eksplisit.
Misalnya diskon pelanggan:
Diskon di bawah 5% dapat ditentukan business rule.
Diskon 5–15% dapat direkomendasikan AI berdasarkan histori pelanggan.
Diskon di atas 15% membutuhkan persetujuan sales manager.
Pembagian seperti ini membantu mencegah agent mengambil alih keputusan yang sebenarnya sudah mempunyai aturan jelas.
Model seharusnya digunakan pada area yang memang membutuhkan penalaran dan fleksibilitas.
3. Bangun Autonomy Matrix per Tool
Jangan menentukan tingkat otonomi pada level “agent” saja.
Satu agent dapat mempunyai sepuluh tool dengan risiko yang sangat berbeda.
Buat autonomy matrix yang menyimpan informasi seperti jenis tool, apakah action dapat dibatalkan, nilai maksimum transaksi, data yang dapat diakses, approval requirement, dan kondisi eskalasi.
Contohnya search_customer dapat berjalan otomatis, sementara change_customer_address memerlukan validasi identitas. Tool issue_refund boleh otomatis sampai batas tertentu, sedangkan close_account selalu membutuhkan approval.
Microsoft menekankan bahwa autonomy level dapat ditentukan berdasarkan operational, security, dan compliance risk serta permission sebaiknya mengikuti least privilege.
Pendekatan ini juga membuat perubahan kebijakan lebih mudah. Tim tidak perlu mengubah keseluruhan prompt agent hanya untuk mengubah batas satu action.
4. Gunakan Sandbox sebelum Memberi Write Access
Sebelum agent mendapat kemampuan melakukan perubahan nyata, lihat bagaimana ia bertindak di lingkungan aman.
Anthropic merekomendasikan extensive testing dalam sandbox untuk agent yang lebih otonom karena kesalahan dapat terakumulasi sepanjang workflow multi-langkah.
Misalnya agent IT diminta memperbaiki konfigurasi cloud.
Tahap pertama, agent hanya membaca telemetry dan merekomendasikan perubahan. Tahap berikutnya, agent menjalankan perubahan pada sandbox environment. Kemudian sistem mengukur apakah konfigurasi baru memang menyelesaikan masalah.
Barulah setelah tingkat keberhasilan cukup tinggi, agent dapat diberi akses terbatas ke production dengan approval gate.
Sandbox memungkinkan tim melihat pola kesalahan tanpa mempertaruhkan sistem utama.
Kasus gagal juga bisa dimasukkan ke regression test sebelum autonomy diperluas.
5. Ukur Reliability dengan Evals, Bukan Feeling
“Agent terlihat cukup bagus” bukan standar yang cukup untuk menentukan kewenangan.
Tetapkan metrik sebelum meningkatkan autonomy.
Misalnya task success rate harus berada di atas 97%, tool selection accuracy di atas 99%, dan critical error rate berada di bawah batas yang telah ditentukan.
Ukur juga unnecessary tool calls, human correction rate, escalation rate, biaya per task, dan kemampuan agent mendeteksi situasi ketika ia seharusnya berhenti.
OpenAI merekomendasikan pendekatan iteratif: mulai sederhana, uji dengan pengguna nyata, gunakan guardrail serta mekanisme human intervention, kemudian perluas kemampuan ketika reliability meningkat.
Autonomy level akhirnya menjadi keputusan berbasis evidence.
Jika performa menurun setelah model atau tool diperbarui, tingkat kewenangan juga dapat diturunkan kembali.
6. Wajibkan Approval pada Irreversible Action
Ada action yang walaupun jarang gagal, tetap tidak layak dijalankan sepenuhnya otomatis karena dampak satu kesalahan terlalu besar.
Google Cloud secara eksplisit menempatkan transaksi finansial, perubahan production infrastructure, dan komunikasi eksternal sensitif sebagai contoh high-stakes atau irreversible actions yang membutuhkan human authorization.
Agent tetap dapat melakukan 95% pekerjaan.
Misalnya ia membuat rencana deployment, menjalankan test, membandingkan konfigurasi, memeriksa dependency, dan menyiapkan perubahan.
Namun tepat sebelum tool deploy_to_production dipanggil, workflow berhenti.
Manusia kemudian melihat ringkasan perubahan dan dampaknya sebelum menyetujui.
Ini bukan berarti agent gagal menjadi otomatis. Justru sistem memusatkan perhatian manusia hanya pada 5% keputusan yang paling kritis.
7. Siapkan Rollback dan Compensating Action
Human approval bukan satu-satunya mekanisme keselamatan.
Untuk action yang boleh dijalankan otomatis, siapkan rollback ketika memungkinkan.
Misalnya agent mengubah status order dari pending menjadi ready_to_ship. Jika validasi berikutnya menemukan masalah, sistem dapat mengembalikan status sebelumnya.
Untuk tindakan yang tidak bisa benar-benar di-undo, gunakan compensating action.
Jika agent terlanjur membuat booking yang salah, misalnya, tindakan kompensasinya adalah membatalkan booking dan membuat pemesanan baru.
Microsoft memasukkan rollback dan human-in-the-loop sebagai pola recovery ketika workflow agent mengalami kegagalan atau degraded behavior.
Dengan strategi seperti ini, otonomi dapat diperluas tanpa menganggap setiap action pasti berjalan sempurna.
8. Simpan Audit Trail untuk Setiap Action
Semakin besar otonomi, semakin penting kemampuan menjawab pertanyaan: mengapa agent melakukan ini?
Catat tool yang digunakan, parameter penting, identity pengguna, policy yang aktif, approval, hasil action, timestamp, serta state sebelum dan sesudah perubahan.
Audit trail berguna untuk debugging, security investigation, compliance, dan evaluasi sistem.
Microsoft Responsible AI guidance menekankan transparency serta kemampuan menjelaskan batas kemampuan agent dan menjaga manusia tetap berada dalam jalur keputusan consequential.
Namun logging harus tetap memperhatikan privasi.
Jangan menyimpan seluruh prompt, password, credential, atau data pribadi hanya karena trace yang lengkap terasa lebih mudah untuk debugging.
Observabilty yang baik berarti mencatat informasi yang memang diperlukan untuk accountability.
9. Buat Autonomy Budget
Konsep praktis lain adalah autonomy budget.
Alih-alih hanya membatasi jenis action, tetapkan seberapa jauh agent boleh berjalan tanpa konfirmasi baru.
Batasnya dapat berupa maksimal lima tool calls, tiga perubahan data, transaksi total Rp1 juta, atau runtime sepuluh menit.
Jika agent melewati budget tersebut, workflow meminta approval tambahan.
Pendekatan ini berguna untuk tugas terbuka karena risiko sering tumbuh seiring panjangnya trajectory.
Anthropic menyoroti bahwa agent bekerja dalam loop berdasarkan feedback lingkungan dan perlu mempunyai stopping conditions agar proses tetap terkendali.
Autonomy budget membuat agent tetap fleksibel, tetapi tidak mendapat “cek kosong” untuk terus bertindak tanpa batas.
10. Turunkan Otonomi ketika Kondisi Berubah
Graduated autonomy harus bekerja dua arah.
Jika reliability meningkat, kewenangan dapat diperluas. Jika performa turun, autonomy harus bisa dikurangi.
Misalnya setelah mengganti model, tool, atau knowledge source, agent kembali ke mode draft-only sampai regression test selesai.
Begitu juga ketika sistem mendeteksi anomali seperti lonjakan error, prompt injection, perubahan pola transaksi, atau API yang tidak stabil.
Anthropic menekankan bahwa semakin luas kemampuan agent untuk bertindak, semakin penting mitigasi terhadap salah interpretasi intent maupun serangan yang mencoba memengaruhi agent.
Dengan mekanisme downgrade, perusahaan tidak terjebak pada asumsi bahwa tingkat kepercayaan yang diberikan hari ini harus berlaku selamanya.
Cara Menentukan Batas Otonomi Agent di production sebaiknya menggunakan graduated autonomy: mulai dari rekomendasi, ukur reliability, lalu tambah kewenangan secara bertahap.
Terapkan permission per tool, sandbox, approval, rollback, audit trail, dan autonomy budget. Buat level otonomi sebagai konfigurasi yang dapat dinaikkan maupun diturunkan berdasarkan data sehingga otomatisasi tetap cepat tanpa kehilangan kontrol bisnis.