AI 模型安全：模型竊取、逆向工程與防護策略

為什麼模型本身需要保護

訓練一個 AI 模型要花大量的運算資源、資料和時間。以一個中型的語言模型為例，訓練一次的 GPU 運算費用可能在數十萬到數百萬美元之間，更不用說收集和清洗訓練資料所投入的人力。對企業來說，模型就是智慧財產，它的價值等同於數年的研發成果。如果模型被竊取或逆向工程，等於競爭對手用極低的成本拿到了你花鉅資開發的技術。

除了商業損失，模型安全還牽涉到隱私問題。模型可能記住訓練資料中的個人資訊，攻擊者透過特定的查詢方式就能把這些資料「問」出來。這在醫療、金融和法律領域尤其敏感，因為這些領域的訓練資料往往包含高度機密的個人資訊。例如用病歷資料訓練的診斷模型，如果被攻擊者透過反覆查詢提取出原始病歷的片段，這就是嚴重的個資外洩。

飛飛在做 AI 安全評估時，發現很多團隊保護了 API Key 和資料庫，卻忽略了模型本身的安全。他們會花大量時間設定防火牆和加密傳輸，但模型檔案卻直接放在沒有存取控制的 S3 bucket 裡，或者 API 回傳了過多的模型內部資訊。這種「重基礎設施、輕模型」的安全觀念需要更新。以下整理四種主要的模型攻擊方式和對應的防護。

模型竊取攻擊（Model Extraction）

模型竊取是最常見的模型攻擊方式。攻擊者透過大量查詢目標模型的 API，收集輸入和輸出的配對，然後用這些資料訓練一個功能相似的「影子模型」。這個影子模型雖然架構可能和原始模型不同，但在特定任務上的行為和表現會非常接近。

攻擊流程通常分為四個階段：

1. 攻擊者準備一批精心設計的輸入資料，這些資料通常涵蓋了目標模型的主要使用場景
2. 透過 API 發送查詢，收集模型的輸出（包含機率分佈或 logits）
3. 用收集到的輸入-輸出配對訓練一個本地模型，這個過程類似知識蒸餾（Knowledge Distillation）
4. 影子模型在特定任務上能達到原始模型 80-95% 的準確度

這種攻擊不需要知道原始模型的架構或訓練資料，只需要能夠呼叫 API。攻擊者甚至不需要有機器學習的深厚背景，因為許多開源框架已經提供了現成的蒸餾工具。對於分類模型，攻擊者只需要數千到數萬次查詢就能建立一個有效的影子模型。對於生成式模型，需要的查詢量更大，但隨著攻擊技術的進步，所需的查詢量也在持續降低。

真實案例：2020 年的研究論文展示了用不到 10 萬次查詢就能竊取 BERT 模型的分類能力，查詢成本約 300 美元。2024 年的後續研究進一步降低了所需的查詢量，用更聰明的主動學習（Active Learning）策略選擇查詢樣本，只需要原來三分之一的查詢就能達到類似的竊取效果。在台灣，已經有資安研究團隊在學術研討會上展示了對本土金融風控模型的竊取攻擊概念驗證。

模型竊取的防護措施

API 速率限制：對單一使用者或 API Key 設定每分鐘、每天的查詢上限。這個限制需要根據正常業務使用量來設計，太寬鬆等於沒有，太嚴格會影響正常使用。建議設定多層級的限速——每分鐘 60 次、每小時 1,000 次、每天 10,000 次，超過任何一個閾值就暫時封鎖並觸發警報。

輸出資訊最小化：這是最有效的防護之一。不要回傳 logits 或機率分佈。分類任務只回傳 Top-1 結果，不要附帶信心分數。生成任務不要回傳 token 層級的機率。如果業務上確實需要提供信心分數，考慮做粗粒度的分級（高/中/低）取代精確的浮點數值，或者加入適量的隨機雜訊。回傳越少的模型內部資訊，攻擊者可利用的資料就越少。

