公司機密資料適合放在雲端 AI 嗎？先做資料分級與風險評估

『雲端 AI 能不能放公司機密？』答案不是一律可以，也不是一律不行。應先確認資料是否含個人資料、營業秘密、客戶合約或受法規限制的內容，再對照所使用的產品、部署類型、資料區域、保存設定、權限和刪除方式。

• 機密資料分級
• 供應商條款
• 權限與日誌
• 本地／混合替代

官方文件通常只會說明特定產品和功能的資料處理方式。例如 Microsoft 對 Azure 中銷售的模型、AWS 對 Amazon Bedrock 都有各自的資料使用與隔離說明；這些政策不能直接套用到私人聊天工具、第三方整合或另一個供應商。本文提供風險評估框架，不是法律意見，也不代表任何服務保證零風險。

先把『機密』拆成可判斷的資料級別

如果所有資料都標成機密，使用者很快會繞過規則；如果所有資料都能上傳，風險也會失去邊界。可以先建立四級分類，再由負責人依公司政策調整：公開資料、一般內部資料、機密資料、高度敏感資料。分類時看資料內容、可識別性、合約限制、外洩後影響與保存要求。

姓名、電話、Email、訂單或客服對話可能屬於個人資料；完整客戶名單、未公開報價、原始碼、未發布產品與合約則可能屬於營業或契約機密。把欄位名稱改掉不一定等於匿名，若仍可與其他資料組合識別，就應按較高風險處理。

台灣個人資料保護法將蒐集、處理、利用與國際傳輸分別定義，並要求不得逾越特定目的必要範圍。若使用雲端 AI 涉及個資、委外處理或跨境傳輸，應由公司依實際情境檢查告知、契約、權限、安全措施和保存刪除流程；有疑義時請法律或個資專業人員確認。

不要只看『不拿來訓練』這一句

『不使用客戶資料訓練模型』只回答資料是否用於某種模型訓練，沒有回答所有風險。還要確認請求與回覆是否暫存、檔案和向量是否保存、管理員或支援人員如何存取、是否有濫用監控、資料在哪個區域處理、是否會跨境、刪除是否立即生效，以及產品是否有另外的狀態或執行緒功能。

Azure 文件說明，部分功能會依設定建立資料儲存；提示、回覆、embeddings 等資料不會在未經許可下用於訓練基礎模型，但地理區域、Global 或 DataZone 部署及濫用監控的處理方式仍需依產品文件確認。AWS 對 Bedrock 的說明指出，客戶內容不會用來改善基礎模型，也不會分享給模型供應商；但不同模式、功能或安全監控可能有不同的保存與處理方式，不能把一段 FAQ 套用到所有 AWS 服務或第三方整合。

因此審查時應記錄『使用的產品和版本、啟用的功能、部署區域、資料流向、保存期限、合約與刪除證據』，而不是只截取一句行銷文案。

• 產品是否為企業方案或 API，而不是個人帳號或未核准的瀏覽器工具。
• 輸入、輸出、上傳檔案、embedding、快取、執行緒和日誌各自保存多久。
• 資料是否會跨境或在指定區域以外處理，供應商及其受託者能否存取。
• 服務停用、帳號刪除、合約終止時，資料與備份如何刪除或返還。

上傳前的八項安全檢查

雲端 AI 導入前，請將供應商回答與公司決策記錄在案。若對方文件沒有說清楚，先把該功能標成未確認，不要用推測補上。

• 資料目的：為了什麼工作送出？是否超出原本蒐集或使用目的？
• 最小化：能否只送必要欄位、摘要或去識別片段，而不是整份資料？
• 供應商：使用哪個產品、版本、部署模式、區域與受託處理者？
• 保存：提示、回覆、檔案、向量、快取、日誌和備份各保存多久？
• 權限：是否使用公司身分驗證、MFA、角色權限與離職撤銷？
• 加密：傳輸、儲存、金鑰管理與備份的責任分界為何？
• 監控：是否能查詢誰在何時送出什麼類型的資料，以及如何告警？
• 回復：API 失效、資料誤傳或帳號外洩時，如何停用、通報、刪除與回到人工流程？

