業務データ向けローカルRAG：機密文書のためのGDPR準拠AI（2026年版）

クイックファクト

• 6つの必須統制： Air-Gap、RBAC、監査ログ、暗号化、データ系統、削除パス。
• 3つの展開パターン： 単一ユーザーラップトップ（単独プロフェッショナル）、On-Premサーバー（5〜50ユーザー）、プライベートEUクラウド（複数法人）。
• DPIAは第35条で必須： 特別カテゴリの個人データ（医療、法的、生体）を大規模に処理する場合。
• EU AI Act： ほとんどのローカルRAGは限定リスク。retrievalが自動化決定（信用、雇用、給付）に供されると高リスクに昇格。
• 忘れられる権利： ソース文書、ベクトルインデックス、キャッシュ済みembedding、回答履歴まで伝播必須。
• METIのAIガバナンス2024は、機微情報を扱う日本企業に対しデータ主権を確保する展開を推奨。ローカル推論はその要件を構造的に満たします。
• Open-source embeddingモデル：重みのピン留め、完全ローカルinference、ライセンス確認の3条件下でのみGDPR準拠。

展開パターン比較

展開パターンの選択

なぜ機密データにローカルRAGか

• 越境移転（第44〜49条）。 個人データをEU域外のprocessorに送るには標準契約条項、移転影響評価、受領管轄に召喚権限が及ぶかという確かな回答が必要です。ローカルRAGはデータを移転しないため、論点が発生しません。
• Sub-processorの増殖（第28条）。 クラウドLLMプロバイダはhyperscalerインフラ、コンテンツモデレーション、observabilityベンダーに依存しがちです。それぞれがリストアップ、契約、監査を要するsub-processorです。ローカルRAGはデフォルトでsub-processorが0です。
• 学習データ漏洩。 多くのクラウドLLM規約は、有償のエンタープライズ枠で学習除外条項が確認されない限り、顧客プロンプトをモデル改善に使う権利を留保します。ローカルRAGは自社で重みを管理するモデルを動かし、ホストから何も出ません。
• クライアント契約の機密保持条項。 外部弁護士契約、M&A NDA、患者データ契約は、保護対象を第三者processorに送ることをしばしば禁じます。ローカルRAGは条項を完全に回避します。
• 召喚および司法手続によるエクスポージャ。 クラウドプロバイダに保管された文書はプロバイダ宛ての法的手続で強制提出され得て、controllerが事前通知を受けない場合もあります。社外に出ない文書は、あなた自身に対してしか強制できません。

6つの必須統制

1. 1
   Air-Gapまたは厳格なegress制御
   Why it matters: 文書とembeddingが外向き通信で漏れないことを確認します — テレメトリSDK、モデル更新プローブ、クラッシュレポーター、コンテンツモデレーションコールバック、フォントの第三者CDNなど。ネットワークアクセスを完全に無効化（真のAir-Gap）するか、署名付き更新サーバーのみ許可するegress allowlistを運用してください。
2. 2
   ロールベースアクセスを伴うユーザー単位認証
   Why it matters: 「誰がどの文書にアクセスしたか」を、規制当局が尋ねる前に答えられる必要があります。IDプロバイダに対するSSO、グループベースのコレクションアクセス、案件で必要なら文書単位のACL。共有アカウントは統制ではなく、起こるのを待つ監査失敗です。
3. 3
   ingestおよびretrievalをカバーする改ざん防止監査ログ
   Why it matters: 各文書について：誰がアップロードしたか、いつ、ソースパス、ハッシュ。各クエリについて：誰が尋ねたか、何を尋ねたか（ロギングポリシーが許す場合）、どのchunkがretrieveされ、どの文書IDから来たか、どの回答が返ったか。ログは改ざん検知可能（append-only、署名、規制当局の調査ウィンドウをカバーする保管期間）でなければなりません。プロンプトレベルの監査トレイル — バージョン管理、変更履歴、ロールバック — については[プロンプトのバージョン管理ワークフロー](/prompt-engineering/prompt-version-control-workflows?lang=ja)を参照してください。
