這是系列的最後一篇。前四篇分別談了 AI Agent 的成本結構、外部 API 的三個結構性風險、自建 GPU 的四道關卡，以及算力層的五個治理能力與三條實作路線。這一篇不講新概念，只做一件事：把它們收成一張可以直接拿去開會的決策地圖。
地圖分三段：先依工作負載決定「走外部 API、落地自建、還是混合」，再依產業補上各自的關鍵條件，最後是採購時該要求供應商回答的六個問題。
第一段：依工作負載分流，而不是依公司分流
最常見的錯誤是把「我們要走 API 還是自建」當成一個公司層級的單選題。實務上，同一家企業的不同 AI 流程會落在不同的答案。判斷每一條流程時看三個軸：
- 資料敏感度。這條流程碰到的資料，依法規或商業機密是否不能送到境外處理。核心帳務、病歷、公文本文、製程參數多半是「不能」。
- 可用性要求。這條流程斷三小時，貴司的營運會怎樣。臨床、交易、對外服務的流程通常不能接受「等供應商修好」。
- 流量形狀。穩定的、可預測的、可以排程的流量，適合自建；突發的、不規則的、偶爾才用的流量，適合外部 API 的彈性。
三個軸看完，多數流程會落在四種組合：
- 低敏感、可容忍中斷、突發流量：走外部 API，經過貴司的閘道。行銷文案、一般客服問答、內部知識查詢。
- 高敏感、任何可用性、穩定流量：落地自建。病歷摘要、帳務核對、公文草擬、製程異常分析。
- 高敏感、但流量極低：落地，但用最小規模的路線一（單機容器化），不需要平台。
- 低敏感、但可用性要求高：外部 API 為主、本地路徑為備援，閘道負責切換。對外的客服 Agent 常是這一類。
盤點完貴司所有的 AI 流程，把它們填進這四格，自建的規模就出來了。它等於第二格加第三格的流量，通常遠小於「把全部搬回來」的想像。這就是第三篇說的「第一批只買不能出去的那部分」。
第二段：四個產業各自的關鍵條件
銀行與金融機構
金管會已表明將把代理式 AI 與風險分類納入金融業 AI 指引，治理與問責會是稽核的重點。關鍵條件：每一次 AI 推論都要可追溯、可歸因、可解釋，這對應第四篇的能力二與能力四。銀行多半已有企業版容器平台與成熟的變更管理，路線三是自然選擇，但要把 AI 推論納入既有的營運持續計畫，而不是另外寫一份。
大型醫療院所
衛福部 2026 年 5 月的醫療機構生成式 AI 指引要求臨床相關情境由具資格的醫事人員負最終責任，醫療主權雲方針的核心是資料留台與金鑰自主。關鍵條件：病歷相關流程幾乎都落在「必須落地」；機房條件常是瓶頸，境內代管是務實的第一步；研究部門若已有高效能運算環境，路線二與路線三會並存。另一個常被忽略的條件是，醫院導入 AI Agent 的治理能力（隔離、歸因、可觀測、人員最終確認）在指引裡是明文要求，不是加分項。
大型科技製造業
沒有專屬指引，但製程參數、良率與供應鏈資料是核心競爭力。關鍵條件：廠區機房環境、多廠區的資料同步、以及研發與生產兩種完全不同的工作負載。製造集團常有的優勢是已經有工廠端的邊緣運算基礎，可以把部分推論放到靠近產線的位置。集團層級的成本歸因特別重要，因為 AI 預算往往跨事業部。
政府機關與公部門
人工智慧基本法已於 2025 年 12 月三讀，國科會為主管機關，資料治理機制由數位發展部負責。關鍵條件：採購程序的時間、公文與民眾資料的敏感度、以及跨機關共用算力的可能性。政府最應該避免的是每個機關各買一批 GPU 各自閒置；第四篇的多租戶隔離與配額歸因，正是讓多個機關共用同一批算力的前提。規格書用「要跑什麼」而不是「要買什麼」來寫，在採購與驗收時最站得住腳。
第三段：分階段導入，三步走
- 治理先行。建立統一閘道、埋點歸因、資料分級。不買任何硬體。這一步讓貴司看見現在的用量與成本曲線，並且確認哪些流程必須落地。這一步不動任何既有系統。
- 最小落地。只為必須落地的流程建第一批算力，多半是路線一或境內代管。跑出真實的使用率與內部帳單。
- 依數據擴充。當第二個部門要用、預算單位要帳單、SRE 要接手，三件事發生任何一件，就走向路線三的平台化。每一批擴充都建立在上一階段的數據上。
三步的共同原則：每一步都可以停，每一步的產出都是下一步的依據。第一步停下來，貴司至少得到了成本可見度與資料分級。第二步停下來，至少不能出去的資料已經留在境內。不會出現「花了三年預算，最後發現不需要」的結局。
第四段：採購時要求供應商回答的六個問題
不論貴司最後選擇外部 API、自建平台或商用 AI 平台，這六個問題都值得寫進需求書：
- 每一次推論能否被歸因到部門、流程與任務類型，並產出月報？
- 資料在處理過程中經過哪些位置，是否全部在台灣境內，貴司能否稽核？
- 供應商或平台中斷時，切換到備援路徑需要改動業務系統嗎？切換是自動的嗎？
- 更換模型、推論框架或 GPU 世代時，業務系統需要重寫嗎？
- 多個部門共用時，配額、優先權與故障隔離怎麼做？
- 驗收能否用貴司自己的工作負載實測，而不是供應商的基準數字？
六個問題分別對應這個系列談過的成本歸因、資料主權、可用性、可攜性、多租戶隔離與規格驗收。答不出來的問題，就是貴司未來的風險所在。
系列結語
AI Agent 的部署不是「API 或自建」的選擇題，而是「哪些流程、在什麼條件下、放在哪裡」的分流題。答對分流題的企業，帳單可控、資料可稽核、系統可接手。
品得網絡在這個領域的角色不是賣硬體、賣平台或賣模型，而是陪貴司把這張地圖填完：從閘道與埋點開始，到資料分級、最小落地、平台化，每一步都與貴司的資訊團隊一起做，讓能力留在貴司內部。如果這五篇文章談的問題正是貴司現在面對的，歡迎聯絡品得網絡，從一份現況盤點開始。
常見問題
我們規模不大，這張地圖適用嗎？
適用，而且會更簡單。規模小的企業多數流程會落在「走外部 API 經閘道」與「高敏感但流量極低、單機落地」兩格。第一步的治理先行不需要任何硬體投資，是所有規模都應該做的。
混合架構會不會反而更複雜？
複雜度集中在閘道這一層，業務系統本身不需要知道請求最後去了哪裡。只要閘道做對，混合架構對業務系統來說跟單一路徑沒有差別，而貴司得到的是可切換、可稽核、可擴充的彈性。
第一步的治理先行，具體要交付什麼？
三樣東西：一個所有 AI 呼叫都經過的閘道、一份能把帳單拆回部門與流程的歸因報表、一份明確標示哪些流程必須落地的資料分級清單。這三樣是後面所有決策的依據。
