FDE 與內部工程團隊：先找出 AI 專案卡點，再分配人力與權責

AI 專案停在測試環境時，先列出還不能發布的理由。模型能跑，是一項進度；品質、權限、整合、失敗處理及維運準備仍可能有缺口。不要由「程式已完成」直接推論只剩採用問題。

FDE 與內部工程團隊都可能承擔建置、評估和營運工作。差異要看實際能力、已分配時間及能取得的決策，而不是預設內部只維護、外部一定能推動改變。下面用三個問題把卡點拆開。

目前缺的是哪項工作與證據？

先確認主要工作和例外是否測過，資料與系統介面是否可用，權限是否符合約定。記錄未解決的錯誤、等待的依賴與缺少的接受證據。把「還不能上線」寫成可由指定人員完成或決定的項目。

GAO 的 AI 責任框架涵蓋治理、資料、效能與監測，可協助辨認漏掉的工作。它不提供模型與採用工作的固定比例，也不表示某一種團隊天生適合某個階段。

假設一套品質文件查詢工具已能回答開發樣本，但尚未測過過期文件、跨部門權限與找不到來源的情況。這裡仍有技術和評估工作，不能先當成使用者不願改習慣。把這些項目列為試行前的條件，指定完成者與接受人員。

把所需技能和已分配的時間分開記錄。內部團隊可能有相關能力卻沒有可用容量；外部團隊也可能受其他交付或人員安排限制。提案上的人數不能代替實際參與者、工作時間和支援安排。

先處理阻礙下一步的項目，不必一次買完整的合作模式。若需要的只是界線清楚的整合或測試工作，就以那項產出和接受證據比較提案。

工程師能提出方案，不代表被授權改動業務流程、開放敏感資料或接受風險。指定決策人、需要的證據與回覆方式。外部團隊到場，也不會自動取得這些權限；內部團隊則可能已具有必要的組織支持。

若資料不能開放，評估核准樣本、受控環境、遠端協作或更小範圍。若仍不足以驗證工作，記錄依賴並調整下一階段，不把所有原始資料存取視為 FDE 的必然前提。

Thoughtworks 的企業 AI 服務公開描述多種工程與轉型工作，說明外部能力可以跨階段；是否包含本案需要的技能、時間或責任，仍要在提案確認。

內部承擔，需要有能力、容量和決策支持。外部承擔，需要核准存取、可接受的範圍及接收角色。共同承擔，則要把兩邊的交付、覆核和依賴接起來，避免同一件事都在等對方。

延續查詢工具的假設情境，內部可負責核准來源與權限決策，外部承接指定的整合與測試，雙方共同查看試行結果。這只是可評估的安排，不推論它一定較快或較便宜。合適分工取決於本案的人員、證據和成本。

交接前，安排接收者實際完成部署、設定、測試或事件處理等必要工作。文件、程式碼與授權依契約確認；外部離場不等於內部已能獨立維運。採用、品質、權限和營運接受各自查看，不能只用每天有人使用判定全部完成。

要比較人力選項與交接能力，接著閱讀現有FDE 與內部工程團隊比較。要整理第一階段與營運責任，參考交付方法。先帶著卡點與待決事項，再討論需要補哪一種工作。