ดาต้าเซ็นเตอร์ล่ม ประกันภัยจ่ายหรือไม่

ถอดรหัสความคุ้มครอง เงื่อนไขการเคลม และความเสี่ยงสะสมของอุตสาหกรรมดิจิทัล

ระบบหยุด..ไม่ได้แปลว่ากรมธรรม์ต้องจ่าย

เมื่อดาต้าเซ็นเตอร์หยุดทำงาน เหตุเดียวอาจสร้างความเสียหายต่อทรัพย์สิน ทำให้ธุรกิจหยุดชะงัก กระทบข้อมูล และก่อความรับผิดต่อผู้ใช้บริการหลายรายพร้อมกัน แต่คำว่า “ระบบล่ม” ยังไม่เพียงพอสำหรับสรุปความคุ้มครอง บริษัทประกันภัยต้องไล่จากสาเหตุ ผู้มีส่วนได้เสียในทรัพย์สินหรือบริการ ประเภทความเสียหาย เงื่อนไขกรมธรรม์ และหลักฐานที่เชื่อมเหตุไปสู่จำนวนเงินที่เรียกร้อง

บทความตอนที่ 2 จึงมองดาต้าเซ็นเตอร์เป็นทั้งความเสี่ยงรายกรมธรรม์และความเสี่ยงสะสมในพอร์ต โดยเชื่อมงานวิศวกรรม ไซเบอร์ สัญญา การเงิน และประกันภัยต่อเข้าด้วยกัน ตัวอย่างตัวเลขทั้งหมดเป็นสมมติฐานเพื่ออธิบายวิธีคิด ไม่ใช่การรับรองว่าจะจ่ายค่าสินไหมในเหตุจริง

ผู้ตัดสินใจแต่ละฝ่ายต้องเห็นข้อมูลชุดเดียวกัน

เหตุเดียวอาจกระทบหลายความคุ้มครอง

โปรแกรมประกันภัยของดาต้าเซ็นเตอร์มักต้องเชื่อมทรัพย์สิน เครื่องจักร ธุรกิจหยุดชะงัก ไซเบอร์ ความรับผิด งานก่อสร้าง และความคุ้มครองตามตัวชี้วัด แนวทางของ Alliant แสดงการจัดประกันตลอดวงจรโครงการ ตั้งแต่ก่อสร้าง เริ่มดำเนินงาน ไปจนถึงความเสี่ยงระหว่างให้บริการ [6] Alliant เป็นนายหน้าประกันภัย จึงใช้เป็นกรอบจัดโปรแกรม มิใช่ถ้อยคำกรมธรรม์เดียวที่รับรองทุกเหตุ

AI Data Centre เพิ่มความเข้มข้นของมูลค่าและการพึ่งพาไฟฟ้า ความเย็น และอุปกรณ์เฉพาะทาง Swiss Re Institute อธิบายว่าการกระจุกตัวของอุปกรณ์มูลค่าสูงและโครงสร้างพื้นฐานร่วมอาจทำให้ความเสียหายขยายตัว [2] บริษัทประกันภัยจึงต้องประเมินทั้ง severity ของสถานที่เดียวและ accumulation จากลูกค้าหลายรายที่พึ่งระบบเดียวกัน
 

ภาพนี้เป็นกรอบสนทนาระหว่างผู้เอาประกัน นายหน้า และบริษัทประกันภัย สิทธิจริงขึ้นกับผู้เอาประกันที่ระบุ นิยามเหตุคุ้มครอง ข้อยกเว้น ระยะรอ วงเงินย่อย ระยะชดใช้ และเอกสารแนบท้ายของแต่ละกรมธรรม์

วางสถาปัตยกรรมความคุ้มครองตามลักษณะความเสียหาย

หลักคิดสำคัญในการรับประกันภัย

• แยกเจ้าของอาคาร อุปกรณ์ ข้อมูล และรายได้ให้ชัด เพราะผู้เสียหายแต่ละรายอาจอยู่คนละกรมธรรม์
• ทดสอบจุดพึ่งพาร่วม เช่น สถานีไฟฟ้า เส้นใยสื่อสาร ระบบยืนยันตัวตน cloud region และทีมปฏิบัติการ
• ประเมิน replacement cost ระยะหาอะไหล่ ความเข้ากันได้ของอุปกรณ์ และเวลาทดสอบก่อนเปิดบริการ
• เทียบภาระใน SLA และสัญญาลูกค้ากับสิ่งที่กรมธรรม์ยอมรับ โดยไม่สมมติว่าเครดิต SLA คือความเสียหายที่คุ้มครองเสมอ
• กำหนด sublimit waiting period indemnity period และผู้เชี่ยวชาญที่อนุมัติล่วงหน้าให้สอดคล้องกับเวลาฟื้นจริง

