一家汽車零組件廠的業務主管想知道某個客戶這季交期達成率為什麼掉下來，得等資訊課排時間。廠長想比對三條產線同一料號的良率差異，要請人從 MES 撈。財務追一個料號的成本為什麼多兩塊錢，得先問三個部門。
問題都不難，難的是答案要排隊。
2026 年 9 月 10 日，OpenAI 在 ChatGPT Work 裡推出 Data agent，處理的正是這段排隊。
Data agent 做了什麼
Data agent 是 ChatGPT Work 裡的一項新功能，不是新的基礎模型。管理員在工作區安裝，使用者在對話裡輸入 @Data 呼叫，用一句話問公司的資料，不必先學會寫 SQL。
它連得到的不只是資料表。依官方公告，理解問題所需的脈絡來自語意層與可信來源，舉例包括 Databricks Genie Ontology、dbt、GitHub、Snowflake Horizon 與既有 BI 儀表板裡的定義。先讀得到公司自己怎麼定義營收與毛利，再算。
資料源方面，官方列出的核准連接對象包括 Amazon Redshift、Datadog、Google BigQuery、ClickHouse、Databricks、MongoDB、Snowflake and more。Google Drive 與 SharePoint 上的檔案也能帶進分析。
產出可以是回答，也可以是活的儀表板，能在 Omni、Oracle BI、Power BI、Sigma、Tableau 與 ThoughtSpot 裡建立並互動，既有的報表系統不必重做。
權限交代得很直接：查詢沿用連接帳號既有的權限，包含資料表、資料列與欄位層級的限制。管理員決定哪些連線可用、哪些角色能用。
OpenAI 也分享了自己內部的採用情形：幾乎所有產品團隊、超過三分之二的 GTM 組織都在用資料代理分析公司資料，但也提出重點：這件事做得到，是因為資料團隊先建立了共用的商業定義、設定了存取規則、對敏感資料做了防護。
本文真正要談的是後半句：那個「資料團隊先做了什麼」的附帶條件。
功能之外的六個問題
過去公司裡會自己拉數字的人只有三五個，排隊本身就是一張過濾網。現在三百個人同時都能問，原本靠「沒人知道那張表在哪」維持的秩序會很快失效。
門檻降下來之後，有六件事會落回企業自己身上：
- 口徑：這個數字，全公司只有一種算法嗎
- 邊界：沒有人定義過的界線，你打算怎麼定
- 責任：遇到錯誤時如何釐清
- 紀錄：三個月後，還查得出當初是怎麼算出來的嗎
- 傳承：問得最好的那個人離職之後呢
- 維護：誰來維護這整件事
這六題是 FDE 進駐客戶現場，把第一批 AI Agent 接進流程時，實際會卡住的地方。沒有一題是技術問題。每一題都有兩段：決策由公司裡的人拍板，FDE 把它問到可以拍板的程度。拍板之後由系統接手，讓那個決定每一次都被同樣執行。
第一題：這個數字，全公司只有一種算法嗎
業務部月報上的毛利率，跟財務結算出來的毛利率，差兩到三個百分點。業務算的是出貨金額扣掉標準成本，財務算的是認列營收扣掉實際成本。兩邊各看各的報表，行之有年，沒出過事，因為這兩個數字不會同時出現在一個畫面上。
自然語言查詢會讓它們同時出現。今天業務主管問「上個月 A 客戶的毛利多少」，明天財務問同一句話，兩個答案不一樣，而且兩邊都拿得出計算過程。
公司認定的算法，在 EgentWrX 以知識庫分三種型態：制度與作業手冊放進 Wiki，散裝的政策條文走語意檢索，要精確數字的對照表上傳成表格直接查。對外回答可以被要求「必須引用來源」，指不出來源的回答會被系統退件。
至於要選哪一個是經營決策，兩種都沒有對錯。我們則建議：把業務與財務找來，兩套算法攤在同一張紙上，問清楚各自拿這個數字做什麼決定，然後請經營層拍板，是選一個，還是兩個都留但各取一個名字。拍板的結果寫進知識庫，之後不管誰問，Agent 引用的結果都能正確命中。
第二題：沒有人定義過的界線，你打算怎麼定
採購課長手上有三家供應商的報價、交期與品質紀錄。業務部的人能不能問到這三家的價差？
多數公司沒有正式回答過。邊界靠慣例維持：比價表就在採購的共用資料夾，有權限的人其實有十幾個，只是沒有人會去翻。
OpenAI 的機制是查詢沿用連接帳號原本就有的權限。這是合理的設計，不另外長出一套權限，就不會有兩套規則打架。問題在於「沿用」的前提是那套權限本來就定義完整，而多數製造業的資料夾權限是十幾年一次一次加上去的，沒有人做過總清查。
EgentWrX 把邊界建在組織架構上。角色分「全公司」與「單位範圍」兩種視野，部門主管只看得到自己單位與子單位。跨部門的知識開放另有一道閘門：開放給同單位的人按下就生效，開放給全公司得送申請、等管理員核可。
閘門能攔下申請，攔下之後准不准，仍需要管理決定「供應商比價屬於採購與經營層」。公司經常未能將決議寫下，我們則在導入階段上將這類問題一條一條提出討論，跟採購、業務與經營層當場定下來，寫成幾條看得懂的規則，再設成角色的範圍與服務窗口的開放對象。從那之後，邊界是一筆有紀錄的決定。
第三題：遇到錯誤時，如何釐清責任
一張對外報價單背後的成本結構，過去是成本會計算好、課長覆核、經理簽字，出錯時找得到人。
現在中間多了一段「AI 算的」。這一段沒有人掛名，不在職務說明書裡，也不在內控稽核的流程圖裡。實務上卡住導入的常常不是技術：沒有人願意在一份 AI 產出的報表上簽名。
這個顧慮不該被說服，而是該設計。把核准的對象從「這個數字」換成「這個動作」：主管簽的不是「毛利率 23.4% 正確」，是「這份成本結構可以送出給客戶」。這本是他在做的判斷。
在 EgentWrX 裡，核可點是建在流程中的。多個任務接續成工作流時，任何一段交棒都可以勾「交棒前需人工核可」，Agent 做到那一步就停下來等人放行，等太久有預設的逾時處理。
誰應該按放行，內控要先定。多少金額以下可以放行、哪些情況一定要人工重算，這些門檻散在簽核表單與慣例裡，FDE 做的是與財務與內控合作，補上「AI 算的」這一段該由誰簽，然後設成工作流的核可點。內控流程圖上原本沒有的那個位置，就這樣補上名字。
第四題：三個月後，還查得出當初是怎麼算出來的嗎
客戶對某一批貨的不良率提出質疑，要你證明這個數字怎麼來的。三個月前算這個數字的人，用的是哪一版判定標準、資料是從 MES 拉的還是從品保自己的報表拉的？
「當下看得到證據」跟「事後還原得了過程」是兩件事。對話當下 AI 附上資料來源與計算方式，解決的是使用者的信心問題。稽核要的則是一份三個月後仍然調得出來、可以逐步比對的紀錄。
留紀錄這件事，EgentWrX 做成涵蓋五十多種資源類型的驗證類型。管理者可以按「驗證完整性」當場重算整條鏈。要交給外部稽核就匯出成 CSV，下載這個動作本身也會被記一筆。
紀錄要留多久、要不要交給外部稽核員、對應哪一條客戶合約條款，答案在你的法遵與客戶合約裡。這一題最好在接第一條資料線之前決定。FDE 則會跟法遵、品保與業務一起翻客戶合約與稽核清單，列成一份要求清單，再對照系統的稽核與匯出設定逐項確認。
第五題：問得最好的那個人離職之後呢
導入三個月，成效集中在三個人身上：一個生管、一個製程工程師、一個廠務課的年輕同事。他們問得好，是因為知道哪個欄位不能信、哪台機器的良率要打折看。
其中一個離職。他帶走的不是資料，資料還在。他帶走的是「怎麼問」，而這件事從來沒有被存下來過。過去 know-how 在老師傅腦袋裡，現在在某個人的對話紀錄裡，組織的脆弱程度沒有改善。
一個人摸索出來的做法，在 EgentWrX 裡可以變成技能。描述成一段文字，由 AI 起草，先在自己的 Agent 上用。覺得值得全公司用，提案上架，管理員核准後進公司的技能庫，做法要改時只改這一份。知識資料上傳時就得選範圍，選「單位」的資料屬於整個部門，不因某個人離開而消失。
第六題：誰來維護這整件事
多數製造業的資訊課是一到三個人，工作重心是 ERP、網路、防毒與機台連線。現在要再加上：誰維護資料連線、誰審核新增資料源的申請、誰處理「AI 這個數字講錯了」的申訴。
回頭看 OpenAI 那句話。內部採用率做得起來，前提是資料團隊先建立了共用定義、存取規則與敏感資料防護。那個前提比那個數字重要，而多數台灣製造業目前沒有這個前提。
所以要問的不是「我們什麼時候會有資料團隊」，是「這件事誰承接」。
EgentWrX 不讓資訊課多養一份名單。帳號走 SSO，並且可以用 SCIM 讓公司既有的身分系統負責開通與停用，那邊移除了人，這邊的成員清單跟著同步。身分系統裡的群組直接對應成平台的角色與單位，同事第一次登入就有對的權限。
導入可以外包，決策不能外包。誰有權新增資料源、誰有權定義指標，這兩個名字一定要是公司裡的人。FDE 在第一條流程上的角色是把這兩件事做出來一次，讓被指定的人在旁邊看完整個過程，第二條流程換他做、我們看。
EgentWrX 的強項在哪一層
六題攤開來看，會發現 Data agent 和 EgentWrX 不在同一層。前者解的是「誰能開始分析」。後者解的是分析之後那一段：這個答案要變成什麼動作、誰負責、留不留得下紀錄、換了人還在不在。
把這一段做起來，靠的是三件事。
資料落點由企業決定。 EgentWrX 可以部署在雲端、企業自己的機房，或機敏資料留地端、推論送雲端的混合架構。接 ERP、MES 這類內部資料庫時，Agent 只能讀不能寫。Agent 對外的連線預設全部拒絕，只有列進白名單的目標放得出去。合約寫著資料不得離境的產業，這是能不能開始的前提。
每一步都留下可驗證的紀錄。 從呼叫模型、取用知識、寫回系統，到檢查碼鏈與完整性驗證，目的是讓「AI 算的」這一段在內控流程圖上有位置。
能力留在組織，不留在個人。 公司技能庫、單位範圍的知識、掛在職務上的 Agent，三個設計指向同一件事：人走了，做法留下來。
這三件事沒有一件是模型能力。挑平台的時候，用哪個模型該是最後一個問題，我們另外寫過：https://www.egentwrx.com/zh/perspectives/ai-agent-harness-execution-layer
那如果六題都還沒有答案呢
多數公司讀到這裡，六題還沒有現成答案，這很正常，你我都聽過的常見建議是：
先把資料整理好、口徑統一、權限重盤一次，再談 AI，但台灣多數製造業是無法執行的。
建議本身並沒有錯。問題是「整理資料」在這些公司從來不是一個專案，而是一個沒有終點的狀態。Excel 有幾千個，同一份表有七個版本，關鍵的判斷規則在幾位資深同事的腦袋裡。要整理到「可以交給 AI」的程度，需要一個專責團隊、兩到三年，以及一筆沒有短期回報的預算。這個建議的實際效果，是讓公司年復一年停在準備階段。
我們的做法順序是反過來的，分三步驟。
第一步：選一條流程，不是選一個部門。 標準有三個：範圍明確、口徑單純、出錯後果可控。像採購的到貨異常通知，或業務的客戶交期查詢，欄位少、規則清楚，有人可以當場判斷答案對不對。FDE 進駐的第一週就在做這件事，訪談各部門，把痛點場景列出來，挑最符合三個標準的那一條，不挑最痛的。
第二步：在這條流程上，把六題定成小尺寸的答案。 你不必一次統一全公司的指標，只需要決定這條流程裡「交期」怎麼定義、誰能問到、誰簽名、紀錄留多久、做法誰維護、規則誰承接。每一題都是 FDE 先跟相關的人問到可以拍板，拍板後設進系統。這一步的產出不是一份治理文件，是一條真的在跑的流程，加上六個有人簽名的決定。
第三步：把定好的東西當成第二條流程的起點。 第一條流程留下來的知識、技能、角色與規則，在系統裡已經是公司資產，第二條流程直接重用。這一次換公司裡被指定的人主導，FDE 退到旁邊看。
這不是叫你不要想清楚，是說有些事只有動起來才想得清楚。第一條流程跑三個月，你會知道真正的口徑衝突卡在哪幾個欄位、哪一份資料其實沒有人在維護，這些是紙上盤點問不出來的。
對沒有資料團隊的公司，治理不會先於使用出現。它是 FDE、同仁與系統在一條一條流程上，一起逼出來的。
跑順之後會遇到下一批問題，我們寫在 https://www.egentwrx.com/zh/perspectives/ai-agent-governance-after-poc 。在那之前，先挑一條流程。