Cara Melindungi Data Pengguna di Aplikasi Buatan AI-mu (Tanpa Tim Keamanan)

Seorang coach yang kami kenal membangun aplikasi pelacak klien dengan AI app builder dalam satu akhir pekan. Catatan sesi, target, check-in kemajuan — semua yang dulu ia simpan di buku catatan, kini bisa dicari dan tertata. Ia bekerja begitu baik sampai dua teman coach memintanya untuk ikut memakainya.

Saat itulah ia tersadar: ia tidak lagi menyimpan catatannya sendiri. Ia menyimpan catatan orang lain tentang klien mereka — detail kesehatan, perjuangan pribadi, nama-nama. Kalau data itu bocor, itu bukan rasa malunya. Itu rasa malu mereka.

Kamu tidak butuh tim keamanan untuk menangani ini secara bertanggung jawab. Kamu butuh tiga kebiasaan dan kesediaan mengajukan beberapa pertanyaan langsung ke AI builder-mu. Panduan ini membahas cara melindungi data pengguna di aplikasi buatan AI-mu pada level yang benar-benar penting untuk produk kecil.

Mulai dengan menyadari data pengguna apa yang sebenarnya kamu simpan

Sebagian besar pembuat meremehkan ini. “Saya cuma punya formulir signup” biasanya berarti kamu punya:

Alamat email — cukup untuk men-spam atau mem-phishing seseorang.
Nama yang terhubung dengan perilaku — apa yang mereka beli, apa yang mereka tulis, kapan mereka login.
Apa pun yang diketik penggunamu ke dalam kotak teks bebas — dan orang akan mengetik apa saja ke dalam kolom catatan: nomor telepon, detail medis, gaji, keluhan tentang atasan mereka.

Luangkan sepuluh menit dan tuliskan setiap potong informasi yang disimpan aplikasimu tentang seseorang. Bukan kolom database-nya — tapi makna manusiawinya. “Email”, “suplemen apa yang mereka konsumsi”, “catatan yang ditulis trainer mereka tentang mereka”. Daftar itu adalah permukaan tanggung jawabmu. Semua bagian lain di tulisan ini adalah soal membuatnya lebih kecil dan lebih aman.

Kebiasaan 1: Kumpulkan lebih sedikit

Data yang paling murah untuk dilindungi adalah data yang tak pernah kamu kumpulkan. Sebelum melindungi apa pun, perkecil daftarnya.

Telusuri daftar yang baru saja kamu buat dan tanyakan untuk setiap item: apakah saya memakai ini? Aplikasi si coach meminta tanggal lahir saat signup karena template signup AI builder-nya menyertakannya. Ia tidak pernah memakainya di mana pun. Satu kalimat ke AI builder-nya — “hapus tanggal lahir dari signup dan hapus kolomnya” — dan satu kategori utuh data sensitif lenyap.

Hal-hal umum yang dikumpulkan aplikasi tapi tak pernah dipakai: tanggal lahir, nomor telepon, alamat fisik, jenis kelamin, “dari mana kamu tahu tentang kami”. Kalau kamu tidak memakainya bulan ini, kamu selalu bisa memintanya nanti. Kamu tidak bisa membatalkan kebocoran.

Kebiasaan 2: Kendalikan siapa bisa melihat apa

Ada dua versi pertanyaan ini, dan kamu butuh keduanya.

Di dalam aplikasi: bisakah satu pengguna melihat data pengguna lain? Kalau aplikasimu punya klien dan coach, bisakah klien A melihat catatan klien B? Kami sudah menulis panduan utuh soal izin pengguna di aplikasi buatan AI-mu, tapi versi singkatnya: jelaskan aturannya ke AI builder-mu dalam bahasa sederhana (“seorang coach hanya melihat kliennya sendiri; klien hanya melihat dirinya sendiri”) lalu uji sendiri dengan dua akun. Login sebagai satu pengguna, coba jangkau data pengguna lain dengan klik-klik. Lima menit, dua akun uji. Satu tes ini menangkap kebocoran yang paling umum di aplikasi kecil.

Di luar aplikasi: siapa yang bisa melihat database-nya sendiri? Itu kamu, platform AI builder-mu, dan siapa pun yang sudah kamu beri akses login. Yang membawa kita ke pertanyaan-pertanyaannya.

Kebiasaan 3: Tanyakan lima pertanyaan ini ke builder-mu

Kamu tidak perlu memahami jawabannya secara mendalam. Kamu perlu bertanya, dan jawabannya seharusnya berupa “ya” yang meyakinkan. Tempel pertanyaan ini ke AI app builder-mu satu per satu:

