LLMは何が機密かを知りません
大規模言語モデルにはデータの機密性の概念がありません。LLMに公開マーケティングコピーと制限付き取締役会議事録を混在させて入力すると、両方を喜んでレスポンスに織り込みます。一方が世界中と共有可能で、もう一方が指名された3人の経営幹部に限定されていることを知りません。
個人のAIアシスタントではこれで問題ありません。エンタープライズAIワークフローでは深刻な問題です。
組織がナレッジベースをAIに接続する場合 — 内部ドキュメントから取得するカスタマーサポートエージェント、価格戦略を参照する営業アシスタント、ポリシーの質問に答えるHRボット — 取得されたすべてのコンテンツがLLM出力の潜在的なものになります。データ分類がなければ、AIがアクセスできるものとアクセスすべきものの間に境界はありません。
ほとんどのAIプラットフォームはこれを完全に無視しています。データソースに接続し、意味的に関連するものを何でも取得します。関連性は認可と同じではありません。
4つの機密性レベル
JieGouはすべてのナレッジベースに4レベルのデータ分類システムを実装しており、広く採用されている情報セキュリティフレームワークに準拠しています：
Public（グリーン）
誰とでも共有できるコンテンツ — 顧客、パートナー、一般公開。マーケティング資料、公開ドキュメント、公開ブログ記事。検索制限なし。
Internal（ブルー）
全社向けのコンテンツ。内部プロセスドキュメント、チームハンドブック、一般的なお知らせ。組織内の認証済みユーザーはAIワークフローを通じてこれにアクセスできます。
Confidential（アンバー）
特定の部門やチームに制限されたコンテンツ。財務予測、競合分析、製品ロードマップ、HR調査。一致する部門アクセスを持つユーザーのみがConfidentialナレッジベースからチャンクを取得できます。
Restricted（レッド）
指名された個人に限定されたコンテンツ。取締役会資料、M&Aドキュメント、経営幹部報酬データ、法的保留資料。アクセスはユーザーごとに明示的に付与されます。これは最高の機密性レベルであり、取得にはユーザーID検証と明示的なアクセスリストメンバーシップの両方が必要です。
RAG検索レイヤーでの強制
重要な設計上の決定は、JieGouが機密性ラベルをLLMにコンテンツが届く前に強制することです。後からではありません。
データガバナンスを試みるほとんどのプラットフォームは、後処理フィルターとして適用します — LLMは利用可能なすべてのコンテキストを使用してレスポンスを生成し、次にフィルターが出力に機密情報が含まれているかどうかをチェックします。これは根本的に壊れています。制限付きコンテンツがLLMのコンテキストウィンドウに入ると、特定のフレーズが削除されてもレスポンスに影響を与えます。モデルは既にデータを「見て」いるのです。
JieGouのアプローチは異なります。RAGクエリが実行される時：
- ユーザーIDが解決される — リクエストユーザーのロール、部門、明示的なアクセス付与がロードされます
- ナレッジベースの機密性ラベルがチェックされる — 接続された各KBに分類レベルがあります
- 検索前フィルタリングが行われる — ユーザーのクリアランスレベルを超えるナレッジベースのチャンクがベクター検索から完全に除外されます
- クリアランスされたコンテンツのみがコンテキストウィンドウに入る — LLMは見るべきでない制限付きデータを決して見ません
これにより、ナレッジベースをクエリするサポートエージェントはPublicとInternalコンテンツを取得しますが、ConfidentialのHRドキュメントやRestricted取締役会資料は見ません — たとえそれらのドキュメントがクエリに意味的に関連していても。
機密性フィルタリングの監査証跡
すべての機密性フィルタリングイベントはJieGouの不変監査証跡に記録されます：
- どのユーザーがクエリを開始したか
- どのナレッジベースがフィルタリングされたか、その理由
- 除外をトリガーした機密性レベル
- タイムスタンプとリクエスト相関ID
これはコンプライアンスにとって重要です。監査人が「AIワークフローが制限付きデータを露出しないことをどのように保証していますか？」と尋ねた時、答えはポリシードキュメントではなく、すべての強制アクションのクエリ可能なログです。
他のプラットフォームの対応方法
| 機能 | 一般的なAIプラットフォーム | JieGou |
|---|---|---|
| データ分類ラベル | なし | 4レベル（Public、Internal、Confidential、Restricted） |
| ナレッジベースごとの機密性 | 利用不可 | KBごとに設定 |
| 検索前フィルタリング | なし — 後処理のみ | はい — LLMコンテキスト前にチャンクを除外 |
| ユーザークリアランスマッチング | ユーザーレベルのデータアクセス制御なし | ロール + 部門 + 明示的付与 |
| 機密性監査証跡 | ログなし | フィルタリングイベントごとの不変ログ |
| 指名個人アクセスリスト | サポートなし | Restrictedレベルでサポート |
ほとんどのプラットフォームは接続されたすべてのデータを同等にアクセス可能として扱います。一部は機能全体への基本的なロールベースアクセスを提供しますが、ナレッジベースからRAGパイプラインレベルで機密性分類を適用するものはありません。
10層ガバナンススタックの一部
データ分類はJieGouのガバナンスアーキテクチャの1つのレイヤーです。他の9層と分離してではなく、連携して機能します：
- 信頼度しきい値 — 低信頼度の出力がユーザーに届く前にエスカレーション
- 承認ゲート — 機密アクションが人間のレビューのために一時停止
- PII検出 — LLM処理前に個人情報をトークン化
- 信頼エスカレーション — パフォーマンス履歴に基づいてエージェントが自律性を獲得
- ブランドボイスガバナンス — 出力が組織のボイスガイドラインに一致
- 部門スコープRBAC — 6ロール、20権限、部門分離
- データ分類 — ここで説明した4レベル機密性システム
- 監査証跡 — すべての決定が完全なトレーサビリティで記録
- 品質モニタリング — ドリフト検出付きの継続的スコアリング
- コンプライアンスコントロール — 412ポリシー + 17 TSCコントロール
これらのレイヤーは組み合わさります。クエリは信頼度しきい値を通過してもデータ分類でフィルタリングされる場合があります。出力は機密性チェックをクリアしても承認ゲートで保留される場合があります。多層防御は単一のレイヤーが全負担を担わないことを意味します。
なぜ今これが重要か
組織がAIをシンプルなチャットボットから部門ワークフロー — サポートトリアージ、営業支援、HRプロセス、財務分析の自動化へスケールするにつれ、これらのシステムを流れるデータはますます機密性が高くなります。「意味的に関連する」と「このユーザーに認可されている」のギャップが責任問題になります。
AIワークフローのデータ分類はあれば良いものではありません。実際のエンタープライズデータを信頼できるAIプラットフォームと、公開向けユースケースに限定されるものとの違いです。