TREND · AGENTIC AI · ENGINEERING GOVERNANCE

Agentic AI 已走向工程決策場景:為什麼企業治理落差正在放大?

從 BOM 變更、需求分析到受控執行,解析 AI Agent 進入工程流程後的身分、權限、驗證、人工核准與稽核挑戰。

工程 AI 的問題,正在從「答得對不對」變成「能不能安全地做」

Siemens 已公開可在 Teamcenter 受治理流程內理解 BOM、分析影響並執行經人工確認之變更的 AI BOM Agent;PTC 則以受權限控制、提供來源引用的 Windchill AI Assistant 協助工程人員取得可信產品資訊。兩者顯示工程 AI 已進入不同成熟度的決策場景。

FROM ANSWERS從找資料開始自然語言搜尋、摘要、引用與工程知識取得。
TO ACTIONS走向受控執行分析 BOM 影響、建立變更並使用系統工具。
GOVERNANCE GAP控制成熟度不一致身分、授權、稽核與回復常落後於 Agent 能力。
「治理落差正在放大」是本文根據產品能力與治理要求所做的市場觀察,不代表所有企業都缺乏制度,也不是沒有研究方法支持的量化排名。

Agentic AI 已經進入哪些工程工作

依目前公開產品資料,工程 AI 已涵蓋 BOM 查詢、組態導覽、where-used 與影響分析、零件替換、工程變更啟動、需求品質檢查,以及規格與企業文件搜尋。真正的分水嶺,是系統是否只提供資訊,或已能使用工具推動後續工作。

BOM NavigationImpact AnalysisPart ReplacementChange InitiationRequirement QualitySource-grounded SearchVerification GapsControlled Execution

這些能力不能一概描述為「自主決策」。有些是受權限控制的搜尋與問答,有些能建立草稿,另一些則在人工確認後執行特定動作。

產品叫 Assistant、Copilot 或 Agent,不代表能力邊界相同

AI 問答、Assistant、Copilot 與 Agent 從回答到執行的能力及風險差異
銳碁資訊依官方產品資料與治理框架整理之概念示意;產品名稱不能取代實際功能與權限查證。
類型主要能力是否執行動作典型風險
AI 問答搜尋、摘要及解釋資訊。通常不執行。答案錯誤、來源不明。
Assistant依權限取用資料並提出有來源的答案。通常有限。錯誤引用、過度依賴。
Copilot協助完成多步驟工作、建立草稿及提出建議。視產品功能而定。使用者未理解變更影響。
Agent規劃任務、選擇工具並執行授權動作。可以。越權、連鎖錯誤、責任不清。
高度自主 Agent在有限監督下持續完成目標。較高程度自主。錯誤累積、難以停止與回復。

從 BOM 洞察走向執行,是工程 AI 的重要轉折

Siemens Teamcenter Copilot for BOM 官方操作畫面
官方圖片來源:Siemens · How AI BOM agents transform engineering change workflows。

Siemens 將 Teamcenter Copilot for BOM 描述為能理解受控 BOM 結構、依 revision、variant 與 effectivity 規則分析產品脈絡,並協助執行零件替換、BOM 組態及工程變更等工作。官方特別說明,變更在既有治理、存取控制與流程中發生,BOM 更新前保留 human-in-the-loop confirmation。

這不等於 AI 可以自行核准所有 ECO 或修改任意資料。能否使用、可執行哪些動作,以及哪些節點仍由責任人核准,仍取決於正式產品版本、系統設定、授權與企業流程。

可信搜尋與來源引用,是另一條治理路徑

PTC Windchill AI Assistant 的公開資料主要聚焦在受權限控制的產品資料問答。系統能依設定搜尋企業 Windchill 文件與 PTC 官方支援內容,並在回答中附上來源引用;使用者仍需具備讀取或下載相關文件的權限。

ACCESS CONTROL

沿用受控權限

回答不應突破使用者原有的文件存取範圍。

CITATIONS

提供來源證據

文件名稱、版本、位置及官方說明協助人工驗證。

BOUNDARY

不等於變更 Agent

官方資料未因此證明其能自主修改 BOM 或核准變更。

「能找到並解釋資料」和「能修改受控資料」是不同能力階段。把所有 AI 助理都稱作自主 Agent,反而會讓風險評估失去準確性。

治理落差不只來自模型,而是企業尚未管理 Agent 的行動

許多既有控制是為人員帳號與固定程式設計;Agent 卻可能代表使用者跨系統讀取資料、選擇工具並形成連續動作。當能力從回答走向執行,原本足以管理查詢的權限,不一定足以約束行動。

  1. Agent 沒有獨立身分,無法區分人員操作與代理行動。
  2. 只沿用使用者權限,沒有額外限制 Agent 可做的動作。
  3. 沒有區分讀取、建議、草稿、執行及核准等風險層級。
  4. 缺少 Prompt、模型版本、來源、工具呼叫及輸出的完整紀錄。
  5. 人工確認只有按鈕,卻沒有充分的差異與影響資訊。
  6. 錯誤後沒有停止、撤銷、補償交易或基線回復。
  7. 測試只看文字答案,沒有評估對 PLM、ERP、MES、ALM、QMS 的後果。
  8. 第三方模型、Plugin、API 與外部資料流未納入供應鏈治理。

