技術的プライバシーレビューのプロセスを解明（具体的ケース）

Demystifying the Technical Privacy Review Process: A Simulated Experience
IAPP Global Privacy Summit 2024 現地レポート[Vol.5]
公開：2024/04/18　執筆：株式会社プライバシーテック

世界中のプライバシー専門家が集う国際会議「IAPP Global Privacy Summit 2024」が、2024年4月1日〜4日の日程で、東京よりも一足早く桜が満開を迎えた米国ワシントンD.C.で開催されました。株式会社プライバシーテックは2年ぶりに現地参加。多くのセッションの中から選りすぐりのスピーチ・セッションの内容をお届けします。

◆ この記事でわかること
・一般的なPIAやDPIAはコンプライアンス（法令）遵守の観点にフォーカスを当てている
・技術的プライバシーレビューは開発プロセスの設計段階におけるプライバシー観点を、機能レベルでのより小さなスコープで、リスクを洗い出すことを目的としている
・技術者とプライバシー担当者とが双方に議論することで、UI/UXやシステムレベルでの設定等の具体的な対応策が見えてくる。

登壇者

Jay Averitt, Senior Privacy Product Manager, Microsoft
Engin Bozdag, CIPT, Senior Staff Privacy Architect, Uber
Nandita Rao Narla, CIPP/US, CIPM, CIPT, FIP, Head of Technical Privacy and Governance, DoorDash
Roche Saje, Manager, Privacy Engineering, Meta

転載：IAPP Global Privacy Summit 2024

概要

個人情報を取り扱う事業者にとって有効なリスクコントロールとして、プライバシー影響評価（PIA: Privacy Impact Assessment）やデータ保護影響評価（DPIA: Data Protection Impact Assessment）がある。

これらは一般的に、「EU一般データ保護規則」（GDPR: General Data Protection Regulation）、「カリフォルニア州消費者プライバシー法」（CCPA: California Consumer Privacy Act）、およびその他の規制に準拠するために法的な観点から実施される。

これらの評価は一般的に、アプリケーションがすでに作成された後か、制作の後期の段階で行われる。しかし、プライバシー・バイ・デザイン（Privacy by Design）は、プライバシーはソフトウェア開発の早い段階で考慮されるべきであると規定している。

強力なプライバシー・バイ・デザインのプロセスを導入している企業は、一般的に、開発プロセスの設計段階で技術的プライバシーレビューを実施することを要求しているが、この技術的プライバシーレビューとは一体何なのだろうか。また、PIAやDPIAと何が異なるのか。

本講演では、登壇者が２組に分かれて、潜在的なプライバシー問題を含む新しいアプリケーションを提案するエンジニアリング・チームと、その設計をレビューする技術的プライバシーの専門家チームとして、模擬的な技術的プライバシーレビューをロールプレイングにて行ってみせた。

法的レビューと技術的レビューの違い

技術的プライバシーレビューは、データの流れをより重視し、実際の要素に焦点を当て、PIAやDPIAよりも早い段階で行われる。製品の企画や設計という非常に初期の段階でプライバシーを考慮することであり、プライバシー管理を基本とするものである。そのため、製品が設計された後に、プライバシー管理が誤魔化されるような事態を避けられる。

ロールプレイング：アプリ開発における技術的プライバシーレビュー

転載：IAPP Global Privacy Summit 2024

開発するアプリ

• 大規模言語モデル（LLM: Large language Models）を搭載したフィットネス・アプリケーション。

• LLMにより、パーソナライズされたフィットネスプランの提案を可能にする。

形式

• 新しいアプリケーションを提案するエンジニアリング・チームと、その設計をレビューする技術的プライバシー専門チームに分かれて議論を展開する。

• システムのメカニズムを構造的に把握・理解するために、共通のシステムフロー図を用いて議論を行う。

レビューで議論された内容

• エンジニアリング・チームからの提案
  

  仕様として、アプリ内に「パーソナライズされた運動の取得」ボタンを設置する。
  
  ユーザーがボタンを押すと、アプリ開発のバックエンドに通知され、マイクロサービスの一つである推奨機能を利用するとともに、LLMのAPIに接続する。
  
  ただし自社のLLMサービスがないため、当社と契約した第三者のベンダーのLLMにユーザーのデータを送信し「パーソナライズされた運動」を作成する。自社のシステムと当該LLMを同期するため、全て一瞬で行われる動作であると想定する。
  

  送信されるユーザーのデータとしては、生年月日や性別、居住地だけでなく、好きな音楽などの嗜好も含まれる。
  

  当社は姓名、メールアドレス、電話番号、社会保障番号など、個人が識別できる情報（Personally Identifiable Information: PII）として保有しているユーザーのデータ全てについてアクセスできる。

• 上記提案に対する技術的プライバシー専門チームからの回答
  ＜質問＞

  - API統合の方法は具体的にどのようなものか。
  - どのようなタイプのデータを送信するのか。
  - 送信する情報を最小限に抑えることは考えているか。
  - データは送信時に暗号化されているのか。
  - 暗号化する場合、暗号キーの設定は当社なのかベンダーなのか。
  - ベンダーと共有されたデータが、パーソナライズするためだけに使用されていることをどのように確認するのか。

  
  ＜要求＞
  - 多くのPIIにアクセスできる状況を踏まえ、セキュリティチームにも相談すること。

  
  ＜提案＞
  - 情報漏洩時のリスクを勘案し、暗号キーはユーザーごとに設定すること。
  - データ削除はどのように行われるか。手作業ではなく、データ削除に特化したツールを設けること。

  - 独立した機関である製品審議会やバイオセキュリティも審査プロセスに含めること。