“Apakah password pengguna disimpan dalam bentuk hashed, atau bisa dibaca siapa saja?” Satu-satunya jawaban yang bisa diterima mengandung kata “hashed”. Kalau aplikasimu menyimpan password yang bisa dibaca siapa saja, perbaiki hari ini juga — biasanya ini perbaikan satu prompt, dan sebagian besar builder modern melakukan ini dengan benar secara default.
“Apakah koneksi ke aplikasi ini terenkripsi (HTTPS)?” Cari gembok di browser-mu sendiri. Kalau alamat aplikasimu diawali https://, beres untuk yang ini.
“Kalau seseorang mendapatkan file database-nya, bisakah mereka membaca kolom yang sensitif?” Ini soal enkripsi data saat tersimpan (at rest). Sebagian besar platform hosting menanganinya otomatis — tanyakan tetap dan tuliskan jawabannya.
“Layanan pihak ketiga mana saja yang menerima data pengguna?” Tools email, analytics, pemroses pembayaran. Kamu tidak menghapusnya — kamu membuat daftarmu lengkap, karena setiap layanan yang menyimpan data penggunamu adalah bagian dari permukaan tanggung jawabmu.
“Apakah ada backup, dan siapa yang bisa mengaksesnya?” Backup adalah salinan datamu, dan salinan juga butuh dilindungi. (Kalau kamu belum menyiapkan backup sama sekali, mulai di sini.)

Simpan jawabannya di sebuah dokumen. Dokumen itu adalah awal dari postur keamananmu, dan kamu akan senang ia ada saat pertama kali seorang pelanggan — atau pengacara pelanggan — bertanya.

Saat ada yang bilang “hapus data saya”

Suatu saat pasti ada yang minta, dan hukum di sebagian besar tempat (GDPR di Eropa, aturan serupa di tempat lain) menyatakan kamu memang harus melakukannya. Tentukan sekarang apa jawabanmu:

Bisakah kamu menghapus satu pengguna dan semua yang terhubung dengannya? Minta AI builder-mu menambahkan ini — “bangun aksi admin yang menghapus seorang pengguna dan semua datanya” — sebelum kamu membutuhkannya di bawah tenggat.
Apakah menghapus mereka di aplikasi juga menghapus mereka dari tools email dan analytics-mu? Cek daftarmu dari pertanyaan 4.
Backup masih akan menyimpan mereka untuk sementara. Itu normal dan umumnya tak masalah — cukup ketahui saja, supaya kamu bisa mengatakannya dengan jujur.

Menjawab permintaan penghapusan dalam sehari karena kamu sudah bersiap terlihat profesional. Kelabakan selama dua minggu terlihat persis seperti apa adanya.

Tulis halaman privasi berbahasa sederhana

Lewati dulu legalese hasil generate sepanjang 4.000 kata. Tulis lima kalimat jujur: apa yang kamu kumpulkan, kenapa, siapa lagi yang menyentuhnya (tools email-mu, pemroses pembayaranmu), berapa lama kamu menyimpannya, dan cara meminta penghapusan. Letakkan di /privacy dan tautkan dari halaman signup-mu.

Ini bukan nasihat hukum, dan kalau kamu menangani data yang benar-benar sensitif — kesehatan, anak-anak, keuangan — keluarkanlah uang untuk satu jam dengan pengacara. Tapi halaman yang jelas dan jujur mengalahkan halaman yang terlihat mengesankan tapi tak bisa dibaca siapa pun, dan menulisnya memaksamu untuk benar-benar mengetahui jawabanmu sendiri.

Standarnya lebih rendah dari yang kamu takutkan, dan lebih tinggi dari nol

Kamu tidak sedang bertahan melawan negara. Kamu bertahan melawan kegagalan yang membosankan dan umum: kolom data sisa yang tak dibutuhkan siapa pun, aturan izin yang tak diuji siapa pun, tabel password yang lupa di-hash seseorang. Melindungi data pengguna pada level ini bukan keterampilan spesialis — setiap kegagalan itu bisa diperbaiki dengan prompt berbahasa sederhana dan tes lima menit.

Si coach dari awal cerita melakukan semua ini dalam satu sore: menghapus dua kolom yang tak terpakai, menjalankan tes dua akun (dan menangkap satu kebocoran — klien bisa melihat nama depan satu sama lain di sebuah dropdown), mengajukan lima pertanyaan, menulis halaman privasinya. Aplikasinya tidak terlihat berbeda sesudahnya. Tapi saat temannya bertanya “apakah ini aman untuk catatan klien saya?”, ia punya jawaban yang sungguhan.

Luangkan satu sorenya. Penggunamu memberimu data mereka atas dasar kepercayaan — beginilah rupa menjaga kepercayaan itu.