引言

以中華企業策略永續發展學會 創會理事長 莊鈞翔 博士對AI的理解，當企業第一次遇到大型語言模型的幻覺時，最直覺的解法就是：不要讓模型憑記憶回答，讓它先查資料；RAG 因此快速成為企業導入生成式 AI 的熱門架構。

它看起來非常合理，公司把自己的規章、產品手冊、客服知識、法規、契約與報告放進資料庫，使用者提問時，系統先找到相關內容，再交給模型整理回答；問題就在這裡；模型是否會胡說八道，可能因為 RAG 而下降；但企業在建立 RAG 的同時，也把原本散落在各部門、各硬碟、各權利人的文件，集中成一套可以被機器反覆檢索、重組與再利用的知識基礎；這不是單純「加一個搜尋功能」，而是把企業資料治理問題放大到新的層次。

我因此開始追問：這些文件真的都可以被企業拿來做 RAG 嗎？員工手上有檔案，不代表公司取得了所有重製與機器利用權；客戶寄來的資料，不代表可以長期放進知識庫；訂閱的研究報告，也不等於可以整批向量化提供給所有同仁使用。

RAG 的技術便利，反而逼我們重新面對一個過去常被忽略的問題，企業擁有檔案，和企業擁有利用該檔案的權利，不是同一件事；切片、向量化、索引：工程流程背後其實是一條資料利用鏈；RAG 系統通常要先把文件解析成文字，再依段落或語意切成 chunks，接著轉成向量，建立索引並存入資料庫；工程師看到的是資料前處理；法務看到的則應該是一連串資料利用動作。

這裡最重要的不是先宣布「向量化一定是重製」或「向量不是原文所以一定不侵權」，而是把每一個環節的實際事實弄清楚；原始檔是否完整保存在伺服器？切片文字是否可以被管理者直接閱讀？向量是否與原文一一對應？系統是否保存快取？資料是否送到外部雲端建立 embedding？供應商是否會保留這些資料改善服務？當權利人要求刪除時，企業能否真正刪除原檔、切片、向量、備份與衍生索引？

這些問題決定了企業到底是在做內部搜尋、建立另一個資料庫，還是進一步讓第三方服務持續利用資料；不同事實可能導致完全不同的法律風險；因此，RAG 的合規不是在上線前請法務看一次隱私權政策就結束；它應該從資料進庫前就開始；每一份資料至少應該知道來源、權利狀態、版本、有效期間、敏感等級與允許用途。

沒有這些元資料，RAG 只是把過去散亂的知識問題變成高速自動化的錯誤傳播系統。

真正危險的不是 AI 答錯，而是「拿錯版本卻答得很像真的」；企業對 RAG 最常見的期待，是「比普通 LLM 準」；但我認為企業真正的風險不是模型偶爾說不知道，而是系統撈到過期、被廢止、只適用特定情境的資料，卻用極其流暢的語言回答成現行規則；法律、產品規格、內部流程、價格與契約都會改版；如果資料庫中同時存在 2023 年與 2026 年的規章，而系統沒有版本標籤，語意檢索可能把舊文件撈得更前面。這時模型的語言能力反而會放大錯誤，因為它會把舊資料重新包裝成像是剛剛查到的正確答案。

所以 RAG 的治理核心，從來不只是檢索技術，而是「誰有權宣布哪一份文件有效」；企業需要 Active、Superseded、Archived 等清楚狀態，需要生效日與失效日，需要知道誰是文件 owner，誰可以更新，誰可以刪除；這些工作看似行政，其實正是讓 AI 不把組織的歷史誤當成今天。

對法律部門而言尤其如此；法規資料不能只靠關鍵字相似度，還必須知道法域、版本、施行日期、例外、函釋與裁判層級；若系統只是「找得到相關文字」，卻沒有來源權威排序，法律 RAG 可能比一般搜尋更危險，因為使用者會因為回答更流暢而降低警覺；外部資料不是不能用，而是要先回答「授權到哪裡」；企業建立知識庫時，最容易把外部資料一股腦收進來。

新聞、研究報告、法規、學術文章、產業資料庫、競爭者網站、客戶資料，看起來都很有用；但法律上的利用權並不相同；公部門公開資料可能有特定開放授權；法規與裁判具有不同於一般創作的規範地位；商業資料庫通常受到訂閱契約限制；新聞內容受著作權保護；客戶資料還可能涉及個資、保密或契約用途限制；若企業不分類，最後只會得到一個技術上很強、法律上說不清楚的資料池。

