報道されている内容をもとに整理しています。報道ごとに日付や詳細が食い違う部分があり、当事者が公式に認めていない記述も含まれます。確定した事実としてではなく、何が起こり得るかの参考として読んでください。
サムスン電子（2023年3月、報道ベース）
生成AIの情報漏洩というと、まずこの件が挙がります。
報道によれば、半導体部門で生成AIの業務利用が許可された直後に、短期間で複数件の入力事故が起きたとされています。内容は、設備計測に使うソースコード、不良検出のコード、そして社内会議の文字起こしです。
いずれも、やった本人は業務を進めようとしていただけです。コードの不具合を直したかった。議事録を作りたかった。悪意のある持ち出しではありません。
その後、入力できる文字数に制限がかけられ、最終的には社内端末での生成AI利用が禁止されたと報じられています。禁止の時期については報道に食い違いがあります。
許可してから事故までが短い。つまり、教育なしで解禁すると、最初の数週間が一番危ない。制限をかけるのは、解禁の前であって後ではありません。
この件で見落とされがちなのが、3件のうち1件が会議の文字起こしだったことです。ソースコードの話として語られることが多いのですが、文字起こしのほうが、どの会社でも起こり得ます。
イタリアのデータ保護当局による一時停止（2023年）
イタリアの個人データ保護監督機関が、ChatGPTに対して国内でのデータ処理を一時的に停止させた件です。学習データの収集根拠や年齢確認の仕組みなどが論点になりました。
事業者側の対応後に再開されています。
この件が示しているのは、自社が何も間違えていなくても、使っているサービスが規制当局の判断で止まることがある、という点です。業務フローに組み込んだあとで止まると困ります。
チャット履歴が他人に見えた不具合（2023年3月）
OpenAIが公表した障害で、一部の利用者に他人の会話履歴のタイトルが表示される問題が発生しました。同じ時間帯に、一部の課金情報が他の利用者に見え得る状態だったことも併せて公表されています。
規模としては限定的でしたが、重要なのは自分が何も間違えなくても起きたことです。設定をオフにしていても、入力を慎重にしていても、預けた先の不具合までは制御できません。
だから「そもそも預けない」という判断が必要な情報が存在します。設定で防げる範囲には限界があるというのは、こういう話です。
日本国内で表に出ている件は少ない
国内の中小企業で起きた生成AI経由の漏洩が、固有名詞つきで報道された例は多くありません。
起きていないわけではないと思っています。表に出ないだけです。
理由は単純で、気づけないからです。メールの誤送信なら送信済みフォルダに残りますが、生成AIへの入力は本人が黙っていれば誰も知りません。取引先から指摘されて初めて発覚する、という経路しかない。
「まだ事例を聞かないから大丈夫」という判断は危険です。検知する仕組みがない以上、件数がゼロに見えるのは当然です。見えていないだけ、という前提で設計してください。
4件に共通していること
並べてみると、共通点が見えます。
- やった本人に悪意がない。むしろ仕事を進めようとしている
- 入力した瞬間には、誰も問題だと思っていない
- 発覚が遅れる。本人の申告か、外部からの指摘しかない
- 起きてから対応すると、選択肢がほとんど残っていない
不正な持ち出しを止める従来の対策は、1番の時点で噛み合いません。悪意を前提にした仕組みは、善意の事故を止められない。
だから効くのは、入力する直前に本人が「これは入れていいんだっけ」と思い出せるかどうかです。そこしかありません。技術で止められない以上、判断を配るしかない。
自社の事例を持っておく
他社の事例は説明には使えますが、社内には刺さりません。「サムスンの話でしょ」で終わります。
いちばん効くのは、自社で起きた小さな事例です。先月、誰かが「これ入れていいですか」と聞いてきた。その場面を2〜3行で書いて、社内のルールに追記する。これが一番読まれます。
そのためには、聞ける空気と、聞かれたときに答えられる人が社内に要ります。順番としては、そこが先かもしれません。