企業 AI 安全、治理與控制框架：elDoc 如何確保 AI 受企業安全管控

企業對生成式 AI 的採用正迅速由試驗階段邁向正式生產環境。

然而，對政府機構、金融機構、關鍵基礎設施營運商及其他受監管機構而言，部署 AI 並不只是將大型語言模型（LLM）連接至企業文件這麼簡單。

真正關鍵的問題是：

企業如何運用 AI，同時確保對資料、使用者、文件、基礎設施及業務流程的控制？

生成式 AI 為企業帶來額外的風險層面。敏感資訊可能被未獲授權的使用者存取，提示注入攻擊可能試圖操縱資訊檢索，AI 亦可能產生不準確資訊、執行不當操作或消耗未受控的資源。企業亦必須考慮資料在哪裡處理、哪些 AI 模型可以存取資料，以及如何對 AI 產生的操作進行治理。

elDoc Enterprise AI 安全、治理與控制框架將 AI 納入既有的企業安全邊界之內，以應對上述挑戰，而非讓 LLM 本身成為安全控制的最終權限來源。

其核心原則十分清晰：

AI 在 elDoc 所建立的安全與治理邊界內運作，不會取代、繞過或自行決定這些控制機制。

為何企業 AI 所需的不只是 LLM 安全防護

LLM 只是企業 AI 架構中的其中一個組成部分。

企業同樣需要管控身分、身份驗證、文件權限、資訊檢索、RAG 流程、AI 操作、輸出內容、基礎設施、資料生命週期及模型連接。

當 AI 連接至企業知識庫時，這一區分尤其重要。

假設一家企業在人力資源、法律、財務、營運及管理等部門擁有數以百萬計的文件，而個別員工可能只獲授權存取其中一小部分。

如果沒有企業級授權層，便直接將 AI 模型連接至整個文件庫，顯然會帶來安全風險。

elDoc 採用不同的架構方式。

底層 LLM 不會自行決定使用者可以存取哪些企業資訊。在資訊提供予 AI 之前，elDoc 會先驗證已完成身份驗證的使用者是否具備相應存取權限。

這在 AI 智能與企業權限之間建立了重要的分離。

elDoc 安全與控制框架的六大支柱

elDoc 以六大相互連結的支柱構建企業安全與 AI 治理架構。

安全與治理支柱	企業控制
1. 平台可用性與安全性	彈性架構、基礎設施安全、監控及高可用性
2. 存取與身份驗證	多重身份驗證（MFA）、單一登入（SSO）及經身份驗證的 AI 存取
3. 角色、權限與存取感知 AI	基於角色的存取控制（RBAC）、群組、文件權限及權限感知 RAG
4. 加密、資料保護與資料主權	加密、受控資料處理，以及靈活的 AI 部署方式，包括 on-premise 部署
5. 細緻化文件控制	精細控制文件的檢視、下載、列印、複製、編輯及分享
6. AI 治理與負責任 AI	受控 AI 代理能力、Human-in-the-Loop（HITL）、基於可靠資料來源的回應、模型治理及 AI 使用量控制

這些控制機制共同保障 使用者 → 文件 → RAG → LLM → AI 代理 → 企業操作 整個互動鏈路的安全性。

1. 安全且具韌性的企業 AI 基礎設施

AI 安全防護始於提示詞送達 LLM 之前。

elDoc 提供具韌性的架構，確保企業文件及 AI 服務在安全狀態下持續穩定運行。

高可用性架構、冗餘機制、基礎設施控制及監控，為企業部署提供所需的穩定運行基礎。

當 AI 深度融入以文件為核心的業務流程時，這一點尤其重要。一旦員工依賴 AI 執行文件檢索、分類、資料擷取、審閱及工作流程操作，AI 的可用性便成為業務持續運作的重要一環。

因此，安全性不僅需要保障機密性，亦必須兼顧可用性、完整性及營運韌性。

2. AI 存取前的企業身份驗證

AI 絕不應成為繞過企業身份驗證的另一條途徑。

elDoc 的存取可透過以下企業身份驗證機制進行管控：

• 多重身份驗證（MFA）
• 單一登入（SSO）
• 身份授權
• 使用者及群組管理
• 基於角色的存取控制（RBAC）

使用者必須先完成身份驗證，方可存取企業資訊或使用 AI 功能。

經身份驗證的員工與 AI 互動時，整個互動過程仍在該員工既有的安全權限範圍內進行。

不存在一個可不受限制存取企業知識的獨立「AI 身份」。

AI 繼承的是限制，而非額外權限。

3. 存取感知 RAG：AI 只能檢索使用者有權存取的資訊

