治理決定 AI 允許做什麼。閘道只是執行治理。

每一項技術轉變都遵循相同的模式。新平台出現後，早期採用者蜂擁而至嘗試，廠商競相推出功能，不久之後每一場會議演講都變成基準比較圖表。

企業 AI 也不例外，而目前企業基礎設施中成長最快的類別之一，就是 AI 閘道。組織希望有集中式方式連接多個基礎模型、管理憑證、監控使用量，並執行預算控制。隨著 AI 從孤立的試驗階段進入正式生產，閘道不再只是便利工具，而是必要需求。

但經過一年與架構師、平台工程師及技術領導者的對話，我不斷注意到同樣的現象：第一個真正的障礙幾乎從來不是技術問題。

會議通常是這樣進行的。資安部門詢問客戶資料是否可以傳送至外部模型。財務部門想知道 AI 支出如何在事業單位之間分配，以及當數十個應用程式每分鐘都在消耗 token 時，誰擁有預算。法務部門詢問 AI 決策將如何稽核。合規部門詢問適用哪些法規。

然後有人提出沒人準備過的問題。

「究竟是誰決定我們可以這麼做？」

房間裡突然安靜下來。不是因為答案困難，而是因為沒有人意識到需要有答案。

這些都不是閘道的問題。它們是治理的問題。

什麼是 AI 治理，以及為什麼它必須優先？

AI 治理是一組組織決策，決定公司允許如何使用 AI：誰可以核准使用哪些模型、哪些資料可以離開組織、如何分配和限制支出、哪些必須記錄和保留，以及誰可以核准例外。這是一項領導職能，而不是軟體功能。

像 Bifrost 這樣的平台很好地說明了這一點。AI 閘道是這些決策的執行層。

這正是順序重要的原因。沒有治理的閘道不會解決不一致，反而會讓不一致規模化。

AI 閘道是大門，治理決定誰能拿到鑰匙。

安裝一扇前門很簡單。決定誰拿到鑰匙、能開哪些房間、有效期限多長，以及有人通過時要記錄什麼，則困難得多。這些都是組織決策。大門只是執行它們。

沒有治理，每個應用團隊都會獨立決定供應商、憑證、預算、記錄和資料處理。兩個做幾乎相同工作的團隊，會因為兩個不同開發者在兩個不同星期二做出不同判斷，而擁有完全不同的政策。一致性消失，風險累積，營運複雜度隨員工數增加而成長。

閘道本身不會解決這個問題。它只創造一個單一位置，讓組織能一致地解決它。

如何將商業政策轉化為技術政策？

這就是 Bifrost AI 閘道比單純管道更有趣的地方。成熟的閘道不只是路由應用程式與供應商之間的請求。它是將商業決策轉譯為執行時行為。

具體來說，假設財務部門決定行銷部門每月有 2,000 美元用於前沿模型實驗，當達到上限的 80% 時發出警示，達到 100% 時硬性停止；而工程部門則有 40,000 美元，因為面向客戶的生產工作負載依賴 AI。這不是預算編列，而是關於相對風險與商業價值的治理決策。沒有系統能執行的預算只是預測。

模型存取也是如此。客戶支援、法務和工程部門各有不同的法規風險，以及使用特定模型的不同理由，這些差異都需要技術機制，否則仍只是建議。

每個連結都指向 Bifrost 如何實作該控制，但無論選擇哪個閘道，這個對應關係都成立。

請注意表格中沒有發生什麼。閘道沒有決定治理。它只是將治理操作化，而這個區別正是整個論點的核心。如果您想探索 Bifrost 如何實作這些功能，文件與開源元件可在 GitHub 的 Bifost 存放庫 中取得。

部署 AI 閘道前需做的六項決策

這些是在基礎設施開始執行前就必須存在的決策。

  1. 指定負責人。 單一負責人或常設委員會。資安、法務與工程之間的共同擁有權，往往導致根本沒人負責。
  2. 分類您的資料。 哪些類別可以傳送到外部模型，哪些永遠不行，哪些需要自架部署。大多數組織已有資料分類，只是尚未將其對應到 AI。
  3. 依功能而非偏好定義核准的模型層級。 面向客戶的生產、內部生產力與實驗性研究是三種不同的風險輪廓，不應共用同一份允許清單。
  4. 在第一個生產工作負載上線前設定預算擁有權與上限。 在採用後才回溯補上成本控制是政治問題而非技術問題，而且情況會更糟。
  5. 決定要記錄什麼以及保留多久。 NIST 的 AI 風險管理框架、ISO/IEC 42001、歐盟 AI 法案，以及現有的 SOC 2 控制都要求證據。在需要出示之前就先決定證據的形式。
  6. 撰寫例外路徑。 沒有文件化例外路徑的政策不會防止例外發生。它只會保證例外發生時沒有記錄。

