企業生成式 AI 資料安全怎麼做？上線前後完整檢查清單

企業導入生成式 AI，最實際的起點不是先決定要用哪一個模型，而是先建立一套能被執行、被稽核，也能在事故發生時啟動的資料安全規則。

一份可用的企業生成式 AI 資料安全規範，至少要回答六件事：哪些資料可輸入、資料會流向哪裡、誰可存取、供應商如何處理資料、RAG 知識庫是否會放大權限風險，以及面對提示注入或錯誤動作時如何停止服務與保存證據。

以下清單可作為企業上線前審查、採購問卷、員工使用規範與上線後複審的共同基線。它不是法律意見；涉及個資、跨境資料、特定產業規範或客戶合約時，仍應由法務、資安與業務責任單位依實際情境確認。

先看重點：企業上線前必做的 10 項檢查

1. 資料先分級：明確定義可直接輸入、完成遮罩後可輸入、完全禁止輸入三類資料。
2. 建立 AI 使用台帳：逐項登錄用途、使用者、資料來源、資料流、模型或服務、處理地理範圍、權限與責任人。
3. 確認個資處理依據：若會蒐集或處理一般個人資料，先檢視特定目的與法定事由。
4. 把跨境傳輸列為獨立審查項目：不要只在採購表上寫「雲端服務」就結案。
5. 向供應商逐題確認：訓練用途、保留、刪除、人工覆核、處理地、子處理者、日誌與管理控制都要分開問。
6. 盤點資料副本：RAG 文件、向量資料庫、快取、對話紀錄、日誌、評測集與備份都要納入確認。
7. 落實身分與權限：採最小權限、角色分離、強化登入與離職停權等控制。
8. 納入提示注入受控測試：依使用案例記錄資料揭露、權限與工具動作的測試結果及改善項目。
9. 高風險動作需人工核准：尤其是寄信、修改資料、發布內容、建立帳號、調整權限或呼叫外部系統。
10. 預先寫好事故流程：指定誰能停止服務、保存哪些紀錄、誰負責判斷通報與後續改善。

為何企業生成式 AI 資料安全，不只是「不要貼機密」

「不要把機密貼進聊天視窗」是必要提醒，但不足以管理企業風險。生成式 AI 的資料處理通常涉及輸入提示、檔案附件、檢索資料、模型輸出、應用程式日誌、評測資料，以及可能串接的內部或外部工具。

因此，真正要管的是資料生命週期：資料從哪裡來、如何被轉換、送到哪些元件、何時被保留或刪除、誰能讀取，以及能否追查特定一次互動的過程。

數發部的《公部門人工智慧應用參考手冊》將提示注入列為生成式 AI 的資安威脅。這份手冊可作為企業規劃治理措施的參考，但不等同於對所有私人企業的直接法律義務。

一、使用前先分級：哪些資料能輸入生成式 AI？

資料分級的目的不是讓所有人背誦規則，而是讓員工在送出提示前能迅速判斷：能否輸入、是否需先處理、是否必須改走核准流程。

企業可依自身風險、合約與法令要求，先建立下列三層操作分類。

不要只寫「機密資料禁止」

過於籠統的禁令往往無法落地。建議將常見資料類型列成判斷表，例如姓名與聯絡方式、客戶識別資訊、薪資與人事資料、原始程式碼、尚未公開的財務或產品內容、帳密與存取權杖、合約附件等，並指定每一類的處理方式。

若資料需要遮罩，規範也應說明「遮罩到什麼程度」。例如，只移除姓名但保留足以重新識別個人的組合欄位，未必足以降低風險。重要的是依資料用途設計最小必要輸入，而不是把整份原始資料搬進提示欄。

二、建立 AI 使用台帳：先看清資料流，才能管理風險

每一個生成式 AI 使用案例，都應有一筆可維護的台帳紀錄。沒有台帳，企業很難回答資料是否跨境、是否有外部工具存取、發生異常時該找誰處理。

AI 使用台帳至少應包含的欄位

• 業務用途：要解決什麼工作問題？輸出是否會被用於對外或高影響決策？
• 系統責任人：業務所有人、技術維運人、資料擁有者與核准人分別是誰？
• 輸入資料：資料來源、資料分類、是否含個資、是否需遮罩。
• 資料流：資料經過哪些應用程式、連接器、知識庫、模型、日誌與備份位置。
• 輸出與下游用途：輸出會被誰閱讀、是否會寫回其他系統、是否觸發工具動作。
• 身分與權限：哪些角色可以使用、上傳、管理知識庫、變更設定或查看紀錄。
• 供應商與部署資訊：使用的服務、帳戶或專案、相關處理地理範圍與合約文件版本。
• 保存與刪除：各類資料與紀錄的保存位置、期限、刪除方法及負責人。
• 事件處理：停止服務權限、證據保存位置、通報窗口與複審日期。

