Tata kelola AI di era Vibe Coding: ketika Shadow IT menjadi Shadow AI

Pada Mei 2026, perusahaan keamanan siber Israel, RedAccess, memindai dan menemukan 380.000 aplikasi hasil vibe coding yang terbuka untuk publik di internet, dan sekitar 5.000 di antaranya menyimpan rahasia perusahaan yang nyata: data arus kas sebuah bank di Brasil, rekam medis pasien dari sebuah uji klinis di Inggris, percakapan dokter-pasien dan jadwal shift staf sebuah rumah sakit, serta rekaman kelas dan data pribadi siswa sebuah sekolah. Aplikasi-aplikasi ini berjalan di platform seperti Lovable, Replit, Base44, dan Netlify. Menurut laporan Axios, sebagian besar bukan diretas, melainkan karena platform secara default bersifat publik, tidak ada yang menutupnya menjadi privat secara manual, sehingga mesin pencari langsung mengindeksnya.

Orang-orang yang membangun aplikasi-aplikasi ini sebagian besar tidak tahu bahwa mereka telah membocorkan sesuatu — inilah wujud Shadow IT di era AI. Simpan dulu istilah ini, nanti kita jelaskan.

---

Mari perbesar gambarnya, dan lihat satu versi yang lebih sehari-hari.

Senin pagi, pukul 10.00. Budi, Direktur IT, mengangkat telepon.

Halaman kampanye keanggotaan perusahaan sedang down; pelanggan sudah membayar tetapi tidak menerima email konfirmasi. Budi membuka dashboard untuk menelusuri log, tetapi service-nya tidak ada di sana. Setelah bertanya ke sana ke mari, dia akhirnya tahu: ini dibangun tim marketing minggu lalu dengan Cursor, dan berjalan di akun cloud pribadi seseorang.

Sejak momen itu, pekerjaan Budi mulai berubah.

Ini bukan kejadian satu kali. Shadow IT (karyawan yang melewati proses IT resmi untuk mengadopsi alat sendiri atau membangun sistem sendiri) selalu ada, tetapi ketika tools AI membuat tim marketing, sales, dan HR semuanya bisa menulis sendiri sebuah aplikasi produksi, skalanya melonjak dari "karyawan diam-diam memasang SaaS" menjadi "karyawan diam-diam menjalankan satu set backend", dan kotak peralatan tata kelola IT tradisional tidak sanggup menangani skala sebesar ini. Tulisan ini membahas persoalan baru itu: ketika Shadow IT menjelma menjadi Shadow AI, bagaimana perimeter keamanan perusahaan ikut bergeser, dan bagaimana Direktur IT di lini terdepan (di UKM atau industri tradisional sering juga disebut MIS atau Kepala Bagian TI, dan tergantung skala perusahaan disebut juga CIO) sebaiknya merespons.

Mari perjelas dulu cakupannya: tata kelola AI itu luas, risiko model, kebijakan penggunaan AI, human-in-the-loop, dan akuntabilitas semuanya ada di dalamnya. Tulisan ini berfokus pada satu irisan, yang paling cepat mengemuka: bagaimana perimeter keamanan perusahaan bergerak begitu vibe coding mengubah Shadow IT menjadi Shadow AI. Pembahasannya berjalan dari fenomena dan penyebabnya hingga sebuah kerangka tata kelola yang benar-benar bisa Anda ikuti. Irisan-irisan lainnya untuk tulisan tersendiri.

TL;DR

• Kerangka kerja: tiga lapisan tata kelola AI, visibilitas → batasan → audit; urutannya penting, melompati lapisan akan membuat Anda terjatuh.
• Tesis: sandbox menjadi perimeter keamanan perusahaan yang baru; jangan melarang vibe coding, bawa ke tempat yang bisa dilihat IT.
• Tiga langkah: inventarisasi apa yang sedang berjalan → buka satu workspace yang disetujui → bangun kadens audit.

Shadow AI di era Vibe Coding: mengapa sepuluh kali lebih parah dari Shadow IT lama

"Shadow IT" adalah istilah lama dalam tata kelola IT, merujuk pada tools atau layanan yang diadopsi sendiri oleh karyawan atau departemen dengan melewati prosedur IT resmi. Gartner pada dekade 2010-an menjadikan fenomena ini sebagai istilah baku. Bagi IT ini adalah titik buta tata kelola, sementara bagi karyawan ini sering kali pilihan yang masuk akal "demi menyelesaikan pekerjaan", masing-masing pihak punya alasannya; namun jika menumpuk dalam jangka panjang, data, proses, dan izin perusahaan akan tersebar di tempat-tempat yang tidak bisa dilihat IT.

Sepuluh tahun lalu, shadow IT berarti karyawan diam-diam memakai Notion atau membayar Slack sendiri. Pekerjaan Direktur IT adalah meninjau pengajuan procurement SaaS, menulis acceptable use policy, dan menjalankan inventarisasi berkala. Titik sakitnya adalah "data tersebar di tempat yang salah", tetapi tempat-tempat itu setidaknya adalah SaaS terkenal: di belakangnya ada laporan SOC 2, ada SLA, ada saluran support.

