不一定。

今天介紹 Glean 時，我們提到一個很重要的能力：

它會盡量延續公司原本資料來源的存取權限。

例如：

你原本沒有權限看的文件。

不應該因為改用企業 AI 搜尋，就突然出現在你的結果裡。

這個方向沒有錯。

Glean 官方也說明，它的 Connector 會同步來源系統中的內容與權限，並依照使用者原本的 ACL 決定搜尋結果。

但真正容易誤解的是下一句：

「既然 Glean 會保留權限，那公司敏感資料就安全了。」

這就不一定。

第一個問題：Glean 保留的是「現在的權限」

假設公司 Google Drive 裡有一份：

員工薪資資料。

正確設定應該只有：

人資。

財務。

主管。

能看到。

那麼企業搜尋系統延續這個權限：

當然很好。

可是如果這份文件三年前為了方便：

被誤設成：

整個公司都可以看。

那問題就不同了。

AI 並沒有破解權限。

它只是忠實地按照：

原本就設太大的權限。

把資料找出來。

所以真正的問題不是：

「AI 有沒有越權？」

而可能是：

「公司以前是不是早就把權限開錯了？」

為什麼 AI 搜尋會讓這個問題更明顯？

以前一份文件即使設成全公司可讀：

只要它藏在某個很深的資料夾裡。

名稱又很難搜尋。

大部分員工可能永遠不會看到。

不是因為沒有權限。

而是：

不知道它存在。

企業 AI 搜尋加入之後：

情況不同。

員工可以直接問：

「公司去年各部門的人事成本是多少？」

以前不知道該去哪裡找。

現在 AI 可能幫你找。

所以搜尋能力變強之後：

原本沉在公司資料底層的錯誤權限，也可能一起被放大。

所以「有權限」不等於「本來就應該有權限」

這兩件事一定要分開。

Glean 可以回答：

系統目前允不允許這個人讀。

但它不一定能替公司回答：

公司當初把這個權限給他，到底是不是管理錯誤。

這屬於：

資料治理。

權限治理。

而不是模型能力。

第二個問題：不同 Connector 的權限能力不完全一樣

這點更重要。

不要認為：

「Glean 連什麼工具，都一定可以百分之百複製原始系統每一層權限。」

不同資料來源能提供給 Glean 的權限資訊並不完全相同。

有些 Connector 可以同步細緻的使用者與文件 ACL。

有些受到來源系統 API 限制。

一個很具體的例子：Notion

Glean 官方目前特別提醒：

Notion 的索引 API 不提供文件層級的使用者 ACL 資訊。

因此：

一旦某份 Notion 文件被分享給 Glean Integration 並建立索引，Glean 無法依照原本 Notion 的每位使用者文件權限做相同的搜尋過濾。

官方文件甚至直接提醒管理員：

只應把適合讓所有相關 Glean 使用者搜尋的 Notion 內容分享給這個 Integration。

這是一個非常重要的例外。

所以不能只問「Glean 安不安全？」

真正應該問的是：

「我正在接哪一個資料來源？」

Google Drive。

SharePoint。

Salesforce。

Notion。

ServiceNow。

每一個 Connector：

來源 API。

權限模型。

資料結構。

同步方式。

都可能不同。

例如 Glean 官方說明，Salesforce Connector 會鏡像 Salesforce 的 Record-level Permissions；SharePoint 與 ServiceNow 等 Connector 也有自己的權限同步與限制說明。

所以企業正式導入前：

不能只看平台首頁寫：

「permission-aware」。

還要看：

你真正準備連接的那一個 Connector。

第三個問題：搜尋權限和 AI Assistant 權限還要分開看

假設某份資料：

員工在企業搜尋裡有權限看到。

不代表公司就一定希望：

AI Assistant 使用這份資料產生答案。

例如某些內容可能包含：

人事。

內部調查。

法律文件。

特殊客戶資料。

未公開財務資訊。

企業可能希望：

員工仍可依正常方式存取。

但不要讓生成式 AI 把這些內容拿來組合回答。

Glean 官方因此提供 Assistant 的內容 Inclusion／Exclusion Rules。

管理員可以設定：

哪些 Datasource。

Container。