4. 4
   保存時および転送時の暗号化
   Why it matters: ホストのディスク暗号化、内部のサービス間通信のTLS、盗難ラップトップや侵害された管理者アカウントを生き延びる鍵管理。クラウド展開では顧客管理鍵。これがないと、デバイス紛失が第33条の通知義務違反に転じます。
5. 5
   chunkからソースまでの決定論的データ系統
   Why it matters: retrieveされた各chunkは、ソース文書、ページ、セクション、バージョンに遡れる必要があります。これにより(a)回答の検証、(b)削除請求の履行、(c)生成された要約が法廷で問われたときの防御が可能になります。「どのchunkがどの回答を生んだか再現できない」は規制当局への許容回答ではありません。
6. 6
   ベクトルインデックスおよびキャッシュ済みembeddingを含む文書化された削除パス
   Why it matters: 忘れられる権利の請求は、ソースストアからベクトルインデックス、キャッシュ済みembedding、retrievalログの保管まで伝播する必要があります。多くの展開はソース削除はきちんと処理しますが、残りを忘れます。本番化前に削除runbookを文書化し、合成データでリハーサルしてください。

Air-Gapとegress制御

• 真のAir-Gap — DHCPなし、公的宛先へのDNS解決なし、外向きTCPなし。更新は管理者が物理的に接続する署名付きメディア経由。機密業務、特定の病院ネットワーク、悪意ある依存関係を脅威モデルに含む展開に最適です。
• Egress allowlist — 外向き通信は名前付き宛先の小リスト（モデル更新サーバー、IDプロバイダ、内部コレクタへのログフォワーダ）にのみ許可。それ以外はファイアウォールでドロップ。規制対象の部門展開のほとんどでは、これが現実的なデフォルトです。
• プラットフォームで確認すべき点： デフォルトのテレメトリゼロ、inference中の外向き呼び出しなし、UIにフォントCDNなし、ペイロードを送るクラッシュレポーターなし。Little Snitch等のツールやパケットキャプチャでテストベンチで検証してから本番昇格してください。
• 更新ガバナンス — モデル重み、embedder重み、アプリケーションコード、OSパッチはすべて統制された更新ウィンドウを通ります。更新を昇格する管理者が書面でサインオフし、変更がログに残ります。
• よくあるAir-Gap破れ： 第三者UIコンポーネントに同梱されたanalytics SDK、アプリケーションchromeのフォントCDN参照、起動時に走る「アップデート確認」プローブ。だから検証ステップが重要です — デフォルトを信用してはいけません。

監査に耐えるaudit logging

• Ingestイベント： 文書ID、ハッシュ（SHA-256）、ファイル名、ソースパス、アップロード者、タイムスタンプ、分類タグ、サイズ、ページ数、所有グループ、保管クラス。ingest時に各文書をタグ付けしてください — 大規模コーパスの遡及分類は困難で完全になることは稀です。
• Retrievalイベント： クエリID、ユーザーID、タイムスタンプ、retrieveされたchunk ID（およびその由来文書ID）、retrievalスコア、最終回答ハッシュ、モデル識別子、embedder識別子、使用したtop-K。クエリテキストそのものは機微 — 処理の目的が許す場合のみログし、そうでなければハッシュとタイムスタンプのみログしてください。
• 管理イベント： モデル昇格、embedder変更、インデックス再構築、ユーザー/グループ変更、ACL変更、アクセスポリシー変更。各イベントは責任ある管理者によって署名されます。
• 改ざん耐性： append-onlyログ、ハッシュチェーン（各エントリは前エントリのハッシュを参照）、out-of-band署名鍵、別管理者または書込専用メディアに保管された別コピーとの定期的整合確認。
• 保管期間： 規制当局の調査ウィンドウに整合 — 最低でも案件の保管期間、規制業界では一般的に6〜7年、業界規則がある場合はそれ以上。
• パイプライン： アプリケーションは構造化イベントを発し、forwarderが書込制限された別ログストアへ送ります。アプリケーションサーバーはログエントリを削除・書換できる権限を絶対に持つべきではありません — 職務分離がログを信頼性のあるものにします。

