AIと金融 / DORAが要請する運用レジリエンス / AIガバナンスをログと契約から組み直す雑感

0　はじめに

　金融領域のAIガバナンスを語るとき、議論の主役は往々にしてEU AI Actである。もっとも、現場の事故は「モデルの倫理」だけでは起きない。クラウド障害、APIの仕様変更、監視の穴、権限設定ミス、サプライチェーン攻撃、そして委託先の倒産。要するに、運用が壊れてサービスが壊れる。そのとき、法的責任の議論は「AIが何を判断したか」から、「誰がどの部品をどの契約で動かしていたか」へ一気に引きずられる。

　この点で、EUのデジタル運用レジリエンス規則、通称DORAは、AI規制としては読まれていないにもかかわらず、AIガバナンスの足場を先に固める規制である。DORAは金融主体に対し、ICTリスクを統合的に管理し、重大インシデントを報告し、レジリエンスをテストし、第三者委託リスクを契約と退出設計で制御することを要求する。適用開始は2025年1月17日であり、AI Actの多くの規定が2026年以降に適用開始されることを踏まえると、DORAのほうが早い（1）。

　以下では、DORAの具体的な要求事項を確認しつつ、AIガバナンスへの含意を整理する。

1　問題の所在　AIはモデルではなく運用で壊れる

　AIの法的ガバナンスは、説明可能性、差別、透明性といった論点に牽引されがちである。もちろん重要である。しかし、金融領域のAIは、単体のモデルとして置かれていることは稀であり、データ供給、特徴量生成、モデル実行基盤、監視・アラート、意思決定システム、顧客接点、ログ保管などが連接した運用システムとして存在する。しかも、その相当部分が外部のICTサービスに依存する。

　この構造の下では、事故の形も独特になる。外部データの欠損が入力分布を歪め、信用判断モデルが急に保守的になる。モデル更新のデプロイが部分的に失敗し、旧版と新版が混在して意思決定が揺れる。運用監視がモデル出力の異常を捉えられず、被害が拡大する。責任論が「誰が悪いか」以前に、「何が起きたか」を確定できない。原因が各所に散り、しかも委託先にある。ログがなければ時間軸すら再構成できないし、契約がなければ責任の所在も定まらない。

　DORAは、この運用の問題を規制対象として正面から扱う。

2　DORAの射程と適用範囲

　DORAは、金融主体のデジタル運用レジリエンスを、ネットワーク・情報システムの安全確保に必要なICT能力の全体として定義する（2）。対象がサイバーセキュリティそれ自体ではなく、業務プロセスを支えるICTの継続性と信頼性である点が肝要である。したがって、DORAの実装は、情報セキュリティ部門だけの仕事になりにくい。業務部門、調達、法務、リスク管理、監査が同じ土俵に上がる。

　適用範囲は広い。信用機関、決済機関、電子マネー機関、投資会社、暗号資産サービス提供者、保険会社、クラウドファンディングサービス提供者など、ほぼすべての金融事業体が対象となる（3）。見落とせないのが、これらの金融事業体にサービスを提供するICTサードパーティサービス提供者である。DORAにおけるICTサービスの定義は、ICTシステムを通じて継続的に提供されるデジタルおよびデータサービスを指す（4）。金融機関にSaaSとして提供されるAIソリューションや、AI開発基盤となるクラウドサービスは、明白にDORAの規律対象となる。

3　第三者リスク管理と契約条項

　AIの導入は、第三者依存を増やす。モデルそのものを外部から調達する場合もあれば、学習・推論基盤、監視、データ、さらには生成AI APIを組み込む場合もある。

　DORAが面白いのは、ここで倫理的スローガンを唱えず、冷徹に「最後に責任を負うのは誰か」を固定する点である。金融主体は、ICTサービスを使って業務を回している場合でも、DORA上の義務と金融サービス法上の義務の履行について、常に全面的に責任を負うとされる（5）。「ベンダのブラックボックスだから分からない」は、原理的には許されない。