Shadow AI adalah versi shadow IT di era AI, dan masalah dasarnya persis sama: karyawan menaruh data sensitif pada layanan pihak ketiga yang tidak ditinjau IT. Yang benar-benar berubah adalah sifat "pihak ketiga" itu: dulu SaaS jadi, sekarang platform vibe coding, atau backend dan database yang dibangun karyawan sendiri. Kontainernya berganti dari "layanan terkenal yang teraudit" menjadi "sistem buatan sendiri yang tak ada yang mengelola", sehingga risikonya tentu beda kelas. Mari bentangkan perbandingannya:

Perbedaan paling krusial adalah "kontrolabilitas". Dulu, ketika data tak sengaja ditaruh di Notion, izin lupa ditutup, dan orang luar mengklik masuk ke halaman itu, cukup tutup izinnya, hapus halamannya, risikonya kurang-lebih sudah terhenti. Tetapi Shadow AI berarti menyambungkan data sensitif ke sebuah sistem yang hidup: satu endpoint yang terekspos ke luar, dan penyerang bisa menelusuri benang merahnya, menarik keluar database, API, dan data internal lain yang terangkai di belakangnya, dan menghapus satu halaman tidak bisa membatalkannya. 5.000 aplikasi bocor di awal tadi persis seperti itu: default publik, lalu diindeks habis oleh mesin pencari.

Fenomena ini lebih lazim dari yang Anda bayangkan; mari tumpuk beberapa angka untuk melihatnya:

• Lebih dari 40% perusahaan akan mengalami insiden keamanan/kepatuhan terkait shadow AI sebelum 2030 (prediksi Gartner).
• 71% karyawan pernah menggunakan tools AI yang tidak disetujui, dan 51% menggunakannya setiap minggu (survei Microsoft UK Oktober 2025).
• Hanya separuh karyawan lini depan yang benar-benar rutin menggunakan AI. Bisa mengakses GenAI adalah satu hal (di industri yang matang 70% karyawan punya akses, di industri yang belum matang kurang dari separuh), dan benar-benar menggunakannya setelah punya akses adalah hal lain. Laporan BCG September 2025 The Widening AI Value Gap (1.250 responden) menyebut jurang antara "bisa mengakses vs benar-benar menggunakan" ini sebagai "silicon ceiling" (langit-langit silikon).

Sekalipun hanya separuh yang rutin memakai AI, separuh itulah yang sudah menumpuk shadow AI yang tidak terlihat IT.

Vibe coding mengubah permainan ini: hal yang dilakukan karyawan naik satu tingkat, dari "memasang SaaS" menjadi "menjalankan sendiri satu set backend + database + API". Tools AI (Claude Code, Cursor, GitHub Copilot) membuat "kemampuan menulis kode" menyebar dari engineer ke semua orang, tetapi "tanggung jawab menjalankan produksi" tidak ikut menyebar. Bisa menuliskannya bukan berarti tahu bahwa:

• secret tidak boleh ditulis ke dalam repo.
• backup tidak akan berjalan otomatis.
• ketika traffic melonjak 10 kali lipat masuk, ada hal yang perlu dilakukan lebih dulu.

Akibatnya, perusahaan tanpa sadar menumpuk sepuluh hingga tiga puluh service produksi yang tidak punya catatan tata kelola apa pun. Mereka mengumpulkan data pelanggan, mengirim email, menyambung ke ERP internal — sementara Direktur IT bahkan tidak bisa menyebut namanya. Tarik-menarik antara demokratisasi tools dan keamanan siber ini adalah ketegangan mendasar yang tak terhindarkan dalam tata kelola vibe coding.

Mengapa perimeter keamanan lama tak sanggup menahan keluaran vibe coding

Shadow AI bisa membengkak sebesar ini karena ada tiga kekuatan yang terjadi bersamaan, dan masing-masing membuat garis pertahanan IT tradisional (firewall, IDP) tak sanggup menahan keluaran karyawan.

Ambang deployment turun ke nol, visibilitas hilang sepenuhnya

Lovable, Bolt, v0, Replit Agent, Claude Code semuanya menjadikan "selesai menulis langsung berjalan di sandbox platform" sebagai aksi default: tidak menulis Dockerfile, tidak mengonfigurasi server, tidak mengajukan akun. Bagi karyawan ini kabar baik luar biasa, bagi Direktur IT ini kehilangan visibilitas total: dia tidak tahu berapa banyak aplikasi produksi yang tidak lewat prosedur sedang berjalan, di akun pribadi siapa ia berjalan, dan kartu kredit siapa yang membayarnya.

AI butuh data perusahaan nyata agar bisa benar-benar berguna

