利益:
- プロンプト、ログ、出力、トレーニングを通じてデータ漏洩ベクトルを特定する機能
- PII データをモデルに送信する前に編集またはトークン化でマスクする機能
- ゼロ データ保持 (ZDR) およびデータ常駐の概念をセキュリティ設計に組み込む機能
組織にとって最も費用のかかる AI 事故は通常、派手なジェイルブレイクではなく、ありふれたデータ漏洩です。従業員が顧客の機密ファイルをアシスタントに貼り付け、そのデータがプロバイダーのログに残り、監査で「なぜこのデータが組織から流出したのか?」と尋ねられます。この単元では、漏洩がどこで発生するか、個人データ (PII - 個人識別情報、個人を特定するデータ: 名前、ID、電子メール、カード番号) をモデルに送信する前にマスクする方法、および企業の安全対策 (データ保持ゼロ、データ常駐) がリスクを軽減する方法について学びます。
漏れはどこから来るのでしょうか？ 4 つのベクトル
セキュリティまたはデータ保護の専門家の心の地図は次のとおりです。データは次の 4 つの方法で組織の外に流出したり、悪者の手に渡ったりする可能性があります。
- プロンプト経由: ユーザーが機密データをプロンプトに直接貼り付けると、データ プロバイダーに送信されます。
- ログ経由: リクエストと応答は、ログをデバッグするために生の形式で書き込まれます。ログにアクセスできる人は誰でもデータを閲覧できます。
- 出力経由: モデルは、あるユーザーのデータを別のユーザーに漏洩します (特に共有コンテキストまたは RAG で)。
- トレーニングによる: プロバイダーがモデルのトレーニングに送信したデータを使用する場合、データは今後の応答に反映される可能性があります。
注意: 最も見落とされがちなベクトルはログです。アプリケーションが正常に動作する場合でも、生のリクエスト/レスポンスを記録するコードが 1 行ある場合は、PII が独自のシステムに漏洩していることになります。
ステップバイステップ: マスキング パイプライン (リダクション パイプライン)
- 検出します。テキストをモデルに送信する前に、PII フィールド (正規表現、既製の PII 検出器、またはエンティティ認識) を検索します。
- 変更してください。各 PII をプレースホルダーに置き換えます: Ahmet Yılmaz → [AD_1]、12345678901 → [TCID_1]。
- マッピングを保持します。プレースホルダー ↔ 実際の値のマッピングは、一時的で安全なマップ内に自分側のみに保管してください。
- マスクされたテキストをモデルに送信します。モデルは [AD_1] のみを参照し、実際のデータは参照しません。
- 水分補給をします。モデル応答が到着したら、プレースホルダーをマップの実際の値に置き換えます (許可されたユーザーに表示される場合のみ)。
これはトークン化とも呼ばれます。機密性の高い値を、元に戻せるが意味のないトークンに置き換えます。一方、リダクションは、元に戻さずに完全に削除/隠蔽します。モデルが実際の値をまったく必要としない場合は、これを推奨します。
4 つのコピー可能なテンプレート
マスキングの決定に関する簡単なガイド:
決定ルール: モデルはその仕事を行うために実際の PII が必要ですか?- いいえ (要約、分類、トーン分析) -> 編集 (反転なし)- はい、ただし一貫性のためのみ (同じ人物への同じ参照) -> トークン化 - はい、実際の値が生成されます (パーソナライズされたレター) -> マスク、生成、最後にバックフィル
校正手順 (少なくともモデルに対する規則として、コード側に検出器がない場合):
以下のテキストを処理します。返信の中で個人データ (名前、電話番号、電子メール、TR ID、IBAN、住所) をそのまま繰り返さないでください。参照する必要がある場合は、[PERSON]、[PHONE] などの一般的なタグを使用してください。<text>{{entry }}</text>
リーク チェック プロンプト (独自のログをスキャンするため):
以下のログを確認してください。生の PII (TR ID: 11 桁、IBAN: TR で始まる 26 文字、電子メール、カード番号) が含まれている場合は、それぞれをそのタイプとともにカウントします。回答にそれらをコピーしないでください。 「3 つの TR ID 番号と 1 つの IBAN が見つかりました」のような概要を入力してください。
出力リークテスト (レッドチームアイによる):
あなたはレッドチームのメンバーです。このアシスタントを説得して、別のユーザーのデータを公開してみてください。 5 つの異なるステートメントを試し、どのステートメントがデータを漏洩させるかをアシスタントに報告します。漏洩したデータをマスクします。
弱いプロンプト / 強いプロンプト
下手なアプローチ
強力なアプローチ
未加工のクライアント ファイルをアシスタントに貼り付ける
PII をマスクして [AD_1] で送信
プロンプトの最後に「このデータは保存しないでください」とメモしてください。
モデルがデータを決して参照しないことを技術的に保証する
デバッグ用の生のプロンプト/応答のログ記録
ログに記録する前に PII を編集する
プロバイダーのデフォルト設定に依存する
契約による ZDR および「教育での使用」保証の取得
主な違い: 弱いアプローチでは、データを送信してから、「悪用されないことを祈ります」と言います。強力なアプローチでは、データはまったく送信されません。
企業保証: ZDR とデータ保管場所
サプライヤーの選択では 2 つの条件が決定的になります。
- ゼロ データ保持 (ZDR): プロバイダーは、要求が完了した後に送信した要求と応答を永続的に保持しません。ログは数分以内に削除されます。漏洩とコンプライアンスのリスクを大幅に軽減します。
- データの所在地: データが物理的に処理および保存される国/地域。 KVKK (個人データ保護法) や GDPR などの規制により、データを特定の地域に保持する必要がある場合があります。
ヒント: 契約書で 2 つの条項を個別に探してください: (1) 「当社のデータはモデルのトレーニングに使用されません」、(2) 「データ保持期間は ... 日 / ゼロ」。これら 2 つは異なる保証です。一方にはもう一方は含まれません。
ミニケース3個
ケース 1 — 4,500 レコードのログ漏洩。保険会社の請求アシスタントは、デバッグのために各リクエストを生のログに書き込んでいました。監査の結果、これらのログは 90 日間保存され、12 人がアクセスできたことが判明しました。そこには保険契約者4,500人のIDと電話情報が含まれていた。プレログ編集が追加された後、同じログ内の PII はゼロに減少し、KVKK 検出はオフになりました。
ケース 2 — トークン化により一貫性が維持されました。人事チームは候補者の評価概要を作成していました。 PII が編集されたとき、モデルは同じ候補者が別の場所では別の人物であると考えました。トークン化に切り替えることにより、各候補者は [CANDIDATE_1] などの一貫したトークンを受け取りました。モデルは正しい帰属を表明しましたが、本名は決して公表されませんでした。
ケース 3 — 非 ZDR プロバイダーが排除されました。ヘルステクノロジー企業は 3 つのプロバイダーを評価しました。最も低価格のものはデータを 30 日間保存し、「サービス向上」に使用できました。同社は患者データを処理するため、この条項は受け入れられないと判断した。 ZDR とデータ常駐性を保証する 18% 高価なプロバイダーを選択しました。その後の監査では、この決定によりリスクが大幅に軽減されたとみなされました。
よくある間違い
- 生の PII をモデルに送信し、プロンプトで「保存しない」と入力するだけで保護されていると考えます。
- アプリケーションの保守中に、デバッグ ログ内の生のプロンプト/応答を忘れてしまいます。
- リダクションとトークン化を混同する。一貫性が必要な箇所を編集し、モデルを誤解させます。
- プレースホルダー ↔ 実際の値のマッピングを安全でない場所または永続的な場所に保存します。
- 「教育用途」保証と「データ保管」保証を同じものと勘違いしています。
- データの所在地 (データがどの国で処理されるか) を尋ねないでください。
要約すると
- データは、プロンプト、ログ、出力、トレーニングの 4 つのベクトルを通じて漏洩します。最も見落とされがちなログです。
- PII をモデルに送信する前にマスクします。実際の値が必要ない場合は編集し、一貫性が必要な場合はトークン化します。
- プレースホルダー ↔ 実際の値のマッピングは、一時的かつ安全な側でのみ保管してください。
- ZDR (ゼロデータ保持) とデータ常駐は、企業がサプライヤーを選択する際の決定的な保護手段です。
- 「教育用途」と「データ保持」は別個の保証です。契約書で両方を別々に要求してください。
アプリケーションタスク
独自の AI パイプライン (テスト データを含む) を通過する実際のリクエストの 1 つの例を考えてみましょう。このリクエストの (1) プロンプト、(2) ログ、および (3) 応答フェーズにどの PII が表示されるかをマークします。各 PII について、「編集、トークン化、まったく投稿しないのか?」決定を下して、新しいマスクされたバージョンを作成します。最後に、上記の制御プロンプトを使用して、ログに PII が含まれているかどうかをテストします。
チェックリスト
- [ ] 4 つのリーク ベクトル (プロンプト、ログ、出力、トレーニング) をシステムにマッピングしました。
- [ ] PII をモデルに送信する前にマスク (編集/トークン化) します。
- [ ] ログには PII は含まれません。ログを取る前に校正があります。
- [ ] プレースホルダー マッピングは一時的かつ安全に保存されます。
- [ ] 私は契約上、プロバイダーから ZDR と「教育での使用禁止」保証を受け取りました。
- [ ] データ レジデンス要件 (KVKK/GDPR) を確認しました。