企業 AI 導入怎麼兼顧機密資料？用資料拆分找到適合的部署方式

依照不同需求，分別決定雲端、地端與資料治理的最佳配置

企業常把「這筆資料能不能用 AI」當成單一決策，但治理強度、部署位置與採購時機其實是三層獨立判斷，同一項工作可能治理要嚴，運算位置卻仍能放在雲端。

企業容易把「這件事該不該做」跟「該去哪裡做」混為一談，直接跳到「機密資料就一定要地端化」的結論。實際上這是三個各自獨立、答案可能不一致的問題：一份客戶投訴紀錄，治理強度可能因為涉及個資而要求主管核准與完整紀錄；但只要先完成去識別化，運算本身仍可以放在雲端，不需要因為敏感就整包搬進地端機房。反過來，一項不涉及機密的產線異常偵測，可能因為要求秒級反應與離線可用，即使治理強度不高，部署位置仍必須留在邊緣或地端。至於要不要為此採購硬體，則是第三層獨立的投報判斷，不該跟前兩層的答案綁在一起自動觸發。企業如果不先把這三層拆開問，很容易在治理會議上把「風險高不高」和「該花多少錢買設備」混成同一個問題，討論到最後反而卡住，什麼都沒決定。

企業 AI 治理不是踩煞車，而是建立安全的使用路徑

企業 AI 治理不等於全面禁止生成式 AI。企業 AI 治理的目的，是依風險建立可使用、必須覆核、需要核准與禁止自動執行的清楚邊界。

全面封鎖看似安全，卻可能讓員工改用個人帳號、私人裝置或公司看不見的工具，形成「影子 AI」（Shadow AI）。企業若只發布一句「不得洩漏機密」，員工仍然不知道會議記錄、客戶來信、報價內容或程式碼能不能貼進 AI。

台灣數位發展部公布的「人工智慧風險分類框架」採用盤點應用情境、識別風險、評估風險及應對風險四個流程，顯示治理方向是依應用風險選擇管理措施，而不是對所有 AI 採取相同限制（數位發展部，2026 年 7 月）。該框架目前主要作為主管機關的共通評估標準，不能直接解讀成所有中小企業都負有相同的稽核或裁罰義務。

用「資料敏感度 × 決策影響」決定 AI 治理強度

資料越敏感、AI 結果影響越重大，治理強度就應越高。企業應逐步加入工具限制、人工覆核、主管核准、操作紀錄與停止權。

「資料敏感度」衡量輸入內容一旦外洩的損害，例如公開資料、內部營運資料、客戶個資、製程參數與核心營業秘密。「決策影響」衡量 AI 出錯後的後果，例如文案草稿容易修正，付款、聘僱、合約、生產控制與客戶權益則可能造成重大損失。

這兩個軸不能只加總成一個分數。高敏感資料即使只用來摘要，也可能需要在受控環境處理；公開資料即使沒有外洩問題，只要 AI 會直接做出高影響決策，仍應保留人工核准。NIST 的生成式 AI 風險管理文件也強調，治理措施應配合組織目標、法律要求、風險容忍度與資源條件，而不是套用單一固定答案（NIST，2024 年 7 月）。

以餐飲或零售業為例，使用公開菜單撰寫社群文案屬於低敏感、低影響；使用匿名化客訴內容歸納常見問題，屬於較敏感但影響可控；根據客戶資料自動核准退款或差別定價，則涉及較高決策影響，不應讓 AI 在無人覆核下直接執行。

哪種資料一定不能直接送進外部 AI？先過五條硬紅線

企業不能只用「機密／非機密」二分法判斷。

只要下列任一條成立，原始資料就不應進入未經企業核准的外部生成式 AI；企業必須改採刪除、拆分、去識別化、受控企業雲或地端處理。

1. 法規紅線：法律或主管機關規範限制資料的蒐集、利用、傳輸或跨境處理。
2. 契約紅線：客戶、供應商、保密協議或委託契約禁止交由外部服務處理。
3. 身分紅線：資料仍能直接或間接辨識個人，且缺乏合法目的、必要性或經核准的保護措施。
4. 營業秘密紅線：配方、製程參數、未公開報價、核心程式碼或策略一旦外洩，損害超過企業可承受範圍。
5. 安全憑證紅線：密碼、私鑰、存取權杖、系統連線資訊及可用來取得權限的內容。

可以將判斷公式簡化為：

外部 AI 可用性 = 無硬紅線 × 僅提供最低必要資料 × 使用核准工具 × 輸出可被人工攔截。

