中央出 29 美元，超過的記專案帳：管 AI 用量之前，先回答費用歸誰

人均上限看得見總量，看不見每一筆用量對應的工作價值。Accenture 的分攤設計，把管理題從「用多少」推進到「為哪項工作而用」。

每月 29 美元，是 Accenture 為部分 Claude 使用者由中央預算負擔的額度。同一份報導裡，個別員工的單月用量曾達到數百美元，逼近一千美元。這兩個數字之間的落差，就是企業 AI 成本管理實際要處理的區間：額度訂在平均值附近，重度使用的工作會中途卡住；額度訂得寬鬆，帳單又會以更快的速度長大。

依 404 Media 十月報導，Accenture 自 2026 年 10 月起，對部分 Claude 使用者由中央負擔每人每月 29 美元，超過的部分，轉由專案或團隊的工作分解結構（WBS）預算代碼承接。使用者想繼續用，得先申請到對應的代碼；內部通知也寫明，取得代碼不代表可以無限使用，也不保證持續存取。

Accenture 對外的說法是，公司會依工作需求提供工具，並持續投資 AI。要留意的是，這是媒體取得內部通知後寫成的個案報導，看不出全公司是否一體適用，也無法用來判定新制度的成效。它真正點出的，是一個多數企業還沒想清楚的問題：AI 的帳單，最後應該記在誰的預算裡。

同一條上限，兩種工作處境

多數企業的第一個念頭，是替每個人設月度上限。這個做法的麻煩在於，同樣的額度對不同工作，意義完全不同。

一名員工每天用 AI 草擬幾封簡短的信件，月用量可能根本碰不到門檻。另一名工程師用程式代理讀整個程式庫、跑測試、來回除錯，長對話、大型檔案與工具呼叫都會推高用量，同一條上限可能讓工作做到一半被迫停下。Anthropic 的企業使用管理指南也列出不同層級的額度與共享預算設計，計費依方案、席次或用量而異，功能差異不小，額度本身並不保證成本下降。

把所有人的用量換算成人均數字，等於把這些差異壓平。總帳單告訴管理者總共花了多少錢，說不出錢落在哪種任務、哪個專案、哪一種使用流程上。反過來講，用量高也未必等於浪費，判斷要回到幾個情境：任務是否必要、產出有沒有被採用、人工檢查與返工有沒有減少。沒有費用歸屬的資料，這些判斷一個都做不了。

另一個極端是逐筆追蹤到個人。管理負擔會明顯增加，也容易把使用者推向拆帳、共用帳號，或者改用自己申請的帳號，讓這部分用量從公司帳面上消失。管理動作本身，會改變被管理者的行為。

時間點也值得注意。企業 AI 在這兩年從試用期走進日常作業，使用方式從偶爾問答變成常駐代理，這與我們先前整理的Muse 與 Dots 帶起的常駐智慧體熱潮是同一條曲線：當工具整天開著跑，費用的單位就從「問了幾次」換成「跑了多久」。帳單從零星雜支變成預算表上看得到的科目，管理壓力才會在此時湧現。

個人、部門、專案：費用歸屬的三條路

個人額度、部門共享預算、專案預算，三種做法並非互斥的單選題，處理的是不同性質的費用，多數企業終究要混用。

個人額度的強項是快速識別異常。哪個帳號的用量突然暴增，一眼就能看到。短板在前一段已經說過：它看不見職務差異，對重度使用者形成工作中斷。

部門共享預算適合承接多人協作、共同服務，以及還沒歸屬到單一專案的使用。風險是權責模糊，帳單由整個部門共同消化，個別專案的成本反而沉到水面下。

專案預算是 Accenture 這份通知選的路。費用掛在 WBS 代碼上，哪個專案用了多少 AI 資源、對應什麼交付工作，帳目上查得到。代價是流程變重：企業得先定義中央預算支付到哪裡為止、代碼的申請條件、核準人是誰、額度用盡之後走什麼程序。這些沒有定義清楚，分攤就只是把帳目從一個科目搬到另一個科目，管理資訊還是不完整。

FinOps Foundation 對雲端支出的成本分攤指引，套在 AI 費用上同樣成立：成本可依帳戶、專案或標籤對應到責任單位，共用費用按比例、按用量或以代理指標分配，或者乾脆留在中央預算。顧問業還要多回答一題：記到專案帳上的 AI 費用，能不能、以及怎麼轉嫁到客戶合約裡。這一步沒有處理好，容易出現重複計算，或把內部成本錯誤地轉嫁出去。

摩擦由誰吸收

額度制度的成本，最終多半由使用者和專案經理吸收，很少由制定制度的單位吸收。

對使用者來說，工作是連續的，額度是按月結算的。代理式的工作一段對話可能跑上大半天，中途被要求申請代碼、等待核準，等於把機器的等待換成人的等待。例外申請的流程設計得越重，繞過制度的動機就越強，而繞過的方式，通常就是讓用量重新從帳面上消失。

對專案經理來說，AI 用量變成一條新的預算線。以前藏在人員工時裡的支出，現在浮上檯面，要估、要核，最後還要對客戶交代。報價與結案的方式要跟著調整，這對多數團隊是新的練習。

真要導入類似制度，有幾件事可以依序確認。告警門檻設在哪裡、觸發之後通知誰，是第一層；例外申請的路徑與核準層級，是第二層；成本效益的檢查方式是第三層，看的指標應該包括產出是否被採用、返工有沒有減少，用量增減只是其中一項。順序上，先定義想回答的管理問題，再回頭收集足以回答問題的使用紀錄，會比先囤一大堆資料再想辦法解讀來得省力。

可以借的是設計，不是數字

這份報導可以當作「中央補助加上超額歸屬」的一個樣本。29 美元無法被推論為合理的人均標準，報導中個別員工的支出數字，也不能拿來當組織平均。每家企業的工作型態、可用模型、合約內容與帳務做法都不同，能搬走的是設計思路：先決定費用由誰、為哪一項工作負責，再談額度數字。

後續有幾個訊號值得留意。模型業者會不會把更細的歸屬工具做進企業版後臺，讓管理者不必自行拼湊紀錄，是其一。顧問業與軟體服務業的合約會不會出現 AI 費用的計價條款，把這筆成本正式寫進對客戶的報價，是其二。其三是額度趨嚴之後的替代行為：自架模型與開源路線會被重新撿起來評估，例如聯想把 122B 模型搬進 30 瓦機身的嘗試，賭的就是組織想把手續與帳單一起收回自己手裡的需求。

回到一開始的問題。額度該設多少，其實是最後一個問題。順序應該是：先定義費用責任歸屬，再讓用量資料對得上工作與預算，最後才輪到數字。Accenture 案例的參考價值在於它把順序走對了；至於 29 美元這個數字本身，換一家公司、換一種工作組成，答案就會不同。

資料來源：本站編輯參考 APPI News〈Claude 使用額度怎麼管？企業 AI 成本管理指南〉（作者：張饒輝 Lightman Chang）改寫而成，原文出處；原文文字內容採 CC BY 4.0 授權。