データガバナンスと情報セキュリティ

データ分類と入力可否の線引き

最初に行うのは、AIに入力してよいデータの分類です。個人情報、営業秘密、顧客データ、著作物を分類し、入力可否、保存期間、第三者提供、学習利用の扱いを決めます。既存の情報資産分類がある場合は、それにAI利用の列を1つ追加する形が現実的です。

本番運用で必要な技術的統制

本番運用では、ID管理、テナント分離、暗号化、アクセスログ、プロンプトインジェクション対策、出力の情報漏洩検査が必要です。これらは一度に全部そろえるのではなく、扱うデータの区分に応じて必要な範囲を積み上げます。

• ID管理と権限：AI機能へのアクセスを既存のIdPに統合し、退職・異動時に自動で失効させます。共有アカウントは証跡を無意味にします。
• テナント分離：部門やプロジェクト単位でデータを分離し、検索・参照の範囲が越境しないようにします。
• 暗号化と保存先：保存時・通信時の暗号化に加え、データが保存されるリージョンと保持期間を契約で確認します。
• アクセスログ：誰が、いつ、どのデータを対象に、どの出力を得たかを記録します。ログ自体の保護と保持期間も定めます。
• レート制御と費用上限：異常な大量アクセスを検知し、情報の大量抽出と予期しない費用の両方を抑えます。

プロンプトインジェクションへの多層防御

外部文書やWebページを読み込む構成では、その内容に埋め込まれた指示がモデルの動作を変えるプロンプトインジェクションが成立します。入力フィルタだけで完全に防ぐことはできないため、被害が発生しない構成にすることが基本方針になります。

1. 権限の最小化：仮に指示を乗っ取られても、エージェントが実行できる操作の範囲が狭ければ被害は限定されます。第2章の操作分類がそのまま防御になります。
2. 信頼境界の明示：システム指示と、外部から取得した本文を構造的に分離し、本文は「データ」として扱う設計にします。
3. 出力側の検査：外部送信や不可逆操作の直前に、出力内容を検査し、想定外の宛先・命令が含まれていないかを確認します。
4. 人間の承認：社外送信や決済など影響の大きい操作は、必ず人間が最終確認します。
5. 継続的な検証：既知の攻撃パターンを回帰テストに組み込み、モデルやプロンプトの更新時に再実行します。

OWASPが公開しているLLMアプリケーション向けのリスク一覧は、自社構成の点検表として有用です。全項目を満たす必要はありませんが、どの項目を「該当しない」と判断したのかを記録しておくと、監査時の説明が容易になります。

出力側の漏洩検査と記録

入力の統制に比べて見落とされがちなのが、出力側の検査です。検索対象に含まれていた機密文書の内容が、権限のない利用者への回答に引用されるケースは、権限設計の漏れとして実際に発生します。

対策としては、回答に引用元の文書IDを必ず付与し、その文書に対する利用者の閲覧権限を回答返却の直前に再検証する構成が有効です。検索時点の権限チェックだけでは、権限変更直後の隙間を防げません。

また、個人情報や機微情報のパターン検出（DLP）を出力に適用し、検出時には出力の抑止と管理者への通知を行います。誤検知が多いと運用が回らないため、検出ルールは自社データで調整し、抑止と警告の2段階に分けるのが現実的です。

追跡可能な状態をつくる

データを使えるかどうかだけでなく、誰が、どの目的で、どの期間、どの結果を得たかを追跡できる状態にします。これは監査対応のためだけではなく、インシデント発生時に影響範囲を特定するための必須条件です。

入力内容そのものを長期保存すると、ログ自体が新たな機密情報の集積になります。保存範囲と保持期間は、追跡の必要性とリスクを比較して決め、ログへのアクセス権限も業務システムと同等に管理してください。