工程 Agent 應依動作風險分級,而不是一次取得完整權限

工程 AI Agent 從讀取、建議、草稿、受控執行到正式核准的治理分級
銳碁資訊依 NIST、ISO 與工程變更治理原則整理之概念示意;並非正式標準分級。
層級允許行為最低控制
Read讀取核准範圍內的資料。來源白名單、最小權限與查詢紀錄。
Recommend分析並提出建議,不改變正式資料。顯示依據、版本、不確定性及影響。
Draft建立變更草稿或 Redline。隔離正式基線,人工檢查完整差異。
Execute通過規則及人工確認後執行限定動作。短效授權、工具白名單、完整稽核及可回復。
Approve使高風險工程變更成為正式基線。明確責任人與雙人覆核;原則上不直接交由 Agent。

Agent 身分與授權,不能只藏在使用者帳號後面

NIST/NCCoE 在 2026 年啟動的 Agentic AI Identity and Authorization 工作,聚焦 Agent 的識別、驗證、授權、委派、稽核、不可否認性、資料流與 Prompt Injection 等問題。這項工作反映 Agent 進入企業系統後的新控制需求,但目前仍是持續發展中的計畫與實作資源,不是已完成的強制標準。

  • 每個 Agent 使用可識別且可撤銷的身分。
  • 記錄它代表哪位使用者、角色、服務或工作流程。
  • 採用最小權限,限制產品、資料、工具、動作與時間。
  • 對高風險工具使用額外確認及短效授權。
  • 記錄工具呼叫、資料流、結果及後續系統影響。
  • 設定 Prompt Injection、資料外洩與越權行為的防護。
  • 提供立即停止、撤銷憑證及隔離執行中的方法。

工程決策不能只留下聊天紀錄

可稽核的 Agent 行動,至少應保留以下證據:

User IdentityAgent IdentityPurposePromptModel VersionPolicy VersionSource DataDocument RevisionTool CallsChanged ObjectsAI RecommendationHuman ConfirmationApproval ReasonExecution ResultRollbackValidation Result

聊天紀錄只能說明使用者問了什麼,卻未必能證明 Agent 實際讀取哪些版本、呼叫哪些工具、修改哪些產品物件,以及由誰承擔正式決策責任。

Agent 驗證要測試整段任務與失敗路徑

驗證面向需要回答的問題
任務結果是否完成正確任務,而不是只產生看似合理的文字?
資料脈絡是否使用正確 revision、variant、effectivity 與成熟度狀態?
權限遵循是否只讀取及執行被授權的內容與工具?
影響分析是否辨識所有受影響產品、文件、測試及下游系統?
不確定性資料不足或衝突時,是否停止並要求人工判讀?
安全回復錯誤、逾時或部分完成時,是否可隔離並回到有效基線?
稽核完整度第三人能否重建決策依據、執行過程及核准責任?

驗收門檻應依使用情境與企業風險設定。沒有可追溯研究資料時,不應自行宣稱通用準確率或自動化比例。

NIST、ISO 42001 與 EU AI Act 提供不同層次的治理支點

NIST AI RMF

治理、辨識、量測、管理

AI RMF 及 GenAI Profile 提供跨生命週期的風險管理方法;並非 Agent 專用認證。

ISO/IEC 42001

AI 管理系統

以持續改善的管理制度處理 AI 政策、責任、風險與控制。

EU AI ACT

依用途與角色判定

義務取決於系統用途、風險及供應鏈角色;不是所有 Agent 都自動屬於高風險。

這些框架不能取代工程專業責任、產品安全案例與正式變更流程。企業仍需把原則轉成特定系統、資料、角色及工具的可執行控制。

先開放低風險能力,再以證據逐步擴大

  1. 盤點所有 AI Assistant、Copilot、Agent 與自動化工具。
  2. 列出每個工具能存取的資料、系統、API 及動作。
  3. 依工程、安全、資安、品質及法規影響分級。
  4. 先開放 Read 與 Recommend,建立使用與錯誤基線。
  5. 在沙盒、模型副本或非正式基線中測試 Draft。
  6. 建立人工確認、雙人覆核與責任人規則。
  7. 驗證身分、最小權限、稽核、停止及回復能力。
  8. 使用真實但隔離的工程案例測試失敗路徑。
  9. 完成資安、法務、品質及產品責任審查。
  10. 通過驗收後,才逐步開放限定範圍的 Execute。

最成熟的 Agent,不是最自主,而是最清楚自己的邊界

Agentic AI 已開始從工程問答走向工程行動。當 AI 可以建立變更、呼叫工具或修改產品結構,風險就不再只是答案錯誤,而是錯誤內容進入正式基線並沿數位主線傳播。

企業的治理落差,來自 Agent 能力演進速度與控制成熟度不一致。真正可用的工程 Agent 應具備清楚身分、最小權限、完整來源、人工核准、端到端驗證及安全回復;它不是繞過治理,而是在治理邊界內可靠工作。

延伸閱讀

先畫出 Agent 的資料、工具與決策邊界

選擇一項工程流程,盤點每個動作需要的身分、權限、證據、核准及回復方式,再決定適合開放到哪個治理層級。

預約顧問說明 ↗

官方資料來源

資料查閱日期:2026 年 10 月 20 日。本文為產業與工程治理趨勢整理,不構成法律、認證、產品安全或採購建議。