1 ポイント 投稿者 GN⁺ 2024-05-17 | 1件のコメント | WhatsAppで共有
  • Slack は顧客データで生成 AI モデルを開発しませんが、絵文字やチャンネル推薦のような予測モデルでは、メッセージ、コンテンツ、ファイル、利用情報が分析されることがあります
  • グローバルモデルは顧客データの一部を再現しないよう設計されており、AI/ML の開発や分析の過程で従業員が基盤コンテンツにアクセスできないよう統制が設けられています
  • 顧客はワークスペースまたは組織のデータをSlack グローバルモデルの学習から除外するようリクエストでき、除外後もグローバル学習 ML モデルの利点を引き続き利用できます
  • チャンネル推薦、検索結果、オートコンプリート、絵文字推薦は、外部モデル、数値スコア、過去の相互作用回数、公開文言などを活用し、顧客データの露出を減らす形で動作します
  • Slack の生成 AI 機能はサードパーティ製 LLM を利用しますが、顧客データは Slack の信頼境界内にとどまり、明示的なオプトインなしに生成 AI モデルの学習に使われることはありません

Slack の AI/ML データ利用原則

  • Slack の製品開発原則は顧客データのプライバシー保護とセキュリティを中心に据えています
  • ML と AI は Slack 製品を改善するためのツールとして活用されます
  • 顧客データで生成 AI モデルを開発することはありません
  • 絵文字推薦、チャンネル推薦のような予測モデルの開発には、次のデータが分析されることがあります
    • Slack に送信された顧客データ: メッセージ、コンテンツ、ファイルなど
    • プライバシーポリシーと顧客契約で定義されたその他の情報: 利用情報を含む

グローバルモデルとアクセス統制

  • Slack は、全顧客に広く使われるモデルを、顧客データの一部を再現できる形で構築または学習しません
  • AI/ML モデルの開発や顧客データ分析の過程で、Slack の従業員は基盤コンテンツにアクセスできません
  • 顧客データの機密性と安全性を保護するため、複数の技術的対策が講じられています
  • 顧客は自分の顧客データを Slack グローバルモデルの学習に使わないようオプトアウトできます
    • オプトアウトしたワークスペースの顧客データは、そのワークスペースの体験改善にのみ使用されます
    • グローバル学習 ML モデルの利点は引き続き利用できます
    • Org または Workspace Owners、Primary Owner は、Workspace/Org URL と件名 Slack Global model opt-out requestfeedback@slack.com に送る必要があります
    • Slack はリクエストを処理した後、完了可否を返信します

顧客データとその他情報によるサービス改善

  • Slack の製品チームおよび分析チームは、サービスの開発、更新、改善のために顧客データとその他の情報を使用できます
  • こうしたパーソナライズと改善は、ユーザーが Slack とどのように相互作用するかを調査し理解する過程で可能になります
  • Slack の顧客契約と Privacy Policy にある守秘義務は、各シナリオに適用されます
  • 顧客は自分の顧客データを所有します
  • Slack は顧客データを集計・分離し、サービス更新に顧客データを使う場合でも、第三者が特定の顧客や個人を改善の出所として識別できないようにしています
    • Slack の関連会社または再委託先は例外に含まれます

予測機能ごとのデータ保護の仕組み

  • チャンネル推薦

    • 社内の新しい公開チャンネルへの参加を推薦できます
    • 推薦はチャンネルのメンバーシップ、活動、トピックの重なりに基づきます
    • モデルは過去の推薦と、ユーザーがそのチャンネルに参加したかどうかから学習します
    • Slack メッセージで学習していない外部モデルがトピックの類似性を評価し、数値スコアを出力します
    • グローバルモデルはこの数値スコアと非顧客データだけを使って推薦を行います
  • 検索結果

    • 検索 ML モデルは特定のクエリに合う結果を識別し、ユーザーが求める情報を見つけられるよう支援します
    • 過去の検索結果と以前のエンゲージメント履歴に基づきます
    • モデルが検索クエリや結果を再現できないよう設計されています
  • オートコンプリート

    • 検索クエリやその他のテキストをオートコンプリートできます
    • たとえばユーザーが Customer Support の先頭数文字を入力すると、その語句を補完する仕組みです
    • 提案はローカルで行われ、ユーザーのワークスペースにある一般的な公開メッセージの文言から取得されます
    • 候補提案を選ぶアルゴリズムは、これまでに提案され受け入れられた補完例をグローバルに学習します
    • 入力テキストと提案の間の類似性をスコア化するルールが使われ、アルゴリズムには数値スコアと過去の相互作用回数のみが入力されます
  • 絵文字推薦

    • メッセージの内容や感情、絵文字の過去の使用、特定の文脈でチーム内で使われる絵文字の頻度に基づいて、リアクション絵文字を提案できます
    • 特定のチャンネルで祝福メッセージに 🎉 リアクションがよく使われるなら、同様にポジティブな新しいメッセージにも 🎉 リアクションを提案できます
    • Slack メッセージで学習していない外部モデルがメッセージの感情を分類することがあります
    • Slack のモデルは、そのワークスペースで特定の感情のメッセージと特定の絵文字が結び付いた頻度だけを考慮して絵文字を提案します

