最近看製造業 AI 的案例，我越來越覺得：很多導入卡住的地方，不是模型不夠聰明，而是資料本身還沒有準備好承擔決策責任。
這句話聽起來有點老派。畢竟現在大家談 AI，焦點很容易放在模型、算力、Agent、視覺辨識、預測維護、排程最佳化。這些都重要，也確實比「整理資料」聽起來性感很多。但如果站在真正要把系統放進工廠流程的人角度，我反而會先問幾個很無聊的問題：這個感測值代表哪一台設備？這個 tag 名稱誰定義的？這份報表裡的良率，是依工單、批號、機台還是時間區間算出來的？如果 ERP、MES、品質系統和設備端數字不一致，誰才是準的？
這些問題如果答不出來，AI 接上去以後不會神奇地變準，只會把原本分散在各系統裡的不確定，包裝成一個很有自信的建議。
很多工廠其實已經有不少系統。MES 有、ERP 有，設備資料也可能有，品質紀錄、維修紀錄、人工報工、Excel 補表也都存在。問題不一定是「沒有資料」，而是資料之間缺少共同語意。有些欄位叫機台，有些叫產線，有些叫工作中心；有些時間是開工時間，有些是完工時間，有些是資料寫入時間；有些異常碼是設備吐出來的，有些是現場人員事後補選的。人可以靠經驗把這些差異腦補起來，但 AI 不會知道哪個腦補是公司真正承認的規則。
所以我現在看製造業 AI，會把「資料治理」看成落地前置工程，而不是 IT 部門的文件工作。它不是要大家先花一年做完完美資料倉儲，也不是要把所有欄位重新命名到漂亮。比較實際的做法，是先挑一個要讓 AI 參與的流程，釐清這個流程裡資料如何產生、被誰維護、何時失效、衝突時誰說了算。
例如要做異常原因分析，就不能只收集異常紀錄。你要知道異常發生時的工單、批次、料號、設備狀態、製程參數、維修事件、換線紀錄、品檢結果，哪些是必要上下文，哪些只是參考訊號。更重要的是，每一種資料都要有責任歸屬：設備訊號由誰確認品質？人工覆判由誰補登？異常分類改版後，舊資料怎麼對應？如果某個欄位長期沒人用，AI 還能不能把它當特徵？
這裡的重點不是追求資料完美，而是讓資料的可信程度可見。企業系統最怕的是假裝資料很乾淨。現場資料一定會有缺漏、延遲、誤填、版本不一致，這很正常。真正成熟的設計，是讓系統知道哪些資料可靠、哪些資料需要人工確認、哪些資料只能用來提示不能用來決策。AI 的輸出也應該繼承這種分層，而不是一律用同樣的語氣給答案。
我會把工廠 AI 的資料準備拆成幾層來看。
第一層是設備與現場語意。設備、產線、工作中心、工序、批次、工單之間的關係要講清楚。否則模型看到一堆 tag，只知道數字上下波動，卻不知道它們在現場流程裡代表什麼位置。
第二層是系統邊界。ERP 管的是訂單、成本、庫存與主資料；MES 管的是現場執行；品質系統管的是檢驗與判定；設備端管的是即時訊號。這些系統可以整合，但不能混成一坨。AI 要查資料時，應該知道每個系統的權威範圍，而不是誰 API 比較方便就相信誰。
第三層是資料責任。每個關鍵資料集都要有人負責語意、品質、變更和例外。沒有資料擁有者，資料問題最後就會變成 AI 團隊的問題；但 AI 團隊通常沒有能力也沒有權限決定一個工廠欄位到底該怎麼填。
第四層是決策用途。同一份資料，用來看趨勢、用來告警、用來停線、用來自動改排程，風險完全不同。資料治理不能只說「這個欄位可用」，還要說「它可用到哪個決策層級」。這也是很多 AI 專案容易忽略的地方：Demo 時拿資料做分析沒問題，正式流程中讓建議影響生產順序或品質放行，責任就完全不同。
從 CTO 或技術主管的角度，我會寧願先把這些無聊的資料責任整理出來，再談模型要多強。因為模型可以換，資料管線可以重做，介面也可以調整；但如果一開始沒有定義資料語意與責任邊界，後面每一個 AI 功能都會在同一片泥地上蓋房子。
這不代表製造業 AI 要等到資料治理百分之百完成才開始。剛好相反，最好的切入方式通常是選一個明確流程，用 AI 專案逼出資料問題，再把修正留下來。做異常分析，就整理異常資料責任；做預測維護，就整理設備與維修資料；做排程建議，就整理產能、交期、換線與限制條件。每一個小專案都應該順手讓資料基礎變好一點，而不是只交付一個孤立模型。
我越來越相信，製造業 AI 的競爭力不會只來自誰買到最新模型，而是誰能把現場知識、系統邊界與資料責任整理成可持續改善的底層能力。模型很會找模式，但它需要知道哪些模式有管理意義，哪些只是資料雜訊。
AI 進工廠之前，先把資料責任整理出來。這件事不酷，卻很關鍵。因為真正能落地的 AI，不是看起來最聰明的那個，而是能在髒資料、舊系統、現場例外和責任邊界之間，仍然說得清楚自己憑什麼做判斷的那個。