中級 15 分コンプライアンス

ローカルLLMとRGPD:個人データのコンプライアンス 企業

顧客データ、契約書、人事資料をChatGPTやClaudeに送ると、素朴な疑問が生じます。データはどこに送られ、誰が処理し、どの法域に属するのでしょうか。DPOにとって、複雑な契約上の調整なしにGDPRに適合する答えが得られることはまれです。Ollama、vLLM、LM Studioを使ったローカルLLMなら、この疑問は解消されます。データが企業のインフラから外に出ることはありません。本ガイドでは、企業のGDPR対応に向けたローカルLLMが2026年にDPOの標準的な技術構成となった理由、8月に全面適用されるAI Actによって何が変わるのか、そして導入環境を監査する方法を詳しく説明します。

著者 Mohamed Meguedmi·更新 2026-08-27·Windows・macOS・Linuxでテスト済み

#ローカルLLMが本来の仕組みからGDPRに適合している理由

GDPRは「AIの使用を禁止する」とは言っていません。個人データの処理には合法的な根拠が必要であり、文書化、最小化、セキュリティの確保が求められ、EU域外への移転は適切な枠組みで管理されなければならないと定めています。クラウドLLMの問題はAIそのものではなく、多くの場合アメリカの第三者の下請け業者による処理、複雑な契約チェーン、そしてGDPR第5章に規定される移転リスクにあります。

ローカルで実行されるLLMは、この方程式を逆転させます。モデルの重みはHugging Faceまたは Ollama から一度ダウンロードされ、その後、推論は100%あなたのハードウェア上で行われます。プロンプトはインターネットに送信されません。第三者によって回答がログ記録されることもありません。「処理」は内部に留まり、あなたの実効的な管理下にあります。

EU外への転送はありません
GDPR第44条および第V章:データが自社のサーバーから一切出ないため、標準契約条項(Standard Contractual Clauses)や移転影響評価(Transfer Impact Assessment)は不要で、米国のCLOUD Actに関する問題も生じません。
第28条にいうデータ処理受託者がいない
データ処理委託契約を交渉する必要も、提供元の製品が変更されるたびに付属書7を更新する必要もありません。提供元が利用規約を一方的に変更することもありません。
設計に組み込まれたデータ最小化
第5.1.c条:誤って第三者に過剰な量のデータを送信することはできません。第三者が存在しないためです。最小化はアーキテクチャの性質となり、遵守すべきポリシーではなくなります
実際の削除
第17条(消去権):自社のデータベース内の記録を消去するのは簡単です。6か月前に送信したプロンプトをOpenAIに消去してもらうよう依頼するのは、契約上の手続きであり、技術的な保証ではありません。
i
CNILの推奨事項
2024年以降、CNILはAIとGDPR(RGPD)に関する解説資料を定期的に公開しています。その立場は一貫しています。センシティブなデータ、健康データ、人事データ、または業務上の守秘義務の対象となるあらゆる情報を扱う処理では、オンプレミスのソリューション、またはデータ主権を確保できるソリューションを優先することです。
企業向けローカルAIキット

職場でのローカルAI導入:GDPR、AI Act、マルチユーザーアーキテクチャ、コスト、経営陣向けメモ。

  • 永久に利用できるオンラインスペース
  • PDF + ファイル
  • 生涯アップデート

現在、欧州では企業におけるLLMの利用に、2つの法令が重なって適用されます。RGPDは個人データを対象とし、AI ActはAIシステムそのものを対象とします。AI Actでは、個人データを処理するかどうかは問いません。

#RGPD:LLMに適用される規定

