中小企業 AI PoC 30 天執行框架：PoC owner 4 種人選對照、5 個轉正合約訊號、4 條退場紅線 讓試點不變沉沒成本

過去一年，我們接觸的中小企業客戶裡，每三家就有一家手上躺著一個「跑完了，但沒下文」的 AI PoC。預算大約落在 30 到 80 萬之間，廠商簡報拍胸脯，老闆當場簽字，三十天後資料工程師交出一份「準確率 87%」的測試報告，然後就沒有然後了。報告歸檔，會議解散，下一季再有人提 AI 時，老闆只說一句「等等再看」。

Gartner 在 2026 Q1 報告寫明，企業生成式 AI 試點到正式上線的轉換率只有 8%，比 2024 年的 13% 還倒退。McKinsey Global Survey 同期數據也顯示，受訪 1,491 家中型企業（員工 50–500 人）裡，61% 過去 12 個月跑過至少一個 AI PoC，但只有 9% 的 PoC 最終簽下正式合約。換句話說，PoC 階段真正的問題是「組織能不能承接」，而非「能不能技術跑通」，而 92% 中小企業在這道關卡前就被擋下來。

PoC 其實是「組織能否承接」的壓力測試，而非技術試點

中小企業老闆對 PoC 最常見的誤解：把 PoC 當成「廠商技術 demo 的延長版」。實際上 PoC 階段技術跑得通與否，多數時候不是門檻。Hugging Face 與 Anthropic 的開源模型加上現成的 RAG / Agent 套件，跑出一個「Demo 看起來 work」的雛形對任何一家正常廠商來說都是兩週內可以完成的事。

真正困難的、也是 92% 死掉的 PoC 共同特徵，是組織端沒有對應的承接準備：

• 沒有指定的業務端 owner，PoC 結果出來沒有人有立場拍板「要不要轉正」
• 沒有寫進 KPI，跑完了不知道算成功還是失敗，會議就沒有結論
• 沒有預算與排程承諾，從 PoC 跨到 production 需要重簽合約、重做預算編列、重排上線時程，三件事任一卡住就拖到下個會計年度
• 沒有資料治理對齊，PoC 用了臨時抽的測試資料，正式上線要動到客戶 PII、財務帳目、合約文件，IT 與法務介入後整個 scope 翻倍重來

我們自己經手過一個典型案例：客戶是製造業中型企業（員工 280 人），找上家廠商做了一個業務報價 AI 助理 PoC，跑完三週示範會議掌聲很大，老闆很滿意。但接下來四個月，這個 PoC 一直在「再評估、再評估」的狀態，最後客戶來找我們重做時才坦白：當初指定的 PoC owner 是資訊部副理，PoC 結果出來後沒有業務副總或營運長拍板，案子就懸在那裡。我們重啟時做的第一件事是請老闆指定一位營運副總當 PoC owner，而非技術，並把 PoC 寫進那位副總的季度 KPI，案子兩個月後就轉正了。

這就是 PoC 的本質：它測試的是組織決策鏈條，不是模型準確率。所以挑 owner 比挑廠商重要，KPI 設計比模型選型重要，退場機制比上線時程重要。

PoC owner 不能讓 IT 主管當：4 種人選的優缺對照

中小企業老闆指派 PoC owner 時，90% 的第一反應是「找資訊部或 MIS 主管」。這個直覺是錯的，而且是 PoC 死亡率最高的 root cause 之一。理由很單純：IT 主管的 KPI 是「系統穩定上線、不出包」，但 PoC 階段需要的是「業務洞察 + 組織政治推動」，兩件事的能力組合完全不同。

四種常見 PoC owner 人選的優缺實況：

選項 A：IT 主管 / 資訊部副理