查詢異常偵測：監控 API 使用模式。正常使用者的查詢分佈通常有明確的業務特徵——例如客服系統的查詢集中在工作時間、內容跟產品相關。模型竊取的查詢則會呈現系統性的探測模式，例如大量隨機或對抗性輸入、查詢內容缺乏業務意義、查詢速率非常穩定（像機器人而非人類的行為模式）。可以用簡單的統計方法（查詢內容的熵值分析、時間間隔分析）來偵測異常。

使用者行為分析（UEBA）：更進階的做法是建立每個 API 使用者的行為基線——平常查詢什麼類型的問題、查詢頻率、查詢時段。當某個使用者的行為突然偏離基線（例如一個平常每天查詢 50 次的使用者突然開始每天查詢 5,000 次），立即觸發警報和臨時限速。

模型反轉攻擊（Model Inversion）

模型反轉攻擊的目標跟模型竊取不同。模型竊取想要複製模型的功能，模型反轉想要取得訓練資料中的敏感資訊。攻擊者利用模型的輸出來推斷訓練資料中的隱私內容，相當於從模型的行為反向推導出它曾經「見過」的資料。

攻擊原理可以用人臉辨識模型來說明。如果一個人臉辨識模型在看到某個人的照片時信心特別高，攻擊者可以透過最佳化演算法，反向生成一張讓模型輸出高信心的影像。具體做法是從一張隨機影像開始，反覆調整像素值讓模型的信心分數持續上升，經過數千次迭代後，這張影像會逐漸接近訓練資料中那個人的真實長相。2023 年的研究已經展示了在現代深度學習模型上，重建出的人臉影像足以讓人辨認出身份。

對語言模型的威脅也很顯著。雖然對 LLM 做模型反轉比影像模型困難，但如果 Fine-tune 的資料包含特定格式的個資（例如「客戶張小明的電話是 0912-345-678」），攻擊者可能透過特定的 Prompt 模式把這些資料「釣」出來。研究者發現，GPT 級別的語言模型可以在特定條件下重現訓練資料中的電話號碼、email 地址、甚至程式碼片段。對企業來說，這意味著用內部資料微調模型時要格外謹慎。

在台灣金融業的情境中，如果銀行用客戶交易資料微調了一個風險評估模型，攻擊者理論上可以透過模型反轉取得部分客戶的交易模式或財務資訊。雖然實際攻擊的難度仍然很高，但隨著攻擊技術的進步和模型規模的增大，這個風險正在增加。

模型反轉的防護措施

差分隱私（Differential Privacy）：在訓練過程中加入數學上可證明的隱私保護。具體做法是在梯度更新的過程中加入校準過的高斯雜訊，讓模型無法精確記住任何單一訓練樣本的資訊。差分隱私有一個隱私預算參數 ε（epsilon），ε 越小隱私保護越強，但模型準確度也越低。在實務上，ε 值通常設在 1-10 之間，需要根據資料敏感度和模型效能需求來取捨。代價是模型準確度會略為下降，對大型語言模型來說計算成本也會顯著增加。

資料去識別化：訓練前移除或替換個資。電話號碼、身分證字號、地址、姓名等敏感欄位應該在資料前處理階段就處理掉。常見的做法包括：用假名取代真名、用隨機數字取代真實號碼、用通用標記（如 [PHONE]、[ADDRESS]）取代敏感欄位。在台灣，依照個資法的規定，可識別個人的資料在用於 AI 訓練前應進行適當的去識別化處理。

Fine-tune 資料審核：如果要微調模型，確認訓練資料中沒有不該出現的個人資料或商業機密。建立一個審核流程——在資料進入訓練流程之前，用自動化工具掃描常見的個資格式（台灣身分證字號的格式、手機號碼的格式、email 地址等），再加上人工抽樣審查。這個步驟聽起來基本，但在飛飛的稽核經驗中，超過半數的企業微調專案跳過了這一步。