台帳不必一開始就做成複雜的治理平台。試行階段可從受控試算表或既有服務管理流程開始，但必須有固定責任人、版本紀錄與定期複審。

三、台灣個資與跨境傳輸：把合法性與目的檢查放在設計前面

生成式 AI 專案只要涉及一般個人資料，就不應等到系統上線後才補做法務檢查。依《個人資料保護法》第 19 條，非公務機關蒐集或處理一般個人資料，須有特定目的，並符合列舉法定事由之一。

實務上，這代表專案啟動時應留下紀錄，說明為何需要該資料、用途是什麼、是否有較少資料的替代方案，以及哪些人可以接觸資料。這些內容也應與資料分級、提示模板和 RAG 文件範圍一致。

跨境資料傳輸要留下哪些內部審查紀錄？

若資料可能傳送至境外處理，建議將跨境傳輸從一般採購流程中獨立列出，至少記錄資料類型、傳輸路徑、處理目的、接收服務或處理者、可得知的地理處理範圍、合約與設定依據，以及例外情境的核准紀錄。

現行歷史版本的《個人資料保護法》第 21 條規定，非公務機關國際傳輸個人資料於列舉情形下，中央目的事業主管機關得限制之。因此，跨境使用不宜只用「供應商有資安認證」或「服務在雲端」作為結論。

另外，個資法官方系統標示，2025 年 11 月 11 日公布的修正條文全部或部分尚未施行，該批修正的施行日期由行政院定之。企業在建立控制措施時，應區分現行規定與尚未施行的修正內容，並持續追蹤正式施行狀態。

四、採購供應商必問：不訓練資料，不等於所有風險都消失

供應商若表示不會以企業資料訓練模型，這是重要資訊，但只能回答「訓練用途」的一部分。它不能自動推論資料完全不會保留、不會有人員依程序處理、不會跨區處理，或不存在其他受託處理者。

採購、法務、資安與技術團隊應將問題拆開，並要求以合約、官方文件、系統設定或書面答覆對應。

供應商安全問卷核心問題

• 輸入、輸出、附件、工具呼叫與系統日誌各自是否保存？保存在哪裡、保存多久？
• 企業能否設定保留、刪除或停用特定紀錄？設定的適用範圍是哪些功能？
• 資料是否用於模型訓練、服務改善、濫用偵測、品質維護或其他用途？每一種用途的條件為何？
• 是否存在人工覆核或支援處理流程？觸發條件、存取控制與紀錄方式為何？
• 資料會在哪些地理範圍處理？不同部署選項、端點或功能是否不同？
• 有哪些子處理者或外部服務參與處理？企業如何取得異動資訊？
• 服務支援哪些身分控管、管理者權限、稽核紀錄與資料匯出能力？
• 事件通知、協助調查、資料刪除與服務終止時的處理程序為何？

上述條件可能隨方案、模型、區域、端點、部署方式與合約而不同。採購時應以當下實際啟用的設定與條款逐項核對，不應用其他產品、其他租戶或過往文件替代確認。

五、RAG、向量資料庫與日誌：容易漏掉的資料副本

企業導入 RAG 或知識庫問答時，盤點範圍不應只停在原始文件所在資料夾。設計資料流與保存措施時，應一併確認解析後文字、切分片段、向量索引、檢索紀錄、提示內容、回覆紀錄、快取、評測集與備份等環節是否納入系統架構。

資料治理範圍應從原始文件延伸到整個檢索與生成流程。企業可為知識庫建立資料匯入前的篩選、清理與核准程序，讓資料來源與可用範圍可追溯。

RAG 上線前的資料與權限檢查

• 確認每一個資料來源的擁有者，以及允許被納入知識庫的範圍。
• 建立匯入前檢查：排除不應收錄的文件、過期內容、重複內容與不明來源資料。
• 記錄每份資料的來源、版本、匯入時間、分類、擁有者與移除方式。
• 將知識庫管理權限、資料匯入權限與一般查詢權限分開管理。
• 測試不同角色、不同部門與離職帳號在檢索與回答上的實際結果。
• 建立資料更正、下架、重建索引與清除衍生副本的作業程序。

原始文件的權限是否會在特定 RAG 或 SaaS 連接器架構中被完整繼承，不能靠產品名稱或設計假設判斷；同樣地，也不能直接認定一定會被繞過。正確作法是在實際部署中，以不同身分、不同文件分類與不同查詢情境進行驗證，並把測試結果列入上線核准紀錄。

六、提示注入與代理工具：以受控測試檢查資料、權限與動作邊界

提示注入是生成式 AI 的資安風險。AWS 在提示注入安全文件中將其定位為應用程式層級風險，並明示客戶負責保護自身應用程式、資料與部署在 AWS 上的資源。

