AI 專案失敗，常常不是因為模型不夠強
在許多企業 AI 專案裡，團隊一開始會把焦點放在模型選型、提示詞、向量資料庫或聊天介面。這些都重要，但如果底層資料混亂，AI 只會更快地把問題放大。資料命名不一致、欄位定義不清、權限邊界模糊、文件版本混雜，最後會讓 AI 回答看似流暢，實際上卻難以驗證。
工程團隊看 AI 導入，不會只問模型能不能回答，而會先問資料從哪裡來、誰負責、多久更新、哪些人可以看、錯了要怎麼查。這些問題聽起來像管理議題，但實作上都是系統設計問題。RAG 需要可靠的文件來源，企業助理需要權限控管，ERP 與 CRM 整合需要欄位語意一致，IoT 資料平台需要時間戳、設備編號與資料品質規則。
資料治理的價值，不是把所有事情變慢，而是讓 AI 導入可以有邊界地加速。沒有治理，PoC 可能很快；但要進到正式營運、跨部門使用、接上核心系統，就會遇到信任、稽核與維護成本的問題。
資料治理要先回答的工程問題
實務上，資料治理不是先寫一份厚重政策，而是先把幾個會直接影響 AI 行為的問題釐清。資料能不能被用，通常不是單一答案，而是跟使用情境、使用者身分、資料敏感度與輸出風險有關。
- 資料來源：AI 使用的是正式系統資料、匯出的 Excel、共享雲端硬碟，還是人工整理的知識庫。來源越多，越需要明確的主資料與同步規則。
- 資料定義：客戶、案件、訂單、設備、服務紀錄等名詞，在不同系統裡是否代表同一件事。定義不一致時，AI 很容易產生看似合理但業務上錯誤的答案。
- 存取權限：使用者能看到哪些資料，不應只靠前端介面限制。RAG 檢索、API 查詢、日誌與快取都要延續相同權限模型。
- 更新頻率：AI 回答依賴的是即時資料、每日同步資料，還是已封存文件。不同頻率會影響架構選擇，也會影響使用者對答案的期待。
- 追溯能力：AI 回答最好能回指來源文件、資料表或交易紀錄。當答案被質疑時，團隊要能查出資料來源與處理流程。
這些問題如果在系統上線後才補，成本通常更高。因為到那時候，資料管線、索引、權限、快取與使用者流程都已經被綁在一起，任何修正都可能牽動多個系統。
治理不是把資料鎖起來，而是讓資料可用
很多團隊一聽到資料治理，就直覺想到限制、審批與文件。但好的治理不是讓資料不能用，而是讓正確的人在正確情境下，用到正確版本的資料。對 AI 導入來說，這點尤其重要，因為 AI 會把原本分散在系統、文件與人腦裡的知識重新組合。如果邊界不清楚，風險會比傳統報表更難控管。
實務上，我們會建議先把資料分級與使用情境綁在一起，而不是只做抽象分類。例如公開型產品資訊可以進入客服知識庫；內部作業手冊可以給員工助理檢索；合約、報價、個資或財務資料則需要更嚴格的身分驗證、遮罩、日誌與輸出限制。這樣做的好處是，工程團隊能依資料等級設計不同的管線，而不是把所有資料都放進同一個索引。
取捨也要說清楚。越嚴格的治理，通常代表更多建置成本與操作摩擦；越寬鬆的治理，短期導入較快，但後續風險與修補成本較高。成熟的做法不是追求一次到位，而是先針對高價值、低敏感度、資料品質可控的場景落地，再逐步擴展到更核心的流程。
從 AI 架構看治理落點
資料治理不只存在於政策文件裡，也會落在系統架構的每一層。以企業 AI 助理或 RAG 系統為例，治理點至少包含資料擷取、清理、切分、嵌入、索引、檢索、生成、日誌與回饋。任何一層沒有設計好，都可能讓資料失真或越權使用。
在資料擷取階段，要決定哪些系統是權威來源，以及同步失敗時要如何告警。在文件處理階段，要保留版本、標題、部門、擁有者與有效日期等中繼資料。在檢索階段，要依使用者身分過濾可見內容。在生成階段，要要求模型引用來源、避免把推論包裝成事實。在日誌階段，則要記錄足夠資訊以便除錯，但也不能把敏感內容無限制保存。
對工程團隊來說，這些不是額外工作，而是 AI 系統能不能進入正式營運的基本條件。沒有這些設計，Demo 可能可以回答問題，但一旦使用者變多、資料變大、流程變複雜，就很難穩定維運。
實際導入可以從小範圍治理開始
企業不需要等到所有資料都整理完才開始 AI 導入。比較務實的路線，是選一個邊界清楚的場景，建立可重複的治理樣板。比如內部知識助理、客服 FAQ、設備維護文件查詢、業務支援資料庫，都是常見的起點。重點不是場景多大，而是資料來源、權限、更新、驗證與責任人能不能說清楚。
一個可執行的起步方式，是先盤點候選資料集，標記資料擁有者與敏感度，選出可以快速產生價值且風險可控的資料。接著建立同步管線、索引策略、權限規則與答案驗證流程。上線後再觀察使用者問題、錯誤回報與資料缺口，把治理規則逐步產品化，而不是永遠靠人工維護。
AI 導入真正困難的地方，不是把模型接上去，而是讓模型能在企業資料環境中可靠工作。資料治理做得夠紮實，AI 才能從展示功能變成可維運的業務系統；需要跨系統整合時，讓工程與治理一起設計，通常會比後補規則更穩。