只看得到總額，
不知道是誰、哪個模型在花
為什麼現在很紅：全公司共用一個 AI 組織帳號，底下幾支 API key 是不同人在不同時間建的，用途不明；帳單變高時，後台只看得到一條總用量曲線。
- 一句話結論
- AI 帳單上只有總額時，沒人說得出這筆錢是誰花的、花在哪個模型上；不知道是誰在花，就沒辦法設預算或評估效益。
- 他要的是什麼
- 一支沒有主人、名字看不出用途的 key，最適合躲在總用量曲線裡：多花的那一段，大家都以為是別的團隊。
- 你今天做一件事
- 今天就打開 AI 平台後台，把每支 API key 列出來，標上擁有者；標不出來的，就是第一批要處理的。 直接去做 →
- 哪些能信
- 2 可證明2 推論2 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（示意情境；涉及的是 AI 平台的組織帳號與 API key，不是自家主機）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 管理層：全公司共用一個 AI 組織帳號，API key 沒有擁有者、命名與用途紀錄；沒有依團隊或用途拆專案或工作區；公司卡上另訂的 AI 服務不在同一個後台
- 馬上自我檢測
登入 AI 平台後台，列出所有 API key 的名稱與建立時間 逐支確認是否叫得出擁有者與用途 從公司卡帳單篩出其他 AI 訂閱，看是否有後台以外的支出- 漏洞修補方式
- 每支 key 指定擁有者、用途、環境與建立日期；找不到主人的先停用一週，沒人問就刪；制定「部門-用途-環境」命名規則；依團隊或用途拆專案或工作區；每月匯出用量加上公司卡 AI 訂閱，做一張歸屬表發給各團隊主管
有 15 分鐘再看：其餘 2 點
- 用途不明的 API key 不只花錢，也可能是外洩的跡象；公司卡上另訂的 AI 服務，更是根本不在後台裡。
- 不用先買工具：每支 key 指定主人、照規則命名、依團隊拆專案，每月做一張「誰花了多少」的表，就能解決大部分問題。
財務拿著 AI 月結帳單問工程主管這個月怎麼多這麼多，工程說可能是產品部，產品部說應該是 API 那邊。AI 支出最難管的往往不是金額，而是歸屬。這篇用命名規則、專案拆分和每月一張歸屬表，把總額拆回每支 key 和每個團隊。
本篇目錄
一路問下去，沒人說得出是誰花的
假設有一家三十人的新創公司，全公司共用一個 AI 平台的組織帳號，底下有好幾支 API key：一支給正式環境的客服機器人，一支給工程師測試，還有幾支是不同的人在不同時間建的，用途不明。
先說清楚，這是示意情境，不是真實事件，公司與細節都是為了說明而設。某個月帳單明顯變高，財務拿著帳單問工程主管，工程主管說可能是產品部，產品部說他們只用聊天介面，應該是 API 那邊。工程團隊打開後台，只看得到總用量曲線；要拆到每支 key、每個模型，得自己匯出資料慢慢整理。另外，有些人用公司卡訂了其他 AI 服務，根本不在這個後台裡。
這篇要講的只有一件事：AI 支出最難管的往往不是金額，而是歸屬。
不知道是誰在花，風險在哪裡
第一層是無法歸因就無法管理。不知道是誰在花，就沒辦法設預算，也沒辦法評估這筆錢值不值得。
第二層是用途不明的 key。它不只花錢，也可能是外洩的跡象，有人在用，但不是你以為的那個人。
第三層是模型選擇沒有回饋。不同模型價差很大，團隊卻不知道自己的選擇造成多少成本差異。
最後是跨供應商無法比較。每家的報表格式不同，公司卡上的訂閱和 API 用量又在不同的系統裡。
這篇示意情境裡，有哪些鑰匙沒人管
這是示意情境，沒有實際外洩；下表列的是共用組織帳號底下最常見、也最難歸屬的那幾支 key。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| AI 平台組織帳號 | API key（用途不明的數支） | 不明；可能是過去的測試或個人實驗 | 明文字串，存在建立者手上或某段程式設定裡 | 共用組織帳號底下 | 可消耗整個組織帳號的額度 | 示意情境；未停用前持續有效 |
| AI 平台組織帳號 | API key（測試用） | 工程師測試 | 明文字串，常見放在本機環境變數 | 工程師的開發環境 | 與正式環境共用同一組織額度 | 示意情境；用量與正式環境混在一起 |
兩列的共同點是：都在同一個帳單裡，但沒有一支寫得出主人是誰。
能證明的、只能推論的
這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的功能；情境裡的歸因只能算推論。
不花錢就能做的流程
到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的五步流程。
第一步，每支 key 都要有主人。 列出所有 API key：名稱、擁有者、用途、環境（正式或測試）、建立日期。找不到主人的 key，先停用一週，看有沒有人來問，沒人問就刪除。
第二步，命名規則。 例如「部門-用途-環境」，像 support-bot-prod-j5q。新建的 key 一律照規則命名，報表一看就懂。
第三步，一個團隊或用途一個專案。 如果平台支援工作區或專案，就依團隊或用途分開，帳單就能自然拆分。
第四步，每月一張歸屬表。 匯出用量，依 key 或專案加總，再加上公司卡的 AI 訂閱，做成一張「誰花了多少」的表，發給各團隊主管。
第五步，模型選擇的簡單原則。 例如測試用便宜的模型，正式環境依需求選。把各模型的價格整理在內部 wiki，讓團隊自己權衡。
什麼時候不需要買工具
一兩家供應商、key 不到二三十支的話，命名規則加上每月一張歸屬表就能解決大部分問題。
真的要看工具，市面上大致分四類。AI 供應商後台，例如 Claude Console 的成本與用量報表，拆分的細度要看各家介面。雲端成本管理，透過 AWS 或 Google Cloud 使用模型時，用標籤、專案搭配預算來拆分和警示。自建彙整，用試算表或 BI 工具定期匯入各家用量資料。商用的跨供應商 AI 用量管理，則是彙整多家 AI 用量和成本、依團隊歸屬的平台類型。
更新（2026/07/14）：1Password 於 2026/07/14 發表 AI Spend & Consumption Management 公開預覽，官方新聞稿說可以依團隊、使用者等面向歸屬 AI 用量與成本，預計 2026 年秋季廣泛提供。這屬於上面說的「跨供應商 AI 用量管理」類型，實際功能以正式版為準。
限制也要一起看：歸屬的前提是 key 和專案本身有分清楚，工具無法替你補上缺少的標記；公司卡上的訂閱和 API 用量通常在不同的系統裡。選的時候看三件事：團隊少用每月一張表就好，團隊多、要分攤成本時再考慮自動化；席位制訂閱看付款紀錄、用量制看 API 報表，兩者都要涵蓋；彙整工具需要管理員 API 權限，評估時要把這個權限本身的風險算進去。
這篇提到的項目要花多少錢
這篇的方法以人力為主；示意情境裡的帳單金額沒有實際數字，照實標成缺口。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 第一次列出所有 API key 並找主人 估 | 工程主管一人 | 估 2–3 小時 | 一次性 | — | — | 本站依五步流程估算 |
| 每月歸屬表（匯出、加總、發送） 估 | 一人 | 估 1 小時／月 | 每月 | — | — | 本站估算 |
| AI 供應商後台的用量報表 | 帳號內建功能 | 本文來源未說明是否另計費 | — | — | — | 官方說明只列功能與角色 |
| 示意情境中帳單增加的金額 | 未知 | 依各家牌價 | 一個月 | — | — | 示意情境，沒有帳單 |
| 商用跨供應商 AI 用量管理 | 依團隊數 | 本文來源未列價格 | 訂閱 | — | — | 本文來源未列價格 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
最貴的不是那一個月多出來的帳單，是每個月都要重新問一輪「這是誰花的」。
你可以學到什麼
站在攻擊者那一側看，一個共用的組織帳號加上一堆沒有主人的 key，是最好躲的地方：他用外洩的那支 key 多跑了一段，帳單上只多了一點總額，每個團隊都以為是別人。歸屬清楚的帳，才會讓多出來的那一段顯得突兀。
- 01AI 支出只看得到總額時，沒人說得出是誰花的，也就沒辦法設預算或評估效益。
- 02每支 API key 都要有擁有者、用途和環境；找不到主人的先停用一週，沒人來問就刪除。
- 03依團隊或用途拆專案或工作區，帳單就能自然拆分；工具無法替你補上當初沒做的標記。
- 04每月一張「誰花了多少」的表要同時涵蓋 API 用量和公司卡上的 AI 訂閱，兩者通常在不同系統裡。
- 05跨供應商彙整工具需要管理員 API 權限，評估時要把這個權限本身的風險一起算進去。
- 01成本歸屬（Cost Attribution）這篇的主角：把總額拆回每個團隊、每支 key，才談得上管理。
- 02API key 擁有者沒有主人的 key 既無法歸屬，也是外洩的可能跡象。
- 03命名規則（部門-用途-環境）最便宜的歸屬工具，讓報表一看就懂。
- 04工作區／專案拆分依團隊或用途分開，帳單自然就拆好了。
- 05組織帳號（Organization）全公司共用一個帳號時，所有 key 的用量混在同一條曲線裡。
- 06Claude Console 用量報表示意情境中查看成本與用量的地方，依角色開放。
- 07成本分配標籤（Tags）透過雲端平台使用模型時，用標籤拆分支出的前提。
- 08席位制 vs 用量制前者看付款紀錄、後者看 API 報表，歸屬表兩者都要涵蓋。
- 09管理員 API 權限彙整工具需要它，而它本身就是一把高權限的鑰匙。
- 10月度歸屬表不花錢就能讓各團隊主管看到自己的 AI 支出。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 登入 AI 平台後台，列出所有 API key 的名稱與建立時間（唯讀）看到什麼代表什麼：名稱看不出用途、建立者已不在團隊的，就是第一批要找主人的 key。
- 對每支 key 問一句：誰在用、用在哪個環境（不用指令）看到什麼代表什麼：答不出來的那幾支，正是總額裡最說不清的一段。
- 在後台用量報表試著依 key、工作區或模型篩選（唯讀）看到什麼代表什麼：篩得出來，就能直接做歸屬表；篩不出來，代表要先拆專案。
- 從公司卡帳單篩出不在這個後台的 AI 訂閱（唯讀）看到什麼代表什麼：這些是歸屬表上一定要另外加進去的那一塊。
揭露：本文未受任何廠商贊助，提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。
來源
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。