把檔案、表格、合約、公文或程式碼貼進 AI 之前，不要只問「這個 AI 安不安全」。更精準的問題是：這份資料外流會不會造成傷害？服務會如何保留或再利用輸入內容？誰能存取？組織是否允許？出事後能不能追蹤與處理？NIST 的生成式 AI 風險管理文件把資料來源、資料保護、資料保留、商業使用、退出選項、影響評估、事件回應、監控與風險式控管列為治理項目；EDPB 的 LLM 隱私文件也聚焦大型語言模型系統的隱私風險與緩解方式。^[1][2]

本文所說的「一般公開型 AI」，指的是尚未經組織核准，且你尚未確認資料留存、商業使用或再處理、退出選項、存取權限、監控與事件回應條件的雲端 AI 工具。這不代表所有 AI 都不能處理敏感資料；重點是必須先有可驗證的資料治理答案。^[2]

先講結論：答不出來，就不要上傳原文

可識別個資、公司機密與未公開政府文件，不應直接貼進一般公開型 AI。即使只是請 AI 摘要、翻譯、改寫或除錯，只要輸入內容可能揭露個人、客戶、內部決策、憑證或受保護資訊，就應先改成去識別化摘要、刪除敏感欄位，或改用組織核准的受控環境。^[1][2]

最安全的判斷標準不是 AI 品牌，而是四件事：資料是否敏感、服務如何保留或使用資料、組織是否明確允許、出事後能否追蹤與處理。NIST 將資料保護、資料保留、監控、事件回應、退出選項與風險式控管列為生成式 AI 治理項目；如果這些條件沒有答案，就不應上傳原文。^[2]

個資、公司機密、政府文件怎麼判斷？

資料類型	原則	上傳前要確認
個資	不要直接上傳可識別個人的原文。若有必要，先做資料最小化、遮蔽或去識別化，並確認服務條款與組織規範允許。	EDPB 將 LLM 隱私風險與緩解列為專門議題；NIST 也把資料保護、資料保留、影響評估與監控列入生成式 AI 治理。[1][2]
公司機密	不要上傳到未核准的公用 AI。合約、客戶名單、投標或併購資料、法務文件、原始碼、金鑰與憑證都應以高風險方式處理。	NIST 的治理項目涵蓋商業使用、資料來源、資料保護、資料保留、事件回應、監控與安全軟體開發。[2]
政府文件	先區分已公開、低敏感、依法可再利用的資料，與未公開公文、內部簽呈、政策草案、調查或執法資料。後者不應放進一般公開型 AI。	JRC 報告把公部門使用生成式 AI 列為專門領域；歐洲議會附件中的案例摘要也提到使用官方 Bundestag 資料時避免個人或敏感資訊。[3][11]

上傳前先問 5 個問題

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

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

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

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

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

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

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

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

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

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

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

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

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

去識別化不是只刪掉姓名

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

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

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

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

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

最簡單的決策規則

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