Agar output vibe coding berubah dari demo menjadi benar-benar berguna, AI butuh disuapi konteks nyata: daftar pelanggan, riwayat pesanan, solusi atas masalah sebelumnya, wiki internal. Semakin banyak konteks yang diberikan, output AI semakin sesuai skenario. Tetapi memberi data berarti harus menghadapi tanggung jawab redaksi / privasi / kepatuhan; tidak memberi, karyawan ibarat tukang masak handal tanpa bahan, dan outputnya berhenti di versi mainan yang "kelihatannya berjalan tetapi tidak cocok dengan skenario".

Agent dan sistem yang dijalankan sendiri oleh karyawan melewati perimeter identitas lama

Computer Use dari Anthropic (Oktober 2024), Operator dari OpenAI, Devin, dan lainnya membuat agent menggerakkan keyboard dan mouse sendiri untuk menulis kode dan men-deploy; aplikasi AI buatan karyawan pun sering kali menjalankan sendiri sebuah sistem tanpa melewati IDP (identity provider). Di era SaaS, IDP mengelola "siapa yang bisa login ke sistem mana". Sekarang ia dilewati sekaligus oleh actor baru (agent) dan surface baru (aplikasi produksi yang dibuka sendiri oleh karyawan).

Laporan State of AI in the Enterprise 2026 dari Deloitte menunjukkan hanya 1 dari 5 (20%) perusahaan yang punya model tata kelola matang untuk agent AI otonom, dan langsung menunjukkan arahnya: "Effective governance integrates with existing risk and oversight structures, not parallel 'shadow' functions". Artinya tata kelola harus terintegrasi ke struktur risiko yang sudah ada, bukan membuka fungsi shadow paralel yang baru.

Ketiga kekuatan ini mengubah definisi "perimeter keamanan perusahaan". Di mana perimeter baru itu seharusnya jatuh, dan mengapa jawabannya akan mengarah ke "sandbox", akan dibentangkan secara khusus nanti (istilah ini pun simpan dulu).

Tiga sinyal Shadow AI lepas kendali: krisis visibilitas, batasan, dan audit

Ketika Direktur IT mulai mengucapkan salah satu dari tiga kalimat berikut, masalah shadow IT sudah mencapai titik waktu yang menuntut tindakan:

Sinyal 1: krisis visibilitas

"Saya tidak tahu berapa banyak aplikasi yang sedang berjalan di perusahaan ini sekarang."

Aplikasi AI buatan karyawan tersebar di berbagai akun, kartu pembayaran, dan penyedia PaaS yang berbeda; IT tidak punya daftarnya, dan setiap kali ada masalah orang pertama yang dipanggil adalah dia, tetapi dia bahkan tidak tahu nama benda itu.

Sinyal 2: krisis batasan

"Dia mengundurkan diri minggu depan, tetapi saya tidak tahu data perusahaan apa saja yang dipakai oleh benda yang dia bangun."

Karyawan memperlihatkan connection string database pelanggan kepada AI, menuliskannya ke dalam kode, dan menjalankannya di akun pribadinya. Ketika orang ini pergi, perusahaan tidak punya mekanisme untuk mengambil alih sistem ini, dan juga tidak punya cara untuk mencabut aksesnya.

Sinyal 3: krisis audit

"Akhir tahun harus lolos audit, tetapi benda-benda ini di luar kendali saya."

Pelanggan meminta SOC 2, tender pemerintah meminta ISO, industri menuntut lolos pemeriksaan keamanan informasi. Auditor akan bertanya "access log? backup? catatan perubahan? siapa yang bisa mengubah, siapa yang bisa melihat?" Direktur IT tidak punya jawaban.

Dilema tata kelola AI perusahaan: Direktur IT terjepit antara adopsi dan kontrol risiko

Mari lihat dulu satu angka acuan: survei global The State of AI 2025 dari McKinsey (mencakup 105 negara, 1.993 responden) menemukan 88% organisasi sudah menggunakan AI secara rutin di minimal satu fungsi bisnis, tetapi hanya 18% yang telah membangun dewan tata kelola AI tingkat enterprise. Dengan kata lain, di lebih dari delapan dari sepuluh perusahaan, karyawan sudah menggunakan AI sementara struktur tata kelolanya belum tumbuh. Dilema Direktur IT tumbuh dari celah itu.

Untuk memahami kesulitan Direktur IT, mari lihat dulu tekanan dari dua lapisan di atasnya.

Pandangan dari ruang direksi: kecemasan tentang adopsi AI

Sepanjang 2025-2026, hampir setiap pemilik perusahaan cemas soal AI: sesama industri melakukannya, pesaing melakukannya, media memberitakannya, karyawan bertanya. Respons instingtifnya adalah menuntut secara top-down: "Tahun depan kita AI-first", "Setiap departemen menyerahkan satu aplikasi AI", "Departemen yang tidak bisa pakai AI akan dievaluasi ulang". Tujuannya adalah membuat perusahaan terlihat bergerak, agar tidak tersapu. Tetapi antara dorongan top-down dan adopsi yang sesungguhnya ada satu jurang.