聯邦學習（Federated Learning）：讓資料留在各個機構的本地環境中，只交換模型更新（梯度），不交換原始資料。這對台灣的醫療和金融業特別有價值，因為這些行業的資料往往受到嚴格的監管，無法集中到單一地點訓練。聯邦學習搭配差分隱私可以提供更強的保護，但技術實作的複雜度也更高。

成員推論攻擊（Membership Inference）

成員推論攻擊的目標是判斷某筆特定的資料是否曾經被用來訓練模型。這種攻擊的危害看起來比模型竊取或反轉小，但在某些場景下後果非常嚴重。

攻擊原理基於一個觀察：模型對訓練資料中見過的樣本和沒見過的樣本，回應方式有微妙的差異。見過的資料通常會得到更高的信心分數和更低的困惑度（perplexity），因為模型在訓練過程中已經「記住」了這些資料的模式。攻擊者可以利用這個差異做判斷——如果某筆資料得到異常高的信心分數，很可能就是訓練資料的一部分。

具體的攻擊流程通常是這樣的：攻擊者準備一批資料，其中一部分是已知在訓練集中的（可以是從公開來源獲得的），一部分是確定不在訓練集中的。用這些資料訓練一個二元分類器（成員 / 非成員），學習模型輸出中區分兩者的特徵。然後用這個分類器去判斷攻擊者感興趣的資料是否在訓練集中。

為什麼這很危險：如果有人能證明某個病人的病歷資料被用來訓練某個 AI 模型，而這個訓練沒有經過病人同意，這在法律上就是個資侵害。在台灣，依照個資法第 19 條和第 20 條，非公務機關利用個人資料必須在特定範圍內，且應與蒐集目的相符。如果企業未取得資料當事人的同意就將其個資用於 AI 訓練，且被成員推論攻擊證實，企業可能面臨個資法的罰則和民事賠償責任。

在學術研究的場景中，成員推論攻擊也被用來驗證資料集的建構是否符合倫理規範。例如檢查某個公開的語言模型是否使用了未經授權的受版權保護內容來訓練，這在 AI 著作權爭議中是一個重要的技術工具。

成員推論的防護措施

溫度調整（Temperature Scaling）：對模型輸出的信心分數做校準，減少過度自信的情況。過擬合的模型會對訓練資料給出異常高的信心分數，校準後信心分數的分佈會更平均，降低攻擊者可利用的差異。溫度參數 T 通常設在 1.0-2.0 之間，T 越大輸出的分佈越平坦。

正則化（Regularization）：訓練時使用 dropout、weight decay 等技術，減少模型對單一訓練樣本的記憶。正則化讓模型學習更泛化的規律，降低對個別樣本的記憶程度。L2 正則化（weight decay）在大多數框架中都有內建支援，dropout 率通常設在 0.1-0.5 之間。這些技巧除了防止成員推論攻擊，也有助於改善模型的泛化能力，可以說是一舉兩得。

輸出擾動：在回傳結果前加入微小的隨機雜訊，讓攻擊者無法精確判斷信心差異。雜訊的量級需要精心設計——太大會影響模型的實用性，太小則無法有效防禦。一種做法是對每次查詢的輸出信心分數加上標準差為 0.01-0.05 的高斯雜訊，這個量級通常不會影響業務決策，但足以干擾成員推論的判斷。

資料增強和混洗：在訓練階段對資料進行增強（例如同義詞替換、句子重組），讓模型看到的不是原始資料本身，而是經過變換的版本。這讓攻擊者即使用原始資料做成員推論，也會因為模型實際上「看到」的是變換版本而得到不一致的結果。

對抗性樣本攻擊（Adversarial Examples）

