社内文書を AI に使わせるが生データは触らせない

AI を業務に入れたいのに、社内文書や個人情報がモデルや外部に漏れる懸念で止まっている方へ。「入れたいが怖い」が共通言語です。AI リテラシーが高くなくても構いません。

• 機密文書・個人情報を扱い、AI 活用が漏洩懸念で進まない企業
• 生成 AI・RAG・エージェントの導入を検討中だが、データガバナンスが課題の部門
• 「AI が何を参照したか」を後から説明する責任を負う立場

この業務は3つが同時に要ります。中身(生データ)を出さずに必要な事実を渡せること。第三者・AI が独立に検証できること。何を使ったかを改ざんなく残せること。

アクセス制御は「入れるか」を決めますが、「AI が何を使ったか」を後から証明できません。3つを同時に満たすのは ZK 証明だけ。1つでも欠けてよいなら既存手段で十分です。3つが同時に要る業務だけが Lemma の領土です。

文書を暗号化したまま、AI には「必要な事実・属性」だけを証明付きで渡します。生の PII や原本にはモデルを触れさせません。さらに、AI が「この事実だけを使った」ことを証跡として残せるので、後から参照内容を説明できます。

AI の判断が下された時点で、参照した事実の docHash と帰属を ZK でコミットします。モデルが更新されても、過去の参照を遡れます。

(御社のどの文書系・AI 経路から始めるか、まず会話で確認できます。)

数値はいずれも目安です。

導入する企業(事業部・情報システム) 「漏洩が怖い」を外して AI 導入を前に進められます。生データをモデルに渡さずに済みます。 例:AI 導入の停滞要因が、漏洩懸念の据え置きから、証明付き参照の運用へ。

ガバナンス・監査側 「AI が何を参照したか」を後から独立検証でき、説明責任を暗号証跡で果たせます。 例:参照の説明が、ログの突合から1つの証明提示へ。

本人・データ主体 生の PII がモデルや外部に渡りません。必要な事実だけが証明として使われます。

ある企業が、社内規程と顧客情報を参照する問い合わせ対応 AI を入れたいが、「顧客 PII がモデルや外部に漏れるのでは」と止まっているとします。アクセス制御を敷いても、「AI が実際に何を使ったか」を後から証明できず、監査で説明できません。

Lemma が導入されていれば、文書は暗号化したまま、AI には「この顧客は契約区分 A である」といった必要な事実だけが証明付きで渡ります。生の PII には触れさせません。判断時点で「どの事実をどの版から使ったか」が ZK で固定され、後から原本を開示せず説明できます。

既存の文書基盤・AI/RAG パイプラインを置き換えません。推論の前段に、事実抽出と証明を1段挟むだけです。

• 選択的開示:BBS+ over BLS12-381 で、原本ではなく必要な属性・事実だけを AI に提示。
• 判断時アテステーション:参照した事実の docHash と帰属を Poseidon over BN254 でコミットし、Groth16(Circom 回路)で証明。
• 来歴:参照元文書の版を docHash と発行者署名で固定。

原本は暗号化されたまま社内に留まり、検証側に渡るのは参照の暗号的事実だけです。

• AI が参照した事実・属性の docHash と、その参照元バージョン
• 「生データではなく、この事実だけを使った」ことの証明
• モデル更新後も不変な、参照の暗号的同一性
• データを開示せずに、ガバナンス・監査・第三者が独立検証できるトレイル

SaaS を単体で入れる話ではありません。AI 導入・データガバナンスのコンサルと PoC から入り、既存プラン月額に着地します。

1. 30分の棚卸し — AI を入れたいが漏洩懸念で止まっている文書系・業務を特定。
2. 証明したい判定(結果)を1〜2個に絞る — 例:「契約区分 A」「与信区分以上」など、AI に渡す事実。原本は出しません。
3. 接続と版管理を設計 — 既存文書基盤・AI/RAG パイプラインとの接続方式と、参照元の版固定。
4. PoC(見積ベース)で1経路を実証 — 1つの AI 業務で動くことを確認。
5. 既存プラン月額に着地(目安) — ユースケースに応じて Lemma Critical / Compliance へ。価格は会話のなかで確認。

「AI を入れたいが漏洩が怖い」を抱える業務を1つ、最初の30分で聞かせてください。機微情報の開示は必要ありません。