• 優點：技術理解快、會問廠商對的問題、能看懂 Demo 背後的架構限制
• 致命缺點：沒有業務拍板權。PoC 結果出來後要說服營運副總、業務副總、財務長三方撥預算，IT 主管沒這個份量。而且 IT 主管的部門 KPI 跟 AI 上線無關，沒有強烈推動誘因
• 適合場景：純技術替換型 PoC（例如 OCR、文件分類），與業務流程關聯弱

選項 B：業務 / 營運副總

• 優點：拍板權充足、KPI 直接對齊（業績提升或成本下降）、會議桌上講話有人聽
• 缺點：技術理解淺、容易被廠商話術帶偏、無法判斷模型輸出的合理區間
• 配套：副總當 owner，IT 主管當 co-owner 做技術翻譯，這是中小企業最穩的組合
• 適合場景：80% 的中小企業 AI PoC，包括客服、業務、報價、合約審閱、知識庫

選項 C：老闆本人 / 創辦人

• 優點：拍板速度最快、跨部門協調阻力最小、預算瓶頸可以當場拆
• 缺點：老闆通常時間嚴重不足，PoC 階段需要的是每週 2–3 小時的細節投入，老闆撐不過第三週就會 delegate 出去，等於沒有 owner
• 適合場景：員工數 < 50 人的小型企業、或 PoC 結果直接影響商業模式的策略級案子

選項 D：外部顧問 / 廠商 PM

• 優點：技術掌握與 PoC SOP 經驗都有
• 致命缺點：沒有組織內部立場。PoC 結果出來要轉正，需要在公司內部協調預算、排程、權限申請、教育訓練，外部顧問做不到這些事
• 適合場景：完全沒有，外部顧問可以當 advisor、但不能當 owner

業界比較成功的 PoC 案例，幾乎都遵循選項 B 的「業務副總 owner + IT 主管 co-owner」模式。我們在跟客戶提案時，第一份簽收的文件是 owner 指定書，而非合約：明確寫出業務副總是 PoC owner、季度 KPI 把這個 PoC 結果寫進去、第 30 天必須提出「轉正 / 退場 / 延長」三選一決策。沒有簽這份文件，案子我們不接。

30 天 PoC KPI 設計：3 條業務指標 + 2 條工程指標 + 1 條財務指標

PoC 跑完之後最常見的會議僵局，是「老闆問做得好不好，沒有人能用數字回答」。原因其實是 PoC 開始前沒有寫 KPI，或者寫了但寫錯了，而非模型差。

中小企業 AI PoC 階段必須寫進合約的六條 KPI，分成三類：

業務指標（3 條，最重要）

1. 承接率 / 採用率：例如業務報價 PoC，PoC 期間業務團隊實際使用 AI 報價建議的次數 / 應使用的總機會次數。門檻建議 ≥ 40%低於這個數字代表業務根本沒在用，模型準不準都是假議題 2. 單筆任務耗時下降：例如客服回信 PoC，從「收信到回覆送出」的平均時長。門檻建議 ≥ 30% 下降，低於 20% 沒有商業意義 3. 任務正確率 / 滿意度：例如業務員回饋「這個 AI 建議我會直接送出 / 微調後送出 / 整段重寫」的三檔分布。前兩檔合計 ≥ 70% 才算可用

工程指標（2 條）

4. 回應時間 P95：使用者按下按鈕到拿到結果，95 百分位數的回應時間。門檻建議 ≤ 5 秒（互動式場景）或 ≤ 30 秒（批次場景） 5. 可用性 / 錯誤率：PoC 期間 API 錯誤率、模型 fallback 觸發率、人工介入次數。門檻建議 ≤ 2%

財務指標（1 條）

6. 單筆任務邊際成本：每次任務的 API token 費用 + 後端運算 + 資料處理攤提。門檻建議 ≤ 業務帶來節省成本的 30%一筆任務 AI 成本如果吃掉 30% 以上的人力節省，正式上線後規模化會無利可圖