法的根拠(第6条)
正当な利益、契約の履行、同意:LLMによるすべての処理は、これらの法的根拠に基づく必要があります。ローカルLLMを使ってもこの義務はなくなりませんが、文書化は容易になります。
本人への情報提供(第13〜14条)
プライバシーポリシーには、ローカルで動作するものも含め、LLM を使用していることを明記する必要があります。モデル名を記載する必要はありませんが、利用目的は記載する必要があります。
AIPD (第35条)
高リスクの処理には影響評価が必要です。クラウドLLMを使う場合、データ保護影響評価(AIPD)には処理の委託先も含める必要があります。ローカルの場合、対象は自分のインフラに限定されます。
セキュリティ(第32条)
モデルおよびログを格納するディスクの暗号化、推論サーバーへのアクセス制御、ログ記録。社内インフラでは一般的な対策です。

#AI Act:2026年8月の期限

AI法(EU規則2024/1689)は2024年8月1日に発効しました。その規定は段階的に適用されます。汎用LLMにとって最も構造的な段階である汎用目的AI(GPAI)モデルに関する義務は、2025年8月2日に適用開始となりました。高リスクAIシステムに関する義務は2026年8月2日に適用され、本ガイドをお読みいただいている時点では約3ヶ月後です。

GPAI(基礎モデル)
義務を負うのは提供元(OpenAI、Anthropic、Mistral、Metaなど)です。Mistral、Qwen、Graniteをローカルで使用する場合も、要件に準拠した技術文書を提供する責任は、すでにモデルの提供元にあります。
高リスクシステム
附属書III:人事、信用スコアリング、教育、必要不可欠な公共サービス、重要インフラ。LLMがこれらの業務フローのいずれかに組み込まれている場合、利用者はAI Act上の「導入者」に該当し、その立場に固有の義務を負います。
透明性
AI が生成したすべてのコンテンツは、AI による生成物だと識別できる必要があります。自然人とやり取りするすべてのシステムは、そのことを相手に知らせなければなりません。社内チャットボットも例外ではありません。
制裁
最も重大な違反(禁止された使用)には、最大3,500万ユーロまたは世界売上高の7%。GPAIの義務違反には、最大1,500万ユーロまたは売上高の3%。
!
導入者と提供者の立場の違い
Qwen 3.6 35B-A3Bをローカルで動かしても、GPAIの提供者になるわけではありません。「導入者」の立場のままです。一方、モデルをファインチューニングして他の組織に提供すると、提供者の区分に移り、その区分に固有の義務を負う可能性があります。

#ChatGPT、Claude、Geminiを使う際の具体的なリスク

これらのベンダーは現在、企業向けプラン(ChatGPT Enterprise、Claude for Work、Gemini for Workspace)を提供しており、データを学習に使用しないことを契約で約束しています。プランによっては欧州でのホスティングも契約に含まれます。一般向けAPIよりはよい選択ですが、すべての問題が解決するわけではありません。

米国のCLOUD法
米国法に基づく法人(OpenAI Inc.、Anthropic PBC、Google LLC)は、EU内に保存されたデータについても、米国当局への協力を法的に義務付けられています。EU司法裁判所(CJUE)は、2020年のSchrems II判決でこの点を改めて指摘しました。
存続が危ぶまれるDPF
データ移転の大半の根拠となっているEU・米国間のデータプライバシーフレームワーク(2023年7月)は、欧州連合司法裁判所(CJUE)でその有効性が争われています。Schrems IIIが起これば、数千件のデータ保護影響評価(AIPD)が一夜にして無効になることになります。
モデルの不透明性
モデルがトレーニング中に見た内容や、モダレーションフィルターがあなたのプロンプトをどう記録しているかについては、正確に把握できません。ChatGPT では、Enterprise版でも「abuse」というログは少なくとも30日間保存されます。
Shadow IT
実務上の最大のリスクは契約ではなく、従業員が人事関連のファイルを無料版ChatGPTにコピーして貼り付けてしまうことです。どんな方針を文書にしても、ブラウザのタブ1つで簡単に破られてしまいます。
→
経営会議に響く論点
ローカルLLMは、法的リスク(データ移転、AI Actに基づく制裁)とシャドーITのリスク(従業員がようやく社内で実際に使える代替手段を得られる)を同時に排除します。「ChatGPT Enterpriseより安い」と言えることはまれですが、ほぼ常に「リスクが低く、監査にかかる時間も短い」と言えます。

