銀行不解密資料就能讓雲端執行 AI 運算，該用什麼技術？

情境

先感受問題：把保險箱鑰匙留在家裡，讓人用保險箱

亞太銀行的 CTO 昭明要解決一個矛盾：

銀行有 200 萬客戶的信用交易資料，要用雲端 AI 做即時信用風險評估。雲端算力強、彈性好、成本低，但：

法規要求：客戶的原始交易資料不能暴露給第三方（雲端供應商）

業務需求：雲端 AI 模型必須能「跑」這些資料，輸出信用評分

傳統加密的困境：把資料加密後送到雲端，雲端要計算就必須先解密，解密後就看到原始資料了。加密的目的就失效了。

同態加密的突破：把資料加密後送到雲端，雲端直接在加密的「密文」上跑模型，輸出的是「加密的評分結果」，送回給銀行，銀行用自己的私鑰解密，得到最終的信用評分。整個過程中，雲端從未看到任何明文資料。

舊方法

傳統隱私保護方法為什麼不能滿足「雲端執行計算又不暴露資料」

1. 匿名化（Anonymization）的侷限：把姓名換成代碼、刪除生日，可以保護直接識別資訊，但雲端在跑模型時仍然需要接觸完整的交易金額、頻率、模式等敏感特徵。匿名化只移除了「能對應到誰」的資訊，不移除「用於計算」的特徵值，雲端仍能看到這些數字。
2. 雜湊（Hash）函數的不可計算性：雜湊是單向不可逆的，但問題是：雜湊後的值無法再做數學計算。把交易金額 5,000 元雜湊後得到一串亂碼，AI 模型看到這串亂碼完全無法計算信用風險。雜湊只適合「驗證身分」，不適合「計算特徵」。
3. 資料本地化（Data Localization）的矛盾：把計算限制在內部伺服器完全繞開了問題，放棄了雲端的所有優勢（彈性、算力、成本）。題目明確說要「部署至雲端平台」，資料本地化根本就不讓資料出去，答非所問。
4. 聯邦學習（Federated Learning）的侷限：聯邦學習讓模型在各客戶端本地訓練，只傳梯度，但需要多方各自有資料和計算能力，不適合「銀行資料集中、要上傳到雲端跑推論」的場景。
5. 差分隱私（Differential Privacy）的精度問題：差分隱私在計算結果中加入統計雜訊，信用風險評估對準確度要求高，加入雜訊會讓評分不準確，可能錯誤地批准或拒絕貸款申請。

新方法

同態加密讓雲端在密文上跑出正確的信用評分

亞太銀行的作法：

銀行在本地把客戶的交易特徵（金額、頻率、類別等）加密成密文，送到雲端 AI 平台。

雲端 AI 平台的信用風險模型直接在這些密文上做計算：乘上權重、加上偏差、通過激活函數，所有運算都在加密狀態下進行。雲端全程看到的是一堆「密文數字」，從未接觸原始的交易金額或客戶資訊。

雲端把「加密的評分結果」送回給銀行，銀行用自己保管的私鑰解密，得到：「這個客戶的信用評分是 720 分，建議審核通過」。

同態加密保證：在密文上做的計算，解密後的結果，和在原始明文上計算的結果完全相同。沒有任何精度損失，也沒有任何資料洩漏。

這就是選項 D 講的：透過同態加密（Homomorphic Encryption），讓雲端系統能直接在加密資料上執行運算，解密後結果與原始資料一致。

錯選項

為什麼其他選項是錯的

變形題

同個考點下次怎麼變形

延伸

想再往下看，這 5 個

• 同態加密（Homomorphic Encryption）
  核心考點，讓雲端在加密資料上直接計算、解密後結果一致的密碼學技術。
• 聯邦學習（Federated Learning）
  多方資料不出境、聯合訓練模型的隱私保護方法，與同態加密互補。
• 資料隱私（Data Privacy）
  金融和醫療 AI 的核心挑戰，同態加密是實現「計算隱私」的技術解法。
• 差分隱私（Differential Privacy）
  在統計輸出中加入雜訊保護個體，適合可接受誤差的統計分析，與同態加密解決不同問題。
• GDPR（歐盟通用資料保護規範）
  推動金融機構探索同態加密等隱私保護技術的重要法規背景。