AI & Polisi Siber: Lindungi Perniagaan dari Outage Awan

Gangguan perkhidmatan awan (cloud outage) bukan lagi isu “IT semata-mata”. Bila platform besar seperti AWS atau Microsoft Azure tergendala, operasi bisnes boleh terhenti serentak—tempahan penerbangan tak boleh diproses, transaksi bank tersangkut, sistem hospital lambat, dan rantaian runcit gagal menyegerakkan inventori. Akhir 2025, beberapa insiden gangguan awan dan gangguan berkaitan ekosistem Windows/Microsoft menghidupkan semula perbincangan yang ramai pengurus risiko cuba elak: adakah polisi insurans siber kita betul-betul melindungi kerugian akibat kegagalan awan?

Bagi saya, ini titik perubahan yang jelas untuk siri “AI dalam Insurans dan Pengurusan Risiko”. Realitinya, risiko awan ialah risiko sistemik—banyak syarikat “menumpang” pada infrastruktur yang sama. Bila satu jatuh, ramai jatuh sekali. Itu sebab pasaran insurans siber makin menekan isu seperti waiting period, pengecualian (exclusion), sublimit, dan definisi “penyedia perkhidmatan awan” dalam polisi.

Yang menarik: kita sebenarnya ada cara yang lebih praktikal untuk mengurus masalah ini—model risiko berasaskan AI yang menghubungkan data operasi, corak gangguan, dan terma polisi supaya jurang perlindungan boleh dikesan lebih awal, bukan selepas kerugian berlaku.

Kenapa cloud outage kini tekan pasaran insurans siber

Jawapan ringkasnya: kekerapan gangguan dan kesan serentak merentas industri menjadikan “jumlah kerugian” sukar diramal.

Apabila gangguan awan menjejaskan aplikasi yang digunakan oleh sektor penerbangan, perbankan, kesihatan dan peruncitan, ia mencipta situasi di mana:

• Banyak organisasi buat tuntutan pada masa yang sama.
• Punca gangguan kadang-kadang bukan serangan siber tradisional, tetapi kegagalan perisian/konfigurasi.
• Kerugian utama bukan semestinya “data bocor”, tetapi Business Interruption (BI) dan Contingent Business Interruption (CBI).

Di hujung 2025, penanggung insurans (carrier) semakin teliti terhadap 3 perkara:

1. Waiting period untuk BI/CBI (contoh: 8 jam, 12 jam, 24 jam) sebelum perlindungan bermula.
2. Exclusion berkaitan kegagalan infrastruktur / outage yang mungkin ditafsir ketat.
3. Definisi cloud service provider serta sublimit khas untuk gangguan awan.

“Waiting period” ialah perangkap paling kerap berlaku

Kalau operasi anda biasanya pulih dalam 6–10 jam, dan polisi hanya aktif selepas 12 jam, anda boleh mengalami kerugian besar tanpa pampasan.

Lebih memeritkan: bagi sesetengah bisnes (e-dagang, pembayaran, logistik), 3 jam pertama ialah tempoh paling mahal.

Risiko sistemik: bila semua orang berkongsi kelemahan yang sama

Jawapan paling jelas: awan mencipta kebergantungan bersama (shared dependency).

Dalam risiko tradisional, kebakaran kilang A tak semestinya menjejaskan kilang B. Dalam cloud outage, satu insiden boleh menyebabkan ribuan organisasi mengalami gangguan pada masa yang sama.

Inilah maksud “pendedahan sistemik” yang jadi tumpuan penanggung insurans:

• Konsentrasi vendor: terlalu banyak beban kerja bertumpu pada beberapa penyedia utama.
• Teknologi yang sama digunakan secara meluas: satu pepijat perisian boleh “merebak” kesannya.
• Rantaian aplikasi: walaupun syarikat anda tidak guna vendor X secara langsung, vendor SaaS anda mungkin guna vendor X.

Satu ayat yang saya suka gunakan dalam workshop risiko: “Anda mungkin ada pelan kesinambungan perniagaan, tapi vendor anda yang menentukan sama ada pelan itu realistik.”

