關於智慧城市 AI 代理，系統整合前要檢查的 5 件事

很多人第一個會先想到 AI 代理能不能讓城市更快做決策。這個問題要先定義清楚：城市真正遇到的是資訊分散、跨單位交接耗時，還是既有流程無法及時回應？NVIDIA 於 2026 年 10 月描述歐洲城市與合作夥伴探索或建置相關應用，涵蓋城市營運決策支援、公共服務協調與數位雙生。這是供應商發布的案例，不能單獨證明成效可移植到其他城市。台灣技術團隊評估智慧城市 AI 代理時，應先看它接在哪個流程、能動用哪些資料，以及誰承擔最後決策責任。

一、先定義 AI 代理在城市流程中的位置

先寫清楚它要處理的城市問題、輸入資訊、輸出內容，以及輸出後由誰採取行動。AI 代理可以整理訊號或提出建議，是否能進一步操作系統，必須另外界定。

NVIDIA 的案例涵蓋多種成熟度不同的應用。法國 Côte-d’Or 省的營運代理結合感測器、基礎設施及歷史資料，支援公共建築的能源、合規、安全與氣候韌性管理；NVIDIA 表示，該案例文件搜尋時間由數週縮短到數分鐘，營運成本降低 10%，並以擴大部署時降低 30% 為目標。這些數字是廠商文章所述，應視為單一案例的自述，尚不足以推論其他城市會得到相同結果。

其他例子仍在探索或測試階段。利物浦城市區與 K2K 探索用 AI 支援都市規劃、公共服務、交通與安全；安特衛普港則測試視覺 AI 能否協助油污警示等情境。把「探索」「測試」寫成已正式營運，會高估案例成熟度。評估時應逐項詢問目前是構想、試辦、部署，還是已經納入常態流程。

資訊整理、任務協調、決策執行是不同層次。代理若只摘要交通、設備或案件狀況，錯誤可能由人員辨認；若能派工、調整號誌或改變公共服務資格，錯誤就可能直接影響市民。設計需求時要把每一層的輸入、輸出、權限和責任人分開描述，避免「智慧城市代理」這個總稱遮住實際風險。

二、系統整合的根因常在資料、流程與角色

優先盤點資料定義與更新時間、既有系統介接方式、身份權限、操作紀錄，以及實際負責接手的人員。模型能運作，不代表它取得的資訊足以支援現場流程。

城市資料分散在交通、建管、能源、環境與客服等系統。即使欄位名稱相同，單位、更新頻率、空值處理或地理範圍也可能不同。交通流量是即時值還是每小時彙整？設備狀態多久更新一次？跨局處的地址與案件編號能否對應？如果來源資料已過期或相互矛盾，代理可能給出語句流暢、依據卻不完整的建議。

同一套介接也不一定能直接複製到鄰近城市。各地的採購條款、資料治理權責、緊急應變程序與既有系統不同，技術團隊需把可共用元件與地方規則分開管理，避免擴點時把前一地的假設帶進新場域。

介接盤點也要記錄系統邊界。列出每個資料來源的擁有單位、讀寫權限、介面與服務中斷時的替代作法，確認外部廠商、城市資訊部門與業務單位各自負責什麼。先以唯讀方式提供資料，通常較容易限制影響範圍；若要讓代理寫回派工或案件系統，還需設計核准流程、回復機制與完整操作紀錄。

資料盤點還要包含「誰有權改定義」。例如同一個道路施工案件，在工務系統可能代表已核准工程，在1999案件系統則可能仍是民眾通報；若代理把兩者合併成同一事件，可能重複派工或誤判處理狀態。城市團隊可建立欄位對照表，說明資料來源、更新時間、有效期限、缺值意義與維護單位，並釐清哪個系統是正式紀錄。遇到跨局處資料，也要先確認分享目的、保存期限及可供模型處理的範圍。

介面可用性與權限也要一起檢視。確認 API 是否有穩定的版本與錯誤回應，尖峰時段能否承受查詢量，帳號是否採用個人或服務身分，以及憑證如何輪替。對外部供應商開放資料時，需限定用途、存取期間及可下載範圍，並保留可查的存取紀錄。若資料不能離開城市管理的環境，也要比較本地運算、委外服務及混合架構各自的維護責任，不能只看模型部署位置。

英國政府的公共部門演算法透明度指引要求說明工具用途、責任角色、輸入與輸出，以及它在整體決策流程中的位置。指引也提醒機關應描述供應鏈各方分工。這些欄位可作為城市團隊盤點文件的參考，並非台灣法規要求。

「應清楚說明演算法工具如何、為何被使用。」英國政府公共部門演算法透明度指引建議以一般人能理解的方式交代工具及其用途。

功能無法進入日常流程，常因現場角色與觸發條件沒有被建模。誰收到警示、誰判斷是否派工、跨單位案件逾時要找誰？若這些答案不在流程設計裡，系統最後可能只多出一個需要人工盯看的儀表板，卻沒有接上原有服務責任鏈。

三、用分階段驗證判斷建議能否採用

先用歷史事件回放和模擬情境檢查輸出，再進入不觸發實際操作的影子模式，最後才在範圍受限且可回復的試辦中觀察。摘要正確與建議可採用，必須分開評估。

回放資料可檢查代理能否正確找出事件、引用來源及呈現時間；模擬則可測試罕見或高影響情境，例如道路封閉與大型活動同時發生。影子模式讓系統產生建議但不執行，團隊可將結果與實際處置、操作人員判斷逐件比較。進入受控試辦後，再追蹤建議被採納或退回的原因、處理時間、錯誤類型，以及各類案件是否有不同影響。

