ISO/IEC 42001という「管理システム」──AIガバナンスを「手続」に落とすという発想

０　はじめに

　今回は以下の続編である。いずれも１分で読める内容である。

　国際規格標準化・認証は現時点では世間では知名度はほとんどないといえる。しかし、AI時代においては法が追いつかない領域が増え、かつ、各国で法制度が分断していく。これは既定路線であると考える。そうした中で白羽の矢が立つのは国際規格標準化・認証であると確信している。

　AIガバナンスは、結局のところチームスポーツである。どれほど立派な原則や倫理方針を掲げても、事故（法的・社会的・技術的な失敗）が起きる典型的なポイントは、戦略から実装、実装から運用、運用から法務・リスク・セキュリティへといった「受け渡し（handoff）」の隙間である。ここが裂けると、最後は「誰が何を決めたのか分からない」という、組織が最も嫌う形で顕在化する。

　ISO/IEC 42001は、この隙間を「管理システム（management system）」として縫い合わせることを要求する標準である（注1）。そして重要なのは、これがモデルの精度やアーキテクチャを直接規定する“技術仕様”ではなく、組織の意思決定と運用を回す枠組み（方針・プロセス・責任分担・記録）を規定する点である（注1）。

1　「AI管理システム」という発想の射程

　ISO/IEC 42001は、AIを開発する組織だけでなく、AIを提供する組織、そしてAIを利用する組織も射程に入れている（注1）。この点で、AIを研究室の成果物ではなく事業運用の構成要素として扱う立ち位置が明確である。

　AIは部品であると同時に、振る舞いが環境に依存して変化しうる部品である。学習・更新、データの変動、運用環境の変更、利用者の使い方のズレが、同じモデルでも違う事故を起こす。ゆえに、AIを「一度リリースして終わり」の発想で扱うと、法務・監査・現場が機能不全に陥る。管理システムは、ここを“継続的改善”として制度化するための道具立てである（注1）。

2　法は「結果」だけでなく「過程」を問う

　AIと法の議論は、しばしば「誰が責任を負うのか」という結論に引き寄せられる。しかし、実務では、責任論の前に「説明可能な過程」が問われる局面が多い。規制当局・取引先・監査・裁判所が見たいのは、神学論争ではなく、(i) リスクを事前にどう把握し、(ii) どう意思決定し、(iii) どう記録し、(iv) 事故時にどう是正したか、という履歴である。

　この意味で、ISO/IEC 42001の“管理システム”は、法的リスクを「条文」ではなく「手続」に翻訳する装置として読める。もちろん、手続が整っていれば免責されるわけではない。しかし、手続が存在しない（あるいは存在する体裁だけで運用されていない）場合、説明責任は一気に崩れる。管理システムは、少なくとも「説明責任の土台」を作る。

3　“CEO向けマニュアル”が示す、失敗の起点

　ISO/IEC 42001が面白いのは、技術者だけに向けた標準ではなく、経営層・CIO/CTO・CISO・CRO・GC（法務責任者）を含む複線的な意思決定構造を前提にしている点である（注2）。実務でAIが揉めるのは、モデルの良し悪しよりも、どのリスクを受け入れるか（risk appetite）、誰が止める権限を持つか、止めた事実をどう記録するか、が曖昧なときである。

　実務向け資料では、AIガバナンスの失敗が“部門の境界”で起きること、ゆえにサイロ化した実装ではなく横断的協働が必要であることを強調されていることが多い（注2）。これは、耳が痛いほど正しい。AIは、法務だけで完結しないし、開発だけでも完結しない。だからこそ、管理システムという“共通言語”が必要になる。

4　最初にやるべきは「AI棚卸し」である

　ガバナンス以前に、統治対象が分からなければ統治できない。最初に必要なのは、AIの棚卸し（AI inventory）である。自社開発モデルだけでなく、SaaS、ベンダー組込み、外部API、社内ツールの裏側で動く“半AI”まで含めて、一覧化することが重要であるように思える。

