Dhivya Nagasubramanian、AI変革・イノベーションのVP – インタビュー・シリーズ

Dhivya Nagasubramanianは、米国主要金融機関のAI変革・イノベーションのVPであり、実稼働中のエージェントAIシステムの設計、展開、ガバナンスを担当しています。彼女は、Agentic AI for Engineers (Apress/Springer Nature)の著者であり、信頼できる自律AIシステムを構築するための実践的なガイドです。この本は、出版以来、SpringerLinkで6,000以上の機関アクセス、世界中の260以上の図書館での所蔵、大学での採用を記録しています。彼女は、応用機械学習でUSPTO特許を取得しています。彼女の研究関心は、攻撃に対して耐性のあるアプリケーションを構築し、多文化の安全性とセキュリティのための業界全体の取り組みに貢献することです。彼女は、業界と学術の会議で求められる専門家のスピーカーとパネリストです。

あなたのキャリアは、エンタープライズコンサルティングとデータサイエンスから、金融サービスにおけるAI変革のリーダーシップへと進化しました。Agentic AI for Engineersを書くきっかけとなった、AI研究とエンタープライズ展開の間にある繰り返し出现するギャップとは何ですか?

2008年に、銀行プラットフォームのポートフォリオ会計とパフォーマンス測定システムを構築し始めました。そのプロジェクトの1つは、80以上の国で使用されるGIPS準拠のエンジンでした。時間加重リターンを計算するエンジンでした。その仕事で、私は、全キャリアを通じて学んだ教訓を得ました。規制された金融では、最も危険な失敗は、見た目が正しい数字の間違った数字です。微妙に間違った計算は、信頼され、報告され、行動され、数年間にわたって続きます。なぜなら、壊れたように見えないからです。

後で同じパターンをもう一度見ました。広く使用されているマーケティング属性モデルのマルコフモデルに構造的なギャップを見つけました。フレームワークは数十万のユーザーによって使用されていましたが、エラーは数年間続いていました。なぜなら、出力は妥当に見えたからです。金融サービスにおけるAI変革に移ったとき、エージェントシステムがこのパターンを繰り返すのを見ましたが、賭けははるかに高くなっていました。エージェントは単に間違った結果を生み出すだけではありません。それに基づいて行動をします。

私を本を書くことにさせたギャップは、研究とエンタープライズ展開が異なるものを気にかけることです。研究はベンチマークでの能力を測ります。エンタープライズは、システムが曖昧さ、変化するデータ、攻撃的な圧力の下でどのように動作するかを気にかけます。大部分のエージェントに関する記述はデモの段階で終わります。私は、エンジニアが名前をシステムに署名する必要があるため、Agentic AI for Engineersを書きました。そのシステムは、規制された機関内で、限定的な監視の下で実行されます。

本書では、自動化から自律性への移行を新しいエンジニアリングの心構えとして説明しています。高度な自動化ワークフローと自律エージェントAIを真正に区別するものは何ですか? どこで組織が2つを混同することがありますか?

私はチームに簡単なテストを与えます。システムを実行する前に、すべてのパスをリストできますか? そうであれば、自動化です。言語モデルが内蔵されている高度な自動化かもしれませんが、自動化です。システムが実行時に目標を分解し、ツールを選択し、コンテキストに基づいてアクションの順序を決定する場合、自律性があります。違いは、使用するモデルとは関係ありません。決定がどこで行われるかということです。

組織は、両方向に2つを混同しますが、1方向のみが高価です。スクリプト化されたLLMワークフローをエージェントと呼ぶことは、主にマーケティングの問題です。費用的ミスは、その逆です。チームは、決定のための真正な自律性を、決定主義的自動化のために設計されたガバナンスの下で展開します。テストは再現性を仮定します。監視は既知の障害パターンを仮定します。監査証跡は、ルールの背後に追跡可能なものがあることを仮定します。エージェントの場合、これらの仮定は当てはまりません。

本書で私は主張する心構えの転換です。自動化の場合、主な質問は、システムが正しく実行されたかどうかです。自律性の場合、質問は、システムが正しく決定したかどうかになります。その答えには、異なる計測、異なる評価方法、異なるレベルの注意が必要です。

多くのエージェントAIシステムは、デモンストレーションでは印象的に動作しますが、実際のユーザー、変化するデータ、予測不可能なツールにさらされると苦労します。実稼働可能なエージェントアーキテクチャには、どのようなコンポーネントが必須と見なされるべきですか?