測試指標應對應要解決的問題。若目標是減少跨單位轉派時間，就要記錄從事件進件到責任單位接手的時間，而不能只看代理回覆速度；若要減少漏掉設備異常，則需抽查不同設備類型、時間帶與資料缺漏情境。設定基準時，最好保留現行人工流程的表現作比較，也要記下人員因何接受或駁回建議。單一平均分數會掩蓋少數高影響錯誤，應另看錯誤嚴重度、資料品質差異及受影響服務對象。

試辦也需有明確的停止條件。當建議錯誤可能導致安全事件、關鍵資料長時間無法取得，或實際工作量反而增加時，負責單位應能暫停系統並回到既有程序。完成一輪測試後，將新發現的錯誤回饋到資料修正、提示設計或流程調整，再以相同情境重測。這樣才分得出改善來自系統更新、資料變動，還是作業人員熟悉工具後的適應。

NIST 的 AI 風險管理框架將風險工作整理為治理、情境辨識、衡量與管理，並指出實驗室或受控環境的結果可能與真實運作不同。這能提醒導入團隊把測試延伸到現場條件，不過框架不會替個別機關訂出可接受風險門檻。

「在實驗室或受控環境衡量風險，可能與實際運作環境出現的風險不同。」NIST《AI RMF 1.0》因此提醒組織依使用情境評估系統。

資料過期、來源中斷、代理無法判斷或輸出互相矛盾時，系統要能顯示原因、停止高影響動作並交回既有流程。團隊可為每種失效情境設定告警對象、服務降級方式與恢復條件。若無法確認輸入資料的時間或來源，應讓操作人員知道哪些資訊缺失，避免把不確定性包裝成確定答案。

四、人工監督要對應責任與決策邊界

涉及公共安全、權益、資源分配或難以回復的操作，應由具權責的人員核准。低風險的資料整理可先由人員抽查，但監督方式仍要符合實際影響與組織規範。

代理參與程度	例子	導入時的控制重點
資訊整理	彙整設備告警、搜尋案件紀錄	顯示來源、時間與缺漏，提供人工查閱
提出建議	排列巡檢順序、提示可能的道路風險	留存採納或退回理由，抽查不同情境表現
觸發操作	建立派工、修改系統設定或調度資源	設定授權範圍、逐筆核准、撤回與緊急停用

人工監督不是畫面上增加一個「確認」按鈕。操作人員需要看得到建議依據、資料時間與不確定處，並有足夠權限拒絕、修改或升級處理。主管也要知道誰能停用功能、停用後由哪個單位接手，以及代理的版本或資料來源變更後由誰重新核准。

監測責任要涵蓋上線後的變化。道路工程、交通習慣、設備汰換與局處分工都可能改變輸入資料的樣貌；原本有效的規則或代理輸出，未必適用於新情境。營運單位應訂出定期檢視節點，追蹤資料延遲、錯誤通報、人工退回比例與未處理案件，並記錄何時需要重新測試或縮小使用範圍。若責任只寫在採購文件，第一線人員仍可能不知道異常時找誰。

若決策會影響市民權益，還要說明如何提出異議或要求人工複核。英國指引將工具輸出與後續決策流程分開檢視，並要求考慮是否存在申訴或審查管道。這項作法可供城市服務設計參考，實際適用義務仍須依所在地法律與機關制度判斷。

五、導入前依序完成五項檢查

依序確認問題範圍、資料品質、介接與權限、驗證方式、人工責任及失效替代流程。每一項都能說明負責角色與通過條件，再考慮擴大試辦。

1. 定義問題：選定一個流程，記錄目前延誤、錯誤或重工發生在哪裡，避免先從模型功能倒推需求。
2. 盤點資料：確認來源單位、欄位定義、更新頻率、缺漏和使用限制，標示不能用於決策的資料。
3. 界定權限：先決定唯讀或可寫入，寫清楚每種角色可查看、核准、修改與停用的範圍。
4. 設計驗證：訂定回放、模擬、影子模式與試辦的評估項目，分別記錄摘要錯誤和建議不適用的案例。
5. 準備失效方案：確認人工接手、服務中斷時的替代流程、事件通報與恢復條件，並指定持續監測的單位。

NVIDIA 描述的歐洲案例提供了城市營運與公共服務的應用線索，不能代替本地驗證。對台灣的技術團隊而言，適合的起點是一個範圍明確、可回復的城市流程。先把資料來源、系統權限、建議檢驗方法、核准角色和失效替代流程逐項確認，再依試辦結果判斷是否擴大。

• 先定義 AI 代理要處理的流程問題，再確認它能讀取或操作哪些系統。
• 把供應商案例數字視為該案例的自述，不能直接當成其他城市的預期成效。
• 高影響操作須明確設置人工核准、操作紀錄、停用與替代流程。

常見問題

Q1：城市 AI 代理可以直接操作既有系統嗎？

技術上是否可介接，取決於系統介面與權限設計；是否應開放操作，則要看影響程度、可回復性及責任安排。可先用唯讀資料或不執行動作的影子模式評估，再逐步決定權限。

Q2：什麼情況適合先做概念驗證？

當流程問題明確，但資料品質、建議效用或現場工作方式仍待確認時，可先以小範圍概念驗證測試。需預先設定成功條件、觀察期限、退出方式與資料使用邊界，避免試辦在沒有決策點的情況下延長。

Q3：導入後由誰負責監測與停用？

應由機關指定一個負責營運的角色或單位統籌，並讓資訊、業務與供應商責任可追溯。監測者需有權通報異常或停用功能，並知道停用後由哪個既有流程接替。