#2026年のDPO向け推奨スタック

スタックは1つに決まっているわけではありません。フランスのIT責任者(DSI)やデータ保護責任者(DPO)が、この18か月にわたって導入してきた、実績のある組み合わせが複数あります。3つの典型的な構成で、ニーズの90%をカバーできます。

#構成例1 — 小規模チーム、各自の端末

ハードウェア
RTX 4070(12 GB)、RTX 4080(16 GB)、またはMac M4 Pro(24〜48 GB)を備えた端末。中央サーバーはありません。
ソフトウェア
Ollama(各端末で動作するローカルデーモン)と、インターフェースとして LM Studio または Open WebUI を使用。データは一切、端末の外に出ません。
おすすめモデル
Mistral Small 24B Q4(14GB、フランス語にネイティブ対応、汎用モデルとして優秀)、またはVRAMが40GB以上なら品質を落とさずに使えるQwen 3.8 27B(262kのコンテキスト、画像対応、Apache 2.0)。
対象
法律事務所、会計事務所、中小企業の人事チーム、ジャーナリスト。個人利用を前提とする30人未満の組織すべてです。

#利用形態2 — 組織内の推論サーバー

ハードウェア
専用GPUサーバー:RTX 4090 24 GB、A6000 48 GB、またはRTX 3090 24 GBを2基。社内の情報システム、またはソブリンクラウド(OVH、Scaleway、Outscale)でホストします。
ソフトウェア
vLLMまたはOllamaで、内部ネットワーク上にOpenAI互換APIを公開。フロントエンドにはOpen WebUIまたはLibreChatを使い、企業のIdP(Keycloak、Azure AD)による認証を通してアクセスする構成。
おすすめモデル
VRAM容量に応じて、Mistral Small 24B、Qwen 3.6 35B-A3B、Granite 4.2 30Bから選びます(Qwen 3.6 35B-A3BのようなMoEモデルは、有効なパラメータが3Bだけなので、24GBのGPUでも高速です)。文書RAG用の埋め込みモデルには、BGE-M3またはSolonを使います。
対象
中堅企業(ETI)、社内法務部門、30~500人のデータチーム。共同利用とアクセス制御の一元管理が可能です。

#構成例 3 — 機密性の高いデータ向けのエアギャップ構成

ハードウェア
パブリックネットワークと物理的に分離されたサーバー。LUKSで暗号化されたディスク。モデルは中継コンピュータへの物理メディア経由でダウンロードされます。
ソフトウェア
vLLMはローカルでコンパイルし、llama.cppはソースからビルドします。公開コンテナは使わず、実行時にDockerイメージを取得することもしません。
おすすめモデル
検証済みの、許諾条件の緩やかなライセンスを採用したモデル(Apache 2.0のMistral、Qwen、Granite、Gemma 4など。重みの監査も実施済み)。理想的には、tarballのコピーをローカルに保存してあるモデル。
対象
医療(DMP、診療報告書)、防衛、特に機密性の高い営業秘密、OIV/OSE。クラウドでは、残余リスクが高いデータ保護影響評価(AIPD)の対象となるようなものすべて。

