企業 AI 建置或採購：一套可重複使用的評估框架

企業導入 AI 時，「自己建」與「直接買」常被當成二選一；實際上，真正需要判斷的是：哪些能力必須由團隊掌握，哪些可以交給供應商，以及出問題時誰能發現、處置與負責。模型 API、SaaS 產品、內部工作流程、資料介接與人工覆核可以分別採取不同做法，因此許多專案最後會落在混合模式，而不是單純的自建或採購。

這篇文章提供一套可重複使用的評估框架。它不承諾用一張分數表就得出唯一答案；分數的用途是讓跨部門假設、證據與取捨能被攤開討論。NIST 的 AI 風險管理框架也把風險工作整理為 Govern、Map、Measure、Manage 四個互相反覆的功能，而非一份照抄即可完成的清單。NIST AI RMF Core

先釐清：自建、採購與混合模式各在解決什麼

• 採購：購買既有 SaaS、模型 API 或垂直解決方案。適合需求明確、希望快速驗證價值，且產品能力與資料條件能對上的情境。
• 自建：由團隊掌握應用層、資料管線、評估與營運，必要時也管理模型或部署環境。適合流程高度差異化、整合複雜，或控制要求無法只靠供應商產品滿足的情境。
• 混合：採購基礎模型或平台，但由內部建立檢索、權限、工具串接、監控與人工覆核。這通常更貼近企業實際分工。

因此，問題不應只是「要不要自己訓練模型」。更有用的問法是：哪些資料會進入系統？回答是否會觸發下一個動作？能否替換供應商？誰負責監看品質與異常？

先設不可退讓的門檻，再討論加權分數

有些條件不適合用低分被其他優點抵銷。例如資料分類或保存位置不符合組織政策、系統無法提供必要的身分與權限控制、關鍵決策沒有人工覆核與申訴處理方式，或合約沒有足以因應停用與資料移轉的安排。這些應先列為「通過／不通過」的門檻。

通過門檻後，才為不同面向設定重要性與可接受證據。這能避免團隊因為展示效果好、初期價格低或產品功能多，就忽略日後營運的限制。NIST 的生成式 AI 風險管理文件亦強調，風險需放在整個生命週期與具體使用脈絡中處理。NIST AI RMF: Generative AI Profile

九個可比較的評估面向

1. 任務與成功條件

先寫出使用者、輸入、預期輸出、不可接受的錯誤，以及改善後要觀察的營運指標。若連任務邊界都未定義，任何供應商展示或內部原型都難以公平比較。

2. 資料、權限與整合

盤點資料來源、敏感等級、保留期限、存取角色與既有系統介接。採購產品若無法符合資料流向或權限模型，後續客製通常會抵銷原本的導入速度；自建則要誠實估計資料工程與維運負擔。

3. 差異化與控制權

問一個簡單問題：這個工作流程是否構成企業獨特能力？若答案是肯定的，內部至少應保留流程編排、評估資料、規則與關鍵介面等控制點。若只是通用功能，採購可能讓團隊把心力放在更有差異化的地方。

4. 上線速度與可逆性

除了第一次上線需要多久，也要比較變更提示、模型、供應商、資料來源或流程時的成本。小範圍試點、可回退的版本與明確退出條件，通常比一次性大規模導入更容易取得可靠證據。

5. 資安、隱私與供應鏈

確認身分驗證、最小權限、資料傳輸與保存、稽核紀錄、漏洞處理、分包商與模型／元件來源。若選擇自建，安全開發流程也必須列入成本；NIST 的 SSDF 可作為與開發團隊或供應商討論安全開發實務的共同語言。NIST SP 800-218 Secure Software Development Framework

6. 品質評估與人工覆核

不要只看一次 demo。應建立與實際任務相近的測試案例，包含正常案例、邊界案例與已知失敗案例，並定義誰覆核高影響輸出、如何回報錯誤、何時暫停或降級服務。模型輸出符合格式，並不代表內容正確或適合直接執行。

7. 營運責任與支援能力

系統上線後需要有人處理帳號、權限、成本、模型或產品版本變動、提示與工具更新、事故通報及使用者回饋。比較方案時，應把供應商 SLA 與內部待命能力都寫進責任分工，而不是假設採購後就不需要營運。

8. 全生命週期成本與退出機制

成本不只包括授權或 API 單價，也包括整合、測試、資料整理、監控、教育訓練、治理與替換成本。應事先問清楚：如何匯出資料與設定？終止後如何處理資料？替換模型或平台時哪些元件需要重做？

9. 治理、法務與變更管理

決定系統的風險等級、核准權責、可接受用途、紀錄保存、定期複查與停用流程。這不是只屬於法務或資安的工作；業務、資料、工程、資安、法務與使用者代表都需要對各自的假設負責。

把評估框架做成可使用的決策紀錄

每個候選方案可用同一份紀錄表：在每個面向填入「決策問題、現有證據、風險、負責人、重要性與暫定評估」。若要使用 1 至 5 分或加權分數，必須同時保留評分依據與不確定性，避免數字看似精確卻無法追溯。

1. 先列出門檻條件與未解問題。
2. 選一個範圍受控、可量測的任務做試點。
3. 同時測試使用者流程、品質、安全控制與營運交接，而不只測模型回答。
4. 在預先約定的時間點檢視證據，決定擴大、調整、替換或停止。

何時較可能偏向哪一種模式？

較可能採購：需求接近通用能力、資料與整合條件可被產品支援、需要快速取得可用版本，且退出與治理條件清楚。

較可能自建：核心流程高度差異化、資料與權限模型特殊、必須掌握評估與變更節奏，並且組織有長期維運所需的人力與安全能力。

較可能採混合模式：希望利用成熟模型或平台縮短基礎建置時間，但仍要把企業資料、工作流程、權限、評估與人工審核保留在自己的控制範圍內。

這些只是討論起點，而不是替任何組織下結論。風險容忍度、產業規範、資料條件與既有能力不同，結果也會不同。

常見問題

可以只用總成本比較嗎？

不建議。總成本很重要，但若忽略資安、品質驗證、變更速度、供應商依賴與內部責任，低價方案可能在上線後產生更高的修正成本。

買了平台，就不需要內部 AI 團隊嗎？

仍需要明確的業務、資料、資安與營運責任。採購可降低部分開發工作，但不會自動替組織定義可用範圍、資料治理、測試標準或事件處理方式。

試點成功就能直接全面導入嗎？

試點只能證明它在當時的範圍與樣本中可行。擴大前仍應重新檢查資料量、使用者角色、成本、錯誤處理與監控是否能承受實際情境。

結語

企業 AI 建置或採購的關鍵，不是替「自建」或「採購」找一個勝負，而是把任務、控制權、風險、營運與退出安排說清楚。先設定不可退讓的門檻，再用一致的證據比較候選方案，才能讓決策從一次性的產品選型，變成可持續檢討的營運能力。

資料來源與延伸閱讀：

• NIST AI Risk Management Framework Core
• NIST AI RMF: Generative AI Profile
• NIST SP 800-218: Secure Software Development Framework