導入 AI 的第一步不是選模型，是把資料分級

問題通常不是「AI 不夠聰明」

企業導入 AI 的第一年，最常聽到的一句話是：「我們試過了，好像沒有想像中好用。」再往下問，情境幾乎一模一樣——員工開了通用的對話介面，問了一個跟自家業務有關的問題，得到一段看起來很通順、但完全不能用的答案。

這不是模型的問題。同一個模型，你把公司的報價規則、過往案例與客戶禁忌一起貼進去，它就答得出來。差別只在於：它有沒有讀到該讀的東西。

所以真正的第一步不是比較模型，也不是挑工具，而是回答一個管理問題：公司裡的哪些資料，可以給 AI 看？

先分級，再建庫

很多團隊的做法是先把雲端硬碟整個丟進去做向量化，之後再來想權限。這個順序會讓你付兩次錢——第一次建，第二次因為外洩風險或稽核要求而重建。

比較穩的做法是先做資料分級，再依級別決定要不要進知識庫、以哪一種形式進去。實務上四級就夠用：

L1 公開資料

官網文案、產品規格、公開報價、常見問答、法規條文。這一層可以無條件進知識庫，也是對外客服 Agent 唯一能讀到的層級。

L2 內部作業

SOP、報價邏輯、折扣權限、出貨規則、內部話術。這一層是讓 AI 「像個老員工」的關鍵，但只開放給內部使用的 Agent，且回覆時要能追溯出處。

L3 客戶資料

聯絡人、成交紀錄、服務歷程。這一層原則上以遮罩或聚合形式進入——Agent 可以知道「這個客戶過去買過三次」，但不需要知道他的身分證字號。

L4 營業秘密與個資核心

成本結構、未公開的策略、人事薪資、完整個資欄位。這一層預設不進知識庫。要用，就走另外的流程與另外的系統，並留完整存取紀錄。

分級的重點不是「擋住 AI」，是讓每一次存取都說得出理由。稽核時你要回答的問題不是「AI 有沒有看過」，而是「誰授權它看的、什麼時候、為了什麼」。

把權限綁在 Agent 上，不是綁在公司上

常見的錯誤設計是給整個 AI 系統一組萬用權限，然後用提示詞叫它「不要說出機密」。這在架構上是把安全性寄託在模型的服從度上，而模型的服從度不是安全機制。

正確的做法是在檢索層就切斷：客服 Agent 的檢索範圍只包含 L1，它在技術上就取不到 L2 的內容，不需要「忍住不說」。內部的數據參謀可以讀到 L2 與遮罩後的 L3，但 L4 連索引都不存在。

這樣設計的另一個好處是，出事時的調查範圍是明確的。你不用檢查整個模型的行為，只要看那一個 Agent 的檢索紀錄。

資料整理沒有捷徑，但有優先序

把公司知識整理成結構化文件，是導入過程中最花時間、也最沒有人想做的一段。要讓它可行，關鍵是不要一次做完，而是照使用頻率排序：

• 先做每天被問的。客服一週重複回答二十次的問題，優先整理成 L1 的問答文件。
• 再做離職會斷的。只有資深員工知道的判斷規則，趁人還在的時候寫成 L2 的作業說明。
• 最後做完整的。其餘資料維持現狀，等到真的有 Agent 需要它時再整理。

用這個順序，第一批可用的知識庫通常兩到四週就能上線，而不是等半年做完一份沒有人維護的大全集。

怎麼知道做對了

知識庫做得好不好，不看文件數量，看三件事：

1. 引用率。AI 的回覆有多少比例附得出知識庫內的出處。答得出來但引用不出來，代表它在用通用知識瞎猜。
2. 拒答率。查不到資料時它會不會誠實說「查不到」。願意拒答的系統，才敢拿去面對客戶。
3. 越權嘗試紀錄。有沒有 Agent 試圖檢索超出授權範圍的內容。這是最早的異常訊號。

這三個數字比任何示範影片都更能說明導入的成熟度。

四級分級實際怎麼標

理論講完，真正卡住團隊的是動手那一刻：桌上攤著三百份文件，第一份要標什麼？以下是實務上可用的判斷順序，照著問三個問題就能決定大部分文件的歸屬。

問題一：這份東西外面看得到嗎

官網上有、型錄印過、公開簡報講過的，一律 L1。這一題就能處理掉兩成到三成的文件，而且幾乎不會有爭議。要注意的是「曾經公開過但已經改版」的資料——舊版報價單流出去不會有法律問題，但 AI 拿舊版報價回答客戶會出事，所以 L1 也需要版本控管。