#導入:基盤となる5つのステップ

  1. 01
    用途を洗い出して整理する
    モデルを選ぶ前に、文章作成、翻訳、契約書の要約、ログ分析、一次対応サポート(N1)といった実際の用途を一覧にしてください。用途ごとに、扱うデータの機密性の区分(公開情報、内部情報、機密情報、職務上の守秘義務の対象となる情報)を記録してください。この整理結果が、AIPDの用途に関する付属資料になります。
  2. 02
    プロファイルとモデルを選ぶ
    マッピングとハードウェアの棚卸しに基づき、上記の3つのプロファイルから1つを選んでください。VRAMが16〜24 GBある場合は、まずQ4_K_MのMistral Small 24Bを選んでください。2026年のフランス語用途では、これが最もバランスの取れた選択です。標準で推奨される量子化方式は引き続きQ4_K_Mです(FP16と比べた品質低下は2%未満)。
  3. 03
    推論サーバーのインストール
    Ollamaはデフォルトでhttp://localhost:11434で接続を待ち受けます。内部ネットワークに公開する場合は、OLLAMA_HOST=0.0.0.0:11434を設定し、認証を管理するリバースプロキシ(Caddy、Traefik)の背後にAPIを配置してください。追跡可能性を確保するため、アクセスログを有効にし、6か月間保存してください。
  4. 04
    処理活動の記録簿に記載する
    処理活動の記録簿(GDPR第30条)に、「社内の生成AIによる支援」という処理の記録を作成または更新してください。処理の目的、データの種類、保存期間、技術的対策を記載します。ローカルで処理することも明示してください。
  5. 05
    研修を行い、周知する
    各従業員が署名するAI利用方針に、次の事項を明記します。(1) 社内インスタンスのみを使用すること、(2) 承認されていないクラウドツールの使用禁止、(3) 用途ごとに使用が許可されるデータの種類。CSEとの協議後、就業規則に添付してください。
Ollamaを内部ネットワークに公開する設定
# Sur Linux (systemd)
sudo systemctl edit ollama.service

# Ajouter :
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.interne.entreprise.fr"
Environment="OLLAMA_KEEP_ALIVE=24h"

# Recharger et redémarrer
sudo systemctl daemon-reload
sudo systemctl restart ollama

# Vérifier
curl http://serveur-ia.interne:11434/api/tags
!
0.0.0.0をリバースプロキシなしで公開しないでください
OLLAMA_HOST=0.0.0.0 は認証なしで API を公開しています。ネットワーク上の誰でもモデルを問い合わせ、会話リストを確認、ダウンロードできます。常に認証付きのリバースプロキシ(OIDC、mTLS、basic auth + IP フィルタリング)を設置してください。これは必須です

#コンプライアンス監査チェックリスト

このチェックリストは、企業でのローカルLLM導入について、GDPR・AI法の監査で確認されるであろう項目を網羅しています。印刷して各項目にチェックを入れ、記録として保管してください。

#ガバナンスとドキュメント

第30条に基づく処理活動の記録
「社内生成AI」の処理記録を最新の状態に保ち、目的、データ、期間、データの提供先(社内のみ)、技術的対策を記載します。
AIPD
データ処理のリスクが高い場合(人事、健康、プロファイリング)に実施します。モデルや用途に大きな変更があるたびに更新します。
AI利用規程
周知済み、署名済み、CSEへの意見聴取後に就業規則へ組み込み済み。
利用用途の整理
承認済みの用途と、用途ごとに使用が許可されたデータの最新リスト。
AI担当者の指定
組織に応じてDPO、RSSI、DSIのいずれかを責任者として明確に指定し、その権限と任務を正式に定めていること。

#技術的セキュリティ

保存データの暗号化
推論サーバーのディスクを暗号化(LUKS、BitLocker、FileVault)。ダウンロードしたモデルと、存在する場合はプロンプトのキャッシュも対象に含みます。
認証
APIへのアクセスはOIDCまたはmTLSで制限します。内部であっても、認証なしでアクセスできるOllamaインスタンスを設けてはいけません。
ログ記録
アクセスログ(誰が、いつ、どのモデルに問い合わせたか)は6〜12か月間保存します。プロンプトの内容は、明確に定められ、文書化された用途がある場合を除き、ログに記録しません。
ネットワークの分離
本番環境では、推論サーバーからインターネットへの外向きのアクセスはできません。機密性の高い用途での導入では、完全なエアギャップを設けます。
バックアップと復旧
文書化された災害復旧計画(PRA):モデルは社内アーカイブから再インストールでき、その際にHugging Faceへすぐにアクセスする必要はありません。

#AI Actへの適合性

