以下各項能力按其於 Console 側邊選單中出現的次序列出。每節都會點出採購問題、Console 為此做了甚麼,以及資料存於何處。
成員與存取
問題:我們組織內誰獲准使用 AI Suite,屬於哪一級授權?
Console 讓管理員以電郵邀請同事、指派 Personal 或 Commercial 授權席位(Monthly、Annual 或 One-Time),並於員工離職時撤銷存取權。可透過 CSV 批量邀請。組織名冊就是部署者就「誰擁有存取權」的單一真實來源 —— 當合規團隊獲要求展示人類監督時,所產出的同樣是這個答案。
存於 Software Tailor 後端的:組織名冊。不存的:這些成員於模型內做過甚麼的任何紀錄。Console 是存取介面;推理發生於本地。
授權
問題:每位成員擁有哪一級,而離線時又如何執行?
按使用者的授權密鑰於離線情況下驗證。當席位需要在沒有網絡來回的情況下繼續運作時便有用 —— 這是受規管行業常見的要求,因為 AI 工作站常處於分段網絡之中。Console 發出及撤銷密鑰;按使用者的層級覆寫會與組織預設並列顯示。
這是 Console 唯一一項會寫入需傳送至使用者機器的能力。其餘一切都是關於部署的元資料,而非關於內容。
AI Server 註冊
問題:我們組織信任哪些硬件來運行推理?
AI Suite 安裝與本地的 aisuite-server 進程對話;該進程可與裝置上的模型或運行於客戶網絡內、由客戶掌控的 AI Server 對話。AI Server 註冊就是 Console 將這些伺服器實例與組織綁定的方式,讓它們接受來自已獲核准的 AI Suite 安裝所發出的已簽署請求。可配對、輪換憑證、撤銷,而毋須觸碰伺服器機身。
採購層面的角度:推理硬件是部署者的。註冊正是證明此事。Console 從不接觸模型的輸入或輸出。
政策
問題:哪些模型、提供者及資料處理規則適用於我們組織的 AI Suite 安裝?
政策就是每個 AI Suite 應用程式所遵守的組織級配置:容許哪些模型、資料駐留提示、登入提供者,以及 OIDC 租戶配置。改動會於下次啟動時傳播至每個安裝。這就是當合規問及「有甚麼護欄?」時,部署者所指向的對象 —— 也是當 EU AI Act 修訂落地時要編輯的地方(最近一次是 2026 年 5 月 7 日的綜合協議收緊了高風險系統的定義 [1])。
審計
問題:誰於何時做了甚麼 —— 而我們能否按要求產出?
每項管理動作均落入一條 JSONL 審計列:時間戳、操作者的電郵、動作動詞、所影響的資源、發起客戶端的 X-App-Id。沒有提示詞。沒有回應。沒有文件內容。部署者的內容儲存空間保存推理內容;Console 的審計列保存動作曾經發生的證明。
這種區分正是讓該列能滿足 NIST AI RMF「足以重構決策之系統動作紀錄」[2],而毋須保留部署者不想保留的模型內容。架構與列格式記錄於我們不含內容的審計日誌一文。
按組織用量
問題:我們組織整體實際正在發生甚麼?
一份範圍限於組織的唯讀遙測匯總:活躍安裝數、最常見事件、平均推理時長、模型評分。沒有原始提示詞。一切以設計言之皆已匯總且不含內容。部署者的 IT 團隊以此作容量規劃;合規團隊以此回答「政策是否真正獲遵守?」
這是 Console 中唯一出現跨成員數字的位置,亦是唯一將行為隨時間匯總的地方。
為何只用一個工具
NIST AI RMF [2] 要求「足以重構決策之系統動作紀錄」。EU AI Act 要求部署者展示人類監督、監察系統運作、保存日誌,並應要求產出 [1]。在兩個框架之下,擁有義務的都是部署者,而非供應商。Console 之所以存在,是因為部署者的 IT 團隊需要一個地方履行此義務。
六項能力並非功能清單。它們是採購審查者按次序提出的六個問題的答案。準備就本地 AI 部署開展盡職審查的團隊,應先從為何本地 AI 部署於採購階段卡關一文的論述框架開始;Console 則是答案所在。
參考資料
- European Commission。「AI Act — Regulatory framework on AI。」digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai。檢索於 2026-07-01。
- NIST。「AI Risk Management Framework。」nist.gov/itl/ai-risk-management-framework。檢索於 2026-07-01。
相關文章
在真實工作負載上看 AI Admin Console 的運作。
免費的 1-week 試行將模型放於客戶的硬件、審計列放於客戶的 SIEM,並將 Console 的六項能力交到 IT 團隊手中。