問題二：這份東西給競爭對手看會不會痛

會痛就不是 L2。SOP、話術、教育訓練教材通常給對手看也還好，那些是 L2；但成本結構、毛利率、供應商議價條件給對手看會直接影響競爭力，那是 L4。中間地帶（客戶名單、成交紀錄、專案報價）落在 L3。

問題三：這份東西裡面有沒有「人」

只要含個人可識別資訊，起跳就是 L3，而且要另外標記個資欄位，因為它受的是法規約束而不只是商業判斷。含醫療、財務、生物特徵等特種個資的，直接進 L4。

這三題答完，通常還會剩下一成左右的模糊案例。這些不要自己決定——列成清單，拿去跟法務和該部門主管開一次三十分鐘的會。實務上這場會議的價值很高，因為它會逼出很多從來沒有人明確講過的內部共識。

盤點時一定會遇到的四件麻煩事

每一個做過資料盤點的團隊都會撞到這幾件事。先知道就不會被嚇到。

• 同一份文件有五個版本，散在五個地方。正確做法不是選最新的那份，而是找出誰有權決定哪份算數，請他裁決並簽名。沒有裁決人的文件不要入庫。
• 最重要的知識根本沒有文件。老鳥的判斷邏輯、客戶的地雷、哪個供應商的交期可以壓——這些只存在腦袋裡。這部分要靠訪談補，而不是等有人寫下來。
• 文件寫得很好但已經過期。三年前的 SOP 寫得很完整，但流程早就變了。過期的完整文件比沒有文件更危險，因為它看起來可信。
• 部門之間的說法互相矛盾。業務跟客服對退貨規則的認知不同，兩邊都覺得自己是對的。這不是資料問題，是管理問題，但它會在盤點時浮出來——而這其實是知識庫專案最大的附加價值。

為什麼「先做能用的一小塊」比較划算

很多公司的第一版知識庫計畫都長得像一份大工程：全公司、所有部門、六個月完成。這種做法的失敗率很高，原因有三個。

第一，六個月裡公司的規則會變，先整理的那批到後期已經需要重做。第二，過程中沒有任何人看到成果，專案的支持度會隨時間遞減，到第四個月開始有人問「這個到底什麼時候會好」。第三，也是最關鍵的——你在第一版做的很多假設是錯的，但要等到真的有人用了才會知道錯在哪。

比較穩的節奏是：挑一個部門、一個場景，兩到四週做出可以真的用的第一版，讓十個人用兩週，收集他們問不出答案的問題，再決定下一批要整理什麼。這樣做的好處是每一批整理的內容都有真實需求支撐，不會做出一堆沒人查的文件。

知識庫的價值不是它收了多少東西，而是有人來查的時候查得到。收了三千份文件卻沒有人查，那是倉庫，不是知識庫。

維護機制：決定這件事是資產還是負債

導入六個月後回頭看，成功與失敗的知識庫差別幾乎都在同一件事：有沒有人在維護。沒有維護機制的知識庫會經歷一個很典型的衰敗過程——先是有幾則答案過時，員工發現後開始自己去問人；問人比查系統快，於是查詢量下降；查詢量下降之後更沒有人回報錯誤，錯誤累積得更快。半年後系統還在，但沒有人相信它。

要打斷這個循環，需要三個機制：

1. 每一則知識都有掛名的維護人。不是「客服部」，是「客服部林主任」。組織負責等於沒有人負責。
2. 每一則知識都有複檢週期。價格類三十天、流程類九十天、法規類依修法時程。到期系統自動通知維護人，逾期的條目在查詢結果中標記為「待複檢」。
3. 答不出來的問題會自動變成待辦。使用者查不到答案時系統開單，累積成下一批要補的清單。這讓知識庫用得越久越完整，而不是越用越糊。

這三件事的工作量其實不大——一個維護人每個月大概花一到兩小時。但它決定了這套系統兩年後還在不在。

先算清楚要花多少

知識庫的成本很容易被低估，因為最大的一塊不是技術費用。實務上的比例大致是：技術建置與串接兩成、資料整理與訪談五成、維運與教育訓練三成。也就是說，如果有人報給你的價格裡只有技術費，那份報價一定不完整。

資料整理這一塊之所以佔比最高，是因為它需要你們自己的人投入——沒有外部廠商能替你決定哪份文件是對的。導入前先把這件事講清楚，避免專案進行到一半才發現內部人力沒有排進去。