這是企業生成式 AI 最重要的控制機制之一。

傳統 RAG 實作往往高度重視索引及檢索準確度，卻可能忽略一個根本問題：

這名使用者是否確實獲授權檢索這項資訊？

elDoc 將基於角色的存取控制、使用者及群組權限，以及細緻的文件級授權機制，整合至 RAG 架構之中。

在將文件內容或 RAG 上下文提供予 LLM 之前，elDoc 會先驗證已完成身份驗證的使用者是否具備相應授權。

只有使用者獲准存取的資訊，才可納入 AI 的處理上下文。

例子

假設企業知識庫包含：

10,000,000 份文件

而員工 A 獲授權存取：

27,500 份文件

即使全部 1,000 萬份文件均已建立索引，員工與 AI 互動時，也不應因此突然獲得對全部文件的語意存取能力。

AI 實際可使用的知識範圍，仍以該員工獲授權存取的資訊為界。

這意味著無論資訊是由使用者直接存取，還是透過 AI 輔助查詢取得，文件權限始終具有最高效力。

同時，這種架構亦能為企業提供重要的防護，降低攻擊者透過提示注入、RAG 操縱、向量層弱點或其他針對 AI 的攻擊技術取得未獲授權資訊的風險。

4. 資料保護與 AI 資料主權

企業 AI 治理越來越取決於一個看似簡單的問題：

我們的資料實際會流向哪裡？

elDoc 透過受控資料處理及加密機制保障資訊安全，包括利用安全的 TLS 通道保護傳輸中的資訊，以及對靜態資料進行加密。

但企業 AI 還需要考慮另一個層面：AI 資料主權。

企業需要掌控的不僅是文件的儲存位置，還包括以下元件的部署及運行位置：

• 文件儲存庫
• RAG 基礎設施
• 向量資料庫
• 嵌入向量
• AI 處理元件
• 大型語言模型

部署及運行。

根據所選架構，這些元件可以部署及運行於受控環境，包括 on-premise 基礎設施。

這讓企業能夠根據自身的監管、網絡安全、基礎設施及資料主權要求設計 AI 架構，而不是將敏感企業資訊自動傳送至外部 AI 服務。

此框架旨在支援具有嚴格安全及資訊保護要求的環境，包括涉及 ISO 27001、GDPR 及 HIPAA 的相關要求。

5. AI 引入後，細緻的文件安全控制依然有效

企業文件即使允許員工存取，仍可能受到其他操作限制。

例如，企業可以允許使用者檢視文件，但禁止下載、列印、複製、編輯或分享。

因此，elDoc 將安全控制延伸至基本文件庫存取之外。

細緻化控制機制可針對以下文件操作進行管控：

文件操作	可進行控制
檢視	✓
下載	✓
列印	✓
複製	✓
編輯	✓
分享	✓

引入 AI 功能後，這些文件層級的控制機制依然適用。

AI 並非用來繞過底層資訊既有存取限制的另一種途徑。

無論是傳統文件操作還是 AI 輔助的文件操作，來源文件的安全分類及授權始終是最終依據。

6. AI 治理：控制 AI 可以執行的操作

企業 AI 安全不僅關乎 LLM 能夠看到甚麼。

更重要的是 AI 能夠執行甚麼操作。

隨著企業由 AI 聊天逐步轉向 AI 代理及代理式工作流程，這一區分變得至關重要。

能夠檢索資訊的 AI 系統涉及一類風險。

而能夠修改文件、變更中繼資料或啟動工作流程操作的 AI 代理，則涉及另一類風險。

因此，elDoc 不會向底層 LLM 授予不受限制的自主操作權限。

AI 功能透過明確定義的應用程式功能提供，並持續受應用程式權限及控制機制約束。

對於會改變系統狀態或寫入資料的操作，可在執行前要求使用者確認或批准。

這建立了一個重要的控制邊界：

LLM 可以提出操作建議，但是否獲准執行，以及如何執行，則由企業應用程式決定。

這有助於降低 AI 自主操作權限過高、提示操縱、非預期變更及不當自主操作所帶來的風險。

Human-in-the-Loop 是企業控制機制，而非 AI 的限制

完全自主並不一定是企業 AI 的目標。

在高影響力的業務流程中，企業可以有意要求人工驗證。

elDoc 支援 Human-in-the-Loop（HITL） 機制，適用於文件資料擷取、分類、處理及工作流程等場景。

因此，一個典型的受控流程可以按照以下方式運作：

文件 → AI 處理 → 驗證 → 獲授權人員批准 → 業務流程

企業可以據此決定哪些操作可以自動化，以及哪些操作在資訊進入後續階段前必須經過人工監督。

