EU AI法は2024年8月に施行され、規定は2～3年の期間をかけて段階的に導入されます[1][2]。これまでのところ、多くの企業のコンプライアンスに関する議論は、ワークフローが「高リスク」カテゴリーに該当するかどうかに集中していました。2026年中頃までには、議論はより実践的な問いに移行しています：そのワークフローが です 対象範囲内で、どの展開アーキテクチャが実際にデプロイヤーの義務を満たし、どれが静かに満たしていないのか？

その第二の質問こそが、オンプレミス展開が単なるスタイルの好みから構造的な適合へと変わるポイントです。

高リスクAIの導入者に求められること

本法は以下の区別を設けています プロバイダー AIシステムの 展開者 それに関して[1]。第三者のLLM APIを利用してローン申請を評価する銀行は、提供者ではなく展開者です。高リスクシステムの展開者は、人間の監督の確保、システム運用の監視、適切な期間のログ保持、システムが基本的権利にリスクをもたらす場合の使用停止、そしてこれらの能力を求めに応じて証明する義務を負います。

いくつかの義務は、デプロイヤーがランタイムを管理している場合には明快です。推論がデプロイヤー所有のサーバーで行われ、ログがデプロイヤーのSIEMに記録される場合、「適切な期間ログを保持する」義務は機械的に簡単です。同様に、「使用停止」義務も、デプロイヤーが自社インフラ上でモデルを停止できる場合には容易です。

同じ義務は、推論がデプロイヤーが運用していないクラウドのLLM API上で実行される場合、より困難になります。デプロイヤーが生成できるログは、プロバイダーが公開する範囲に限られます。利用停止にはプロバイダーの協力が必要です。システムを通過したデータを同時に示すには、プロバイダーのパイプラインを信頼する必要があります。

クラウドLLM APIの規制における位置づけ

これらのいずれも、クラウドLLM APIが非準拠であることを意味しません。条文ごとに見ても、クラウドホスト型AIの提供者および展開者は本法の義務を満たすことが可能です。問題となるのは法的な側面ではなく運用上の摩擦であり、展開者はベンダーの境界を越えて、しばしば1日に数千回の推論を実行するワークフローに対して、コンプライアンスの組み立て、監査、証明を行わなければなりません。

スタンフォードHAIの長期的なAIインデックスは、企業の支出の対応する変化を追跡しています[3]。2023年から2025年にかけて最も急激に成長したのは汎用の生成AIではなく、観測性、ガバナンス、プロンプトログ記録、コンテンツ分類、ジャイルブレイク検出といった支援ツールでした。これらの支出の大部分は、クラウドLLM APIがネイティブに提供するものと、導入者が規制上の文脈で証明する必要があるものとのギャップを埋めるために存在しています。

その差が、導入者が所有するハードウェア上で推論を実行することの構造的な利点です。あらゆる「これは起こったのか？」という問いは、導入者自身のログから答えられる問いに収束します。

オンプレミスでは無料で得られないもの

AI法における3つの導入者義務は次のとおりです いいえ オンプレミス展開によって自動的に満たされる要件であり、明確に挙げておく価値があります：

  • 人間の監督。 本法は、高リスクAIに対して意味のある監視を求めており、人間が出力を解釈し介入できることが必要です。モデルをローカルで実行すること自体が人間を介在させるわけではなく、ワークフローデザインがそれを実現します。
  • ドリフトおよび安全でない動作の監視。 導入者はシステムを継続的に監視しなければなりません。オンプレミス展開は 配管 些細なことです（データはローカルです）が、ポリシー（「このワークフローにおけるドリフトとは何か？」）は依然として定義する必要があります。
  • プロバイダーの義務が引き継がれました。 オンプレミス展開がサードパーティのモデル（例：非商用ライセンスのオープンウェイトモデルやバイナリとして提供されるベンダーモデル）に基づいている場合でも、展開者はプロバイダーが求める開示事項を明示する必要があります。

オンプレミスの構造的な利点は、ポリシーではなくデータ処理と実証可能性の軸にあります。ポリシーはGPUの設置場所に関係なく策定され、施行されなければなりません。

これが米国、英国、その他の法域にどのように影響するか

EU AI法は主要な枠組みの中で最も詳細な規定を持っています。米国のNIST AI RMF[4]は任意のフレームワークベースのアプローチを採用しており、OECD AI政策オブザーバトリー[5]はEU外の各国政府がリスクベースの監督、透明性義務、データ処理規則といった大まかに類似した原則に収束している様子を追跡しています。

多国籍展開者にとって、実際の影響は最も厳しい法域がアーキテクチャを決定するということです。ワークフローが欧州のユーザー向けにEU AI法を満たす必要がある場合、その同じワークフローはEUの基準に基づいて設計されていれば、米国、英国、日本、シンガポールの義務を満たさないことはありません。最も厳しい基準に基づいて展開を設計すること—展開者がリクエストごとのデータ処理を証明できる能力を含め—これが2026年の企業向けAIにおいてオンプレミスが構造的によりシンプルなデフォルトとなる理由です。

2026年のコンプライアンスに対応したオンプレミスAI導入の姿

当社が提供する形態、そして当社が連携するコンプライアンス審査担当者が求める形態は以下の通りです。

  • 推論は顧客のローカル環境で行われます。 ユーザーのデバイス上、または顧客が運用するサーバー上で実行されます。プロンプトは境界外に一切送信されません。
  • コンテンツを含まない監査ログ。 すべての管理操作はタイムスタンプと実行者とともに記録されます。プロンプトや応答は監査ログには含まれません。監査ログ自体が証拠となり、コンテンツは導入者が自身の保持ポリシーに従って管理します。
  • 顧客のIdPによる認証。 Microsoft Entra IDまたはGoogle Workspaceに対するOIDC認証を用い、導入者の既存のアクセス制御は変更なく適用されます。
  • ベンダー運用の推論テナントはありません。 Software Tailorはこの経路でモデルの実行環境を運用せず、プロンプトや応答、顧客のドキュメントを受け取りません。組織の認証、ライセンス、ポリシー、サーバー状態、集計利用状況、監査およびサポート記録はベンダーのコントロールプレーンを利用可能ですが、別個の依存関係として評価が必要です。

この最後の推論の特性は、クラウドのLLM APIが構造的に再現できないものです。これによりオンプレミス製品が自動的に準拠するわけではなく、コントロールプレーン、サポート経路、モデルのサプライチェーン、顧客の運用責任の評価が依然として必要です。

当社がこの方針を最初から構築してきた背景については、 AIをクラウドSaaSではなくインストール可能なバイナリとして提供する理由に記載しています。監査、認証、ポリシーの機能は AI Admin Consoleに実装されています。

参考文献

  1. 欧州委員会「AI法 — AIに関する規制枠組み」 https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai（2026年6月15日アクセス）
  2. 欧州委員会「AI法の施行」 https://digital-strategy.ec.europa.eu/2026年6月15日アクセス。
  3. スタンフォードHAI。「AIインデックスレポート」。 https://aiindex.stanford.edu/2026年6月15日アクセス。
  4. NIST。「AIリスク管理フレームワーク（AI RMF 1.0）」。 https://www.nist.gov/itl/ai-risk-management-framework2026年6月15日アクセス。
  5. OECD AI政策オブザーバトリー。「国家AI政策」。 https://oecd.ai/2026年6月15日アクセス。