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

將檔案、表格、合約、政府文件或者程式碼貼入 AI 之前，唔好只問：呢個 AI 安唔安全？更實際係問：如果呢份資料外洩，會唔會傷害到個人、公司、公共利益或合規狀況？服務會點樣保存、再用你輸入的內容？邊個可以存取？你所屬機構有冇批准？出事時追唔追查到、補唔補救到？

歐洲資料保護委員會 EDPB 的 LLM 私隱文件，專門討論大型語言模型系統的私隱風險同緩解方法；美國 NIST 的生成式 AI 風險管理文件，亦將資料來源、資料保護、資料保留、商業使用、退出選項、影響評估、事故應變、監察和風險式控制列為治理項目。

本文所講的「一般公開型 AI」，係指未經你公司或機構核准，而你亦未確認輸入內容會否被保留、商業使用、再處理、用作改善服務、是否有退出機制、誰可存取，以及是否有監察和事故應變安排的雲端 AI 工具。這不代表所有 AI 都不能處理敏感資料；重點係先要有可核實的資料治理答案。

先講結論：答唔到，就唔好上傳原文

可識別個人資料、公司機密、未公開政府文件，不應直接貼入一般公開型 AI。即使你只係想叫 AI 摘要、翻譯、改寫或除錯，只要內容可能揭露個人、客戶、內部決策、系統憑證或受保護資訊，就應先改成去識別化摘要、刪走敏感欄位，或者改用機構核准的受控環境。

最穩陣的判斷標準唔係 AI 品牌，而係四件事：資料是否敏感、服務會點樣保留或使用資料、機構是否明確准許、出事後能否追蹤同處理。NIST 將資料保護、資料保留、監察、事故應變、退出選項和風險式控制列為生成式 AI 治理項目；如果這些條件無答案，就不應上傳原文。

個人資料、公司機密、政府文件點分？

資料類型	原則	上傳前要確認
個人資料	唔好直接上傳可識別個人的原文。如真有需要，先做資料最小化、遮蔽或去識別化，並確認服務條款及機構規範准許。	EDPB 將 LLM 私隱風險同緩解列為專門議題；NIST 亦把資料保護、資料保留、影響評估和監察列入生成式 AI 治理。
公司機密	唔好放入未經核准的公用 AI。合約、客戶名單、投標或併購資料、法務文件、源碼、密鑰同憑證，都應當作高風險資料處理。	NIST 的治理項目涵蓋商業使用、資料來源、資料保護、資料保留、事故應變、監察和安全軟件開發。
政府文件	先分清已公開、低敏感、依法可再用的資料，與未公開內部文件、政策草稿、調查或執法資料；後者不應放入一般公開型 AI。	歐盟聯合研究中心 JRC 報告把公共部門使用生成式 AI 列為專門領域；歐洲議會附件中的案例摘要亦提到使用官方 Bundestag 資料時避免個人或敏感資訊。

上傳前，先問 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。先遮蔽、摘要、最小化；如果任務真的需要原文，改走批核流程和受控工具，並確認資料保護、資料保留、存取權限、監察和事故應變機制。