作者：Sunny Shih
過去，醫療 IT 的核心任務相對明確：讓 HIS、PACS、LIS、EMR 與醫療設備穩定運作，確保臨床服務不中斷。但 RAG、生成式 AI、AI Agent、Data Platform 與研究運算陸續進入醫院後，IT 團隊開始面對一批性質截然不同的 workload——它們需要更彈性的運算資源、更頻繁的模型與知識更新，也必須跨系統串接資料與 API。這也是醫療機構重新思考上雲的原因：原本支撐傳統醫療資訊系統的 IT 架構，不一定適合承接快速演進的 Data 與 AI workload。
iKala 團隊在第一線觀察到，當 AI 從概念驗證走向日常營運，問題很快就從「做不做得到」變成「能不能長期運作」：誰可以登入？哪些資料可以被存取？Knowledge 如何更新？Prompt 與 Model 如何版本控管？Audit Log 怎麼留？AI 答錯時誰介入？服務中斷後又如何恢復？
這些問題背後都牽涉身分、資料、資安、復原與後續維運，也揭示了 PoC 與 Production 最實際的差距：PoC 證明技術做得到；Production 則要確保服務管得住、查得到、救得回來，也有人持續維護。
醫療產業為什麼需要上雲？哪些系統該上雲、哪些該留下？
談醫療上雲，很容易把問題簡化成 Cloud Migration：哪些伺服器要搬？選哪一家 Cloud？一年可以省多少硬體成本？
但醫療環境真正需要回答的問題，其實更接近：
「這個 workload 如果中斷，醫院會發生什麼事？」
一套研究資料分析環境停機數小時，和床邊系統、醫囑或給藥交易中斷數小時，影響完全不同。同樣是醫療資料，影像封存、研究資料集、院內知識庫與核心病歷系統，對網路、延遲、既有介面與復原時間的要求也不一樣。
因此，規劃醫療雲端架構時，不宜先從「Cloud 或 On-premises」二選一，而應先判斷 workload 的特性與風險。iKala 團隊提出六個評估面向，包括臨床關鍵性、資料敏感度、網路與延遲依賴、整合複雜度、法規與契約，以及營運成熟度，再據此判斷 workload 適合留在地端、採 Hybrid Cloud（混合雲），或進一步評估 Public Cloud（公有雲）。
不同工作負載的部署方式自然也不同。開發／測試、非臨床行政系統，以及備份與 DR 副本，可優先評估上雲；研究運算、RAG、企業知識與影像封存，則需要在資料權限、日誌、成本或系統介接等條件到位後再導入。至於核心 HIS、床邊與給藥交易等高度影響臨床連續性的系統，現階段仍以地端或混合架構為主，並需同步考量 WAN fallback、設備介接、臨床降級與復原驗證。
換句話說，醫療上雲相較於決定「整間醫院要不要搬上雲」，逐一判斷不同 workload 最適合放在哪裡，以及上雲前必須具備哪些控制條件更為理想。
想了解更多？立即報名 iKala AI 醫療講座！
AI PoC 為什麼常在「準備上線」時卡住？
PoC 階段，團隊通常只需要驗證一件事：AI 能不能完成預期任務？
以院內 RAG 為例，最簡單的架構可能只有：
文件 → Search / Retrieval → LLM → 使用者
只要檢索結果與回答品質符合預期，PoC 就可以視為初步成立。但到了 Production，架構設計的單位不再只是「模型」，而是完整的服務與資料流。
例如，使用者送出問題之前，系統需要先確認身分與權限；RAG 檢索時，只能取得該使用者有權存取的知識來源；模型產生回答後，還需要留下必要的操作與系統紀錄，特定情境則可能進入人工覆核。當模型、Prompt 或知識來源更新，也必須重新確認變更是否影響原本的服務品質。
因此，Production 架構更接近：
User → Identity / IAM → AI Application → RAG / Model → Authorized Data → Evaluation / Logging → Human Review → Monitoring
其中，「Authorized Data」往往比架構圖上的一個方塊複雜得多。
院內規章等文件可能適合使用 Role-Based Access Control（RBAC）；涉及病人資料後，權限還可能與科別、照護關係、時間與使用情境有關。急診等特殊情境甚至需要處理 Break-glass access。這類需求可能進一步採用 Attribute-Based Access Control（ABAC）或其他 context-aware policy。
權限也必須一路延伸到 Retrieval。即使文件已經切成 Chunk、建立 Embedding 並寫入 Vector Store，使用者仍只能檢索符合授權範圍的內容。Metadata、Filtering、Index Design 與 Query Performance 都會因此進入架構考量。「使用者已經登入」與「這次 Retrieval 有權取得這筆資料」是兩個不同層次的問題。
根據 RAND Corporation 研究指出，AI 專案失敗率超過 80%。 iKala 團隊觀察，在醫療產業中，上述即是許多 PoC 在「功能已經做好」之後，仍需要一段時間才能正式上線的原因。（而大多企業在這長時間等待中便會宣告「放棄」、「失敗」）
PoC 到 Production 的關鍵，除了把 AI Application 部署上線，更是需要讓 AI 進入一套可以持續治理與營運的架構。
如果醫院不希望每做一個 AI 專案，就重新建立一次這些能力，下一個問題自然是：共同的基礎架構應該怎麼設計？
醫療產業 AI 正式營運需要什麼？從 Cloud、Data 到 AI Foundation
一套正式的醫療 AI 服務，可以從底層往上理解成四個層次：
這四層描述的是能力與治理範圍，實際部署通常會橫跨 On-premises 與 Public Cloud。病歷資料可能留在院內，Identity 沿用既有 IdP，部分模型或資料服務部署於 Cloud，再透過 API 與院內系統交換資料。
因此，Production Architecture 還要進一步畫清楚 Data Flow、Identity Flow、Network Path 與 Trust Boundary：資料經過哪些系統？身分與權限在哪裡驗證？哪些服務需要跨越院內與 Cloud？其中一個節點中斷後，服務又如何降級或復原？
醫師、護理師或行政人員接觸的是最上方的 Healthcare Application；下面三層則支撐它的資料使用、AI 生命週期與日常營運。
Cloud Foundation：建立可重複使用的基礎控制
Cloud Foundation 涵蓋 IAM、Network、Logging、KMS、Backup、Security Policy 與 FinOps 等共通能力。
假設院內同時有研究運算、RAG、備份與不同科部的 Cloud 專案，每一組團隊都自行建立帳號、網路與權限，剛開始或許運作得很快。專案一多，維運難度就會逐漸浮現：誰的權限該撤銷？日誌保存多久？金鑰由誰管理？成本該算在哪個科部？
Cloud Foundation 提供一套共同控制基礎，後續 workload 可以沿用既有規則，IT 與資安團隊也比較容易維持一致的管理方式。
以 KMS 為例，「資料已加密」還不足以回答醫院的治理問題。團隊需要進一步確認金鑰由誰建立、誰可以使用、如何輪替與撤銷，以及院方與 Cloud Service Provider 各自掌握哪些控制權。依 workload 的風險與服務能力，也可能評估 Customer-Managed Encryption Keys 或 BYOK（Bring Your Own Key）等模式。
FinOps 在生成式 AI 環境也有新的變數。Model 選擇、Context 長度、RAG 每次帶入的內容量、多輪對話，以及 Agent 執行任務時的呼叫次數，都會影響實際成本。Production 環境可以進一步設定 Project / Department Quota、Usage Monitoring、Rate Limit、Timeout 與 Spending Guardrail，讓異常用量在發生過程中就能被發現與限制。
✦延伸閱讀：Gemini Enterprise Agent Platform 是什麼？一次看懂 Google 企業 AI Agent 平台
Data Foundation：資料進入模型前，先畫清楚使用邊界
醫院擁有大量資料，但資料通常分散在 HIS、PACS、研究環境、資料庫與各種應用系統裡。
醫院資料散落在 HIS、PACS、研究環境、資料庫與各種應用系統裡。Data Foundation 要處理 Data Owner、存取權限、資料品質、欄位與術語映射、API，以及資料允許使用的場景。
到了生成式 AI，還得沿著 Data Flow 再往下追：哪些資料可以離開原始系統？哪些資訊需要遮蔽或去識別化？資料進入 Embedding、Vector Store、Prompt、Model Endpoint、Output 與 Log 後，分別會留下什麼？
一份病歷自由文本可能同時包含姓名、病史與其他可識別資訊。即使使用者最後只看到一段 AI 摘要，資料在產生答案以前，仍可能經過 Retrieval、Prompt Context、Model Endpoint 與 Logging 等多個節點。每個節點都需要確認資料類型、權限、保存方式與使用目的。
De-identification、Masking 或 Tokenization 都可能成為控制手段，實際採用方式仍要依資料內容、用途、系統架構與適用規範判斷。
以 RAG 為例，系統即使可以檢索上萬份文件，如果 Knowledge Source 的權限與版本沒有同步管理，使用者仍可能取得超出授權範圍的內容，或收到來自舊版文件的答案。
Data Foundation 最後要回答的是：這筆資料從哪裡來、誰可以用、可以用來做什麼，以及使用過程能不能被追查。
✦延伸閱讀：Agentic Data Cloud 是什麼？Google 如何讓企業資料成為 AI Agent 的決策基礎
為什麼醫療 AI 需要共同治理底座？
想像醫院同時有五個專案：研究團隊需要短期 HPC、資訊部門正在做 RAG、另一組負責 Backup / DR，行政單位有自己的入口網站，臨床科部也正在測試新的 AI 應用。
如果五個專案各自建立 Cloud Account，IAM、Logging、KMS、Network 與 Billing 很快就會形成五套做法。
專案規模還小時，問題可能不明顯。等到帳號、供應商與資料來源愈來愈多，IT 團隊就得面對權限到期規則不一致、日誌散落、金鑰管理方式不同，以及成本難以歸屬等問題。
iKala 團隊因此提出 Cloud Foundation／Landing Zone 架構的重要性。底層先建立組織與帳號架構、政策基線、IaC、責任分工與例外流程；往上一層則提供 IAM、Network、Logging、KMS、Backup、Security 與 FinOps 等共用控制。Research、Data、Backup / DR 與 AI workload 可以在這套基礎上建立各自的應用。
如此一來，新專案啟動時，可以直接沿用既有的治理框架。IT 團隊也能用較一致的方式處理權限、日誌、備份與成本。
Landing Zone 可以理解成醫療雲端的共同起跑線：先把反覆出現的治理問題整理成基礎設施，後續 workload 再依自己的需求往上建立。
當然，建立 Landing Zone 不會直接取得「醫療合規」這張通行證。Google Cloud、AWS 等雲端服務商都有相關參考架構與工具，但實際控制仍需要依台灣醫療法規、資料類型、契約與個別 workload 的風險逐項確認。
✦延伸閱讀：Agentic Enterprise 是什麼？Google Cloud Next 2026 宣布開啟「代理式企業」新時代！
醫療上雲怎麼開始？先選一個 workload
醫院不必一開始就規劃全院系統遷移。選定一個具體 workload，往往更容易看清楚技術、治理與營運上的缺口。例如，可以從院內 RAG、研究運算、Backup / DR 或非臨床行政系統開始。iKala 團隊將這條路徑整理成四個階段：
Define → Foundation → Validate → Operate & Scale
Define 階段先確認要解決的問題、Owner，以及涉及哪些資料、流程、系統與臨床依賴。
進入 Foundation 後，團隊盤點 IAM、Network、Logging、KMS、Backup、Policy 與成本治理，找出目前缺少的共同控制，並建立目標架構。
到了 Validate，Pilot 的測試範圍擴大到品質、成本、復原、風險與退出條件。團隊可以在這個階段判斷 workload 是否具備正式上線條件，或現階段繼續留在地端更合適。
最後的 Operate & Scale 處理上線後的工作。權限需要定期檢視，Policy 可能產生 Drift，成本需要歸屬，新的資料來源、模型與供應商也會持續加入。這些工作需要明確的承接人與固定治理節奏。
這種做法讓「上雲」回到一個更具體的問題：下一個 workload 出現時，醫院能不能判斷它適合放在哪裡，知道上線前還缺哪些控制，並在部署之後持續維護？
當這套能力逐漸建立，下一個 Data 或 AI 專案進來時，團隊已經知道資料怎麼進、權限怎麼管、日誌留在哪裡、服務壞掉怎麼救，以及上線後由誰接手。
到這個階段，衡量醫療雲端成熟度的方法也會跟著改變。與其計算「多少系統已經上雲」，更有意義的問題是：下一個 workload 出現時，醫院能不能快速判斷部署位置，沿用既有控制，完成驗證，再交給明確的團隊持續營運？
這套能力建立起來之後，雲端才會真正成為醫院承接資料與 AI workload 的長期基礎。
FAQ：醫療上雲與 AI Production 常見問題
Q1：醫療產業為什麼需要上雲？
醫療上雲的需求逐漸延伸到 Data 與 AI workload。RAG、生成式 AI、研究運算與 Data Platform 對運算彈性、資料串接、模型更新與持續維運都有新的要求。雲端可以提供相應的技術與管理能力，但醫院仍需依 workload 特性決定部署方式，並建立 IAM、Logging、KMS、Backup 等共同控制。
Q2：醫院所有系統都適合搬上 Public Cloud （公有雲）嗎？
不一定。部署位置應依臨床關鍵性、資料敏感度、網路與延遲依賴、整合複雜度、法規與契約，以及營運成熟度綜合判斷。開發／測試、非臨床行政系統與 Backup / DR 副本可優先評估雲端；核心 HIS、床邊與給藥交易現階段則較適合地端或 Hybrid Cloud，並需考量 WAN fallback、設備介接與臨床降級機制。
Q3：Hybrid Cloud（混合雲）在醫療產業扮演什麼角色？
Hybrid Cloud 讓醫院依 workload 分配地端與雲端資源。例如，高度依賴院內網路、醫療設備與即時臨床流程的系統可以保留在地端；研究運算、備份、部分 Data 與 AI workload 則可依控制條件評估雲端。部署方式可以隨臨床風險、資料要求與系統依賴關係調整。
Q4：為什麼 AI PoC 成功後，還不能直接正式上線？
PoC 通常先確認功能與技術可行性。進入 Production 後，系統開始承接正式使用者與資料，Identity、Authorization、Logging、Evaluation、Human Review、版本變更、服務復原與 Monitoring 都會進入架構範圍。生成式 AI 上線後，Model、Prompt 與 Knowledge Source 還會持續更新，因此需要搭配版本、評測與變更管理機制。
Q5：Cloud Foundation、Data Foundation、AI Foundation 有什麼差別？
Cloud Foundation 建立 IAM、Network、Logging、KMS、Backup、Security 與 FinOps 等共通控制；Data Foundation 管理 Data Owner、資料品質、權限、API 與使用限制；AI Foundation 則涵蓋 Model、RAG、Prompt、Evaluation、Human Review、版本與 Monitoring。三者共同支撐上層的 Healthcare Application，讓不同專案可以沿用既有能力。
Q6：醫院要開始上雲，一定要先做大型 Cloud Migration 嗎？
可以先選一個具體 workload 開始，例如開發／測試、研究運算、Backup / DR 或符合條件的 AI use case。iKala 團隊提出 Define → Foundation → Validate → Operate & Scale 四階段方法，先確認 workload 與責任人，再建立必要控制、進行正式條件下的驗證，最後進入持續營運與擴展。
Q7：醫療機構如何判斷自己的 AI PoC 已具備 Production 條件？
可以從幾個問題檢查：使用者身分與資料權限是否明確？Model、Prompt 與 Knowledge Source 變更後是否有重新評測機制？系統是否保留必要日誌？高風險情境是否有人工作業與覆核機制？服務中斷時是否有替代流程？上線後又由誰負責權限、備份、成本、變更與異常處理？這些條件若仍沒有明確答案，代表專案還有 Production Readiness 的工作需要完成。
iKala，企業轉型的 AI 顧問！
身為 Google Cloud Premier Partner，iKala 不僅是您導入工具的推手，更是企業在雲端數位轉型旅程中的技術後盾。iKala 透過深度整合 Google Workspace 與 Google Cloud Platform 全球基礎設施，協助企業建構高可用性且具備高度彈性的現代化辦公環境。從基礎的混合雲架構設計、Identity & Security (IAM) 身分資安控管，到進階的 BigQuery 建置，我們專精於打破資料孤島，讓企業能利用 Gemini 模型實現自動化工作流與客製化 AI 模型開發。
iKala 提供從初期架構盤點、中期的 PoC 技術驗證，到後期在地化技術支援與成本優化建議的「一站式陪跑服務」，致力於降低導入門檻並確保轉型路徑與商業目標一致。選擇 iKala，您獲得的不只是領先的 AI 解決方案，更是加速創新、提升全球營運效率的長期策略盟友。
如果您正在尋找能加速創新與提升營運效率的 AI 解決方案，歡迎 聯繫 iKala，獲得量身打造的技術建議與實作協助。
