Bagian Pemasaran Diam-diam Menyambung Tiga Agen AI, dan IT Sama Sekali Tak Tahu: Shadow AI Menjelma Lubang Hitam Keamanan Siber

Seorang staf keamanan siber di sebuah perusahaan e-commerce menengah di Indonesia pernah menggambarkan satu situasi kepada saya. Saat memeriksa rutin catatan akses API, ia menemukan satu set kredensial terus membaca basis data pesanan pada pukul tiga dini hari, ratusan baris tiap kali, berlangsung lebih dari dua bulan.

Bukan peretasan. Itu satu agen AI yang disambung bagian pemasaran tiga bulan lalu, untuk otomatis menghasilkan ringkasan penjualan harian. Kredensialnya diberikan seorang engineer waktu itu dengan alasan "coba dulu saja untuk tes", dengan izin read-only ke seluruh tabel.

Tak ada yang jahat. Tak ada yang melanggar aturan perusahaan — sebab perusahaan memang tak punya aturan itu.

Latar Belakang Peristiwa

Istilah shadow IT sudah lama ada: karyawan memakai sendiri alat dengan melewati bagian IT, mengirim berkas lewat Dropbox pribadi, mengonversi PDF lewat alat daring gratis. Risikonya nyata, tetapi batasannya relatif jelas — alat-alat itu pasif, apa yang Anda masukkan itulah yang diproses.

Agen AI berbeda, dan perbedaan inilah kuncinya. Agen menjalankan aksi secara aktif: membaca sistem, memanggil API, menulis data, mengirim pesan. Ia bukan situs yang sesekali Anda unggahi berkas, melainkan sesuatu yang terus beroperasi, memegang kredensial, dan bertindak di dalam sistem Anda.

Dan ambang penerapannya rendah luar biasa. Platform low-code masa kini membuat seorang staf pemasaran bisa dalam satu sore menyambung agen yang membaca CRM, menulis laporan, dan mengirim pesan Slack. Ia tak perlu persetujuan IT, tak perlu proses pengadaan, bahkan mungkin tak merasa sedang "menerapkan sistem" — ia merasa hanya mengatur satu otomasi.

Masalah ini besar sampai ada startup yang khusus menggarapnya. Decawork dari batch Musim Panas 2026 Y Combinator menyebut dirinya "control plane agen untuk tim IT", mengunggulkan kemampuan bagian IT untuk men-deploy, mengelola, dan memelihara seluruh agen AI organisasi dalam satu antarmuka: perlu persetujuan sebelum live, izin kredensial diciutkan ke lingkup seminimal mungkin, dan semua aksi dipantau serta dicatat. Perusahaan ini didirikan Aman Raj dan Sarthak Aggarwal pada 2026 di San Francisco, dengan tim yang saat ini hanya dua orang — skalanya kecil, tetapi arahnya menunjukkan nyatanya masalah ini.

Poin Utama Kali Ini

• Perbedaan kunci shadow AI dan shadow IT: agen menjalankan aksi secara aktif, bukan memproses secara pasif apa yang Anda berikan.
• Ambang penerapannya sangat rendah, seorang nonteknis dalam satu sore bisa menyambung agen yang memegang kredensial.
• Risiko terbesar bukan kebocoran data, melainkan akses berkelanjutan dengan izin berlebihan tanpa pengawasan.
• Audit sulit: perilaku agen bersifat dinamis, dan model izin statis tradisional tak mudah mencakupnya.
• Masalah ini mulai diperhatikan regulator, dan persyaratan Undang-Undang AI Uni Eropa soal kemampuan audit akan mempercepat perusahaan menanganinya.

Analisis Dampak Pasar

Bagi Pengguna di Indonesia

Pertama, satu hal yang adil untuk dikatakan: karyawan yang menyambung sendiri agen AI biasanya justru kelompok paling proaktif di tim. Mereka tak sedang merusak aturan, melainkan menyelesaikan masalah mereka sendiri, dan sering kali cukup baik hasilnya.