　この棚卸しができた瞬間に、議論の質が変わる。「生成AIが怖い」ではなく、「どの業務で、どの入力を、どの出力に使い、誰が最終判断者で、誤りの影響は何か」という具体の問題になる。ある実務資料でも、基礎フェーズとして横断チームの編成、AIインベントリ、初期リスク評価、リスク許容度の設定を並べている（注2）。この順序は、綺麗事ではなく、現場の生存戦略である。

5　リスク管理を「書類」から「意思決定」に戻す

　AIのリスク管理は、放っておくと“紙の儀式”になる。チェックリストを埋め、リスクレジスターを作り、会議体の議事録を残して満足する。しかし、重要なのは「誰が何を判断し、何を却下し、何を条件付きで許容したか」である。

　実務資料が提示するAIリスクレジスターの肝は、結局、リスクの識別・評価・対応だけでなく、受容（acceptance）とエスカレーションの設計にある（注2）。法務の視点でいえば、ここが「後で説明できる」かどうかの分水嶺である。AIの不具合はゼロにはならない（むしろゼロと言う組織が危ない）。ゼロにできない以上、「どういう基準で受容したのか」を説明できる形にしておく必要がある。

6　国内外の枠組みは「リスクベース」で収斂している

　日本の「AI事業者ガイドライン（第1.0版）」も、過度な対策が利活用を阻害しうることを踏まえつつ、リスクの大きさに応じて対策の程度を対応させる「リスクベースアプローチ」を強調している（注4）。米国NISTのAI RMFも、フレームワーク自体はリスク許容度を規定しないが、リスク許容度が法規制等の要請に左右されうること、そして文脈依存であることを明確に述べている（注3）。

　EUのAI Actも、リスクに応じた規律を中核に据える（注5）。ここで重要なのは、「規制を知っている」ことではなく、「規制が要求する説明責任の型」が、リスク管理・記録・監督・改善というプロセスに寄ってきている点である。ISO/IEC 42001は、まさにこの“型”を組織に実装するためのテンプレートとして機能しうる。

7　契約・調達は、ガバナンスの“現場”である

　AIガバナンスを議論するとき、ついポリシー文書や委員会設計に目が行く。しかし、実務の現場は、契約と調達である。外部APIやベンダー製品を使うなら、モデルカードの有無、ログ・監査の可否、学習への再利用、データの帰属、インシデント時の連絡義務、サブプロセッサ、国外移転、アップデート時の通知等が、ガバナンスの勝敗を決める。

　実務資料のように、契約テンプレートやベンダー管理プロトコルを“管理システムの部品”として位置付ける発想は、法務的に筋が良い（注2）。ただし、契約条項は万能薬ではない。運用側が守れない条項は、単に組織を脆くする。契約は、運用に落ちる粒度と整合しなければならない。

8　最後は三つの問いに収斂する

　ISO/IEC 42001を導入するにせよ、導入しないにせよ、実務的には次の三つの問いから逃げられないように思える。

　第一に、リスク許容度を誰が決めるのか。これは「CROが決める」のではなく、経営が責任を負う形で決められる必要がある（注2）（注3）。

　第二に、止める権限は誰が持つのか。AIは“便利な自動化”として広がるほど、止める権限が曖昧になる。曖昧なまま事故が起きると、止めなかった者が全員になりうる。

　第三に、何を証拠として残すのか。ログ、データ、評価結果、意思決定、例外処理、インシデント対応、再発防止策。これらが「後から復元できない」形で散逸すると、説明責任は崩れる。

　ISO/IEC 42001は、魔法ではない。だが、AIガバナンスを“精神論”から“運用”へ引き戻すための、かなり強力な道具である。ガバナンスの成熟度とは、理念の高さではなく、手続の耐久性で測られる。要するに、事故のときに折れない骨格を作る話である。そこに法務が関与するのは、条文を振りかざすためではなく、説明責任の骨格を「証拠の残る形」にするためである。

　以上の内容は、前回の透明性確保において資するものといえる。

（その他参考）

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

※目次は以下を参照

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