chunkからソースまでのデータ系統

• 文書レベルの系統： 各文書は安定した内部ID、コンテンツハッシュ、ingestタイムスタンプ、所有者、分類、保管クラスを持ちます。原本ファイルはソースストアに留まり、RAGシステムは参照のみを保持します。
• chunkレベルの系統： 各chunkは親文書ID、ページ（PDF）、セクション（構造化文書）、文字オフセット、長さ、chunking戦略バージョンを参照します。再chunkするとき（必ず行います）、古いchunkはin-place削除ではなくtombstoneにし、古いretrievalログが解決可能なまま保ちます。
• embeddingレベルの系統： 各embeddingベクトルはchunk IDとembedder識別子を参照します。embedderを変えるとき、新しいembeddingが検証され、それを参照する案件がクローズされるまで古いベクトルを保持し、その後にパージします。
• 回答レベルの系統： 各生成回答は、それを生んだchunk ID、モデル識別子、プロンプトテンプレートバージョン、タイムスタンプを参照します。「この回答はどこから来たか」をユーザーが尋ねたとき、システムはchunk → 文書 → ページを1クリックで解決します。
• 系統を壊さない再インデックス： 再構築は文書IDを保持し、chunking戦略バージョンをインクリメントします。古いchunk IDはretrievalログ内で解決可能なまま残り、ライブインデックスが進んでも問題ありません。

暗号化とアクセス制御

• 保存時暗号化 — ホストのフルディスク暗号化（Linux：LUKS、Windows：BitLocker、macOS：FileVaultはラップトップ向け）。サーバーではベクトルストアやingestステージング領域のパーティションも暗号化してください。クラウド展開には顧客管理鍵を、ポリシーに従い鍵ローテーション。
• 転送時暗号化 — サービス間ホップごとにTLS、localhost上でも。業界ベースラインに合わせた暗号スイート方針。脅威モデルが正当化する場合はMutual TLS — クラウド展開のサーバー間が典型例。
• 認証 — 既存IDプロバイダ（OIDC、SAML）に対するSSO。本番にはローカルアカウントなし。管理権限または機微コレクションへのアクセスを持つユーザーにはMFAを強制。
• 認可 — コレクションレベルのグループベースアクセス、案件で必要な場合は文書レベルACL（M&Aデータルーム、雇用調査など）。retrievalパイプラインはクエリ時にACLを強制する必要があります — UIだけではダメです。文書を見られないユーザーにはchunkも返ってはいけません。
• 管理アクセス — インデックスを読む・再構築する、監査ログを見る、ACLを変える権限を持つアカウントには特権アクセス管理（PAM）。常時管理者権限より、ログ付き正当化を伴うjust-in-time昇格が優れています。
• エンドポイントセキュリティ — ラップトップ展開には管理デバイス（MDM登録、暗号化、画面ロックポリシー強制）。文書ストアが復号されたまま無人でカフェに置かれた単独プロフェッショナルのラップトップは、書きたくないGDPR違反です。

単一ユーザーラップトップパターン

