摘要
如果你已經用 Dify 做出第一個 FAQ 客服助理，也把 SOP、產品型錄、報價規則整理成知識庫，下一步不是急著開給全公司用，而是先問一個比較不熱血、但更重要的問題：
如果它答錯、洩露資料、引用過期規則，或員工把不該輸入的個資貼進去，誰負責？
這篇不會把 AI 治理寫成大公司才看得懂的厚文件，而是整理成台灣中小企業可以先做的「最小可行治理」：
- 權限要怎麼分。
- 日誌要看什麼、留多久。
- 個資與敏感資料要怎麼避開。
- 供應商條款至少要檢查哪幾項。
- 員工使用規範與上線核准怎麼落地。
本文不是法律意見；若你的應用牽涉醫療、金融、法律、高額交易、未成年人或大量個資，請務必請法務、資安或外部顧問一起審查。
Dify 系列閱讀順序
這篇是 Dify 系列第 5 篇。前四篇負責把應用做出來，本文負責讓它可以更安全地上線。
| 順序 | 文章 | 你會解決的問題 |
|---|---|---|
| 1 | 為什麼台灣中小企業先從 Dify 做可控內部 AI 應用 | 先判斷 Dify 是否適合你的公司 |
| 2 | 用 Dify 選第一個必成功用例 | 在客服、業務、內勤中挑第一案 |
| 3 | 7 天做出可上線 FAQ 客服助理 | 把提示詞變成可交付流程 |
| 4 | 知識庫 / RAG 實戰整理法 | 讓 Dify 依據 SOP、型錄與報價規則回答 |
| 5 | 本文 | 上線前把權限、日誌、個資與條款講清楚 |
| 6 | Dify 上線後怎麼證明有用 | 用 KPI 證明成效並規劃擴張 |
完整路線整理在：Dify AI 工作流導入路線圖。
目錄
- 先講結論：Dify 上線前要過 7 個治理門檻
- 權限：不要讓所有人都看得到所有知識庫
- 日誌：它不是監控員工，而是讓錯誤能被追蹤
- 個資與敏感資料：先建立「禁止輸入」與「遮罩」規則
- 供應商條款：至少檢查資料使用、留存、刪除與轉委託
- 員工使用規範：用 1 頁文件讓大家知道能做與不能做
- 上線核准表：從 demo 到正式流程的最後檢查
- FAQ
- 參考來源與資料時間
- CTA：如果你要導入團隊
先講結論：Dify 上線前要過 7 個治理門檻
中小企業不需要一開始就做一套巨大治理制度，但至少要能回答 7 個問題：
| 門檻 | 要能回答的問題 | 最小交付物 |
|---|---|---|
| 用途邊界 | 這個 AI 應用只能回答什麼？不能回答什麼？ | 用途說明與拒答清單 |
| 使用者權限 | 誰能用？誰能編輯？誰能看日誌？ | 角色權限表 |
| 資料範圍 | 它能引用哪些知識庫？哪些資料禁止進入？ | 資料清單與禁止資料清單 |
| 個資規則 | 什麼資料不能輸入？若不得不處理，怎麼遮罩？ | 個資與敏感資料規則 |
| 日誌管理 | 會記錄什麼？誰能看？多久檢查一次？ | 日誌檢查與留存規則 |
| 供應商檢查 | 平台與模型供應商如何處理資料？ | 條款檢查表 |
| 責任歸屬 | 答錯、客訴、資料過期時誰處理？ | 上線核准表與負責人 |
這 7 件事聽起來像管理成本，但它們其實是在保護導入成果。沒有治理的 AI 很容易變成短期 demo；有治理的 AI 才有機會變成可擴張流程。
權限：不要讓所有人都看得到所有知識庫
Dify 的工作區與成員管理是以 workspace 為核心。不同角色可以做的事情不同，例如 owner、admin、editor、member 的能力不同；發布後的 Web App 也有存取控制設定。實務上，你不應該把「可以編輯應用的人」與「可以使用應用的人」混在一起。
建議先分 5 種角色
| 角色 | 可以做什麼 | 不該做什麼 |
|---|---|---|
| Owner | 決定工作區、帳務、最終權限 | 不應日常調 prompt |
| Admin | 管理成員、模型 provider、插件與整體設定 | 不應獨自決定業務規則 |
| Editor | 建立與修改應用、知識庫、流程 | 不應接觸不屬於該部門的敏感資料 |
| Reviewer | 驗收答案、看錯誤案例、提供修正 | 不一定要能改系統 |
| Member | 使用已發布應用 | 不應看完整日誌與知識庫內容 |
最容易犯的錯
很多公司第一版試點時，會把所有測試成員都設成高權限。這在 demo 階段很方便，但一旦上線，就會出現三個問題：
- 不知道誰改了提示詞。
- 不知道誰改了知識庫。
- 不知道哪些人看到超出職務需求的資料。
建議做法是：能用的人不一定能改，能改的人不一定能管理成員，能管理成員的人不一定能看所有業務資料。
日誌：它不是監控員工，而是讓錯誤能被追蹤
Dify 的 Logs 可以記錄使用者互動、輸入輸出、模型、token、回應時間、錯誤與回饋等資訊；Run History 也能讓 workflow 的執行結果、節點細節與 tracing 被檢查。這些紀錄對改善應用很有用，但也代表日誌本身可能含有敏感內容。
日誌至少要看 6 件事
| 指標 | 用途 |
|---|---|
| 錯答案例 | 找出知識庫缺口、提示詞邊界不足或資料過期 |
| 人工介入 | 判斷哪些問題不適合自動回答 |
| 使用頻率 | 看應用是否真的被採用 |
| 回應時間 | 找出慢節點與過長 prompt |
| token 成本 | 控制模型費用與用量異常 |
| 使用者回饋 | 找出最常被抱怨或最有價值的回答 |
但日誌不是越多人看越好
日誌可能包含完整對話、客戶問題、業務資訊、甚至個資。建議先定三條規則：
- 誰能看日誌： 通常只給 owner、admin、維運負責人、指定 reviewer。
- 日誌怎麼用： 用於 debug、品質改善、客訴查核，不用來做無關的人事評價。
- 多久檢查一次： 試點期每週一次，上線後至少每月一次；高風險流程要更密集。
如果應用會處理敏感資料，還要評估縮短留存、匿名化、遮罩或改採自架環境。
個資與敏感資料：先建立「禁止輸入」與「遮罩」規則
台灣個資法要求個人資料的蒐集、處理與利用要有合法目的與必要範圍。2025 年 11 月 11 日公布的修法包含主管機關與監督機制等變更，官方法規系統也註明部分條文尚未施行；因此企業在 2026 年導入 AI 時，不能只看舊印象，應確認最新法規狀態與內部合規要求。
先把資料分成 4 層
| 等級 | 範例 | Dify 試點建議 |
|---|---|---|
| 公開資料 | 官網、公開型錄、公開 FAQ | 可作為低風險知識庫 |
| 內部一般資料 | SOP、流程說明、非敏感報價規則 | 可用，但要有版本與權限 |
| 敏感商業資料 | 成本、毛利、未公開合約、客戶名單 | 預設不放，除非有明確權限與用途 |
| 個資與特種資料 | 姓名、電話、Email、身分證字號、健康資料等 | 原則上避免輸入；必要時遮罩、限縮與留紀錄 |
建議員工先遵守 5 條禁止輸入規則
- 不輸入完整身分證字號、護照號碼、健保資料。
- 不輸入完整信用卡、銀行帳號、薪資明細。
- 不輸入未遮罩的客戶電話、地址、Email 名單。
- 不輸入病歷、健康檢查、犯罪前科等高敏感資料。
- 不輸入尚未公開的成本、合約底價、併購或人事決策。
如果業務流程真的需要處理這類資料，就不要只靠「員工自己小心」。你需要建立表單欄位、遮罩規則、權限限制、日誌檢查與法務/資安審查。
供應商條款：至少檢查資料使用、留存、刪除與轉委託
Dify 可能有雲端版、自架版，也可能串接不同模型供應商、插件與外部 API。你的資料不只進入 Dify，還可能經過模型 provider、向量資料庫、插件服務或外部系統。
上線前請至少檢查 8 件事：
| 檢查項目 | 要問的問題 |
|---|---|
| 資料用於訓練嗎 | 你的輸入、輸出、知識庫是否會被用於模型訓練 |
| 日誌留存多久 | 平台、模型、插件各自保存哪些紀錄 |
| 刪除機制 | 終止使用後，資料與備份如何刪除 |
| 資料所在地 | 資料會存在哪些地區或雲端服務 |
| 轉委託 | 是否會交給第三方 subprocessors |
| 權限與稽核 | 是否能查到誰存取、誰修改、誰匯出 |
| 安全認證 | 是否有 SOC 2、ISO 27001、DPA 或資安報告可供審查 |
| 事件通報 | 資安事件或資料外洩時，多久通知、誰負責 |
Dify 官方在 2026 年公告其 SOC 2 Type II、ISO 27001:2022 與 GDPR 合規維護進度；這是供應商審查可以參考的信號，但不能取代你自己的資料分類、模型供應商條款、插件條款與內部風險評估。
員工使用規範：用 1 頁文件讓大家知道能做與不能做
治理文件最怕寫得很完整，員工卻沒人讀。中小企業第一版建議只寫一頁，內容包含：
1. 這個 AI 能做什麼
例如：
- 查詢公開 FAQ。
- 查詢已核准 SOP。
- 協助草擬客服回覆，但對外前要人工確認。
- 協助整理報價必要欄位，但不能直接決定價格。
2. 這個 AI 不能做什麼
例如：
- 不能承諾價格、交期、保固例外。
- 不能提供法律、醫療、投資等高風險建議。
- 不能處理未遮罩個資。
- 不能取代主管核准。
3. 發現錯誤怎麼回報
建立一個簡單流程：
- 截圖或貼上錯誤回答。
- 標註是哪個情境。
- 指出正確答案來源。
- 由 reviewer 判斷要改 prompt、補知識庫或調整拒答規則。
上線核准表：從 demo 到正式流程的最後檢查
你可以用下面這張表做內部核准。
| 檢查項目 | 通過標準 | 負責人 |
|---|---|---|
| 用途邊界 | 已列出可回答與不可回答範圍 | 應用 owner |
| 知識庫版本 | 每份文件有來源、日期、負責人 | 部門主管 |
| 權限設定 | 使用者、編輯者、管理者已分層 | Admin |
| 個資規則 | 已定義禁止輸入與遮罩方式 | 管理部 / 法務 |
| 日誌檢查 | 已定義查看人員、頻率、改善流程 | 維運負責人 |
| 測試題庫 | 至少 20 題真實問題，達到可接受門檻 | Reviewer |
| 人工交接 | 高風險與不確定情境會轉人工 | 客服 / 業務主管 |
| 對外聲明 | 對客戶可見流程有必要提醒與責任邊界 | 業務 / 客服主管 |
完成這張表後，才建議從「試點使用」進入「部門內正式使用」。
FAQ
Q1：我們只是內部用，也需要個資規則嗎？
需要。內部使用不代表沒有個資風險。只要員工可能輸入客戶資料、員工資料、聯絡資訊或交易資料，就應該先定義哪些資料禁止輸入、哪些要遮罩、誰能看日誌。
Q2：Dify 有日誌是不是就代表治理完成？
不是。日誌只是工具。你還要定義誰看、怎麼看、多久看一次、發現錯誤後怎麼修正，以及日誌本身是否含敏感資料。
Q3：自架 Dify 就一定比較安全嗎？
不一定。自架可以提高控制度，但也代表你要自己負責系統更新、權限、備份、資安監控、日誌留存與事件處理。小公司若沒有維運能力，自架不一定比較穩。
Q4：員工如果不小心輸入個資怎麼辦？
先定義通報與刪除流程：誰接收通報、誰評估影響、是否需要刪除紀錄、是否需要通知主管或當事人。更重要的是前端就要降低輸入風險，例如表單欄位提示、遮罩、禁填規則。
Q5：供應商說有 SOC 2 或 ISO 27001 就夠了嗎？
不夠。認證可以當作信任訊號，但你仍要看實際條款、資料處理範圍、模型供應商、插件、留存、刪除、轉委託與事件通報。
參考來源與資料時間
資料時間：2026-05-07。法規、平台功能與供應商條款可能更新，正式導入前請再次確認官方文件。
- Dify Docs: Manage Members
- Dify Docs: Web App Access Control
- Dify Docs: Logs
- Dify Docs: Run History
- Dify Docs: Knowledge Settings
- 個人資料保護委員會籌備處法規系統：個人資料保護法
- Dify Blog: SOC 2, ISO 27001 & GDPR compliance update
CTA：如果你要把它導入團隊
如果你已經完成第一個 Dify 應用，請先不要急著開給全公司。下一步建議做一場 60 分鐘治理盤點：
- 列出應用用途與不能回答的範圍。
- 檢查知識庫資料等級與版本。
- 分配 owner、admin、editor、reviewer、member。
- 定義日誌查看與錯誤修正流程。
- 用 20 題真實問題做上線驗收。
若你需要先看成效怎麼量化，下一篇請接著讀：導入 Dify 之後怎麼證明有用？用工時、轉單率與客服解決率做 KPI。