案例04｜全球製造商：Public API 在 Pilot 可用，全球部署卻卡在敏感資料與延遲

一、案例定位

本案例依原書第 4 章 Foundation Shift 情境重組，並非原書正式案例研究。

理解 Pilot Architecture 為何可能在全球部署時因資料邊界與 Network Latency 而需要根本調整。

二、學習目標

辨識 Public Endpoint 的企業限制。
把資料敏感度與跨區延遲納入架構。
理解「Pilot 成功」不等於架構可直接放大。

三、案例情境

某全球製造商的 AI Quality Control System 在 Pilot Facility 使用 Public API Endpoints 運作良好。但準備全球部署時，團隊發現敏感 Production Data 不能經由 Public Endpoints 處理，而且全球工廠與中央 AI Service 之間的 Network Latency 也成為重要問題。

四、開始資料

條件	Pilot	Global Deployment
API Endpoint	Public Endpoint 可運作	敏感 Production Data 不可依原方式處理
地理範圍	單一 Pilot Facility	Global Facilities
Latency	不是關鍵瓶頸	跨區 Network Latency 成為 Critical Concern
架構結果	初始部署成功	需要 Fundamental Architectural Changes

五、Excel／AI 分析方法

Excel 可記錄各地區 Endpoint、資料分類、Latency 與允許的 Data Boundary；AI 可整理架構選項與風險，但不能在未測試時宣稱某區域延遲符合要求。

六、計算結果

原書沒有提供延遲毫秒數、工廠數或吞吐量，因此不建立數值 SLA。

七、結果分析與管理解讀

規模化會把原本不重要的約束放大。資料主權、安全邊界與跨區延遲都可能讓 Pilot 的簡單架構無法沿用。

八、AI 提問詞

請比較 Pilot 與 Global Deployment 的資料邊界、Endpoint、Latency 與 Security 條件，列出哪些元件需要重新設計。沒有實測 latency 時，不要宣稱符合 SLA。