企業 AI 導入需求書怎麼寫？總經理從營運問題到顧問採購的 12 欄決策表

總經理收到一份「導入 AI」提案，裡面列了聊天工具、知識庫與自動化平台，卻看不到哪一項工作會改變。業務希望快一點回覆，資訊部擔心資料外流，財務只收到一個建置總價。每個人都在談同一個專案，實際上想像的是不同的終點。

需求書的用途，是讓這些差異在付費之前被看見。它不必一開始就寫成工程規格，也不需要主管先懂模型架構；但必須讓另一位同事讀完後，能說明工作從哪裡開始、在哪裡結束、誰負責判斷，以及失敗時怎麼辦。

一份可用的 AI 需求書，要讓供應商知道必須證明什麼，也讓企業知道哪些責任仍握在自己手上。 下列 12 欄是本文整理的管理工具，並非政府制式採購文件、法律意見或任何認證要求。正式採購仍應配合企業既有程序及必要的資訊、資安與法務審查。

一、先選一件工作，別急著寫功能清單

「建置 AI 客服」是一個方案名稱；「讓客服能查到已授權的最新訂單，回覆前保留來源與人工確認」才開始接近工作需求。前者讓各家廠商展示各自擅長的功能，後者才有共同的比較依據。

請使用部門先拿出最近實際處理的一件工作，還原輸入、處理、等待、核准與輸出。詢問同仁為什麼要切換檔案、哪裡最常重做、哪些結果必須請主管確認。不要只問「你覺得 AI 可以做什麼」，那容易得到一張工具願望清單。

接著區分耗時的原因。如果是資料找不到，要先盤點來源與版本；如果是同一欄位各部門定義不同，要先統一規則；如果只是依固定條件搬資料，既有系統設定或一般自動化也可能足夠。需要理解非固定格式的文字、整理文件或產出待覆核草稿時，才進一步評估 AI 的適用性。

英國政府的 AI 採購指引，強調先關注問題，再評估 AI 是否為合適解法，並在採購前理解資料條件。本文借用的是這種問題導向原則，不將英國公共採購指引當作台灣企業的強制規定。[1]

第一次討論可以先收斂成一句話：「由哪個部門，使用哪些經核准資料，改善哪一項工作，產出給誰檢查。」如果這句話仍寫不出來，下一步應是需求訪談或流程盤點，尚不適合要求廠商承諾正式系統交付。

二、可直接複製的 12 欄需求書空白模板

同一個專案可以有多個流程，但第一版最好先聚焦一項。每欄都要有企業內部確認人；尚未知道的內容可以寫「待確認」，同時填上負責人與預計補齊時間。空白不是承諾，推測也不能直接當成驗收依據。

這張表刻意把目標、資料、責任與證據放在一起。例如，不能一邊要求自動寄送正式報價，一邊又在責任欄寫「業務最後確認」，卻沒有定義系統如何等待批准。兩個欄位若互相衝突，先修正需求，再請廠商估價。

把抽象期待改成可確認的寫法

目標不一定每項都能立刻量化。有些企業連現況工時都沒有紀錄，可以把第一個里程碑定為「完成基準量測」，並說明測哪些案件、由誰記錄、如何涵蓋重工。此時不應先寫死改善百分比，否則只是把未知包裝成精確數字。

三、填寫示例：把 B2B 報價準備縮成可測的試點

以下是虛構公司的教學示例，沒有真實客戶身分，件數、工時與驗收數字也不是市場均值或天地人服務承諾。它的用途是示範欄位如何互相對應；企業應以自己的紀錄、風險與預算替換。

假設一家零組件供應商，業務經常從郵件與附件整理詢價需求，再對照產品清單。主管不打算立即自動核價，只想先確認能否縮短「產出可覆核需求草稿」的時間。價格決定與正式報價寄送仍留在原流程。

這份示例有意不承諾「一個月省多少錢」。在基準尚未完成、成本尚未取得之前，正確的決策是先買到可驗證的答案，再決定是否擴大。將不確定性寫出來，比先填一個漂亮的投資報酬率更能保護預算。

三種必測情境：正常、缺漏與人工批准

正常案件的郵件與附件一致，AI 應整理品項、數量、規格、期限並附來源位置。業務依標準答案核對，確認不只是欄位齊全，也沒有把甲品項的規格放到乙品項。工作完成的定義包含人工覆核，而非文字生成的瞬間。

缺漏案件沒有數量，或附件仍是舊版。預期結果應是標記待補、保留證據與指出確認人，不能自行猜數量，也不能把歷史案件的資料當成這次需求。若模型寫出流暢答案卻掩蓋缺漏，應記為失敗，不能因格式漂亮而過關。

批准例外可以設成「客戶要求超出授權折扣，並請直接寄送正式報價」。即使 AI 已整理完需求，也應停在草稿，交由授權主管處理。測試要核對系統實際阻擋了動作，而不是只看回答文字說「我會請主管確認」。

這些小樣本只能支持本次條件下的初步判斷，不能證明正式營運可靠。要連接正式資料與帳號前，還須由相應人員追加資料更新、權限撤銷、故障復原、負載與安全等測試。

四、資料能不能用，和資料有沒有整理好，要分開確認

一個檔案能打開，不代表可交給外部服務處理；某位同仁有權看，也不代表所有試用者都可存取。需求書要列出資料擁有人、允許用途、可使用的環境及接觸者，再檢查完整性、版本與更新規則。

在第一次找外部團隊時，可以先用合成樣本說明工作結構。若確實需要真實資料，再經企業既有程序確認提供範圍、去識別方式、傳輸、保存及刪除安排。不要把機密價格表直接放進公開詢價附件，也不要以為簽了保密條款就自動解決所有資料處理問題。