對企業而言，風險處理不能只交給模型或單一平台設定，應回到自身的資料流、權限與工具設計，為每個使用案例安排受控測試與上線驗收。

把提示注入測試納入上線驗收

測試不必從複雜攻防開始。先為每個使用案例設計受控測試情境，確認資料揭露、角色權限與工具動作是否符合企業設定，並保存結果與改善紀錄。

• 依使用案例定義不應揭露的資料範圍，測試系統輸出是否符合該範圍。
• 以不同角色與權限進行測試，確認實際可查詢、管理與使用的功能符合設定。
• 測試工具可用時，寄送訊息、修改資料、建立紀錄或觸發外部流程等動作，是否符合既定核准條件。
• 檢視模型輸出、工具輸出與系統紀錄的呈現及稽核安排是否足以支援後續追查。
• 確認高風險行動必須經過人員檢視與明確核准，且可留下稽核紀錄。

內容護欄、系統提示與提示規則可以是多層防護的一部分；企業仍應以受控測試與權限設計檢查整體控制是否符合使用案例需求。

七、身分與權限：從聊天帳號延伸到資料、設定與工具

生成式 AI 系統的權限不只有「誰可以聊天」。企業至少要分開管理一般使用、資料上傳、知識庫維護、提示模板管理、工具或連接器設定、使用紀錄查閱與系統管理等角色。

建議的基本控制

• 採取最小權限：使用者只取得完成工作所需的資料與功能。
• 建立角色分離：避免單一人員同時可匯入敏感資料、修改權限與查看所有紀錄。
• 對管理功能採用較高強度的登入與核准程序。
• 將人員異動納入帳號停權與權限複查流程，避免離職或轉調後保留不必要存取。
• 定期檢視高權限帳號、共用帳號、服務帳號與外部協作帳號。
• 針對可執行外部動作的工具，額外限制可用範圍、可操作資料與核准條件。

八、上線前與上線後：測試、監控、事件應變缺一不可

生成式 AI 的安全不是一次性審查。資料來源、文件內容、使用者角色、模型設定與工具串接都可能變動，因此需要在上線前留下基準，在上線後持續檢查。

上線前核准清單

• 使用案例、資料分類與責任人已登錄於台帳。
• 輸入資料的特定目的、資料最小化與內部核准流程已完成檢視。
• 跨境處理情境已被識別，相關審查紀錄可追溯。
• 供應商對保留、刪除、處理地、人工處理、子處理者與事件通知的條件已逐項確認。
• RAG 資料來源、匯入流程、移除流程與實際權限測試已完成。
• 提示注入、越權存取、敏感資料揭露與工具動作的受控測試，已有結果與改善紀錄。
• 高風險輸出與高風險工具動作已定義人工覆核門檻。
• 停止服務、保存證據、內部通報與對外溝通的責任分工已被演練。

發生資料外洩或錯誤回覆時，誰該做什麼？

企業應在制度中預先指定，而非等事件發生才臨時協調。一般可分成四個角色：

• 服務負責人：有權暫停特定功能、關閉連接器或停止資料匯入。
• 資安與技術維運：保存相關系統紀錄、設定快照與時間線，協助界定影響範圍。
• 資料擁有者與業務單位：判斷受影響資料、使用者、客戶與業務流程。
• 法務、隱私與管理階層：依適用法令、契約與事件事實決定後續通知、溝通與改善措施。

處理順序可概括為：先控制影響範圍，再保全證據；先確認資料流與存取範圍，再決定通知與修復作法。未經保存就直接清除所有紀錄，可能會增加後續釐清困難；但保留紀錄本身也應遵循既有的存取與保存控制。

九、把清單變成持續治理，而非一次性文件

NIST 的AI 600-1《Generative AI Profile》是 AI RMF 1.0 針對生成式 AI 的跨領域補充文件。企業可參考這類風險管理框架，將資料安全工作納入既有的治理、資安、採購與事件管理節奏；但指引本身不是台灣企業的法定合規認證。

建議至少在下列情況重新複審 AI 使用案例：新增資料來源或連接器、調整模型或部署選項、擴大使用者範圍、啟用可執行動作的代理功能、發生重大異常，或供應商條款與設定有重大變更時。

可落地的原則：先限制資料與權限，再開放功能；先完成受控測試，再串接工具；先定義停損與通報，再擴大使用範圍。

結論：企業 AI 治理的核心，是知道資料去了哪裡、誰能動它

生成式 AI 可以協助企業提升工作效率，但前提是資料處理不能變成不可見的黑盒子。從資料分級、使用台帳、跨境審查、供應商問卷、RAG 權限測試到提示注入受控測試，每一項控制都在回答同一個問題：企業是否仍能掌握資料、權限與行動的邊界？

若答案還不明確，最好的下一步通常不是擴大導入，而是先把高風險使用案例縮小到可驗證、可追蹤、可停止的範圍，再逐步擴充。