Duolingo adalah kasus representatif ketika jurang itu menjadi publik: pada 28 April 2025, CEO Luis von Ahn mengumumkan strategi "AI-first" di LinkedIn: secara bertahap menghentikan kontraktor yang bisa digantikan AI, memasukkan "bisa pakai AI" ke dalam syarat rekrutmen dan penilaian kinerja; TechCrunch melaporkan dua hari setelah pengumuman itu perusahaan merilis 148 kursus hasil AI, volume pengembangan kurikulum selama 12 tahun dipampatkan menjadi kurang dari satu tahun. Reaksi balik komunitas meledak dengan cepat: pengguna membatalkan langganan, menghapus aplikasi, dan menyerbu kolom review TikTok dengan ulasan negatif; Duolingo menghapus seluruh post TikTok / Instagram dan menghilang selama beberapa waktu. Sekitar empat minggu kemudian, von Ahn secara terbuka menarik kembali pernyataannya di LinkedIn, dan Fortune mengutip ucapan aslinya: "I do not see AI as replacing what our employees do", serta menyatakan rekrutmen tetap pada kecepatan semula; pada earnings call Q2 2025 dia juga mengakui bahwa komentar AI itu membuat pertumbuhan DAU jatuh ke titik rendah yang diperkirakan (40% YoY, dibanding 60% pada periode yang sama tahun sebelumnya).

Pola ini berulang di banyak perusahaan ketika mendorong AI secara top-down. Fortune melaporkan Klarna mengganti 700 agen layanan pelanggan dengan AI, lalu setengah tahun kemudian merekrut kembali manusia, naskah yang sama.

Deskripsi yang paling sering saya pakai adalah:

Bisa terpakai bukan berarti teradopsi, dan berhasil diadopsi bukan berarti benar-benar terpakai. — Ling Wu

Karyawan membuka Cursor setiap hari (bahkan memakainya untuk bertanya mau makan siang apa) bukan berarti perusahaan benar-benar sudah membawa AI masuk ke alur kerja; meskipun benar-benar memakainya untuk membangun beberapa sistem kecil, kebanyakan perusahaan pun belum punya alat ukur untuk menilai "apakah AI sungguh meningkatkan produktivitas". Dua jurang di tengah (treatment vs deployment, dan deployment vs utilization) keduanya bisa membuat macet.

Pandangan Direktur IT: dilema antara kontrol risiko dan fleksibilitas

Dalam struktur sandwich ini, Direktur IT harus sekaligus merespons tuntutan bos "kita harus AI-first" (mendorong adopsi), dan mengelola risiko tata kelola dari penyebaran vibe coding (menjaga stabilitas). Ini adalah pekerjaan melakukan enable + control secara bersamaan: salah satu sisi terlalu berat dan semuanya terbalik.

Dua reaksi ekstrem yang bersesuaian, keduanya adalah versi yang tidak sanggup menjepit kedua sisi:

Reaksi 1: larang

"Mulai sekarang karyawan tidak boleh menggunakan AI untuk menulis aplikasi sendiri, semuanya harus lewat prosedur pengajuan IT." Akibatnya adalah memaksa semua orang memakai tools yang justru mengikat tangan sendiri: set yang disetujui IT sering kali tertinggal satu tingkat dari kemampuan yang dipakai builder di luar sana, tidak bisa mengerjakan hal yang benar-benar ingin dilakukan karyawan; karyawan tidak akan berhenti hanya karena IT menolak (bos baru saja bilang "semua orang pakai AI untuk meningkatkan efisiensi"), sehingga mereka terus membangun, dan memindahkannya ke tempat yang lebih tersembunyi. Larangan memperbesar krisis visibilitas menjadi krisis bawah tanah, dan membuat Direktur IT tampak seperti "penghambat yang membuat AI tidak bisa bergerak" di mata bos.

Reaksi 2: abaikan

"Toh auditnya belum datang, urus nanti saja." Dibiarkan sejenak, tetapi semakin dibiarkan masalahnya akan tumbuh sendiri: rekan yang tidak menguasai framework frontend dan pilihan database masing-masing memilih tools sendiri, tiga orang bisa saja memakai tiga framework dan empat database yang berbeda; sepuluh sistem tumbuh bersamaan, dan perusahaan kini memegang setumpuk permutasi tech stack yang menunggu ada yang membereskan. Ketika auditor benar-benar datang, yang harus ditanggung Direktur IT bukan hanya mimpi buruk audit, tetapi juga permutasi tech stack hasil pembiaran itu meledak bersamaan.

Titik sakit dari sandwich ini, kalau diucapkan terus terang, adalah: bos hanya melihat apakah adopsi bergerak, karyawan hanya peduli apakah yang mereka tulis bisa berjalan, sementara risiko (kebocoran data, celah kepatuhan, kegagalan audit) dan "utang" pengelolaan (siapa yang memperbaiki, siapa yang mem-backup, siapa yang mengganti tools) semuanya ditimpakan ke satu orang Direktur IT — tidak ada yang peduli apa yang dia tanggung.