甚至特定文件。

不讓 Assistant 使用。

這代表企業至少有兩個問題要問

第一層

這個人能不能看到這份資料？

這是來源系統權限。

第二層

就算他能看到，AI Assistant 要不要使用這份資料？

這是另一個管理決定。

兩個不要混在一起。

例如一份公司併購計畫

假設某位財務主管：

本來就有權限看。

企業搜尋讓他找到：

沒有問題。

但公司可能仍然決定：

這整個資料夾不要進生成式 AI Assistant。

因為內容：

高度敏感。

使用範圍很小。

也沒有必要拿去回答一般工作問題。

這時就可以考慮：

直接排除。

「AI 能不能看」不是只有開和關

公司真正成熟的做法應該更細。

例如：

產品 FAQ。

可以搜尋。

可以讓 Assistant 使用。

客服知識。

可以搜尋。

可以讓 Assistant 摘要。

內部專案文件。

可以搜尋。

但視部門權限。

人事資料。

只給特定人存取。

而且可能排除 Assistant。

董事會文件。

甚至可能：

根本不要讓某個 Connector 抓取。

這才是真正的資料範圍管理。

第四個問題：Admin 自己也能限制哪些內容進來

Glean 的 Connector 設定並不是只能：

「整套 App 全部抓進來。」

官方文件提供 Crawling Restrictions 等設定，管理員可以限制哪些資料被索引；Admin Console 也可以管理資料來源，以及隱藏部分文件不出現在搜尋結果中。

這表示：

企業真正的第一道防線甚至可以放在：

不要索引。

如果一批資料根本不需要 AI 搜尋：

就沒有一定要先抓進來再想辦法限制。

所以資料可以分成三層

第一層：可以搜尋，也可以給 AI 使用

例如：

產品手冊。

一般 SOP。

公開內部政策。

常見客服知識。

第二層：可以搜尋，但限制 AI 使用

例如：

部分敏感專案。

需要人直接閱讀的正式文件。

第三層：根本不要進入這個 AI 搜尋範圍

例如：

高度機密資料。

不相關的人事資訊。

沒有業務必要的特殊敏感文件。

這比：

「全部接進來，再相信 AI 不會亂看。」

可靠很多。

第五個問題：Agent 又比搜尋多一層風險

Glean 現在不只有搜尋和 Assistant。

還有 Agent。

而 Agent 可能不只是：

讀。

還可能：

找資料。

呼叫工具。

執行工作。

所以當 AI 從：

看資料

變成：

做事情

權限問題又要重新檢查。

例如一個 Agent 可以讀 CRM：

風險是一層。

如果它還可以修改 CRM：

又是另一層。

可以建立 Ticket：

再一層。

可以對外寄信：

風險更高。

不要因為「讀得到」就順手把「能修改」也打開

這和昨天我們談 Workspace Studio 時一樣。

完成工作需要：

Read。

就先不要給：

Write。

只需要查詢客戶資料。

就不要順便開：

刪除客戶。

改價格。

改付款條件。

AI 工具的能力越完整：

最低權限原則反而越重要。

第六個問題：公司人員異動後，權限會不會跟著更新？

例如員工：

從業務部門調到行銷部。

以前可以看：

某些客戶資料。

現在不應該再看。

如果來源系統本身的群組與權限已經正確修改：

Glean Connector 才能把正確狀態同步過來。

所以權限管理真正的源頭：

仍然在：

Google Workspace。

Microsoft 365。

Salesforce。

其他原始系統。

不是等資料進 Glean 之後才開始管。

真正好的企業 AI 權限流程應該從原始系統開始

順序可以是：

第一，來源權限正確。

↓

第二，只索引需要的資料。

↓

第三，確認 Connector 能不能同步需要的 ACL。

↓

第四，再決定 Assistant 可以使用哪些內容。

↓

第五，Agent 只給完成工作需要的最小行動權限。

這樣才比較完整。

公司第一次導入，可以做一個「反向測試」

很多企業測 AI 搜尋時，只做：

「能不能找到我要的？」

今天再增加另一個測試：

「能不能找不到我不應該看到的？」

這非常重要。

怎麼測？

準備三種測試帳號。

例如：

一般員工。

