ソートリーダー

AIエージェントを統治するためのアーキテクチャ的シフト

mm
Unite.AI を Google の優先ソースに追加
A photorealistic widescreen image of a technician viewed from behind, seated at a dark command center with multiple monitors. A large glass wall in front of him displays a complex, glowing architectural blueprint made of blue and green light. The hologram features intricate pathways, interconnected nodes, and two small silhouettes of figures standing together, representing a human and an AI

AIは、単にテキストを生成するチャットボットではありません。企業環境では、AIエージェントは、機密データの取得、ワークフローのトリガー、ツールの呼び出し、システム全体でのアクティビティのログ記録などのアクションを実行しています。自律性は、統治に関する議論を完全に変えます。人間のユーザーと従来のアプリケーション向けに設計された最初のコントロールと手順は、実行時にはマルチステップのアクションを実行できるソフトウェアを統治するために構築されていませんでした。

リスクは理論的なものではありません。可視性、 アクセス制御、監査可能性の小さなギャップは、検出が困難で、さらに逆転が困難なランタイムの故障に急速に蓄積する可能性があります。

この新しい時代に追いつくには、AIエージェントの統治は、さらに多くのポリシードキュメントを追加することによって実行できません。設計による統治が必要です。つまり、コントロールプレーンにコントロールを埋め込み、ランタイムで継続的に適用するアーキテクチャ的なアプローチです。エージェントがデジタルコラボレーターのように行動する場合、彼らは人間と同じ企業のガイドラインを継承し、さらに強力なランタイムの監視を受ける必要があります。

収束の時代に統治が崩壊する理由

企業アーキテクチャは、収束の時代に入りました。データとワークロードは、複数のクラウド、プライベートデータセンター、エッジ環境にまたがっています。

複数のプロセスを同時に管理するために、並行システムでプラットフォームを実行している組織があります。これには、別々のアイデンティティシステム、ログパイプライン、カタログ、承認プロセスが含まれます。結果は、ある種の「フランケンシュタインのプラットフォーム」であり、統合オーバーヘッドは、新しいツールまたはクラウド環境ごとに増加します。実際、この断片化は、日常の現実に現れています。

最近の調査によると、47%の回答者は、複雑なアクセス要件とプロセスを、44%の回答者は、データの所在に関する可視性の欠如を、データを効果的に使用するための障害として挙げています。

これは、エージェントがシステム間のシームを暴露する場所です。

ビジネス上の質問に答えるために、エージェントは、オンプレミスERPシステム、クラウドCRM、別のクラウドの運用テレメトリ、コラボレーションスイートのドキュメントからデータを取得する必要がある場合があります。組織が各場所でポリシーを異なる方法で適用する場合、エージェントは失敗するか、または説明または制御できない方法で成功する可能性があります。

これは、企業のリーダーが注意を払うべき瞬間です。エージェントは、環境全体にわたる一貫性とランタイムでの説明責任を要求する、より高い基準を強制しています。

統治は、この理由で、規制当局やセキュリティ機関によってスポットライトに照らされています。例としては、NIST AIリスク管理フレームワークがあります。これは、AIライフサイクル全体にわたるリスク管理を強調しており、ビルド時のみではありません。これは、コンプライアンスと信頼性は、運用上の責任であり、一時的なチェックリストではないことを思い出させるものです。

ポリシーからプラットフォームへ

設計による統治とは、統治がワークロードとともに移動し、各シロに再実装されないことを意味します。実践では、これは3つの構成要素に依存しています:

  • 統一されたコントロールプレーン

アイデンティティ、 アクセス、ポリシー、カタログ、エンタイトルメントをクラウドとデータセンター全体で定義および適用するための1つの場所。

目標は、ポリシーを1回書き込み、データとモデルが実行されるどこにでも適用することであり、システムごとにコントロールシステムを再構築するのではなく、エージェントの動作のドリフトを防ぎます。ここで、エージェントは1つの環境では安全に動作しますが、別の環境では危険に動作します。

実用的なテストはシンプルです。ユーザーが列にアクセスできない場合、ユーザーを代理するエージェントもアクセスできないことを確認する必要があります。これは、書き込まれたポリシーがコントロールプレーン全体で適用されているかどうかを示すはずです。

  • オープン標準に基づくデータファブリック

エージェントは、動作するためにコンテキストが必要です。コンテキストがさまざまな構造に分散し、さまざまなチームが所有している場合、データファブリックは、エージェントが各データセットごとに新しいルールセットを学習する必要がないように、セマンティクスとアクセスパターンを標準化するのに役立ちます。

Apache Icebergのようなオープンテーブル形式は、Apache Icebergをサポートすることでこれを実現し、複数のエンジンが管理されたデータを共有できるようにします。データの複製は、統治が通常失敗する場所です。チームが「エージェントに必要なものだけ」をコピーし始めると、新しい、より制限のない環境を作成します。

