AI 專案為何做完 PoC 卻無法上線？企業 AI 落地的技術選型、治理與驗收指南

導讀｜ 會回答問題的 Demo，與能夠接管日常業務的生產系統，是兩種不同的交付物。企業 AI 落地的關鍵，在於找對架構、控制資料與動作權限、建立測試集和回復機制。本文提出從 PoC 到 Production 的 5 道驗收閘門，說明何時用一般規則、單次 LLM、RAG、固定流程，何時才需要 AI Agent，並附上可交給 IT、資安與業務主管共同使用的驗收表。

本文定位： 這是一份跨系統導入的技術治理與交付決策指南，不重複單獨教 Prompt 調整、RAG 檢索測試或報價自動化核准。文中標示的命中率、可用率與測試件數是供企業調整的示範門檻，不是 OWASP、NIST 或任何供應商保證標準；高敏感場景仍須進行專屬法遵與安全審查。

為什麼「測試能動」經常無法代表「可以交接」？

PoC 的典型成功畫面：工程師在受控範例下，輸入三個問題，系統生成通順內容。正式環境卻有更多變數：來源文件更新、不同職員存取權不同、網路斷線、API 超時、帳單暴增、模型輸出格式改變、工作流程重送、客戶要求刪除資料。真正的上線驗收，應測試這些「不在展示腳本內」的狀況。

企業最容易忽略的不是模型的平均表現，而是不正常情況下的可預測程度。一套系統能回答 95% 的例題，仍可能因剩下 5% 的高風險錯誤而不得對外自動執行。因此評測要依「業務損害程度」分級；所有平均分數都不能覆蓋必要的零容忍事件。

第 1 道閘門：用最簡單的架構達成任務

Anthropic 在其工程文章《Building effective agents》中，明確區分預先編排的 workflows 與由模型動態決定步驟及工具的 agents，並建議優先使用滿足任務需求的簡單解法。文章 2024 年發表，官網也提醒其中部分工具生態已更新；本文只援用架構原則，不當作 2026 年產品功能清單。S05｜Anthropic 原文。

決策規則： 若 80% 以上的正常任務都能以預先定義的分支處理（此處 80% 僅作示意，不是通用門檻），先採固定流程；僅當變化多、無法充分列舉，且具有可監督的狀態與成本限制時，才評估 Agent。導入多個 Agent 不是成熟度指標。附件 architecture_decision_table.csv 可逐案填寫。

第 2 道閘門：資料治理必須落在系統權限，不只寫在 Prompt

以內部文件助理為例，流程應為：使用者身分驗證 → 以身分映射取得可讀文件 → 檢索候選段落 → 依存取權與文件版本過濾 → 形成答案及引用 → 保留核對或升級入口。將「不要回答機密資料」放在系統提示文字，不能代替身分驗證與權限過濾。

在選 RAG 或訓練客製模型之前，先回答：文件從何處來？由誰維護？更新多久同步？哪些文件不可納入索引？刪除原始文件後，索引與快取是否同步移除？日誌含不含個資？資料將在什麼地區處理與保存？模型供應商是否將輸入用於訓練，合約實際條款怎麼寫？這些都應以供應商文件與內部政策確認，不能用「企業版通常安全」一語帶過。

OWASP 2025 年 LLM Top 10 將 Prompt Injection、敏感資訊洩漏、Excessive Agency、向量與嵌入弱點等列為需要處理的風險類別。S06｜OWASP 2025。安全控制應部署在資料、工具、身分與輸出介面，而非單一提示詞。

可落地的五層保護如下：

1. 身分層： 每個使用者及服務帳號有唯一身分，不共用管理員金鑰。
2. 資料層： 資料分類、文件權限、檢索前後過濾、資料保留／刪除政策。
3. 模型層： 結構化輸出驗證、來源要求、必要時拒答、版本固定。
4. 工具層： 明確可呼叫的 API 名單、最小權限、金額與頻率限制，寫入與寄送需批准。
5. 營運層： 風險日誌、異常告警、成本上限、故障回復、定期抽驗。

Cloud Security Alliance 於 2026 年公開的 AI Security Maturity Model 特別把 AI 治理、非人類身分與代理工具的 IAM、監測、模型／應用／資料安全等列為不同治理領域。S09｜CSA 2026。企業不一定要一次實作所有控制，但必須能指明「哪一項風險由哪一道控制降低，誰定期查核」。

第 3 道閘門：建立黃金樣本與失敗測試，而非只做成功 Demo

評測須區分四種層次：系統可用性、檢索正確性、答案品質、動作安全性。對知識助理應至少涵蓋：正常有答案、資料不存在、同名條款衝突、過期文件、不同權限、繁簡混用、數字格式、惡意提示、文件更新、服務超時。對自動化流程加上：重複請求、錯誤補償、授權撤銷、人工拒絕與回復。

建議初版由業務專家準備 60 個普通案例、20 個邊界案例、20 個高風險及越權案例（100 題僅是示範題庫規模），每一題包含：使用者角色、輸入、合法可讀資料、預期答案／拒答、允許工具、禁止工具、人工評分、實際結果、失敗原因與修正版本。

只報「整體準確率 90%」不夠。要分別算：

• 檢索召回率： 應被找到的相關證據段落，有多少在檢索候選中出現？分母是已人工標示的相關證據段落數。
• 答案支持率： 回答中的可驗證主張，有多少能由引用文件支持？分母是抽樣的可驗證主張數。
• 拒答正確率： 對沒有足夠資料、越權或禁止輸出的題目，系統有多少按要求拒答？分母是該類測試題數。
• 結構符合率： 必要欄位與格式完全合規的次數／有效測試次數；另列「輸出可解析但含錯誤值」比例。
• 動作違規數： 未核准寫入、寄送、付款或公開發布的事件數。零容忍類別不得由高平均分抵銷。