Arah yang benar adalah jalan ketiga: bawa output AI ke dalam lingkungan yang bisa dilihat IT, tetapi tidak menghalangi karyawan untuk terus membangun. Dengan kata lain: sandbox menjadi perimeter keamanan perusahaan yang baru (di komunitas berbahasa Inggris ada ungkapannya: "sandbox is the new perimeter").

Dalam sudut pandang ini, Direktur IT sekaligus melakukan enable (karyawan terus pakai AI) + control (IT bisa melihat / mengelola), merespons dorongan top-down bos, menyelesaikan risiko tata kelola, sekaligus alur kerja harian karyawan tidak terganggu. Apa sebenarnya sandbox itu, dan mengapa baru dalam satu-dua tahun terakhir ia menjadi jawaban default bagi perimeter keamanan perusahaan, akan dibahas di bagian tersendiri nanti.

Kerangka tata kelola Vibe Coding: tiga lapisan visibilitas, batasan, audit

Untuk menangani tata kelola vibe coding sebagai isu serius tingkat enterprise, industri sudah punya beberapa standard yang menangani isu ini:

• Undang-Undang Pelindungan Data Pribadi (UU No. 27 Tahun 2022): disahkan Oktober 2022 dengan masa transisi penuh hingga Oktober 2024. UU PDP mengikat semua pengendali dan pemroses data pribadi, termasuk ketika data tersebut diproses oleh sistem AI. Setiap aplikasi shadow AI yang menyentuh data pelanggan berada dalam yurisdiksi UU ini, terlepas dari apakah IT mengetahuinya atau tidak.
• Surat Edaran Menteri Komunikasi dan Informatika No. 9 Tahun 2023 tentang Etika Kecerdasan Artifisial: diterbitkan Desember 2023. Sifatnya tidak mengikat, tetapi memberi sinyal arah pemerintah: inklusivitas, transparansi, kemanusiaan, dan keamanan dalam pengelolaan sumber daya data.
• ISO/IEC 42001:2023: standar manajemen sistem AI internasional pertama, selaras dengan framework ISMS yang sudah ada seperti ISO 9001 / ISO 27001.
• Untuk sektor keuangan, POJK No. 11/POJK.03/2022 memberi kerangka spesifik untuk penyelenggaraan teknologi informasi oleh bank umum: tata kelola TI, manajemen risiko, pelaporan ke OJK, dan penilaian kematangan digital tahunan.

Bagaimana standard-standard ini saling selaras, dari mana SMB sebaiknya mulai menerapkannya, dan apa saja trade-off implementasinya (bagaimana menyesuaikan istilah tata kelola AI seperti quality gate, operational debt, technical debt, dan paved path ke dalam proses perusahaan sendiri) akan dikupas tuntas di tulisan lain.

Tulisan ini meringkas standard-standard di atas menjadi kerangka tiga lapisan yang bisa cepat mengenali masalah skenario vibe coding: visibilitas, batasan, audit. Urutannya penting, setiap lapisan menyelesaikan masalah yang berbeda:

Lapisan 1: Visibilitas

Pekerjaan paling mendasar adalah membawa semua aplikasi AI ke satu tempat untuk dilihat. Satu titik penagihan, satu dashboard untuk melihat seluruh deployment, satu audit log untuk mengetahui siapa mengubah apa.

Hal konkret yang perlu dilakukan adalah: berikan karyawan environment yang boleh mereka pakai (workspace yang dibayar perusahaan, akun yang dikelola perusahaan), dorong agar aplikasi AI mereka di-deploy ke sini, karyawan terus melakukan vibe coding dan IT bisa melihatnya. Tanpa visibilitas, dua lapisan berikutnya tidak bisa dikerjakan.

Pola "buat data terlihat dan definisinya rapi dulu, baru aplikasi AI bisa menyambung" ini tidak asing bagi tim engineering tingkat platform di Indonesia. Blog teknologi Gojek dan blog engineering Tokopedia selama beberapa tahun terakhir mendokumentasikan investasi serupa dalam tata kelola data terpusat dan internal developer platform: buat data terlihat dan definisinya rapi dulu, baru model AI bisa tumbuh di atasnya. Lapisan 1 tata kelola vibe coding mengikuti logika yang sama, ada lingkungan yang terlihat dulu, baru enable yang berikutnya jadi bermakna.

Jika diterjemahkan ke layar nyata, kira-kira seperti ini: Budi membuka IT workspace perusahaan, sekilas melihat dua belas service berjejer: marketing-membership-page (dibuat marketing, env var-nya diubah oleh Andi minggu lalu), hr-interview-scheduler (dibuat HR, berjalan di region Asia, memakai 2,3 GB bulan ini), sales-customer-cleanup (dibuat sales, sudah dua minggu tidak di-deploy)… masing-masing punya owner, last deploy, region, dan cost. Budi tidak perlu bertanya kepada siapa pun, dashboard langsung menjawab "apa yang sedang berjalan sekarang".