任何一項不成立，就不能把原始資料直接送入外部 AI。硬紅線也不代表整個工作永遠不能使用 AI，而是必須改變資料形式、部署位置或工作流程。

機密資料不一定整包搬到地端，可以先把資料拆開

企業可以將識別資料與分析內容分開，在本機完成遮罩、記號化或資料最小化，只把完成任務所需的最低限度內容送往核准的 AI。

資料拆分的核心，不是宣稱「處理過就絕對安全」，而是減少外部 AI 能接觸的內容。企業可以先在內部工具移除姓名、電話、客戶編號、精確金額、配方代號與其他直接或間接識別欄位，再用無意義的代碼取代；雲端 AI 完成分類、摘要或文字生成後，結果回到內部環境重新配對。

1. 原始資料保留在企業內部。
2. 本機工具辨識並移除不必要欄位。
3. 以不可直接識別的代碼取代必要索引。
4. 僅將任務所需內容送入核准的 AI 服務。
5. AI 結果回到內部系統重新配對。
6. 人工檢查內容、對象與用途後才正式使用。

數位發展部說明，遮罩、記號化、雜湊化與泛化都屬於常見的去識別化方式，但處理後的資料仍可能與外部資料比對而重新識別。因此，去識別化不能取代合法使用目的、資料最小化、存取權限與供應商管理（數位發展部，日期不明）。

用「資料敏感度 × 即時性需求」選擇雲端、地端或邊緣運算

非機密且可容忍延遲的工作適合雲端優先；涉及高度機密或必須秒級反應的工作，才優先評估地端或邊緣運算。

治理矩陣決定「管多嚴」，部署矩陣則決定「放哪裡」。即時性需求是部署位置的重要路由因子：一般文件摘要可以等待數秒或數分鐘，產線異常偵測、工安警示或設備控制卻可能要求秒級反應，網路中斷也不能停止。

雲端、地端與邊緣運算不是互相排斥的選項。成熟的做法通常是雲地混合：通用模型能力由雲端提供，機密原始資料與即時處理留在內部，兩者之間以資料拆分、權限與稽核紀錄建立邊界。ISO/IEC 42001 將風險、資料治理、生命週期控制、績效監測與持續改善放在同一套 AI 管理系統中，也說明部署位置只是治理的一部分（ISO，日期不明）。

匿名案例：製造業不想洩漏製程，又負擔不起一次全面地端化

一間傳統製造業者希望使用 AI 提升管理與生產效率，但內部最擔心的是製程參數、異常處理知識與客戶限制資料外流。若一開始就全面採購地端設備，企業尚未掌握實際工作負載，也缺少足夠的維運人力與投報證據。

導入規劃因此沒有採取「先買設備，再找用途」，而是先把應用分成三路：公開資訊整理與一般報告草稿採雲端優先；含敏感欄位但可拆分的工作，先在本機移除識別內容，再將最低必要資訊送往核准服務；核心製程與即時產線判讀則保留在地端候選清單，先估算效益與內部資源，再做採購決策。

這個案例的價值不是證明某套設備已帶來多少成果，而是避免企業在效益尚未確認前，把「資安焦慮」直接轉成昂貴的硬體採購。每個階段只做一個可驗證的小決策，治理與導入才能同時前進。

何時該買地端設備？紅線看投報，一般場景看用量

紅線場景應先驗證商業效益與投報，再決定是否地端化；一般場景則先使用雲端量測真實用量，跨過成本交叉點後才考慮採購。

資料紅線只代表「如果要讓 AI 處理，就應留在受控環境」，不代表企業一定要立即購買硬體。如果製程知識庫或即時品檢沒有明確效益、資料品質不足，也沒有人能維運，倉促採購只會產生閒置設備。

企業可以先讓非紅線用例在雲端進行概念驗證（Proof of Concept，PoC），記錄每月請求量、運算時間、延遲、傳輸及人工覆核成本。紅線用例無法直接把原始機密送上公有雲試驗，應先使用合成資料、去識別化樣本或隔離測試環境驗證流程，再依投報決定是否投入地端設備。

員工會使用 AI 與 Vibe Coding，本身就是企業競爭力

員工具備 AI 與 Vibe Coding 能力後，可以製作資料清理、去識別化及本機前處理小工具，降低企業初期導入門檻。

Vibe Coding 是以自然語言描述需求，讓 AI 協助產生與修改程式碼的開發方式。對沒有大型資訊團隊的中小企業而言，員工可以先處理欄位遮罩、檔案格式轉換、敏感字詞偵測、資料切分與結果檢查等小型工作，不必每個需求都等待大型系統專案。

Vibe Coding 降低的是開發門檻，不是安全與品質門檻。涉及機敏資料的工具應遵循以下條件：