業務主管。

人資主管。

再準備幾種文件。

全公司文件。

業務限定文件。

人資限定文件。

然後每個帳號問同一組問題。

正確情況應該是：

三個人得到不同結果。

因為他們本來的權限就不同。

如果一般員工竟然搜尋到：

人資限定資料。

先不要怪 AI。

第一件事要查：

原始資料來源的權限到底怎麼設定。

再刻意測一份「誤設權限」文件

這個測試更有價值。

找一份測試文件。

故意把原始來源設成：

全公司可見。

然後看看 Glean 是否能找到。

如果找得到：

反而證明：

AI 正在依照原始權限工作。

真正需要修正的是：

來源設定。

這能讓團隊真正理解：

Permission-aware 不等於 Permission-correcting。

AI 尊重權限。

不代表 AI 幫你判斷權限設得合不合理。

可以直接使用的權限測試 Prompt

你是我的企業 AI 權限測試助手。

我要測試企業搜尋或 AI Assistant 是否只會顯示使用者應該存取的公司資訊。

目前測試帳號角色是：

[一般員工／主管／人資／財務／其他]

這個角色原本應該可以看到：

[資料範圍]

不應該看到：

[資料範圍]

請使用以下方式測試。

第一：

列出 10 個這個角色正常應該可以回答的公司問題。

第二：

列出 10 個這個角色理論上不應該取得答案的問題。

第三：

逐題測試時記錄：

是否找到資料。

引用來源。

來源系統。

資料是否真的符合帳號原有權限。

第四：

如果 AI 找到理論上不應該看到的內容：

不要直接判定 AI 越權。

請先檢查：

原始文件是否已經誤設成公開。

來源系統群組是否設定錯誤。

Connector 是否支援文件層級 ACL。

Connector 是否存在已知的權限同步限制。

資料是否因為被分享給 Integration 而擴大可見範圍。

第五：

再檢查這份資料是否有必要：

被索引。

被企業搜尋找到。

被 AI Assistant 使用。

被 Agent 使用。

最後把問題分成：

來源權限錯誤。

Connector 權限限制。

AI Assistant 資料範圍問題。

Agent 行動權限問題。

沒有發現問題。

不要只回答「安全」或「不安全」。

我要知道問題實際發生在哪一層。

今天最容易犯的錯

看到產品寫：

「尊重原始權限。」

就直接認為：

資料治理問題解決了。

沒有。

Glean 可以在支援的來源中延續既有 ACL。

但它不能替公司自動判斷：

三年前開給全公司的文件：

現在是不是其實應該只有財務看。

而且不同 Connector 的權限同步能力也可能受到來源平台限制。

所以：

產品安全機制很重要。

但公司的權限管理同樣重要。

今天最重要的答案

Glean 會保留原本權限：

是一個非常重要的企業安全基礎。

但它不代表：

敏感資料一定不會被找到。

真正要再確認三件事：

第一：

原始權限本身有沒有設對？

第二：

這個 Connector 能不能完整同步需要的權限？

第三：

這份資料到底有沒有必要進 Search、Assistant 或 Agent？

如果原始權限已經錯：

AI 可能只是把原本隱藏的錯誤變得更容易被發現。

如果 Connector 本身沒有細緻 ACL 能力：

就要另外限制資料範圍。

如果資料高度敏感而且根本沒有 AI 使用需求：

最安全的選擇可能不是：

「相信 AI 不會用。」

而是：

不要讓它進來。

企業 AI 真正成熟的安全方式，不是問：

「這套 AI 安不安全？」

而是逐層確認：

誰能看、AI 能用、Agent 能做什麼。

今天，和 AI 一起進步一點。

每天學會一個 AI 技巧。

每天節省一點時間。

每天提升一點能力。

SasaDaily，陪你一起成長。

推薦閱讀

AI 快問快答｜2026/07/23：把 AI 加進團隊群組後，它會看到所有公司訊息嗎？

AI 快問快答｜2026/08/12：工作符合「高頻、低風險、可驗證」，就可以直接全自動嗎？

今日 AI 工具｜2026/07/23：Claude Tag，把 Claude 加進 Slack，讓整個團隊共同交辦與追蹤工作