オンプレミス AI の導入が調達段階で停滞する理由(そしてそれを解消するフレーミング)
エンタープライズの AI 調達が停滞するのは、技術ではなく deployer(導入者)義務が原因です。2026 年に停滞を解消する導入アーキテクチャの特性、そしてコンプライアンス部門が今問うている問いに対して「当社は SOC 2 に準拠しています」が誤った回答である理由を解説します。
2027 年 12 月 2 日までに、EU AI Act の deployer(導入者)義務は、生体認証、重要インフラ、教育、雇用、移民、庇護、国境管理に用いられる高リスク AI システムに適用されます[1]。2026 年のコンプライアンス部門は、2027 年 12 月まで対応を待つことはしません。すでにベンダーデューデリジェンスのアンケートを作成しており、エンタープライズの AI 調達は、調達対象となる技術とはほとんど関係のない理由で、これらのアンケートにより停滞しています。解決策は、より優れたデモを行うことではありません。調達の対話が実際に何についてのものなのかを、再構成することです。
2026 年における「停滞」の実態
技術的な概念実証は通過します。モデルは顧客の実ワークロード上で有用な出力を生成します。技術評価担当者は肯定的な所見を書き、書類を調達部門に引き渡します。そして書類はそこで止まります。3 週間後、顧客のコンプライアンス部門が次のようなメモとともに戻ってきます。「当社が制御していないエンドポイントで推論が行われる場合、このワークフローにおける deployer 義務を立証することはできません。」
a16z のエンタープライズ調査は、このパターンが形成されつつあった当時の形状を捉えています。新しい要件に適合する製品については、「以前は成約まで 1 年以上を要していた取引が、2 ~ 3 か月で進められている」と報告されています[4]。逆もまた然りです。新しい要件に適合しない製品の調達は、依然として 1 年を要します。強力な技術パイロットがあっても、それは変わりません。
調達部門が実際に立証を求められていること
EU AI Act は、AI システムのprovider(提供者)とdeployer(導入者)を区別しています[1]。サードパーティ LLM API を用いて融資審査スコアを算出する銀行は deployer です。Deployer 義務には、人間による監督、モニタリング、インシデント報告、そして要求に応じてこれらの能力を実証することが含まれます。これらの義務は LLM ベンダーではなく銀行に課されます。そして銀行の調達部門こそが、ベンダー選定によって義務充足の現実性が決まる接点となります。
この流れは EU に限ったものではありません。NIST は 2026 年 4 月 7 日に、Trustworthy AI in Critical Infrastructure に関する AI RMF プロファイルの概念ノートを公表しました[2]。これは米国における重要インフラ運営者を対象とした AI RMF deployer 義務の、連邦レベル初のスコーピングです。OECD AI Policy Observatory は「80 を超える法域および組織」からの情報を継続的に集約するリポジトリを維持しています[3]。法域を越えた deployer 側義務への収斂は、例外ではなく趨勢です。
規制業種の調達部門はこれらのシグナルを読み取り、先回りして体制を整えます。ベンダーアーキテクチャが自らの義務充足を可能にするかどうかを、2027 年 12 月 2 日まで待って判断することはできないのです。
「当社は SOC 2 に準拠しています」が誤った回答である理由
従来エンタープライズの調達対話を解決してきたベンダー側統制の回答 —— SOC 2 Type II、ISO 27001、GDPR に整合する DPA —— はベンダー側の統制を扱うものです。これらは必要条件ですが、今まさに到来しつつある deployer 義務に対しては十分ではありません。
Deployer 義務は、deployer が要求に応じて、どのようなデータが AI システムを通じて流れたかを実証することを求めます。これは deployer 自身のログに関する問いであり、ベンダーのログに関する問いではありません。プロンプトとレスポンスをマネージドクラウド内に保持する SOC 2 適合ベンダーでは、このギャップを埋めることができません。なぜならギャップは deployer 側の境界内にあるからです —— deployer は、自らが見えないものについてログを生成することはできません。
これが調達の対話を停滞させる構造的なミスマッチです。コンプライアンス部門は deployer 義務に照らしてメモを書きます。ベンダーはベンダー側の認証で応答します。両者は互いに行き違うばかりです。
停滞を解消するフレーミング
ベンダーアンケートの冒頭で明示される、導入アーキテクチャの 3 つの特性が、停滞を解消します。
- Deployer に対してローカルな推論。ユーザーのデバイス上、または deployer が運用するサーバー上のいずれかで実行されます。プロンプトとレスポンスは deployer の境界を離れません。
- Deployer が保有する、コンテンツを含まない監査ログ。すべての管理アクションは、タイムスタンプとアクターとともに deployer の SIEM に記録されます。監査行にはプロンプトもレスポンスも記載されません。行が証跡であり、コンテンツは deployer 自身の保存ポリシーに従って保持されます。
- Deployer の IdP を介した認証。Microsoft Entra ID または Google Workspace に対する OIDC。Deployer の既存のアクセス制御および SSO ポリシーが、そのまま適用されます。
これらは認証されるべきベンダー特性ではありません。仕様として定められるべき導入アーキテクチャ特性です。ベンダーアンケートをこれらに照らして構成すれば、コンプライアンスメモは自ずと書き上がります。すべての deployer 義務に対して、deployer が指し示せる対応するアーキテクチャ特性が存在するからです。
当社が提供する形態における具体像
Software Tailor の AI Suite は、ローカルの推論プロセスと通信するデスクトップインストーラーとして提供されます。AI Admin Console は、deployer の IT 部門がポリシー適用、ライセンス管理、監査の可視化に用いる管理画面です。製薬、金融、政府、法律、防衛、エネルギーの各分野にわたる Fortune Global 500 の 6 社が、2007 年以降この形態で導入を行ってきました(過去の顧客)。そして、いずれの案件も、契約締結前に上記フレーミングの何らかの形を経ています。
これを具体化する最速の方法は、実際のワークロードでこれを通すことです。無料の 1 週間パイロットは、顧客のハードウェア上にモデルを、顧客の SIEM に監査行を、顧客の IdP を介した認証を配置します —— コンプライアンス部門が、実際に直面する義務に照らしてメモを書き上げるのに十分な材料が揃います。
参考文献
- European Commission.「AI Act — Regulatory framework on AI.」digital-strategy.ec.europa.eu。2026-06-03 閲覧。
- NIST.「AI Risk Management Framework.」nist.gov/itl/ai-risk-management-framework。2026-06-03 閲覧。Critical Infrastructure に関する概念ノートは 2026 年 4 月 7 日に公表されました。
- OECD AI Policy Observatory.「Policy Navigator dashboards.」oecd.ai/en/dashboards。2026-06-03 閲覧。
- Andreessen Horowitz.「State of Generative AI in the Enterprise.」a16z.com/generative-ai-enterprise-2024。2024 年 3 月 21 日公開。2026-06-03 閲覧。
関連記事
実際のワークロードを 1 つ、このフレーミングに通してみませんか。
無料の 1 週間パイロットでは、モデル、監査行、認証のすべてを顧客の境界内に配置し、コンプライアンス部門が実際に直面する義務に照らしてメモを書き上げることができます。