AIが高速にエンタープライズに入り込んでいる。AIチャットの実験として始まったものが、今や実際のワークフローや生産性ツールに入り込み、エージェント機能として業務の一部になりつつある。この変化がCIOに新たな課題をもたらしている。問いは「ビジネスがAIを望むかどうか」ではない。「企業が既に使っているAIをどうガバナンスするか」だ。
ビジネス部門はスピード、利便性、即時の生産性向上に引き寄せられる。社員は自分でミーティングを要約し、コミュニケーションを下書きし、データを分析し、コードを生成し、ワークフローを自動化する方法を見つけている。社員からすればAIは仕事を速くするツールだ。ITから見れば、かつてのシャドーITがシャドーAIとして再来しているように映る。
この緊張は現実だ。ITは物事の進展を遅らせる部門として映りやすい。それは、CIOがサイバーセキュリティリスク、データ漏洩、IDの管理、監査可能性、ワークフロー承認、そしてAIが提案から行動に移るときの説明責任を含むリスク全体像を見て進めるからだ。だからこそ、オペレーティングモデルが重要なのだ。AIがどのように企業に入るか、意思決定がどう行われるか、誰が成果を所有し、どこに説明責任があるか——それを決めることがAI時代の任務の核心だ。
統制を失わずにAIを導入することは難しい
AIが個人の生産性を超えてビジネスプロセスに入り込むと、状況が変わる。ミーティングを要約するツールと、ダッシュボードを確認して意思決定を推奨するツールは同じではない。データをレポート用に取り出すだけのツールと、ファイルを移動し、後続の処理を起動し、例外を承認するツールは根本的に違う。後者になった瞬間、リスクの性格が変わる。
本当の課題は、どのユースケースを素早く進め、どれに厳しい管理が必要かを判断することだ。すべてに重い審査を課せばビジネス部門はITを迂回する。かといって何でも承認すればリスクは積み上がる。ITの準備ができているかどうかは、ツールを速く立ち上げられるかではなく、組織がそのツールの影響範囲と説明責任を理解しているかで決まる。
多くのガバナンスモデルが機能しない理由はシンプルだ。テクノロジーの導入スピードについていけないほど硬直しているからだ。AIはその問題を一気に表面化させる。だからといってガバナンスを緩めるべきではない。ガバナンスはAIの実態に合わせて動ける、実践的なものでなければならない。ここで有用なのが、NISTのAIリスク管理フレームワークだ。AIリスク管理を一度限りのコントロールではなく、継続的な組織の規律として扱っているからだ。
AIユースケースを評価する際は、名称ではなく何ができるかで評価すべきだ。問うべきは、次の3つだ。
1)そのツールはどのデータにアクセスできるか？
2)どんな行動を取れるか？
3)間違えたときの影響は何か？
AIのリスクレベルは用途によって大きく異なる。承認済みの情報を検索・要約するだけなら比較的低リスクだ。人間がレビューするコンテンツの下書きはその次のレベル。そして、財務管理や規制対象業務に関わる推奨になれば、管理を一段引き上げる必要がある。さらに、ファイルの移動、ワークフローの変更、トランザクションの承認ができるなら、まったく別の扱いが必要だ。
具体例を挙げると、管理されたクラウド環境で共有ダッシュボードをホストすることと、個人のデスクトップ上のAIエージェントが企業データに接続して行動することは根本的に異なる。前者はIDとアクセス管理、ログを通じてガバナンスできる。後者は個人の実験として始まっても、不整合なデータや業務上の意思決定に触れれば、すぐに企業全体の問題になる。
ここで重要なのが「ヒューマン・イン・ザ・ループ」の設計だ。ツールが実行できるからといって、重要な決定や承認が静かに自動化に流れ込んでいいわけではない。誰かが決定と成果に対して説明責任を持ち続ける必要がある。ID管理、ログ、エンドポイント保護——AIの時代、これらの重要はさらに高まる。
Verizonの2025年データ侵害調査レポートは過去最多の1万2195件の侵害を分析している。これはAIとは直接関係ないが、エンタープライズ環境がすでに高リスクであることを示している。その上でAIを導入すれば、利便性と引き換えに攻撃者にとっての悪用機会も増える。
答えは「ノー」ではなく、適切な管理で進めることだ
重要度の低いユースケースはベーシックなレビューを経た軽量なプロセスで進めればいい。だが、リスクの高いユースケースでは、より深い審査と明確なオーナーシップが必要だ。目標は官僚主義ではない。回避できるリスクを未然に防ぎ、AI関連の決定がその場限りにならない構造を作ることだ。
AIの需要には方針だけでなく、構造が必要だ
AIガバナンスの議論が進まない組織に共通するのは、理論にとどまっていることだ。方針を定めるだけでは解決しない。需要がスケールする前に、実際に機能する評価の仕組みが必要だ。部門をまたいだ意思決定の場を早期に設けることで、テクノロジーを超えた問題にも組織全体で責任を持てるようになる。
すべてのAIリクエストが同じ扱いを受けるべきではない。内部メモの下書きに使いたいチームと、契約のレビューや例外の承認、文書の移動を行うエージェントを求めるチームでは、必要な審査のレベルがまったく異なる。前者はガードレールを設けた上で素早く進めていい。後者は本番環境に入れる前に、厳しいレビューと明確なオーナーシップが必要だ。
AIリクエストを受け付けるプロセスは、需要を記録するだけでは足りない。個人の生産性ツールなのか、ワークフロー支援なのか、行動を起こすエージェントなのか——早期に分類することが重要だ。どのシステムやデータに触れるか、アウトプットは助言か業務上の決定か、誰がオーナーになるか。こうした問いに事前に答えることで、後から問題が大きくなるのを防げる。
承認で終わりにしてはいけない。本番環境に入ったユースケースには、オーナー、ログ、定期レビュー、振る舞いが変わったときのエスカレーション経路が必要だ。低リスクとして始まったものが予想以上に早くハイインパクトになることがある。
AIを単なるテクノロジーの実験として扱えば、やがて制御できなくなる。AIを規律を持って導入した組織と、統制なしに広がるに任せた組織——その差が、数年後に競争力の差として現れる。