Maka prinsip pertama menangani shadow AI: jangan menanganinya dengan cara melarang. Begitu Anda melarang, hal ini hanya berpindah ke bawah tanah — agen yang semula masih di bawah akun perusahaan akan dipindah ke akun pribadi, menjadi lebih sulit dilacak.

Cara pragmatisnya adalah menyediakan satu jalur yang sah. Katakan dengan jelas kepada rekan: Anda boleh memakai agen, tetapi harus terdaftar, harus melewati peninjauan yang disederhanakan, dan harus memakai kredensial yang dikeluarkan IT alih-alih meminta ke engineer. Turunkan gesekan seminimal mungkin, buat kepatuhan lebih mudah daripada pelanggaran; ini lebih efektif daripada dokumen kebijakan apa pun.

Bagi Penerapan Perusahaan

Dari sudut manajemen risiko perusahaan, bahaya shadow AI diremehkan secara sistematis, karena tiga alasan.

Pertama, izin lepas kendali. Kredensial biasanya diberikan sementara dengan pikiran "coba dulu saja", dan setelah tes selesai tak ada yang kembali mencabutnya. Dan agar bisa menangani beragam situasi, agen AI kerap diberi izin lebih besar daripada yang sebenarnya dibutuhkan — read-only seluruh tabel lebih praktis daripada memberi izin per tabel, maka diberilah read-only seluruh tabel.

Kedua, arah aliran data tak jelas. Agen itu di belakangnya menyambung model dari vendor mana? Apakah datanya keluar dari Indonesia? Apakah dipakai untuk pelatihan? Orang yang menerapkannya kebanyakan tak pernah menanyakan hal ini, sebab antarmukanya tak menampilkannya.

Ketiga, dan paling merepotkan: tak ada jejak audit. Ketika suatu hari perlu menjawab "apakah data pelanggan kami pernah diakses secara tak semestinya", jika agen itu disambung sendiri oleh bagian tertentu, Anda bahkan tak tahu harus mulai memeriksa dari mana.

Langkah pertama dalam praktik bukan membeli alat, melainkan inventarisasi. Dengan cara paling sederhana: periksa catatan penerbitan API key, periksa pola akses anomali basis data, periksa tagihan langganan SaaS tiap bagian, dan langsung tanyakan ke tiap kepala bagian "apakah kalian memakai alat yang bekerja otomatis". Daftar ini biasanya cukup mengejutkan.

Setelah inventarisasi barulah pemeringkatan: agen mana yang menyentuh data pribadi, mana yang bisa menulis dan bukan sekadar membaca, mana yang bisa mengirim pesan ke luar. Yang menyentuh data pribadi sekaligus bisa menulis sekaligus bisa mengirim ke luar adalah risiko tertinggi, tangani lebih dulu.

Bagi Pengembang

Bagi tim engineer, pelajaran paling nyata dari hal ini: penerbitan kredensial harus punya siklus hidup.

"Coba dulu saja untuk tes" adalah titik awal semua masalah. Cara yang masuk akal: setiap kredensial sementara wajib punya tanggal kedaluwarsa, otomatis tak berlaku saat waktunya tiba, dan bila perlu diperpanjang harus mengajukan ulang. Secara teknis ini tak sulit, yang sulit adalah kebiasaannya.

Hal lain yang perlu dibangun adalah default izin minimal. Agen perlu membaca data pesanan, beri ia izin read-only atas data pesanan, bukan seluruh basis data. Ini terdengar dasar dalam keamanan siber, tetapi paling sering dilewati di bawah tekanan "cepat buat ia jalan".

Saya juga menyarankan memperlakukan log perilaku agen sebagai warga kelas satu dalam desain. Apa yang dilakukan agen, apa yang diaksesnya, apa yang dikeluarkannya — jika tak disimpan sejak tahap desain, mustahil ditambal setelahnya. Persyaratan Undang-Undang AI Uni Eropa soal kemampuan audit sedang mendorong hal ini dari praktik terbaik menjadi syarat wajib.