正直な答えは、実稼働にはデモでスキップできるすべてが必要です。デモは、誰かが環境を制御したため機能します。実稼働では、その制御が取り除かれます。

本書では、7層のリファレンスアーキテクチャを説明していますが、以下のコンポーネントを必須と見なしています。入力と明示的な権限を持つツール契約により、エージェントのリーチは設計によって制限され、希望によって制限されません。中断と障害に耐える状態管理。明示的なエスカレーションパスを持つ構造化された障害処理。起動前に一度だけ実行するのではなく、継続的に実行される評価ハーネス。決定とその背後にある理由を記録する監査証跡であり、取られたアクションのみを記録するものではありません。

チームが最も頻繁にスキップするコンポーネントは、ランタイム検証です。これは、エージェントの明示された目的と適用されるポリシーに対して、毎回のアクションをチェックするレイヤーです。標準的なインフラストラクチャは、呼び出しが成功したかどうかを示します。検証は、呼び出しが行われるべきかどうかを尋ねます。デモでは価値を証明することはできません。なぜなら、デモでは何も捕捉する必要がないからです。実稼働では、最初に欲しいものになります。

エンジニアリングチームは、安全性を最終的な事前起動レビューとして扱うのではなく、安全性要素を継続的な保証プロセスに組み込むべきです。どのようにすればよいですか?

最終レビューは、レビューしたシステムが実行されるシステムであるという仮定に基づいています。エージェントAIの場合、この仮定は3つの方法で失敗します。基礎となるモデルが更新されます。エージェントが依存するツールとAPIが変更されます。エージェントが動作するデータと環境が継続的に変化します。一回限りの安全性レビューは、数ヶ月後にはもはや存在しないシステムを記述します。

継続的な保証とは、ループを閉じることを意味します。行動評価は、ユニットテストと同じようにCI（継続的統合）で実行され、プロンプト、ツール、モデルへの変更ごとにゲートされます。ランタイム監視は、生産トレースを評価セットにフィードバックします。我が書く4つの監視パターンは、障害の全表面をカバーするものではありません。各インシデントは、新しいチェックを生み出し、バグが生まれるのと同じように、回帰テストを生み出します。攻撃テストは、起動前に一度だけではなく、定期的なスケジュールで実行されます。

組織的な側面は、技術的な側面と同じくらい重要です。安全性は、最後にチェックリストを持って現れる別のチームではありません。エージェントを構築するエンジニアは、その評価スイート、その不変条件、そのエスカレーションデザインを所有する必要があります。なぜなら、彼らは、システムの判断が最も弱い場所を誰よりもよく知っているからです。

あなたはエージェントツールコールのセマンティック監視を強調しています。セマンティック監視は、従来のログと可観測性ツールでは明らかにならないものを何を明らかにしますか? エージェントが技術的に機能しているが、間違った目標を追求している場合を検出するにはどうすればよいですか?

従来の可観測性は1つの質問に答えます。呼び出しが成功したかどうかです。状態コード、スキーマ、待機時間、エラー率をカバーします。エージェントにとって最も重要な質問には答えることはできません。呼び出しが発生するべきかどうかです。ツールコールは技術的に完璧でいても、間違ったアクションである可能性があります。正しい形式、有効な資格情報、成功した応答、間違ったことをする。

セマンティック監視は、エージェントの明示された目的と適用されるポリシーに対して、毎回のアクションを評価します。我が書くこのことを、エージェントツールコール上のセマンティック不変量を定義することと説明しています。これらは、エージェントが取るパスに関係なく、保持しなければならない特性です。顧客のケースを調査しているエージェントは、決してそのケース以外のレコードにアクセスすべきではありません。エージェントは、一定のしきい値を超える不一致をフラグとして設定する必要があります。決してそれ自身では解決しないでしょう。不変量が違反されたとき、行動の瞬間に問題を捕捉します。

これは、エージェントが間違った目標を追求していることを検出する方法でもあります。目標のズレは、エージェントが毎ステップを正しく完了するように見えますが、静かに間違った目標に向かって動作していることを意味します。ログに表示されることはありません。なぜなら、失敗することはないからです。セマンティック監視は、意図を直接測定します。意図は、エージェントが間違うところです。