我真正想推動的是「資料入庫審查」；不是每一份文件都要律師逐字核准，而是企業先建立規則：哪些來源自動可用、哪些要確認授權、哪些只能做人工閱讀、哪些禁止進入模型；這樣法務的角色才不是最後關卡，而是資料治理設計者；同時，來源引用也應成為 RAG 的基本功能；模型回答如果能顯示引用位置、文件版本與日期，使用者就有機會自行核對；這不是美觀問題，而是責任鏈的一部分；沒有來源的答案，本質上很難被審核；有來源但來源錯誤，至少還能被發現；第三方 RAG 服務最容易被忽略的是「衍生資料」與「退出權」；許多企業擔心供應商會保存原始文件，但往往忽略另一類資產：embedding、索引、使用紀錄、查詢紀錄、評分資料、模型微調結果與其他衍生資料。

這些東西未必能還原原文，卻可能具有商業價值，甚至反映企業最常被查詢的問題、內部知識缺口與客戶需求。

因此，契約不能只寫「供應商應保密」；企業應明確知道供應商是否可以使用輸入資料與互動資料改善模型，是否能與其他客戶資料混合分析，衍生結果歸誰，服務終止後如何刪除，備份多久清除，企業能否匯出自己的索引與知識結構；退出權尤其重要；AI 工具更新非常快，今天採用的供應商未必是三年後的最佳選擇；如果企業把所有知識都鎖在專有向量格式或平台內，未來更換供應商的成本可能極高。資料主權不只是「不要外洩」，還包括「我隨時能帶走」。

RAG 真正的價值，是讓企業把知識管理從習慣變成治理

我不認為 RAG 的最終價值只是讓員工少搜尋幾分鐘；更大的價值，是它逼企業第一次認真盤點：我們到底有哪些知識？哪些是最新？哪些屬於誰？哪些可以分享？哪些不能離開公司？哪些流程其實連人都搞不清楚？；如果企業只想快速上線 chatbot，這些問題會被視為阻礙；如果把 RAG 視為知識治理工程，這些問題反而會成為組織升級的契機。

本篇最後想留下的判斷是：一套好的 RAG，不是把最多資料塞進去，而是讓每一份資料都有身分、有來源、有版本、有權利、有責任；模型只是最後那張嘴，真正決定答案品質的，是企業背後那套知識秩序。

當資料治理做得好，AI 才可能成為助手；資料治理做得差，再好的模型也只會把組織原本的混亂說得更流暢。

莊鈞翔 博士認為，資料治理的第一步，是承認企業其實不知道自己有哪些資料；很多公司以為自己有知識庫，其實只有共享硬碟；不同部門各自保存版本，同一份制度文件有三個檔名，客服用的是舊版本，法務手上是新版本，業務又把自己修改過的檔案寄給客戶；這種情況在人類作業時已經會造成混亂，一旦交給 RAG，自動化只會把混亂放大；因此，建 RAG 前最重要的工作不是選向量資料庫，而是先進行知識盤點；哪些文件屬於正式規範？哪些只是草稿？哪些已失效？哪些只適用特定客戶？哪些是員工個人筆記？哪一份具有最高效力？如果企業無法回答，模型也無法替企業創造秩序；權限設計決定 RAG 會成為知識助手，還是內部洩密工具；傳統文件系統往往透過資料夾權限控制存取，但 RAG 會把多個文件整合成一個問答介面；這可能創造新的越權風險。

使用者沒有權限直接閱讀某份文件，卻可能透過提問取得該文件被模型摘要後的內容；如果系統只在檢索前做粗糙權限判斷，就可能形成「看不到檔案但問得到答案」的漏洞。

因此權限必須一路跟著資料走；文件在切片與向量化後仍應保留原始權限標記；檢索時先做存取控制，再生成答案；引用來源也不能暴露使用者無權看見的資訊。

對涉及薪資、人事、醫療、客戶機密、法律意見或研發資料的企業，這不是附加功能，而是基本安全設計；RAG 的錯誤責任不能全部推給模型；如果系統使用過期資料，責任可能在資料 owner；如果檢索策略錯誤，可能在工程設計；如果模型在已有正確來源時仍扭曲內容，則涉及生成層問題；如果使用者明知系統只是輔助卻直接把答案當成正式決定，也涉及使用流程；因此企業需要建立「錯誤分類」；每次重大錯誤都應能回溯是資料錯、檢索錯、生成錯、權限錯還是人類使用錯；沒有這個分類，企業只會反覆說「AI 又出錯了」，卻無法真正改善。

