CSBSのAI監督フレームワーク、任意ガイダンスを検査官向けプレイブックへ
CSBSは9月16日、AI監督フレームワークを公表した。導入の判断は個々の機関に委ねられる一方で、州の検査官に共通のプレイブックを提供する。このフレームワークは、州レベルで監督される銀行およびノンバンク金融会社を対象とする。また、連邦規制当局が、従来のモデルおよび第三者に関するガイダンスを新しいAIシステムへどう適用すべきかを再考する時期にも発表された。
この対照こそが本件を特徴づける。CSBS AI supervisory frameworkは任意のものであり、新たな法的義務を生み出すものではない。それでも、実際の検査のあり方に影響し得る、具体的な質問、資料提出要請、レビュー手順、リスク階層化ツールを検査官に提供する。
連邦のアプローチは異なる方向へ進んでいる。改訂された連邦のモデルリスク・ガイダンスは、生成AIおよびエージェント型AIを適用範囲から明示的に除外している。CSBSは州の検査官に対し、こうしたシステムを見つけ出し、その利用を理解し、より詳細な精査が妥当かどうかを判断するための、より広範な方法を提供している。
したがって、このフレームワークの重要性は新たな規則というより、運用マニュアルとしての側面にある。金融機関は、AIのインベントリ、ガバナンス、ベンダー、顧客への影響、自律的な行動について、検査官が何を尋ね得るかをより明確に予見できるようになった。
CSBS AI Supervisory Frameworkが変えること
CSBSは広範なAIガバナンス原則を、州機関が採用または調整できる実践的な検査プロセスへと転換した。
CSBS frameworkは、自らを州の検査官のための裁量的なツールと位置づけている。AIの利用を特定し、関連リスクを評価し、既存の監督リソースによる詳細なレビューが必要かどうかを判断する助けとなる。
この限定的な説明は重要である。CSBSは、すべての州規制対象機関に適用される拘束力ある全国基準を発表したわけではない。各州の金融規制機関が、このフレームワークをどの程度自らの監督プログラムに組み込むかを決めることになる。
フレームワークは2026年8月にCSBSの2つの委員会で承認された。CSBSはその後、9月16日に公表した。想定する対象には、州認可銀行および州免許を受けたノンバンク金融会社を監督する検査官が含まれる。
パッケージには、相互に関連する複数のリソースが含まれる。Core Examiner Guideは、初期的なスコーピング質問、資料提出リスト、レビュー手順を提供する。これらの手順は、ガバナンス、監督、AIインベントリ、ユースケース、生成AI、その他の新興アプリケーションを対象とする。
Examineer Work Programは、レビューを実施するための詳細を加える。別途用意されたノンバンク向け補足資料では、ノンバンク金融サービス会社における第三者リスク、モデルリスク、消費者保護を扱う。
任意のAI Use Case Risk Tiering Worksheetは、ケースごとの評価を支援する。すべてのAIツールを同程度に危険とみなすのではなく、検査官は特定の導入における目的、影響範囲、複雑性、顧客への影響、周辺の統制を考慮できる。
Source Support Documentは、フレームワークの策定に使われた資料を特定している。CSBSによると、これらにはNational Institute of Standards and TechnologyのAI Risk Management Frameworkおよび財務省のAI用語に関する取り組みが含まれる。
この基盤は、州の監督を確立されたリスク管理の概念と結び付ける。たとえばNIST AI frameworkは、AIリスクに関する取り組みを、リスクの統治、マッピング、測定、管理を中心に整理している。
CSBSのパッケージは、これらの概念を検査の場に持ち込む。金融機関は、AIがどこで使われているか、誰が承認したか、どのデータに触れるか、誰がその性能を監視するかを示す必要があるかもしれない。
検査官は、機関がベンダーのシステムをどのように統制しているかも尋ねられる。関連記録には、契約、データ利用条件、テスト文書、リスク評価、顧客向け出力の例などが含まれ得る。
エージェント型システムでは、レビューはより運用面に踏み込む。エージェント型システムは、限定的な人間の指示の下で、目標に向けて行動できる。検査官は、許可された行動、人間によるチェックポイント、活動ログ、可逆性、緊急停止の統制を確認する可能性がある。
この水準の具体性は、準備のあり方を変える。一般的なAIポリシーだけでは、想定されるすべての質問には答えられない。機関には、文書化されたガバナンスを実際のシステム、ベンダー、意思決定、顧客の結果と結び付ける証拠が必要となる。
このフレームワークは、狭い数学的なモデル定義には収まらない可能性がある用途にも及ぶ。顧客サービス支援ツール、従業員向け調査ツール、不正対策ワークフロー、自律的なプロセスも、プライバシー、サイバーセキュリティ、コンプライアンス、業務上のリスクを生む可能性がある。
CSBSは実質的に、AIの発見から詳細な検査へ至る地図を提供した。この地図が本記事の中心的な緊張関係を生む。州機関には裁量が残される一方、監督対象企業は、それらの機関がどのような証拠を要求できるかを把握できるようになった。
州規制対象企業が今、認識すべき理由
直ちに圧力を受けるのは、自社のAI利用について信頼できるインベントリを作成できない機関である。
AIインベントリとは、導入済みまたは承認済みのAIシステムを構造化して記録したものである。通常、各システムの所有者、目的、データ、ベンダー、リスク水準、利用者、統制、レビュー履歴を特定する。
多くの機関はすでにモデルのインベントリやベンダー一覧を維持している。しかし、こうした記録では、生産性ソフトウェア、顧客向けプラットフォーム、セキュリティツール、外部委託業務プロセスに組み込まれたAI対応機能をすべて把握できない可能性がある。
ベンダーが通常の製品アップデートを通じてAIを追加すると、発見の問題はさらに大きくなる。銀行はある機能のためにソフトウェアサービスを承認した後、数カ月後に要約機能や自動意思決定機能を受け取るかもしれない。
従業員による導入も別の隙間を生む。コンプライアンスチームが活動を分類する前に、スタッフが公開AIアシスタント、ブラウザー拡張機能、組み込み型copilotを利用する可能性がある。承認済み製品にもAIが導入される場合、すべてのツールを禁止してもガバナンス上の問題は解決しない。
CSBS AI supervisory frameworkは、機関にこうした断片を結び付けるよう促す。検査官はスコーピング質問と文書から始め、より詳しいレビューに値する領域を特定できる。
金融機関は、説明責任についての質問を想定すべきである。検査官は、AIリスクを担う経営幹部または委員会がどこか、問題が生じた際に誰がシステムを停止できるのかを知りたい場合がある。
この責任を純粋に技術的なものにとどめることはできない。与信ツールは公正融資の要件に関わり得る。顧客支援ツールは、開示、プライバシー、不公正な慣行に関する懸念を生み得る。不正対策システムは、取引へのアクセスやエラー解決に影響を及ぼす可能性がある。
米政府会計検査院は、financial AI reviewで、このより広いリスク環境を文書化した。同院は、潜在的な利点とともに、偏った意思決定、データ品質の失敗、プライバシー上の懸念、新たなサイバーセキュリティ上の脅威を特定した。
GAOはまた、金融規制当局が主に既存の法律、ガイダンス、リスクベースの検査を通じてAIを監督していると指摘した。CSBSも同じパターンに従う。同フレームワークは、検査官がAIユースケースを既存の監督権限および確立されたリスク区分と結び付けるのを支援する。
この構造は、銀行だけでなくノンバンク企業にも圧力をかける。住宅ローン会社、送金事業者、消費者向け貸し手、その他の免許事業者は、複数の州で事業を展開することが多い。
複数州で事業を行う企業は、異なる機関から異なる実施方針に直面する可能性がある。ある規制当局はフレームワーク全体を組み込む一方、別の当局は一部の質問または既存の検査手順だけを用いるかもしれない。
実務的な対応は、管轄ごとに別々のガバナンスプログラムを構築することではない。企業には、複数の監督アプローチを支えられる、説明可能な証拠基盤が必要である。
その基盤はインベントリから始まるが、そこで終わることはできない。重要なユースケースごとに、担当所有者、承認された目的、文書化された制限、潜在的な影響に見合う統制が必要となる。
第三者システムには特段の注意が必要である。ベンダーのセキュリティ質問票では、そのAI機能がどのようにテストされたか、顧客データが別のモデルの学習に使われるか、アップデート後に出力がどのように変わるかが説明されていない可能性がある。
機関には人間による監督の記録も必要である。人が関与し続けると述べるだけでは、その人が何をレビューするのか、いつ介入するのか、自動化された行動を覆せるのかを説明できない。
ナレッジワークでは、ポリシー、承認、ベンダー資料、テスト記録を検索可能な形でまとめておけば、文書化は容易になる。維持管理されたAI knowledge baseはその作業を支援できるが、正式なコンプライアンスシステムの代替にはならない。
最も大きな圧力を受けるのは、必ずしもAIを最も多く導入している機関ではない。AIがどこで稼働し、なぜ稼働し、どの統制がそのリスクに伴うのかを説明できない機関である。
この区別は、リスクベースのアプローチを反映する。影響の小さい文書作成支援ツールに、自動化された融資判断や自律的な支払い行動と同じレビューを適用すべきではない。
ただし、機関はまず両方のシステムを特定しなければならない。発見とインベントリがなければ、信頼できるリスク上の区別を行うことはできない。
AI銀行監督は今、一貫性の試練に直面している
主要な争点は、監督上の柔軟性と、州および連邦機関をまたぐ一貫した期待の必要性との間にある。
CSBSは意図的に検査官の裁量を維持している。フレームワークは、機関の規模、複雑性、リスクプロファイル、実際のAI利用を考慮する。
このような調整により、小規模な機関を過度なコンプライアンス業務から守ることができる。AIへの関与が限定的なコミュニティバンクに、大手事業領域全体でモデルを展開する複雑な金融グループと同じプログラムを求めるべきではない。
州ごとの柔軟性は、米国の金融監督の構造も反映している。州機関は、銀行、貸し手、送金事業者、住宅ローン会社、その他の規制対象事業者を、それぞれ異なる組み合わせで監督している。
その代償は予見可能性である。各機関がフレームワークの利用方法を決める場合、機関側は検査が同一の範囲や基準に従うと想定できない。
ある検査官はCore Examiner Guideを予備的なスクリーニングとして扱うかもしれない。別の機関は、資料提出要請と検査業務をパッケージ全体に基づいて構築する可能性がある。
この懸念は理論上のものではない。CSBS会長のRhoshunda Kellyはこれまで、監督上の期待を一貫して実施すること、および州・連邦規制当局のより明確な連携を求めてきた。
連邦の立場は、さらに別の層を加える。2026年4月、Federal Reserve、Office of the Comptroller of the Currency、Federal Deposit Insurance Corporationは、共同のモデルリスク・ガイダンスを改訂した。
revised federal guidanceは、モデルへのエクスポージャー、組織規模、業務上の複雑性に応じたリスクベースのアプローチを強調している。開発、検証、モニタリング、ガバナンス、インベントリ、文書化、ベンダー製品を対象とする。
ただし、このガイダンスは、生成AIおよびエージェント型AIを新規かつ急速に進化する技術だとしている。そのため、これらのシステムを文書の正式な適用範囲から除外している。
この除外は、銀行が生成AIを統制なしに利用できることを意味しない。ガイダンスは、適用範囲外のツールに対する適切な監督は、より広範なリスク管理およびガバナンスの慣行によって決まるべきだとしている。
それは境界線の問題を生じさせる。従来型の統計システムは、連邦政府のモデルリスクに関するガイダンスの適用対象に明確に該当する可能性がある。同じワークフローに接続された生成AIアシスタントには、別の枠組みから導かれる統制が必要になる場合がある。
CSBSは、その隔たりにおける発見の側面に対応している。審査官向けガイドは、初期レビュー手続きの中に生成AIと新たなユースケースを明示的に含めている。
この2つのアプローチは、直接的に矛盾するものではない。連邦機関はモデルに関する特定のガイダンスの範囲を狭める一方、CSBSは既存の監督リソースを参照する、より広範な審査官向け枠組みを整備した。
それでも企業は、この違いを実務に落とし込まなければならない。あるシステムが対象となるモデルなのか、AI対応プロセスなのか、第三者サービスなのか、あるいはそれらの複数に該当するのかを把握する必要がある。
ベンダーへの依存は分類をさらに難しくする。金融機関は、学習データ、基盤となるコード、評価手法、または完全な性能エビデンスにアクセスできない場合がある。
連邦ガイダンスは、ベンダー固有のコンポーネントが検証上の課題を生みうると指摘している。それでも組織には、概念的妥当性、設計、開発データ、性能、継続的な目的適合性を理解することが求められる。
生成AIベンダーは、そのすべての情報を提供しない可能性がある。また、その製品は従来の銀行モデルより頻繁に変化する可能性があり、ときにはプロバイダーが全面的に管理する更新を通じて変更される。
CSBSは、州の審査官がその不確実性を検証する手段を提供する。ノンバンク向け補足資料と文書提出要請により、適用可能な場合には、ベンダー監督を消費者保護、業務統制、モデルリスクと結び付けられる。
連邦機関も第三者監督を見直している。2026年9月の第三者に関する提案は、個別の関係に合わせた原則ベースのアプローチを求めている。
この提案は拘束力を持たず、パブリックコメントも引き続き手続きの一部である。それでも、AI監督と並行してベンダー監督が変化していることを示している。
そのため金融機関は、複数の変動する層に直面している。州ごとの実施状況、連邦モデルの境界、進展中の第三者ガイダンス、そして基礎となる金融活動を規律する法律を追跡しなければならない。
最善の防御策は、名称ではなくユースケースに従う統制システムである。ソフトウェアをcopilot、assistant、algorithm、workflowと呼ぶことによって、リスク分析のすべてが決まるべきではない。
目的、権限、データアクセス、顧客への影響、可逆性は、より持続性のある判断基準となる。ベンダーが基盤モデルを変更しても、これらの要素は引き続き重要である。
実務的なプレイブックにも法的不確実性は残る
この枠組みは審査官の対応力を高めるが、AIを用いた銀行監督をめぐる権限、執行、標準化の問題を解決するものではない。
CSBSは、この枠組みが裁量的なものであると述べている。また、各州の機関が、資料を監督プログラムに取り入れるかどうか、またどのように取り入れるかを管理するとしている。
これは、直ちに全国的な影響が生じるという主張を限定する。公表されたからといって、すべての州の審査官が次の検査サイクルで各ワークシートを使い始めるわけではない。
この枠組み自体も、新たな法的義務を生み出すものではない。審査官の指摘は依然として、AI活動を既存法、安全性・健全性上の懸念、消費者保護要件、または確立された監督上の期待と関連付けることができる。
この区別は規制対象企業にとって重要である。任意と表示された文書であっても、審査官がどのように証拠を集め、別の拘束力ある要件に違反したかどうかを評価するかに影響を与えうる。
実務上の負担は、正式な執行措置より前に生じる可能性がある。金融機関は、より広範な文書提出要請を受けたり、追加の質問に直面したり、複雑なシステムを説明する専門人材を必要としたりする可能性がある。
小規模な企業にとっては、その準備が難しいかもしれない。中核処理事業者やテクノロジーベンダーに大きく依存する一方、詳細なAI文書を入手するための交渉力が弱いことが多い。
ベンダーは、モデルの挙動、プロンプトの取り扱い、下請け事業者、更新統制を明らかにせず、標準的な監査報告書だけを提供する場合がある。金融機関は、部分的にしか観測できないリスクを理解する責任を負い続ける。
リスク階層化は別の不確実性をもたらす。任意のワークシートは比例的なレビューを促すが、リスク分類は影響、自律性、データ、統制の有効性に関する前提に依存する。
2人のレビュー担当者が、同じユースケースを異なる方法で分類しても合理的な場合がある。文書作成支援アシスタントは、従業員が機密性の高い顧客データを入力したり、捏造された法的分析に依存したりするまでは、低リスクに見えるかもしれない。
顧客向けの出力は、さらに複雑さを加える。チャットボットは正式な信用判断を行わない場合でも、不正確な回答は苦情、手数料、口座へのアクセス、消費者による自身の権利の理解に影響を与えうる。
エージェント型システムは、より大きな業務上のリスクをもたらす。人による承認が意味を持つのは、レビュー担当者に有害な行為を止めるための十分な情報、時間、権限、専門性がある場合に限られる。
ログにも実質が必要である。AIシステムが行動したことを示す記録だけでは、その判断が適切だったことも、その推論を再構成できることも証明しない。
既存の監督リソースに依拠するこの枠組みは合理的だが、重複したレビューを生む可能性がある。1件のAI導入が、サイバーセキュリティ、プライバシー、第三者リスク、業務レジリエンス、消費者コンプライアンス、モデルガバナンスにまたがることがある。
チームが連携すれば、その重複はカバレッジの向上につながる。一方で、責任分担が不明確なままであれば、重複した要請や相反する統制上の期待を生む可能性もある。
エビデンスの品質も別の課題である。金融機関は、ベンダーの主張と、独立したテスト、社内評価、本番環境のモニタリング、顧客の結果を区別すべきである。
プロバイダーが示すデモは、銀行の環境における性能を立証するものではない。テストは、金融機関の利用者、データ、ワークフロー、障害モード、法的義務を反映すべきである。
生成出力には、従来の精度を超えた評価が必要である。レビュー担当者は、捏造、有害な指示、データ漏えい、一貫しない扱い、プロンプト攻撃、不正な行為への耐性を評価する必要があるかもしれない。
システムが急速に変化する場合、継続的なモニタリングも難しくなる。導入前に実施した統制評価は、モデル、データソース、プロンプト、統合が変更された後には意味を失う可能性がある。
このため、インベントリにはライフサイクル上のトリガーを含めなければならない。金融機関は、どの変更について再テスト、法務レビュー、ベンダー評価、経営陣の承認、または停止を要するかを定義すべきである。
単純なコンプライアンス・チェックリストとして説明するCSBS AI framework explainedでは、この点を見落としてしまう。その価値は、システムが恒久的に安全だと認証することではなく、検討を構造化することにある。
また、すべての州機関がこのパッケージを一貫して解釈するという証拠は、まだ存在しない。初期の検査実務によって、この枠組みが収れんを生むのか、それとも管轄ごとのばらつきをさらに増やすのかが明らかになるだろう。
金融機関は、両極端の2つの誤りを避けるべきである。裁量的な枠組みを直ちに拘束力ある規則として扱うべきではなく、無関係なガイダンスとして退けるべきでもない。
より正確な理解は、その中間にある。CSBSは共通の監督用語と再利用可能なプロセスを作り出した。導入、解釈、執行は引き続き分散されている。
枠組みの重要性を示す3つのシグナル
この枠組みの実際の影響力は、州による導入、検査実務、進展する連邦ガイダンスとの連携を通じて明らかになる。
第1のシグナルは、州機関による正式または運用上の導入である。公表通知、改訂された検査マニュアル、新たな文書提出要請、審査官研修は、枠組みがどこで有効化されるかを示す。
州は、この枠組みを重要なものにするために新たな規制を発行する必要はない。通常の検査にその質問を組み込むことで、企業の準備方法や審査官による高リスク用途の特定方法を変えられる。
広範な導入は、全社横断の単一エビデンスシステムを構築する根拠を強める。導入が断片的であれば、ガバナンス記録を管轄区域ごとの期待に照らして対応付ける必要性が高まる。
第2のシグナルは、実際の検査の内容である。金融機関は、審査官がまずインベントリとガバナンスに重点を置くのか、それとも特定のユースケースのテストに素早く踏み込むのかを注視すべきである。
ベンダー契約、モデル文書、出力サンプル、インシデント記録、リスク評価に関する要請は、どのセクションが実務上最も重視されるかを明らかにする。
エージェント型統制への注目は、特に重要となる。許可された行為、人によるチェックポイント、監査ログ、可逆性、停止メカニズムに関する質問は、より深い業務上の精査を示すことになる。
検査はまた、レビュー担当者が従業員による非公式な利用をどのように扱うかも明らかにする。承認済みの企業システムだけに焦点を当てた枠組みでは、重大なデータおよび判断リスクを見逃す可能性がある。
第3のシグナルは連邦レベルでの連携である。連邦機関は、現在のモデルリスクに関するガイダンスの範囲を狭める一方で、AIと第三者関係に関する追加の作業を進めている。
OCCは4月、各機関が生成AIおよびエージェント型システムを含むAIに焦点を当てた追加的な情報収集を計画していると述べた。その結果として生じる要請やガイダンスは、連邦アプローチがCSBSと重なる領域を明確にする可能性がある。
連携したアプローチは、連邦監督も受ける州認可銀行にとって不確実性を低減するだろう。定義や文書化基準が異なれば、より多くの調整作業が生じる。
GAOが信用組合の監督に継続的な注意を向けていることも、有用な指標となる。より広範なモデルリスク・ガイダンスに関する同機関の勧告は、金融機関の種類によって監督のカバレッジが依然として不均一であることを示している。
これらのシグナルのいずれも、金融機関に待機を求めるものではない。この枠組みはすでに、特定の機関による導入判断にかかわらず、健全なガバナンスを支える準備作業を示している。
金融機関は、インベントリを検証し、説明責任を負う担当者を割り当て、ユースケースを分類し、承認基準を文書化できる。また、ベンダーの記録が、審査官が尋ねる可能性の高い質問に答えられるかもテストできる。
影響の大きいシステムには、その実際の目的に結び付いた結果モニタリングが必要である。不正検知ツールは、技術的なベンチマークだけでなく、不正の結果と顧客への混乱に照らして評価すべきである。
顧客向けシステムには、代表性のある出力レビューが必要である。チームは、成功したデモだけを記録するのではなく、失敗、修正、苦情、変更の証拠を保存すべきである。
エージェント型の導入には、明確に限定された権限が必要である。組織は、どの行為に承認が必要か、どの行為を元に戻せるか、インシデント時に誰がシステムを無効化できるかを定義すべきである。
取締役会と上級管理職が、すべてのモデルアーキテクチャを習得する必要はない。しかし、重要な用途、未解決のリスク、インシデント、ベンダーの制約、受け入れられた例外について、正確な報告を受ける必要がある。
同じ規律は従業員にも役立つ。明確なルールは、承認済みシステムと禁止された利用を区別し、従業員が予期しない挙動をどのように報告できるかを説明すべきである。
CSBS AI supervisory frameworkが最も重要になるのは、こうした運用習慣を変える場合である。よく整理されたポリシーフォルダだけでは、導入済みシステムに対する統制を示すことはできない。
テクノロジーベンダーへのメッセージも同様に直接的である。金融機関は、データの取り扱い、テスト、システム変更、下請け事業者、ログ、人による介入に関する、より明確な文書をますます求めるようになる。
信頼できるエビデンスを提供できないベンダーは、製品の性能が高くても承認を得にくくなる可能性がある。調達チームには、導入後も継続的な監督を支える契約上の権利が必要である。
金融機関にとって、次の段階は焦点を絞った準備状況レビューである。組織は、重要なAI利用をすべて特定し、責任者と結び付け、そのリスク分類を裏付けるエビデンスを提示できるだろうか。
ベンダーのシステムが何を行うのかを、営業資料だけに全面的に依存せず説明できるだろうか。システムが障害を起こした場合、あるいは権限のない行為を行った場合に何が起こるのかを示せるだろうか。
これらの問いは、新たなフレームワークが実務上何を意味するのかを端的に表している。州による実施状況は依然として不透明だが、求められる証拠はより明確になりつつある。
次回の検査で、すべてのCSBS文書が用いられるとは限らない。それでも、根底にある同じ問いは問われうる。すなわち、その機関は自社の事業内で稼働するAIを理解し、管理できているのか。