システム分類
用途のリスクが限定的、高い、または最小のいずれに当たるかを判定済みです。高リスク(附属書III)に該当する場合は、専用の適合性文書一式があります。
ユーザーへの情報提供
各インターフェースには「AIによって生成されたコンテンツ」または同等の注意書きを表示します。AI Act 第50条、2026年8月から適用。
モデルのトレーサビリティ
使用したモデルの正確なバージョン、重みの入手元、ダウンロード日、SHA256ハッシュを記録・保存します。これにより、監査で「特定の日付に特定の回答を生成したのは、どのモデルか」という問いに答えられます。
人間による監視
高リスク用途では、個人に影響を与えるあらゆる決定(採用、スコアリング、制裁)の前に人間がレビューを行うための、文書化された手順。

#よくある落とし穴

「ローカル」でもテレメトリは収集
一部のインターフェース(古いバージョンの LM Studio、一部の VSCode プラグイン)はテレメトリを送信します。Wireshark や Little Snitch などの通信監視ツールで、外部に何も送信されていないことを確認してください。当サイトのプライバシーチェックリストガイドでは、この手順を説明しています。
ライセンスが曖昧なモデル
例えば Codestral 22B は非本番環境向けライセンスであり、企業での利用は禁止されています。Llama はコミュニティライセンスを採用しており、大規模企業(MAUが7億を超える企業)の利用を制限しています。本番環境にデプロイする前にライセンスを確認してください。特に大規模組織やソフトウェア企業の場合は、Apache 2.0 ライセンスのモデル(Mistral Small、Qwen 3.5/3.8、Granite 4.2、Gemma 4)を優先してください。
モデルとファインチューニングの混同
社内の人事データでファインチューニングを行うと、新たなデータ処理となり、その処理について独自のデータ保護影響評価(AIPD)が必要になります。ファインチューニングしたモデルは、学習データを記憶することで、そのデータを漏らす可能性があります(memorization)。機微なデータには、ファインチューニングよりもRAGを優先してください。
トレーサビリティの過小評価
18か月後に誰かから「3月にAIが私の案件についてどう答えたか見せてください」と求められたとき、答えられるようにしておく必要があります。監査ログの準備は初日から行い、最初のインシデントが起きるまで先延ばしにしないでください。
ローカルLLMがすべてを解決するという誤解
ローカルLLMはデータ転送の問題を解決しますが、利用方法の問題までは解決しません。人事評価の自動スコアリングに使うローカルモデルは、AI Act上、依然として高リスクシステムに該当します。ローカル実行 ≠ 適用免除。
i
CNILの見解の要約
CNILは2024年以降、AIに関する複数の解説資料を公開しています(法的根拠、データの最小化、AIPD-IAに関する資料)。ローカルでの実行を義務付けてはいませんが、特に機微なデータについて、RGPD第32条にいう「適切な技術的措置」として評価しています。

#さらに詳しく

コンプライアンスを確保したら、導入をさらに進めるために、次の3つの方向で取り組むとよいでしょう:

技術面でデータの機密性を確保する
プライバシーチェックリストは、DPO側の法的枠組みを補完するネットワークおよびシステムの確認項目を詳細に記載しています。本番環境への移行前に必ず確認してください。
内部ドキュメントに基づいたRAGの構築
汎用アシスタントを業務ツールにするには、RAG(Retrieval-Augmented Generation、検索拡張生成)を使えば、ファインチューニングなしで契約書、手順書、社内データベースの内容について質問できます。ローカルRAGの入門ガイドで、その基礎を説明しています。
ユーザーインターフェースを選ぶ
Open WebUIは、複数ユーザー対応、OIDC、組み込みRAG、ログなど、企業でのニーズの80%をカバーします。専用ガイドでは、リバースプロキシの背後にDockerでデプロイする方法を説明しています。
このガイドは役に立ちましたか?

ご意見、誤りのご指摘、補足はありますか?ぜひお知らせください。皆さんにとってより良いガイドにするために役立ちます。