個人を識別できる情報、会社の機密情報、未公開の政府・行政文書は、一般公開型AIにそのまま貼り付けるべきではありません。要約、翻訳、文章の整形、コードのデバッグだけのつもりでも、入力内容に個人、顧客、内部判断、認証情報、保護すべき情報が含まれるなら、まず匿名化・マスキング・要約に切り替えるか、組織が承認した管理下の環境を使うべきです。
「プロンプトに『秘密にして』と書いたから大丈夫」ではありません。確認すべきなのは、データがどう保存されるか、誰が見られるか、再利用を止められるか、事故時に誰が対応するか、そして自分の組織がその利用を明確に認めているかです。
1つでも答えられないなら、原文を入れる前に立ち止まるのが安全です。
| データの種類 | 原則 | アップロード前の確認 |
|---|---|---|
| 個人情報 | 個人を識別できる原文は入れない。必要なら、最小限の情報に絞り、匿名化・マスキング・要約を行う。 | EDPBはLLMのプライバシーリスクと緩和策を扱い、NISTもデータ保護、データ保持、影響評価、監視を治理項目に含めています。 |
| 会社の機密情報 | 未承認の公用AIに入れない。契約書、顧客リスト、入札・M&A関連資料、法務文書、ソースコード、鍵や認証情報は高リスクとして扱う。 | NISTの治理項目には、商用利用、データの出所、データ保護、データ保持、監視、インシデント対応、安全なソフトウェア開発が含まれます。 |
| 政府・行政文書 | 公開済みで低リスクの資料と、未公開の公文書、内部決裁資料、政策案、調査・執行関連資料を分ける。後者は一般公開型AIに入れない。 | JRC報告は公共部門での生成AI利用を専門領域として扱い、欧州議会資料の事例一覧でも、公式Bundestagデータを使う際に個人情報や機微情報を避ける例が示されています。 |
ただし、公開情報だから無条件に安全とは限りません。公開資料の中に個人情報や機微情報が含まれるなら、プライバシーリスクとデータ保護の観点で扱う必要があります。
この種類の資料は、AI利用が常に不可能というわけではありません。ただし、承認、保存ルール、監視、事故対応がない状態で一般公開型AIに投げ込むべきではありません。
氏名を消しても、電話番号、メールアドレス、住所、社員番号、顧客ID、案件番号、日付、場所、まれな肩書きが残っていれば、個人や案件を推測できる場合があります。EDPBの文書が焦点を当てるのも、LLMシステムにおけるプライバシーリスクとその緩和です。
比較的安全な進め方は、実名や会社名を仮名に置き換える、必要な箇所だけを抜き出す、原文を抽象化した相談文にする、名簿や表は集計値にする、原文処理が必要な場合は組織が承認したツールと手順に切り替えることです。
公共部門で生成AIを使うこと自体は、単純に禁止か解禁かで片付く話ではありません。欧州委員会の共同研究センター(JRC)による生成AI Outlook報告は、公共部門での生成AI利用を専門項目として扱っています。
検討できるのは、すでに公開され、低リスクで、利用条件を確認できる公式資料です。一方で、未公開公文書、内部決裁資料、政策草案、調査・執行関連資料、調達評価資料、個人情報や機微情報を含む文書は、一般公開型AIに直接入れるべきではありません。欧州議会資料の事例一覧にも、公式Bundestagデータを使いつつ個人情報や機微情報を避ける例が示されています。
その資料が漏れたとき、個人、組織、公共の利益、法令順守に損害が出るなら、一般公開型AIに原文を渡さない。まず削る、ぼかす、要約する、最小限にする。どうしても原文処理が必要なら、承認済みの環境で、データ保護、保存期間、アクセス権限、監視、インシデント対応を確認してから使う。
AIに聞く前に、資料そのもののリスクを見極めることが、いちばん確実な安全策です。