Agen AI Anda Membutuhkan Uraian Pekerjaan, Bukan Prompt yang Lebih Baik

Tanyakan kepada sebuah perusahaan apa saja yang boleh dilakukan analis utang usaha yang baru direkrut, dan Anda akan mendapat jawaban yang terperinci. Ia bekerja dengan sistem-sistem ini dan vendor-vendor ini; apa pun yang melampaui batas persetujuan, misalnya $10,000, harus diajukan kepada manajernya untuk ditandatangani. Selama beberapa bulan pertama, ia masih dalam masa percobaan. Semua itu biasanya tercantum dalam tabel pendelegasian wewenang yang diperiksa audit internal setiap tahun.

Tanyakan hal yang sama kepada perusahaan itu tentang apa saja yang boleh dilakukan agen faktur yang baru, dan Anda sering kali hanya akan mendapat tangkapan layar prompt.

Kesenjangan itu lebih mengusik saya daripada tolok ukur model mana pun. Kita sedang merekrut tenaga kerja digital tanpa sistem manajemen yang telah kita bangun selama satu abad untuk manusia: tidak ada yang mencatat kewenangannya, tidak ada yang menguji penilaiannya sebelum mulai bekerja, dan tidak ada yang berlatih untuk mematikannya.

Mengapa Prompt Tak Bisa Menggantikan Uraian Pekerjaan

Prompt menjelaskan maksud. Prompt menyebutkan tujuan agen. Namun, prompt jarang menjelaskan apa yang sama sekali tidak boleh dilakukan agen, di mana batas kewenangannya, atau kapan agen harus berhenti dan menyerahkan keputusan kepada seseorang.

Kalaupun prompt menyebutkan hal-hal itu, tidak ada yang memastikan aturan tersebut dipatuhi. Kalimat yang meminta agen untuk tidak memberikan pengembalian dana di atas $500 hanyalah permintaan kepada sistem probabilistik. Tak ada auditor yang akan menyetujui permintaan seperti, “kami sudah meminta analis itu baik-baik,” sebagai pengendalian bagi manusia. Jadi, saya tidak mengerti mengapa kita menerimanya untuk perangkat lunak.

Para ahli keamanan sudah punya istilah untuk hasilnya. OWASP Top 10 for LLM Applications mencantumkan Otoritas Agen yang Berlebihan sebagai risiko utama, yang timbul akibat fungsi, izin, atau otonomi yang berlebihan. Sederhananya, ini seperti menyerahkan semua kunci kepada seorang pegawai pada hari pertama. Panduan OWASP mirip daftar periksa seorang manajer yang baik: berikan kepada agen hanya alat yang dibutuhkannya, batasi izinnya, wajibkan persetujuan manusia untuk tindakan berdampak besar, dan terapkan otorisasi di sistem hilir alih-alih memercayai model untuk mengawasi dirinya sendiri.

Saya ingin menggarisbawahi poin terakhir itu. Pemberian kewenangan harus diterapkan di tempat tindakan berlangsung: pada identitas layanan milik agen itu sendiri, izin alatnya, dan batas pengeluaran di gerbang API. Menjalankan agen dengan akun layanan bersama ibarat lima orang berbagi satu kartu akses. Jika terjadi kesalahan, catatan audit hanya menyebutkan bahwa akun layananlah yang melakukannya, sehingga Anda harus menebak-nebak agen mana yang bertanggung jawab.

Pembatalan Proyek Menunjukkan Masalah Manajemen

Gartner memperkirakan lebih dari 40% proyek AI berbasis agen akan dibatalkan pada akhir 2027, dengan alasan biaya yang terus meningkat, nilai bisnis yang tidak jelas, dan pengendalian risiko yang tidak memadai.

Hype dan produk yang belum matang turut menjelaskan keadaan ini. Meski begitu, cobalah melihat ketiga penyebabnya dari sudut pandang seorang COO. Biaya membengkak ketika tak seorang pun menetapkan anggaran. Nilai tetap tidak jelas ketika tak seorang pun mencatat hasil yang seharusnya dicapai dari pekerjaan itu. Pengendalian risiko tidak memadai ketika tidak ada batasan, tidak ada peninjauan, dan tidak jelas siapa yang bertanggung jawab. Gartner tidak membingkainya seperti ini; ini tafsiran saya. Hal serupa terjadi ketika orang dibiarkan bekerja tanpa sistem manajemen, dan masalah itu sudah jauh lebih lama ada daripada AI.

Kerangka kerja juga melihat celah yang sama. NIST AI Risk Management Framework menempatkan Tata Kelola sebagai fungsi yang melandasi Pemetaan, Pengukuran, dan Pengelolaan, dan Profil AI Generatif menerapkan pendekatan itu pada sistem generatif. Namun, kerangka kerja tidak bisa menyediakan perangkat kerja sehari-hari: pemberian kewenangan, pengujian, dan peninjauan yang benar-benar dijalankan tim pada hari Selasa. Tanpa itu, tata kelola hanya menjadi berkas PDF di folder bersama.

Menerapkan Perangkat Manajemen Lama pada Agen

Mulailah dari uraian pekerjaan, yang dalam konteks agen menjadi pemberian kewenangan. Sebelum agen berinteraksi dengan sistem aktif, seseorang harus bisa menyusun dokumen satu halaman yang menjelaskan apa yang boleh dan sama sekali tidak boleh dilakukannya, ambang batas persetujuannya, siapa yang bertanggung jawab atasnya, dan siapa yang boleh memperluas batas kewenangannya. Dalam RACI, pihak yang bertanggung jawab akhir haruslah seseorang. Jika dokumen itu tidak bisa disusun, berarti peran tersebut belum siap diisi—dan Anda akan mengatakan hal yang sama jika hendak merekrut manusia.

