Peneliti Desak Pengembang AI Perketat Sistem Keamanan

Apa yang terjadi dalam seruan keamanan AI ini?

Peneliti desak pengembang AI perketat sistem keamanan melalui penerapan perlindungan sebelum model diuji maupun digunakan. Lebih dari 400 peneliti dari berbagai negara menyerukan langkah tersebut lewat surat terbuka yang diberitakan detikInet pada 15 Oktober 2026, di tengah kekhawatiran terhadap serangan siber yang dikaitkan dengan rogue AI.

Tuntutan utamanya adalah penerapan high-assurance containment systems sebelum model AI diuji atau diberi akses ke lingkungan produksi. Menurut detikInet, sistem ini menempatkan agen AI dalam sandbox terisolasi dari infrastruktur eksternal. Tujuannya bukan menghentikan AI bekerja, melainkan membatasi ruang tindakan sistem agar tidak bebas mengakses jaringan, layanan, atau sistem pihak ketiga.

Dalam praktiknya, isolasi menjawab pertanyaan mendasar: tindakan apa yang benar-benar diperlukan model? Sistem untuk merangkum dokumen tidak memerlukan akses mengirim email, menjalankan kode, mengubah data pelanggan, atau memanggil API produksi. Akses tambahan berarti area risiko tambahan yang perlu diawasi.

Para peneliti juga mengusulkan badan pengawas independen berskala internasional. Menurut bsinews.id dan Demokratis.co.id, badan ini diharapkan mencatat kegagalan isolasi secara transparan serta menyusun standar perlindungan minimum bagi laboratorium riset dan perusahaan pengembang AI. Usulan tersebut masih berupa seruan, belum menjadi standar berlaku.

Mengapa sandbox saja belum cukup?

Sandbox memisahkan lingkungan pengujian dari sistem operasional. Pemisahan penting, tetapi bukan jaminan tunggal. Risiko tetap ada bila sistem memakai kredensial produksi, memiliki izin terlalu luas, atau mampu mengirim tindakan keluar tanpa pemeriksaan manusia.

Bayangkan tim menguji agent untuk membaca formulir pelanggan, mengklasifikasikan kebutuhan, memperbarui CRM, lalu menyiapkan draf email tindak lanjut. Pengujian lebih aman memakai formulir dummy, akun CRM khusus uji, alamat email internal. Agent boleh membuat draf, tetapi tidak boleh mengirimkannya kepada pelanggan. Tim kemudian meninjau log: data yang dibaca, perubahan yang dicoba, serta respons sistem saat mencoba mengakses akun produksi.

Pemisahan juga membantu menemukan kesalahan desain sebelum berdampak luas. Instruksi pengguna yang tidak terduga dapat membuat model mencoba tindakan di luar tujuan awal. Akses terbatas menghentikan tindakan itu di lingkungan uji. Koneksi langsung ke sistem operasional dapat membuat kesalahan menyentuh data atau proses bisnis nyata.

OpenAI, dalam artikel tentang Codex Security, menekankan bahwa pemeriksaan keamanan tidak cukup mengikuti aliran data. Tim perlu memvalidasi apakah pertahanan yang dirancang benar-benar bekerja dalam konteks sistem. Prinsip ini relevan untuk workflow AI: jangan hanya mendokumentasikan batas akses, tetapi uji apakah sistem menolak tindakan yang tidak diizinkan.

Risiko bertambah saat AI memakai alat dan akses

Risiko berubah ketika AI tidak lagi hanya menghasilkan jawaban di layar. Sistem terhubung ke CRM, basis data, email, layanan penyimpanan, API, atau alat pengembang dapat menjalankan tindakan di luar percakapan. Karena itu, chatbot, automation, dan AI agent perlu dibedakan.

Chatbot biasanya menjawab pertanyaan pengguna. Automation menjalankan rangkaian tindakan berdasarkan trigger dan aturan, misalnya formulir masuk lalu data dicatat ke CRM. AI automation menambahkan kemampuan AI untuk memahami atau mengklasifikasikan isi formulir sebelum workflow berjalan. AI agent dapat memakai konteks dan alat untuk menyelesaikan beberapa langkah menuju tujuan tertentu. Kapabilitas lebih luas memerlukan batas tindakan lebih tegas.

Contoh hipotetis: tim operasional membuat agent untuk menangani permintaan calon pelanggan. Sistem menerima formulir, membaca kebutuhan, mencari informasi pada knowledge base internal, memberi label prioritas, lalu menyiapkan draf tindak lanjut. Akses yang relevan: membaca formulir uji dan knowledge base terpilih. Akses yang harus ditahan: menghapus data CRM, mengubah harga, mengekspor seluruh daftar pelanggan, atau mengirim pesan massal tanpa persetujuan.

