Anda mengetik kebutuhan usaha, memilih tampilan, lalu AI menyusun website. Halamannya rapi, tombolnya bisa diklik, dan hasilnya terlihat siap dibagikan. Wajar jika Anda berpikir: buat apa membayar engineer kalau sebagian besar pekerjaan ini bisa saya lakukan sendiri?
Buat website sendiri pakai AI bisa menjadi pilihan yang masuk akal. Yang perlu Anda nilai adalah kesiapan untuk memeriksa hasilnya, mengelola data, menangani gangguan, dan merawatnya setelah terbit. Biaya awal yang kecil belum menjawab siapa yang mengerjakan semua itu.
Bayangkan website jasa dengan formulir permintaan penawaran. Pengunjung melihat pesan berhasil, tetapi permintaannya tidak tersimpan. Pemilik baru menyadarinya ketika calon pelanggan menanyakan tindak lanjut. Ini ilustrasi, bukan pengalaman pelanggan tertentu. Tampilan yang meyakinkan belum memastikan proses bisnis di belakangnya bekerja.
Saya, Dicky Ibrohim, membantu pengembangan dan perbaikan website dengan membahas fungsi bisnis serta lingkup pekerjaan secara langsung. Jika Anda sudah mempunyai hasil buatan AI, hasil itu dapat menjadi bahan pembahasan. Kebutuhan perbaikan atau pembangunan ulang ditentukan dari kondisinya.
Apakah AI benar-benar bisa menggantikan jasa pembuatan website?
AI dapat membantu menyusun kode, konten, dan rancangan awal. Untuk halaman informasi sederhana, alat yang sesuai dapat memangkas pekerjaan. Namun, keputusan mengenai data apa yang disimpan, siapa yang boleh mengaksesnya, serta bagaimana layanan dipulihkan tetap perlu dibuat dan diuji.
Ada tiga penggunaan AI yang perlu dibedakan:
| Cara memakai AI | Risiko yang perlu diperiksa |
|---|---|
| AI menghasilkan kode atau tampilan | Ketepatan fungsi, keamanan kode, kualitas pengalaman pengguna, dan pemeliharaan |
| Agen AI diberi akses ke berkas, server, atau layanan | Batas izin, perubahan yang dapat dilakukan, dan persetujuan untuk tindakan berdampak besar |
| Website menyediakan chatbot atau fitur AI kepada pengunjung | Data yang masuk ke model, manipulasi instruksi, biaya pemakaian, dan tindakan yang dapat dipicu |
Website statis yang dibuat dengan bantuan AI tidak otomatis menjalankan model AI pada setiap kunjungan. Risiko chatbot dan biaya pemanggilan model hanya relevan bila ada fitur atau layanan tersebut. Sebaliknya, kode buatan manusia juga perlu diperiksa dengan standar yang sama.
Apa kata riset tentang keamanan kode buatan AI?
Studi Perry dan rekan-rekan yang diterbitkan pada ACM CCS 2023 melibatkan 47 peserta dengan tugas pemrograman terkait keamanan. Dalam pengaturan studi tersebut, kelompok berbantuan AI menghasilkan kode yang secara keseluruhan kurang aman dan lebih percaya bahwa hasilnya aman. Pesertanya terutama mahasiswa dan modelnya Codex generasi lama. Hasilnya terbatas pada kondisi penelitian, bukan ukuran kerentanan semua website pada 2026. Makalah peneliti, terbit di ACM CCS.
Riset lain di USENIX Security 2025 meneliti 16 model pembuat kode dan menemukan rekomendasi paket perangkat lunak yang sebenarnya tidak tersedia. Nama paket semacam itu dapat menimbulkan risiko bila seseorang kemudian menyediakannya untuk tujuan berbahaya dan pengguna memasangnya tanpa pemeriksaan. Hasilnya menjelaskan mekanisme risiko, bukan menyatakan semua saran paket AI palsu. Makalah USENIX tentang halusinasi paket.
Pelajaran bagi pemilik bisnis adalah menyiapkan pemeriksaan yang dapat dipertanggungjawabkan. Jawaban AI yang terdengar yakin, kode yang berhasil dijalankan, dan tampilan yang selesai belum menggantikan bukti pengujian.
Risiko 1 sampai 8: website terlihat jadi, tetapi fondasinya belum diperiksa
Daftar berikut memetakan 20 risiko yang perlu dipertimbangkan sesuai fungsi website. Ini bukan daftar seluruh kemungkinan kegagalan, dan setiap poin tidak otomatis berlaku pada semua proyek. Contoh bisnis di dalamnya merupakan ilustrasi untuk membantu Anda menilai kebutuhan.
1. Percaya diri sebelum ada bukti bahwa kode aman
Pesan AI yang menyatakan pekerjaan selesai mudah terasa seperti hasil pemeriksaan. Padahal, penjelasan tersebut belum merupakan verifikasi independen. Untuk bisnis Anda, mintalah bukti fungsi apa yang diuji, skenario apa yang gagal, dan temuan apa yang belum selesai ditangani.
2. Aturan bisnis tidak tercermin dalam rancangan
Misalnya, permintaan perubahan jadwal seharusnya membutuhkan persetujuan pengelola, tetapi website langsung mengonfirmasinya. Antarmuka bisa berjalan persis seperti kode yang dibuat, sementara aturan usahanya keliru. OWASP memasukkan kelemahan logika bisnis dalam risiko desain. Pendampingan berguna untuk menerjemahkan kebutuhan menjadi aturan dan hasil uji yang jelas sebelum fitur diaktifkan. OWASP: Insecure Design.
3. Pengunjung bisa mengakses data yang bukan haknya
Menyembunyikan tombol admin belum cukup untuk membatasi akses. Sistem juga perlu memeriksa izin ketika permintaan diproses, termasuk apakah suatu catatan memang boleh dibaca atau diubah oleh pengguna tersebut. Tanpa pemeriksaan yang benar, data pelanggan dapat terbuka atau berubah melalui akses yang tidak semestinya. OWASP: Broken Access Control.
4. Login bekerja, tetapi pemulihan akun dan sesi lemah
Halaman masuk hanyalah satu bagian dari pengelolaan akun. Alur lupa kata sandi, perlindungan kredensial, serta pengakhiran sesi setelah keluar juga perlu diuji. Kekeliruan pada bagian ini dapat membuka jalan bagi pengambilalihan akun. Kebutuhannya mengikuti tingkat akses dan data yang dimiliki pengguna. OWASP: Authentication Failures.
5. Isian pengguna diproses sebagai perintah
Formulir, pencarian, atau komentar menerima masukan dari luar. Jika penanganannya salah, masukan tersebut dapat memengaruhi perintah basis data atau konten yang dijalankan di browser. Risiko injection dan XSS perlu diperiksa pada bagian yang menerima serta menampilkan data, termasuk masukan yang tidak sesuai harapan. OWASP: Injection.
6. HTTPS dianggap sudah melindungi semua data
HTTPS melindungi komunikasi pada jalur yang menggunakannya. Perlindungan data tersimpan dan pengelolaan kunci merupakan pekerjaan lain. Formulir yang memakai HTTPS masih dapat menyimpan informasi sensitif dengan cara yang tidak memadai. Tentukan data yang diperlukan, lokasi penyimpanannya, dan perlindungan yang sesuai; simbol koneksi aman bukan penilaian menyeluruh terhadap website. OWASP: Cryptographic Failures.
7. Pengaturan untuk percobaan terbawa ke website aktif
Pesan kesalahan yang terlalu rinci, izin penyimpanan yang longgar, atau akun bawaan dapat membuka informasi dan akses yang seharusnya dibatasi. Pemeriksaan kode saja belum mencakup seluruh pengaturan hosting dan layanan pendukung. Sebelum terbit, konfigurasi lingkungan aktif perlu ditinjau sesuai kebutuhan website. OWASP: Security Misconfiguration.
8. Paket pendukung dipasang tanpa mengetahui asal dan dukungannya
Selain paket yang mungkin diada-adakan AI, komponen nyata dapat sudah tidak dirawat atau memiliki kerentanan. Ada pula risiko pada proses distribusi dan pembaruannya. Anda perlu mengetahui komponen yang digunakan, sumbernya, serta siapa yang memantau perubahan keamanan. Memasang semakin banyak paket juga berarti menambah bagian yang perlu dikelola. OWASP: Software Supply Chain Failures.
Risiko 9 sampai 12: akses AI, data, dan biaya perlu dibatasi
9. Informasi sensitif ikut dikirim saat meminta bantuan AI
Menempelkan log, daftar pelanggan, atau konfigurasi lengkap ke alat AI dapat ikut mengirim data yang tidak diperlukan. Kebijakan penyimpanan dan pemrosesan berbeda antarproduk serta pengaturan akun. Gunakan data contoh atau penyamaran bila memadai, dan periksa apa yang boleh dibagikan. Jangan berasumsi setiap layanan memproses informasi dengan ketentuan yang sama. OWASP: Sensitive Information Disclosure.
10. Agen mendapat kewenangan lebih luas daripada tugasnya
Risiko berubah ketika alat dapat mengubah server, menghapus berkas, atau menjalankan tindakan di layanan bisnis. Kesalahan tidak lagi terbatas pada jawaban yang salah. Batasi izin sesuai pekerjaan dan tetapkan persetujuan untuk tindakan berdampak besar. Hal ini relevan untuk agen yang mempunyai akses tersebut, bukan setiap percakapan dengan AI. OWASP: Excessive Agency.
11. Instruksi dari luar memengaruhi perilaku AI
Fitur AI yang membaca pesan, dokumen, atau halaman dari luar dapat menerima instruksi yang mencoba mengalihkan tugasnya. Ini dikenal sebagai prompt injection. Dampaknya bergantung pada data dan kemampuan yang tersedia bagi sistem. Website statis tidak otomatis mempunyai risiko ini hanya karena kodenya dibuat AI; periksa apakah ada model atau agen yang memproses masukan tidak tepercaya. OWASP: Prompt Injection.
12. Pemakaian layanan meningkat tanpa batas biaya yang jelas
Permintaan berlebihan pada API dapat membebani kapasitas dan menambah biaya operasional. Jika website menyediakan fitur AI berbayar per pemakaian, tentukan kuota, batas akses, serta penanganan saat batas tercapai. Biaya alat untuk membuat website berbeda dari biaya fitur yang terus berjalan bagi pengunjung. OWASP API Security: Unrestricted Resource Consumption.
Periksa pula apakah pengaturan anggaran hanya mengirim peringatan atau benar-benar membatasi pemakaian. Dokumentasi Google Cloud, misalnya, membedakan anggaran alerts-only dan anggaran dengan spend cap. Konfigurasi serta layanan yang tercakup perlu dipastikan. Dokumentasi anggaran Google Cloud.
Risiko 13 sampai 16: masalah sering terasa setelah website mulai dipakai
13. Sistem tidak siap ketika layanan pendukung gagal
Koneksi terputus, layanan email terlambat, atau data tidak lengkap perlu mempunyai penanganan yang masuk akal. Pada ilustrasi formulir tadi, pesan berhasil seharusnya mengikuti hasil proses yang benar-benar terjadi. Uji kondisi gagal dan tentukan apa yang dilihat pengguna serta tindakan pemulihannya. OWASP membahas dampak keamanan dan keandalan dari kondisi tidak normal yang ditangani secara keliru. OWASP: Mishandling of Exceptional Conditions.
14. Gangguan tidak terdeteksi dan cadangan sulit dipulihkan
Catatan aktivitas membutuhkan pemeriksaan dan peringatan yang sesuai agar kejadian penting tidak terlewat. Penyimpanannya juga harus menghindari paparan informasi sensitif. OWASP: Security Logging and Alerting Failures.
Cadangan mempunyai fungsi berbeda: menyediakan salinan untuk pemulihan. NCSC menekankan pentingnya memahami cara mengembalikan cadangan dan memeriksa kelengkapan isinya. Untuk website bisnis, sepakati data yang dicadangkan, pihak yang dapat memulihkannya, dan pengujian pemulihan yang diperlukan. Panduan cadangan NCSC.
15. Tidak ada penanggung jawab setelah serah terima
Website tetap membutuhkan keputusan ketika komponen diperbarui, dukungan berakhir, atau masalah dilaporkan. Software Security Code of Practice pemerintah Inggris memasukkan kejelasan dukungan dan pemeliharaan dalam komunikasi kepada pelanggan. Pedoman sukarela tersebut dapat menjadi bahan menilai penawaran jasa, tanpa menyiratkan sertifikasi penyedia. Pedoman perangkat lunak GOV.UK.
Tentukan siapa yang menangani laporan, jam layanan, batas pekerjaan, dan biaya tambahan. Jika Anda mempunyai pengelola sendiri, penyerahan ke pengelola itu bisa memadai. Jika belum, kebutuhan pendampingan perlu dibicarakan sebelum website aktif. Baca juga pembahasan website crash setelah update.
16. Pindah platform ternyata membutuhkan pekerjaan besar
Kemudahan saat mulai perlu ditimbang bersama kemampuan mengekspor data, memindahkan fungsi, dan melanjutkan layanan. Panduan GOV.UK tentang ketergantungan teknologi membahas manfaat layanan terkelola sekaligus biaya dan kesulitan berpindah. Prinsip tersebut berguna saat membandingkan platform website, meskipun panduannya membahas layanan cloud. GOV.UK: Managing Technical Lock-in.
Website custom juga dapat bergantung pada framework, lisensi, dan pengetahuan pengelolanya. Mintalah penjelasan tertulis mengenai akses, dokumentasi, serta pilihan serah terima. Ulasan risiko ketergantungan kepada vendor membantu menyiapkan pertanyaan sebelum memesan.
Risiko 17 sampai 20: website ada, tetapi belum membantu pelanggan
17. Konten meyakinkan berisi klaim atau materi yang belum diperiksa
AI dapat menghasilkan keterangan produk yang tidak sesuai, testimoni rekaan, atau materi dengan asal dan hak penggunaan yang belum jelas. NIST mengidentifikasi ketidakakuratan keluaran serta risiko kekayaan intelektual dalam profil risiko AI generatifnya. Periksa fakta, izin penggunaan aset, dan klaim penawaran sebelum terbit. Hasil generatif tidak otomatis melanggar hak pihak lain, tetapi tetap perlu ditinjau. NIST AI 600-1.
18. Sebagian pengunjung kesulitan memakai website
Desain yang menarik bagi pembuatnya belum tentu dapat digunakan oleh orang dengan kebutuhan akses yang berbeda. W3C menyediakan kriteria WCAG yang dapat diuji untuk menilai aksesibilitas konten web. Rencanakan pemeriksaan penggunaan keyboard, formulir, dan keterbacaan sebagai bagian dari pekerjaan. Satu hasil pemeriksaan otomatis belum cukup untuk mengklaim seluruh website memenuhi standar. W3C: WCAG.
19. Tampilan bagus di perangkat Anda, lambat bagi pelanggan
Gambar, skrip, dan layanan tambahan perlu dinilai dampaknya pada pengalaman nyata. Core Web Vitals mencakup pemuatan, respons interaksi, dan kestabilan tampilan. Hasil pengujian laboratorium juga dapat berbeda dari pengalaman pengguna sebenarnya. Mintalah pemeriksaan sesuai perangkat dan kondisi penggunaan yang relevan, bukan hanya melihat pratinjau pada komputer pembuatnya. Panduan Web Vitals.
20. Halaman sulit ditemukan oleh mesin pencari
Website perlu dapat diakses perayap, memberikan respons yang sesuai, dan memiliki konten yang dapat diindeks untuk memenuhi persyaratan teknis dasar Google Search. Salah pengaturan dapat menghalangi proses itu. Memenuhi persyaratan tetap tidak menjamin indeks atau peringkat. Struktur halaman, isi yang berguna, serta penyiapan teknis SEO perlu dikerjakan dan diperiksa. Persyaratan teknis Google Search.
Kapan membuat sendiri masuk akal, kapan perlu engineer?
Mulailah dari kerumitan fungsi dan dampak jika terjadi kesalahan. Halaman profil tanpa akun pelanggan berbeda kebutuhannya dari sistem pemesanan yang menyimpan data atau mengatur akses staf.
| Kondisi bisnis | Pilihan yang layak dipertimbangkan | Yang tetap perlu Anda siapkan |
|---|---|---|
| Halaman informasi sederhana, sedikit integrasi | Membuat sendiri memakai alat atau platform yang sesuai | Waktu memeriksa isi, akses, tampilan, dan pengelolaan domain |
| Kebutuhan standar yang sudah dilayani platform terkelola | Memakai layanan siap pakai dan bantuan seperlunya | Pemeriksaan fitur, biaya, batas dukungan, serta ekspor data |
| Alur kerja khusus, beberapa peran pengguna, atau integrasi penting | Pendampingan engineer dan pengembangan sesuai kebutuhan | Prioritas bisnis, aturan akses, skenario uji, serta anggaran perawatan |
| Website hasil AI sudah ada, tetapi belum diketahui kualitasnya | Penilaian terbatas sebelum memutuskan langkah berikutnya | URL, tujuan website, akses yang tersedia, dan kendala yang terlihat |
Tabel tersebut merupakan panduan keputusan, bukan penilaian atas platform tertentu. Untuk sistem transaksi, lihat juga risiko toko online berbantuan AI tanpa pendampingan.
Apa yang sebenarnya Anda bayar ketika memakai engineer?
Anda perlu mendapatkan pekerjaan yang hasilnya dapat diperiksa: kebutuhan yang jelas, keputusan teknis yang bisa dijelaskan, fungsi yang diuji, serta rencana pengelolaan. NIST SSDF menempatkan pengembangan aman sebagai praktik sepanjang proses pengembangan perangkat lunak. Menulis kode hanyalah salah satu bagiannya. NIST: Secure Software Development Framework.
Dalam pembahasan proyek bersama saya, kebutuhan bisnis menjadi dasar menentukan pekerjaan. Website custom berguna ketika cara menerima permintaan, menyetujui pekerjaan, atau mengelola informasi perlu mengikuti proses usaha Anda. Desain visual juga dapat diarahkan pada identitas usaha dan informasi yang dibutuhkan calon pelanggan untuk mengambil keputusan.
Sebelum menyepakati jasa, minta hasil kerja yang konkret: fungsi yang termasuk, batas integrasi, pemeriksaan sebelum terbit, dan penjelasan pengelolaan setelahnya.
Membayar engineer layak ketika ada pekerjaan, bukti hasil, dan tanggung jawab yang jelas.
Gelar profesi atau penggunaan alat tertentu saja tidak menjamin kualitas.
Pendampingan dapat memakai AI sebagai alat bantu sambil mempertahankan penilaian manusia. Bila kebutuhan Anda cukup ditangani platform siap pakai atau perbaikan kecil, pilihan tersebut juga perlu dipertimbangkan. Pembangunan ulang harus mempunyai alasan yang dapat dijelaskan.
Bandingkan biaya sampai website bisa dikelola
Saat membandingkan penawaran, hitung pembuatan awal, waktu pengelolaan, domain, hosting, lisensi, layanan berbayar, dan kebutuhan perubahan. Besarnya bergantung pada rancangan serta pemakaian. Hindari menganggap semua biaya tersebut sudah termasuk hanya karena tertulis paket website.
Saya membahas lingkup, biaya, dan jadwal sebelum pengerjaan. Dukungan lanjutan, waktu respons, dan pekerjaan tambahan mengikuti kesepakatan; tidak semua proyek mencakup pemantauan sepanjang waktu. Akses data, akun, dokumentasi, serta hak penggunaan perlu dijelaskan. Penyerahan kode sumber tidak otomatis termasuk dan bergantung pada penawaran serta lisensi yang berlaku.
Tujuannya agar Anda memahami apa yang dikerjakan dan ke mana meminta bantuan. Pengujian serta perawatan dapat mengurangi risiko, tetapi tidak menjamin website bebas gangguan selamanya atau pasti mencapai peringkat pencarian tertentu.
Jika Anda sudah mencoba membuat website dengan AI, bawalah hasilnya ke pembahasan. Kita dapat mulai dari fungsi yang paling penting bagi usaha, menilai bagian yang perlu diperiksa, lalu menentukan lingkup bantuan yang masuk akal.
Pertanyaan yang sering diajukan
Apakah membuat website sendiri pakai AI selalu berbahaya?
Tidak. Risikonya bergantung pada fungsi, data, akses, komponen, dan pengelolaannya. Halaman informasi sederhana berbeda dari aplikasi dengan akun pelanggan atau integrasi penting. Yang perlu dinilai adalah hasil serta proses pemeriksaannya, termasuk bila kode ditulis manusia.
Apa perbedaan AI website builder dan jasa engineer?
Pembuat website membantu menghasilkan halaman atau fungsi melalui alat dan fitur yang tersedia. Jasa engineer dapat mencakup penerjemahan kebutuhan bisnis, peninjauan rancangan, pengujian, integrasi, dan pengelolaan teknis. Isi pekerjaan serta dukungannya tetap harus diperiksa dalam penawaran, karena tiap layanan berbeda.
Apakah saya harus membuang website yang sudah dibuat dengan AI?
Keputusan itu perlu mengikuti kondisi website. Hasil yang ada dapat dipakai untuk membahas tujuan, fungsi yang belum berjalan, dan bagian yang membutuhkan pemeriksaan. Pembangunan ulang baru layak dipilih jika ada alasan yang lebih kuat daripada perbaikan terbatas.
Apakah website buatan AI otomatis buruk untuk SEO?
Cara kode dibuat saja tidak menentukan kelayakan halaman untuk pencarian. Periksa akses perayap, respons halaman, konten yang dapat diindeks, struktur, dan kegunaan isinya. Memenuhi persyaratan teknis tidak menjamin indeks atau peringkat tertentu.
Apakah biaya engineer sudah mencakup maintenance dan kode sumber?
Cakupannya mengikuti penawaran. Pastikan biaya awal, layanan berulang, dukungan, waktu respons, akses, dokumentasi, serta ketentuan kode sumber dijelaskan. Penyerahan kode sumber tidak otomatis termasuk dan dapat bergantung pada lisensi atau kesepakatan terpisah.
Bagaimana memulai pembahasan dengan Dicky Ibrohim?
Sampaikan tujuan bisnis, fungsi yang Anda perlukan, dan URL atau gambaran hasil yang sudah ada. Sebutkan kendala serta kemampuan pengelolaan Anda. Informasi awal tersebut membantu membahas lingkup bantuan; jangan mengirim kata sandi atau data pribadi pelanggan melalui pesan pembuka.