這六條 KPI 必須寫進 PoC 合約附件，廠商簡報時要明確同意門檻數字，第 30 天 review 會議直接拿這六條對。任一條業務指標低於門檻 → 不轉正、退場。任一條工程指標低於門檻 → 廠商免費延長一輪，最多延長兩輪不到位就退場。

我們手上正在跑的客製化系統開發案件，內部 PoC 階段都套這套 KPI 框架，差異只在數字依場景調。比如電商客服 AI 助理 PoC 的承接率門檻會拉到 60%（客服場景行為更可預測），但業務報價 PoC 我們會放寬到 40%（業務員話術差異大，初期承接低正常）。

5 個「該轉正式合約」訊號 vs 5 個「該退場」訊號

PoC 跑到第 30 天，會議桌上的決策三選一：轉正、退場、延長。70% 的中小企業老闆在這一步陷入「再看看」的拖延陷阱，是因為沒有事先約定訊號清單，而非訊號不清楚。

5 個明確「該轉正」訊號

1. 六條 KPI 全達標，且至少 2 條業務指標超出門檻 20% 以上代表使用者真的在用、效果真的有 2. 業務端 owner 主動要求擴大 scope副總或部門主管在 review 會議上開始問「能不能再加 X 場景」，代表組織承接動能在 3. PoC 期間累積 ≥ 20 份使用者 feedback正面 / 負面比例 ≥ 7:3，代表使用者真的在用、且願意給意見 4. IT 主管 co-owner 主動寫了 production 上線評估文件代表技術端準備好接案 5. 預算與排程已經有「下一年度編列承諾」財務長口頭承諾不算數，要寫進下一年度 IT 預算草案才算

5 個明確「該退場」訊號

1. 承接率 < 30%業務根本沒在用，模型再準也無意義 2. PoC 期間業務端 owner 換過 ≥ 2 次組織內部沒人想扛這個案子，強行轉正只是把問題推到 production 3. 廠商交付每週 review 報告有 ≥ 30% 內容是「待釐清 / 持續評估」，代表廠商自己也沒抓到問題 4. 使用者 feedback 出現「我寧可自己做」≥ 5 次產品設計與使用者實際工作流不匹配，不是模型問題、是 PM 問題 5. 30 天內已經改過 3 次以上場景 scope代表一開始 PoC 目標就沒對齊，繼續跑只是燒錢

退場不是失敗。30 天用 60 萬燒掉一個錯的方向，比簽下 300 萬合約然後一年後才發現方向錯划算得多。中小企業老闆最常犯的錯，是 PoC 跑得不漂亮時還想「再延一個月看看」，這個 instinct 通常是錯的，PoC 訊號清楚的話，第 30 天就要拍板。

PoC → Production 合約轉換時的 4 條紅線條款

PoC 訊號正向、決定轉正後，第一件事不是慶祝、是重新談合約。PoC 階段合約通常是廠商自己的標準模板，條款對甲方相當不友善，這在 PoC 階段不要緊（金額小），但轉到 production 後相同條款會吃掉甲方所有議價空間。

四條中小企業老闆必須在 production 合約裡守住的紅線：

紅線 1：資料所有權與訓練排除條款

PoC 期間用的資料通常是抽樣或測試資料，正式上線後輸入的是真實業務資料，客戶 PII、報價內容、合約文件、財務帳目。合約必須明確寫：

• 所有甲方輸入資料的所有權永久歸屬甲方
• 廠商不得將甲方資料用於模型訓練、廠商自有產品優化、或對外揭露
• 違反此條款 → 甲方可立即終止合約 + 索賠 ≥ 兩年合約金額

OpenAI 與 Anthropic 的企業 API 條款都明確排除訓練用途，但台灣本地廠商的合約模板裡 70% 沒寫。這條不簽，未來廠商商業模式調整時甲方資料就是任他擺布。

紅線 2：模型升級與切換權