• ハードウェア — フルディスク暗号化、専用GPU（または近年のunified-memoryマシン）、最低32 GBのRAMを備えたワークステーションクラスのラップトップ。モデルとembedderはベクトルストアキャッシュとともにメモリに収まる必要があります。VRAMによるハード要件とモデル選択についてはローカルLLMハードウェアガイドを参照してください。
• ソフトウェア — ローカルで動く自己完結型のデスクトップRAGアプリ、重みを一度ダウンロードしハッシュにピン留めしたOpen-source LLM、Open-source embedder、暗号化ディスク上のローカルベクトルストア。ローカルRAGに適したオープンソースモデルの比較はOllama向けトップオープンソースモデルを参照してください。
• ネットワークposture — 業務中はAir-Gap、明示的な署名付き更新時のみ再接続。OSファイアウォールをデフォルトで全外向きdrop、更新ワークフロー用に明示的例外を作成してください。
• 文書の取り扱い — 暗号化ディスク上のソース文書、案件ごとの分離フォルダ構造、別場所保管の外付けディスクへの週次暗号化バックアップ。
• 監査posture — OSレベルの監査ログ（ログイン、ファイルアクセス、周辺機器イベント）が床面。アプリケーションレベルイベントはOn-Premパターンの方が容易ですが、ラップトップパターンではOSログを主記録として扱い、案件ごとの手書き記録で補完します。
• 限界 — 単一ユーザーラップトップはマルチユーザープラットフォームではありません。ラップトップやアカウントを共有する、文書ストアを同僚のマシンにコピーするのは、監査postureと適法性評価の両方を壊します。

On-Premサーバーパターン

• ハードウェア — エンタープライズGPU 1〜2基（小規模コーパスならワークステーションGPUも可）、冗長化ディスク、ECCメモリ、UPS搭載のサーバー。生コーパスの2〜4倍のストレージを、ベクトル、インデックス、ログ、バックアップ向けに見込んでください。
• ネットワーク — 企業ファイアウォール背後の専用VLAN、脅威モデルに応じてegress allowlistまたは完全Air-Gap。社内アクセスは企業ネットワーク経由のみ、公的ingressなし。
• ソフトウェアスタック — セルフホスト型RAGプラットフォーム（スタンドアロンのサーバーイメージかコンテナ化展開）、チャットモデルとしてのOpen-source LLM、Open-source embedder、コーパスサイズに応じたベクトルストア。アプリケーションサーバー、ベクトルストア、ログforwarderは別プロセス・別サービスアカウントで動作させます。
• ID — 企業IDプロバイダに対するフェデレーション、グループメンバシップがコレクションアクセスを駆動。機微コレクションは追加承認ワークフローでゲートします。
• バックアップとDR — 文書ストアとベクトルインデックスの夜次インクリメンタルバックアップ、週次フルバックアップ、ITが保持するオフサイトコピー。文書化された復元runbookを少なくとも年1回テスト。
• 運用 — 変更管理ポリシーに従ったパッチウィンドウ、四半期アクセスレビュー、忘れられる権利の請求向けに練習済み削除runbook、系統を保持するモデル・embedderアップグレードパスの文書化。
• 容量計画 — 数千件の文書と5〜50同時ユーザーは、単一のmid-range GPUサーバーで快適に収まります。それを超えるなら、より高性能なホストかプライベートクラウドパターンへの移行を計画してください。

On-Prem RAG向けベクトルデータベース選択肢

プライベートEUクラウドパターン

• プロバイダ選定 — hyperscalerのEUソブリンオファリングか欧州系クラウドプロバイダ。DPAは全sub-processorをリストアップ必須、EEA外のsub-processorがいる場合は移転メカニズムを示す必要があります。Schrems II型の移転影響評価は、直接のprocessorがEU所在でもファイルに含めます。
• リージョン — EU限定、明示的なデータレジデンシー保証付き。クロスリージョンレプリケーションは他のEUリージョンのみ。バックアップ目的でも一時的でもUSリージョンへのfailoverは不可。
• 暗号化 — ローテーション付き顧客管理鍵、プロバイダがサポートする場合はbring-your-own-key、鍵アクセスイベントはクラウドプロバイダの運用ログとは別に記録。
• ネットワーク — 公的ingressなしのプライベートVPC、企業ネットワークからの専用接続またはVPN経由のみアクセス、外向き依存にはegress allowlist。
• ID — 企業IdPに対するフェデレーション、共有サービスアカウントではなくユーザーIDに紐付くクラウドネイティブIAM、retrievalパイプラインで強制されるコレクション別ACL。
• Logging — クラウドネイティブの監査ログを既存SIEMに供給、アプリケーション監査イベントは別取込、規制当局期待に応える改ざん耐性保管。
• 契約 — DPAは第28条準拠、sub-processor列挙、必要に応じてSCCs対処、LLM重みおよび付随サービス（検索、テレメトリ、サポート）をカバーする明示的な学習禁止条項を含む必要があります。