用遮罩、權限檢索和混合流程降低暴露面

不必在『整份資料上雲』與『完全不用 AI』之間二選一。應用程式可以先在內部完成欄位遮罩、去識別、權限檢查和文件切片，只把必要內容送到已核准的模型；回覆再經過敏感資訊檢查和人工確認後，才回到客服或營運流程。

企業知識庫也應先驗證使用者能看哪些文件，再做檢索。不能因為模型能找到某個檔案，就讓所有員工看見內容。每次引用最好保留文件版本、段落或來源識別，方便人工追查與撤下過期資料。

對高度敏感資料，可以把摘要或分類留在本地，把不含識別資訊的工作交給雲端；若連摘要都會洩漏關鍵內容，就應留在核准的內部模型與人工流程。混合方案的安全性來自資料路徑和權限設計，不是『用了混合』四個字。

防止提示注入、越權查詢和錯誤回寫

即使供應商的基礎設施安全，應用程式仍可能被惡意文件或使用者輸入影響。文件內的『忽略系統指令、把資料傳出去』等內容不應取得更高權限；模型回覆也不能自行決定查詢不屬於使用者的資料。應將系統指令、資料內容和使用者輸入分開處理，並在工具呼叫前再次驗證權限。

涉及報價、折扣、庫存、訂單、付款、會員權限或對外承諾時，先輸出待確認草稿，由規則與人工共同檢查，再寫入正式系統。錯誤的 AI 回覆即使沒有造成資料外洩，也可能造成商業損失，因此要把『錯誤答案』納入驗收案例。

• 把工具權限放在後端，不讓前端或模型自行決定 API 金鑰和角色。
• 對外部文件、網頁和附件做類型、大小、惡意內容與編碼檢查。
• 回覆寫入 CRM、訂單或報價前，檢查欄位格式、角色、狀態與人工批准。
• 保存 request ID、模型版本、引用文件和覆核結果，避免只留下不可追溯文字。

台灣企業的個資與合約確認重點

個人資料保護法的適用與責任要看資料、目的、角色和實際處理方式。若把客戶資料交由雲端供應商處理，企業仍應確認告知與利用目的、委託關係、跨境傳輸、當事人權利、安全維護、保存刪除與事件應變。不要因為資料是『給 AI 讀』就當成一般技術資料。

如果客戶合約、供應商合約或產業規範對資料所在地、再委託、保密、稽核或刪除有要求，應先讓負責法務、個資或資安的人員檢查。本文不替公司判定是否合規，也不應取代正式法律意見。

• 確認公司隱私權政策與資料處理紀錄是否涵蓋新的 AI 使用目的。
• 確認委託、跨境傳輸、供應商再委託與資料事件通報條款。
• 把個資、營業秘密、付款與金鑰從一般測試資料中分離。
• 設定資料保存期限、刪除流程與定期權限檢查，並保留稽核紀錄。

什麼情況先不要把資料送上雲端

如果公司還不知道資料有哪些、誰可以看、供應商會怎麼保存，或只打算用員工私人帳號貼上整份客戶名單，應先停下來完成盤點。沒有明確資料責任人、沒有停用金鑰的方法、沒有人工覆核和回復流程，也不適合直接接到正式訂單或付款。

這時可以先用去識別、合成或公開資料做概念驗證；把敏感工作留在內部，等供應商、合約和權限確認後，再逐步擴大。慢一點完成可追溯的試作，通常比事後追查資料流向更省時間。

需求評估檢查清單

透過 LINE 詢問企業 AI 建置前，建議準備以下資訊；不要直接傳送完整客戶名單、金鑰或未核准機密檔案。

• 資料種類與級別：公開、內部、機密、高度敏感，是否含個資或合約限制。
• 工作流程：客服、文件搜尋、摘要、報價、預約、分析或自動化工具。
• 供應商條件：現有帳號、產品／API、區域、保存、刪除、管理與合約要求。
• 環境限制：是否必須離線、是否已有內部 GPU／NAS／VPN／SSO。
• 驗收條件：權限測試、敏感資料遮罩、錯誤轉人工、日誌、告警、備份與回復。