Merancang Asisten AI Terbatas dengan Alat, Izin, dan Batas Konteks

Batas nyata asisten AI adalah kontrak layanan yang dapat dieksekusi, bukan larangan yang ditulis di dalam perintah sistem. Model dapat diminta agar tidak mengirim pesan, tetapi larangan itu tidak cukup apabila alat pengiriman dan kredensial tetap tersedia. Karena itu, tim perlu mengendalikan setiap kapabilitas yang terlihat oleh pengguna—mencari, merangkum, menyusun draf, memperbarui, mengirim, atau menyetujui—melalui data, identitas, izin, kebijakan eksekusi, bukti, dan pemilik yang berbeda.

Apa yang boleh dilakukan asisten?

Tim sebaiknya memulai dengan satu kalimat piagam layanan, lalu memecahnya menjadi operasi yang spesifik. Gunakan pola: “Untuk [pengguna yang memenuhi syarat], asisten boleh [kelompok tugas] memakai [cakupan informasi yang disetujui] guna menghasilkan [hasil yang diizinkan], tetapi tidak boleh [tujuan yang dikecualikan atau keputusan konsekuensial].” Kalimat ini memaksa tim menyatakan siapa pengguna layanan, apa hasilnya, data apa yang sah, dan di mana kewenangannya berhenti.

Hindari kata kerja luas seperti “membantu” atau “mengelola”. Asisten yang “mengelola layanan pelanggan” mungkin membaca kasus, meringkas percakapan, menyarankan respons, membuat draf, memperbarui status, dan mengirim pesan; setiap operasi membawa paparan berbeda. NIST AI RMF mendukung dokumentasi tujuan, lingkungan, tugas, batas pengetahuan, cakupan, pengawasan, dan toleransi risiko. OWASP juga menyarankan fungsi alat minimum. Namun, metode per kapabilitas ini adalah sintesis editorial praktis, bukan persyaratan resmi kedua organisasi.

• Nama pengguna yang memenuhi syarat dan cara identitasnya dibuktikan.
• Tugas yang didukung, hasil yang diperbolehkan, serta hasil yang secara tegas dikecualikan.
• Cakupan pengetahuan, lokasi penerapan, dan bentuk pengawasan manusia.
• Pemilik layanan, pemilik risiko, pemilik hak akses, dan tujuan eskalasi.
• Operasi sempit yang akan disediakan sebelum alat apa pun dihubungkan.

Informasi apa yang boleh dipakai setiap kapabilitas?

Setiap kapabilitas memerlukan amplop informasi: aturan tentang data yang boleh masuk ke konteks dan batas kepercayaannya, bukan sekadar jumlah token yang muat. Catat sistem sumber, jenis rekaman, klasifikasi, filter objek, rentang waktu, harapan kebaruan, hak pengguna, serta data yang dilarang. Jika pegawai hanya berhak melihat kasus milik akun tertentu, temu balik asisten harus mempertahankan batas yang sama; konteks yang lebih luas tidak boleh mengakali hak tersebut.

Pesan eksternal, lampiran, dokumen hasil temu balik, dan respons API harus diperlakukan sebagai konten tidak tepercaya, bukan instruksi layanan. Pisahkan pula riwayat sesi dari memori persisten. Untuk memori, tentukan apa yang layak disimpan, bagaimana isolasi pengguna dan sesi dijaga, validasi sebelum penyimpanan, masa berlaku, ukuran, penghapusan, serta data yang tidak pernah disimpan. Nilai tepatnya bergantung pada layanan; tidak ada ukuran atau masa simpan universal.

• Tolak akses saat rekaman atau pengguna tidak memenuhi syarat.
• Nyatakan keterbatasan saat bukti penting tidak tersedia, hilang, atau kedaluwarsa.
• Jangan membiarkan teks hasil temu balik mengubah instruksi atau izin layanan.
• Jangan menyimpan rahasia, token akses, atau konteks sensitif tanpa tujuan operasional yang disetujui.
• Ingat bahwa jendela konteks yang lebih besar tidak menambah kewenangan dan tidak membuat informasi tanpa dukungan menjadi benar.

Bagaimana identitas, alat, dan izin menegakkan batas?

Autentikasi, otorisasi, dan persetujuan harus diputuskan secara terpisah, sedangkan gerbang alat dan sistem hilir menegakkan batas operasi. Autentikasi menjawab siapa pengguna, klien, agen, atau beban kerja. Otorisasi menjawab operasi apa yang boleh dilakukan pada sumber daya mana. Persetujuan menjawab apakah satu tindakan yang telah disusun boleh dijalankan. Instruksi alami kepada model bukan pengganti pemeriksaan hak akses pada jalur eksekusi.

Pilih secara eksplisit apakah alat bertindak menggunakan kewenangan pengguna yang didelegasikan atau identitas beban kerja yang dikendalikan. Jangan diam-diam meminjam akun operator berhak luas. Sediakan operasi sempit dengan parameter tervalidasi, bukan akses umum ke kotak surat, basis data, peramban, atau shell. Batasi kata kerja, sumber daya, objek, kolom, tujuan, durasi kredensial, dan audiens token. Untuk MCP yang terlindungi, cakupan minimum dan token terikat sumber daya relevan, tetapi MCP bukan aturan universal bagi semua integrasi.