　そのうえでDORAは、第三者リスク管理を見える化するための装置として、登録簿を要求する。金融主体は、ICT第三者提供者との契約について登録簿を維持・更新し、当局の求めに応じて提示できなければならない（6）。さらに、重要機能を支えるICTサービスについては、退出戦略を整備し、計画をテストし、代替策と移行計画まで用意することが要求される（7）。AIシステムで言えば、このモデルAPIを止めたら何が止まるか、代替モデルはあるか、学習データとログを引き上げられるか、を平時に設計図として持てという話になる。

　契約条項の法定化も見逃せない。DORA第30条は、金融機関とICT提供者との契約に含めるべき条項を具体的にリストアップしている。データの可用性・真正性・完全性・機密性の保護とデータの復旧・返還に関する規定、サービスレベル記述と障害時の支援義務、金融機関および監督当局がICT提供者の施設に立ち入り監査を行う権利（8）。これらが欠けている場合、契約自体が規制違反となる。委任規則2024/1773は、契約ライフサイクル全体を覆う構造を求め、退出戦略・終了プロセスの明確化を要請している（9）。

4　ログ要件

　事故が起きたとき、何が起きたかを確定できなければ責任の議論は始まらない。ログがなければ時間軸が確定しない。

　DORAの周辺法である委任規則2024/1772は、重大インシデント報告の前提として、インシデントの継続時間の測定方法を定める。インシデントが発生した時点から解決した時点までを測定するのが原則だが、発生時点を確定できない場合は検知時点から測定することになる（10）。逆に言えば、ログがなければ発生時点を確定できず、責任の範囲も曖昧になる。

　さらに委任規則2024/1774は、ログの粒度と目的を統治対象にする。ログの詳細度を目的に整合させ、異常活動の検知を可能にすること、アクセス制御・容量管理・変更管理・ICT運用等に関するイベントをログに残すこと等が要求される（11）。AIシステムで言えば、モデルの版、特徴量定義、推論リクエスト、閾値設定、人的オーバーライド、データ前処理の変更などが、変更管理とログの対象になるべきだという含意が出てくる。

　この点は、AI Actが高リスクAIに求めるログ要求とも噛み合う。AI Actは、高リスクAIがシステムのライフタイムにわたって自動的にログを記録できることを要求する（12）。ログは後で揉めたときの証拠ではなく、揉めないために先に仕込む統治技術である。

5　テスト制度

　DORAのもう一つの特徴は、テストを監査の付録にせず、制度の中心に置く点である。すべてのICTシステムに対し、少なくとも年に1回のリスクベースのテストが必要となる（13）。AIシステムの場合、モデルの堅牢性テストやバイアス評価もこのプロセスに統合されるべきだろう。

　とりわけ、脅威主導型侵入テスト、いわゆるTLPTは注目に値する。金融主体のICT成熟度とリスクプロファイルに応じて実施主体が選定され、実施後の所見と改善計画が当局に通知される。対象は本番環境であり、サプライチェーンに含まれるICTサードパーティ提供者も参加しなければならない（14）。

　AIベンダーにとって、これは自社のシステムが金融機関のTLPTの対象となり、レッドチームによる攻撃シミュレーションを受けることを意味する。AIの攻撃面は、従来型のネットワーク侵入にとどまらない。データ汚染、モデル抽出、プロンプトインジェクション、権限昇格、監視回避、サプライチェーン依存など、モデル層・データ層・運用層が同時に狙われる。TLPTをAIに接続するとは、モデルの変更管理と署名検証、学習・推論パイプラインの権限分離、監視の盲点を攻撃者視点で突く、といった設計に落とすことになる。

6　重要ICTサードパーティへの直接監督