這是一週的會議，而不是一季的會議。

這些決策在設定檔中的樣貌

決策三與四最容易看出，因為同一個物件同時承載兩者。在 Bifrost 中，這個物件是虛擬金鑰，包含供應商與模型的允許清單、擁有團隊，以及自己的預算。前面提到的行銷決策，也就是財務部門在會議中做出的決策，最後會呈現如下。

{
  "name": "Marketing Experimentation",
  "team_id": "team-marketing",
  "provider_configs": [
    { "provider": "openai", "allowed_models": ["gpt-4o-mini"] }
  ],
  "budget": {
    "max_limit": 2000.00,
    "reset_duration": "1M"
  },
  "expires_at": "2026-12-31T00:00:00Z",
  "is_active": true
}

Enter fullscreen mode Exit fullscreen mode

先前存在於投影片中的政策。允許清單是決策三，預算是決策四，而 expires_at 是決策六，因為將例外設定時限，是防止它預設變成永久的做法。審查政策現在只要閱讀檔案，而不是訪談二十個團隊，而當「上季哪些模型核准給誰」的答案是一個 diff 時，稽核就不再是考古工程。

這就是更深層的意義。在請求發生的那一刻建立的記錄才是證據。事後從發票與回憶重建的記錄只是證詞。我曾在其他地方將此稱為 寫入端保管，其原則是來源必須在寫入發生時捕捉，而不是事後拼湊。閘道是組織發出的每一筆 AI 請求的寫入端，這使其成為保管成本最低的地方。

但治理優先是否意味著等待？

這是一個合理的反對意見，而失敗模式也是真實存在的。許多組織已經討論 AI 治理十八個月，卻什麼都沒推出，而工程師們悄悄用個人 API 金鑰報帳繼續工作。治理每多花一個月做決定，組織就多一個月在沒有治理的情況下做決定。

因此這個論點的誠實版本不是「完成治理，再購買基礎設施」，而是這六項決策成本低廉，而生產流量不應先於其中三項：資料分類、預算擁有權與記錄。同時部署閘道。只是不要讓第一個面向客戶的工作負載，成為發現您從未決定什麼算敏感資料的那件事。

當治理改變時會發生什麼？

六個月後，同一家公司收購了一家競爭對手。行銷部門一夜之間規模加倍。財務部門希望收購團隊有獨立預算。法務部門堅持歐洲客戶資料不得離開歐盟。工程部門已有二十個應用程式在生產環境，沒有重寫任何一個的意願。

這就是組織發現閘道真正用途的時候。不是路由請求，而是吸收政策變更而不強迫應用程式變更。

如何評估 AI 閘道（超越功能清單）

比較閘道很容易，只要計算供應商數量、測量延遲或對照定價即可。這些事情很重要。但每一個閘道在每秒十次請求時的展示看起來都一樣。它們在預算上限、稽核請求和組織重組時才會出現差異。如果您正在進行正式評估，LLM 閘道採購指南 是一個合理的架構可以參考。

治理先於基礎設施

技術從來不是策略的替代品。組織可以購買市面上最強大的閘道，但如果尚未決定 AI 應如何治理，仍可能遇到困難。反之亦然，而且更有趣：先解決治理的組織，往往能更快而非更慢地採用新模型，因為困難的問題已經一次解決，而不是每次整合都要重新爭論。

這把我們帶回那個安靜的房間。

目標不是讓沒有人再問「究竟是誰決定我們可以這麼做」。目標是當有人這麼問時，房間裡有人能回答，而且能說出名字，並指出執行該決策的系統。

就像每一扇前門一樣，閘道的價值不是用它開得多好來衡量，而是用您對「誰正在通過它」有多確定來衡量。

本文與 Bifrost 團隊合作撰寫。此處表達的架構觀點與結論為筆者個人意見。