企業 AI 資安與治理框架：從存取控制到稽核

AI 系統的資安風險，和一般內部系統不完全相同。它不只要防止未授權存取，還要考慮資料是否會流向外部模型服務、輸出內容是否可能洩漏不該顯示的資訊，以及系統在被誘導或誤用時會不會做出超出預期的操作。

這些風險在展示或小範圍測試階段通常不明顯，一旦連接真實資料與更多使用者，影響範圍才會顯現。治理框架的目的，是在上線前把風險項目列清楚，而不是等事件發生才補救。

存取控制：最小權限原則

AI 系統常同時扮演多個使用者的代理人，設計時應確保：

• 系統存取後端資料時，權限範圍不超過任務所需。
• 依角色與部門設定可查詢的資料範圍，避免單一帳號擁有全部權限。
• 服務對服務的呼叫需要驗證身分，而不是共用單一金鑰。
• 定期檢視權限設定，移除已不再需要的存取範圍。

一個常見風險是開發階段為求方便，先給予較大權限，正式上線前才發現範圍過廣，需要額外時間重新設計。

資料保護：傳輸、儲存與留存

資料保護需要涵蓋整個生命週期：

• 傳輸過程加密，避免中間攔截。
• 儲存時依敏感程度分級保護。
• 明確設定資料留存期限與刪除機制。
• 對個資或機密欄位進行遮罩或去識別化處理。
• 記錄資料在系統間流動的路徑，方便事後追查。

若系統會保留對話紀錄或查詢紀錄作為改善依據，需要額外確認保留範圍是否符合內部政策，避免留存超出必要的敏感內容。

供應商與模型風險

使用外部模型服務時，應確認：

• 資料是否可能被用於訓練模型，或需額外簽署協議排除。
• 資料處理與儲存地點是否符合資料主權要求。
• 服務中斷或供應商政策變動時的因應方案。
• 合約中對資料所有權、刪除義務與責任歸屬的約定是否清楚。

即使是知名供應商，條款細節也可能因方案不同而有差異。建議在簽約前，由法務或資安人員一併檢視資料使用相關條款，而不是只由技術團隊確認功能面。

輸出風險：幻覺與有害內容

AI 系統的輸出本身也是風險來源：

• 生成內容可能包含錯誤資訊或不存在的引用。
• 回答可能被誘導產生不當、偏頗或違反政策的內容。
• 對外顯示的內容若未經確認，可能被誤認為官方正式立場。

因應方式包括建立輸出檢查機制、限制高風險情境的自動發布權限，以及在使用者介面上清楚標示內容由 AI 產生，並提供回報錯誤的管道。

高風險操作的人工核准

不是所有 AI 產出都適合直接自動執行。設計時應區分：

• 低風險操作：草稿、建議、內部參考，可直接產出。
• 中風險操作：需要人工確認後才送出，例如對外回覆或修改紀錄。
• 高風險操作：涉及金流、合約或不可逆變更，應強制人工核准。

風險分級應依實際後果決定，而不是依技術是否可行決定。同一項技術能力，用在內部草稿與用在自動對外發送，風險等級完全不同。

稽核與可追溯性

上線後應能回答「這個決定是怎麼來的」，這需要：

• 記錄輸入、輸出與使用的資料來源版本。
• 保留人工核准與修改的紀錄。
• 建立版本控管，方便追溯模型或提示詞的變更歷史。
• 設定異常查詢與大量存取的告警機制。

稽核紀錄不只是為了合規，也是系統出現爭議或錯誤時，能快速定位原因的關鍵依據。

異常應變與降級機制

正式系統需要規劃在異常情況下的因應方式：

• 外部服務逾時或中斷時，如何降級或提示使用者。
• 發現輸出品質異常時，能否快速暫停特定功能。
• 是否有明確的回退方案，回到人工處理流程。

沒有降級機制的系統，一旦外部依賴出現問題，往往會直接中斷服務，而不是優雅地縮小功能範圍。

治理責任分工

資安與治理不應只是技術團隊的責任，建議明確分工：

• 業務單位負責定義風險容忍度與使用規範。
• 技術團隊負責落實存取控制與監控機制。
• 法務或合規人員負責檢視外部合約與法規要求。
• 指定專責窗口，負責處理資安事件與政策更新。

治理框架應該在上線前而非事後補上

AI 系統的資安與治理設計，越晚處理，修改成本越高。建議在 PoC 階段就同步規劃權限架構與風險分級，而不是等到正式上線前才臨時補強。

如果你正在準備從 PoC 走向正式環境，可以參考AI PoC 走向正式環境的關鍵；資料面的整備可參考企業 AI 資料整備與治理。若需要協助設計權限架構與治理流程，歡迎了解首硬網路的企業 AI 解決方案或洽詢導入規劃。