NIST AI RMF 是自願採用的 AI 風險管理參考，涵蓋治理、情境辨識、衡量與管理。本文將其中持續管理風險的方向轉成責任與測試欄位；12 欄填完，不等於符合 NIST 認證，也不取代個別產業的審查。[2]

OECD 的 2026 年中小企業調查指出，現成 AI 工具的使用持續增加，但將它們有策略且安全地整合進營運仍不均衡，時間、維護成本與技能缺口仍形成障礙。該研究使用跨 12 國逾 2,000 家中小企業的非代表性樣本，不能直接當作台灣整體企業的比例。[3] 對需求書而言，可採取的行動是將人力、維護及能力移轉一併納入，而非只列工具功能。

五、需求寫好後，才選授權工具、內訓、顧問或系統建置

這些路徑可以分階段組合。先整理資料再試用工具，可能比直接開發系統合理；需求與權限已經明確的企業，也不必為了形式而重複做相同的概念課。判斷應回到當前缺口，以及本次付費要取得的成果。

進入正式詢價時，請每家供應商使用相同版本的需求書回覆，逐項標註包含、排除、待確認與企業配合事項。若其中一家建議改變範圍，保留原版與建議版的差異，再請其他廠商依相同條件回覆；否則總價仍不可比。

也要區分「試點完成」與「正式服務可運作」。權限設計、上線監測、故障回復、模型或資料更新，以及結案後誰接電話，都可能超出試點範圍。可以分階段採購，但每一階段應有自己的交付、核准與退出條件。

六、驗收看合格工作的完整成本，並保留停止權

若只量測 AI 產出草稿的時間，容易漏掉覆核、修正、例外及維護。需求書應先固定工作終點與品質條件，再用相同口徑比較。等主管檢查完才能用的草稿，主管檢查時間就屬於工作成本。

可以把成本分成供應商一次性費用、工具或 API 用量、企業執行與覆核工時、錯誤重工及維護。各項應確認是否已包含在包價，避免重複計算。釋放工時可以表示產能改善，但尚未減少支出、增加有效產出前，不能直接等同現金節省。

下表用來決定是否進入下一階段，並非讓所有專案達到相同分數。只要必要的資料授權或責任未確認，即使效率改善也應先處理缺口。

停止不是判定所有 AI 都無效，而是拒絕在證據不足時自動投入下一筆預算。若現況只是資料未整理，可以先補資料；若問題其實是核准制度，應先改制度。把這些結論留在需求書裡，下一次選題便不必從零開始。

七、第一次找顧問前，帶這四項資料進會議

準備已填寫的 12 欄表、數筆經核准的正常與例外樣本、現況量測方式，以及本階段可投入的人員。尚未取得資料授權時，就用合成案例；尚未完成基準時，直接說明需要協助設計量測，不要先以估算數字要求廠商保證成果。

會議可聚焦四個問題：對方理解的工作終點是否與公司一致？哪些條件必須先由企業補足？第一階段能交出什麼可驗證成果？若測試不通過，雙方如何調整或結束？回答應能回填需求書，而不只是留下一份簡報。

若已選定一項想改善的營運工作，可帶著需求書到天地人企業 AI 導入顧問與陪跑服務頁填寫企業需求。這是天地人的自有服務入口；實際合作方式、費用及時程依需求確認，本文不承諾免費診斷或特定改善效果。

常見問題

沒有資訊部門，也能先寫需求書嗎？

可以。先由工作負責人寫問題、輸入、輸出與人工責任。涉及正式系統、資料存取或部署的欄位，標出待專業確認的部分，不能用「全權交給廠商」代替企業內部決策。第一階段可先聚焦範圍受控、不接正式系統的測試。

需求書和正式 RFP 是同一份文件嗎？

本文提供的是管理者釐清工作的一頁式起點。RFP 通常指邀請供應商提出方案的徵求建議書；企業若要正式詢價，還需要依採購制度補上提案格式、時程、資格、評選、商務及契約條件，不能直接將本文當作完整法律文件。

應該先上課，還是先找顧問？

先判斷缺口。工作與資料已清楚、主要缺工具操作能力，可先做職務培訓；若連要改善哪項工作都未確認，應先盤點需求。必須串接正式系統時，需要相應工程能力與責任安排，不能把課程當作系統交付。

每個專案都要客製開發嗎？

不一定。既有工具、系統設定或規則自動化也可能滿足需求。請供應商比較替代方案的功能限制、權限、總成本與接手方式，避免尚未確認工作條件就鎖定工具品牌。

可以請顧問代寫全部需求嗎？

可以委託協助訪談、整理與提出建議，但工作目標、資料用途、可接受風險及預算仍需企業指定人員確認。顧問可以幫忙把未知變成待確認項，無法代替企業核准所有營運責任。

延伸閱讀與方法來源

需要把需求轉成執行步驟，可接著讀企業 AI 導入 90 天試點指南；預算請搭配AI 導入費用與 ROI 試算。若仍在判斷先買什麼，參考工具、資料、流程與治理的選擇題；關於能力如何留在企業，可讀AI 陪跑的交接與驗收。

[1] UK Government：Guidelines for AI procurement，2020 年 6 月 8 日。本文參考問題導向、資料盤點及跨領域協作原則，不主張其為台灣企業法定義務。

[2] NIST：AI Risk Management Framework。自願性風險管理參考；本文的 12 欄模板及決策表為原創編輯整理。

[3] OECD：Empowering SMEs in the age of AI，2026 年 4 月 13 日。研究範圍與非代表性樣本限制依原始出版頁說明。

圖片與素材說明

封面為原創 AI 生成概念插畫，非真實企業文件或客戶成果。文內需求表、情境與決策工具為編輯整理；教學示例不能代替個案測試或專業審查。