Istilah rogue AI perlu dibaca hati-hati. Istilah ini tidak membuktikan sistem memiliki kehendak sendiri. Dalam konteks laporan detikInet, istilah tersebut merujuk pada kekhawatiran agen AI melakukan tindakan merugikan di luar kendali pengembang, termasuk mengeksploitasi celah keamanan atau menyasar sistem pihak ketiga. Mitigasinya tetap konkret: isolasi, pembatasan akses, pencatatan, tinjauan manusia.

Cara menguji workflow AI sebelum masuk produksi

Keamanan perlu masuk sejak desain workflow, bukan setelah demo berhasil. Mulailah dari proses bisnis yang hendak dibantu. Pecah proses menjadi data masuk, keputusan, tindakan, serta pihak bertanggung jawab. Pemetaan ini membantu tim menentukan bagian yang aman diotomatisasi dan bagian yang harus menunggu persetujuan.

Gunakan urutan berikut pada workflow berisiko rendah:

1. Tentukan tujuan sempit. Misalnya, hanya mengklasifikasikan jenis pertanyaan pelanggan. Hindari tujuan kabur seperti “mengurus semua pertanyaan masuk”.
2. Pisahkan data dan akun uji. Jangan gunakan data pelanggan atau kredensial produksi sebelum perilaku sistem tervalidasi.
3. Buat daftar izin. Tuliskan sistem yang boleh dibaca, tindakan yang boleh dilakukan, serta tindakan yang selalu ditolak.
4. Atur persetujuan manusia. Pengiriman pesan eksternal, perubahan data penting, transaksi, atau tindakan berdampak tinggi perlu menunggu approval.
5. Simpan log tindakan. Catat input, alat yang dipanggil, hasil tindakan, kegagalan, serta pihak yang menyetujui tindakan tertentu.
6. Uji skenario gagal. Masukkan instruksi ambigu, data tidak lengkap, atau permintaan di luar tugas. Periksa apakah sistem berhenti, meminta klarifikasi, atau mencoba tindakan tidak semestinya.

Bayangkan workflow laporan internal. Data dari sumber uji dikumpulkan, AI menyusun draf ringkasan, lalu laporan ditempatkan di folder khusus review. Sistem tidak perlu memiliki izin mengubah sumber data, mengirim laporan ke pihak luar, atau mengundang pengguna baru ke folder. Reviewer manusia memeriksa isi sebelum laporan dibagikan. Struktur ini menjaga manfaat automasi sambil membatasi dampak ringkasan keliru atau instruksi yang dipahami salah.

Kontrol yang perlu ditetapkan sebelum akses diperluas

Setelah workflow berjalan dalam sandbox, langkah berikutnya bukan akses penuh. Tim perlu memperluas kewenangan secara bertahap. Prinsip akses minimum berarti sistem hanya menerima izin yang diperlukan untuk tugas saat itu, bukan izin luas untuk kebutuhan yang belum ada.

Tentukan pemilik proses. Tim teknis dapat mengelola integrasi, tetapi pemilik bisnis perlu menetapkan apakah hasil klasifikasi layak dipakai, tindakan mana yang dapat berjalan otomatis, serta kapan workflow harus dihentikan. Kepemilikan jelas mencegah kesalahan berpindah antar tim tanpa keputusan cepat.

Prosedur penghentian harus mudah dijalankan. Bayangkan ditemukan aktivitas tidak sesuai tujuan: akses API dicabut, workflow dinonaktifkan, atau akun integrasi diganti. Prosedur ini tidak menghapus risiko, tetapi membatasi dampak ketika pengujian menemukan masalah.

Untuk konteks penggunaan AI pada transaksi dan data pengguna, pembaca dapat melanjutkan ke pembahasan Memastikan Keamanan Pembayaran Digital di Era AI bagi Pengguna. Titik temunya sama: akses, verifikasi, tanggung jawab perlu jelas sejak awal.

Mulai dari satu audit workflow

Pilih satu workflow AI yang sedang diuji atau direncanakan. Buat dokumen satu halaman berisi tujuan workflow, jenis data, sistem terhubung, izin diberikan, tindakan yang memerlukan approval, serta cara menghentikannya. Jalankan pengujian dengan data dan akun terpisah terlebih dahulu.

Kemudian, minta orang yang tidak membuat workflow menguji skenario gagal: instruksi tidak jelas, permintaan akses di luar tugas, atau data sengaja tidak lengkap. Jika tim belum mampu menjelaskan tindakan yang boleh dilakukan sistem dan cara menghentikannya, akses ke lingkungan produksi belum perlu diperluas.