使用Unity Catalog大規模治理AI代理

一年前，你的組織可能只有十幾個AI代理。如今，可能已有成千上萬個。每個開發團隊都有編碼代理，負責編寫、審查和部署程式碼；分析團隊構建了預測代理；銷售運營部署了潛在客戶評分；支援團隊自動化了工單分派；市場營銷啟動了個性化推薦；財務部門開發了對賬工作流。每個團隊都看到了機會並迅速行動。

現在有人問：“哪些代理在訪問客戶PII？”答案需要從多個系統中提取日誌，手動關聯，然後希望沒有遺漏。每個代理的日誌記錄、身份驗證和資料訪問方式各不相同，沒有一個統一的檢視點。相反，如果你選擇了完全鎖定的路線，沒有代理能在未經嚴格審查的情況下部署，安全保持良好，但你會落後於競爭對手六個月。開發者和使用者感到沮喪，有些人甚至離開了公司，去那些真正能使用AI工具的地方。

兩種極端都不可行。不受治理的代理會帶來無法衡量的風險，而鎖定環境則帶來另一種風險：落後於人，人才流失。傳統的治理假設人類做出決策，應用程式可預測地執行它們。但代理不是這樣工作的。它們是自主的，每次做出不同選擇，並以無法透過閱讀程式碼預測的方式連結工具。你不能透過審查代理可能做什麼來治理它，而是透過控制它能訪問什麼並監控它實際做了什麼來治理。

AI代理治理的四大支柱

Unity Catalog自2021年起已透過統一許可權模型、統一血緣和跨所有資產的一致審計軌跡治理企業資料。現在，我們將相同的治理基礎設施擴充套件到AI系統接觸的每一個資產：LLM、MCP伺服器、技能和代理。已經知道誰能訪問你的客戶資料的目錄，現在也管理哪些代理可以呼叫哪些工具，以及在什麼條件下。

Unity AI Gateway是代理世界中的執法層。每一次模型呼叫、每一次工具呼叫、每一次代理互動都流經閘道器。每個請求在執行前都會根據Unity Catalog中定義的策略進行評估，並在執行後記錄。傳統治理工具是為靜態應用構建的，對此毫無可見性，而Unity AI Gateway則能做到。

支柱一：委託訪問

代理必須在明確定義的許可權邊界內執行，包括它們代表誰行動以及可以訪問什麼。大多數平臺像處理應用許可權一樣處理這個問題：使用靜態憑據和廣泛訪問的服務賬戶。這導致責任缺失，無法控制爆炸半徑。Databricks採用不同方法：身份從頭到尾流動，從提問的使用者到代理檢索的特定錶行。代理透過即時委託令牌傳遞繼承呼叫使用者的資料許可權，而不是共享服務賬戶。如果你無法訪問Unity Catalog中的表，代表你行動的代理也無法訪問。每個動作都根據兩個身份記錄：觸發請求的真實使用者和代表他們行動的代理，記錄訪問了哪些表、執行了什麼操作以及何時發生。

我們將此模型擴充套件到MCP伺服器。團隊在Unity Catalog中註冊外部MCP伺服器（如GitHub、Jira、Slack等），並像管理其他可安全物件一樣管理它們：許可權、憑據管理以及集中審計日誌。我們還認識到同樣的原則不僅適用於訪問時間，也適用於執行時。知道代理被允許呼叫GitHub並不能告訴你它是否應該刪除檔案或合併拉取請求。因此我們構建了服務策略，這些策略是UC函式，在UC中管理並附加到Unity Catalog中註冊的MCP上，控制哪些工具呼叫成功。每個工具呼叫在執行前都會根據工具名稱、引數或呼叫者身份進行評估，策略返回允許、拒絕或請求使用者同意。

在模型層面，護欄即時檢查流經推理的內容，掃描輸入以查詢PII和越獄嘗試，在輸出到達使用者前檢查幻覺和敏感內容。它們在每個請求上內聯執行並失敗關閉。許可權控制誰能呼叫什麼，服務策略控制特定工具呼叫是否應在給定請求的上下文中進行，護欄控制什麼內容流入和流出。