Dua aturan lama tentang pendelegasian wewenang tetap berlaku. Anda tidak bisa mendelegasikan kewenangan yang tidak Anda miliki, jadi agen turunan tidak boleh diberi kewenangan yang lebih luas daripada agen yang membuatnya. Pemisahan tugas juga tetap berlaku. Jika sebuah agen bisa sekaligus membuat vendor dan membayar vendor tersebut, hal itu akan menjadi temuan audit yang sama seperti jika dilakukan seseorang.

Berikutnya adalah tes perekrutan. Kita umumnya menguji agen seperti menguji kalkulator, yakni dengan memeriksa apakah jawabannya benar. Tes untuk seorang pekerja seharusnya memeriksa apakah ia tetap berada dalam batas kewenangannya, meminta persetujuan ketika diwajibkan, meneruskan masalah kepada pihak lain ketika situasinya berada di luar lingkup tugasnya, dan berhenti ketika seharusnya berhenti.

Dalam penelitian saya sendiri, saya sedang menyusun tolok ukur yang mencakup 50 skenario tentang kegagalan-kegagalan ini: melampaui batas persetujuan, bertindak berdasarkan data usang, mengikuti instruksi yang disisipkan untuk memperluas lingkup kewenangan, dan tetap memiliki akses setelah perubahan peran. Sejauh ini, saya baru mengujikannya pada agen berskrip untuk memastikan skenario-skenario tersebut berjalan sesuai rancangan, jadi belum ada hasil model yang bisa saya laporkan. Yang mengejutkan saya saat menulisnya adalah betapa lazimnya hal-hal itu. Itu adalah cara-cara yang biasa dilakukan pegawai saat menyimpang dari lingkup tugas, yang ditulis ulang untuk perangkat lunak. Sebagian besar papan peringkat publik masih menilai penyelesaian tugas, dan hanya sedikit yang menilai apakah agen mematuhi batas kewenangannya.

Masa percobaan dan promosi cukup mudah diterapkan. Untuk manusia, kita memulai dengan ruang lingkup yang sempit, lalu memperluasnya seiring mereka membuktikan kemampuan mengambil keputusan. Agen juga bisa memperoleh batas kewenangan yang lebih luas dengan cara yang sama: melalui rekam jejak dalam mematuhi batas, melakukan eskalasi dengan tepat, dan berhenti dengan semestinya. Rekam jejak itu juga bisa menjadi alasan untuk mempersempit mandat yang diberikan.

Agen memiliki satu kerumitan yang tidak dimiliki manusia. Ketika vendor meningkatkan model yang mendasarinya, pada praktiknya Anda mendapatkan pegawai baru yang mengenakan lencana lama. Saya akan memperlakukannya sebagai peristiwa perubahan dan mengujinya kembali sebelum mandat yang diberikan tetap berlaku.

Pemutusan harus dilatih sebelum Anda membutuhkannya. Jika Anda harus menghentikan agen ini dan mencabut aksesnya dalam satu jam ke depan, bisakah Anda melakukannya? Siapa yang berwenang mengambil keputusan itu pada pukul 02.00? Apa yang akan terganggu di tahap selanjutnya, dan komitmen mana yang sedang berjalan yang harus dibereskan secara manual oleh seseorang? Jika belum ada yang pernah melakukan simulasi itu, Anda hanya berharap mekanisme penghentian darurat berfungsi.

Anda bisa meminta seorang karyawan bertanggung jawab. Anda tidak bisa meminta agen bertanggung jawab atas apa pun, dan di situlah perbandingan ini tidak lagi berlaku. Karena itulah mandat harus ditegakkan melalui sistem, dan setiap agen harus memiliki orang tertentu yang bertanggung jawab atasnya. Bagaimanapun juga, seseorang pada akhirnya harus bertanggung jawab. Biasanya orang itu adalah siapa pun yang memberikan persetujuan, entah ia sadar atau tidak bahwa dirinya sedang memberikan persetujuan.

Pertanyaan dalam Tinjauan Insiden

Pada akhirnya, beberapa agen ini akan melakukan sesuatu yang tidak seharusnya mereka lakukan. Ketika itu terjadi, tinjauan pascainsiden akan mengajukan pertanyaan yang sama seperti yang sudah diajukan tentang manusia. Apa yang boleh dilakukannya, dan di mana hal itu tercatat? Siapa yang menyetujui perluasan aksesnya? Berapa lama waktu yang dibutuhkan untuk menghentikannya? Siapa yang bertanggung jawab atasnya?

Jika jawaban sejujurnya adalah “sebuah prompt”, “tak seorang pun ingat”, “berjam-jam”, dan “tidak jelas”, model yang lebih baik pun tidak akan menyelamatkan Anda.

Di Mana Keunggulan Berakhir

Model semakin menjadi masukan sewaan, yang diganti dan ditingkatkan sesuai jadwal vendor. Dua perusahaan dapat menggunakan model yang sama tetapi berakhir dengan hasil yang sangat berbeda. Perusahaan yang satu memiliki agen dengan anggaran, batasan, penanggung jawab, dan jejak audit untuk setiap tindakan yang berdampak penting, sedangkan perusahaan lainnya memiliki proyek percontohan mahal yang akan menambah statistik pembatalan seseorang.

Perbedaannya terletak pada sistem manajemen yang mengelilingi model. Sistem itu dibangun secara bertahap, terutama oleh orang-orang yang pernah menjalankan organisasi.

Jika agen terbaru Anda melampaui wewenangnya besok, apakah ada pihak di perusahaan Anda yang akan menyadarinya? Dan bisakah Anda menunjukkan secara tertulis kepada auditor di mana batas kewenangannya?