Sardine に入社する前は、銀行業界で 20 年間働いていました。まずは個人向け銀行業務とウェルスマネジメント向けのエンドツーエンドのリスクシステムを構築し、その後、複数のティア1銀行をまとめて Zelle ネットワークのリスク管理フレームワークを設計し、運用に落とし込む取り組みを主導しました。
現在、私はSardineで最新の不正検知およびリスクインフラの構築に携わるとともに、銀行、フィンテック企業、決済ネットワーク間でカウンターパーティリスクと情報を共有する業界向けユーティリティであるSonarを率いています。
私たちがエージェンティック・オーバーサイト・フレームワーク（AOF）を発表したとき、業界全体で大きな反響を呼びましたが、同時に、かつての同僚であるリスク、コンプライアンス、ポリシー部門の担当者たちから、すぐにある疑問が投げかけられました。
「この概念的なフレームワークを、実際に規制当局が承認してくれるものへと、どうやって落とし込めばよいのか？」
このプレイブックが私の答えです。
それはイノベーションと規制当局による精査とのギャップを埋め、AOF をモデルガバナンス、サードパーティ管理、オペレーショナルリスクチーム向けに最適化された、実行可能で監督にすぐ活用できるコンポーネントへと変換します。
審査や意思決定、カスタマーサービス、ワークフローの自動化など、AIエージェントを安全に導入しようとしている銀行に向けて、このプレイブックは、規制当局の変化し続ける期待に整合させるための運用上の枠組みを提供します。
1. エージェント型AIのガバナンスは、エージェントの分類とリスク階層化から始まる
各AIエージェントごとに個別のポリシーを作成するのではなく、エージェントをリスク階層に割り当てる分類マップを作成しましょう。どの階層に属するかによって、必要となる監督、文書化、および検証の水準が決まります。
- ティア1（重大な影響）: 規制上、財務上、または法的な措置を直接引き起こすエージェント。たとえば、不審行為報告書（SAR）の提出、支払いのブロック、制裁チェックの実施などが該当します。これらのエージェントには、フェデラル・リザーブのSR 11-7に準拠した包括的なモデル検証が必要であり、フォールバック制御や改ざん不可能な監査ログを含みます。
- ティア2（中程度の影響）：意思決定を支援するが、自律的には行動しないエージェント。たとえば、オンボーディング、不正調査のトリアージ、KYC ワークフローの支援などが含まれます。出力結果は人間の判断に影響を与えるため、説明可能性と人間によるレビュー（ヒューマン・イン・ザ・ループ）が必須となります。
- ティア3（低影響）：ナレッジ検索やレポート作成など、社内業務を支援するエージェント。コンプライアンス上の義務を直接発生させることはありませんが、重要な業務フローでの無制限な利用を防ぐため、記録とモニタリングが必須です。ティア3エージェントには比較的緩やかな管理が適用される場合がありますが、その影響度が高まった場合には、区分の見直し（再分類）が必要となります。
この階層化されたアプローチは、OCCおよびFFIECのリスクベースのガバナンスと整合しています。
2. 技術アーキテクチャ：監査対応可能で、防御可能なAIシステム
審査担当者にとって、アーキテクチャはリスク管理の一部です。適合したAIシステムは、単に高精度であればよいわけではありません。監査可能で、正当性を説明でき、設計段階からセキュアである必要があります。
- 推論ゲートウェイ：ユーザーとモデルの間に位置し、個人データをマスキングまたはトークン化することで、モデルが不要な機微情報にアクセスしないようにします。
- エージェントランタイム（モデルコンテナ）： 実行時にモデルのバージョンと設定を固定します。これにより、説明可能性を損なったり、検証結果からのドリフトを引き起こしたりする「サイレントアップデート」を防ぎます。
- 説明レイヤー： モデルがその判断を下した理由について、思考過程の連鎖（チェーン・オブ・ソート）による推論、信頼度スコア、および一文の要約を生成します。
- 改ざん不可能な監査ログ：すべてのプロンプト、入力、モデル、および出力が記録され、ハッシュ化されます。これにより FFIEC 監査への備えが可能になり、規制当局はモデルが実際に何を見たのかを正確に再現できます。
- エージェントの判断に対する品質保証（QA）レイヤー： ログ取得にとどまらず、システムは人間の意思決定者に対して行うのと同様に、エージェントの判断について定期的なサンプリングと体系的なレビューを可能にすべきです。これにより、コンプライアンス、監査、QAチームはポリシーとの整合性を継続的に検証し、イレギュラーなケースをスポットチェックし、結果が期待どおりであり続けることを確認できます。また、継続的な改善を支援し、SR 11-7、FFIEC、EU AI法第15条といった、単発の検証ではなく継続的なモニタリングを重視する枠組みにおける監督当局の期待にも応えます。
- フォールバック経路： モデルが失敗したり応答品質が低下した場合に備えて組み込まれた仕組みです。ルールエンジンがデフォルトの保守的な対応を実行するか、タスクを人間のレビュアーに送ります。
- 継続的なモニタリング： モデルドリフト、外れ値的な挙動、パフォーマンス低下をリアルタイムで検知するための自動ダッシュボードとアラート。
システムの各部分を NIST 800-53 および ISO 27001 にマッピングすることで、情報セキュリティチームは内部監査と各種試験の双方に向けた準備状況を証明できます。
3. AIモデル検証 SR 11-7：監督要件に準拠したプレイブック
意思決定に実質的な影響を与えたり、意思決定を実行したりするAIエージェントは、従来型の機械学習かLLMかを問わず、SR 11-7の下ではモデルとして扱われます。検証は監督当局の期待水準を満たさなければなりません。そのため、検証には次の点を含める必要があります。
- ポリシー適合性：エージェントのロジックが銀行の方針を反映しているか確認する（例：正当な理由に基づいて取引を拒否しているか、BSA/AML 規則に従って不審な行動を適切に検知・フラグ付けしているか）。
- バックテスト： エージェントを過去の事例でテストし、正しい判断・誤検知（偽陽性）・見逃し（偽陰性）をどの程度の頻度で行うかを確認します。そのうえでリスクを定量化します。
- ロバスト性チェック： モデルが表面的な違いだけで出力を変えないことを確認するために、入力をランダム化したり言い換えたりする。
- 敵対的テスト： 悪意のある入力（プロンプトインジェクション、不正な形式のデータ、極端に長いテキストなど）を与えて、どのような異常な挙動が起きるか観察します。クラッシュしたり、フリーズしたり、ハルシネーション（事実無根の出力）を起こしたりしないか確認しましょう。
- 独立したレビュー：最終報告書は、開発チーム外の人物（SR 11-7 の独立性要件に基づく）によって署名されます。報告書は、単なる Python コードではなく、誰にでも理解しやすい内容でなければなりません。
- バイアスと公平性の監査： 特に融資、不正検知、またはオンボーディングにおいて、不均衡な影響が生じていないかを定期的に評価します。保護対象属性ごとに公平性の指標を追跡し、講じた緩和策を文書化します。
このプロセスは、あらゆるモデル更新の後や、継続的モニタリングによってドリフトが検知された場合などに、定期的に繰り返し実施されます。SR 11-7 に基づく AI モデル検証で特に重要なのは、銀行がエージェントの出力が正確で安定しており、独立したレビューを受け、かつ方針と整合していることを証明しなければならない点です。
4. コンプライアンス上のギャップを最小化するデータプライバシーとサイバーセキュリティ管理
すべてのエージェントはゼロトラストの原則に従ってデータを取り扱わなければなりません。つまり、身元を検証し、各タスクに必要な最小限のデータにのみアクセスを制限し、監査のためにあらゆるやり取りを記録する必要があります。いかなるエージェントも、社内システムや他のエージェントを当然に信頼できるものとみなしてはなりません。いかなるモデル、ベンダー、プロンプトも、本当に必要な範囲を超えてアクセスしてはなりません。
- GLBA:金融データは暗号化され、定められた正当な利用目的のためにのみアクセスされなければなりません。（15 USC §§ 6801-6809）
- CCPA： 個人には、通知を受ける権利、訂正を求める権利、およびオプトアウトする権利があります。AI エージェントが顧客向けのメッセージを生成する場合、これらの権利が組み込まれていなければなりません。（カリフォルニア民法典 §§ 1798.100–1798.199）
- NY DFS:72時間以内の侵害通知、インシデント対応計画、および年次コンプライアンス認証を義務付けています。（23 NYCRR §§ 500.1–500.22）
- GDPR 第22条：EU/英国での事業運営において、人間の関与なしに重大な影響を及ぼす完全な自動化による意思決定を禁止します。
- ISO/NIST:各システムコンポーネントは、監査およびセキュリティテストを支援するために、対応する管理策セットにタグ付けされるべきです。
- 合成データ： テスト、トレーニング、または検証に使用する場合、特に本番データセットから生成された合成データについては、プライバシー漏えいおよびメンバーシップ推論リスクの観点から評価しなければなりません。NIST SP 800-53 第5版および ISO/IEC 42001 における新たな指針の下で、銀行は合成データセットがリバースエンジニアリングされても非公開の個人情報（NPI）が特定されないことを実証することが求められています。
- 国境を越えたデータ移転：グローバルに事業を展開する銀行は、AIエージェントによるデータの流れが、GDPR や英国 DPA などの国際的なデータ移転関連法令に準拠していることを確保する必要があります。
AIベンダーがこの対応をしてくれると決めつけないでください。あなたの銀行は引き続きデータ管理者であり、不正利用についての責任を負います。
5. 説明可能性、監査可能性、および規制当局によるアクセス
判断を説明できなければ、それを正当化することはできません。規制対象となる判断に影響を与える、またはそれを実行するあらゆる出力は、必ず次の情報とともに記録しなければなりません。
- 正確な入力内容（適切にマスキングされたもの）
- モデルのバージョンと構成パラメーター
- 意思決定に関する明確で人間が理解しやすい根拠。
- 調査および消費者からの異議申し立てへの対応を支援するため、再現可能な監査証跡を維持すること。
これらのログは、ECOA/FCRA に基づく不利な行為通知を支援し、苦情調査およびコンプライアンスの品質保証のために取得可能でなければなりません。構造化が進んでいるほど、モデルガバナンス審査を乗り切りやすくなります。
6. 第三者AIリスクの銀行業務：ベンダー管理と契約上の統制
サードパーティのプラットフォームやAPIが関与する場合、契約書には次の点を明確に盛り込む必要があります。
- 監査権限：内部チームおよび規制当局がログ、バージョン履歴、データの来歴を確認できるようにすること
- セキュリティ認証：SOC 2 Type II、ISO 27001、および文書化されたペネトレーションテストを必須とする。
- インシデント通知：セキュリティまたはモデルに関するインシデントを72時間以内に開示することを義務付ける。
- データエクジット： データを取得および削除できることを保証してください。そうでなければ、リスクなしにベンダーを乗り換えることはできません。
- オープンソースモデルのリスク：オープンソースのLLMやフレームワークを利用する場合は、脆弱性に対する審査、パッチ適用、および監視を徹底してください。
これらの規定は、第三者リスク管理に関する規制ガイドラインと整合しています。
7. AIエージェント監督フレームワーク：ガードレール、フォールバック、および故障モード
オペレーショナルリスクチームは、失敗を前提とし、各モードに対する管理策を定義しなければなりません。
- タイムアウトとトークン上限：ルールエンジンまたは人によるトリアージへのフォールバック。
- 信頼性の低い出力： 自動的に人による確認にエスカレーションします。
- 有害な入力やプロンプトインジェクション：既知の攻撃パターンをフィルタリングします。
- 出力ドリフト：出力を常にベースラインと比較し、必要に応じて再学習またはロールバックを行います。
- インシデント対応プレイブック： 明確なトリアージ、コミュニケーション、規制当局への通知、および是正措置の手順を定義すること（NY DFS § 500.16）。
あらゆる障害シナリオを既存のインシデント対応手順にマッピングする必要があります。運用プレイブックおよび事業継続計画には、モデル固有の項目を含めてください。
8. 規制報告の整合性：継続的な監査対応準備の確保
エージェントが規制対象のプロセスに関与する場合は、その役割をそれぞれの報告義務に対応付けてください。
- SAR 申請：出力結果はコンプライアンス部門が確認できる必要があります。ログは 5 年間保管してください。
- ECOA/FCRA： 不利な行為に関する開示のために、モデルの根拠と入力データを提供すること。
- UDAAP：不公正、欺瞞的、または乱用的な自動コミュニケーションを回避すること。
- GDPR： 自動化された判断に対して、人による不服申し立ての権利を提供すること（EU/UK の業務）。
これは統制テストに含め、法務およびコンプライアンス部門によって定期的に検証されるべきです。
9. 顧客とのコミュニケーションと透明性
顧客が関わる意思決定については、次のとおりです。
- AIが使用されていることを事前に知らせる
- 人による異議申し立てができる窓口を設ける
- 開示内容がCFPBおよびGDPR第22条の基準を満たすようにする
- あいまいな表現や目立たない場所に記載された免責事項は避けてください。
こちらは開示文のサンプルテンプレートです。
「この決定は自動化されたシステムの支援を受けて行われました。ご不明な点がある場合や、人による再審査を希望される場合は、[support channel] までご連絡ください。」
10. モデルのインベントリおよびライフサイクル管理
使用中またはテスト中のすべてのAIシステムについて、単一のバージョン管理されたレジストリを維持すること。含める内容：
- エージェント名
- リスク階層
- オーナー
- 最終確認
- 更新履歴
- 現在の状況
- 監査ログの保存場所
これは四半期ごとのレポーティングにおいて、モデルリスクおよびエンタープライズリスクの各機能向けに使用してください。監査に備えるため、すべての変更を必ずアーカイブし、バージョン管理してください。未使用のエージェントを正式に廃止する場合は、誤って再有効化されないようにするための統制が整備されていることを確認してください。
11. 導入チェックリスト：本番稼働前に確認すべきこと
以下の関係者から文書による承認を必ず取得すること：
- モデルリスク：検証、ポリシー整合性、公平性監査。
- 情報セキュリティ：脅威モデルのレビュー、エンドポイントセキュリティ、監視。
- プライバシー：適法なデータ処理、最小化、国境を越えたコンプライアンス。
- 調達： ベンダーリスク評価、契約上の保護措置、終了時の計画。
- オペレーション：人による介入テスト、リアルタイム対応、インシデント対応の準備態勢。
- 内部監査：ログの検証、監査証跡の完全性。
- コンプライアンス：適用される法律および規制との整合性が確認されました。
各承認では、レビューした特定の管理領域と、リリースに課されたあらゆる条件を明示しなければなりません。いずれかのチームがローンチをブロックする場合、その判断は理由およびエスカレーション経路とともに文書化される必要があります。
12. 継続的な監視と改善
一度導入されたエージェントは、次の観点から継続的に評価されなければなりません。
- ドリフトや異常を検知するためのリアルタイム監視ダッシュボードとアラート。
- 合成データや敵対的入力を用いた定期的なチャレンジテスト。
- リスク階層化、検証結果、およびモデルレジストリの四半期レビュー。
エージェントプロンプト、モデルパラメータ、基盤となるツールへのあらゆる変更を記録・レビューし、承認する正式な変更管理プロトコルを確立してください。これにより、追跡可能性と方針との整合性が確保され、SR 11-7 などの枠組みおよび OCC 2023-17 における監督当局の期待にも適合します。
インシデント、監査、および顧客からの申し立てに関するフィードバックを、継続的な改善のプロセスに組み込むことが重要です。これらのインプットは、シミュレーションデータやバックテストデータだけでは捉えきれない例外的なケースを明らかにし、統制機能が実際の行動や状況の変化に対して柔軟かつ適切に対応し続けられるようにするのに役立ちます。
アーキテクチャに信頼性を組み込む
AIエージェントは、意思決定にかかる時間を数時間から数分へと短縮できます。しかし、適切な管理がなければ、規制上のリスクを高めてしまう可能性があります。階層化された監督体制を構築し、技術的なセーフガードを組み込み、トレーサビリティを維持し、人間の責任を徹底することで、銀行は設計段階からコンプライアンスに適合し、監査や検証にも耐えうるAIエージェントを導入することができます。
Sardine の AI エージェントが実際にどのように動作するかデモをご覧になりたい方や、これらのエージェントを本番環境に安全に導入する方法について詳しく知りたい方は、お問い合わせください。
よくある質問
銀行業におけるエージェンティックAIとは何ですか？
銀行業におけるエージェンティックAIとは、リスク管理されたガードレールの中で複数のステップからなる行動を実行するAIエージェントの導入を指します。具体的には、アラートキューのトリアージ、SAR（疑わしい取引報告書）記述のドラフト作成、手動審査の振り分け、高い確度の不正案件のエスカレーションなどです。顧客対応や当局対応に関わる最終的な判断については、人間が承認を行います。
SR 11-7 はエージェント型 AI にどのように適用されますか？
SR 11-7（連邦準備制度によるモデルリスク管理ガイダンス）は、規制対象となる意思決定に影響を与えるあらゆるモデルに適用されます。エージェンティックAIは SR 11-7 に加え、説明可能性、意思決定の来歴（ラインエージ）、および制約された行動空間の文書化に関する要件を追加する補足ガイダンス SR 26-2 の対象にもなります。
連邦準備制度のSR 26-2ガイダンスとは何ですか？
SR 26-2 は、銀行業務におけるエージェント型 AI に特化して、SR 11-7 を補完する連邦準備制度理事会の 2026 年版サプリメントです。自律的な意思決定、制約された行動範囲、および監査可能な来歴（オーディット・ラインエージ）に関する検証要件を明確化しており、施行時期に関する情報提供依頼（RFI）が業界向けに公表されています。
エージェンティック・オーバーサイト・フレームワーク（AOF）とは何ですか？
Agentic Oversight Framework は、エージェント型 AI に対する SR 11-7 および SR 26-2 を、Sardine がリファレンス実装したフレームワークです。これには、改ざん不可能な意思決定監査ログ、制約されたアクション範囲のドキュメント化、人間による承認（ヒューマン・イン・ザ・ループ）ワークフロー、および監督当局の審査で求められるライネージ（系譜）トラッキングが含まれます。
Sonarはどのようにして銀行の第三者AIリスクを低減しますか？
サードパーティのAIベンダーはサプライチェーンリスクをもたらします。Sonarコンソーシアムは、加盟金融機関から共有されるシグナルに基づいてベンダーを事前スコアリングし、銀行自身の本番トラフィックに影響が出る前に、集中リスク、パフォーマンス低下、挙動の異常を可視化します。