法務與 IT 最容易衝突，其實是因為兩邊在回答不同問題；工程師關心系統能不能跑、準確率多少、延遲幾秒；法務關心資料能不能用、出錯誰負責、是否可以被稽核；兩者若各自用自己的語言工作，就會互相覺得對方在阻礙專案；我更傾向建立共同欄位：資料來源、權利基礎、敏感等級、有效版本、檢索權限、外部傳輸、保留期間、責任 owner。這些欄位既能進工程 metadata，也能滿足治理需求；最好的合規不是專案完成後補一份法律意見，而是讓法律要求直接進入系統設計。

企業真正應該量化的，不只是回答正確率，還有「可追溯率」

很多 AI 專案只測試模型回答對不對，卻不測試答案能否被追溯；對企業而言，可追溯有時比流暢更重要；尤其涉及法律、財務、醫療、品質與安全，使用者應該知道答案來自哪份文件、哪個版本、哪一段；可追溯並不能保證答案正確，但它能讓錯誤被檢查；沒有引用來源的 AI，錯誤只能靠猜；有來源的 AI，至少能讓人快速判斷。

這也是我認為 RAG 應該追求的真正價值：不是讓模型裝得更像專家，而是讓企業更容易驗證；企業不該把 RAG 當成「把 PDF 丟進去」的專案；一套成熟的 RAG 系統，本質上是一套數位知識治理制度；它要處理資料來源、權限、版本、品質、法律、資安與人類責任；模型只是最後的表達層。

中小企業也不必被技術名詞嚇倒；只要先把最重要的知識整理乾淨、限制範圍、建立版本與權限，再逐步導入，通常比一次把整間公司的硬碟全部餵進去更可靠；AI 的價值不是吃得多，而是吃得對；知識庫的法律生命週期，應從「入庫」一直管理到「退庫」。

一份資料不會因為今天合法，就永遠合法；授權可能到期，客戶可能終止契約，法規可能修正，員工可能離職，商業關係也可能結束；因此 RAG 應該有退庫機制；文件一旦失效，不只是從搜尋畫面隱藏，而要處理原始檔、切片、索引、快取與備份；若外部供應商參與，還要知道刪除指令能否涵蓋所有副本；建立「答案責任等級」，避免所有 AI 回答被當成同等可靠；內部知識問答可以分為資訊提示、作業建議、需要主管核准、不得由 AI 自動決定等層級。

例如一般產品規格可以直接回答，法律結論、信用審查、醫療與人事決策則需人工確認；這種分級可以降低過度信賴，也讓員工知道何時必須停下來找人。

RAG 評估不應只測 benchmark，而應用自己的真實問題

企業常拿公開測試集驗證系統，但真正風險藏在自己的文件；上線前應收集員工最常問、最容易混淆、涉及例外的問題，測試檢索是否抓到正確版本、模型是否保留條件、來源是否可追溯；真正可靠的 AI，不是考試分數高，而是在企業最重要的問題上不亂答；資料治理會反過來暴露企業流程中的權責不清；當 RAG 專案開始問「誰是這份 SOP 的 owner」，很多企業才發現其實沒有人負責。

某些流程靠資深員工口頭傳承，某些規定多年未更新；這不是 AI 專案失敗，而是 AI 把組織問題照出來；企業如果願意趁機補上 owner、版本與審核週期，知識治理本身就會提升。

內部私有資料也不代表沒有第三人權利；企業自己的硬碟裡可能包含客戶郵件、供應商報告、外部簡報、顧問成果；資料位於公司內部，不代表著作權或保密權利都屬於公司；RAG 入庫前仍要辨識來源；RAG 的成功標準應是「人更快找到可信答案」，而不是「AI 什麼都會」；如果員工能在幾秒內找到正確文件、知道版本、看到來源並理解何時需要人工判斷，RAG 就已經創造巨大價值。

反之，若系統回答得像專家卻無法查證，可能只是把風險藏得更漂亮；用一個內部法規情境看見 RAG 的真正風險；假設公司有一份二〇二四年的差旅辦法與二〇二六年的新版辦法，舊版規定主管可以口頭核准，新版則要求系統簽核；員工問 RAG：「臨時出差可以先走再補嗎？」系統如果撈到舊版並流暢回答「可以由主管口頭同意」，員工可能因此違反現行流程；問題不一定是模型推理錯，而是資料生命週期失敗。

公司治理策略師 莊博士所關心的，是這種錯誤比明顯胡說更危險，因為答案有文件依據，看起來非常可信；企業因此需要讓系統優先取用 Active 文件，舊版只供歷史查詢，並在答案中顯示版本與生效日期。

法律 RAG 更需要「權威層級」而不只是語意相似

