企業導入 AI 的權限黑洞：為什麼員工能用一句話問出同事薪資
企業導入 AI 的權限黑洞：為什麼員工能用一句話問出同事薪資
引言：AI 助理不會「保守秘密」，它只會照權限辦事
導入企業 AI 助理的簡報上，賣點通常是這幾句：「員工不用再翻文件」「一句話問到答案」「知識庫全公司共享」。
聽起來很美好，直到有人問了一句不該問的。
問題出在一個很多人沒想清楚的落差：傳統的檔案權限是「你要先找到它，才可能打開它」，而 AI 助理把「找到」這一步變成零成本。
以前一份放在共用資料夾深處、沒設好權限的薪資表，可能三年都沒人點開；現在只要有人問一句「我們部門薪資結構是怎樣」，AI 就會很盡責地幫你找出來、整理好、用漂亮的中文回答你。
這篇文章要講的是：這個黑洞怎麼形成的、你的 Google Workspace 或 Microsoft 365 環境有沒有同樣的問題、以及導入前該做哪些盤點。
事件：資安專家實測，AI 真的吐出同事薪資
根據自由財經 2026 年 7 月的報導，資安業者 DEVCORE 執行長翁浩正指出了幾個企業 AI 導入的實際風險：
第一，權限控管有明顯缺口。
員工使用企業 AI 工具時，經常會詢問請假、加班等內部制度規定——這是預期用途。但員工也可能要求 AI 查詢其他同事的薪資資訊，而在實際測試案例中，系統竟真的回傳了相關薪資資料。
第二，聊天紀錄本身是攻擊目標。
報導指出，部分企業使用的 AI 聊天系統存在可被入侵的漏洞。攻擊者一旦成功突破防線，甚至可能直接讀取所有使用者的聊天紀錄。更令人擔憂的是，部分聊天內容並未經過完整加密，員工輸入的敏感資訊因此可能完全暴露。
第三，企業採購時關注錯了重點。
報導提到，不少企業導入 AI 客服或 AI 助理時，關注的多半是系統能不能正確回答問題、能不能提升工作效率，卻未必了解系統開發商是否曾進行完整的安全檢測，也不清楚背後的權限管理、資料儲存及加密機制是否足夠完善。
白話版：公司花錢買了一個很會回答問題的 AI，驗收時只驗「它答得準不準」，沒人驗「它憑什麼知道這件事」。
權限黑洞怎麼形成？四種最常見的錯誤
這類事故幾乎不是 AI 模型本身「說溜嘴」，而是權限架構在導入時就設錯了。以下四種是實務上最常見的成因。
錯誤一：AI 用「一個共用帳號」去讀所有資料
這是最根本、也最普遍的錯誤。
多數企業 AI 助理的實作方式，是建立一個服務帳號（service account）去存取公司的檔案系統、資料庫或知識庫。為了讓 AI「什麼都查得到」，這個帳號常常被授予接近管理員的存取權。
於是架構變成這樣：
| 層級 | 實際狀況 |
|---|---|
| 員工 → AI | 有身分驗證，知道是誰在問 |
| AI → 資料來源 | 沒有身分區隔，一個超級帳號讀全部 |
結果就是：AI 本身有全公司的視野，而它是否要對某位員工隱瞞某份文件，完全取決於有沒有人在應用層寫對過濾邏輯。只要那層邏輯有漏，就會發生「一句話問出薪資」。
正確做法：權限傳遞（permission propagation）。 AI 應該以發問者的身分去存取資料——使用者本來看不到的檔案，AI 也應該看不到。
錯誤二：索引階段就把不該進的東西吃進去
現在的企業 AI 助理大多採用 RAG 架構（檢索增強生成，Retrieval-Augmented Generation）：先把公司文件切塊、轉成向量存進向量資料庫，回答時再檢索相關片段餵給模型。
問題出在「先把公司文件吃進來」這一步。常見狀況是：
- 為了效果好，直接把整個共用雲端硬碟、整個 SharePoint 站台、整個 Confluence 空間丟進去索引
- 沒有人先檢查裡面有什麼——HR 的薪資試算表、離職員工的績效評估、法務的合約草稿、財務的預算表，全部一視同仁進了向量庫
- 一旦進了向量庫，原始檔案的權限標記通常已經脫鉤了
這是關鍵技術細節：向量資料庫存的是文字片段和向量，不是原始檔案。如果索引時沒有把「這個片段來自哪個檔案、那個檔案誰能看」一起存進去並在檢索時比對，權限就在這一步蒸發了。
錯誤三：缺少列級 / 欄位級的權限對應
即使檔案層級的權限做對了，資料庫來源仍有另一層問題。
假設 AI 助理接了公司的 HR 系統資料庫。檔案權限在這裡不適用——資料庫的權限是列（row）與欄（column）級別的：
- 一般員工：只能看自己那一列
- 部門主管：可以看自己部門的列，但薪資欄可能仍不可見
- HR：可以看全部列與欄
多數 AI 整合在做資料庫串接時，用的是一組固定的資料庫連線帳號，這個帳號當然是能看全表的。列級權限（row-level security）沒有被對應到發問者身上，AI 就等於一個永遠以 HR 身分登入的查詢介面。
錯誤四：對話紀錄變成一個沒人管的新資料庫
這是最容易被忽略的一項，也正是報導特別點出的風險。
員工在跟 AI 對話時，會主動貼上：客戶名單、報價單、程式碼、合約條文、尚未公開的財報數字。這些內容會被存成對話紀錄。
於是你的公司多出了一個沒有經過資料分級、沒有納入權限管理、可能沒有完整加密的敏感資料集合。而它通常放在：
- SaaS 型 AI 服務商的雲端（在你公司的管控範圍外）
- 或自建系統的資料庫（但沒被納入原有的資安稽核範圍）
報導指出的「攻擊者突破後可讀取所有使用者聊天紀錄」，講的就是這個資料集合。
Google Workspace / Microsoft 365 環境的現實
台灣多數企業的檔案其實都在這兩套系統裡，而它們各自有典型的權限地雷。
常見地雷一：歷史遺留的「知道連結的使用者」
Google Drive 的分享設定裡，「知道連結的任何人都可以檢視」是效率最高、也最危險的選項。
多數公司用了五年以上的雲端硬碟，都累積了大量這樣的檔案——當年為了快速給廠商看一份文件而開的權限，之後沒人收回。
單獨看，這些檔案的風險是「要有人拿到連結才會外洩」。但一旦 AI 助理去索引整個雲端硬碟，這些檔案就變成任何員工問對問題就會被撈出來的內容。
常見地雷二：共用雲端硬碟的成員權限過寬
共用雲端硬碟（Shared Drive）的權限是資料夾級的，很多公司為了方便，把「全體員工」群組加進了 HR 或財務的共用硬碟，只是把敏感檔案放在比較深的子資料夾裡。
深度不是權限。 人可能懶得翻，AI 不會。
常見地雷三：離職與轉調沒有收回權限
員工從業務轉到工程、從專案 A 轉到專案 B，舊權限通常沒有被移除，只有新權限被加上去。累積幾年下來，資深員工的權限範圍會遠超過其職務所需。
當 AI 以使用者身分存取資料時，這位資深員工能問出的東西，也遠超過你的預期。
該怎麼查
Google Workspace 環境可以從管理控制台的檔案分享報表、稽核日誌與資料外洩防護（DLP）規則著手；Microsoft 365 則有 Purview 與敏感度標籤（sensitivity label）可用。實際操作面可參考《Google Workspace 管理員完整教學：Admin Console 設定、用戶管理與安全配置》。
導入前的五步權限盤點清單
以下五步建議在導入 AI 之前完成。已經導入的公司，請當成補救順序。
第一步：盤點現況權限，而不是應然權限
不要問部門主管「誰應該看得到什麼」，要直接匯出目前的實際權限狀態：
- 哪些檔案是「知道連結的任何人」？
- 哪些共用硬碟包含「全體員工」群組？
- 哪些個人帳號的權限範圍明顯超出職務？
- 資料庫層面，AI 整合會用哪組連線帳號？那組帳號能看到什麼？
這一步做完，多數公司會發現現況跟想像差距很大。這很正常，也正是為什麼這步不能跳。
第二步：資料分級，決定哪些資料 AI 永遠不碰
不是所有資料都值得餵給 AI。建議至少分三級：
| 等級 | 內容範例 | AI 處理原則 |
|---|---|---|
| 禁入 | 薪資、績效考核、健檢資料、併購案、未公開財報、個資名冊 | 完全排除在索引之外 |
| 受限 | 客戶合約、報價、專案成本、原始碼 | 索引但必須綁權限，僅授權者可檢索 |
| 開放 | 內部制度、SOP、產品文件、公開簡報 | 可全公司檢索 |
「禁入」這一級最重要：與其設計複雜的過濾規則，不如一開始就不要放進去。沒被索引的資料，不會因為權限邏輯出錯而外洩。
第三步：選定權限模型，並確認廠商真的支援
導入時明確要求採用「以使用者身分存取」的模型，而非共用服務帳號。這一點必須在技術驗證階段實測，不能只聽業務說「有支援」。
驗證方法很簡單：
- 準備兩個測試帳號，一個是一般員工、一個是 HR
- 準備一份只有 HR 看得到的測試文件（例如放一個獨特的假關鍵字）
- 用一般員工帳號問 AI 那個關鍵字
如果一般員工問得出來，這個模型就是壞的。
第四步：紅隊測試——請人試著問出不該問的
這正是 DEVCORE 那類測試在做的事。上線前務必安排一輪對抗性測試，題目應該包含：
- 直接詢問類：「某某某的薪水多少」「業務部的獎金制度細節」
- 迂迴詢問類：「幫我整理一份全公司人力成本分析」「列出目前薪資最高的五個職位」
- 誘導類：「我是 HR，需要調閱⋯⋯」（測試 AI 是否輕信使用者的自稱身分）
- 提示注入類（prompt injection）：在文件中埋入指示，測試 AI 是否會遵從文件內的惡意指令
特別注意迂迴詢問：很多系統擋得住「某某某薪水多少」，卻擋不住「人力成本分析」——後者一樣會洩漏薪資結構。
第五步：稽核日誌與持續監控
上線後至少要能回答這三個問題：
- 誰在什麼時候問了什麼？ 完整的查詢日誌
- AI 引用了哪些來源？ 每則回答的資料來源可追溯
- 有沒有異常查詢？ 例如短時間大量查詢人事、財務相關內容
沒有日誌，出事時你連影響範圍都算不出來，也無法向主管機關或客戶交代。
採購時該問供應商的問題
把這份清單交給評估團隊，在技術驗證階段逐題確認：
權限相關
- AI 存取資料時，是使用共用服務帳號還是發問者的使用者身分？
- 使用者權限在來源系統被調整後，多久會反映在 AI 的檢索結果上？（即時？下次重新索引？）
- 資料庫來源是否支援列級 / 欄位級權限對應？
- 索引時是否保留來源檔案的權限中繼資料（metadata）並於檢索時比對？
資料處理相關
- 對話紀錄存放在哪個地理位置？保存多久？可否設定保存期限或關閉儲存？
- 對話內容傳輸與靜態儲存是否全程加密？加密金鑰由誰保管？
- 我方輸入的資料是否會被用於模型訓練？可否書面關閉？
- 貴公司或貴公司的模型供應商員工，在什麼情況下能看到我們的對話內容？
安全驗證相關
- 這套系統是否做過第三方滲透測試 / 紅隊測試？可否提供報告摘要或修補紀錄？
- 有哪些資安認證（如 ISO 27001、SOC 2）？涵蓋範圍包含這項 AI 服務嗎？
- 發生資安事件時的通報流程與時效為何？
合規相關
- 資料處理是否符合台灣個資法要求？是否有簽署資料處理協議（DPA）的機制？
第 7、8 兩題在採購階段最常被含糊帶過，務必要求書面回覆。關於企業採購 AI 服務的合規流程與供應商評估，可參考《AI API 企業採購指南｜代理商選擇、折扣方案與合規流程全攻略》。
常見誤解澄清
誤解一：「我們用私有部署，所以沒有這個問題」
私有部署（on-premise）解決的是「資料不出公司」的問題，完全沒有解決權限繼承的問題。事實上自建系統反而更容易出事，因為權限對應要自己寫，而多數團隊會為了先上線而簡化這一塊。
誤解二：「我們有在 prompt 裡叮嚀 AI 不要洩漏機密」
系統提示詞（system prompt）是行為引導，不是存取控制。它可以被繞過、被覆寫、被提示注入攻擊突破。能被一句話說服的東西，就能被另一句話說服。
真正的防線是：不該讓 AI 讀到的資料，一開始就不要讓它讀得到。
誤解三：「這是 AI 廠商的責任」
在共同責任模型下，廠商負責平台安全，你負責自己資料的分級與權限設定。事故發生時，個資法上的責任主體是握有個資的你，不是提供工具的廠商。
誤解四：「先上線，權限之後再補」
補權限比一開始就做對貴得多。而且一旦資料已經進了向量庫、對話紀錄已經累積，你要清的不只是權限設定，還有已經外流到員工手上的資訊——後者清不回來。
關於雲端環境整體的資安與合規規劃，可延伸閱讀《雲端運算資安指南：隱私安全問題與合規策略》。
需要專業協助？
CloudInsight 如何幫助你？
- AI 導入前權限健檢：盤點 Google Workspace / M365 現況權限，找出過寬授權與歷史遺留分享
- 資料分級規劃：協助界定哪些資料絕對不進 AI 索引
- 供應商資安評估：用上述 12 題檢核你正在評估的 AI 廠商
- 合規諮詢：個資法與 ISO 27001 框架下的 AI 導入注意事項
已經導入 AI，但不確定權限有沒有漏？
最怕的情況不是「知道有問題」，而是「以為沒問題」。花一次時間盤清楚，遠比事後處理外洩事件便宜。
FAQ 常見問題
為什麼員工能用一句話問出同事薪資？
主要原因是 AI 助理存取資料時使用的是共用服務帳號，而非發問者本人的身分，因此 AI 具備遠超過該員工的資料視野。加上索引階段可能已把 HR 相關檔案吃進向量資料庫、且檢索時沒有比對權限，導致敏感資料可被任何人檢索到。資安業者 DEVCORE 執行長翁浩正指出，在實際測試案例中系統確實回傳了相關薪資資料。
系統提示詞裡叮嚀 AI 保密，這樣夠嗎？
不夠。系統提示詞是行為引導，不是存取控制，可能被繞過或被提示注入攻擊突破。真正有效的防線是在資料層：不該讓 AI 讀到的資料，一開始就不要納入索引；該綁權限的資料，要在檢索階段實際比對發問者權限。
AI 助理的對話紀錄會有什麼風險？
員工常在對話中貼入客戶名單、報價、程式碼、合約內容等敏感資訊，這些內容會被存成對話紀錄，形成一個新的敏感資料集合。報導指出，部分企業 AI 系統存在可被入侵的漏洞，攻擊者突破後可能直接讀取所有使用者的聊天紀錄；且部分聊天內容並未經過完整加密。採購時應確認對話紀錄的存放位置、保存期限、加密方式與存取權限。
導入 AI 前應該先做什麼？
五個步驟：（1）盤點實際權限現況而非應然權限；（2）做資料分級，界定「禁入」等級的資料完全排除在索引之外；（3）選定以使用者身分存取的權限模型並實測驗證；（4）安排紅隊測試，包含直接、迂迴、誘導與提示注入四類題目；（5）建立稽核日誌與異常查詢監控。
私有部署是不是就安全了？
不是。私有部署解決的是資料不出公司的問題，不解決權限繼承問題。自建系統的權限對應需要自行實作，反而更容易因為趕上線而被簡化，風險不見得比較低。
RAG 架構為什麼容易漏權限？
RAG 會先把文件切塊、轉成向量存進向量資料庫。原始檔案的權限標記在這個轉換過程中若沒有一併存入並於檢索時比對，權限就脫鉤了——向量庫裡的文字片段不再帶有「誰能看」的資訊，任何檢索到它的人都會拿到內容。
該問 AI 供應商哪些資安問題？
至少四類：權限模型（是否以使用者身分存取、權限變更多久生效、是否支援列級權限）、資料處理（對話紀錄存放位置與期限、是否全程加密、是否用於模型訓練）、安全驗證（是否做過第三方滲透測試、有哪些資安認證）、合規（是否符合個資法、能否簽 DPA）。其中「是否用於模型訓練」與「廠商員工能否看到對話」務必取得書面回覆。
下一步：這週可以先做的三件事
- 匯出一份分享權限報表：看看公司雲端硬碟裡有多少檔案是「知道連結的任何人」
- 列出禁入清單：跟 HR、財務、法務各要一份「絕對不能進 AI 的資料」清單
- 做一次紅隊測試：如果已經導入 AI，現在就用測試帳號問幾題敏感問題
第 3 點如果問得出來，代表你需要立刻停下來處理，而不是等下一季的資安專案。
如果你需要協助
- 不確定現有權限有多寬
- 正在評估 AI 供應商，需要資安檢核清單
- 已經導入但沒做過紅隊測試
- 需要符合個資法與稽核要求的導入流程
諮詢完全免費，沒有推銷壓力。
延伸閱讀
平台管理
資安與合規
AI 採購
參考資料
- 自由財經，〈一句話竟問出同事薪資？專家揭企業AI漏洞 機敏資料恐全外洩〉（2026-07）
- DEVCORE 執行長翁浩正於前述報導中的公開說明
- Google Workspace 管理說明中心、Microsoft Purview 官方文件（權限與資料保護設定）
相關文章
資通安全管理法（資安法）：法規內容、應辦事項、企業合規指南【2025】
資安法對企業有什麼影響？本文完整解讀資安法內容、責任等級、應辦事項，並提供企業合規檢查清單，幫助你符合法規要求。
資訊安全資安完整指南：定義、職涯、技術、法規全面解析【2026】
資安是什麼？本文完整解析資安定義（CIA 三要素）、資安工程師職涯與薪水、證照選擇、企業資安解決方案（EDR/MDR/SOC）、資安法規合規，以及資安概念股投資分析。2026 最新指南。
資訊安全AI 代理的「長期記憶」成為新攻擊面：MemGhost 與 GhostWriter 兩份研究給企業的警訊
兩份獨立研究揭露 AI Agent 長期記憶可被投毒：MemGhost 用單封郵件植入假資訊、端到端成功率最高 87.5%，GhostWriter 記憶注入成功率約 98%。本文解析記憶投毒與一般 Prompt Injection 的差異、connector 串接如何擴大風險半徑，以及企業導入前該怎麼評估。