18.5 Security dan Reliability sebagai Desain Awal
Bayangkan Anda telah membangun sistem pemesanan tiket dengan modul-modul yang rapi, API yang jelas, dan data yang terkelola dengan baik. Kemudian Anda memberikan akses kepada AI untuk membantu mengembangkan fitur baru. Semua terlihat aman karena data sudah memiliki schema dan ownership. Tapi apakah itu cukup?
Suatu hari, AI yang Anda tugaskan untuk menambahkan fitur “pengembalian tiket” secara tidak sengaja membuat endpoint baru yang bisa diakses tanpa verifikasi identitas. Karena tidak ada pembatasan akses, siapa pun bisa memanggil endpoint itu dan membatalkan tiket orang lain. Bukan karena AI jahat, tetapi karena Anda tidak memberi tahu AI tentang siapa yang boleh melakukan apa.
Inilah masalahnya: security dan reliability sering dianggap sebagai lapisan yang bisa ditambahkan belakangan. Pasang firewall, tambahkan autentikasi, pasang monitoring. Tapi ketika AI mulai memodifikasi sistem, pendekatan tambal sulam tidak akan berfungsi. AI akan membaca kode yang ada, melihat pola yang longgar, dan mengulangi pola yang sama.
Diagram berikut menunjukkan bagaimana mekanisme security dan reliability harus terintegrasi sejak awal pada setiap modul, bukan ditambahkan setelah sistem berjalan.
Arsitektur yang baik sejak awal harus menentukan identitas dan izin. Setiap modul harus tahu siapa yang boleh memanggilnya, data apa yang boleh diakses, dan tindakan apa yang diizinkan. Bukan hanya untuk pengguna manusia, tetapi juga untuk modul lain dan untuk AI yang memodifikasi sistem. Jika Anda tidak mendefinisikan ini di arsitektur, AI akan membuat asumsinya sendiri, dan asumsi itu mungkin salah.
Reliability memiliki masalah serupa. Bayangkan AI menambahkan fitur yang memanggil layanan pembayaran eksternal. Tanpa mekanisme timeout yang jelas, panggilan itu bisa menggantung selamanya. Tanpa circuit breaker, satu kegagalan bisa merambat ke seluruh sistem. Tanpa jalur cadangan, pengguna hanya melihat layar kosong saat terjadi kesalahan.
Ini bukan soal menulis kode yang kuat. Ini soal arsitektur yang menyediakan mekanisme kegagalan yang terdefinisi. Setiap panggilan antar modul harus memiliki batas waktu. Setiap integrasi eksternal harus memiliki pola jalur cadangan. Setiap kegagalan harus meninggalkan jejak yang bisa dilacak.
Audit trail juga menjadi bagian dari desain awal. Ketika AI memodifikasi data, Anda perlu tahu apa yang diubah, oleh siapa, dan kapan. Bukan karena Anda tidak percaya pada AI, tetapi karena Anda perlu verifikasi. Tanpa audit, Anda tidak bisa membedakan antara perubahan yang sah dan perubahan yang merusak.
Observability bukan alat debugging yang dipasang setelah sistem jalan. Observability adalah bagian dari arsitektur: log yang terstruktur, metrik yang terdefinisi, dan tracing yang melintasi modul. Ketika AI menambahkan fitur baru, Anda harus bisa melihat dampaknya tanpa harus membaca semua kode.
Semua ini terdengar seperti beban tambahan. Tapi justru sebaliknya: ketika security dan reliability sudah menjadi bagian dari arsitektur, AI menjadi lebih mudah diberi konteks. Anda bisa memberi tahu AI: “Setiap endpoint harus memiliki pemeriksaan identitas. Setiap panggilan eksternal harus memiliki timeout lima detik. Setiap perubahan data harus dicatat.” AI tidak perlu menebak-nebak.
Dan ketika AI tidak perlu menebak, risiko berkurang. Sistem menjadi lebih aman bukan karena Anda memasang pagar setelahnya, tetapi karena pagar sudah ada sejak pondasi dibangun.
Setelah arsitektur memiliki batasan yang jelas, modul yang terpisah, API yang terikat kontrak, data yang terkelola, dan mekanisme keamanan serta keandalan yang terdefinisi, pertanyaan berikutnya adalah: bagaimana Anda terus merapikan sistem ini tanpa harus memulai dari awal? Di situlah refactor menjadi investasi, bukan sekadar bersih-bersih.
