← All articles

Business benefits Published 2026-06-03 · 6 min read

Why on-prem AI deployments stall in procurement (and the framing that fixes it)

Enterprise AI procurement stalls on deployer obligations, not technology. The deployment-architecture properties that resolve the stall in 2026, and why "we're SOC 2" is the wrong answer to the question compliance teams are now asking.

By 2 December 2027, deployer obligations under the EU AI Act apply to high-risk AI systems used in biometrics, critical infrastructure, education, employment, migration, asylum, and border control [1]. Compliance teams in 2026 are not waiting until December 2027 to position. They are writing vendor-diligence questionnaires now, and enterprise AI procurement is stalling on those questionnaires at a rate that has very little to do with the technology being procured. The fix is not a better demo. It is a reframing of what the procurement conversation is actually about.

What "stall" actually looks like in 2026

The technical proof-of-concept passes. The model produces useful output on the customer's own workload. The technical evaluator writes a positive note and hands the file to procurement. Then the file sits. Three weeks later, the customer's compliance team comes back with a memo: "We cannot evidence our deployer obligations on this workflow if the inference happens on an endpoint we do not control."

a16z's enterprise survey identified the shape of this pattern as it was forming: deal cycles that "used to take over a year to close are being pushed through in 2 or 3 months" for products that fit the new requirements [4]. The implication runs the other way too. Procurement for products that do not fit the new requirements still takes the year. Strong technical pilots do not change that.

What procurement is actually being asked to evidence

The EU AI Act distinguishes between the provider of an AI system and the deployer of it [1]. A bank running a third-party LLM API to score loan applications is the deployer. Deployer obligations include human oversight, monitoring, incident reporting, and demonstrating these capabilities on request. These obligations apply to the bank, not to the LLM vendor — and the bank's procurement team is the surface where vendor selection decides whether the obligations are practical to satisfy.

This direction is not EU-only. NIST released a concept note for an AI RMF Profile on Trustworthy AI in Critical Infrastructure on 7 April 2026 [2], the first federal scoping of AI RMF deployer obligations for critical-infrastructure operators in the United States. The OECD AI Policy Observatory maintains a living repository "from more than 80 jurisdictions and organisations" [3]. Cross-jurisdiction convergence on deployer-side obligations is the trend, not an outlier.

Procurement teams in regulated industries read these signals and pre-position. They cannot wait until 2 December 2027 to learn whether a vendor architecture will let them satisfy their obligations.

Why "we're SOC 2" is the wrong answer

The vendor-controls answer that historically resolved enterprise procurement conversations — SOC 2 Type II, ISO 27001, GDPR-aligned DPA — addresses vendor-side controls. They are necessary. They are not sufficient for the deployer obligations now landing.

Deployer obligations require the deployer to demonstrate, per request, what data flowed through the AI system. That is a question about the deployer's own logs, not the vendor's. A SOC-2-clean vendor that holds the prompt and response in a managed cloud cannot close this gap, because the gap is on the deployer's side of the boundary: the deployer cannot produce a log of something they do not see.

This is the structural mismatch that stalls the procurement conversation. The compliance team writes a memo against deployer obligations. The vendor responds with vendor-side certifications. The two ships pass.

The framing that resolves the stall

Three properties of the deployment architecture, named upfront in the vendor questionnaire, collapse the stall:

  1. Inference local to the deployer. Either on the user's device or on a server the deployer operates. Prompts and responses never leave the deployer's perimeter.
  2. Content-free audit logs the deployer owns. Every administrative action is logged with timestamp and actor, in the deployer's SIEM. No prompts or responses appear in the audit row. The row is the evidence; the content is the deployer's to retain under their own retention policy.
  3. Identity through the deployer's IdP. OIDC against Microsoft Entra ID or Google Workspace. The deployer's existing access controls and SSO policies apply unchanged.

These are not vendor properties to be certified. They are deployment-architecture properties to be specified. Once the vendor questionnaire is framed against them, the compliance memo writes itself: every deployer obligation has a corresponding architectural property the deployer can point at.

What this looks like in the shape we ship

Software Tailor's AI Suite ships as desktop installers that talk to a local inference process. AI Admin Console is the management surface the deployer's IT team uses to enforce policy, manage licenses, and surface audit. Six Fortune Global 500 customers across pharma, finance, government, legal, defence, and energy have deployed against this shape since 2007 (past clients), and every one of those engagements went through a version of the framing above before the contract was signed.

The fastest way to make this concrete is to walk through it on a real workload. A free 1-week pilot puts the model on the customer's hardware, the audit row in the customer's SIEM, and identity through the customer's IdP — enough for the compliance team to write the memo against the obligations they actually face.

References

  1. European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Accessed 2026-06-03.
  2. NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Accessed 2026-06-03. The Critical Infrastructure concept note was released 7 April 2026.
  3. OECD AI Policy Observatory. "Policy Navigator dashboards." oecd.ai/en/dashboards. Accessed 2026-06-03.
  4. Andreessen Horowitz. "State of Generative AI in the Enterprise." a16z.com/generative-ai-enterprise-2024. Published 21 March 2024. Accessed 2026-06-03.

Related articles

Walk one real workload through the framing.

A free 1-week pilot puts model, audit row, and identity inside the customer's perimeter, and lets the compliance team write the memo against obligations they actually face.

Get release updates

New free AI products, major updates, and a few releases available only via this site. No spam.