EU AI Actの分類：限定リスク vs 高リスク

• 限定リスク（ほとんどのローカルRAG） — 文書をretrieve・要約して人を補助し、人が判断します。義務は主に透明性：ユーザーはAIと対話していることを認識する必要があり、生成コンテンツはそのことが識別可能で、操作的・欺瞞的設計は禁止。
• 高リスク — retrievalがActで列挙された領域（信用スコアリング、雇用スクリーニング、教育入学、必須公的サービス、法執行、移民、司法、生体識別、重要インフラ）の自動化決定に供されるケース。治療を推奨する臨床意思決定支援RAGは高リスク。臨床プロトコル要約RAGで医師がガイドラインを速く読むのを助けるものは高リスクではありません。
• 高リスクの義務 — ライフサイクルにわたるリスクマネジメントシステム、データガバナンス（学習・検証・テストデータの文書化）、技術文書、自動イベントロギング、ユーザーへの透明性と情報、人間の監督、精度と頑健性、上市前の適合性評価、市場投入後モニタリング。
• 汎用AIの考慮 — 汎用LLM（オープンソース問わず）の利用は、高リスク義務をモデルプロバイダに移しません。デプロイヤ（あなたの組織）が、そのモデルで構築するシステムの高リスク義務を負います。
• 禁止行為 — 社会スコアリング、無差別な顔画像スクレイピング、職場・学校での感情認識、特定のリアルタイム生体カテゴリ化。どれだけローカルで動かそうと、これらは対象外です。
• 監査成果物としての文書 — 高リスクシステムに必要な技術ファイルは一度きりの納品物ではなく、生きた文書です。変更管理プロセスと連動させ、モデル昇格、embedder変更、ACL変更ごとに反映させてください。

DPIA要件（第35条）

• 必須となるとき — 法的効果を伴うプロファイリングを含む系統的かつ広範な評価、特別カテゴリの個人データ（医療、法的、生体、人種、政治、宗教、組合）の大規模処理、公的領域の系統的監視。各国規制当局がDPIAを必ず要する処理リストを公表しています — 自分のものを確認してください。
• DPIAの範囲 — 目的および適法性、処理活動の記述、必要性と比例性、データ主体へのリスク評価、緩和策と残存リスク、DPOとの協議、残存リスクが高い場合は処理開始前に規制当局と協議。
• RAG固有のリスク： retrieveされたchunkからの個人再識別、人に影響する不正確な情報の生成、ログやバックアップ経由の漏洩、忘れられる権利の削除完全性、コレクション間の汚染、power userへの過大なアクセス。
• 文書化すべき緩和策 — 上記の6統制、加えて適法性が同意または正当な利益の場合のchunkレベルの黒塗り・仮名化、リハーサル証拠付き削除runbook、定義されたケイデンスのアクセスレビュー。
• レビュアー — DPOが承認、緩和後の残存リスクが高いままなら規制当局と協議。署名されたDPIAは、システムが高リスクでもある場合はEU AI Act適合文書とともに技術ファイルへ。
• 生きた文書 — コーパスが大きく拡張するとき、モデルやembedderが変わるとき、アクセス境界が変わるとき、またはベースラインとして毎年DPIAを再実施。変更管理プロセスに連動させてください。

ドイツ固有の留意点（Datenschutz）

