データ分類・リスク評価マトリクス

顧客データのリスク評価

社内ドキュメントのリスク評価

チャットログのリスク評価

# AIデータガバナンスポリシー v1.0

## 1. 目的と適用範囲

### 目的
本ポリシーは、組織のデータ資産をAIシステムで安全かつ効果的に
活用するための方針を定める。

### 適用範囲
- 対象データ: 顧客データ、社内ドキュメント、チャットログ、
  および今後追加される全データ資産
- 対象システム: 社内LLM（Llama 3 70B）、RAGシステム、
  データパイプライン
- 対象者: データを扱う全従業員

## 2. 組織体制

| ロール | 担当者 | 責任 |
|--------|--------|------|
| データガバナンス委員長 | CTO | 最終意思決定、四半期レビュー |
| 顧客データオーナー | マーケティング部長 | 顧客データのAI利用承認 |
| 業務データオーナー | 各部門長 | 部門データの分類・管理 |
| データスチュワード | データ管理課（2名） | 品質ルール運用、メタデータ管理 |
| データエンジニア | データ基盤チーム（3名） | パイプライン構築・運用 |
| プライバシー担当 | 法務部 | 法規制対応、DPIA実施 |

## 3. データ分類基準とAI利用ルール

### 分類基準
- Level 1（公開）: 外部公開済みの情報
- Level 2（社内）: 社内に限定された情報（PII含まない）
- Level 3（機密）: アクセス制限のある業務情報（PII含む）
- Level 4（極秘）: 経営上の最重要情報

### AI利用ルール
- Level 1-2: 社内LLMでのRAG利用を許可
- Level 3: 匿名化・マスキング後、データオーナーの承認を得て利用
- Level 4: AI利用禁止（技術的にも遮断）

## 4. PII取扱い規定

- 全データは取り込み時にPII自動スキャンを実施
- 検出されたPIIは用途に応じて匿名化またはマスキング
- 匿名化手法: 一般化、仮名化（SHA-256ハッシュ）
- PII検出ツール: Presidio（Microsoft OSS）
- PII含有データの外部LLM APIへの送信は禁止

## 5. データ品質SLO

| データ資産 | 品質スコア目標 | 完全性 | 鮮度 |
|-----------|-------------|--------|------|
| 顧客データ | >= 85 | >= 95% | < 24h |
| 社内ドキュメント | >= 80 | >= 90% | < 7日 |
| チャットログ | >= 75 | >= 85% | < 1h |

品質スコアが目標を3日連続で下回った場合、
データスチュワードが改善チケットを起票する。

## 6. インシデント対応

### PII漏洩時
1. パイプラインの即時停止
2. 影響範囲の特定（リネージュ追跡）
3. 漏洩データの削除
4. データオーナーへの報告（1時間以内）
5. 法務部への報告（当日中）
6. 根本原因分析と再発防止策

### 品質異常時
1. 品質ゲートで自動ブロック
2. データスチュワードへの通知
3. 原因調査と修正
4. 品質スコア回復を確認後にパイプライン再開

## 7. 監査と見直し

- 月次: データ品質レポートのレビュー
- 四半期: ポリシーの見直し、ガバナンス委員会
- 年次: 外部監査、法規制対応の棚卸し
- 随時: 法規制変更時のポリシー更新

全体アーキテクチャ

[データソース]
├─ Salesforce CRM (顧客データ)
├─ Confluence / SharePoint / Google Drive (ドキュメント)
└─ Slack API (チャットログ)
      │
      ▼
[Stage 1: 取り込み (Ingestion)]
├─ ツール: Apache Airflow (オーケストレーション)
├─ 処理: フォーマット正規化、メタデータ付与
├─ スケジュール:
│   ├ 顧客データ: 日次バッチ
│   ├ ドキュメント: 日次差分同期
│   └ チャット: 準リアルタイム (1時間バッチ)
└─ 格納先: S3 (raw/)
      │
      ▼
[Stage 2: PII検出・処理]
├─ ツール: Microsoft Presidio + カスタムルール
├─ 処理:
│   ├ PII自動検出（NER + 正規表現）
│   ├ 分類レベルの自動判定
│   └ マスキング/匿名化の実行
└─ 格納先: S3 (cleaned/)
      │
      ▼
[Stage 3: 前処理・クレンジング]
├─ ツール: Python (pandas, spaCy)
├─ 処理:
│   ├ テキスト抽出 (PDF, DOCX → plaintext)
│   ├ 重複検出・除去 (MinHash LSH)
│   ├ 言語検出・正規化
│   └ チャット: 業務チャンネルのフィルタリング
└─ 格納先: S3 (processed/)
      │
      ▼
[Stage 4: 品質ゲート]
├─ ツール: Great Expectations
├─ チェック項目:
│   ├ PII残存チェック（ゼロであること）
│   ├ 品質スコア >= 閾値
│   ├ レコード数の異常検出（前回比 ±30%以内）
│   └ テキスト長の妥当性チェック
├─ 合格: 次ステージへ
└─ 不合格: パイプライン停止、データスチュワードに通知
      │
      ▼
[Stage 5: チャンキング + 埋め込み]
├─ ツール: LangChain (chunking) + self-hosted embedding model
├─ チャンキング戦略:
│   ├ ドキュメント: Recursive (512 tokens, overlap 50)
│   ├ チャット: Fixed size (256 tokens, overlap 30)
│   └ 顧客: Structured (フィールド別)
├─ 埋め込み: multilingual-e5-large (self-hosted)
└─ メタデータ: source, classification, quality_score, timestamp
      │
      ▼
[Stage 6: ベクトルDB格納]
├─ ツール: Amazon OpenSearch (k-NN)
├─ インデックス:
│   ├ helpdesk-docs (社内ドキュメント)
│   ├ helpdesk-chat (チャットログ)
│   └ customer-insights (顧客データ)
└─ メタデータストア: PostgreSQL (リネージュ情報)

品質ゲートの設計

監視・アラート設計

データバージョニング方針