支柱二：以資料為中心的AI治理

大多數AI治理工具忽略了一個原則：代理的行為幾乎完全由其可訪問的資料決定。它能讀取什麼、資料有多新鮮、敏感欄位是否被遮蔽——這些不是AI治理問題，而是資料治理問題。分開處理會導致兩個不完整的系統，而統一處理則能使治理自我強化。

首先你需要完整的審計軌跡，監管使這成為必需。新興AI法規要求組織展示其AI系統做了什麼、得到了什麼以及產生了什麼。AI Gateway將每個模型呼叫的完整負載寫入推理表：確切提示、確切響應、令牌計數和延遲。Unity Catalog在審計日誌中捕獲每個訪問操作，包括哪個主體呼叫了什麼、來自哪個代理以及何時發生。兩者都以表的形式存入你的湖倉，可按你的意願保留。

其次，審計資料只有在你能夠分析時才有用。分析需要資料平臺，而不是日誌工具。代理軌跡是Unity Catalog中的表，可用與你用於其他一切相同的SQL查詢。沒有新查詢語言，沒有單獨工具。

第三，你需要知道代理依賴的資料是否可信。資料質量監控持續跟蹤整個目錄的新鮮度和完整性。將其與代理軌跡結合，你可以從“代理給出了錯誤答案”推進到“代理查詢了一個已被標記為過時的表”，將代理行為與底層資料質量聯絡起來。資料分類增加了另一層：AI系統持續掃描和標記敏感列（如PII、HIPAA和GDPR監管資料），這些標記直接反饋到訪問控制。無論哪個代理或框架請求，被遮蔽的列仍然保持遮蔽。你已有的資料治理自動成為你的AI治理。

支柱三：成本智慧

每次模型呼叫都有代價。大多數企業不知道誰在增加成本、為了什麼，或者是否有效，直到賬單到達，財務部門不得不解釋一個沒人預見到的數字。根本原因是缺少基礎設施：沒有檢視所有AI流量的計量層，沒有將其歸因於團隊或用例的標記系統，沒有與訪問控制並行的支出控制。我們將其構建到Unity Catalog和Unity AI Gateway中。使用跟蹤將所有請求記錄到使用表中，包括令牌計數、延遲、請求者身份和模型目標，無論模型是Databricks託管的還是外部提供商的，都在一個表中。它允許你按團隊、專案或成本中心標記請求。由於它像代理軌跡和業務資料一樣以表的形式儲存，你可以將成本與結果聯絡起來。

Unity AI Gateway中的預算增加了策略層。管理員為每個使用者或組設定月度支出閾值，並在消費接近或超過時收到警報——這是支出成為問題之前的訊號。硬執行是自然的下一步。

支柱四：開放和互操作

每個企業AI治理策略最終都會面對同樣的驅動力：新團隊選擇不同框架，新提供商釋出更好模型。如果你的治理內建於當前工具選擇中，你就處於跑步機上：每個新框架都是新整合，每個新模型都是新策略。我們認識到這一點，因此採取了不同於大多數治理工具的方法。治理不能只存在於代理層，還需要存在於代理訪問的資料和服務中，無論這些服務是否由Databricks管理。基於LangGraph和CrewAI的代理都查詢相同的Unity Catalog，呼叫相同的受治理MCP伺服器，並流經相同的AI Gateway。框架無關。治理隨資源而非呼叫程式碼流動。

開放標準使這具體化。MCP為代理提供通用工具連線協議：在Unity Catalog中註冊一次，從任何框架呼叫，具有相同的許可權和審計軌跡。Unity AI Gateway為Databricks託管模型、Azure OpenAI、AWS Bedrock和Anthropic提供單一受治理端點，跨提供商具有統一策略、審計軌跡和成本歸因層。MLflow跟蹤自動檢測LangChain、LlamaIndex、AutoGen、OpenAI SDK、Anthropic SDK等，軌跡以表形式存入Unity Catalog，無需每個框架自定義檢測。

最終結果是治理成為平臺的屬性，而不是你為每個新框架或模型重建的東西。你部署的每個代理，無論它是如何構建的或由哪個模型驅動，都訪問相同的受治理資源。