企業導入生成式 AI 最常踩到的資安風險有哪些

企業導入生成式 AI 後，最常見的資安風險包括機密資料被貼進公開服務、提示注入操縱 AI 助理、員工使用未經核准的影子 AI、第三方 API 資料流向不清，以及 AI 應用缺少最小權限與稽核紀錄。這些問題會出現在模型外圍的資料、權限、供應商和工作流程，不能只靠換一個模型處理。對企業來說，第一步是把每個 AI 用途的輸入、取用資料、模型、工具、輸出與責任人畫成流程，再依風險配置控制措施。

先把風險放回企業工作流程

生成式 AI 的資安問題可以拆成三個位置。第一個是資料進入模型前，包含員工輸入、檔案上傳、檢索資料與外部內容；第二個是模型產生回答後，包含輸出是否能直接寫入資料庫、寄信、執行程式或觸發交易；第三個是服務運作期間，包含帳號、權限、供應商、保存期限、模型更新與稽核紀錄。這個分法能接上企業既有的資料分級、身分與存取管理、供應商管理、事件通報和變更管理。

企業原本若已經在做 AI 工作流，應先把觸發、取資料、模型處理、人工覆核、寫回與退出條件串起來，這些節點也正是資安控制的落點。本站先前整理的AI 工作流資料、權限與人工覆核設計可作為流程盤點的起點。NIST 的生成式 AI 風險管理檔案則把風險放進 Govern、Map、Measure、Manage 四個管理功能，適合拿來安排企業的制度、風險評估、測試和改善循環。

風險一：員工把機密資料貼進公開 AI 服務

這是最容易發生、也最容易被低估的情境。工程師為了除錯，把一段未公開原始碼貼進聊天機器人；客服人員把客戶來信和訂單資料貼進去，要求模型整理；人資把履歷、面談紀錄或薪資表交給工具產生摘要。從使用者角度看，這是把複製貼上換成更快的工作方法，從企業角度看，資料已經送到公司控制範圍以外的服務。

2023 年三星半導體部門就曾被報導發生三起員工把內部資料送進 ChatGPT 的事件，包括原始碼、硬體資訊與會議內容；報導也指出，三星後來限制員工使用生成式 AI 工具。Cybersecurity Dive 的事件整理支持這個案例，但它是媒體根據韓國報導轉述，本文不把事件擴大解讀成公開網路已經取得那些資料。可確定的資安問題是，員工輸入本身就可能讓企業失去對資料保存、存取和刪除的直接控制。

防範方式要落在資料進入服務前。企業可以把資料分成公開、內部、機密、受法規保護四級，為每一級訂定可使用的工具和輸入規則；在瀏覽器、郵件、端點或 API 閘道部署資料外洩防護，偵測身分證號、客戶編號、原始碼、金鑰和未公開財務資料；對機密資料要求遮罩、去識別化或只在核准的企業工作區處理。若資料含個人資料，輸入前還要確認蒐集目的、利用範圍、保存與刪除機制，並對照全國法規資料庫的個人資料保護法。

風險二：提示注入把外部文字變成操作指令

提示注入是攻擊者把特製指令藏在使用者輸入、郵件、網頁、PDF、圖片或檢索資料中，讓模型改變原本的任務。直接提示注入是使用者自己輸入誘導語句；間接提示注入則是 AI 助理讀到外部內容後，被內容裡的指令帶偏。當 AI 只有回答問題的權限，影響可能停留在錯誤摘要；當 AI 能讀取信箱、搜尋雲端檔案或呼叫工具，結果就可能變成資料外洩或未授權操作。

Microsoft 的文件把企業郵件列為一個實際防護場景，指出成功的提示注入可能讓 AI 助理洩漏信箱內容、誤判惡意郵件、產生誤導摘要，或在自動化工作流中做出不希望的動作。Microsoft Defender 的提示注入防護說明也明確區分郵件通道的前置偵測與模型執行時的防護。2025 年公開的 EchoLeak 研究進一步記錄 Microsoft 365 Copilot 的一個零點擊提示注入漏洞，研究團隊描述攻擊者可用一封特製郵件觸發資料外洩鏈，並以 CVE-2025-32711 追蹤。研究論文支持的是該漏洞與攻擊鏈的技術描述，不能直接推論每個 Copilot 租戶都曾遭到利用。

控制措施要把外部內容視為不受信任的輸入。系統提示不能承擔身分驗證或授權責任，模型也不應直接持有資料庫密碼、雲端金鑰或高權限 API 憑證。應用程式要在程式碼層分開系統指令、使用者內容和檢索內容，對輸出做格式、範圍和目的地驗證，讓高風險動作停在人工核准；對可讀寫的工具再加上沙箱、網域白名單、速率限制與交易上限。OWASP 2025 LLM Top 10 將提示注入列為 LLM01，也把敏感資訊外洩、供應鏈、過度代理權限和輸出處理列為相鄰風險，企業可用OWASP 的風險與緩解清單建立測試案例。