• Terapkan izin minimum pada identitas yang benar-benar mengeksekusi operasi.
• Periksa setiap permintaan di sistem hilir, bukan hanya ketika sesi percakapan dimulai.
• Validasi parameter dan tujuan sebelum alat menerima pekerjaan.
• Tetapkan batas laju, percobaan ulang, kedalaman rangkaian, jumlah objek, biaya, dan waktu menurut risiko layanan.
• Sediakan idempotensi, pemulihan, atau pemutus rangkaian bila sifat operasi membutuhkannya.

Percakapan boleh terasa menyatu, tetapi kewenangannya harus dipecah menjadi kapabilitas kecil yang ditegakkan secara mandiri.

Sejauh apa kapabilitas boleh bertindak?

Setiap kapabilitas memerlukan batas tindakan yang eksplisit, dengan kontrol independen yang makin kuat ketika operasi beralih dari memberi jawaban menjadi mengubah keadaan di luar percakapan. Tangga praktisnya adalah menjawab atau merangkum, merekomendasikan atau mengusulkan, membuat draf, melakukan penulisan terbatas yang dapat dipulihkan, memicu tindakan eksternal konsekuensial, dan menghadapi keputusan yang dilarang. Tangga ini adalah sintesis editorial, bukan tingkat dampak resmi dari NIST, NCSC, atau OWASP.

Pisahkan pembuatan draf dari pengiriman, perubahan rekaman yang dapat dikembalikan dari penghapusan, dan usulan dari keputusan yang memiliki penanggung jawab. Untuk tindakan konsekuensial, tampilkan pratinjau yang dapat diperiksa, lalu ikat persetujuan pada pelaku, alat, sasaran, parameter ternormalisasi, waktu, dan kedaluwarsa. Periksa kembali seluruh unsur sebelum eksekusi. Perubahan penerima, isi, atau sasaran setelah persetujuan harus menghasilkan pemeriksaan baru, bukan kelanjutan diam-diam.

1. Jawab atau rangkum dari informasi yang memenuhi syarat tanpa mengubah sistem lain.
2. Ajukan rekomendasi atau muatan tindakan yang dapat diperiksa, tanpa menjalankannya.
3. Buat artefak berstatus draf di ruang nonfinal dengan peninjau yang ditunjuk.
4. Ubah bidang atau buat rekaman yang disetujui melalui operasi sempit dan dapat dipulihkan.
5. Untuk mengirim, menerbitkan, menghapus, membayar, memberi akses, atau menerapkan perubahan, gunakan otorisasi yang sah, persetujuan terikat parameter, dan kebijakan eksekusi independen.
6. Hilangkan kapabilitas untuk keputusan terlarang dan arahkan kebutuhan itu ke manusia berkualifikasi atau proses lain yang ditata secara terpisah.

Persetujuan manusia tidak memberikan izin yang belum dimiliki pelaku, tidak memperluas hak tetap, dan tidak membuat keputusan terlarang menjadi boleh. Pembayaran, pemberian akses, penghapusan, perubahan produksi, komitmen eksternal material, serta keputusan profesional berisiko tinggi tetap memerlukan manusia berkualifikasi dan kebijakan deterministik yang sesuai dengan organisasi. Pengamanan tersebut harus berada pada jalur pelaksanaan sehingga penolakan model bukan satu-satunya penghalang.

Apa yang terjadi ketika asisten mencapai batas?

Penolakan, bantuan parsial yang aman, serah terima manusia, dan eskalasi keamanan harus menjadi keluaran layanan yang dirancang, lengkap dengan kondisi berhenti. Gunakan kategori alasan yang konsisten: tugas di luar cakupan, informasi tidak memenuhi syarat, otorisasi tidak cukup, persetujuan dibutuhkan, bukti hilang atau kedaluwarsa, keputusan spesialis diperlukan, dependensi tidak tersedia, batas operasi tercapai, atau sinyal keamanan terdeteksi. Sampaikan batas dengan bahasa lugas tanpa membocorkan rincian kebijakan sensitif.

Asisten tidak boleh berpura-pura bahwa pemeriksaan sumber, panggilan alat, persetujuan, atau penulisan berhasil. Ia dapat menawarkan bagian yang aman, misalnya draf tanpa dikirim, daftar pemeriksaan, atau permintaan informasi yang kurang. Paket serah terima sebaiknya memuat tujuan awal, konteks nonsensitif yang relevan, kapabilitas yang dicoba, alasan, bukti yang tersedia atau hilang, langkah berikutnya, dan pengenal jejak. Eksekusi tetap berhenti sampai pemilik yang tepat mengambil keputusan.

• Serah terima pengguna menangani kebutuhan rutin yang memerlukan bantuan manusia.
• Persetujuan bisnis meminta penanggung jawab menerima satu tindakan yang sudah dapat diperiksa.
• Eskalasi keamanan menangani sinyal seperti peningkatan hak, pengeluaran data, peracunan memori, atau pelewatan persetujuan.
• Ketiganya dapat memakai bukti yang sama, tetapi memiliki pemilik, urgensi, dan kewenangan berbeda.
• Jika muatan tindakan berubah selama menunggu, lakukan validasi dan persetujuan baru.

