AIシステムによるデータアクセスのセキュリティ

AIシステムによるデータアクセスのセキュリティに新しいモデルは必要ない

私はよく顧客から、「AIシステムがアクセスするデータをどのように安全に保護すべきか」という質問を受けます。

この質問には、たいてい不安が伴います。AIは新しく感じられ、インターフェースもこれまでと異なり、影響範囲も大きいように思えるからです。さらに、「AIデータセキュリティ」や「LLMセキュリティ」と銘打ったツールが増えていることが、AIがまったく新しい種類のデータリスクを生み出しているかのような印象を強めています。

しかし、私の考えは一貫して逆です。

AIを使うという理由だけで、新しい製品を購入したり、新しいセキュリティモデルを採用したりする必要はありません。

必要なのは、すでに理解しているデータセキュリティの原則を、AIシステムにも一貫して適用することです。

AIはなぜ特別に見えるのか。しかし本質は同じ

AIシステムは新しいデータの利用者ではありますが、新しい種類のデータ利用者ではありません。

モデルの学習パイプライン、推論サービス、検索拡張生成（RAG）のワークフロー、自律型エージェントなど、どの形態であっても、根本的な振る舞いは同じです。認証し、データを要求し、処理し、結果を出力します。

データセキュリティの観点では、AIシステムは単なる一つのアイデンティティに過ぎません。

それがサービスアカウントであれ、APIであれ、ジョブやエージェントであれ、必要なデータに対して、必要な感度レベルでのみアクセスを許可されるべき存在です。

多くの組織が犯している誤りは、AIを例外的な存在として扱ってしまうことです。「モデルにはデータが必要だから」という理由で過剰なアクセスを与えたり、データアクセス層ではなく、プロンプトや出力の層で動作するAI専用の制御を後付けしたりします。

どちらの方法も、実際のリスクを解決するものではありません。

本当に問うべきこと

本当に問うべきことは、「AIをどうやって守るか」ではありません。

問うべきなのは、次の点です。

このAIシステムは、どのデータに対して平文でのアクセスを許可されるべきか。

そして同じくらい重要なのが、

どのデータには、平文でアクセスすべきではないのか。

この問いを立てると、問題は一気に見慣れたものになります。

AIシステムが平文で参照する必要のない機微なフィールドは、暗号化、トークン化、またはマスキングされた状態のままであるべきです。本当に必要なデータだけを、意図的かつ明示的に利用可能にすればよいのです。

これはAI特有の考え方ではありません。データアクセスに最小権限の原則を適用しているだけです。

AIを特別扱いせず、アイデンティティとして扱う

成熟した環境では、アプリケーション、分析基盤、ユーザーはすでに「アイデンティティ」として扱われ、それぞれに明確な権限が定義されています。AIシステムも同じモデルに従うべきです。

レポーティング用のダッシュボードに、個人識別番号への生アクセスを与えることはありません。マーケティング担当者に、完全なカード番号を見せることもありません。すべての内部サービスに、顧客データへの無制限アクセスを与えることもありません。

AIシステムも例外ではありません。

AIサービスを一つのアイデンティティとして扱えば、そのAIがどのシステムで、どのフィールドにアクセスできるのかを、フィールドレベルで明確に定義できます。この一貫性こそが、追加のツールではなく、AI導入を安全にする要因です。

AIの代表的なデータアクセスパターンを正しく捉える

多くのAIワークロードは、いくつかの典型的なデータアクセスパターンに分類できます。この視点で見ると、セキュリティ上の判断は驚くほど明確になります。

モデル学習
学習には大量の過去データが必要になることが多いですが、それは生の個人識別情報が必要だという意味ではありません。多くの場合、トークン化や暗号化された識別子を用いても、統計的な価値や関連性を保ったまま学習できます。平文アクセスは例外であるべきです。

推論と予測
推論システムは、結果を生成するために限定的な文脈しか必要としません。完全な機微情報が必要になることは稀です。マスキングやトークン化されたデータで十分な場合が多く、平文アクセスは厳密に管理されたワークフローに限定すべきです。

検索拡張生成（RAG）
RAGシステムは、クエリ時にデータベースやデータウェアハウスから情報を取得します。ここが最も過剰露出が起きやすいポイントです。RAGサービスを一つのアイデンティティとして扱い、フィールドレベルのアクセス制御を適用することで、AIが許可されたデータのみを取得するようにできます。

AIエージェントと自動化
エージェントは複数のデータソースやアクションを組み合わせることが多く、最小権限の重要性はさらに高まります。各エージェントは、デフォルトでは保護されたデータを扱い、平文アクセスは明示的な承認がある場合に限るべきです。

いずれのケースでも、制御すべきポイントはプロンプトではありません。データアクセス層です。

なぜ従来の制御ではここでも不十分なのか

一部の組織は、保存時暗号化やシステム単位のアクセス制御を行っているため、すでに十分だと考えがちです。

しかし、その認識は正しくありません。

保存時暗号化は、ディスク上のデータを保護するものであり、利用時のデータアクセスを制御するものではありません。システムが一度認可されると、データは自動的に復号され、平文で返されます。正当なクエリと、過剰権限や侵害されたアイデンティティによるクエリを区別する仕組みはありません。

IAMによる境界型の制御は、システムに入れるかどうかを決めるものであり、内部でどのデータにアクセスできるかを決めるものではありません。その結果、機微なフィールドが分析ツール、ログ、そしてAIパイプラインにまで広く露出してしまいます。

プロンプトフィルタや出力検査ツールは、データがすでにアクセスされた後で動作します。露出を防ぐのではなく、事後的に検知しようとするだけです。

これらの方法はいずれも、アイデンティティと目的に基づいて、フィールドレベルで機微データへのアクセスを制御するという本質的な問題を解決しません。

これにより実現できること

AIシステムをアイデンティティとして扱い、機微データへのアクセスを一貫して制御すると、いくつかの変化が起こります。

チームは例外対応に頼ることなく、より迅速にAIを導入できます。
データチームは、AI専用のデータコピーを作成する必要がなくなります。
セキュリティチームは、誰がどのデータに、なぜアクセスできるのかを明確に説明できます。
特定のデータ利用者にしか対応しないツールが増え続けることを防げます。

何よりも、AIは特別で危険な存在ではなく、既存のガバナンスとセキュリティモデルの中で動作する一つのワークロードになります。

AIに新しいデータセキュリティカテゴリは不要

AIはデータの利用方法を変えますが、データアクセスを制御する原則を変えるものではありません。

AIで成功する組織は、新しいセキュリティカテゴリを追いかける組織ではありません。技術が進化しても、実証された原則を一貫して適用し続ける組織です。

AIをアイデンティティとして扱う。
アクセスできるデータを決める。
それ以外はすべて保護する。

それは新しいセキュリティモデルではありません。
単に、正しいやり方なのです。