エージェントが曖昧な指示、矛盾するポリシー、利用できないツール、または不十分な信頼性に出会ったとき、構造化された障害処理はどのようなものになるべきですか? 開発者は、システムが即興で動作するのではなく、停止、エスカレーション、または回復するように保証するにはどうすればよいですか?

設計するべき問題は、ほとんどのエージェントがタスクを終了する方法が1つしかないことです。それは、答えを生み出すことです。指示が曖昧であるか、ポリシーが矛盾する場合、エージェントは即興で動作します。モデルが無謀であるということではありません。アーキテクチャが許可する行動はそれだけだからです。構造化された障害処理とは、システムにより良い選択肢を与え、それらが即興の答えよりも簡単に到達できるようにすることを意味します。

実践では、拒否とエスカレーションは、成功と同じ注意とテストで設計およびテストされることを意味します。我が推奨するのは、型付きの障害状態を定義することです。曖昧な指示、矛盾するポリシー、利用できないツール、不十分な信頼性。各状態は、特定の動作にマッピングされます。明確化の質問を尋ねます。人間に完全なコンテキストを添付して手渡します。読み取り専用の動作に切り替えます。より厳しい制限内で再試行します。あるいは停止します。信頼性のしきい値は、特定のアクションのリスクと一致する必要があります。内部要約を起草するためのしきい値と、顧客アカウントに触れるためのしきい値は、決して同じ数字にはなりません。

2つの実践がこれを実現します。まず、エスカレーションパスを幸せなパスよりも先に設計します。人間がハンドオフを受け取る場合、コンテキストと権限を、最初のプロンプトを書く前に決定します。2つ目は、障害を機能と同じようにテストすることです。曖昧な指示を挿入します。ステージングでツールを無効にします。エージェントに矛盾するポリシーを提供します。障害を一度も練習したことがないシステムは、実稼働で初めて発生したときに、指示なしで動作します。

金融機関は、実験と、プライバシー、監査可能性、モデルリスク、規制遵守に関する厳格な要件のバランスを取らなければなりません。人間の承認が必須である場所はどこですか? エージェントはどこでより大きな運用的自律性を安全に与えることができますか?

私のルールは、人間の承認が、以下のアクションに対して必須であるべきであるということです。不可逆的なアクション、金銭の移動や患者結果に影響を与えるアクション、規制上の重みを持つ顧客コミュニケーションを含むアクション、規制報告を供給するアクション、またはエージェント自身のツール、ポリシー、または権限を変更するアクション。エージェントは、読み取りと推論作業でより大きな自律性を安全に与えることができます。研究、検索、文書分析、トライエージュ、下書き、人間のレビューのために不一致をフラグする調整などです。

一般的な間違いは、毎ステップで人間の承認を必要とすることです。そのことではシステムをより安全にしません。手動プロセスを再作成し、レビューアーがスタンプを押すようにトレーニングします。承認は、実際の意思決定ポイントにあるべきです。少なくともそれらが存在する必要があり、各承認は実際の権限を持つ誰かによって行われるべきです。

もう1つの原則は、自律性は与えられるのではなく、獲得されるべきであるということです。狭いところから始めます。監視の下でシステムが自分自身を証明するにつれて、範囲を拡大します。証拠を保持します。モデルリスクの観点から、コントロール環境は、エージェントが行ったことと、与えた自律性レベルを正当化した理由を、規制機関に示すことができるべきです。その記録は、実際に運用するための実際のライセンスです。

あなたは人工知能の安全保障と標準に関する作業を通じて、継続的に変化する能力を持つシステムのルールを定義しています。現時点で標準化できる安全保障は何ですか? どの領域は依然としてコンテキスト、業界、またはユースケースに大きく依存していますか?

現在標準化できる安全保障は、構造的なものです。特定のコントロールが存在し、文書化され、検査できることを必要とします。自律システムの明示された能力と権限の境界。人間の監視とエスカレーションメカニズムの定義。インシデントの検出と報告の義務。評価方法と証拠の要件。システムのライフサイクル全体にわたる明確な責任があり、何かが間違ったときに、AIだけが責任者であることはありません。これらは標準化できます。なぜなら、コントロールが存在するかどうか、どのくらいの質があるかということのみに関係するからです。特定の値を取るかどうかではありません。

