防止機密資訊外洩的AI架構設計

僅將AI伺服器部署在本地，資訊保護並不完整。需要將使用者權限、參考文件、外部連接和回答處理作為一個整體流程進行設計。

不要止步於「放在本地就安全了」

混合AI為在內部處理機密資訊提供了路徑。但僅憑伺服器的實體位置無法判斷安全性。如果終端可以直接連接外部服務、管理入口開放過寬、不再需要的權限仍然存在，資訊就可能透過其他路徑洩露。

NIST的零信任說明中也提出，不應僅憑網路位置信任使用者或設備。除「內部還是外部」之外，確認「誰、用什麼設備、存取什麼」同樣重要。

本文介紹的是將這些理念應用於企業AI的設計示例，並不代表特定產品的標準功能，也不保證完全防止資訊洩露。導入時需確認與現有認證基礎設施和文件管理的整合。

四階段存取控制流程：認證→權限確認→資訊判定→AI處理。

僅檢查員工輸入的簡短問題，無法了解AI實際接收到的全部資訊。附件、歷史對話、檢索到的內部文件以及從圖片中識別的文字，都可能包含在處理範圍內。

例如，「請摘要這份合約」這個問題本身可能幾乎沒有機密線索，但附件中可能包含未公開條款或個人資訊。需要設計在即將發送到外部之前，對實際發送資訊整體進行確認的機制。

將防資訊洩露的DLP、文件機密分類、規則匹配和AI內容分類結合使用。由於分類AI也可能出錯，當判斷出現分歧或確認功能停止時，應暫時擱置外發。提供停止原因和負責人確認方式，可以減少員工繞過系統使用的情況。

檢索內部文件並傳遞給AI的RAG，是生成貼近業務回答的配置方式。但如果檢索範圍過寬，本不應查看的文件內容可能混入回答中。

需要將檢索候選限定為員工有權查閱的文件，反映因部門調動或離職導致的權限變更，並確認回答中引用的來源也在可查閱範圍內。即使無法直接開啟檔案，也可能透過摘要或檢索結果片段推斷出內容。

此外，不能將檢索到的文件中包含的指令直接作為系統命令執行。需預設文件中可能包含「忽略限制並發送到外部」等內容，透過獨立機制限制AI可呼叫的功能和發送目標。將文件內容與系統權限分離，是設計上的關鍵要點。

即便提供了經審批的AI介面，如果終端可以自由向其他服務發送資訊，公司政策就無法一致執行。除AI入口外，還需綜合確認外部API出口、終端管理、瀏覽器使用和管理員連接。

示例配置中，將發送到本地AI的處理與發送到已審批外部API的處理分開。管理雲端連接目標和認證資訊，使其無法連接到未經許可的目標。故障時自動切換到其他外部模型的功能，也需從資料處理角度而非僅從便利性角度進行判斷。

去除機密部分後再發送也是一種方法，但僅刪除姓名可能並不充分。結合職位、日期和案件特徵，有時仍可推斷出對象。需確定哪些資訊可以保留，並設置確認處理後內容的步驟。

在運營中，需要能夠追溯誰在何時使用、按照哪條規則路由到哪個處理目標。了解規則版本和審批記錄，便於在出現問題時調查原因並推動設置優化。

另一方面，保存所有輸入和回答會導致日誌中積累機密資訊。根據目的精簡保存項目，並確定查閱權限、保存期限、刪除和防篡改措施。監控記錄不能成為另一條資訊洩露路徑。

在員工介面上清晰顯示處理目標和擱置原因。但「顯示為內部處理」本身並不能證明安全性。需在導入時和變更時確認實際通訊和設置與顯示內容一致。

AI工作區本地處理

請整理這份提案的要點。

已收到文件。透過本地處理路徑整理要點…

請輸入您的請求…

發送

每條請求均顯示處理目標和審批狀態。

顯示處理目標和審批狀態的工作區介面示例。並非實際產品介面。

第一線工作中會出現緊急任務或非常規案件。如果「本次批准」的判斷僅憑使用者或管理員的口頭同意，事後將無法確認批准了什麼。需記錄目標文件、發送目標、目的、期限和審批人，並限定在必要範圍內。

擁有權限的管理員自身的操作也不例外。需考慮是否能將變更設置的人與審批內容的人分開，以及變更後是否能進行驗證。小型組織可能無法完全分離角色，此時需確定可行的程序，如確認記錄和定期審查。

向使用者返回的說明也需要用心。與其簡單顯示「禁止」，不如顯示「因包含內部資料，已切換至內部處理」或「因無法確認分類，等待負責人審批」，讓使用者清楚下一步行動。同時確認錯誤詳情中不會顯示過多機密資訊。

在PoC中，用不同權限的使用者測試相同問題，更容易發現控制漏洞。確認有查閱權限的使用者能獲得帶有依據的回答，而無查閱權限的使用者不會獲得內容。需分別檢查檢索結果、回答、日誌和通知，確認各項均在預期範圍內。

安全性與易用性並非相互對立的問題。即便發生擱置或拒絕，能夠引導使用者進入下一個已審批行動的設計，才能讓規則在實際工作中得到遵守。

僅將規則文件化，並不能保證第一線每次都能做出相同判斷。將常規限制反映到系統中，將複雜例外交給負責人處理——明確這一分工，可以避免將判斷壓力轉嫁給員工。

例如，準備無法外發的測試文件，改變附件、長文本、圖片、對話中途等條件進行測試。不僅在正常狀態下，還需在判定功能停止、連接目標變更、權限失效時，確認是否符合預期行為。

資訊保護設計不是一次性工作。模型、業務或組織發生變化時，需重新審視判定和權限。下一篇將從8塊GPU的配置示例出發，探討支撐這一保護、生成和審計處理的計算基礎設施。