正式上線後，廠商升級底層模型（例如從 GPT-4 升到 GPT-5、或從 Claude Sonnet 切到 Claude Opus）必須給甲方至少 30 天書面通知 + 平行運行期 ≥ 14 天。理由是：模型升級會改變輸出特性，甲方業務流程需要時間驗證新模型是否仍符合 KPI 門檻。

延伸條款：甲方有權在 production 階段要求切換底層模型供應商（例如從 OpenAI 切到 Anthropic 或自架 Llama），廠商需在 60 天內完成切換 + 不得加收 base subscription 以外費用。這條是 vendor lock-in 的解藥，不簽就等著被綁。

紅線 3：KPI 對賭與罰則啟動條件

PoC 跑出的六條 KPI 寫進 production 合約變成 SLA，但 production 階段的數字會比 PoC 更嚴格。建議：

• 業務指標門檻：PoC 數字 ×1.1（提升 10%）
• 工程指標門檻：P95 回應時間從 5 秒收緊到 3 秒、可用性 99.5% 起跳
• 連續 2 個月任一 SLA 未達 → 廠商免收當月維護費 + 30 天改善期 + 改善期內未達標可單方面終止合約

這條最容易被廠商拖：他們會在第一輪談判時拒絕、第二輪改成「綜合評估」、第三輪改成「兩造協議調整」，目的是讓 SLA 失去執行力。中小企業老闆要堅持「具體門檻數字 + 自動觸發罰則」，模糊條款一律不簽。

紅線 4：退出與資料攜出條款

合約期滿或提前終止時：

• 廠商需在 30 天內提供甲方所有資料的完整匯出（含原始輸入、模型輸出、log、metadata）
• 匯出格式必須是業界標準（JSON / CSV / Parquet），不能用廠商專有格式
• 廠商需提供至少 60 天的並行運行期，讓新廠商順暢接手
• 違反此條款 → 廠商保證金沒收 + 索賠

這四條紅線寫進合約，中小企業老闆才算真正控住 PoC 轉正之後的 production 風險。少任何一條，未來都會在某個時點吃悶虧。

我們服務過哪些 PoC → Production 案件

恆遠的客製化開發業務裡，AI 系統整合占 2026 上半年案件量的 38%。經手過的 PoC → Production 轉換案件，常見的三個技術組合是：

• RAG 知識庫 + 業務工作流整合：客戶 PoC 用 OpenAI / Anthropic API + 簡單向量庫做出 Demo，轉正時整合進客戶 CRM、報價系統、合約管理，並把資料治理收回自有 Postgres + 自架向量庫
• 業務 / 客服對話 AI：PoC 階段用 GPT-4 跑通對話品質，轉正時整合進客戶 LINE 官方帳號 / Web Chat / 客服中心後台，加上人工接管 fallback、客戶資料隔離、talk-handover 機制
• 文件 / 報價自動化：PoC 階段做出單一文件類型的處理範本，轉正時擴大成完整文件流（合約、報價、發票、簽核），整合到客戶 ERP / 簽核系統

可以看出來這些其實都是「把廠商不能客製的部分自己拉回來做」，而非「賣模型」或「賣 SaaS 訂閱」。所以如果你的 PoC 結論是「我要一套自家擁有、能整合既有系統、未來能換底層模型不被綁」的 AI 系統，那就是我們服務範圍。如果結論是「我直接買 Gong / Salesforce Einstein 就好」，那也是合理結論，本文只是幫你判斷該不該買的決策框架。

📂 客製化系統開發案例集：客製化開發作品集

我們怎麼看 PoC owner 與轉正決策的關鍵

恆遠團隊內部跑了 14 個月的 AI 案件，包含我們自己 dog-fooding 的內部知識庫、業務報價、文件處理三個 PoC。最大的教訓是：PoC 死亡的真正原因是決策慣性，而非技術。中小企業老闆習慣把 AI 採購當成 IT 採購，但 AI 在 PoC 階段最像「組織重組」，需要業務副總層級的人扛 KPI、需要跨部門推動、需要老闆親自過問。把它當 IT 採購交給 MIS 處理，案子就會死在「待評估」的迴圈裡。