對抗性樣本是一種利用模型弱點的攻擊方式。攻擊者在輸入中加入人類察覺不到的微小擾動，讓模型做出完全錯誤的判斷。例如在一張貓的圖片上加入精心計算的雜訊（人眼看起來完全一樣），模型卻會把它辨識為狗、甚至辨識為完全不相關的物件。

這種攻擊對安全關鍵的 AI 系統特別危險。自動駕駛系統如果被對抗性樣本欺騙，可能把停止標誌辨識為速限標誌。門禁系統的人臉辨識如果被欺騙，可能讓未授權的人通過。在台灣的智慧交通系統中，如果路況辨識 AI 被對抗性樣本干擾，可能做出錯誤的交通號誌控制決策。

防護措施包括對抗訓練（Adversarial Training）——在訓練過程中主動加入對抗性樣本，讓模型學會對這類擾動有抵抗力。另一種做法是輸入預處理，在資料進入模型之前做降噪或壓縮，消除潛在的對抗性擾動。但這些防護都有局限性，對新型態的攻擊手法不一定有效。

模型水印技術

水印是一種主動防護，在模型中植入可驗證的標記，用來證明模型的所有權。跟傳統的數位版權管理類似，水印的目的是在事後能夠證明某個模型是從你的原始模型衍生出來的。

水印的運作方式：在訓練過程中植入特定的「觸發模式」。例如讓模型在看到特定的輸入組合時，產生特定的輸出模式。這個觸發模式設計得非常隱蔽，不影響模型的正常使用，但可以用來驗證某個模型是否來自你的原始模型。如果有人竊取了你的模型（即使經過微調或修改），只要觸發模式還在，你就能證明它的來源。

具體的實作方法有幾種。後門水印（Backdoor Watermark）是最常見的方式，在訓練資料中加入少量帶有特定觸發特徵的樣本，讓模型對這些樣本有特定的輸出。例如在圖片分類模型中，加入一批在右下角有特定小圖案的圖片，並標註為特定的類別。正常使用時這些觸發圖案不會出現在輸入中，但驗證所有權時可以用它們來測試。

對 LLM 的輸出水印：在模型生成文字時，透過調整 token 選擇的偏好來植入統計上可偵測的模式。例如 Google 的 SynthID 技術，會在生成文字時偏好某些 token 的組合，人類讀者察覺不到差異，但統計分析可以偵測出這種偏好模式。這種水印技術可以用來追蹤 AI 生成的文字來源，在假新聞偵測和學術誠信方面有重要的應用。

水印的限制值得重視。水印可以被清除——如果攻擊者知道水印的存在，可以透過重新訓練（fine-tune）或後處理來移除。對於輸出水印，簡單的釋義（paraphrase）就可能破壞統計模式。水印是一種威懾和事後追溯的手段，可以增加攻擊者的成本和風險，但不是強制的存取控制。在法律層面，水印提供了所有權的技術證據，但是否能作為法庭上的充分證據，在台灣目前還沒有明確的判例。

存取控制實務

除了被動防護，主動的存取控制是保護模型的基礎。好的存取控制架構應該是多層的，每一層都是一道防線，就算某一層被突破，其他層仍然能提供保護。

API 層級控制的完整流程：

使用者驗證 → 授權檢查 → 速率限制 → 輸入過濾
    ↓
模型推論
    ↓
輸出過濾 → 日誌記錄 → 回應

每一層都有具體的作用。認證（你是誰）確認呼叫者的身份，通常用 API Key 或 OAuth 2.0 token。授權（你能用哪些功能）根據呼叫者的角色決定能存取的模型和功能，例如免費使用者只能用基礎模型、付費使用者能用進階模型。限速（你能用多少）限制查詢頻率，防止濫用和模型竊取。過濾（哪些輸入和輸出被允許）攔截惡意輸入和不當輸出。