• 使用合成或去識別化測試資料開發，不直接連接正式資料庫。
• 僅開放完成任務所需的最小權限。
• 由具備程式能力的人員進行程式碼審查與安全檢查。
• 為關鍵轉換建立測試案例，避免錯遮、漏遮或配對錯誤。
• 保存版本、操作與錯誤紀錄，並設計復原方式。
• 正式上線前由資訊、資安或被授權的負責人核准。

員工 AI 素養的價值不只是「會下提示詞」，而是能辨認資料邊界、驗證輸出、描述工作規則，並與資訊人員共同把安全措施嵌回既有流程。

中小企業的最小可行 AI 治理，可以先做五件事

中小企業可以先盤點工具、完成資料分級、選定低風險工作、設置人工覆核，再以效益與用量決定是否擴大部署。

企業不需要第一天就完成 ISO/IEC 42001 認證，也不需要立即購買 GPU 伺服器。最小可行治理的目標，是讓員工知道現在可以怎麼做，並讓企業能從實際使用紀錄修正規範。

1. 盤點使用現況： 訪談各部門正在使用的 AI 工具、帳號、資料與任務。
2. 完成資料分級： 至少區分公開、內部、機密與受管制資料。
3. 選一至兩個低風險用例： 優先選擇結果可由人工攔截、錯誤容易修正的工作。
4. 設置覆核與異常回報： 指定誰檢查、誰核准、發現問題時誰能停止。
5. 量測效益與用量： 記錄工時、錯誤率、使用量與成本，再決定是否擴大或採購地端設備。

數位發展部的風險分類流程與 NIST AI RMF 都強調持續治理，而非一次性採購。企業 AI 導入的第一項成果，不一定是完整系統；更重要的成果，是建立一條員工敢用、管理者看得見、風險能被攔截的工作路徑。

常見問題

Q公司是不是應該直接封鎖 ChatGPT？

公司不宜把封鎖當成唯一措施。涉及個資、營業秘密或高影響決策的工作可以限制使用，但企業也應提供核准工具與安全流程，避免員工轉用無法監控的個人帳號。

Q使用企業版 AI 就不會外洩資料嗎？

企業版 AI 通常提供較完整的資料使用條款、帳號與管理功能，但不代表百分之百安全。企業仍須確認供應商條款、資料保存、權限、外掛與串接方式，並防範員工誤傳及不當分享。

Q去掉姓名後，資料就不算個資了嗎？

不一定。電話、地址、訂單、時間、職務或其他欄位組合後，仍可能間接識別特定個人；企業需要評估重新識別風險，而不是只刪除姓名。

QVibe Coding 做的內部工具可以直接上線嗎？

不建議直接上線。Vibe Coding 產生的程式碼仍須經過程式碼審查、測試、權限限制與上線核准，涉及機敏資料時更應先使用合成資料驗證。

Q地端模型一定比雲端 AI 安全嗎？

不一定。地端部署可以降低資料外傳風險，但仍可能發生權限配置錯誤、設備未更新、內部人員誤用及備份外洩；地端設備也需要持續維運與監控。

Q沒有資訊部門的小公司能做 AI 治理嗎？

可以先從一頁式資料分級、核准工具清單及人工覆核規則開始。低風險場景先用受控的雲端服務驗證效益，再依資料、用量與投報逐步增加技術控制。

Q哪些工作一定要保留人工審核？

付款、聘僱、合約、法律、醫療、安全、生產控制及會直接影響客戶權益的工作，原則上應保留具權責人員的審核或核准。實際要求仍須依產業法規、契約及風險評估調整。

延伸閱讀

• 如何串接 Email、ERP 與企業資料，自動執行完整工作流程？：資料拆分之外，這篇補上串接 Email 與 ERP 時的五層授權分級與資安控管架構。
• 企業 AI 規模化怎麼診斷、怎麼衡量？七個障礙與五層指標：資料治理談妥後，下一步是規模化怎麼診斷、怎麼衡量成效。

參考資料

1. 數位發展部，〈訂定「人工智慧風險分類框架」，並自即日生效〉，2026 年 7 月 7 日。存取日期：2026 年 8 月 24 日。
2. 數位發展部，〈隱私強化技術：平衡資料保護與資料應用〉，發布日期不明。存取日期：2026 年 8 月 24 日。
3. National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” July 26, 2024. Accessed August 24, 2026.
4. International Organization for Standardization, “ISO/IEC 42001:2023 - AI management systems,” publication date not shown. Accessed August 24, 2026.

關於作者 {#author}

Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。

最後更新：2026-08-24