Lapisan 2: Batasan

Visibilitas menyelesaikan "tidak tahu apa yang sedang berjalan", batasan menyelesaikan "tidak tahu apa yang dipakai".

Hal konkret yang perlu dilakukan ada tiga:

• Isolasi environment: izin di environment dev / staging / production masing-masing independen, sehingga eksperimen tidak akan tidak sengaja menyentuh data production.
• Secret manager bersama: kredensial disimpan di satu tempat yang dikelola, AI bisa melihat reference-nya tetapi tidak bisa menyentuh plaintext-nya.
• Otomasi pencabutan kursi: ketika karyawan pergi, semua jalur akses dicabut dengan satu klik, tanpa perlu main pukul tikus di lima dashboard PaaS.

Aplikasi AI karyawan boleh menyambung ke data internal, tetapi kredensial tidak akan terbaca oleh AI ke dalam prompt, dan ketika karyawan pergi akses otomatis terputus.

Jika diterjemahkan ke layar nyata: Andi yang mengundurkan diri minggu lalu pernah membuat customer-feedback-collector, berjalan di akun GitHub OAuth pribadinya. Budi menekan sekali "hapus collaborator" di workspace: prod env service ini otomatis beralih ke status "belum diklaim", semua jalur akses dicabut, penagihan beralih ke akun utama perusahaan, dan HR tidak perlu mengejar Andi untuk apa pun.

Lapisan 3: Audit

Audit log mengetahui siapa men-deploy apa, siapa mengubah env var, siapa melihat log; kepemilikan resource membuat "service ini milik siapa" punya jawaban; riwayat deployment membuat catatan perubahan tidak perlu disimpan sendiri oleh karyawan.

Lapisan ini hanya menyelesaikan sisi tata kelola, bukan sertifikasi kepatuhan itu sendiri. Ketika pelanggan harus lolos SOC 2 / ISO 27001 / UU PDP / POJK, perlu memetakan tools bawaan plan ke kerangka audit. Ini biasanya membutuhkan konsultan atau peninjauan tata kelola, bukan urusan yang harus ditanggung PaaS.

Bagi institusi keuangan Indonesia, daftar pertanyaan audit itu lebih panjang lagi. POJK No. 11/POJK.03/2022 dari Otoritas Jasa Keuangan (OJK), yang ditetapkan Juli 2022, mewajibkan bank umum memiliki tata kelola TI yang jelas, manajemen risiko, rencana pemulihan bencana, serta penilaian tingkat kematangan digital tahunan yang dilaporkan ke OJK. Sebuah halaman kampanye yang dibangun marketing di akun pribadi tidak akan muncul dalam laporan kematangan digital tersebut, sampai hari ia bocor. Bagi Direktur IT industri bank / asuransi, ini adalah kerangka audit yang langsung ditulis untuk Anda; bagi industri lain pun ia jadi referensi awal. "Siapa membuat keputusan apa di tahap mana" yang diminta audit hanya separuh dijawab oleh audit log PaaS, separuh lainnya harus diturunkan ke dalam organisasi lewat proses.

Mari ambil satu skenario konkret: seorang karyawan memakai workflow yang dia bangun sendiri (tool kecil hasil Claude Code + n8n yang menyambung ke API wiki internal) untuk otomatis menghasilkan konten balasan yang menghadap pelanggan; agar AI menjawab lebih akurat, dia menjejalkan data wiki internal perusahaan ke dalam prompt. Tetapi data di wiki internal belum sepenuhnya diredaksi: daftar personalia, nilai kerja sama, dan catatan keluhan pelanggan sebelumnya semua ada di dalamnya. AI tidak akan secara aktif membedakan mana yang boleh publik dan mana yang tidak, sehingga sebagian data privat ikut terbawa keluar secara publik di dalam "balasan yang dilihat pelanggan".

Soal akuntabilitas / gugatan dalam skenario ini kita kesampingkan dulu. Pada akarnya, inti dari lapisan audit terletak pada desain proses: apakah ada checkpoint yang dipasang pada titik di mana AI menyentuh data sensitif. Bisa mengeluarkan log saat auditor datang itu hanya standar dasar; desain proses-lah yang sebenarnya sedang dijaga. Di era AI, tidak ada yang tahu kapan insiden tata kelola publik berikutnya akan muncul; menerapkan tata kelola tiga lapisan ini secara bertahap di dalam organisasi adalah kunci untuk mengubah risiko semacam ini dari "bencana" menjadi "insiden kecil yang bisa dicegat sejak dini".