転載：IAPP Global Privacy Summit 2024

ロールプレイングを聞いた聴衆からの質問および登壇者からの回答

Q：技術的プライバシーレビューにおいて、指標となるような測定方法、または推奨されるメトリクスのようなものはあるか。

A：通常は、何件のレビューを行ったか、どれくらいの期間使用したか等を数値化することでメトリクスを作成する。
2023年のUSENIXプライバシー・エンジニアリングの実践および尊重に関する会議（2023 USENIX Conference on Privacy Engineering Practice and Respect: PEPR’23）の動画（PEPR'23 videos）を参考として欲しい。

Q：既存のサービスや製品に新機能を搭載する場合にも、この技術的プライバシーレビューは適用できるのか。

A：実際に現場で行われている技術的プライバシーレビューの99%は、既存の技術に新たなサービスを追加するケースにて行われる。
新たな機能により何が変化するのか、その機能により新たに取得が必要となる情報は何なのか、という側面に焦点を当てて行う。
新製品として打ち出したい機能が、技術的プライバシーレビューの結果、実現不可能と判断される可能性も十分にある。

Q：取引先のベンダーとの関係性について。ベンダーがどのように取り扱いデータを仕込み、変更を加えたかどうか等、どのように確認すれば良いのか。

A：基本的には取引先との契約に基づく。系統図、データフロー、またそのデータフローを保護する仕組みを検証する必要がある。データ処理における全工程を査定対象としなければならない。またその査定に当たった担当者とすぐに連絡が取れるようにしておくべきである。監査結果はきちんと記録に残しておく必要がある。記録方法については、事業者ごとに使い慣れたシステムを利用して構わない。

Q：プライバシー管理を担当する弁護士が、技術分野は専門外という理由で製品の内容をよく理解できず、取引先や自社のITチームに依存している場合はどうするのか。

A：エンジニアたちが技術的な専門用語を多用する場合、まず彼らが何について話しているのかを把握すべきである。
そしてどのようなパーソナルデータが対象となっているのかを理解し、適切な質問を投げかけていくことが重要となる。「誰が関わっているのか？」「データの保存期間は？」など、適切な質問を繰り返すことで重要なポイントが見えてくる。
弁護士は、例えばコードの仕組みや実際にどう機能しているかなどは知らなくても良い。ただし、鍵となるソフトウェアシステムの構成要素は理解しておくべきである。

Q：ベンダー側が、内部干渉や過干渉などと理由をつけて監査を拒否する場合があるが、その点についてどう考えているか。

A：自社およびベンダーの事業者としての規模や立ち位置により、どちらが交渉の主導権を握るか決まってしまうという事実はある。少し譲歩し、ベンダーが行うリスクアセスメントと重複する事項を削るという手段を取ってみてはどうか。
巨大企業ほど、システム担当者がお互い会話をせず、各部署間でも情報の連携ができていない傾向がある。社内のプライバシー管理部署やセキュリティチームと密に連絡を取り合うことで、ベンダー側へ要求する監査項目を減らすことができるかもしれない。

Q：AIがシステム設計を担うようになっても、そのシステムの評価を行うのは人間だと思うか。

A：コードスキャニングのようなツールにより、パーソナルデータの抽出やある程度のレビューは可能。しかし、コードにないデータの流れが起きた場合や、エンジニアが提供したものが100%正確ではなかった場合等は対応しきれない。当面は自動化された機能を用いながら人間が確認していく流れが続くと思われる。

Q：プライバシーとセキュリティに関する見解の質は、開発者がその機能を説明する能力と協調して適切な質問をする能力、あるいは開発者が製品をどれだけ理解しているかによって決まる。そこで、このような人的要素を減らすためにプライバシー・スタンダードを採用し、そのスタンダードを技術要件に反映させ、今後すべての機能のベースラインとして要求することは理にかなっていると考えるか？

A：そうすべきだと考える。技術的プライバシーレビュー時には、スタンダードで網羅されていないデータや新しい機能のみに焦点を当てれば良い。しかし大多数の企業は、そのようなスタンダードや要求事項を明文化しきれていないのが現状である。

（以上）

※本記事はプライバシーテック（ウンリュエル愛友美）が翻訳、編集しています。

当社では、今回のカンファレンスの詳細版レポートと勉強会を有償（10万円〜）にて提供しています。ご関心がございましたら問い合わせフォームよりご連絡くださいませ。

一覧はこちら（IAPP Webサイト）↗

＞＞次へ：[Vol.6] PETs： プライバシー保護技術の発展を促進するには？国家戦略と規制当局の視点

＜＜前へ：[Vol.4]アジア各国におけるプライバシー規制の違いとは

◆ 関連記事
[Vol.1]IAPP Global Privacy Summit 2024 とは？
[Vol.2]米･欧･中が競合する、世界のテクノロジー規制 (Opening Session)
[Vol.3]医療技術とマーケティングにおける新たなベストプラクティス： 潮目の変化
[Vol.4]アジア各国におけるプライバシー規制の違いとは
[Vol.5]技術的プライバシーレビューのプロセスを解明←この記事
[Vol.6]PETs： プライバシー保護技術の発展を促進するには？国家戦略と規制当局の視点

===

IAPP公式サイト：https://iapp.org/about/

#AIガバナンス　#AI利活用　#プライバシー　＃IAPP