2026 年における EU AI Act:オンプレミス導入がコンプライアンスにもたらす変化
EU AI Act の高リスク deployer(導入者)義務は 2026 年を通じて段階的に施行されます。オンプレミス導入は規制を回避するものではありません。しかし、どの義務を現実的に充足できるか、そしてクラウド SaaS では充足できない義務がどれかを変えます。
EU AI Act は 2024 年 8 月に発効し、2 ~ 3 年の期間をかけて条項が段階的に施行されます[1][2]。これまでのところ、エンタープライズにおけるコンプライアンス対話の大半は、ワークフローがそもそも「高リスク」カテゴリーに該当するかどうかに集中してきました。2026 年半ばには、議論はより実務的な問いへと移っています。すなわち、ワークフローが対象範囲に含まれるとして、どの導入アーキテクチャであれば deployer 義務を実際に充足できるのか、そしてどのアーキテクチャでは静かに充足できなくなるのか、という問いです。
この第二の問いこそが、オンプレミス導入が様式的な好みであることをやめ、構造的な適合となり始める場所です。
高リスク AI の deployer に対し、本法が求めること
本法は、AI システムのprovider(提供者)とdeployer(導入者)を区別しています[1]。サードパーティ LLM API を用いて融資審査スコアを算出する銀行は、provider ではなく deployer です。高リスクシステムの deployer は次のような義務を負います:人間による監督の確保、システム稼働状況のモニタリング、適切な期間のログ保持、システムが基本権に対するリスクをもたらす場合の使用停止、そしてこれらの能力を要求に応じて実証すること。
これらの義務のいくつかは、deployer がランタイムを制御している場合には明快です。「適切な期間のログを保持する」義務は、推論が deployer が所有するサーバー上で行われ、ログが deployer の SIEM に着地するならば、機械的に単純です。「使用停止」義務も、deployer が自社インフラ上でモデルを停止できるなら、同様に容易です。
これらの義務は、deployer が運用していないクラウド LLM API 上で推論が行われる場合には難しくなります。Deployer が生成できるログは provider が公開するものに限られます。使用停止には provider の協力が必要です。どのようなデータがシステムを通じて流れたかを同時並行的に実証することは、provider のパイプラインを信頼することを必要とします。
クラウド LLM API が規制のどこに位置するか
以上のいずれも、クラウド LLM API を不適合とするものではありません。条項単位で見れば、クラウドホスト型 AI の provider および deployer は、本法の義務を充足できます。摩擦は法的なものではなく運用上のものです。Deployer はベンダー境界を越えてコンプライアンスを組み立て、監査し、実証しなければならず、しかも 1 日あたり数千件の推論を実行するワークフローについて、それを行うことが多いのです。
Stanford HAI の長期的な AI Index は、エンタープライズ支出における対応するシフトを追跡しています[3]。2023 ~ 2025 年で最も急峻な成長は、汎用生成 AI そのものではなく、それを支える周辺ツール —— オブザーバビリティ、ガバナンス、プロンプトロギング、コンテンツ分類、ジェイルブレイク検知 —— で見られました。この支出の大半は、クラウド LLM API が標準で公開するものと、deployer が規制文脈で実証する必要があるものの差を埋めるために存在しています。
そのギャップこそが、deployer が所有するハードウェア上で推論を行うことの構造的優位性です。「これは発生したか?」という問いはすべて、deployer が自社ログから回答できる問いに収束します。
オンプレミスでも無償で得られないもの
AI Act の deployer 義務のうち 3 つは、オンプレミス導入によって自動的には満たされません。これらを明示的に挙げる価値があります。
- 人間による監督。本法は、高リスク AI に対する実効的な監督を要求し、人間が出力を解釈し介入できることを求めます。モデルをローカルで稼働させても、人間がループに入ることにはなりません。ワークフロー設計がそれを担います。
- ドリフトおよび不安全な挙動のモニタリング。Deployer はシステムを継続的にモニタリングしなければなりません。オンプレミス導入は配管を単純化しますが(データがローカルにあるため)、ポリシー(「このワークフローにおいてドリフトとはどのようなものか?」)は依然として定義する必要があります。
- Provider 義務の引き継ぎ。オンプレミス導入がサードパーティのモデル(例えば非商用ライセンスのオープンウェイトモデル、またはバイナリとして提供されるベンダーモデル)の上に構築されている場合でも、deployer は provider の必須開示事項を表面化する必要があります。
オンプレミスの構造的優位性は、データ取扱いおよび実証可能性の軸にあり、ポリシーの軸にはありません。ポリシーは、GPU がどこにあるかに関わらず、策定され執行されなければなりません。
米国、英国、その他の法域との関係
EU AI Act は主要な枠組みの中で最も規範的です。米国の NIST AI RMF[4]は任意的でフレームワークベースのアプローチを採り、OECD AI Policy Observatory[5]は EU 以外の各国政府が概ね類似した原則(リスクベースの監督、透明性義務、データ取扱い規則)に収斂しつつある状況を追跡しています。
多国籍 deployer にとって実務的な帰結は、最も厳格な法域がアーキテクチャを決定するということです。あるワークフローが欧州ユーザーに対して EU AI Act を充足しなければならないなら、同じワークフローを EU の基準に合わせて設計すれば、米国、英国、日本、シンガポールの義務にも違反しません。Deployer がリクエスト単位のデータ取扱いを実証する能力を含め、最も厳格な基準に合わせて導入を設計すること —— これこそが、オンプレミスを 2026 年のエンタープライズ AI における構造的により単純なデフォルトとするものです。
2026 年のコンプライアンスに対応したオンプレミス AI 導入の形
当社が提供する形 —— そして当社が協働するコンプライアンスレビュアーが求める形 —— は次のとおりです。
- 顧客に対してローカルな推論。ユーザーのデバイス上、または顧客が運用するサーバー上のいずれか。プロンプトは境界を離れません。
- コンテンツを含まない監査ログ。すべての管理アクションがタイムスタンプとアクターとともに記録され、監査行にはプロンプトもレスポンスも記載されません。監査行が証跡であり、コンテンツは deployer 自身の保存ポリシーに従って保持されます。
- 顧客の IdP を介した認証。Microsoft Entra ID または Google Workspace に対する OIDC で、deployer の既存のアクセス制御がそのまま適用されます。
- ベンダー側テナントなし。ベンダー(当社)はランタイムを運用せず、データを目にせず、deployer のコンプライアンス態勢の障害点にもなりません。
この最後の特性こそが、クラウド LLM API が構造的に再現できないものです。そして、これが、2026 年における規制対象エンタープライズ領域で、オンプレミス導入が支配的なパターンとなっている理由です。
当社が当初からこの考え方に沿って構築してきた経緯については、当社が AI をクラウド SaaS ではなくインストール可能なバイナリとして提供する理由をご参照ください。監査、認証、ポリシー画面を実装する機能群は AI Admin Console に集約されています。
参考文献
- European Commission.「AI Act — Regulatory framework on AI.」digital-strategy.ec.europa.eu。2026-06-15 閲覧。
- European Commission.「AI Act enters into force.」digital-strategy.ec.europa.eu。2026-06-15 閲覧。
- Stanford HAI.「AI Index Report.」aiindex.stanford.edu。2026-06-15 閲覧。
- NIST.「AI Risk Management Framework (AI RMF 1.0).」nist.gov/itl/ai-risk-management-framework。2026-06-15 閲覧。
- OECD AI Policy Observatory.「National AI policies.」oecd.ai。2026-06-15 閲覧。
関連記事
Deployer 義務を、実際のワークロードで通してみませんか。
無料の 1 週間パイロットでは、顧客のコンプライアンス部門が deployer 義務を実際の業務に照らして検証します。ローカル推論、顧客の IdP、顧客の監査証跡を用いて行います。