Bukti Keamanan Aplikasi AI untuk Serah Terima ke Klien
Momen paling tidak nyaman bagi studio atau agensi yang membangun aplikasi berbasis AI bukan saat demo, tetapi saat serah terima. Klien bertanya satu kalimat sederhana: "aplikasi ini aman, kan?" Dan terlalu sering jawabannya berupa keyakinan — bukan bukti.
Padahal bukti itu bisa disiapkan. Artikel ini merangkum apa yang benar-benar bisa dibuktikan secara teknis, apa yang tidak bisa, dan bagaimana menyusunnya supaya bisa dilampirkan ke dokumen serah terima tanpa melebih-lebihkan.
Kenapa Pertanyaan Itu Sulit Dijawab
Ada dua alasan. Pertama, sebagian besar alat keamanan generik memeriksa hal yang tidak menjadi risiko utama aplikasi AI. Aplikasi berbasis LLM gagal "seperti percakapan", bukan seperti database — ia menerima instruksi dan data dalam satu aliran yang sama. Celah seperti prompt injection dan prompt stealing tidak muncul di daftar kerentanan pemindai kode biasa.
Kedua, klaim keamanan mudah berubah menjadi klaim palsu. Menulis "aplikasi terbukti aman" di dokumen serah terima adalah janji yang tidak bisa ditepati siapa pun — termasuk alat pemindai terbaik. Yang jujur dan tetap bernilai adalah bukti pengujian, bukan jaminan.
Apa yang Bisa Dibuktikan, Apa yang Tidak
Inilah pembagian yang perlu Anda pahami sebelum menjanjikan apa pun ke klien.
- Bisa diperiksa otomatis: kebocoran kunci API dan rahasia di kode/riwayat Git, dependensi dengan kerentanan diketahui, pola berisiko pada kode (injeksi, konfigurasi CORS longgar, debug aktif), konfigurasi TLS/header pada URL, serta perilaku model terhadap serangan prompt (jailbreak, prompt stealing, indikasi prompt injection).
- Tidak bisa diperiksa otomatis: izin database dan kebijakan akses baris (RLS) — ini hanya terlihat dari dalam platform database yang Anda pakai; logika bisnis yang salah rancang; dan pembuktian bahwa sebuah celah benar-benar bisa dieksploitasi tanpa pengujian aktif yang disetujui pemilik sistem.
Empat Bukti yang Layak Dilampirkan
- Hasil pengujian lapisan LLM — daftar skenario serangan yang dijalankan (injeksi langsung, injeksi tidak langsung lewat dokumen, jailbreak, permintaan mencuri system prompt) beserta respons aplikasi. Ini bukti yang paling relevan untuk aplikasi AI dan paling jarang dimiliki.
- Laporan temuan berprioritas — apa yang ditemukan, tingkat keparahan, dampak bisnis singkat, dan status perbaikan. Bukan dump ribuan baris, tapi daftar yang bisa dieksekusi.
- Daftar area yang belum diuji — justru bagian ini yang membuat laporan dipercaya. Menyebut apa yang tidak tercakup membuat klien tahu batasnya dan menghindarkan Anda dari klaim berlebih.
- Bukti kepemilikan target — catatan bahwa pengujian dilakukan atas otorisasi pemilik sistem. Ini melindungi Anda dan klien secara hukum, terutama bila pengujian menyertakan pemindaian URL.
Alur Kerja Satu Hari Sebelum Serah Terima
- Kunci versi dulu — catat commit atau rilis yang diuji. Laporan keamanan tanpa versi yang jelas tidak bisa dipertanggungjawabkan saat kode berubah.
- Uji dua sisi paralel — sisi kode (rahasia, dependensi, pola berisiko) dan sisi percakapan (perilaku model terhadap serangan prompt).
- Periksa izin akses dari dalam platform — jalankan pemeriksa bawaan layanan database/aplikasi Anda untuk kebijakan akses; ini melengkapi hasil pengujian dari sisi luar.
- Susun lampiran serah terima — ringkasan temuan, status perbaikan, area yang belum diuji, dan tanggal pengujian.
Kesimpulan
Klien tidak meminta jaminan mutlak — mereka meminta kejelasan. Tiga hal yang benar-benar menaikkan kepercayaan saat serah terima: menunjukkan apa yang sudah diuji, menunjukkan apa yang belum, dan menyimpan buktinya dalam bentuk laporan yang bisa dibaca ulang.
AISG dibangun untuk bagian kode dan lapisan AI dari pekerjaan itu: pemindaian rahasia, dependensi, dan pola berisiko pada kode, ditambah pengujian LLM (prompt injection, jailbreak, prompt stealing) dalam satu laporan PDF yang bisa dilampirkan. Pemindaian kode berjalan lokal di mesin Anda — kode tidak perlu diunggah ke mana pun.