我們現在接客戶 PoC 案的第一個動作是請老闆指定業務端 owner 並簽 owner 指定書，而非技術簡報。沒有簽不接案，是替客戶省錢，而非傲嬌。簽了之後 30 天 PoC 完整跑下來，案子轉正率超過 65%，比業界 9% 平均高七倍。差別不在我們的模型多厲害，而是這份 owner 指定書 + 六條 KPI 對賭把 PoC 從「技術 demo 延長賽」拉回「組織決策訓練場」。

老闆如果讀完本文還是覺得「等等再看」，建議現在就翻日曆找出下週可以跟業務副總、營運副總、財務長三方對齊一小時的時間槽，這個會議比簽下任何 PoC 合約都優先。

常見問題 FAQ

Q1：PoC 預算抓多少合理？ 中小企業 30 天 PoC 合理區間是 30–80 萬台幣，依複雜度切：純文件處理 PoC 30–50 萬、業務 / 客服整合 50–80 萬、跨系統整合 80 萬起跳。低於 30 萬通常是「廠商在賠錢搶單想綁住你」，注意後續 production 報價會翻 5–10 倍補回。

Q2：PoC 期間廠商一直要 scope 加碼怎麼辦？ 60% 中小企業 PoC 死因之一。應對：合約裡明寫「PoC scope 變更需雙方書面同意 + 不影響原訂 30 天交付期 + 不影響原訂 KPI 門檻」。廠商提加碼時，老闆只回一句「不影響原 KPI 的話 OK」，多數廠商就會收手。

Q3：六條 KPI 我看不懂，怎麼跟廠商談？ 請廠商在 PoC 簡報階段就提出「他們建議的 KPI 數字」，老闆只負責挑戰兩件事：(1)業務指標門檻是否與商業 ROI 對得上、(2)財務指標的單筆成本攤提是否合理。技術細節讓 IT co-owner 接手談。

Q4：PoC 跑得不漂亮，廠商提出免費延長一個月，該接嗎？ 看訊號類型。如果是工程指標未達標（P95 太慢、錯誤率高），廠商有改善空間，免費延長合理可接。如果是業務指標未達標（承接率低、滿意度差），延長解決不了問題，這代表場景或產品設計錯了，延長只是拖時間，建議直接退場重新評估。

Q5：我們 IT 部門非常想接 PoC owner，怎麼拒絕？ 不要拒絕，請 IT 主管當 co-owner。明確區分：業務副總 owner 負責場景、KPI、轉正決策；IT 主管 co-owner 負責技術評估、架構盤點、production 上線評估。兩個人共同對老闆每月 review 簡報。IT 主管的成就感與專業判斷有發揮空間，但拍板權留給業務端。

Q6：合約裡如何寫資料訓練排除條款？ 建議寫法：「乙方確認所有甲方輸入之資料（含原始輸入、加工結果、log、metadata）僅用於本合約約定之服務交付目的；乙方不得將前述資料用於：(1)乙方自有或第三方模型之訓練、微調、評估；(2)乙方自有或關係企業產品之優化、benchmark；(3)對外揭露、轉售、授權。違反此條款者，甲方得立即終止合約且不受違約罰則限制，並得請求兩年合約金額之懲罰性違約金。」

Q7：PoC 轉正後第一個月就出包怎麼辦？ 第一個月 production 出包是高機率事件，所以合約要寫「上線後 30 天保固期 / 觀察期」：保固期內所有 P0 / P1 bug 廠商免費修復、回應時間 ≤ 4 小時、不啟動 SLA 罰則。但保固期滿後 SLA 全部生效，任何 P0 都觸發罰則條款。