Di sinilah AI paling berguna: menilai risiko outage secara dinamik

Jawapan praktikal: AI boleh menukar penilaian risiko daripada ‘sekali setahun’ kepada ‘hampir masa nyata’.

Dalam underwriting dan pengurusan risiko siber, AI boleh membantu pada tiga lapisan—data, ramalan, dan keputusan.

1) AI menggabungkan data yang biasanya ‘berpecah’

Kebanyakan organisasi simpan data risiko dalam silo:

• Log pemantauan (APM/observability)
• Laporan insiden dan post-mortem
• SLA dan kontrak vendor
• Rekod downtime aplikasi
• Data kewangan: hasil/jualan per jam, kos operasi, penalti SLA pelanggan

AI (terutama model ramalan + entity resolution) boleh menggabungkan semua ini untuk menghasilkan profil risiko outage yang lebih tepat: aplikasi mana paling kritikal, vendor mana paling berisiko, dan titik kegagalan mana paling mahal.

2) AI menganggarkan kerugian BI/CBI dengan lebih “boleh audit”

Penilaian BI sering jadi debat semasa tuntutan: berapa kerugian sebenar? apa yang “sepatutnya” berlaku jika tiada outage?

Model AI boleh membina baseline hasil dan trafik berdasarkan corak bermusim. Pada Disember, contohnya, banyak industri menghadapi:

• Lonjakan transaksi akhir tahun
• Kempen promosi dan cuti sekolah
• Penutupan akaun tahunan dan audit

Jadi outage pada 21/12/2025 (musim sibuk) tak sama nilainya dengan outage pada minggu biasa. AI boleh mengira kerugian per jam yang berbeza mengikut musim, bukan purata tahunan yang mengaburkan risiko.

3) AI mencadangkan struktur polisi yang lebih sesuai, bukan sekadar premium

Ini bahagian yang ramai terlepas. Fokus bukan hanya “dapatkan harga murah”, tapi “dapatkan terma yang selamat”. Dengan analitik AI, broker/insurer dan pembeli boleh berbincang berdasarkan bukti:

• Waiting period patut 8 jam atau 12 jam?
• Perlu sublimit cloud outage berapa?
• CBI perlu diperluas kepada vendor SaaS tertentu?
• Adakah definition of system failure dalam polisi selari dengan realiti seni bina anda?

Jurang perlindungan yang patut anda semak sekarang (sebelum renewal 2026)

Jawapan terus: semak terma polisi seperti anda semak firewall rules—teliti, berlapis, dan ada ujian.

Berpandukan tekanan pasaran yang dilaporkan (penanggung insurans menilai semula exclusion, sublimit, definisi cloud, dan threshold tempoh), berikut ialah senarai semak yang saya cadangkan untuk pasukan risiko/IT/Kewangan.

Semakan polisi siber: 10 item “wajib semak”

1. Adakah cloud outage dianggap “insiden” yang dilindungi? (atau dikategorikan sebagai kegagalan infrastruktur yang dikecualikan)
2. Waiting period untuk BI/CBI: 8/12/24 jam? Sejajar dengan purata masa pulih anda?
3. Sublimit untuk gangguan awan: adakah terlalu kecil berbanding kerugian per jam?
4. CBI: adakah meliputi vendor SaaS/managed service yang anda guna, bukan sekadar “cloud provider” utama?
5. Systemic risk / widespread event language: ada tak klausa yang mengehadkan pembayaran jika ramai terjejas serentak?
6. Definition of computer system / network: adakah termasuk beban kerja di awan dan komponen pihak ketiga?
7. Breach vs outage: polisi anda lebih kuat pada insiden kebocoran data berbanding downtime?
8. Kewajipan notifikasi: berapa cepat anda mesti maklumkan insurer untuk kekal layak?
9. Keperluan kawalan keselamatan (MFA, EDR, backup): adakah anda patuh sepenuhnya? Kegagalan patuh boleh menjejaskan tuntutan.
10. Bukti downtime: adakah proses anda mampu buktikan bila gangguan bermula/berakhir (ini kritikal untuk waiting period)?

