Unity Catalog を使用した AI エージェントの規模でのガバナンス

1年前、あなたの組織には十数個のAIエージェントがありました。今日では、数千個に増えています。

すべての開発者には、コーディングエージェントがあり、開発者と一緒にコードを作成、レビュー、出荷しています。あなたの分析チームは、予測エージェントを構築しました。営業部門は、リードスコアリングを展開しました。サポート部門は、チケットルーティングを自動化しました。マーケティングは、パーソナライゼーションを開始しました。財務部門は、照合ワークフローを構築しました。すべてのチームが機会を見出し、迅速に行動しました。

ここで、「どのエージェントが顧客のPIIにアクセスしていますか？」という質問が出されました。

その答えを得るには、数十のシステムからログをプルし、手動で相関させ、何も見落とされていないことを願う必要があります。各エージェントは、異なる方法でログを記録し、認証し、データにアクセスします。確認できる単一の場所がありません。

あるいは、逆の道を選んだかもしれません。すべてをロックダウンしました。広範なレビューなしには、エージェントは展開されませんでした。セキュリティは厳格に保たれました。しかし、今では、より迅速に行動した競合他社に半年遅れをとっています。開発者やユーザーは不満を抱いています。AIツールを実際に使用できる企業に転職した人もいます。

どちらの極端も機能しません。ガバナンスのないエージェントは、測定できないリスクを生み出します。ロックダウンされた環境は、別の種類のリスクを生み出します。それは、人材が流出する間に遅れをとることです。

従来のガバナンスは、人間が決定を下し、アプリケーションがそれらを予測可能に実行することを前提としていました。エージェントはそのようには機能しません。それらは自律的であり、毎回異なる選択をし、コードを読むだけでは予測できない方法でツールを連携させます。コードを読むだけで、エージェントが何をする可能性があるかをレビューしてガバナンスすることはできません。エージェントがアクセスできるものを制御し、実際に行っていることを監視することで、エージェントをガバナンスします。

エージェントガバナンスの4つの柱

Unity Catalogは、単一の権限モデル、統合されたリネージ、およびすべての資産にわたる一貫した監査証跡を通じて、2021年からエンタープライズデータをガバナンスしてきました。私たちは今、AIシステムが触れるすべての資産（LLM、MCPサーバー、スキル、エージェント）をカバーするために、同じガバナンスインフラストラクチャを拡張しています。すでに顧客データへのアクセス権を持つユーザーを把握しているカタログが、どのエージェントがどのツールを呼び出すことができるか、そしてどのような条件下で呼び出すことができるかをガバナンスするようになりました。

Unity AI Gatewayは、エージェントの世界の強制ファブリックです。すべてのモデル呼び出し、すべてのツール呼び出し、すべてのエージェントインタラクションは、ゲートウェイを通過します。それぞれが実行前にUnity Catalogで定義されたポリシーに対して評価され、その後ログに記録されます。従来のガバナンスツールは、静的アプリケーションのために構築されました。それらは、これらのいずれにも可視性がありません。Unity AI Gatewayは、それを行います。

Pillar 1: Delegated access

エージェントは、誰のために行動できるか、そして何にアクセスできるかの両方の観点から、明確に定義された権限の境界内で運用する必要があります。ほとんどのプラットフォームは、アプリケーションの権限を処理する方法でこれを処理します。つまり、静的な認証情報と広範なアクセス権を持つサービスアカウントです。これにより、アカウンタビリティが失われ、影響範囲を封じ込めることができません。

Databricksは異なるアプローチを採用しています。IDは、質問するユーザーからエージェントが取得する特定のテーブル行まで、エンドツーエンドで流れます。エージェントは、共有サービスアカウントではなく、on-behalf-ofトークンパスを介して、リアルタイムで呼び出し元のユーザーのデータ権限を継承します。Unity Catalogのテーブルにアクセスできない場合、その代理として行動するエージェントもアクセスできません。すべての操作は、両方のIDに対してログに記録されます。要求をトリガーした実際のユーザーと、その代理として行動したエージェントの両方に対して、どのテーブルがアクセスされたか、どの操作が実行されたか、いつ実行されたかがキャプチャされます。問題が発生した場合、アクションがどこから来たのか、誰がそれを承認したのかを正確に把握できます。