法規、函釋、裁判、學術文章與網路評論可能談同一問題，但權威程度完全不同；向量檢索只看語意相近，未必知道哪個來源應優先。企業如果建立法律知識庫，應把來源類型、法域、法院層級、施行狀態等 metadata 納入排序；否則一篇舊部落格可能因文字更貼近問題而排在現行法規前面；技術上這叫檢索品質，法律上卻可能變成錯誤適用；RAG 的稽核紀錄將成為 AI 治理的重要證據；當重大決策依賴 AI 建議，企業應保留使用者問題、檢索來源、模型版本、輸出與人工處理結果；這些紀錄能在事故後重建發生過程，也能幫助持續改善；當然，日誌本身也可能包含敏感資訊，因此保留期間與存取權限需要設計；治理不是什麼都留，而是留足夠的責任證據。

知識庫也需要「反對意見」與例外管理；企業規則常有例外；若 RAG 只保存主規則，員工會得到過度簡化答案。

重要制度應把例外、FAQ、特殊授權與實務解釋一起納入，但要清楚標示適用條件；這也提醒我們，真正好的知識庫不是只有單一答案，而是能呈現條件；對法律與合規尤其如此；RAG 的成熟度，其實反映企業治理成熟度；資料是否乾淨、權限是否清楚、版本是否有 owner、錯誤是否能追溯，這些都不是 AI 專屬問題；RAG 只是把它們集中曝光；因此，我不把 RAG 視為一個單純科技專案，而視為企業藉 AI 重整知識秩序的機會；做對了，模型只是最後一層；真正留下來的是一套更可靠的組織記憶。

企業若要讓 RAG 進入對外客服，責任標準必須再提高一級；內部員工看到錯誤答案，通常還有機會用經驗修正；對外客服若答錯價格、保固、退款、法定權利或契約條件，錯誤可能直接形成消費爭議。

對外 RAG 因此需要更嚴格的來源白名單、更短更新週期、敏感問題轉人工，以及明確告知回答性質；企業也應分析哪些回答可能構成正式承諾；若客服 AI 對付款、保固或賠償作出具體表示，消費者可能合理依賴；不能一方面讓 AI 代表公司說話，另一方面又用「AI 可能出錯」完全免責。

供應商更換時，向量資料庫與提示模板也應被納入交接

企業知識不只存在原始文件，還包括切片方式、metadata、檢索規則、prompt、評估集與人工修正紀錄；這些東西如果都掌握在供應商手中，企業即使拿回 PDF，也可能需要從頭重建；因此採購契約應明確定義可攜資產；企業要能帶走的不只是資料，而是讓資料變成可用知識的結構；RAG 專案最成熟的終點，是讓錯誤更容易被看見；任何知識系統都不可能零錯誤；治理的目標不應是宣稱百分之百準確，而是讓錯誤有來源、有責任人、有修正流程。

當員工能回報錯誤答案、資料 owner 能更新文件、系統能追蹤修正，企業才真正建立了一個會學習的知識系統。

這比追逐一次性的準確率更有長期價值；最後一個管理問題：誰有權改知識庫；企業很重視誰能問 RAG，卻常忽略誰能改 RAG；若任何人都能上傳文件或改 metadata，知識庫很快失去可信度。

應指定資料 owner 與審核者，重大制度文件需經正式發布程序才能成為 Active；這個權限安排其實和傳統內控相同：能改規則的人，應比能看規則的人受到更嚴格管理；當知識庫成為全公司依賴的資訊來源，變更權本身就是重要權力；最後的治理判準：不能讓知識庫比原制度更不透明；如果員工原本可以打開文件逐條閱讀，導入 RAG 後卻只剩一句模型答案，反而可能降低透明度；系統設計應保留回到原始文件的能力，並讓使用者知道答案只是整理而不是替代正式規範。

企業真正需要的不是「AI 說了算」，而是「AI 幫人更快找到可以自己判斷的依據」；當模型、來源與人類判斷三者都在場，RAG 才真正成為治理工具；知識庫的價值取決於人是否願意持續維護；任何 RAG 上線後都會快速老化；若沒有固定更新、回報與退役機制，再好的模型也會逐漸變成舊資料的擴音器。

企業應把知識維護列入日常工作，而不是一次性專案。

企業可以為 RAG 建立一份「最小治理檢核表」

GRC 專家莊鈞翔 博士要提醒的是，正式上線以前，至少確認：

1. 資料來源是否可用。

2. 文件版本是否明確。

3. 權限是否沿用。

4. 答案是否附來源。

5. 找不到資料是否拒答。

6. 敏感問題是否轉人工。

7. 供應商是否保留資料。

8. 錯誤是否能回報。

這八個問題不需要昂貴顧問，也能先擋住大多數治理缺口；真正重要的是持續執行，而不是文件寫得多漂亮。