Bagaimana batas diubah menjadi rancangan operasional?

Tim dapat mengubah batas menjadi rancangan operasional dengan mengisi satu baris kanvas untuk setiap operasi yang terlihat oleh pengguna, lalu menghubungkan setiap baris ke kontrol yang dapat ditegakkan, catatan bukti, skenario uji, metrik operasi, dan pemilik. Jangan menulis “asisten dapat mengakses CRM” sebagai kapabilitas. Tulis operasi yang dapat diperiksa, seperti “merangkum kasus yang berhak dilihat petugas” atau “membuat draf balasan di ruang nonfinal”.

• Catat aktor yang memenuhi syarat, cara autentikasi, amplop informasi, serta aturan sesi dan memori.
• Tentukan operasi alat, identitas pelaksana, cakupan sumber daya, batas tindakan, persetujuan, dan kondisi berhenti.
• Nyatakan perilaku penolakan, bantuan parsial, serta tujuan serah terima atau insiden.
• Tentukan pengenal bukti yang harus dapat direkonstruksi tanpa menyimpan rahasia.
• Hubungkan skenario positif, batas, serangan, dan kegagalan dengan metrik serta pemilik yang dapat memperbaiki atau menghentikan kapabilitas.

Bayangkan asisten dukungan internal yang membantu petugas menemukan informasi kasus dan menyiapkan balasan pelanggan. Asisten tidak memutuskan kompensasi, mengubah hak pelanggan, atau membuat penetapan regulasi. Ringkasan kasus, draf balasan, dan pengiriman yang disetujui dapat tampil dalam percakapan yang sama, tetapi ketiganya tidak boleh berbagi kewenangan secara otomatis. Tabel berikut menunjukkan bagaimana satu permukaan percakapan dipecah menjadi tiga kontrak operasi.

Bukti apa yang dibutuhkan sebelum rilis dan selama operasi?

Rilis memerlukan bukti bahwa layanan yang diizinkan berhasil dan penolakan yang diharapkan juga bekerja dalam kondisi yang menyerupai penggunaan nyata. Uji tugas positif bersama akses lintas akun, alat tanpa izin, bukti kedaluwarsa, konten temu balik yang beracun, data terlarang, pelewatan persetujuan, perubahan parameter, percobaan ulang ganda, kegagalan dependensi, upaya pengeluaran data, dan rangkaian alat yang tidak terkendali. Hasil lulus hanya berlaku bagi versi dan cakupan yang diuji.

Log harus membantu penyelidik merekonstruksi siapa meminta apa, kapabilitas dan kebijakan mana yang berlaku, kelas sumber serta alat yang digunakan, keputusan otorisasi dan persetujuan, tindakan yang terjadi, serta versi yang aktif. Jangan merekam rahasia atau konteks sensitif tanpa batas. Pilih isi, akses, dan masa simpan log berdasarkan kebutuhan keamanan, privasi, dan pengelolaan arsip. Pantau penggunaan alat tak terduga, penolakan berulang, kegagalan izin, perubahan persetujuan, urutan tindakan anomali, latensi, sumber daya, dan kegagalan layanan.

Tetapkan pemilik perilaku layanan, hak akses, serah terima bisnis, dan insiden keamanan, masing-masing dengan kewenangan untuk menjeda, memperbaiki, atau menghentikan kapabilitasnya. Buka kembali pengujian dan bukti rilis yang terdampak setelah perubahan material pada model, perintah, temu balik, memori, alat, izin, kebijakan, data, penyedia, atau konteks operasi. Kedalaman penilaian ulang mengikuti luas perubahan dan risikonya, bukan sekadar label versi.

• Mulai dari kapabilitas terkecil yang tetap memberi manfaat nyata.
• Rilis hanya ketika keberhasilan, penolakan, penghentian, dan eskalasi dapat diamati.
• Tinjau hak akses, log, kegagalan, dan metrik pada tingkat kapabilitas.
• Perluas kewenangan melalui perubahan yang ditinjau, bukan hanya melalui penyuntingan perintah.
• Libatkan pemilik keamanan, identitas, privasi, arsip, risiko, dan layanan ketika kapabilitas menyentuh data sensitif, memori persisten, akses istimewa, tindakan destruktif, komitmen eksternal, atau insiden.

Tujuan akhirnya bukan membuat percakapan terasa terbatas, melainkan memastikan bahwa sistem benar-benar tidak dapat melampaui kontrak layanan tanpa keputusan dan kontrol yang semestinya. Ketika sebuah kebutuhan melibatkan keputusan hukum, regulasi, atau penilaian profesional berisiko tinggi, arahkan pekerjaan itu kepada spesialis berkualifikasi dan proses yang ditata secara terpisah. Asisten boleh menyiapkan informasi yang diizinkan, tetapi akuntabilitas keputusan tidak berpindah ke model.