風險三：影子 AI 讓企業看不見資料去了哪裡

影子 AI 指員工在未經資訊、資安或法遵單位核准的情況下，使用公開聊天機器人、個人帳號、瀏覽器外掛、程式碼助理或自行串接的 API。風險也來自企業看不見有哪些服務正在處理資料、誰擁有帳號、誰能查看對話、資料保留多久、服務商是否更換模型或子處理者，以及離職後帳號是否仍能存取工作資料。

Cisco 2024 Data Privacy Benchmark Study 調查 12 個地區的 2,600 名隱私與資安專業人員，48% 受訪者承認曾把公司非公開資訊輸入生成式 AI 工具，63% 的組織限制可輸入的資料，61% 限制員工可使用的工具，27% 暫時禁止生成式 AI。Cisco 報告原文清楚標示了樣本與調查範圍。這些數字不能當成台灣企業的使用率，但足以說明「員工可能已經在用」應該被當成盤點前提。

企業若只發布一張禁止清單，通常看不見真正的使用情況。較可行的做法是建立核准工具目錄與註冊流程，使用公司身分登入和單一登入，透過網路閘道、端點管理、瀏覽器管理、CASB 或資料外洩防護辨識未註冊服務，再把員工教育改成明確列出可輸入與不可輸入的資料範例。IBM 2025 年資料外洩報告把影子 AI 納入調查，在 600 個曾發生資料外洩的組織中，五分之一回報與影子 AI 有關；這項數字來自 IBM 贊助、Ponemon Institute 執行的研究，應與報告的樣本和定義一起閱讀。IBM 台灣報告摘要提供了研究樣本、影子 AI 定義與主要數字。

風險四：第三方 API 的資料流向與責任邊界不清

企業把生成式 AI 透過 API 接進客服、內部搜尋、程式碼檢查或文件流程後，資料通常會經過應用程式、代理層、模型服務、記錄系統與可能存在的子處理者。每一層都可能有不同的保存時間、處理地區、加密方式、支援人員存取條件和事件通報程序。企業如果只問「這家模型會不會拿資料訓練」，得到的答案仍不足以判斷整條資料鏈的風險。

以 OpenAI API 的資料控制文件為例，符合資格的客戶可以在 Modified Abuse Monitoring 與 Zero Data Retention 等選項間選擇，但實際可用功能仍取決於產品、方案、端點和契約。OpenAI API 資料控制文件把不同端點的資料使用與保存規則分開列出，企業應逐一核對。相同檢查也應套用在其他模型供應商、雲端代理服務、向量資料庫和外掛工具，不能把單一產品的承諾推廣到整個供應鏈。

採購與資安團隊應要求供應商提供資料流程圖、資料處理附約、子處理者名單、保存和刪除規則、跨境處理位置、加密與金鑰管理、模型和版本變更通知、漏洞通報、事件回應、稽核權與終止服務時的資料返還或刪除證明。內部也要留下每個 API 專案使用的模型版本、端點、提示模板、檢索來源、資料類型與目的。這些資料可對接 ISO/IEC 42001 的 AI 管理系統，該標準要求組織建立、執行、維護並持續改善 AI 管理系統，涵蓋使用 AI 的組織，不限於模型開發商。IEC 的 ISO/IEC 42001 標準頁面可作為管理制度與責任分工的對照基準。

風險五：權限過大、人工覆核缺位，稽核又沒有留下來

AI 應用常被當成單一使用者的工具，但企業系統裡至少有三種身分需要分開管理：提出要求的人、執行模型或代理的服務身分，以及被讀取或修改的資料與工具。若每個人都能讓 AI 搜尋所有內部資料，或同一組 API 金鑰同時能讀取資料、修改資料、寄信和刪除紀錄，任何提示注入、帳號外洩、模型誤判或程式錯誤都會擴大成跨系統事件。

OWASP LLM Top 10 把 Excessive Agency 列為 LLM06，建議使用最小權限、把工具憑證放在應用程式程式碼而非交給模型、對高風險動作要求人工核准，並把外部內容清楚分隔。OWASP 2025 風險頁面提供了這些控制方向。NIST SP 800-53 則可接上企業既有的 Access Control、Identification and Authentication、Audit and Accountability、System and Communications Protection 控制族，讓 AI 應用不用另起一套孤立的資安制度。NIST SP 800-53 控制清單列有目前版本與控制基線下載資源。

落地時可把權限切成讀取、搜尋、建議、寫入、核准、刪除六類，先讓 AI 只讀取完成明確任務所需的資料，再把寫入和刪除拆成另一個受控工具。客服摘要可以寫入待審草稿，不能直接發送；採購助理可以提出訂單，不能直接付款；程式碼代理可以在沙箱執行測試，不能直接推送生產環境。高風險行動要顯示來源、參數、影響範圍和核准人，拒絕或逾時時回到人工流程。

