# センシティブ安全性(Sensitive Safety)
# センシティブなデータが漏れずに済むという安全性や安心感のこと。
# 特に生成AIの文脈で使う。

# 概要
- センシティブなデータとは:
    - 機密情報
    - 個人情報
    - プライバシー
- ITと付き合うとは情報をシステムに残すことであるが、人はセンシティブなデータは意図しない範囲には漏らしたくないし、組織としても知られたくないので、「漏れない」との保証がほしい
    - 保障は（クローズドなシステムでもなければ）原理的に不可能である
    - 最もかんたんなのは諦める――つまりはITを使わない、とのスタンスを取ることだが、これは不便である
    - ならば、あとは自ら気をつけて使うしかない。自ら保証するしかない
- 保証の程度はシステム側次第で、あるいはこちら側の使い方次第で左右されるが、いずれにせよ議論できるようにしたい
    - 「保証の程度」に名前をつける。それがセンシティブ安全性。これにより安全性が低い、高い、高くするといった言及が可能となり、言及できるなら議論もできる

# 例1: [クリップボード]の内容を自動で読み取って生成AIに投げるアプリ
- 安全性は低い
- なぜならパスワードやその他センシティブな情報をコピーすることがあり、それも生成AIに投げられてしまうからだ
    - かといって、いちいちコピーする前に気にかけて一時的にオフにしたり、などはやってられないだろう
    - また「センシティブな内容だったら生成AIには投げない」のようなガードも不可能ではないが、意味的な判断ができねばならず、そのためには結局生成AIが必要である
        - ただし今後外部にデータを漏らさないローカルなLLMのハードルがより下がると、この選択肢は現実的になりえる<a href="sta.md"><img src="https://gyazo.com/a0a22d2fc5cf4fb2525db091fb66594b.png" alt="sta" width="16"/></a>
# 例2: あらゆる音を拾って録音、文字起こしして、生成AIに投げるデバイス
- 安全性は少し低い
- しかし例1ほどではない
    - 「記録されたくない場合はオフにする」が比較的しやすいからだ
# 例3: 社内のクローズドなファイルサーバーを読み取って生成AIに投げるアプリ
- 安全性は低い
- 機密情報を読み取られる恐れがある
    - 特にアプリ側で読み取り範囲を設定していたとしても、リテラシーのない社員が「読み取られる場所」に「センシティブなファイル」を置いてしまう可能性がある

# 付き合い方
- 1: できるだけ歩み寄る
    - まず「安全に倒して丸々使えなくする」は論外である
        - テクノロジーの便宜を享受できない
        - （無論便宜よりもセキュリティを最優先したい場合など適することもある）
    - リスクがあろうと、できるだけ歩み寄った方が良いに決まっている
    - どうやって歩み寄るか → 「安全性が損なわれるのはどういうときか」から攻める
        - 具体的に洗い出すことで、対処しやすくなる
- 2: 仕組みを知る
    - LLMのサービス側で情報がどのように扱われるかを理解する等
    - 仕組みを知れば知るほど許容の判断もしやすくなる
- 3 分離する
    - 情報に少しでもセンシティブなものが混ざっていると、その情報全体がセンシティブになる
    - これを[* センシティブの汚染]という
    - 汚染された情報は使いづらくなるので、汚染されないよう日頃から分けて扱うようにする
        - [分離エンジニアリング](分離エンジニアリング.md)