西元 64 年，羅馬帝國因大火後的重建支出面臨財政壓力，尼祿皇帝決定降低銀幣的重量與含銀量。儘管外觀與面額不變，實際價值卻已下降。此後歷任皇帝陸續採取相同措施，長期累積的問題最終動搖了貨幣的信任基礎。
這段歷史揭示了一項值得企業警惕的風險：當既有機制長期被視為可靠，卻未經實際驗證，潛在問題便可能在不知不覺中持續累積。 企業的 AI 系統復原計畫同樣如此。沿用既有備份與復原機制，不代表就能滿足 AI 工作負載的特殊需求；唯有透過實際測試，才能確認系統是否真正具備復原能力。
AI 系統恢復與傳統資料庫復原有何不同？
傳統資料庫復原通常具有明確的驗證標準，包括資料筆數、參照完整性及最後一次成功提交的交易紀錄等。企業可透過這些指標，判斷資料是否已正確還原，整體驗證結果相對明確且可預測。
然而，AI 系統的恢復機制更為複雜。即使模型成功還原、檔案校驗碼完全一致，且載入過程未出現錯誤，仍可能產生與先前不同的輸出結果。原因在於，AI 系統的運作不僅取決於模型本身，更仰賴多項相互關聯的組成要素。
這些要素包括模型權重（weights），亦即模型在訓練過程中學習所得、用以記錄資料模式與關聯性並影響輸出結果的數值參數；此外，也涵蓋訓練或參考資料集、資料索引、系統設定、提示詞（prompts），以及各項元件之間的版本相容性。
因此，即使所有元件均已成功還原並通過個別驗證，若版本或復原時間點未能一致，AI 系統仍可能無法恢復預期行為。傳統備份與復原驗證所能確認的資料完整性，並不等同於 AI 系統的行為正確性。
戴爾科技委託 Omdia 進行的研究顯示，過去 12 個月有高達 80% 的企業曾遭遇 AI 相關資安事件。然而，僅有 8% 的受訪企業將 AI 模型與應用程式復原視為最主要的挑戰；在 AI 資安投資優先事項中，系統韌性與正常運作時間亦排名最後，僅占 18%。
這顯示企業目前的 AI 資安投資仍較側重事件預防與威脅偵測，對於事件發生後的系統恢復能力，則往往假設既有機制已足以因應。然而，當 AI 環境持續演進，復原準備卻未能同步提升時，企業便可能逐漸累積所謂的「韌性債務」（resilience debt），使潛在的營運風險隨時間擴大。
要降低這類風險，企業可從以下三個面向著手，無須全面重新設計既有 AI 架構。
一、盤點相依要素，確立復原順序
有效的 AI 復原計畫，必須建立在完整掌握系統組成與相依關係的基礎上。復原範圍不應僅限於模型本身，還須涵蓋模型權重與檢查點（checkpoints）、資料集與索引、系統設定、提示詞，以及各項元件的版本對應關係。
然而，許多企業在設定復原目標時便已面臨挑戰。根據戴爾科技的資安韌性研究，僅有 32% 的企業明確定義復原時間目標（Recovery Time Objective, RTO）與復原點目標（Recovery Point Objective, RPO）。隨著 AI 工作負載增加系統相依性與復原需求，相關挑戰將更加複雜。
因此，企業應先全面盤點 AI 工作負載及其相依要素，辨識維持基本業務運作所需的關鍵系統，再依據營運重要性設定復原優先順序與目標，讓復原規劃真正符合業務持續運作的需求。
二、以隔離備份保護關鍵資產
當攻擊者取得正式營運環境的存取憑證，便可能進一步存取備份資料，使備份同樣面臨遭竄改或破壞的風險。因此，企業應採用不可變更備份（immutable backups）與環境隔離機制，將具備版本紀錄的備份副本保存於受入侵憑證無法存取的獨立環境，確保資安事件發生時仍保有可靠的復原資產。
在 AI 環境中，應優先保護難以重建且直接影響模型行為的關鍵資產，包括微調後的模型權重與檢查點、提示詞、系統設定、安全防護規則，以及各項元件的版本對應紀錄。其中，版本對應資訊經常被忽略，卻是確保 AI 系統恢復原有運作行為的重要依據。
此外，企業應保留足夠的歷史備份版本，以便在發生異常時回溯至問題出現前的正常狀態。訓練資料同樣需要妥善保護，但不一定須存放於上述隔離備份環境中。
三、實際測試，驗證 AI 恢復能力
風險評估有助於企業掌握復原準備程度，情境模擬演練（tabletop exercise）則可確認相關人員是否熟悉應變流程。然而，兩者都無法證明系統在資安事件後能否真正恢復正常運作，唯有實際復原測試才能驗證系統的恢復能力。
對 AI 系統而言，測試不應止於確認模型與資料是否成功還原，更須將模型及相關資料部署至隔離環境，觀察實際運作表現是否符合預期。
從既有假設走向實際驗證，降低 AI 韌性債務
AI 系統的韌性風險往往不會立即顯現。當企業持續沿用未經充分驗證的復原機制，風險便可能隨時間累積，直到真正需要恢復系統時，才發現既有能力與實際需求存在落差。
韌性債務的關鍵風險，在於企業可能尚未確認系統能否有效復原，就已將營運持續性建立在這項假設之上。 隨著 AI 逐步深入核心營運，企業應及早辨識復原準備的缺口，透過實際測試確認系統恢復能力，避免潛在風險在資安事件發生時轉化為營運衝擊。
＜本文作者：廖仁祥現為台灣戴爾科技集團總經理＞