稽核紀錄則要能回答五個問題：誰提出要求、使用哪個模型與版本、模型讀取了哪些資料、呼叫了哪些工具、最後由誰核准或拒絕。除提示與回答外，還應保存取用的文件識別碼、權限判斷、工具參數、輸出檢查結果、人工修改與錯誤退回原因。個資和營業機密不應原文寫入所有日誌，可用遮罩、雜湊、分級保存與受限查閱設計，讓事件調查所需的證據仍然存在。

把五種風險對照到既有框架

框架的用途是讓不同部門用同一套詞彙討論，並把「要注意資安」改寫成可驗收的控制項。NIST AI RMF 適合做整體風險管理循環，NIST 的生成式 AI Profile 適合補充提示注入、資料外洩、供應鏈與資訊安全風險，OWASP LLM Top 10 適合做應用層威脅模型和測試，ISO/IEC 42001 適合建立組織層的政策、責任、風險處理與持續改善，NIST SP 800-53 則適合把身分、權限、稽核、通訊和系統保護接回既有控制庫。

企業常見風險	發生方式	可對照的框架	上線前應留下的證據
機密資料進入公開服務	員工貼上原始碼、客戶資料或內部文件	NIST AI RMF、個資法、ISO/IEC 42001	資料分類、DLP 規則、核准工具清單、保存設定
提示注入	郵件、網頁、檔案或檢索內容含有惡意指令	OWASP LLM01、NIST AI 600-1	對抗測試、外部內容標記、輸出驗證、人工核准
影子 AI	個人帳號、未註冊網站或自行串接 API	NIST AI RMF Govern、ISO/IEC 42001	AI 資產盤點、SSO、端點與網路偵測、教育紀錄
第三方 API 資料流	模型供應商、雲端代理與子處理者處理輸入	OWASP LLM03、ISO/IEC 42001	DPA、資料流程圖、子處理者、刪除與事件通報條款
權限與稽核缺口	AI 可讀寫過多系統，日誌又無法還原事件	OWASP LLM06、NIST SP 800-53	服務身分、最小權限、審批紀錄、不可任意修改的日誌

企業可以依序做的六個檢查

第一，列出所有已使用或正在試辦的生成式 AI，正式專案之外，也要納入員工自建工具、瀏覽器外掛、程式碼助理、表單自動化和模型 API。第二，替每個用途畫資料流，標記輸入、檢索來源、模型、輸出、外部連線、保存位置和刪除方式。第三，替人員、服務和 agent 建立身分，刪掉共用帳號，把讀取、寫入、核准和刪除拆開。第四，對外部內容做提示注入測試，測試郵件、網頁、PDF、圖片、向量資料和編碼文字。第五，把高風險輸出放進人工覆核和可停用的替代流程。第六，確認每次請求、資料取用、工具呼叫、模型版本、人工決定和事件處理都能回溯。

這六個檢查應該有明確的停止條件。資料分類尚未完成時，不要讓機密資料進入試辦；供應商無法說明保存和刪除時，不要接入受保護資料；AI agent 沒有獨立身分和最小權限時，不要開啟寫入或外部傳送；高風險工作流沒有人工核准和退回路徑時，先維持草稿模式。本站已有的AI 基本法風險分類與企業清單也提醒企業，風險盤點要先落到用途與流程，才能對接後續制度。

企業導入生成式 AI 的資安治理，最後要回到責任分工。資訊單位負責身分、網路、端點、日誌和事件應變；資料與法遵單位負責分類、目的、保存、跨境和契約；業務單位負責確認 AI 是否真的符合工作需求；系統負責人負責測試、版本、輸出品質和停用條件。每個 AI 用途都應有一位能核准上線、暫停服務與處理事件的負責人。把這些條件寫進流程，企業才有機會在風險擴大前看見異常。

常見問題

企業可以直接禁止所有生成式 AI 嗎？
企業可以依資料類型、工作流程與法遵要求限制或暫停使用，但全面禁止不會自動消除員工私下使用工具的情況。較可查證的做法是建立核准工具、資料輸入規則、身分登入、端點偵測與事件通報，讓使用行為回到可管理範圍。

使用企業版 AI 就不會有資料外洩風險嗎？
企業版的訓練、保存、身分與稽核設定可能比個人服務完整，但仍要核對契約、端點、資料處理地區、子處理者、權限和工具連線。OpenAI 的 API 資料控制文件也把不同端點的資料使用與保存規則分開說明，不能把其中一項承諾當成整體安全保證。

提示注入可以靠系統提示詞完全擋住嗎？
不能把系統提示詞當成完整的身分驗證或授權機制。企業還需要把外部內容視為不受信任輸入、限制模型工具權限、驗證輸出、測試對抗情境，並在寄信、付款、刪除或寫入生產系統前要求人工核准。