Masalah 'siapa boleh melihat apa': menambahkan user permissions ke aplikasi buatan AI-mu

Saat aplikasi buatan AI-mu berhenti hanya menjadi milikmu, saat itulah permissions menjadi masalah nyata. Sampai saat itu, setiap halaman menampilkan segalanya. Setiap daftar menampilkan setiap baris. Setiap tombol berfungsi untuk semua orang. Ini aplikasi single-player yang berpura-pura jadi multi-player.

Lalu kamu menambahkan rekan tim pertamamu, atau pelanggan pertamamu, atau penguji beta pertamamu — dan mereka melihat sesuatu yang seharusnya tidak mereka lihat. Mungkin itu gaji rekan timnya. Mungkin itu draf yang belum siap. Mungkin itu pengaturan admin, yang tak sengaja terekspos.

Inilah masalah “siapa boleh melihat apa”, dan ini adalah satu hal terbesar yang disalahpahami builder non-teknis saat merilis proyek AI app builder. Kabar baiknya: kamu tidak perlu menjadi pakar keamanan untuk memecahkannya. Kamu hanya butuh cara yang jelas untuk membicarakannya dengan AI builder-mu.

Kenapa aplikasi buatan AI-mu dimulai dengan terlalu permisif

Saat kamu mendeskripsikan sebuah aplikasi ke AI builder — “Aku ingin CRM tempat aku bisa menambahkan klien dan catatan” — builder-nya mengoptimalkan satu hal: membuatnya berfungsi untuk orang yang mendeskripsikannya. Aplikasi default-nya adalah “semua orang yang sudah login bisa melihat segalanya”. Ini baik-baik saja untuk tools pribadi. Ini bencana saat pengguna kedua muncul.

Ini bukan bug di AI app builder. Ini hasil alami dari kamu yang tidak memberitahunya siapa yang boleh melihat apa. Builder-nya tidak tahu daftar klienmu itu sensitif, atau bahwa “Catatan” mungkin berisi hal-hal yang tidak ingin kamu perlihatkan ke klien. Kamu yang harus mengatakannya.

Tiga pertanyaan yang harus diajukan sebelum menambahkan pengguna kedua

Sebelum kamu mengundang siapa pun, tanyakan tiga hal pada dirimu sendiri. Tuliskan jawabannya — kamu akan menyodorkannya ke AI builder-mu di langkah berikutnya.

1. Apa saja peran-perannya?

Bukan orangnya — kategorinya. Kebanyakan aplikasi punya antara dua sampai empat. Untuk portal freelancer: “Aku” dan “Klien”. Untuk internal tool: “Admin”, “Manajer”, “Anggota tim”. Untuk aplikasi komunitas: “Moderator”, “Anggota”, “Tamu”. Tahan godaan untuk melewati empat peran terlalu dini. Setiap peran melipatgandakan aturan yang harus kamu lacak.

2. Untuk setiap peran, apa yang boleh mereka lihat?

Telusuri setiap halaman di aplikasimu, dalam benakmu. Untuk masing-masing, tanyakan: haruskah seorang Klien melihat halaman ini sama sekali? Haruskah mereka melihat semua data di dalamnya, atau hanya milik mereka sendiri? Haruskah mereka melihat halamannya tapi dengan beberapa field disembunyikan?

Pola paling sederhana: pemilik melihat segalanya; semua orang lain hanya melihat apa yang secara eksplisit diberi akses kepadanya. Ini berfungsi untuk 80% aplikasi tanpa banyak kustomisasi.

3. Untuk setiap peran, apa yang boleh mereka lakukan?

Latihan yang sama, tapi untuk tombol dan aksi. Bolehkah seorang Anggota menghapus proyek? Bolehkah seorang Klien mengedit profil mereka tapi bukan paket mereka? Bolehkah seorang Manajer mengundang orang baru? Kebanyakan builder non-teknis melupakan langkah ini sama sekali dan berakhir dengan aplikasi yang membuat pengguna mana pun yang sudah login bisa menghapus seluruh database dengan satu klik tombol.

Membicarakan permissions dengan AI builder-mu

Begitu kamu punya jawabannya, prompt ke AI builder-mu menulis dirinya sendiri. Bentuknya seperti ini:

Perbarui aplikasi ini untuk mendukung dua peran: Owner dan Klien.

Owner bisa melihat semua klien, semua proyek, dan semua tagihan. Owner bisa membuat, mengedit, dan menghapus apa pun.

Klien hanya bisa melihat proyek mereka sendiri dan tagihan mereka sendiri. Mereka tidak bisa melihat daftar klien, halaman tim, atau halaman pengaturan. Mereka bisa melihat proyek mereka tapi tidak bisa mengeditnya. Mereka bisa melihat dan membayar tagihan mereka sendiri.

Saat seorang Klien sudah login, sembunyikan tautan navigasi ke Pengaturan dan Tim. Kalau seorang Klien mencoba mengunjungi halaman-halaman itu lewat URL, alihkan mereka ke dashboard mereka.

Tiga hal yang penting dalam prompt itu:

Spesifik per halaman dan aksi. “Klien bisa melihat proyek mereka” itu kabur. “Klien bisa melihat tapi tidak mengedit proyek mereka sendiri di halaman /projects” adalah sesuatu yang benar-benar bisa diimplementasikan oleh AI builder.
Katakan apa yang terjadi pada nav-nya. Menyembunyikan tautannya tidak sama dengan memblokir halamannya. Kamu ingin keduanya.
Tangani kasus pengetikan URL. Kalau tidak, pengguna yang penasaran bisa menempelkan /admin di bilah browser mereka dan masuk begitu saja.

Empat kesalahan yang kulihat setiap minggu

Setelah menyaksikan banyak builder merilis aplikasi multi-user pertama mereka, kesalahan yang sama terus muncul:

Menyembunyikan tombol bukan menyembunyikan data. Kalau kamu menyuruh AI builder-mu untuk “sembunyikan tombol hapus untuk Klien”, tombolnya hilang dari layar. Tapi operasi hapus di baliknya tetap berfungsi kalau ada yang tahu cara memanggilnya. Perbaikannya: suruh juga builder-nya untuk “tolak permintaan hapus dari akun non-Owner di backend”. Kalau builder-nya tidak tahu apa arti “backend” di aplikasimu, suruh ia untuk “blokir aksinya di sisi server, bukan cuma menyembunyikan tombolnya”.

Satu peran untuk dua pekerjaan. Orang mencampuradukkan “orang yang membayar” dengan “orang yang memakai aplikasinya”. Seorang Klien yang membayarmu untuk sebuah pekerjaan dan seorang karyawan-Klien yang memakai dashboard yang kamu bangun untuk klien itu bukanlah peran yang sama. Kalau kamu mencampurnya, kamu akan menghabiskan sebulan ke depan menambal aturan satu-per-satu. Dua peran. Selalu.

Membiarkan pengguna mengundang pengguna sejak hari pertama. Menggoda untuk langsung menambahkan “Undang rekan tim”. Jangan. Untuk 10 pengguna pertamamu, undang mereka sendiri, secara manual, dari panel admin yang hanya bisa kamu lihat. Undangan swalayan adalah satu kategori utuh aturan permission (siapa boleh mengundang siapa? peran apa yang didapat orang yang diundang? bisakah mereka mengundang orang lain?). Tunggu sampai kamu benar-benar membutuhkannya.

Memercayai apa yang dikatakan AI builder tanpa mengecek. AI builder akan memberitahumu, dengan percaya diri, bahwa permissions sudah disiapkan. Mungkin sudah. Mungkin belum. Selalu uji dengan login sebagai non-owner dan coba lakukan hal-hal buruk: klik tombol hapus, tempelkan URL admin, edit field yang seharusnya tidak bisa kamu edit. Kalau ada yang berfungsi padahal seharusnya tidak, suruh builder-nya memperbaikinya secara spesifik.

Checklist cepat sebelum kamu mengundang siapa pun

Sebelum kamu mengirim undangan pertama itu ke pengguna kedua, jalani ini:

Aku bisa menyebutkan peran-peran di aplikasiku dengan jari satu tangan.
Untuk setiap peran, aku tahu halaman mana yang boleh mereka lihat dan mana yang tidak.
Aku sudah login sebagai non-owner dan memastikan halaman yang salah tersembunyi.
Aku sudah mencoba menempelkan URL admin di browser sebagai non-owner dan terblokir.
Aku sudah mencoba mengklik tombol hapus atau edit yang seharusnya terlarang dan terblokir.
Kalau ada yang salah, aku punya cara untuk mencabut akses seorang pengguna dengan cepat.

Kalau ada poin yang tidak lolos, itulah percakapan berikutnya dengan AI builder-mu — sebelum kamu mengirim undangannya, bukan sesudah.

Satu pergeseran pola pikir yang membantu

Membangun permissions untuk aplikasi multi-user sebagian besar adalah soal membayangkan dirimu sebagai versi sedikit usil dari penggunamu yang paling nakal. Bukan jahat — cuma penasaran. Mereka akan mengklik berbagai hal. Mereka akan menempelkan URL. Mereka akan mencoba melihat apa isi halaman “Pengaturan” yang mereka perhatikan di screenshot-mu.

Tugasmu — dan tugas AI builder-mu — adalah memastikan bahwa saat mereka melihat, jawabannya konsisten: entah mereka boleh melihatnya karena itu data mereka, atau mereka tidak boleh melihatnya karena itu bukan. Tanpa celah. Tanpa halaman admin yang tak sengaja terekspos. Tanpa “aku lupa halaman itu ada”.

Kebanyakan builder tidak memikirkan permissions sampai sesuatu yang memalukan terjadi. Kabar baiknya: menghabiskan 20 menit memikirkan peran sebelum kamu merilis menghematmu 20 jam memperbaikinya nanti, plus email yang tidak ingin kamu tulis ke pelanggan yang melihat hal yang salah.

Sedang membangun sesuatu yang punya sisi multi-user? Lain kali saat kamu duduk dengan AI app builder-mu, mulai sesinya dengan menyebutkan peran-peran di aplikasimu dengan lantang. Itu kebiasaan lima menit termudah untuk dibangun, dan akan menangkap sebagian besar kesalahan terburuk sebelum terjadi.