生成 AI における顧客データ処理

  • 生成 AI は、ユーザーが入力したプロンプトに応答してテキストのようなコンテンツを生成できる AI システムのカテゴリです
  • このカテゴリには**大規模言語モデル(LLM)**が含まれます
  • AI in Slack は生成 AI を使用し、サードパーティ製 LLM を活用します
  • 顧客が明示的にオプトイン同意しない限り、顧客データが生成 AI モデルの学習に使われることはありません
  • AI in Slack は既製の LLM を使用しており、これらのモデルはリクエスト後に顧客データで更新されず、顧客データを他の形で保持することもありません
  • 該当モデルは AWS のようなクラウドプロバイダーのインフラ上でホストされています
  • 顧客データは Slack の信頼境界内にとどまり、LLM 提供者は顧客データにアクセスできません
  • 再委託先の変更通知は Trust and Compliance webpage で受け取れます

Slack AI 検索回答のソース

  • AI in Slack の検索機能は、Slack 内部機能と接続されたドキュメントから回答ソースを取得します
  • 検索ソースには次が含まれます
    • Slack 機能: キャンバス、huddles canvas notes、clip transcripts、text snippets
    • Slack にアップロードされたファイル: PDF、メール、docx、pptx、Keynote
    • Google Drive の接続ドキュメント: Docs、Slides
    • Sharepoint/OnDrive のドキュメント: Word、Powerpoint
    • Box のようなファイル保存パートナーアプリ: インストールされている場合
  • ユーザーは Slack との統合を通じて認証されている場合にのみ、それらのファイルへアクセスできます
  • 管理者はすべてのファイル結果を無効化したり、外部ホストされたファイルをソースとして使わないよう設定したりできます
  • 関連案内は Help Center で確認できます