まだ標準化できないのは、設定自体です。特定の信頼性のしきい値、有害性の分類、適切な自律性レベルは、コンテキスト、業界、用途に大きく依存しています。マーケティングコンテンツエージェントと、臨床的または金融上の意思決定に触れるシステムのための許容される障害容認度は、同じスケールの2つのポイントではありません。異なるレジームに属し、ドメイン、管轄区域、障害時に損害を被るものによって形成されます。

金融コントロールはここで有用なモデルです。監査要件は世界的に標準化されていますが、重要性は常にコンテキストで判断されます。コンテキストに依存しない値を尊重する標準は採用されます。コンテキストに依存する値を指定しようとする標準は、採用されません。誰も従わない安全性標準は、誰もを保護しません。

あなたの最近の研究は、AIの安全性評価における多文化的および対抗的な堅牢性を探究しています。西洋中心の、または世界平均のベンチマークによって見逃される可能性のある、どのような種類のモデル障害がありますか? 多文化展開を目的としたシステムを、企業はどのように評価するべきですか?

平均化されたベンチマークのみを見ると、最も重要な障害が見逃される可能性があります。モデルは、強力な全体的な安全性スコアを記録しながら、特定の言語、方言、文化的コンテキストに対して大幅に失敗する可能性があります。なぜなら、その障害は平均値に埋もれてしまうからです。西洋中心の評価は別の盲点を追加します。文化的に特有の有害性、たとえば、同じ出力が1つの文化では無害で、別の文化では有害である、アイディオム、ジェスチャー、宗教的または地域的なコンテキストを逃します。また、コードスイッチング、ラテン文字化、西洋以外の名前やエンティティを十分にテストしません。対抗的な側面もあります。攻撃者は平均的なパフォーマンスを標的にしません。彼らはあなたの最も弱いスライスを見つけます。ほとんどのモデルにとって、そのスライスは、リソースが限られた言語または評価が不十分な文化的コンテキストです。

これが、私が多文化AIの安全性ベンチマーク研究に貢献することになった理由です。主な発見は、文化全体の安全性を評価するには、文化からの評価データと人間の判断が必要であるというものです。損害が発生するコンテキスト外から損害を評価することはできません。

企業にとって、私は3つのルールを提案します。サービスするすべてのセグメントを評価し、平均値を証拠として受け入れないでください。実際の顧客ポップレーションから評価セットを構築します。顧客が使用する言語で対抗的なテストを実行します。顧客を40カ国でサービスしている場合、英語のみで評価することは、システムを別の展開のために評価していることになります。

あなたは、応用AIで特許を取得しています。どのような問題を解決しようとしていたのですか? 特許プロセスは、AIの研究を実用的なイノベーションに変えることについて何を教えましたか? 次に解決したい未解決のエージェントAIの課題は何ですか?

承認された特許は、金融サービスにおける品質レビューの拡大と一貫性の問題に対処しています。従来のコールレビューは手動で行われ、人間のレビュアーはコールのごく一部のみをサンプリングできます。評価とコンプライアンスの質問ごとに、最も適した方法をルーティングする私のアプローチであり、決定はすべてログされ、監査可能です。

私が説明したのと同じテーマが見られます。各タスクを、最も適したツールにルーティングします。人間の判断が重要な場所に人間を保持します。自動化された決定はすべて追跡可能です。なぜなら、規制された機関では、証拠のない答えは答えではないからです。

特許プロセスは、具体性への取り組みを教えてくれました。漠然としたアイデアを特許付けることはできません。方法が何を異なるようにしているか、どこで適用されるかを正確に示す必要があります。その精度は、基礎となる作業を改善しました。

私が今最も心配している未解決の課題は、多エージェントシステムのランタイム検証です。単一のエージェントのセマンティック不変量を定義することは、管理可能です。私が知っているのは、実稼働でそれを実行しているからです。エージェントが他のエージェントに作業を委託する場合、動作は出現し、障害はハンドオフに移動します。指示が各ステップでわずかに解釈されます。ポリシーは1つのエージェントに適用されますが、エージェントが採用したエージェントには適用されません。エージェント間の相互作用、各エージェントのアクションのみではなく、検証することは、次の世代の沈黙した障害が現れる場所です。次に取り組みたい問題です。

素晴らしいインタビュー、読者は彼女の本 Agentic AI for Engineers を注文することもできます。