ローカルAIなら安全とは限らない｜導入前の確認項目

はじめに

ローカルAIはデータを社外へ送らない構成を選びやすい一方、置くだけで安全になるわけではありません。モデル取得元、入力保存、利用者権限、端末管理、ログ、脆弱性対応を自社で担います。クラウドAIも、契約、保存設定、学習利用、接続先を適切に管理すれば選択肢になります。判断は設置場所ではなく、データの全経路と運用責任で行います。

経済産業省のAI事業者ガイドライン第1.2版は、AIのライフサイクルを通じてプライバシーとセキュリティを扱い、システム構成やデータ処理を文書化する考え方を示しています。個人情報保護委員会も、生成AIへ個人データを入力する際、利用目的や提供事業者による取扱いを確認するよう注意喚起しています。

「ローカル」と「クラウド」で責任が移る

どちらも一長一短です。機密性だけでなく、可用性、更新速度、運用人材、費用、既存システム接続を含めて判断します。基盤全体の選択はクラウド・オンプレ・エッジの判断軸も参照してください。

導入前に確認する六つの項目

1. データ経路

利用者端末からモデルまで、入力、添付、検索、キャッシュ、バックアップ、ログがどこを通るか描きます。モデル本体が社内でも、外部の検索APIや監視サービスへ情報が出る構成があります。

2. データ区分

公開、社内、機密、個人情報などの区分ごとに、利用可能なAI環境を決めます。入力禁止を周知するだけでなく、接続先や権限で制御します。

3. モデルと部品の供給元

モデル、ライブラリ、コンテナ、拡張機能の取得元とライセンスを記録します。更新時は変更内容と安全性を確認し、元へ戻せる版を保持します。

4. 利用者とサービスの権限

誰がどのデータを検索でき、どのツールを実行できるかを分けます。共有アカウントを避け、操作主体を追跡します。エージェントへ操作権限を与える場合は最小権限と承認の設計が必要です。

5. ログと保持

入力全文を無条件に保存しません。障害解析と監査に必要な項目を決め、機密情報をマスキングし、保持期間と閲覧者を制限します。ログ自体が情報漏えい源になるためです。

6. 更新・停止・廃棄

脆弱性対応、モデル更新、証明書更新、容量監視、障害時の代替手段を決めます。利用終了時には、モデルのキャッシュ、ベクトルデータ、バックアップ、認証情報まで削除対象を確認します。

最初に作るデータフロー図

対象業務を一つ選び、利用者、入力データ、モデル、検索先、業務システム、ログ、管理者を一枚に描きます。それぞれに「保存するか」「社外へ出るか」「誰が見られるか」「誰が更新するか」を追記します。

この図があれば、ローカルかクラウドかを抽象的に議論せず、特定のデータと責任に基づいて比較できます。AI-OCRのように原本を扱う業務では、文書処理の6段階にも同じ図を適用できます。

実行チェックリスト

• 入力からログまでデータ経路を描いた
• データ区分ごとに利用可能環境を決めた
• 外部APIと拡張機能を一覧化した
• モデルと部品の取得元を記録した
• 利用者とサービスの権限を分離した
• ログの内容、閲覧者、保持期間を決めた
• 更新失敗時に切り戻せる
• 利用終了時の削除対象が決まっている

まとめ

ローカルAIは有力な選択肢ですが、安全性を自動的に保証しません。クラウドAIも一律に危険ではありません。データ経路、区分、供給元、権限、ログ、運用の六項目を具体化し、自社が負う責任と提供者へ任せる責任を比較して選ぶことが重要です。

参考

• 経済産業省 — AI事業者ガイドライン 第1.2版
• 個人情報保護委員会 — 生成AIサービスの利用に関する注意喚起
• NIST Privacy Framework