真正的品質比較要在相同測試集與版本下進行。任何更換模型、系統提示、資料索引、工具定義，均需保留版本及執行回歸測試。不要讓工程師在看過測試答案後只優化原題，造成測試集洩漏。測試數據與回報可用附件 go_live_quality_gates.csv 和 adversarial_test_cases.csv。

第 4 道閘門：把 Agent 的「能力」拆成可核准的動作

一個能讀 CRM 的 Agent，與能修改 CRM 的 Agent，風險不同；再加上能對外寄信或發動付款，風險會明顯提高。最小授權設計先把動作分為：讀取、建立草稿、更新內部資料、對外送件、不可逆交易。高影響動作要求人員批准，而且批准要綁定已確認的內容版本、資料對象、工具參數、操作者與有效期限。按過「同意」後如果內容變了，原核准不得沿用。

OWASP 的 Excessive Agency 風險提醒，當 LLM 有過多操作能力或權限時，非預期或受操縱的輸出可能導致有害動作。[S06]。因此請用程式層權限限制 API，而不是只要求模型「小心」。

此外，重試必須有冪等設計。若對外通知發送超時，不可假定一定失敗而直接重送；必須先用交易 ID、狀態台帳或對帳結果判斷。這個單點技術細節可接續閱讀天地人既有的 重試與冪等鍵驗收文章。

第 5 道閘門：正式上線時需要 9 份證據

英國 NCSC 的安全 AI 系統開發指引把工作分成安全設計、開發、部署、營運維護四個生命週期領域。S07｜NCSC 官方指引。它可作為跨階段安全分工的參考，但不替代企業適用的產業規範。

建議驗收會由業務、技術、資安共同簽核。允許下列四種狀態：PASS、PASS_WITH_RESTRICTIONS、FAIL、NOT_TESTED。未測試不可當通過；對零容忍事件，即使其他分數很高，也只能判定為 FAIL。

可操作案例：內部業務知識助理怎麼從 PoC 進入正式營運？

情境假設： 某 80 人公司，15 位業務需要查詢 500 份版本不一的產品規格文件。第一週先統計 30 個真實問答的查找時間與正確性；第二週把文件分為公開、內部及業務專屬，建立索引版本與擁有人；第三至四週建立最小 RAG，僅開放已批准的文件；第五週以跨角色題庫測試越權和過期條款；第六週採人工檢核的 shadow 模式；第七週才討論是否開放團隊使用。

試點成功條件不能只寫「會答問題」；應指定：每次回答顯示可核對的來源與版本、沒有授權的文件即使使用者直接提問也不可返回、資料缺失時須拒答或轉人工、文件撤銷後索引在規定時間內更新，以及人員可以回報錯答並追溯版本。

當系統只是檢索與回答，通常無需 Agent。一旦增加「自動建立報價單」功能，就須另開權限與核准驗收，不能沿用知識助理已通過的評測結果。

什麼情況應暫停或退出？

如果試點沒有資料所有人、模型持續產生不可控的高風險錯誤、資料權限無法隔離、成本無法限制、單一供應商故障會停止關鍵業務，或人員不願意接管錯誤處理，就應停在人工輔助層級。這不是「AI 失敗」；而是正確地避免把實驗成本擴散為營運風險。

結論： PoC 的目標是驗證可行性；Production 的目標是穩定、權限、責任、可回復與可量測。真正的 AI 落地不在於系統自主性多高，而在於業務主管願不願意簽收、資安是否能稽核、維運團隊是否接得住下一次例外。

實務工具與延伸閱讀

• 附件：architecture_decision_table.csv、go_live_quality_gates.csv、adversarial_test_cases.csv；內容為自建框架與合成測試情境。
• 企業 AI 導入 90 天完整計畫。
• RAG 有引用仍答錯？用 12 道測試題定位問題。

企業落地需求洽詢

準備向企業 AI 培訓或技術服務商洽詢前，請帶著「系統清單、使用者角色、資料敏感程度、使用者數、API 寫入權限、測試情境、預算上限、期望上線時間」。可先閱讀 天地人企業服務資訊，了解企業培訓與服務範圍。

原始英文資料與核對範圍

• [S05] Anthropic（2024-12-19），Building effective agents。英文原文摘句：“When building applications with LLMs, we recommend finding the simplest solution possible”。來源。註：目前原文提醒自 2024 年發布後工具生態已有變動，提醒本身未標示獨立更新日期。
• [S06] OWASP（2025 版），Top 10 for LLM and GenAI。英文原文摘句：“Excessive Agency is the vulnerability that enables damaging actions to be performed”。原始風險條目。風險條目名稱與類別由 OWASP 列出，本文的工程控制是延伸操作建議。
• [S07] UK NCSC（2023-11-27），Guidelines for secure AI system development。英文原文摘句：“secure design, secure development, secure deployment, and secure operation and maintenance”。來源。
• [S09] Cloud Security Alliance（2026-05-19），AI Security Maturity Model。英文原文摘句：“policies, decision rights, approval authorities”。來源。

編輯揭露：本文由 TARAISG 使用 AI 協助整理、寫作、來源核對及繪製原創圖表，使用假設案例解說，不主張有第三方實測成效。本文未經具名人類編輯或資安領域專家獨立審閱；實際高風險部署仍須另行取得企業內部法務與資安核准。企業服務連結僅供資訊參考，本次未驗證表單收件或 GA4 轉換追蹤。最後資料查核：2026 年 10 月 20 日。