API Key 管理的實務建議：每個應用或使用者應該有獨立的 API Key，不要共用。API Key 應該有過期時間，建議 90 天輪換一次。對不同用途的 API Key 設定不同的權限和限額。記錄每個 API Key 的使用日誌，包含呼叫次數、呼叫內容的摘要、來源 IP。

模型檔案存取控制：

如果是自架模型，模型檔案（.pt、.safetensors、.gguf）的存取權限跟資料庫一樣重要。模型檔案不應該放在公開可存取的路徑，不應該被非授權的使用者讀取。

# 設定模型檔案權限
chmod 640 /models/*.safetensors
chown ai-service:ai-team /models/*.safetensors

# 檢查權限設定
ls -la /models/

容器化部署時的注意事項：模型檔案不要打包在容器映像檔中，因為映像檔通常會被推送到 registry，增加洩漏風險。正確的做法是在執行時從加密的儲存空間載入模型。在台灣常用的雲端服務上，可以使用 GCS（Google Cloud Storage）或 S3 的伺服器端加密，搭配 IAM 角色控制存取權限。

網路層級隔離：模型推論服務應該部署在內部網路中，不直接暴露在公開網路上。外部存取必須透過 API Gateway，API Gateway 負責認證、限速和日誌。在 Kubernetes 環境中，可以用 NetworkPolicy 限制只有 API Gateway 的 Pod 能夠存取模型推論服務的 Pod。

台灣企業的模型安全實務

台灣的營業秘密法可以保護 AI 模型作為營業秘密，但需要企業主動採取「合理保護措施」。這意味著如果你沒有設定存取控制、沒有簽署保密協議、沒有記錄存取日誌，法律保護的力度會大打折扣。法院在判斷是否構成營業秘密時，會檢視企業是否已經盡到合理的保護義務。

具體來說，台灣企業應該做的合理保護措施包括：

1. 與所有能接觸模型的員工和外包商簽署保密協議（NDA）
2. 在技術層面實施存取控制，確保只有需要的人員能存取模型
3. 記錄所有模型存取的日誌，包含誰在什麼時候存取了什麼
4. 在模型檔案和相關文件上標註「機密」或「營業秘密」字樣
5. 定期審查存取權限，離職員工的權限要立即移除

對於使用 AI API 服務（如 OpenAI、Anthropic）的企業，要確認服務合約中對智慧財產權的約定。大部分平台對透過 API 微調的模型提供智慧財產權保護，但具體條款因服務商而異，建議由法務仔細審閱。

金融業有額外的規範。金管會針對金融機構使用 AI 的指引中，對模型的管理有明確的要求，包括模型驗證、模型風險管理和資料治理。銀行和保險公司在部署 AI 模型時，需要同時考慮金管會的規範和模型安全的技術措施。

安全與限制

模型安全沒有一勞永逸的解法。攻擊技術持續演進，防護也要持續更新。以下是目前的主要限制：

差分隱私的計算成本高，不是所有場景都適用。大型語言模型的差分隱私訓練仍然是活躍的研究領域，目前的技術在保護隱私的同時會讓模型效能下降 5-15%，這在某些精度要求高的應用中可能無法接受。

水印技術在商業應用中還不夠成熟。沒有統一的標準，不同的水印方案之間互不相容。而且水印可以被移除，特別是當攻擊者知道水印的存在時。目前水印更多是作為威懾和事後追溯的手段，不能作為唯一的保護措施。

模型竊取的偵測很困難。你可能永遠不知道有人複製了你的模型。攻擊者可以用竊取的模型建立競品服務，而你從外部很難判斷他們的模型是自行訓練的還是竊取的。即使你懷疑被竊取，要在法律上證明也需要有力的技術證據（如水印驗證）。

多層防禦是目前最務實的策略。把模型安全想成跟其他資安一樣的縱深防禦——存取控制、速率限制、輸出資訊最小化、水印、異常偵測、法律保護，每一層都不是萬能的，但組合在一起可以大幅提高攻擊的門檻和成本。

常見問題