1件のコメント

 
GN⁺ 2024-05-17
Hacker Newsの意見
  • サポートチームに連絡してオプトアウトしたところ、リクエストは完了したという返答だった
    Slackは、チャンネルや絵文字の推薦、検索結果のようなプラットフォームレベルの機械学習モデルはあるが、顧客データを学習・記憶・再現できる形で作成したり学習させたりはしないと説明している
    Slack AIは別途購入するアドオンであり、顧客データでLLMを学習せず、SlackのAWSインフラ内でホストされたLLMを使うため、データが外部のLLMプロバイダーと共有されることはないという
    ポリシーのリンク: https://slack.com/trust/data-management/privacy-principles, https://slack.engineering/how-we-built-slack-ai-to-be-secure...

    • 結局「当社のAIにあなたのデータを食わせるが、他社とは共有しない」という意味に聞こえる
      次の利用規約アップデートまでの話だろうが
    • ひっそりとデフォルト参加で有効にしておき、Slackの管理者パネルに簡単なオプトアウトも入れていないのに、顧客プライバシーを気にしているふりをするのは、まったく誠意がないように見える
    • 「顧客データをSlackのグローバルモデルから除外したい場合は、Org/Workspace OwnerまたはPrimary Ownerが、Workspace/Org URLと件名『Slack Global model opt-out request』を添えてfeedback@slack.comに送る」という手続きだった気がする
      たぶんそれをやったんだろう?
    • 同じ定型回答を受け取り、追加の詳細を尋ねたが何の返事もなかった
  • 「Slackのグローバルモデルの学習に顧客データを使わせないためにオプトアウトできる。オプトアウトしてもワークスペースのデータはそのワークスペース体験の改善にのみ使われ、グローバル学習モデルの恩恵は引き続き受けられる」という仕組みなら、なぜ誰もがオプトアウトしないのかと思う
    もちろん、自分がオプトアウトすべきだと知らない場合は別として、完全に損しかない選択に見える

    • プレスリリースにAIを付ければ、有料サービス上の私的なコミュニケーションデータを許可なく産業規模でかき集めて収益化しても、顧客が受け入れると企業が考えているのが理解できない
    • 簡単にするつもりはなさそうだ
      個人ユーザーには自分のデータの使われ方について発言権がないように見え、Workspace Ownerに連絡しなければならない
      そう連絡するなら、むしろ代替プラットフォームを検討してほしいと頼むつもりだ
    • インターネットのプライバシーはだいたいこういうものだが、簡単なら全員がオプトアウトしていたはずだ
      結局はオプトアウトのもぐら叩きになり、方法も一般問い合わせで、オプトアウトしてもなお学習はするというふうに見える
    • 「顧客に選択肢を提供する」という文言を見ると、『銀河ヒッチハイク・ガイド』式の冗談を思い出す
      規約の300ページ目あたりの、ほとんど目につかない場所に小さなヒントを置いておくのかもしれない
    • 最高のグローバルモデルを望むこともあり得る
      オプトアウトしないことを「より良い製品づくりを助けること」と見れば、すでにお金を払っている製品で、追加の時間投資なしに次のリリースを良くできるなら、なぜやらないのかとも思う
      同じ価格でより良い製品を得られ、会社はより売りやすい製品を得る
      会社のほうがより多く得をする取引かもしれないが、一方がより多く勝つからといって、もう一方が負けるわけではない
      データプライバシーを非常に重視している、あるいは学習の許可が実際に非公開情報の漏えいリスクを生むと信じているなら話は別で、その場合は停止する選択肢があるのだから、「より良い製品」と「非公開情報漏えいの推定リスク」の価値を各自で量ればよい
  • 「すべての顧客に広く使われるモデルは、顧客データの一部を学習・記憶・再現できる形で作成したり学習させたりはしない」という文言は、微妙な含みと免責のための表現が多すぎて、信頼よりも不信感を強める
    「すべての顧客に広く」使われるモデルにだけ該当するので、広く使われない、あるいは一部の顧客にだけ使われるなら、文全体が適用されないという意味になる
    論理的には、そのような場合にはデータが漏れ得るという含意のように聞こえ、かなりひどい
    この文言は修正すべきで、これを書いた人はリスクだ

    • 「書いた人がリスク」というより、むしろ責任回避のために意図的にそう書いたように聞こえる
    • 数段落下で「顧客データをSlackのグローバルモデルの学習に使わせないようにするにはオプトアウトできる」と言っているので、さらに変だ
      顧客データは「すべての顧客に広く使われるモデルをそのような方法で」学習するためには使われないが、グローバルモデルの学習には役立つ、ということになる
    • 問題は、その免責文言をめぐって法務チームに踊らせる現実を決めた人にある
      ただし、その問題は彼らよりも我々にとってのほうが大きい
    • 企業Slackのチャンネルや非公開チャットにはインターネットのどこにもない情報があり、それがモデルに入ると想像してしまう
      誰かが非常に具体的な状況について会話するように質問すれば、顧客名にひも付けられなくても機密データが外に出てくるように見える
      特定業界の特定または任意の会社が何かをどう設計するかをLLMに尋ねられないわけでもないし
    • 文言は可能な限り明確に見え、箇条書きでより詳しい例を挙げているのだと思う
      チャンネル推薦モデルは過去の推薦と、ユーザーが推薦チャンネルに入ったかどうかを学習するが、顧客データとモデルを分離してプライバシーを保護するとしている
      Slackメッセージで学習していない外部モデルでトピックの類似度を評価して数値スコアを作り、グローバルモデルはそのスコアと非顧客データだけで推薦すると説明している
      検索も、クエリや結果テキストそのものは学習せず、メッセージが検索でクリックされた回数や、クエリと推薦メッセージの単語の重なりのようなチーム別の文脈情報を学習するという
      オートコンプリートの提案はワークスペースの公開メッセージによくあるフレーズから取得し、グローバルには以前に提案・承認された補完結果を基に学習するが、アルゴリズムにはスコアと過去のインタラクション回数だけを使うという
      絵文字推薦も、Slackメッセージで学習していない外部モデルで感情を分類し、そのワークスペースでその感情のメッセージと特定の絵文字が一緒に使われた頻度だけを考慮する、という形だ
  • 要するに、データをグローバルモデルから除外するにはオプトアウトが必要ということ。
    同時に「データはワークスペース間で漏れない」と曖昧に言っているので、非常に混乱する。
    「漏れないだろう」ではなく、「漏れようがない」ツールを使うべきだ。

    • そもそもすべてのツールは本質的に、API 呼び出し 1 回でデータが漏れる状態なのではないか?
    • ほとんどの SaaS はマルチテナントなので、何十年もの間すでに「漏れ得るが漏らさないだろう」という世界で生きてきた。
    • 法的文言における「will not」と「cannot」の違いが何なのか気になる。
  • 「AI/ML モデルを開発したり顧客データを分析したりする際、Slack は基盤コンテンツにアクセスできない。これを防ぐさまざまな技術的措置がある」という文は混乱を招く。
    「できない」という強い表現だが、AI モデルはデータにアクセスできる一方で、Slack, Inc 自体はアクセスできないというのがどう可能なのか気になる。
    見落としがなければ、「できない」ではなく「しない」に近い言い方に見える。

    • ここでの「Slack」という言葉が興味深い。
      おそらく「Slack の従業員」を意味しているのだろうが、「Slack」は会社の資産、代理人、システム、コンピューター、サーバー、AI モデルなどをすべて含み得る。
      Signal が「私たちはユーザーコンテンツにアクセスできない」と言っても、不安定で楽観的な文言に聞こえる。
      「できない」と聞くと、会社の中の誰も合法的な範囲内でそれを行えない、という意味に受け取ってしまう。
      Slack の従業員はその技術的措置をオフにできるし、Signal の従業員もアプリ更新ですべてのメッセージを別サーバーへ迂回送信させることができる。
      より良い表現は「Slack の従業員は基盤コンテンツにアクセスしない」だ。
    • 同じコメントでリンクされているホワイトペーパーには、最小権限とロールベースの権限でアクセスをプロビジョニングし、現在の業務に合理的に必要なデータだけを扱えるようにし、すべての本番環境アクセスを少なくとも四半期ごとに見直す、とある。
      そうであれば、非常に明確にアクセス可能に見える。
    • センシティブなデータを扱うシステムを作ったことのあるエンジニアの立場から見ると、この文はアクセス制御リスト、そのアクセス制御リストをプロビジョニングするシステム、そのシステムが従うポリシーについて述べているように見える。
      例えばモデル学習のバッチジョブは、「インタラクション」と注釈されたデータにはアクセスできるシステムユーザーとして実行されるが、メッセージ本文やユーザークエリのテキストのような「コンテンツ」データにはアクセス権がない、ということがあり得る。
      学習ジョブがそうしたコンテンツを取得しようとする RPC を送ると、ログインせずに他人の DM にアクセスしようとしたときのように拒否される。
      大企業では、エンジニアやプロダクトマネージャーが勝手にアクセス制御リストを決めることはできず、バッチジョブのアクセス権を何らかのシステムに申請し、そのシステムを運用する人たちも会社のポリシーに従う。
      銀行員が口座番号を扱うものの、個人口座へこっそり送金することはできない、または発覚するのと似ている。
      この文は、Slack のある PM が自分のチームの OKR を上げるためにポリシーを無視し、別チームが使っていない顧客データでこっそり学習することはシステム上できない、という意味に近い。
      もちろん比喩は完璧ではない。
      銀行員は、顧客の同意後にメッセージを代わりに見られる Slack のカスタマーサポート担当者に近く、個人に付与された限定的アクセスをモデル学習ジョブへ流し込む方法は実際には存在しない可能性が高い。
      成熟した会社であれば、従業員が個人データへのアクセス権を使って任意のノート PC 上でモデルを学習し、そのモデルを本番環境にデプロイすることも防がれているべきだ。
      スタートアップならそう回っていることもあるかもしれないが。
    • エンドツーエンド暗号化」を約束するすべての会社も、結局は指切りげんまんで約束している程度だ。
      Telegram や WhatsApp も同じだ。
  • こういうことをする会社のリストをまとめておけば避けられるのに、と思う。
    簡単で目立つオプトアウトのトグルなしに顧客データで学習している他の会社を知っていたら、下に書いてほしい。

    • Synology が 3 月にこのポリシーを更新した。
      以前は、技術サポートの依頼から得た情報は問題解決にのみ使い、個人情報を削除した後、一部の技術的詳細をバグレポート作成に使用できるとしていた。
      新しい文言には、個人情報を削除した後、特定の技術情報をバグレポート作成に使うことができ、匿名化された技術情報を Microsoft Azure に送信して OpenAI サービスを活用し、技術サポート体験を改善できる、という内容が入った。
      氏名、電話番号、住所、メールアドレス、IP アドレス、製品シリアル番号のような個人識別情報は除外するとしている。
      以前はプライバシーポリシー更新のメールをそのまま削除していたが、今ではこうした文言が差し込まれていないか diff を見る習慣がついた。
    • データが会社が自由に読んでアクセスできるデータベースに保存されているなら、つまりエンドツーエンド暗号化ではないなら、結局その会社はデータをAI 学習に使えるよう利用規約を変えるだろう。
      インセンティブが強すぎて、耐えるのは難しい。
      https://twitter.com/kepano/status/1688610782509211648
      https://twitter.com/kepano/status/1682829662370557952
    • これをしていない会社のリストを作る方が簡単だろう。
      リストは空だ。
    • 保護措置が整い、各自が自分のデータの使われ方と補償の有無を決められるようになるまでは、インターネットに有用または正確な内容を投稿しないという形で対抗できる。
  • これが欧州の忘れられる権利の法律とどう両立できるのか分からない
    実際、こうしたAIモデルのうち、その権利を守れるものがあるのか疑問に思う
    ユーザーが削除を求めたら、モデル全体を再学習するのだろうか? そうはならない気がする

    • 今起きている「AI」詐欺は、数々の小細工を隠す究極に複雑な手続きのように見える
      著作権はもはや存在せず、盗むのではなく変換しているだけだと言い、インターネット全体でモデルを学習する前にオプトアウトしなければならないと言い、しかもそれでも対応してくれなさそうだ
      雇用はまったく減らないと言いながら、どの会社も即座に15%を解雇し、オフィス復帰を強制して車のデータまでさらに得ようとしている、という具合だ
      「奇妙なたった1つの秘訣」で最高に生産的なプログラマーになれると売り込むが、実際には自分たちで収益性のある製品を作るより、個人に売ろうとしているように見える
      最も深刻で危険なのは、情報が人々の指先や目の前に届くより前に、最も低いレベルで検閲されることだ
    • 機械アンラーニングは実際に存在する分野で、入門資料として[0]を参照できる
      [0] https://ai.stanford.edu/~kzliu/blog/unlearning
    • 現在のGDPRなどの解釈がそうなっているとは思わない
      モデルがすでに学習済みなら、忘れられる権利の要求によって削除する必要はない、という方向だと理解しているが、法的な不確実性は大きい
      最近のGDPR判決を見ると、オプトインではなくオプトアウトである点から、なお違反である可能性が高い
      おそらくEEAで生成されたデータはすべて除外しているのだと思う
  • チームメッセージングには、Matrix/Elementのようなセルフホスティング型ソリューションを本当に使うべきだ
    自社設備を社内に置きたくないのは構わないが、解決策はホスティング業者がデータにアクセスできないよう、エンドツーエンド暗号化されたソリューションを運用することだ
    cryptpad.frも優れたソフトウェアだ

    • Campfireを確認してみるとよい
      ソースコード(Ruby on Rails)を入手して好きな場所にデプロイする方式で、私たちはDigitalOcean droplet上で動かしている
    • Zulip(https://zulip.com/)は、Slack/Teamsの優れたセルフホスティング可能なPythonベースの代替に見える
  • Slack、Google、Microsoftをはじめ、あらゆるSaaSツール提供者にとって、このようなことをするインセンティブは非常に大きい
    企業がベンダーにコモディティ化されることを避けるには、結局、自社のデータとAI戦略を自分たちで制御しなければならない
    それはおそらく、小さく高価で事業を破壊しかねない機能をオフにし、アクセス制御とガバナンスがしっかりした中央ナレッジベースを作ったうえで、どの提供者のオープンソースまたはブラックボックスLLMでも差し込んで使う方向に進む、という意味だ

    • 「ベンダーにコモディティ化される」というのは、まさに探していた表現だ
      だから会社にはSlackではなくMattermostのセルフホスティングを使ってほしかった
    • 確かにモラルハザードであり、同時に機会でもある
      ちなみにWindows 11はデフォルトでMicrosoftのサーバーにファイルを同期する
  • 「絵文字を選ぶためだけに使います、それから社内専用の面白い株式推薦ツールにも少し使います」みたいなことになりそうだ
    何十万ものテック企業の匿名化されたリアルタイムな本音を基に、買うと面白そうな株を推薦してくれるツール、というわけだ