Tren Perkembangan Masa Depan

Pertama, tata kelola agen akan menjadi bidang perluasan IAM (Identity and Access Management). Alat manajemen izin yang ada dirancang untuk manusia dan aplikasi, sedangkan pola perilaku agen berada di antara keduanya — ia beroperasi terus-menerus seperti aplikasi, tetapi membuat penilaian tak terduga seperti manusia. Celah ini akan diisi, mungkin lewat akuisisi startup oleh pemain besar keamanan siber yang sudah ada.

Kedua, "identitas agen" akan menjadi konsep yang jelas. Sebagaimana dahulu service account terpisah dari akun manusia, agen membutuhkan jenis identitasnya sendiri, model izinnya sendiri, dan manajemen siklus hidupnya sendiri.

Ketiga, regulasi akan mempercepat hal ini. Ketika perusahaan wajib membuktikan kepada regulator apa yang dilakukan sistem AI-nya, agen yang keberadaannya tak diketahui siapa pun akan menjadi risiko yang tak tertanggungkan. Tekanan kepatuhan sering kali lebih mampu mendorong anggaran daripada peringatan keamanan siber.

Kesimpulan dan Ulasan TheAI Academy

Saya ingin lebih dulu mengatakan satu hal yang mungkin kurang populer: tanggung jawab atas hal ini tak ada pada karyawan yang menyambung sendiri agen.

Ketika perusahaan tak menyediakan jalur yang sah, tak menjelaskan aturan, dan tak ada yang memberi tahu bahwa "memberi satu set kredensial read-only seluruh tabel ke layanan eksternal" itu bermasalah, karyawan menyelesaikan masalah dengan caranya sendiri adalah perilaku yang sepenuhnya masuk akal. Tanggung jawab ada pada organisasi yang tak mengikuti laju perubahan alat.

Penilaian saya atas masalah ini: ia belum meledak sekarang, tetapi sedang menumpuk. Shadow AI di mayoritas perusahaan masih pada tahap yang relatif tak berbahaya seperti "membantu membuat laporan", tetapi kemampuan agen makin kuat tiap bulan, dan satu set kredensial yang sama tahun depan mungkin tak sekadar membaca data lagi.

Waktu untuk menanganinya adalah sekarang, selagi daftarnya masih bisa diinventarisasi sampai tuntas.

Ulasan: shadow AI bukan masalah disiplin karyawan, melainkan celah tata kelola organisasi. Melarang tak berguna, satu-satunya cara efektif adalah membangun jalur patuh yang lebih mudah dilalui daripada jalur melanggar.

Saran konkret bagi pembaca di Indonesia: jika Anda menangani IT atau keamanan siber perusahaan, bulan ini lakukan tiga hal. Pertama, inventarisasi — periksa catatan penerbitan API key, pola akses anomali basis data, dan tagihan SaaS tiap bagian, buat satu daftar agen. Kedua, ciutkan kredensial — semua kredensial sementara diberi tanggal kedaluwarsa, semua izin agen diciutkan ke lingkup minimal yang perlu. Ketiga, buka satu jalur sah — rancang formulir pendaftaran yang bisa diisi dalam lima menit, agar rekan bersedia melapor secara proaktif. Adapun alat tata kelola, produk seperti Decawork arahnya benar tetapi timnya hanya dua orang dan baru berdiri tahun ini; pada tahap ini disarankan memahami dulu masalahnya dan mengamatinya dalam lingkup kecil, jangan buru-buru menyerahkan kunci perusahaan. Untuk memahami lebih banyak alat terkait, lihat kategori Framework Pengembangan dan Infrastruktur AI di situs, atau lihat Panduan Tugas AI.

Sumber Data

• Decawork (halaman perusahaan Y Combinator)
• Komisi Eropa: Kerangka Penegakan Undang-Undang AI

(Artikel ini disusun berdasarkan informasi publik; situasi kasus adalah tulisan ulang setelah memadukan berbagai wawancara, tidak merujuk pada perusahaan tertentu.)