このモデルをMCPサーバーにも拡張します。チームは、外部MCPサーバー（GitHub、Jira、Slackなど）をUnity Catalogに登録し、他のセキュアブルと同様にガバナンスします。つまり、権限、認証情報管理、および1か所での完全な監査ログです。

アクセス時間だけでなく、実行時にも同じ原則が適用されることを認識しました。エージェントがGitHubを呼び出すことができることを知っていても、ファイルが削除されるのか、プルリクエストがマージされるのかはわかりません。そこで、UC関数であり、UCで管理され、Unity Catalogの登録済みMCPにアタッチされ、ツール呼び出しを制御するService Policiesを構築しました。すべてのツール呼び出しは、実行前に評価されます。ツール名、その引数、または呼び出し元のIDに基づいて、ポリシーは許可、拒否、またはユーザーの同意を求めます。ポリシー評価の結果が「拒否」の場合、呼び出しはブロックされます。

モデルレイヤーでは、ガードレールがリアルタイムの推論を通過するものを検査し、PIIやジェイルブレイクの試みをスキャンし、ユーザーに到達する前に幻覚や機密コンテンツをチェックします。それらはすべてのリクエストでインラインで実行され、クローズフェイルします。

実際には、これらの3つのレイヤーは連携して機能します。権限は、誰が何を呼び出すことができるかを制御します。サービスポリシーは、特定のツール呼び出しが指定されたリクエストのコンテキストで続行されるべきかどうかを制御します。ガードレールは、どのコンテンツが出入りするかを制御します。

Pillar 2: Data-centric AI governance

AIガバナンスツールのほとんどが見落としている原則があります。それは、エージェントの動作は、アクセスできるデータによってほぼ完全に決定されるということです。エージェントが読み取れるもの、そのデータの鮮度、機密フィールドがマスクされているかどうかは、AIガバナンスの質問ではありません。それらはデータガバナンスの質問です。それらを別々に扱うと、2つの不完全なシステムができあがります。それらを一緒に扱うと、ガバナンスは自己強化されます。

まず、完全な監査証跡が必要です。規制により、これは交渉の余地がなくなっています。新しいAI規制では、組織はAIシステムが何をしたか、何を与えられたか、そして何を生み出したかを証明する必要があります。AI Gatewayは、すべてのモデル呼び出しの完全なペイロードをinference tablesに書き込みます。つまり、送信された正確なプロンプト、返された正確な応答、トークン数、およびレイテンシです。Unity Catalogは、どのプリンシパルが何を呼び出したか、どのエージェントから、いつ呼び出したかを含む、すべてのアクセス操作を監査ログにキャプチャします。どちらもレイクハウスにテーブルとして着地し、あなたの条件で保持されます。ほとんどのロギングアーキテクチャでは、完全性とコストのトレードオフを強制され、サンプリング、フィルタリング、および短い保持期間の設定が必要になります。Unity AI Gatewayは、レイクハウスでオブザーバビリティデータをキャプチャするため、それを行う必要はありません。

次に、その監査データは、分析できる能力と同じくらいしか役に立ちません。分析には、ロギングツールではなく、データプラットフォームが必要です。エージェントトレースはUnity Catalogのテーブルであり、他のすべてのものに使用するのと同じSQLでクエリできます。新しいクエリ言語や別のツールは不要です。エージェントが予期しないことをした場合、調査するためのデータはすでにそこにあります。先週特定のサービスにアクセスしたエージェント、各チームが推論にいくら費やしているか、そしてエージェントが認証情報やPIIに触れたかどうか。監査データはビジネスデータの隣にあるため、さらに進んで、エージェントの動作をビジネス成果と結合して、エージェントが何をしたかだけでなく、それが機能したかどうかを理解できます。Lakewatchは、セキュリティレイクハウス上に構築されたDatabricksのエージェントSIEMであり、これをさらに進め、同じ監査証跡をアクティブなセキュリティインテリジェンスに変換します。つまり、レイクハウス上に構築されたAI駆動の脅威検出と応答です。攻撃者はエージェントを使用しています。防御者もそうすべきです。

