知道誰使用了 AI，只是企業 AI 治理的第一步
當企業發現某名員工或 AI Agent 的 Token 用量突然大幅增加，管理層通常會問：這是合理的業務需求、低效率的使用方式，還是有人正在使用公司資源處理私人工作？
AI 帳單本身無法回答這個問題
同樣的 Token 增長，可能來自重要系統即將上線、Agent 陷入重複呼叫，或企業帳戶被用於私人項目。這些情況在成本報表上可能十分相似，但代表的風險和處理方式完全不同。
企業可以單靠 AI Token 用量判斷私人用途嗎？
不可以。Token 數量、使用時間和異常行為只能提供調查訊號，不能單獨證明一項 AI 活動屬於企業工作或私人用途。
企業需要把用量連結至實際使用者、應用程式、裝置、業務項目、工作負載、數據類型和成本責任，才能形成較可靠的判斷。
Identity-aware AI Gateway 可以協助企業回答「誰在使用」；行為分析可以指出「誰偏離了正常模式」。但企業仍需要業務脈絡，才能判斷這項活動是否獲得授權。
Cloudflare Identity-aware AI Gateway 能解決什麼？
Cloudflare 在 2026 年 8 月發表的文章《Catching rogue AI behavior with identity-aware analytics》中指出，企業需要把 AI 請求連結至已驗證的使用者身分，並為每名使用者或 Agent 建立正常的使用基線。
Cloudflare Access 與 AI Gateway 的整合可以把已驗證的使用者 ID 寫入請求 Metadata，讓管理員按照實際使用者查看 Logs、Analytics 和支出。Identity-aware AI Gateway with Cloudflare Access 目前處於 Open Beta，而 User Insights 已向 AI Gateway 客戶正式提供。
User Insights 所回答的，不只是「誰花費最多」，而是：誰的 AI 使用突然改變了？
這種分析有助企業發現 Credential 被盜用、Agent 行為失控或突然出現的高成本工作負載。但Cloudflare 亦清楚說明，User Insights 不會判斷使用意圖，也不會自動封鎖帳戶。它只會把偏離正常基線的活動帶到管理員面前。Cloudflare 正在開發 Prompt Classification，以區分 Coding、Writing 等工作類型，但這仍屬後續發展方向
從企業治理角度來看，這代表異常偵測只能提供調查線索，不能單獨構成員工濫用或私人使用的證據。
為什麼異常使用不等於濫用？
假設一名市場部員工在星期六晚上使用了數百萬個 Token。這可能是私人用途，也可能是為星期一的產品發布準備多語言內容。
相反，一名開發人員每天在辦公時間內穩定使用 AI，沒有偏離正常基線，但實際上可能正在利用企業模型額度開發私人產品。
Token 本身並沒有「企業用途」或「私人用途」標籤。高用量不一定代表浪費，辦公時間內的活動也不一定屬於公司工作。即使 Prompt 的主題符合員工職位，也不能證明該工作已獲得公司授權。
因此，企業需要區分三個層次：
身分告訴企業誰使用了 AI。行為分析告訴企業什麼發生了變化。業務脈絡才協助企業判斷這項工作是否真正屬於公司。
Master Concept 提出的 Business Context Layer
從 Master Concept 的顧問角度，企業可以在 AI Gateway 周圍建立一個 Business Context Layer。此治理框架概括企業判斷 AI 使用目的時所需的身分、存取、應用程式、項目、工作負載、數據和成本訊號。
| 判斷脈絡 | 核心問題 | 判斷價值 |
| Identity | 哪名員工、承辦商或 Agent 使用？ | 建立問責 |
| Access | 是否來自受管理裝置和合規環境？ | 評估存取風險 |
| Application | 是否透過獲批准的企業應用程式？ | 驗證使用渠道 |
| Project | 是否連結有效項目或工作指令？ | 驗證業務目的 |
| Workload | AI 實際在處理哪類工作？ | 補充用途脈絡 |
| Data | 數據是否獲准由該模型處理？ | 評估數據風險 |
| Cost ownership | 哪個部門或項目承擔成本？ | 建立財務責任 |
沒有任何單一訊號能夠可靠地判斷使用意圖。較可信的結論，來自多項訊號是否能夠互相支持。
建立可問責的身分和業務歸屬
企業首先應減少使用無法歸屬的共用 API Key，盡量把每項 AI 活動連結至員工、承辦商、Service Account 或 Agent。
Cloudflare AI Gateway 支援 Custom Metadata，企業可以加入 User ID、Team、Application 或其他識別資料。當請求透過受 Cloudflare Access 保護的 Custom Domain 進入 AI Gateway 時，AI Gateway 會把已驗證的 Access User ID 寫入 cf.user_id。
但只有身分仍然不足。企業還需要知道請求是透過哪個應用程式發出、屬於哪個項目，以及由哪個部門或 Cost Centre 負責。
Cloudflare AI Gateway 可以按照 Model、Provider 和 Custom Metadata 設定 Spend Limits。當累計支出達到限制時，後續請求可以被阻擋，或轉往較低成本的處理方式。
這些項目標記不應完全依賴員工自行填寫，否則私人活動也可以被標示為「客戶項目」。較可靠的設計，是由獲批准的企業應用程式自動加入 Project ID，再由內部系統驗證項目狀態、團隊權限和預算歸屬。
如此一來，管理員看到的便不只是：某名員工使用了一百萬個 Token
而是：某名員工透過獲批准的應用程式，為一個有效客戶項目使用了一百萬個 Token
Cloudflare AI Gateway 目前每次請求最多保存五個 Custom Metadata 項目。因此，企業不應嘗試把完整治理資料都放進每一次 AI 請求。較實際的做法，是只傳送 User ID、Application ID、Project ID、Environment 和 Cost Centre 等核心識別碼，再透過內部 Registry 查找項目負責人、數據分類和批准模型。
工作合理，不代表數據使用合理
即使一項 AI 工作確實屬於企業項目，也不代表它符合所有政策。員工可能正在執行獲批准的客戶工作，卻把個人資料、Source Code、Credential 或合約內容發送至不合適的模型。此時問題不是私人用途，而是數據治理、供應商風險和合規風險。
Cloudflare AI Gateway DLP 可以檢查發送至模型的 Prompt 和模型傳回的 Response，並按照政策標示或阻擋敏感資料。
企業亦可以把工作負載概括為 Software Development、Customer Support、Content Production、Internal Research、Data Analysis 或其他類型，但這些分類只能提高調查效率，不能直接成為違規裁決。
一項 Coding 請求仍可能屬於私人開發；一項 Writing 請求亦可能是合理的企業工作。
企業是否需要保存所有 Prompt？
不建議。
企業應採取風險為本以及最少必要原則，而不是預設長期保存所有 Prompt 和 Response。
Cloudflare AI Gateway Logs 可以記錄 Prompt、模型回應、Token、成本、模型和執行時間。企業也可以停止保存 Request 和 Response Payload，同時保留 Model、Provider、Token、Status、Cost 和 Duration 等 Metadata。
對一般低風險活動而言，企業通常只需要保留身分、應用程式、項目、模型、Token、成本和風險結果。只有當活動觸發異常、DLP、未批准應用程式、異常裝置或缺少業務歸屬時，才啟動更深入的記錄和人工審查。
企業需要建立的是可解釋的治理紀錄，而不是無限擴張的員工監察系統。
發現異常後，企業應如何回應？
企業不應把所有異常活動一律封鎖。
如果活動來自獲批准的應用程式、受管理裝置和有效項目，企業可能只需要記錄原因並繼續監察。如果用量異常，但業務目的仍然不清楚，則可以要求使用者或業務負責人確認。
對於工作合理但使用方式低效率的情況，企業可以提供模型選擇建議、培訓或成本限制。只有當活動涉及未知身分、未批准應用程式、敏感數據或 Credential 風險時，才應考慮限制模型、隔離 Credential 或直接封鎖。
Cloudflare 亦建議企業先以 Monitoring Mode 學習正常基線，再逐步進入執行階段。
這種分級處理可以避免把高生產力員工誤判為威脅，也避免企業因為一項活動沒有偏離基線，便假設它一定安全。
AI 治理應由政策開始，而不是由 Token 上限開始
成本上限可以控制支出，但不能定義什麼是合理使用。
企業首先需要確定哪些人可以透過哪些應用程式使用哪些模型、處理哪些類型的數據，以及哪些業務目的屬於可接受用途。
NIST AI Risk Management Framework 是一套自願採用的 AI 風險管理框架，透過 Govern、Map、Measure 和 Manage 四項功能，協助組織建立治理責任、理解使用脈絡、量度風險和採取管理行動。
ISO/IEC 42001 則要求組織建立、實施、維護和持續改善 Artificial Intelligence Management System。它把 AI 治理視為一套包含政策、目標、流程、風險處理和持續改善的管理系統，而不是單一監察工具。
這兩個框架不會直接判斷某個 Prompt 是否屬於私人用途。它們所支持的是更基礎的治理原則：企業必須先定義責任、可接受用途和風險承受水平，才能有效配置 AI Gateway、身分控制、DLP、Metadata 和 Spend Limits。
從 Master Concept 的顧問角度，企業下一步應建立 Business Context Layer，把身分與應用程式、項目、裝置、工作負載、數據和成本責任連接起來。因為企業最終需要回答的不只是誰使用了這些 Token，而是這些 Token 是否被用於企業已授權、願意支付成本，也願意承擔相關風險的工作。歡迎聯絡思想科技 Master Concept 專業顧問了解更多！
FAQ
Cloudflare User Insights 可以自動判斷私人用途嗎？
不可以。它可以找出偏離正常行為基線的使用者或 Agent，但不會判定意圖或自動封鎖帳戶。企業仍需要加入項目、應用程式、數據和成本脈絡。
高 Token 用量是否代表濫用？
不一定。大型程式碼分析、文件處理和研究工作都可能合理地消耗大量 Token。企業應評估用量是否與有效業務項目和獲批准的工作負載一致。
Business Context Layer 是 Cloudflare 功能嗎？
不是。Business Context Layer 是本文由 Master Concept 提出的治理框架，用來描述企業在 AI Gateway 技術資料之外，仍需連接的項目、應用程式、數據和成本脈絡。