• Betriebsratの共同決定 — §87 BetrVGにより、従業員のパフォーマンスや行動を監視するシステムは、展開前にBetriebsratとの合意を要します。従業員作成コンテンツ（メール、社内文書）に対するRAGは典型的にこれを発動させます。設計時にBetriebsratを巻き込み、合意（Betriebsvereinbarung）を適法性ファイルに含めてください。
• 業界別の守秘 — §203 StGBは職業上の守秘義務違反（弁護士、医師、税理士、監査人）を犯罪化します。守秘義務に拘束されないスタッフや外部processorに保護対象クライアントデータをさらすRAG展開は、民事ではなく刑事問題になり得ます。これらの業界ではOn-PremまたはAir-Gappedパターンが安全な選択です。
• TelemediengesetzおよびTTDSG — エンドユーザーデバイスに触れる外向きテレメトリはGDPRだけでなくTTDSGにも規律されます。Air-Gapはこの問いを取り除きます。egress制御展開では、外向き呼び出しが同意済み、必要、または厳格に技術的なものであることを検証する必要があります。
• BSI-Grundschutzバウシュタイン — 行政機関やKRITIS事業者には、BSI-Grundschutz-Kompendiumが拘束的な基準を提供します。中堅企業でも、OPS.1.2.4（クラウド利用）、OPS.2.1（アウトソーシング）、APP.4.4（Webアプリ）等のバウシュタインはアーキテクチャ文書の有用な参照になります。
• 監督機関（連邦・州レベル） — 民間部門のデータ保護監督は州レベルで組織されます。第36条に基づく協議が必要なら、所管のLandesbeauftragte für Datenschutzに相談してください。
• 文書言語 — ドイツの監督機関は英語の文書を受け付けますが、主要なユーザー向け成果物（プライバシー通知、透明性開示、Betriebsrat合意）は法的・実務的理由からドイツ語で書くべきです。

本番化前のコンプライアンスチェックリスト

• ☐ 適法性が文書化されている — 各カテゴリのソースデータについて：同意、契約、法的義務、生命に関わる利益、公的任務、または比例衡量を伴う正当な利益。
• ☐ DPIAがDPOによって承認、リハーサル済み削除runbookが添付されている。
• ☐ 処理活動の記録（第30条） が更新され、RAGシステム、データカテゴリ、保管、受信者、移転メカニズム（ローカルRAGでは典型的になし）を含む。
• ☐ 6統制がエンド・ツー・エンドで検証 — Air-Gapまたはegress allowlist、RBAC、監査ログ、暗号化、系統、削除パス。
• ☐ 外向きパケットキャプチャ が24時間soakテストでクリーン、アプリ更新ごとに繰り返される。
• ☐ IDプロバイダ統合 が各アクセス層の実ユーザーでテスト済み、機微コレクションアクセスは別の昇格を要する。
• ☐ バックアップが取得され、復元が実際にテスト されている — ステータスパネルでの確認だけでなく分離ハードでの実テスト。
• ☐ 忘れられる権利runbookがリハーサル済み — 合成データでソースストア、ベクトルインデックス、キャッシュ済みembedding、retrievalログ保管をカバー。
• ☐ EU AI Act分類 確認済み（限定リスク vs 高リスク）、高リスクなら技術ファイル準備済み。
• ☐ ベンダー契約（あれば）レビュー済み — DPAが第28条準拠、sub-processor列挙、顧客データをカバーする学習禁止条項。
• ☐ Betriebsrat合意 が、従業員作成コンテンツが範囲に含まれる場合に存在する（ドイツ、類似のEUルールが他国にも）。
• ☐ 透明性通知 がユーザー向け平易な言葉で起草され、AI支援、human-in-the-loop、データフローを説明。
• ☐ インシデント対応runbook がRAG固有シナリオを含めて更新 — インデックス漏洩、ログ改ざん、削除失敗、下流系統を壊すモデル交換。
• ☐ 四半期アクセスレビュー がスケジュール・割当済み、本番化前に最初のレビューがカレンダーに。
• ☐ 年次DPIAリフレッシュ がスケジュール済み、変更管理プロセスに連動。