AI 因此維持其企業輔助能力的定位，而不會自動成為獨立的決策權限主體。

透過企業知識溯源降低幻覺風險

生成式 AI 可能產生看似可信、但缺乏企業資訊支持的答案。

對受監管機構而言，這可能帶來重大的營運風險。

elDoc 採用 Retrieval-Augmented Generation（RAG），讓 AI 回應以獲授權的企業文件為依據。

在適用情況下，AI 回應可引用其底層來源文件，讓使用者能夠根據企業內容核實生成的資訊。

這有助於建立更透明的知識處理流程：

問題 → 獲授權檢索 → 企業來源 → LLM 推理 → 附來源參考的回應

RAG 並不能保證 LLM 永遠不會產生錯誤回應。其作用在於減少對缺乏依據的模型內建知識的依賴，並讓使用者更容易追溯及核實 AI 生成的資訊。

elDoc 不會使用客戶文件訓練 LLM

另一個重要區分在於推理與訓練。

elDoc 不會使用客戶文件訓練或微調底層 LLM。

獲授權的企業資訊會在 RAG 及推理過程中作為上下文資訊提供，而不會被納入模型的訓練參數。

因此，企業資訊仍由受控的 elDoc 環境進行管理，並持續受既定的存取、保留、生命週期及刪除政策約束。

這種分離有助於降低客戶資訊因 elDoc 執行訓練而被納入模型參數，從而使 elDoc 直接暴露於相關風險的程度。

受控的 AI 輸出

LLM 的輸出絕不應自動被視為可信且可執行的輸入。

在 elDoc 中，AI 生成的輸出會被視為應用程式資料，並透過受控的應用程式邏輯進行處理。

AI 生成的程式碼不會在應用程式或底層基礎設施中自動編譯或執行。

同樣地，即使提示詞要求 LLM 執行具備特權的應用程式功能，LLM 也無法僅憑提示詞自行呼叫該等功能。

任何會改變系統狀態的操作，仍須遵循相應的授權及應用程式控制機制。

這建立了另一個重要的權限分離：

LM 生成 ≠ 應用程式授權。

以 LLM 無關架構實現治理控制

AI 模型正以前所未有的速度持續演進。

企業今天選用某一 LLM，日後可能因應安全性、監管、效能、成本、資料主權或組織需求而決定更換模型。

因此，elDoc 採用 LLM 無關架構。

企業安全架構並不從根本上依賴任何特定 AI 模型。

企業可以選擇及更換 LLM，同時維持 elDoc 的授權、文件安全、RAG 及應用程式控制層。

這亦有助於更清晰地劃分各層的責任。

elDoc 應用程式層控制

elDoc 負責管控以下範疇：

• 身份驗證
• 授權
• 企業資訊存取
• 文件權限
• 存取感知 RAG
• AI 驅動的應用程式操作
• 輸出處理
• 文件生命週期
• AI 與企業功能之間的互動

底層 LLM 風險

以下特性包括：

• 模型訓練資料的構成
• 模型固有偏差
• 模型記憶特性
• 模型文件及相關說明
• 公平性特徵
• 供應商特定的模型限制

取決於所選 LLM 及其供應商。

LLM 無關的架構讓企業可以在底層模型的特性不再符合所需的風險要求時，重新評估或更換模型。

AI 使用量與成本治理

AI 治理亦涉及營運及財務層面。

缺乏適當控制時，企業採用 AI 可能導致 Token 使用量失控、並行請求過多、資源競爭及成本難以預測。

elDoc 將 AI 功能限制於經身份驗證的使用者，並提供應用程式層面的機制，以控制及監控 AI 資源使用量。

根據部署要求，企業可以限制並行請求及資源使用量，同時監控使用情況，以支援營運及財務治理。

因此，企業 AI 不僅受到安全控制，亦受到使用量控制。

準備好打造安全且受控的企業 AI？

從 AI 概念驗證（PoC）邁向正式生產環境，需要的不只是選擇 LLM，更需要一套安全與治理架構，在每次 AI 互動的前、中、後全程保護企業資訊。

歡迎與 elDoc Enterprise AI 專家交流，了解如何在掌控資料存取、文件權限、AI 操作、Human-in-the-Loop 審批、LLM 選擇、AI 資料主權及部署架構的同時，為企業實施生成式 AI、Agentic RAG 及 AI 文件代理。

無論企業需要雲端、私有基礎設施，還是完全 on-premise 的 AI 部署，elDoc 均提供所需的安全與控制框架，協助企業將 AI 引入敏感及受監管的文件環境。

將 AI 引入企業知識，同時掌控企業資料。 與 elDoc 專家交流