　DORAの革新的な点は、特定のICT事業者を「重要」と指定し、当局の直接的な監視下に置く制度を導入したことにある。欧州監督当局は、金融サービスの安定性と継続性に対するシステミックな影響、金融機関の依存度、代替可能性の程度といった基準に基づき、重要ICTサードパーティサービス提供者を指定する（15）。

　指定された事業者にはリード・オーバーシーアが任命され、情報提供および文書提出の要求、調査およびオンサイト検査、勧告および是正命令、制裁金の賦課といった権限が行使される（16）。制裁金は全世界の年間売上高の最大1%に相当する日歩制裁金となりうる（17）。EU域外に拠点を置く重要ICTサードパーティに対しては、EU域内への子会社設立が義務付けられる（18）。ハイパースケーラーが対象となることは確実視されているが、金融業界で支配的な地位を持つAIプラットフォーマーも、将来的に指定される可能性がある。

7　AI Actとの接合

　規制の接合を考えるとき、まず時間軸が問題になる。DORAは2025年1月17日から適用される。AI Actは2026年8月2日から大部分が原則適用であり、禁止規定等は2025年2月2日、ガバナンスやGPAI関連等は2025年8月2日からの段階適用である。金融領域では、AI Act本体の適用を待つ前に、DORAによって運用と委託の側からAIシステムが規律され始める。

　監督構造にも接続点がある。AI Actは、EU金融サービス法で規制される金融機関が用いる高リスクAIについて、当該金融監督当局が市場監視当局になる旨を定める（19）。金融監督当局が、DORAとAI Actを同じ監督テーブルで見る可能性が高い。企業側の実務論点は二重にやるではなく、同じ材料を別の法目的で使い回すことに収斂する。

　具体的には、DORAで整備するICT資産・委託登録簿を、AI Actの技術文書・品質管理と接続する。DORAのインシデント対応・報告のフローに、AI Actの深刻インシデント報告を吸収する。DORAのテストに、AI固有の攻撃面の評価を組み込む。ここが噛み合わないと、ログは二重化し、監査は二重化し、契約要求は二重化し、現場のコストだけが増える。

8　日本企業への含意

　日本の金融グループがEUで活動する場合、DORAはサイバー規制というより、委託と運用の法定設計図を突きつける規制である。EU域内金融主体にサービス提供する日本のIT企業・AIベンダも、契約条項や監査対応を通じてDORAの影響下に入る。金融向けにAI基盤やAPIを提供する側は、金融機関が責任を負うというDORAの原理を前提に、透明性と可監査性を商品仕様に埋め込む必要がある。

　実務的な設計原理を三つに圧縮する。

　第一に、棚卸しをモデルまで下ろす。ICT資産の棚卸しと委託登録簿は、モデル、データ、プロンプト、閾値、ガードレール、権限、監視指標まで含む形で設計しなければ、事故時に原因が再構成できない。

　第二に、契約を退出可能性の器にする。重要機能を支えるAIサービスについて、データとログの可搬性、監査権、サブ委託の可視化、インシデント協力義務、終了時の移行支援を、最初から契約要件として持つ。DORAが退出戦略のテストまで求める以上、退出は書面ではなく実装対象である。

　第三に、ログとテストを統治の最小単位にする。ログがなければ時間軸も原因も確定しない以上、ログ設計と保全は法務・監査の話であり、同時にMLOpsの話でもある。テストはやったことではなく、回り続けることが重要である。

9　おわりに

　DORAはAI規制ではない。しかし、AIを金融サービスに埋め込むなら、AIの責任帰属は、モデル単体の説明可能性よりも先に、運用の可観測性と委託の可統制性に依存する。DORAはこの前提条件を、金融セクターに限ってだが、法的に強制する。AIガバナンスの議論が原則から実装へ移る局面で、DORAは静かに主役級の仕事をしているように見受けられる。

（マガジン）「AIと法-雑感」

　※目次は以下を参照

note総則規約3条2項前段
3.2 クリエイターが制作したデジタルコンテンツの著作権は、クリエイターに帰属します。