エージェントがデータセット全体で新しいアクセスギャップを導入せずに動作できる場合、統治は意図したとおりに機能しています。

  • リアルタイムの可視性とプロバンス

エージェントは、ランタイムで可視化できる場合にのみ統治できます。

ここでの可視化は、「望ましい」ものではなく、ランタイムコントロールとインシデントレスポンスの基盤です。

具体的には、エージェントのアクションのエンドツーエンドの証明が必要です。エージェントは、アクセスしたデータや呼び出したツールなど、アクションを証明できなければなりません。そこから、プロバンスは出力と入力の間に関連性を結び付けることができます。チームは、必要に応じて、決定を監査し、障害をトラブルシューティングすることができます。つまり、全体的なコンプライアンスを証明することになります。

エージェントを「デジタルコラボレーター」として扱う

最も役立つ精神モデルは、エージェントをデジタルコラボレーターとして扱うことです。

ここでは、その分解を示すための比較があります。従業員は、アクセスバッジを持っており、特定の建物や部屋への入場が許可されますが、他の建物や部屋への入場は許可されません。統治により、エージェントは制限付きのアクセスを持ちます。1つの重要な追加は、エージェントが状況に応じて、開示することが許可されているものを認識する必要があることです。

サポートエージェントを考えてみましょう。問題を解決するために、以前のサポートケースにアクセスする必要があるかもしれませんが、他の顧客のプライベート詳細を漏らすことはできません。言い換えると、エージェントは制限付きの知識を使用して推論できますが、開示の境界を強制する必要があります。これは、歴史的にナビゲートしてきた「プロンプトの書き込み」問題ではありません。むしろ、これはアイデンティティとランタイムの適用の問題です。

2026年に何が変わるのか:エージェントが実験から本格的な運用に移行する

2026年は、実験が終了し、エージェントが本格的な運用に移行する年です。

この移行により、企業は2つの速度で運営する必要があります。1つはイノベーションの速度であり、チームは新しいモデル、ツール、エージェントのワークフローをテストして競争上の優位性を得る必要があります。もう1つは、セキュアな速度であり、システムはコンプライアンスと運用上の要件を満たす必要があります。これには、厳格なアクセス制御と盲点が含まれる場合があります。

アーキテクチャ的な統治がなければ、これら2つの速度は衝突します。

チームがエージェントを統治する前に展開すると、パッチワークのコントロールと運用上の障害が発生します。逆に、セキュリティがすべてをブロックし、イノベーションが統治を損なう影のITに移行します。

目標は、速度を選択することではありません。両方をサポートするアーキテクチャを構築することです。

エージェントのランタイムでの統治のための実用的なチェックリスト

  • エージェントを構築またはスケーリングしている場合、統治が真正にアーキテクチャ的なものであるかどうかを明らかにするために、次の質問を自分に問いかけることが重要です。エージェントが回答またはアクションを生成するためにアクセスしたデータを、エンドツーエンドで説明できますか?
  • アクセス決定は、ハイブリッド環境全体で一貫していますか? それともプラットフォームごとに異なりますか?
  • エージェントのアクション、ツールの呼び出し、ポリシーのチェック、人間のエスカレーションに関するテレメトリがありますか?
  • エージェントが予期せずに動作した場合、ランタイムでエージェントをスロットル、停止、または隔離できますか?
  • 規制上の義務とリスクへの姿勢に一致するポスト展開の監視計画がありますか?

これらの質問に答えることができない場合、エージェントの展開を本格的な運用のインシデントとして扱う必要があります。

統治のシフトはアーキテクチャ的なものでなければならない

エージェントは、企業運営の標準的な追加機能になります。質問は、エージェントが企業運営の信頼できる部分になるかどうかです。

エージェントが人間やミッションクリティカルなソフトウェアと同じレベルの自信で統治されていない場合、結果は現実的になります。データ漏洩、コンプライアンスの失敗、運用上の停止、AIプログラムへの信頼の喪失など、影響が見られるでしょう。

リーダーは、エージェントの統治を文書化の演習として扱うのを止める必要があります。プラットフォームの機能が拡大するにつれて、エージェントの統治は、他の役割の監視を担うものの1つになるはずです。これには、コントロールプレーンにコントロールを埋め込み、アクションを可視化し、決定を監査可能にすることが含まれます。次に、拡大します。

これが、エンタープライズを壊すことなく迅速に動作するエージェントを取得する方法です。

セルジオ・ガゴは、ClouderaのCTOであり、AI/ML、量子コンピューティング、データ駆動型アーキテクチャにおける20年以上の経験を持っています。モディーズ・アナリティクスのAI/ML&量子コンピューティングの元マネージング・ディレクターであり、楽天、Qapacity、ジニオでのCTO役職も経験しています。セルジオは、信頼できるデータインフラストラクチャの強力な支持者であり、AIは2030年までに企業のオペレーティングシステムに進化することを信じています。