Mendorong gerbang penjagaan pertama ke tangan karyawan juga merupakan implementasi konkret lapisan ini: sebelum deploy jalankan dulu satu putaran pemindaian secret, pemeriksaan jalur kebocoran data sensitif, dan peringatan dependency yang belum di-upgrade, sehingga karyawan sendiri melihat risikonya dan menambalnya sendiri; saat IT mengambil alih, yang diterima adalah hasil jadi yang sudah melewati gerbang pertama, dan perhatiannya tertuju pada lapisan kebijakan, tidak perlu mengejar lubang dasar satu per satu di dashboard. Di pasaran sudah ada banyak layanan yang mengotomasi gerbang penjagaan ini: mendistribusikan "kotak pertama" tanggung jawab ke tangan karyawan, sementara IT menjaga desain yang lebih di hulu.

Bagaimana merancang checkpoint proses dan bagaimana membangun kaidah human-in-the-loop adalah topik tulisan lain (akan ditulis khusus nanti). Lapisan audit di tulisan ini lebih dulu menunjukkan satu pengamatan: punya audit log adalah baseline, desain proses adalah pekerjaan yang lebih di hulu.

Menempatkan tiga lapisan visibilitas → batasan → audit bersama-sama, masing-masing menyelesaikan masalah pada tingkat yang berbeda; tetapi ketiga hal ini punya satu prasyarat bersama: harus ada satu kontainer yang bisa dilihat dan dikelola IT untuk menampung mereka. Di bagian Dilema tata kelola AI perusahaan sebelumnya jawaban ini sudah disinggung: sandbox menjadi perimeter keamanan perusahaan yang baru. Bagian berikutnya akan membentangkan mengapa jawaban ini baru muncul dalam satu-dua tahun terakhir, dan apa yang berubah.

Perimeter keamanan perusahaan baru bagi Shadow IT: sandbox

Sejak tadi "sandbox" terus dilempar sebagai jawaban. Di sini kita jelaskan secara resmi apa sebenarnya ia.

Konsepnya sebenarnya tidak baru: browser punya sandbox (halaman web tidak bisa mengakses file lokal Anda), iOS punya sandbox (setiap aplikasi hanya bisa menyentuh datanya sendiri), dan runtime berbagai bahasa pemrograman juga punya desain isolasinya masing-masing, setidaknya berusia sepuluh tahun ke atas. Yang baru adalah: dalam satu-dua tahun terakhir ia terdorong ke pusat diskusi tata kelola IT dan menjadi jawaban default bagi perimeter keamanan perusahaan. Penyebabnya, tiga kekuatan tadi (ambang deployment turun ke nol, AI butuh data nyata, agent melewati IDP) telah menembus garis pertahanan lama.

Sandbox adalah jalan keluar bersama bagi ketiga kekuatan itu: karyawan tetap men-deploy tanpa hambatan, tetapi berjalan di dalam sandbox yang bisa dilihat IT; AI hanya melihat irisan data yang sudah disiapkan di dalam sandbox, field sensitif sudah ditangani sebelum data keluar dari sandbox, sehingga IT tidak perlu meninjau setiap prompt satu per satu; dan sandbox menangkap aksi agent + sistem karyawan sekaligus sebagai batas eksekusi yang terpadu. Perusahaan yang khusus membuat agent sandbox seperti E2B, Daytona, CodeSandbox SDK, Modal, dan Beam bermunculan dengan cepat dalam 12 bulan terakhir, persis karena melihat celah ini.

Sandbox-nya sendiri berjalan di mana?

Menerapkan sandbox punya tiga opsi: pakai sandbox bawaan platform, sepenuhnya self-host, atau sandbox terkelola (model PaaS). Mengakui bahwa sandbox adalah jawabannya baru langkah pertama. Sandbox-nya sendiri berjalan di mana, siapa yang mengelolanya, siapa yang memperbaiki saat ada masalah, adalah soal pilihan yang sedang dievaluasi setiap Direktur IT di 2026, dan ketiga jalan punya trade-off-nya masing-masing:

• Pakai sandbox bawaan platform (default Lovable / Bolt / v0 dan sejenisnya): sederhana, tetapi data dan output-nya terikat ke vendor, IT tidak bisa menarik inventaris, dan penagihannya sering kali masih ada di kartu pribadi karyawan.
• Sepenuhnya self-host: secara teknis terkendali, tetapi harus memelihara satu tim infra khusus. Karyawan melakukan vibe coding demi menghindari prosedur IT, sementara IT justru harus mengelola satu sistem tambahan demi mengurung vibe coding ke dalam sandbox, dan biayanya belum tentu lebih murah.
• Sandbox terkelola (model PaaS): pilih sendiri cloud, region, dan cakupan kedaulatan data yang diinginkan, tetapi operasinya diserahkan ke platform.

Pilihan ini tidak bisa ditunda: karyawan yang melakukan vibe coding tidak akan menunggu Anda.

Menarik ketiga kekuatan ini bersama-sama, definisi perimeter keamanan perusahaan sebenarnya terus bergeser sepanjang waktu: sebelum era 2000-an ini adalah era firewall, yang menjaga "siapa yang bisa masuk ke jaringan perusahaan"; dari 2010 hingga 2024 ia berubah menjadi IDP / SaaS, yang menjaga "siapa yang bisa login ke sistem mana"; sejak 2024 dan seterusnya, di era vibe coding, yang harus dijaga menjadi "di sandbox mana output karyawan dan agent berjalan".