แบบจำลอง Indemnity ต้องพิสูจน์ความเสียหายจริง

การชดใช้แบบ Indemnity เริ่มจากรายการความเสียหายที่เข้าเงื่อนไข หักค่าใช้จ่ายที่ประหยัดได้ เงินหรือเครดิตที่ต้องนำมาหัก และค่าเสียหายส่วนแรก จากนั้นใช้วงเงินย่อยและวงเงินรวมตามลำดับในกรมธรรม์ สำหรับ BI ต้องพิสูจน์ผลทางการเงินและระยะหยุดที่สัมพันธ์กับเหตุ มิใช่นำรายได้ทั้งหมดคูณจำนวนวันหยุดโดยตรง

ตัวอย่างสมมติระบบความเย็นเสียและบริการหยุดสามวัน

สมมติว่าลูกค้าเสียกำไร 5 ล้านบาทและได้รับเครดิต SLA 2 ล้านบาท ลูกค้าไม่ได้รับ 5 ล้านบาทจากกรมธรรม์ของผู้ให้บริการโดยอัตโนมัติ ต้องประเมินกรมธรรม์ของลูกค้าและสิทธิเรียกร้องตามสัญญาแยกกัน ส่วนเครดิต SLA จะนำมาหักหรือไม่ขึ้นกับถ้อยคำกรมธรรม์และธรรมชาติของรายการความเสียหาย

แบบจำลอง Parametric จ่ายตาม Trigger ที่ตกลง

สมมติสัญญากำหนด outage ของบริการและพื้นที่ที่ระบุ จ่าย 0.1 ล้านบาทต่อชั่วโมงเฉพาะเวลาที่เกิน threshold 4 ชั่วโมง เพดาน 2 ล้านบาท หากระบบตรวจวัดยืนยัน outage 12 ชั่วโมง เงินจ่ายตามสูตรเท่ากับ (12 − 4) × 0.1 = 0.8 ล้านบาท แม้ความเสียหายจริงอาจสูงหรือต่ำกว่า หากระบบภายในลูกค้าล่มแต่บริการที่ระบุไม่เข้า Trigger อาจไม่มีเงินจ่าย

ตัวอย่างโมเดลต่างประเทศใช้เป็นกรอบ ไม่ใช่คำรับรองความคุ้มครอง

ตลาดต่างประเทศมีทั้งการจัดโปรแกรมแบบครบวงจร ความคุ้มครองช่องว่างค่าเสียหายตามสัญญา และประกันคลาวด์ล่มที่จ่ายตามตัวชี้วัด ตัวอย่างเหล่านี้ช่วยให้เห็นกลไกการโอนความเสี่ยง แต่ไม่ได้ยืนยันว่าผลิตภัณฑ์เดียวกันมีจำหน่ายในประเทศไทย หรือเหตุสมมติในบทความจะได้รับค่าสินไหม

 
Alliant เสนอกรอบจัดประกันตามวงจรโครงการ [6] Munich Re อธิบาย LD Gap Cover สำหรับช่องว่างค่าเสียหายตามสัญญาในโครงการดาต้าเซ็นเตอร์ โดยพิจารณาสัญญาและความเสี่ยงโครงการ [3] Parametrix เผยแพร่ Cloud Outage Insurance ที่อาศัยการตรวจวัดบริการที่ระบุและ Trigger ล่วงหน้า [7] ขณะที่ Swiss Re Corporate Solutions ให้ข้อเสนอด้านวิศวกรรมเพื่อลดความเสี่ยงไฟไหม้และการหยุด 

ความเสี่ยงสะสมต้องมองข้ามรายกรมธรรม์

บริษัทประกันภัยอาจมีความเสี่ยงสองชั้นพร้อมกัน ชั้นแรกคือระบบดาต้าเซ็นเตอร์หรือคลาวด์ที่บริษัทใช้ดำเนินธุรกิจของตน ชั้นที่สองคือพอร์ตผู้เอาประกันจำนวนมากที่พึ่งผู้ให้บริการหรือโครงสร้างพื้นฐานเดียวกัน รายงาน Cloud Down ของ Lloyd’s ใช้สถานการณ์จำลองเพื่อแสดงว่าคลาวด์ล่มสามารถกระทบหลายอุตสาหกรรมพร้อมกัน [1] จึงควรจัดทำมุมมอง accumulation ที่เชื่อม Property BI Cyber Liability และ Supply Chain เข้าด้วยกัน

กระบวนการเคลมที่ลดความล่าช้าและข้อพิพาท