Jika anda hanya boleh buat satu perkara minggu ini: padankan metrik downtime aplikasi dengan terma waiting period polisi. Jurang kecil di sini biasanya mahal.

Contoh senario: dua syarikat, outage yang sama, hasil tuntutan berbeza

Jawapan paling mudah difahami: terma polisi menentukan nasib anda, bukan hanya insiden itu sendiri.

Bayangkan dua syarikat runcit digital bersaiz sederhana, kedua-duanya bergantung kepada satu vendor awan dan satu platform pembayaran pihak ketiga.

• Syarikat A ada waiting period BI 12 jam, sublimit cloud outage kecil, CBI terhad.
• Syarikat B guna analitik AI untuk kira kerugian per jam musim hujung tahun, dan semasa renewal mereka runding waiting period 8 jam + perluasan CBI kepada vendor pembayaran kritikal.

Gangguan berlaku selama 10 jam pada minggu kemuncak jualan.

• Syarikat A: banyak kerugian “tak lepas waiting period”. Tuntutan tersangkut.
• Syarikat B: sebahagian besar kerugian layak dituntut kerana struktur polisi selari dengan realiti operasi.

Bezanya bukan siapa lebih “bernasib baik”. Bezanya siapa yang ukur risiko dengan betul dan terjemahkannya ke dalam bahasa polisi.

Cara mulakan program AI untuk risiko cloud—tanpa projek gergasi

Jawapan ringkas: mulakan kecil, tapi ukur dengan disiplin.

Ramai organisasi takut projek AI sebab fikir perlu 12 bulan dan kos besar. Untuk risiko cloud outage, saya lebih suka pendekatan 90 hari:

Pelan 90 hari (praktikal untuk pasukan risiko + IT)

1. Hari 1–14: Takrif “kritikal”

   • Senaraikan 10 aplikasi paling penting.
   • Tanda vendor bergantung (cloud, SaaS, pembayaran, CDN).

2. Hari 15–45: Bina data set minimum

   • Downtime per aplikasi (6–12 bulan).
   • Anggaran hasil/kos per jam.
   • SLA vendor dan penalti kepada pelanggan.

3. Hari 46–75: Modelkan kerugian

   • Baseline musim hujung tahun vs bulan biasa.
   • Simulasi senario 4 jam, 8 jam, 12 jam.

4. Hari 76–90: Terjemah kepada tindakan

   • Cadangan waiting period.
   • Cadangan sublimit.
   • Keutamaan mitigasi (multi-region, multi-cloud untuk komponen tertentu, pelan fallback pembayaran).

Output akhir bukan “dashboard cantik”. Output akhir ialah cadangan terma polisi + pelaburan mitigasi yang boleh dibawa ke mesyuarat renewal.

Apa yang saya jangka untuk 2026: underwriting siber makin ‘tegas’ pada cloud

Jawapan terus: 2026 akan memihak kepada organisasi yang boleh buktikan mereka faham pendedahan cloud mereka.

Pasaran komersial memang ada garis yang “lebih menyokong pembeli” untuk beberapa line termasuk siber, tetapi tekanan pada risiko sistemik tidak akan hilang. Penanggung insurans masih perlu memastikan kadar mencukupi dan pendedahan terkawal—lebih-lebih lagi bila kejadian outage besar boleh mencipta gelombang tuntutan serentak.

Bagi pembeli, strategi yang paling selamat ialah:

• Datang awal untuk renewal.
• Bawa bukti (data downtime, kerugian per jam, seni bina).
• Gunakan analitik AI untuk tunjuk anda bukan sekadar “minta limit tinggi”, tetapi faham risiko dan ada pelan kawalan.

Akhirnya, cloud outage memaksa satu disiplin baru: pengurusan risiko siber bukan lagi tentang “serangan” sahaja, tapi tentang “ketersediaan” (availability) sebagai aset kewangan.

Kalau anda sedang menilai semula insurans siber menjelang 2026, saya cadangkan mulakan dengan satu soalan yang mudah tapi tajam: adakah terma polisi kita sepadan dengan cara sistem kita benar-benar gagal?