まず、エージェントが最初に参照したデータが信頼できるものであることを知る必要があります。完全な監査証跡は、エージェントが何にアクセスしたかを示しますが、そのデータがどれほど優れていたかまでは示しません。 データ品質モニタリングは、カタログ全体の鮮度と完全性を継続的に追跡します。これをエージェントのトレースと結合すると、「エージェントが間違った回答をした」から「エージェントが古いとフラグ付けされたテーブルにクエリを実行した」というレベルに移行し、エージェントの動作をその下のデータの品質に結び付けます。 データ分類はさらにレイヤーを追加します。エージェントAIシステムは、PII、HIPAA、GDPR規制データなどの機密列を継続的にスキャンしてタグ付けし、それらのタグはアクセス制御に直接フィードされます。マスクされた列は、どのエージェントまたはフレームワークが要求しても、マスクされたままになります。既存のデータガバナンスは、自動的にAIガバナンスになります。

Pillar 3: Cost intelligence

すべてのモデル呼び出しには価格があります。ほとんどの企業は、請求書が届き、経理部門が誰も予期しなかった数字を説明するまで、誰がそれらを実行しているのか、何のために実行しているのか、またはそれが機能しているのかどうかさえ知りません。

根本原因は、壊れたプロセスではありません。それはインフラストラクチャの欠如です。すべてのAIトラフィックを1か所で見えるようにするメータリングレイヤーがなく、チームやユースケースに帰属させるためのタグ付けシステムがなく、同じリソースを制御するアクセス制御の隣に配置される支出制御がないのです。

これらをUnity CatalogとUnity AI Gatewayに組み込みました。 使用状況追跡は、トークン数、レイテンシ、要求者ID、Databricksホストおよび外部プロバイダー全体のエージェントのモデル宛先を含むすべての要求を単一のテーブルに使用状況テーブルに記録します。これにより、要求をチーム、プロジェクト、またはコストセンターごとにタグ付けできます。エージェントのトレースやビジネスデータと一緒にテーブルとして保存されるため、コストと成果を結び付けることができます。200ドルかかり、50Kドルの適格なパイプラインを生成するエージェントは、お買い得です。200ドルかかり、古いデータをループでクエリするエージェントは無駄です。コストと成果を結合しないと、違いを判断できません。

予算はUnity AI Gatewayでポリシーレイヤーを追加します。管理者は、ユーザーまたはグループごとに月間支出しきい値を設定し、消費量がそれに近づいたり超過したりするとアラートを受け取ります。これは、問題が発生した後ではなく、発生する前に必要なシグナルです。ハードエンフォースメントは自然な次のステップであり、それについては近日中にさらに共有する予定です。

Pillar 4: Open and interoperable

すべてのエンタープライズ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に配置します。

最終的な結果は、ガバナンスがプラットフォームのプロパティになり、各新しいフレームワークやモデルのために再構築する必要がなくなることです。デプロイするすべてのエージェントは、どのように構築されたか、またはどのモデルによって駆動されているかに関係なく、同じガバナンスされたデータ、同じビジネスロジック、同じ権限にアクセスします。ルールを一度定義すれば、後から来るすべてのエージェントが自動的にそれを取得します。

Learn more

AIガバナンスを正しく行う企業は、インシデントを回避するだけではありません。彼らは、チームがその下のインフラストラクチャを信頼しているため、そうでない企業よりも速く進むでしょう。そして、信頼は、他のすべてを遅くする摩擦を取り除きます。

これに向けて構築している場合は、AIエージェントのガバナンスに関する無料コースから始め、Databricks AI Security Framework (DASF)をダウンロードし、追加のリソースについてはAIガバナンスのWebページをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事