技術分享
MCP 資安警報：把 AI Agent 接上內部系統前必做的安全檢查
AI Agent 透過 MCP 直連企業內部系統已成標配，但 NSA 發布安全指引、Azure DevOps MCP 漏洞與惡意技能事件接連爆發，顯示整合速度已超過安全防護。本文以近期真實案例拆解兩大攻擊型態，並提供一份部署前可逐項核對的五面向安全檢查清單。
Gartner 預測，到 2025 年底至少有三成的生成式 AI 專案會在概念驗證（POC）之後被放棄，原因包含資料品質不佳、成本失控與商業價值不明；RAND 智庫 2024 年訪談 65 位資料科學家與工程師後給出更嚴峻的數字——超過八成的 AI 專案無法真正走到有意義的生產部署，失敗率是不含 AI 的 IT 專案的兩倍；MIT 在 2025 年的企業調查則發現，高達 95% 的生成式 AI 試點對損益毫無實質貢獻。把這些數字只當成「專案沒管好」是誤診。真正的問題更工程：POC 的程式碼本身就是一堆技術債，讓系統撐得住上線，是一項重構工程，不是一張避坑清單。
Demo 跑得動，不等於系統站得住
POC 的目標是「證明這件事做得到」，所以它被允許走捷徑：prompt 寫死在程式裡、只處理最順的那條路徑、綁定單一模型、餵一份精挑細選的乾淨資料。這些捷徑在 Demo 當下完全合理，因為它們換來的是「今天就能給老闆看」。問題是，生產環境優化的是完全不同的東西——可靠度、規模、成本與可維運性。RAND 的研究直指，多數失敗不在模型不夠強，而在對「部署基礎設施」的長期低估；一位受訪工程師的說法很傳神：「AI 有八成是資料工程的髒活。」當你把一個為「證明可行」而生的原型，直接丟進要求「穩定運行」的環境，那些捷徑就一次現形，成為必須償還的債。
為什麼 POC 天生是技術債：CACE 效應
Google 早在 2015 年的經典論文〈機器學習系統中的隱藏技術債〉就指出，AI 系統除了背負傳統程式的所有維護問題，還多出一整類專屬風險，其中最核心的是 CACE 原則——Changing Anything Changes Everything，「改動任一處，牽動所有處」。傳統軟體靠嚴謹的抽象邊界隔離變更；AI 系統卻把訊號、prompt、資料與參數深度糾纏在一起，動一個提示詞、換一份資料、調一個門檻，整體行為都可能不可預測地位移。這正是 POC 撐不住的根因：它從沒為「可被隔離地修改」而設計。此外還有隱藏的回饋迴圈、未申報的下游依賴、堆積的設定債——這些在 Demo 看不見，上線後卻是每一次改動的地雷。
盤點技術債：每個捷徑都對應一筆生產負債
重構的第一步，是誠實盤點 POC 留下的債。以下把最常見的幾項攤開對照：
| POC 的做法 | 生產的要求 | 不重寫的後果 |
|---|---|---|
| Prompt 與規則寫死在程式裡 | 可調整、可版本控管、可測試 | 每次微調都要改碼重部署，無法回溯 |
| 只處理正常路徑 | 邊界、異常、逾時都要有處理 | 真實輸入一多就崩，錯誤無聲擴散 |
| 直接呼叫單一模型 API | 可切換、可降級、可控成本 | 模型漲價或故障即全線停擺 |
| 憑感覺判斷輸出好壞 | 可量化的評測基準 | 改了東西不知道變好還變壞 |
| 資料來自一份乾淨樣本 | 面對骯髒、會漂移的真實資料 | 上線後表現持續衰退卻查不出原因 |
這些後果並非危言聳聽。2024 年 Moffatt 訴 Air Canada 一案中，航空公司的客服機器人對喪親票價政策給出了錯誤（幻覺）資訊，加拿大卑詩省民事法庭判定企業須為機器人的說法負責、判賠乘客——本案被廣泛視為企業須為 AI 聊天機器人錯誤資訊負法律責任的指標性判例。一個沒有輸出護欄、只驗過正常路徑的 POC，上線後付的可能不只是工程代價。
重構策略：用絞殺者模式分層抽換
盤點完債務，多數團隊的直覺是「乾脆整套重寫」，但這通常最危險——你會同時失去已驗證的商業邏輯，又拉長交付時間。更務實的是軟體架構大師 Martin Fowler 提出的「絞殺者無花果」（Strangler Fig）模式：在 POC 外圍包一層 façade 閘道，把對模型的呼叫收斂到單一入口，再讓新的生產級元件一塊一塊接手舊路徑的流量。它的三個好處正好對症——每一步都能交付價值、每一步都可回退、過程中業務從不停線。先把糾纏的三件事拆開（prompt 邏輯、業務流程、資料存取），已驗證的核心予以保留，脆弱的接縫逐段抽換，而不是停線幾個月賭一次大改版。
補齊工程底座：2026 的 LLMOps 標配
POC 通常缺一整層讓系統「可被信任地運行」的基礎設施。走過 2025，業界已把過去的「憑感覺驗收」（vibe check）逐步收斂成工程紀律，上線前至少要補齊：
- 評測基準（Eval）：用 DeepEval、Arize Phoenix、MLflow Evaluation 這類框架建立固定測試集與評分，讓每次改動都能被量化，而非憑手感——這在 CACE 效應下尤其關鍵。
- 可觀測性：記錄每一次呼叫的輸入、輸出、延遲與成本，出問題時能回溯是哪一步、哪個輸入出錯。
- 護欄（Guardrails）：以同步攔截層在輸入與輸出兩端執行政策，擋下 OWASP 點名的提示注入、敏感資料外洩與過度授權等風險。
- 降級、重試與成本控制：模型逾時要有備援、重試須具冪等性、用量設上限與快取，避免一次流量尖峰就燒掉整月預算。
該重寫還是該保留：一個簡單判準
重構最耗神的判斷，是每一塊到底該留還是該砍。一個好用的準則是同時看兩件事：這塊程式的「商業邏輯正確性」與「工程可維運性」。邏輯已驗證正確、只是工程粗糙的，優先保留邏輯、重寫外殼；邏輯本身沒想清楚的，別急著美化，退回去釐清需求再寫。既沒被驗證、又難以維運的實驗性程式，就是最該果斷丟棄的部分。把力氣花在償還真正阻礙上線的債，而不是把每一行 POC 都打磨成藝術品。
恩梯科技：陪你把 POC 重構成撐得住的生產系統
恩梯科技的 AI 系統顧問與客製開發服務，專注在把「Demo 跑得動」的原型，重構成「上線撐得住」的生產系統。我們協助企業盤點 POC 累積的技術債、以絞殺者模式規劃分層抽換的重構路徑，並補齊評測、可觀測性與降級護欄等工程底座，讓 AI 系統不止步於概念驗證的展示品，而是能長期穩定為業務創造價值的資產。
參考資料
- Gartner，《Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025》，2024。來源連結
- RAND Corporation（James Ryseff 等），《The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed》，2024。來源連結
- MIT NANDA，《The GenAI Divide: State of AI in Business 2025》，2025。來源連結
- D. Sculley 等（Google），《Hidden Technical Debt in Machine Learning Systems》，NeurIPS，2015。來源連結
- American Bar Association，《BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot》，2024。來源連結
- Martin Fowler，《Strangler Fig Application》，2024。來源連結
