資料可以上傳到 AI 嗎？個資、公司機密與政府文件安全指南

上傳前先問 5 個問題

只要有一題答不出來，就先不要把原文放進一般公開型 AI。

1. 內容是否含個資或敏感資訊？ 只要資料可能識別個人，或涉及隱私風險，就不應直接貼原文；EDPB 文件正是針對 LLM 系統的隱私風險與緩解方式提出討論。
2. 服務會保留輸入或輸出嗎？保留多久？ NIST 將資料保留列為生成式 AI 風險管理項目。
3. 資料會不會被商業使用、再處理或用於改進服務？是否有退出機制？ NIST 同時列出商業使用、資料保護、資料保留與退出選項等治理面向。
4. 誰可以用這項工具，使用行為能否追蹤？ NIST 提到使用者資格、避免匿名使用與監控；實務上，這代表組織需要知道誰在用、為什麼用，以及用了哪些資料。
5. 組織是否做過影響評估、事件回應與風險式控管？ 這些都是 NIST 生成式 AI 風險管理文件列出的項目。

不要把提示詞裡的一句「請保密」當成安全控制。真正需要確認的是資料會怎麼被保存、誰能存取、是否可退出再利用、出事時誰負責處理，以及你的組織是否允許。

紅黃綠清單：哪些可以，哪些先不要？

以下清單是把資料保護、資料留存與風險式控管原則轉成日常判斷；它不是法律意見，仍要以你所在組織的資安、法務、個資與公文管理規範為準。

綠燈：可以考慮，但仍要檢查條款

• 已公開、低敏感，且你確認有權使用的資料。
• 已去識別化、刪除敏感欄位或改寫成摘要後，無法合理回推個人、客戶、案件或內部機密的資料。
• 只保留必要背景的問題描述，而不是整份合約、公文、客戶資料表或程式碼庫。

公開不等於零風險。如果公開資料仍含個資或敏感資訊，仍要回到隱私風險與資料保護規則處理。

黃燈：先改寫、遮蔽，或走核准流程

• 含有客戶、員工、供應商、案件當事人或民眾資訊的資料。
• 合約草稿、財務資料、內部簡報、會議紀錄、法務意見或政策草案。
• 原始程式碼、技術文件、系統架構圖，尤其是可能包含金鑰、憑證或弱點資訊的內容；NIST 將安全軟體開發與風險式控管列為生成式 AI 治理項目。
• 政府機關內部文件、未公開公文、簽呈、評選資料或跨機關協作文件；公部門使用生成式 AI 時仍需處理個人或敏感資訊風險。

這類資料未必永遠不能用 AI 處理，但不應在沒有核准、沒有留存規則、沒有監控與事件回應機制時丟進一般公開型 AI。

紅燈：不應上傳到一般公開型 AI

• 依法或依內規禁止外流的資料。
• 機密等級文件，或涉及國安、執法、調查、採購評選等高敏感資料。
• 帳號密碼、API key、私鑰、憑證、存取權杖，或任何可用來進入系統的資訊。
• 你無法確認來源、授權、留存、刪除與再利用條件的資料。

去識別化不是只刪掉姓名

若證號、電話、Email、地址、帳號、案號、稀有職稱、日期地點組合仍能指向特定人或案件，隱私風險可能仍在。EDPB 文件的核心關切之一就是 LLM 系統中的隱私風險與緩解；因此，上傳前應把識別資訊、可回推的細節與非必要欄位一併移除或改寫。

比較安全的做法是：用代稱取代真實姓名與公司名；只提供必要片段；把原始文件改寫成抽象情境；對名單、紀錄或表格先做彙總；真的需要處理原文時，改走組織核准的工具與流程。

政府文件：公開資料和內部文件要分開

公部門使用生成式 AI 不是單純禁止或開放的二分題。JRC 的生成式 AI Outlook 報告把公部門應用列為專門討論領域；歐洲議會附件中的案例摘要也提到使用官方 Bundestag 資料，並避免個人或敏感資訊。

可考慮的通常是已公開、低敏感、可依法使用的官方資料；需要特別保守的則是未公開公文、內部簽呈、政策草案、調查資料、執法資料、採購評選資料，以及任何含個資或敏感資訊的文件。前者仍要檢查使用條件；後者不應直接丟進一般公開型 AI。

最簡單的決策規則

如果資料外流會傷害個人、組織、公共利益或法遵狀態，就不要把原文交給一般公開型 AI。先遮蔽、摘要、最小化；若任務真的需要原文，改走核准流程與受控工具，並確認資料保護、資料留存、存取權限、監控與事件回應機制。