Sandbox ini menggambar satu cakupan yang bisa dilihat IT di sekitar kebebasan karyawan. Karyawan (dan agent yang dibuka karyawan) terus melakukan vibe coding di dalamnya; IT tidak perlu meninjau kode, tidak perlu melarang tools, tidak perlu mengulang pekerjaan karyawan, cukup memelihara sandbox itu sendiri: di mana ia berada, siapa yang bisa masuk, apa yang berjalan, berapa banyak yang dipakai.

Sudut pandang ini adalah pembebasan bagi Direktur IT: perannya berbalik dari "melarang karyawan melakukan X" menjadi "memberi karyawan tempat untuk melakukan X". Yang pertama membuatnya menjadi blocker, yang kedua membuatnya menjadi enabler; Direktur IT yang sama, bedanya hanya pada garis mana yang dia pilih untuk dijaga.

Tiga langkah Direktur IT menerapkan tata kelola vibe coding

Jika Anda seorang Direktur IT, dan perusahaan baru mulai memasuki tahap vibe coding:

Langkah pertama: jalankan satu kali inventarisasi. Tanyakan setiap departemen "apakah belakangan ini kalian memakai AI untuk menulis sesuatu yang sedang berjalan?" Hasilnya biasanya akan mengejutkan. Tulis semuanya, ini adalah baseline visibilitas Anda.

Langkah kedua: buka satu workspace yang disetujui, dengan deployment terpusat, penagihan bersama, audit log, dan manajemen kursi sekaligus dalam satu tempat. Ekosistem ini kira-kira terbagi tiga lapisan, dengan opsi yang umum:

• Lapisan identitas dan izin: Okta, Entra ID (sebelumnya Azure AD), Auth0, JumpCloud, GitHub Enterprise SSO, mengelola "siapa yang bisa login ke sistem mana"
• Lapisan integrasi deployment + penagihan + audit: Fly.io organizations, Heroku Teams, Render Teams, Vercel Teams, Zeabur Team Plan, mengelola "benda berjalan di mana, siapa yang bisa melihat, siapa yang membayar"
• Lapisan otomasi kontrol risiko dan kepatuhan: Vanta, Drata, Secureframe, Datadog Cloud Security, mengelola "persiapan audit dan peringatan anomali"

Stack lengkap biasanya memadukan dua atau tiga lapisan. Memilih bukan intinya; membuat aplikasi AI karyawan yang ada pindah ke sini, dan yang baru secara default berjalan di sini, itulah intinya.

Langkah ketiga: bangun jalur audit. Bahkan jika tidak harus lolos ISO atau SOC 2 formal, jalankan pemeriksaan audit log sekali per kuartal, pastikan semua service produksi punya owner. Kebiasaan ini akan menyelamatkan Anda ketika audit yang sesungguhnya benar-benar datang.

Perusahaan di industri berbeda punya pemahamannya masing-masing dalam menghadapi masalah tata kelola AI. Mesin dua orang di industri komedi-hiburan adalah salah satu contoh terkini: Sunny memimpin tata kelola, Feng membangun sistem, dan menuliskan tiga lapisan tata kelola di atas ke dalam alur kerja harian.

Membawa sistem vibe coding ke dalam kerangka tata kelola IT

Kembali ke kisah Budi, tiga bulan telah berlalu.

Saat dulu menerima telepon "halaman kampanye keanggotaan down", Budi bahkan tidak tahu nama service itu. Sekarang dia membuka IT workspace perusahaan, dan yang dia lihat adalah satu dashboard terpadu: halaman kampanye keanggotaan buatan marketing ada di sini, tool perapihan data pelanggan buatan sales ada di sana, scheduler interview buatan HR juga ada. Status deployment setiap service, siapa yang terakhir mengubah env var, berapa banyak resource yang dipakai, berjalan di region mana, semuanya ada di satu layar.

Karyawan terus memakai Cursor untuk menulis, dan aplikasi AI yang baru dibuat secara default di-deploy ke workspace ini. Budi tidak perlu mengejar setiap departemen untuk bertanya "belakangan kalian buat apa", karena dashboard sudah menjawab pertanyaan itu; ketika ada masalah dia tahu harus mencari siapa, tahu service terkait berjalan di mana, tahu di mana batasan datanya.

Dia tidak melarang siapa pun memakai AI, yang dia lakukan adalah menyiapkan sandbox-nya, agar vibe coding karyawan terjadi secara alami di ruang yang disetujui ini.

Inilah tata kelola IT di era vibe coding: setelah merancang dengan jelas di mana karyawan boleh berjalan, pertanyaan siapa yang boleh menulis berhenti menjadi masalah.

Untuk langsung menyiapkan sandbox dan membawa vibe coding karyawan ke dalam lingkungan yang bisa dilihat IT, Zeabur Team Plan dirancang untuk melakukan hal ini.