よくある誤り

• 誤り1：「ローカル」を「準拠」の同義語として扱う。 On-Prem運用は移転とprocessorの問いを解きますが、適法性、DPIA、監査ロギング、データ主体権は解きません。コンプライアンスは多層プログラムであり、展開選択ではありません。
• 誤り2：システムが「ただの検索ツール」だからとDPIAをスキップする。 特別カテゴリの個人データを大規模にingestする検索ツールこそが第35条の対象です。DPIAをスキップすれば監査時の防御もスキップしたことになります。
• 誤り3：適法性を確認せずにクエリテキストをログする。 クエリは個人を参照すれば自身が個人データです。設計時に処理目的がクエリロギングをカバーするか決め、カバーしないならハッシュとメタデータのみログしてください。
• 誤り4：削除runbookでキャッシュ済みembeddingを忘れる。 ソース削除は機能します。ベクトルインデックス再構築も機能します。プラットフォームがパフォーマンス目的で追加したキャッシュ層、retrievalログ内のembedding指紋、チャットストアの回答履歴は見落とされる箇所です。
• 誤り5：power userにコレクションACLのバイパスを許す。「管理者は全部見える」は便利でとても一般的ですが、監査が悪化する単独最大の理由でもあります。特権アクセス自体がアクセス制御され、時間制限され、利用ごとに正当化される必要があります。
• 誤り6：複数案件・クライアントで1ワークスペースを使い回す。 引用とコンテキストの相互汚染は、外部に見られる前から守秘失敗です。1ワークスペース1案件・1クライアント、ACL分離、保管分離。
• 誤り7：Air-Gapを買って、テストに私物スマホを差す。 Air-Gap境界はデータを越境させ得る人を含む必要があります。エンドポイントポリシーは統制の一部であり、別件ではありません。
• 誤り8：モデルとembedderの選択を「設定して放置」と扱う。 すべてのアップグレードはDPIA、系統、監査トレイルへの含意を持つ変更管理イベントです。最初の本番展開前にアップグレードワークフローを計画してください。

出典

• GDPR全文（公式） — 一般データ保護規則の完全テキスト、条文ごとの注釈付き。
• EU AI Act全文 — リスク分類フレームワークを含む完全な規則テキスト。
• NIST AI Risk Management Framework — AIリスク評価に適用可能な米連邦ガバナンスフレームワーク。
• BDSG-Neu（ドイツ連邦データ保護法） — 業界別追加を含むGDPRのドイツでの実装。
• EDPBによるDPIAガイドライン — DPIAをいつ・どう実施するかに関する欧州データ保護理事会の指針。
• METI AI事業者ガイドライン — 経済産業省のAIガバナンス指針、日本企業のAI展開に対するベストプラクティス。

FAQ

関連資料

• AnythingLLM vs PrivateGPT vs Open WebUI：最良のローカルRAG — どのセルフホストプラットフォームがどのコンプライアンスpostureに合うか、テレメトリとライセンスに関する注釈付き。
• 業務ワークフローとEUコンプライアンスのためのローカルAIエージェント — retrievalが人間の読者ではなく自動化ワークフローステップを供給するときの隣接コンプライアンス話題。
• ローカルLLMでのメール・カレンダー自動化 — 同じ統制セットが適用される隣接業務自動化パターン。
• ローカルRAGでPDFをステップバイステップ — On-Premとラップトップパターンの実践的な実装ウォークスルー。
• 1,000件のPDFとローカルでチャット — On-Prem上限を押し上げる大規模コーパスの運用ガイダンス。
• Power Local LLMハブ — セルフホストLLM展開の完全なガイドライブラリ。