1. แจ้งเหตุและรักษาหลักฐาน กำหนดเวลาอ้างอิง ผู้บัญชาการเหตุ ผู้ดูแลหลักฐาน และผู้ประสานบริษัทประกันภัย
2. พิสูจน์สาเหตุและลำดับเหตุ เชื่อมข้อมูลไฟฟ้า ความเย็น Log การเปลี่ยนแปลง ภาพหน้างาน และรายงานผู้เชี่ยวชาญ
3. แยกความเสียหาย ทรัพย์สิน BI Extra Expense Data Restoration Response และ Liability โดยไม่ซ้ำกัน
4. ตรวจการลดความเสียหาย บันทึกเหตุผลและการอนุมัติค่าใช้จ่ายฉุกเฉิน พร้อมเปรียบเทียบกับ BI ที่หลีกเลี่ยงได้
5. คำนวณและหักรายการเกี่ยวข้อง Deductible waiting period saved expense SLA credit sublimit aggregate และเงินชดเชยอื่น
6. ตกลงชดใช้และแก้ต้นเหตุ ระบุส่วนที่ยอมรับ ส่วนที่ยังต้องพิสูจน์ สิทธิไล่เบี้ย และการปรับปรุงเงื่อนไขครั้งต่อไป

ข้อเสนอสำหรับบริษัทประกันภัยและผู้บริหารความเสี่ยง

1. จัดทำ Data Centre Exposure Register ที่ระบุผู้ให้บริการ สถานที่ cloud region utility carrier และผู้ให้บริการเทคโนโลยีร่วมของผู้เอาประกัน
2. ใช้ทีมร่วมระหว่างวิศวกรรม ไซเบอร์ BI Liability Claims และ Reinsurance ตั้งแต่การรับประกันภัย ไม่รอจนเกิดเหตุ
3. ทดสอบสองสถานการณ์คู่กันเสมอ คือ physical damage ที่ทำให้ BI และ non damage outage ที่กระทบลูกค้าหลายราย
4. กำหนด Trigger waiting period sublimit indemnity period และหลักฐานที่ต้องใช้ให้สอดคล้องกันระหว่างกรมธรรม์หลัก เอกสารแนบท้าย และประกันภัยต่อ
5. เทียบภาระ SLA และ contractual liability กับความคุ้มครองจริง พร้อมระบุส่วนที่องค์กรต้องรับเองอย่างโปร่งใส
6. ซ้อม Tabletop ร่วมกับผู้เอาประกัน นายหน้า ผู้ประเมินสินไหม ผู้เชี่ยวชาญดิจิทัล และผู้รับประกันภัยต่อ เพื่อทดสอบการตัดสินใจและเอกสาร

คำถามที่คณะกรรมการและผู้บริหารควรได้รับคำตอบ

• เหตุเดียวที่รุนแรงที่สุดอาจกระทบผู้เอาประกันกี่ราย และยอดความเสียหาย gross กับ net ต่างกันเท่าใด
• จุดพึ่งพาร่วมที่สำคัญที่สุดอยู่ที่ไฟฟ้า ความเย็น เครือข่าย คลาวด์ Identity หรือบุคลากร
• กรมธรรม์ใดตอบสนองก่อน และมีช่องว่างหรือการซ้อนทับระหว่าง Property Cyber และ Liability หรือไม่
• ข้อมูลที่มีอยู่เพียงพอจะพิสูจน์สาเหตุ ระยะหยุด และผลเสียหายทางการเงินหรือไม่
• ผลทดสอบระบบสำรองและแผนฟื้นฟูยืนยันเวลาฟื้นจริง หรือเป็นเพียงเอกสารรับรอง

บทสรุป

คำตอบว่า “ประกันภัยจ่ายหรือไม่” ไม่ได้อยู่ที่ชื่อกรมธรรม์ แต่อยู่ที่ความสอดคล้องระหว่างเหตุ ผู้เอาประกัน ประเภทความเสียหาย Trigger และหลักฐาน โปรแกรมที่ดีต้องเชื่อมความคุ้มครองหลายชั้น ควบคุมช่องว่างจากสัญญา และมองเห็นความเสี่ยงสะสมทั้งพอร์ต ก่อนเกิดเหตุจริง

แหล่งอ้างอิง
[1] Lloyd’s และ AIR Worldwide, Cloud Down, 2018
[2] Swiss Re Institute, Insuring AI Data Centre Value Accumulation Risks, 2026
[3] Munich Re, Liquidated Damages Cover for Data Center Projects
[4] Lloyd’s, Business Interruption Insurance and Parametrix, 2020
[5] CISA, StopRansomware Guide
[6] Alliant, Data Center Insurance and Risk Management Solutions
[7] Parametrix, Cloud Outage Insurance
[8] Swiss Re Corporate Solutions, Data Centres Reducing Fire and Operational Risks