資料可唔可以交畀 AI？個人資料、公司機密、政府文件判斷指南

上傳前，先問 5 條問題

只要有一條答唔到，就先唔好將原文放入一般公開型 AI。

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

提示詞入面寫一句「請保密」，唔等於安全控制。真正要確認的，是資料點樣被保存、誰可存取、是否可退出再利用、出事時由誰處理，以及你所屬機構是否准許。

紅黃綠燈：邊啲可以，邊啲要停一停？

以下清單係將資料保護、資料保留和風險式控制原則，轉成日常判斷。它不是法律意見；實際做法仍要跟你所在地法律、合約、資安、法務、個人資料和文件管理規範。

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

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

公開不等於零風險。如果公開資料仍含個人資料或敏感資訊，仍要按私隱風險同資料保護原則處理。

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

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

這類資料未必永遠不能用 AI 處理，但不應在沒有批核、沒有保留規則、沒有監察和事故應變機制時，直接丟入一般公開型 AI。

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

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

去識別化：唔係淨係刪走姓名

刪走姓名未必夠。如果證件號碼、電話、電郵、地址、戶口、案號、罕見職銜、日期加地點的組合，仍然可以指向某個人或案件，私隱風險仍然存在。EDPB 文件關注的核心之一，就是 LLM 系統中的私隱風險與緩解；所以上傳前，應一併移除或改寫可識別資料、可回推細節和非必要欄位。

較安全的做法包括：用代稱取代真實姓名同公司名；只提供必要片段；將原始文件改寫成抽象情境；名單、紀錄或表格先做彙總；如果任務真的需要處理原文，就改用機構核准、有權限控制和記錄的工具與流程。

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

公共部門用生成式 AI，唔係簡單一句全面禁止或全面開放。JRC 的生成式 AI Outlook 報告把公共部門應用列為專門討論領域；歐洲議會附件中的案例摘要亦提到使用德國聯邦議院 Bundestag 的官方資料，並避免個人或敏感資訊。

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

最簡單的決策規則

如果資料外洩會傷害個人、機構、公共利益或合規狀況，就唔好將原文交畀一般公開型 AI。先遮蔽、摘要、最小化；如果任務真的需要原文，改走批核流程和受控工具，並確認資料保護、資料保留、存取權限、監察和事故應變機制。