エンタープライズAIエージェントのガバナンスは、ポリシーから実行時制御へ移行している
エンタープライズAIエージェントのガバナンスは、最初の運用上の壁を越えた。現実世界で自律的に行動するソフトウェアを、ポリシー文書だけで統制することはできない。新たなモデルでは、エージェントがデータを送信し、レコードを変更し、ツールを呼び出し、あるいは資金を支出する直前の時点に、統制を組み込む。
この転換こそ、最近の行動時点での統制という論点の中核をなす主張である。ガバナンスはもはや、モデルの承認、リスクの文書化、導入後の出力レビューだけを指すものではない。実行時のセキュリティ問題へと変わりつつある。
この圧力は、セキュリティチーム、アイデンティティプロバイダー、アプリケーション所有者、そしてエージェントプラットフォームを構築するすべてのベンダーに及ぶ。対立点は明確だ。企業はより少ない監督でエージェントに長いワークフローを完遂させたい一方、セキュリティチームは、影響の大きいすべての行動が追跡可能で、取り消し可能であることを求めている。
これは、人工知能にルールが必要かどうかをめぐる新たな議論ではない。より差し迫った問いは、そのルールをどこで機能させるべきかだ。自律システムの場合、その答えは行動そのものに限りなく近い場所にある。
エンタープライズAIエージェントのガバナンスで変わったこと
統制の対象は、もはや単なるモデルやアプリケーションではない。ツール、メモリ、権限、そして変化するコンテキストを備えた、行動するアイデンティティである。
従来のAI監督は、比較的安定した一連の流れに焦点を当てる。人が入力を送信し、モデルが出力を生成し、誰かがその出力を確認または利用する。ガバナンスでは、モデル、学習データ、想定用途、評価結果、生成コンテンツを検証できる。
AIエージェントは、この流れを変える。目標を複数のステップに分解し、ツールを選び、情報を取得し、外部サービスを呼び出し、システムを変更できる。また、目標が達成されたと判断するまで、このプロセスを繰り返すこともできる。
各ステップは、次のステップのリスクを変化させ得る。顧客フィードバックを要約するだけの無害な依頼も、エージェントが顧客データベースを開けば、より機微なものになる。レコードをエクスポートし、メッセージを下書きし、レビューなしで送信する場合には、リスクはさらに変わる。
これにより、設計時の承認と実行時の振る舞いの間に隔たりが生まれる。ガバナンス委員会は営業支援用のエージェントを承認できるが、そのラベルから特定のデータベースクエリについて分かることはほとんどない。また、役員アカウントから午前2時に特定のメールを送るべきかどうかも判断できない。
NIST AIフレームワークは、AIリスクを統治、マッピング、測定、管理するための広範な枠組みを組織に提供している。この枠組みは依然として有用だが、エージェントの存在により、チームはその原則をはるかに細かい粒度で実装する必要に迫られている。
アプリケーション全体に付与されたリスク分類では、実行時のすべての問いに答えられない。システムは、誰がタスクを依頼したのか、どのエージェントが行動しているのか、どのデータにアクセスしたのか、どのツールを選択したのかを把握しなければならない。また、要求された行動がユーザーの権限を超えていないかも知る必要がある。
これが、行動時点でのガバナンスの実践的な意味である。制御機構は、現在のアイデンティティ、権限、データ、環境シグナルを用いて、試行される行動を評価する。そして、その行動を許可、ブロック、制限、またはエスカレーションする。
資金移動の前に人による承認を求めることもある。情報がモデルに届く前に、機微なフィールドをマスキングすることもある。同じエージェントが社内向け下書きを作成できたとしても、外部アドレスへのメール送信を防ぐことも可能だ。
こうした判断は、実行中に行われなければならない。四半期ごとのポリシーレビューでは、危険なAPI呼び出しを止められない。導入後の監査はインシデントを説明できるが、最初の行動を防ぐことはできない。
この転換は、何を証拠と見なすかも変える。組織には、エージェントが承認されたことを示す記録以上のものが必要になる。元の依頼と、モデルの判断、ツール呼び出し、取得データ、承認、最終結果を結び付けるログが求められる。
この連鎖は、エージェントが複数のサービスにまたがって稼働する際に重要となる。あるワークフローはチャットインターフェースで始まり、契約書を取得し、顧客レコードを更新し、支払い依頼を作成するかもしれない。移行のたびに、権限が拡大したりコンテキストが失われたりする場所が新たに生じる。
行動時点でのガバナンスでは、こうした移行をセキュリティ境界として扱う。このアプローチは、承認済みのエージェントがワークフロー全体を通じて安全であり続けるとは仮定しない。意味のある各行動が、当初の目的と委任された権限に引き続き適合しているかを検証する。
静的なAIポリシーが実行時に統制を失う理由
文書化されたポリシーは許容される行動を示すが、自律的なワークフローには、影響の大きい各ステップの前に実行可能な判断が必要だ。
静的なガバナンスは、システムが予測可能に振る舞う場合に最も有効である。チームは承認済みの用途を定義し、機微な入力を禁止し、固定されたワークフローをテストし、従業員を教育できる。しかし、エージェントが接続されたツール群を通る経路を自ら選択する場合、これらの対策の信頼性は下がる。
エージェントは、許可された目標から始めても、許容されない行動を生み出す可能性がある。指示を誤解したり、文書から取得した悪意あるコンテンツに従ったり、個別には無害な権限を組み合わせたりすることがある。その結果として生じる能力は、単一の権限から想定される範囲を超え得る。
プロンプトインジェクションは、この問題をよく示している。敵対的な指示は、エージェントが取得するウェブページ、メール、文書、サポートチケットの中に現れる可能性がある。そのコンテンツは、元の目標を無視し、情報を開示し、別のツールを有効化するようエージェントに指示する。
従来型のフィルターは、ユーザーの最初のプロンプトを検査しても、危険な内容を見つけられないことがある。有害な指示は、ワークフロー開始後に後から入り込む。そのため、ガバナンスはコンテキストの変化を通じてエージェントを追跡しなければならない。
OWASPのエージェント型AIガイダンスは、過剰な自律性、ツールの悪用、メモリ操作、連鎖的障害、侵害されたエージェント間連携に関するリスクを説明している。これらは、単に望ましくないテキスト出力ではなく、実行時のリスクである。
過剰な自律性は、エージェントがタスクに必要な以上の権限を与えられたときに発生する。スケジューリング支援エージェントには、カレンダーを読み、会議候補時刻を提案する権限が必要かもしれない。しかし、予定を無制限に削除したり、外部参加者を招待したり、すべての非公開添付ファイルを読んだりするアクセスは、通常必要ない。
ワークフローが動的になると、この区別は一見単純でも難しくなる。あるタスクでは一時的なアクセス拡張が正当化される一方、別のタスクでは不要かもしれない。恒久的に広範な権限を与えれば運用上の問題は解決するが、常設のセキュリティリスクを生む。
実行時制御は異なるアプローチを提供する。システムは、タスクとそのコンテキストを評価した後、限定的で一時的な認可を発行できる。その認可は1回の行動後に失効させることも、要求される範囲が変わった場合に承認を求めることもできる。
同じ原則はデータにも当てはまる。四半期サマリーを作成するエージェントには、集計済みの売上情報は必要かもしれないが、すべての顧客の個人記録までは不要である。データソースに近い制御機構は、モデルが目にする前に、エージェントが取得できる情報を制限できる。
これは、モデルレベルの安全対策が1つの層にすぎないため重要である。モデルに機微な情報を明かさないよう指示できても、指示は競合したり失敗したりする可能性がある。データ最小化とツール認可は、モデルの振る舞いが信頼できなくなった場合の影響を抑える。
実行時アプローチはまた、低リスクの推論と高リスクの実行を分離する。エージェントは、実行する権限を受け取らずに、選択肢を分析し、推奨案を下書きし、行動をシミュレーションできる。権限は、ワークフローが制御された境界に到達したときにのみ付与される。
人による承認は依然として重要だが、万能の答えにはなり得ない。すべてのツール呼び出しに承認を求めれば、エージェントが約束する効率性の大部分が失われる。また、人々がコンテキストを確認せずに要求を承認する、承認疲れを招く可能性もある。
優れたガバナンスは、意味のある閾値に介入を限定する。公開された製品ページの閲覧は自動的に進められるかもしれない。一方、顧客レコードのエクスポート、本番コードの変更、資金送付には、より強い確認を求めるべきである。
正確な境界は、組織とタスクによって異なる。しかし仕組みは一貫している。行動、その対象、実行主体、潜在的影響を評価する。そして、正当な業務の継続を可能にする最も限定的な権限を適用する。
NISTの生成AIプロファイルは、AIライフサイクル全体にわたるリスク管理を強調している。エージェント型システムは、そのライフサイクルを即時の影響を生み得る一連の判断へと拡張する。
そのため、ガバナンスはルールブックを発行する行為ではなく、認可システムを運用する行為に近づいている。ポリシーは依然として、何が起こるべきかを定義する。実行時制御は、そのポリシーを、結果が現実になる前に行われる技術的な判断へと変換する。
アイデンティティはAIエージェントのコントロールプレーンになる
エージェントには、明確に追跡可能な固有のアイデンティティが必要だ。従業員の認証情報を借用すると、説明責任が失われ、下流のあらゆる制御が弱まるためである。
初期段階のエージェントの多くは、人間のユーザーが既に持つアカウントを通じて動作する。エージェントはセッション、APIトークン、あるいはサービス認証情報を継承する。この設計はプロトタイプを容易にするが、調査やアクセスレビューの際に曖昧さを生む。
システムログには、従業員がファイルをダウンロードしたと記録されるかもしれない。しかし、その人物が実際にダウンロードをクリックしたのか、承認済みのエージェントが取得したのか、侵害されたワークフローがそのアカウントを通じて行動したのかは分からない可能性がある。認可記録には実際の行為者が欠けている。
エージェント専用のアイデンティティは、この問題の一部を解決する。管理者はエージェントに権限を割り当て、その振る舞いを監視し、人間のスポンサーを無効化することなくアクセスを取り消せる。また、ポリシーによって人間の行動と機械の行動を区別することも可能になる。
ただし、このアイデンティティは責任を負う人物または業務プロセスと結び付いていなければならない。そうでなければ、組織は明確な所有者のいないマシンアカウントを増やしてしまう。休眠状態のエージェントは、元のプロジェクトが終了した後もアクセス権を保持し続ける可能性がある。
Microsoftは、エージェントの発見、統制、保護のためのアイデンティティ層としてAgent ID controlsを提示している。この方向性は、より広範な業界の結論を反映している。エージェントには、他の非人間アイデンティティに匹敵するライフサイクル管理が必要だということだ。
セキュリティチームは可視化できないエージェントを統制できないため、まずは発見が必要になる。事業部門は、ソフトウェアプラットフォーム、ローコードシステム、開発フレームワーク、クラウドサービスの中でエージェントを作成できる。各経路は、新たなアイデンティティ、トークン、または統合を生み出し得る。
登録時には、エージェントの所有者、目的、環境、承認済みツール、想定されるデータアクセスを記録すべきである。また、そのエージェントが自動的に行動できるのか、確認を必要とするのかも記録する必要がある。こうした属性は、実行時システムに認可の基盤を与える。
認証は、呼び出し元が登録済みのエージェントであるかを確認する。認可は、そのエージェントがこれらの条件下でこの行動を実行できるかを判断する。チームが最初の問いだけを解決し、2つ目の問いに対して広範かつ永続的なアクセスを付与すると、ガバナンスは機能しなくなる。
コンテキストにより、認可の精度は高まる。ポリシーは、要求するユーザー、デバイスの状態、データ分類、送信先、取引金額、直近のエージェント行動を評価できる。そのうえで、エージェント全体を再定義することなく、異なる制御を適用できる。
アシスタントは通常業務中、従業員本人の会議メモを読み取れる場合がある。しかし、別部門の制限付きファイルを対象とする同じ要求には、より厳密な審査が必要だ。突発的な大量ダウンロードは、1件の文書を取得する場合とは異なる扱いを受けるべきである。
メモリは、もう一つのアイデンティティ上の問題をもたらす。エージェントは、タスク履歴、設定、取得した事実、中間判断を保存できる。このメモリは元のユーザーセッション終了後も残り、別の要求に対する将来の行動に影響を及ぼす可能性がある。
チームは、誰のアイデンティティがそのメモリを所有し、誰が変更できるのかを把握する必要がある。また、保存された情報の出所とその変化を記録するプロベナンスも必要だ。プロベナンスがなければ、汚染されたメモリが後続のワークフローを気付かれないまま別の方向へ導くおそれがある。
ナレッジシステムは、情報源の境界とアクセス制御を維持することで、より安全な検索を支援できる。エンジニアリング向けナレッジベースは、エージェントが現在の要求者にアクセス権のある文書だけを受け取る場合に、最も有用になる。
マルチエージェントのワークフローでは、アイデンティティの重要性がさらに増す。あるエージェントが別のエージェントに調査を委任し、その後、第三のエージェントにシステム更新を依頼することもある。受信側のサービスは、委任された権限がその連鎖をまたいでも有効かどうかを把握しなければならない。
委任によって、意図せず新たな権限が生まれてはならない。最初のエージェントに支払い承認の権限がなければ、委任先のエージェントもその能力を得るべきではない。あらゆる権限移譲で、元の制限、目的、有効期限を維持する必要がある。
この要件はアイデンティティセキュリティで確立された考え方に似ているが、エージェントには特有の速度と規模がある。人間は1回のセッションで数件の機密性の高い操作を行うかもしれない。自動化エージェントは、レビュー担当者が気付く前に、複数のシステムをまたいで多数の操作を開始できる。
したがってコントロールプレーンは、アイデンティティをレート制限、行動監視、取引ポリシーと組み合わせなければならない。アイデンティティは、誰が行動したのかを組織に示す。ランタイムガバナンスは、その主体に継続を許可すべきかどうかを判断する。
実行時点での制御には固有のトレードオフがある
ランタイムでの強制は無制限の権限を抑える一方、レイテンシー、ポリシーの複雑さ、統合リスク、そして攻撃者の標的になり得る新たな制御点をもたらす。
ガバナンスをめぐる最も強い主張は、一見すると過度に完全に聞こえる。すべてのエージェントにアイデンティティを付与し、各行動を評価し、すべての判断を記録し、危険な操作には承認を求める。しかし実際には、各要素が失敗し得る。
第一の制約はポリシーの質だ。ランタイムエンジンは、チームが明確なルールへと落とし込んでいない意図を強制できない。「機密」「適切」「重要」「信頼できる」といった言葉には、部門ごとに異なる事業上の判断が求められることが多い。
ルールが広すぎれば、危険な操作が可能なまま残る。厳しすぎれば正当な業務を妨げ、従業員がシステムを迂回することを促す。組織は、抽象的なリスク分類だけでなく、実際のワークフローに基づいてポリシーを調整しなければならない。
コンテキストが不完全な場合もある。セキュリティサービスは、そこに至った会話を理解しないままAPIリクエストを見るかもしれない。モデルゲートウェイはプロンプトを理解しても、対象システムにおけるデータ分類の情報を持たない可能性がある。
攻撃者はその隙を悪用できる。禁止された目的を、複数の許可済み操作に分割することがある。各ステップは個別に調べれば無害に見える一方、全体としては不正な結果を生み出す。
シーケンスを認識する制御は一部のパターンを検出できるが、より豊富な状態情報と長期の保持を必要とする。それはプライバシーと運用面の懸念を生む。詳細なトレースには、従業員からの要求、顧客データ、モデル出力、機密の事業判断が含まれる可能性がある。
組織は、監視対象のシステムと同じくらい慎重にガバナンステレメトリーを保護しなければならない。侵害されたログは攻撃を隠したり、ユーザーに誤った嫌疑をかけたりする可能性がある。公開されたトレースは、制御が保護するために設計された情報そのものを露出させかねない。
パフォーマンスも別のトレードオフをもたらす。エージェントは1つのタスクを完了する間に、多数の小さなツール呼び出しを行うことがある。すべての呼び出しを複数のポリシーエンジンに通せば、遅延、コスト、追加の障害点が増える。
リスクベースの強制は、その負担を軽減できる。影響が小さく、元に戻せる操作には軽量なチェックを適用する。影響が大きい、または取り消せない操作には、より強力な認可、詳細なログ、人によるレビューを適用する。
この区別には慎重な分類が必要だ。下書きを社内レビューキューへ送ることは元に戻せる。同じテキストを顧客に公開することは、そうではない。1件の顧客レコードを読むことと、データベース全体をエクスポートすることも異なる。
エージェントは、モデルの更新後に異なる挙動を示すこともある。新しいモデルは別の順序でツールを選択し、異なる引数を生成し、より多くのステップを試みる可能性がある。既存のポリシーは新しい挙動をブロックしたり、新たに導入された経路を見逃したりするおそれがある。
そのため、継続的なテストはガバナンスの一部となる。チームは、更新されたモデル、ツール、ポリシーに対し、代表的なワークフローを再生すべきだ。テストには、敵対的な文書、曖昧な指示、取り消された権限、利用できないサービスを含める必要がある。
相互運用性は、別の不確実性を加える。業界では、エージェントによる機能の発見とシステム間通信を支援するプロトコルの開発が進んでいる。Googleは、異なるフレームワークで構築されたエージェント間の連携を支援するため、Agent2Agent protocolを導入した。
相互運用性は統合作業を減らせる一方、信頼関係を拡大する。ローカルエージェントは、リモートエージェントが示す能力、アイデンティティ、完了した作業の説明に依存する可能性がある。その主張には技術的な検証が必要だ。
共有プロトコルがあっても、共有ガバナンスが自動的に成立するわけではない。組織には依然として、委任されたタスクの受け入れ、機密コンテキストの送信、返却結果の検証に関するルールが必要だ。どのリモートエージェントを各信頼境界の内側に置くかも決めなければならない。
ベンダー集中も関連するリスクである。1つのアイデンティティまたはポリシープラットフォームがすべてのエージェント操作を仲介する場合、障害によって重要なワークフローが停止する可能性がある。設定ミスにより、組織全体がブロックされたり、大規模に過剰なアクセスが付与されたりすることもある。
チームは導入前にフォールバック動作を用意する必要がある。一部の操作は、制御が利用できない場合にシステムがブロックする「フェイルクローズ」とすべきだ。ほかの低リスク操作は、より厳しい制限と強化されたログ記録のもとで継続できる場合がある。
したがって、実行時点のガバナンスは保証ではなく、多層防御として扱うべきである。制限されたツール、最小限のデータアクセス、隔離された実行、出力検証、監視、インシデント対応と組み合わせたときに最も効果を発揮する。
懐疑的な結論は明快だ。制御を実行に近づけることで、組織の被害防止能力は向上する。しかし、自律的な挙動を予測可能にするわけでも、設計時レビューの必要性をなくすわけでもない。
負担はセキュリティチームにとどまらない
AIエージェントのガバナンスは、セキュリティチームがワークフローの外部から追加できない制御を、アプリケーションベンダーと事業責任者に公開するよう求める。
セキュリティチームはアイデンティティとネットワークアクセスを管理できるが、アプリケーションにおけるビジネス上の意味を常に理解できるとは限らない。フィールドを変更するAPI呼び出しは、返金の承認、文書の公開、顧客アカウントの閉鎖を意味する可能性がある。
アプリケーションベンダーは、重要な結果を伴う操作を分類し、その周囲に認可ポイントを公開しなければならない。また、ポリシーシステムがプレビューと確定操作を区別できるだけのコンテキストを返す必要がある。その詳細がなければ、強制は粗いものにとどまる。
エージェントプラットフォームの提供者にも同様の責務がある。計画ステップ、ツール選択、引数、応答、承認について、永続的な記録を保持する必要がある。セキュリティチームは、制限のない思考過程データを公開することなく、それらの記録を検索できなければならない。
モデル提供者は、安全対策、評価、予測可能なツール利用の挙動に引き続き責任を負う。ただし、すべての顧客の認可ポリシーを決定することはできない。同じモデル操作でも、ある環境では無害であり、別の環境では禁止される可能性がある。
その区別を定義するのは事業責任者だ。財務責任者は、どの取引で職務分掌が必要かを知っている。人事チームは、どの従業員記録により厳格なアクセス制御が必要かを知っている。法務チームは、生成された下書きが正式なコミュニケーションになるタイミングを知っている。
次に開発者が、これらの要件を技術的な境界へと変換する。エージェントが呼び出せるツール、指定できるパラメータ、受け取れる応答を決める。また、制御がステップを拒否した場合に何が起きるかも定める。
この責任分担は、どの参加者も単独では問題を解決できないため、負担を生む。アイデンティティプラットフォームには完全なタスクの意味がない。アプリケーションベンダーには完全な組織コンテキストがない。モデル提供者には顧客ポリシーに対する権限がない。
最も弱い統合が、チェーン全体を損なう可能性がある。エージェントは強固なアイデンティティを持っていても、共有サービスアカウントを介してツールを呼び出すかもしれない。ツールは権限を強制していても、外部文書からの未検証の指示を受け入れる可能性がある。
調達チームは、エージェントベンダーにより具体的な回答を求めるべきだ。責任あるAIに関する一般論だけでは不十分である。購入者は、製品がアイデンティティ、委任、承認、ログ、メモリ、権限取り消しをどのように扱うのかを知る必要がある。
また、コネクターをまたいでも制御が有効であり続けるかを尋ねるべきだ。エージェントは主要プラットフォーム内では制限を守っても、第三者サービスを呼び出す際にそれらを失う可能性がある。権限継承はその移行を越えて維持されなければならない。
購入後の運用上の所有者も重要だ。誰かがアクセスをレビューし、異常を調査し、未使用のエージェントを削除し、ワークフローの変更に応じてポリシーを更新しなければならない。運用プロセスを伴わないエージェントインベントリは、また一つの古びた資産リストになる。
開発者とナレッジワーカーも、より厳格なガバナンスが製品体験を形作るため、関心を持つべきである。一部のエージェントは機密性の高い操作の前に停止する。ほかのエージェントは、プレビュー、制約付きモード、明示的な権限要求を提供するだろう。
そのような中断は、常に欠陥ではない。可視化された承認ステップは、エージェントが何をしようとしているのか、どのデータを使うのかを明確にできる。実行前に、ユーザーが誤解された目的を見つける機会を与える。
設計の悪い制御は、逆の結果を生む。繰り返される曖昧なプロンプトは、ユーザーに要求を自動的に承認する習慣をつけさせる。インターフェースは、具体的な操作、対象、範囲、結果を平易な言葉で説明しなければならない。
したがって市場の圧力は、有用な自律性と理解しやすい境界を組み合わせた製品を後押しする。生のタスク完了能力は引き続き重要だ。エージェントが価値あるシステムへのアクセスを得るにつれ、信頼できる委任も同等に重要になる。
ランタイムガバナンスが機能するかを示す3つのシグナル
次の試験は、また一つのポリシー発表ではない。実際の複数ステップのワークフロー全体で、アイデンティティ、認可、証跡が維持されるかどうかだ。
第一のシグナルは、主要なエンタープライズプラットフォームで独立したエージェントアイデンティティが採用されることだ。重要な証拠には、ライフサイクル制御、明示された所有者、限定的な権限、有効期限、取り消しが含まれる。
製品ラベルだけでは不十分だ。セキュリティチームは、エージェントを、そのスポンサーとなる従業員やツールの背後にあるサービスアカウントと区別する必要がある。より広範な対応は、ランタイムガバナンスの主張を強めるだろう。
第二のシグナルは、アプリケーション境界での強制である。エンタープライズソフトウェアの提供者は、外部メッセージ、レコード変更、コードデプロイ、財務操作など、重要な結果を伴う操作に対するポリシーを公開すべきである。
これらのコントロールがビジネス上の文脈を理解しているのか、それとも単にテキストをフィルタリングしているだけなのかに注目すべきです。文脈を踏まえた認可が実現していれば、ガバナンスが実行段階へ移行したことを示します。一般的な警告や任意のログにとどまるなら、その移行はまだ不完全です。
3つ目のシグナルは、障害事例と独立したテストから得られる証拠です。研究者は、プロンプトインジェクション、委任された権限、汚染されたメモリ、過剰な権限、リモートエージェント間の相互作用をテストする必要があります。
透明性の高いインシデント報告は、成功事例のデモと同じくらい重要になります。こうした報告により、コントロールが有害な行為を阻止したのか、影響範囲を限定したのか、あるいは事後的に被害を記録しただけなのかが明らかになります。バイパスの繰り返しは、行為時点での強制が成熟しているという主張を弱めることになります。
今後数カ月にわたり、購入側はベンダーに一連の完全なチェーンを実演するよう求めるべきです。特定のユーザーから始め、範囲を限定したタスクを委任し、保護されたデータを取得し、ツールを呼び出し、承認を必須とし、アクセスを取り消します。
次に、証拠を確認します。ベンダーは、誰がタスクを開始したのか、どのエージェントが行動したのか、何にアクセスしたのか、どのポリシーが適用されたのか、委任によって権限が変化したのかを示せるでしょうか。
エンタープライズAIエージェントのガバナンスが成功するのは、こうした問いへの回答が実際の導入環境でも通用する場合に限られます。組織でエージェントの試験導入を進めているなら、各ワークフローにおける最初の不可逆なアクションを特定してください。そこに最も強力なコントロールを配置し、拒否経路をテストし、すべての判断が追跡可能であることを確認してください。
