Should the AI security purchase precede or follow the deployer's AI policy work?

The AI policy and the AI security product have to be developed together. A policy with no enforcement architecture is aspirational. An enforcement architecture with no policy has no decisions to make. The pattern that works is to scope the initial policy at the same time as the product evaluation, with the product's policy language influencing what the initial policy can express and the policy requirements influencing the product short list.

How long does an AI security vendor evaluation typically take?

The evaluation depends on the deployer's depth of analysis. A typical pattern is two to three weeks of vendor briefings, one to two weeks of technical proof of concept on the deployer's AI traffic, and two weeks of compliance and procurement review. The full cycle runs six to ten weeks. Compressing the cycle beyond six weeks usually skips the technical proof of concept, which is the part of the evaluation that surfaces the architectural fit questions.

What is the typical procurement size for an AI security purchase?

The size depends on the deployer's AI traffic volume and the regulatory scope. Single-product purchases for a focused use case typically sit in the mid-five-figure annual range. Enterprise-wide platform purchases sit in the high-six-figure to seven-figure annual range, with the price reflecting the traffic volume, the number of identity-bound users, and the support model. The cost of an EU AI Act non-compliance penalty (15 million EUR or 3% of global turnover) reframes the purchase economics for deployers in scope.

How does the AI security purchase interact with the existing CASB and DLP purchase?

The AI security product covers a surface the CASB and DLP do not reach. The CASB covers SaaS-app adoption. The DLP covers structured data movement across email, storage, and endpoint. The AI security product covers the prompt-layer content and the per-decision authorization. The three products operate at complementary layers, with the AI security product owning the records and the policy at the AI request boundary. The pattern of operating all three is becoming standard at mature enterprises.

What about open-source AI security tooling?

Open-source projects in the AI security space cover specific functions: prompt classification, guardrail templates, log instrumentation. The projects work as components inside a deployer's own enforcement architecture, with the deployer assembling and operating the layer. The trade-off is between the lower licensing cost and the higher operational responsibility. For deployers with capacity to operate the layer in-house, open-source components fit. For deployers wanting the compliance evidence and the vendor support, commercial products are the more common path.

AI Security Buying Guide: How to Evaluate Vendors Against the 2026 Compliance Stack

The AI security vendor landscape in 2026 splits across five product orientations: model-side guardrails inside provider inference, browser extensions covering the user surface, CASB integrations covering SaaS-app adoption, ML observability covering model behavior, and identity-aware proxies covering the request boundary. Each category solves a different problem and produces different evidence. The AI buyer's job is to find the architectural fit for the deployer's compliance footprint and operational reality, not the highest-scoring feature checklist.

I want to walk through the ten questions any AI security vendor should be able to answer before a purchase decision. The questions reflect the EU AI Act, the NIST AI RMF, ISO 42001, and the sector frameworks. The aim is an architectural fit decision.

Question 1: Which AI surface does the vendor's product cover?

The deployer's AI footprint spans the browser surface (ChatGPT, Claude, Copilot Chat, Gemini), the API surface (internal applications calling LLM provider APIs), the agent surface (workflows that call models and downstream services), and the SaaS embedding surface (vendor-hosted AI inside enterprise SaaS tools). Each vendor's product covers some subset of these.

The buyer's question is whether the surfaces the product covers align with the deployer's actual usage. A browser extension covers the browser surface and misses the API and agent surfaces. A CASB covers SaaS adoption and misses the prompt-layer content. An identity-aware proxy can cover the surfaces the deployer routes through it. The coverage gap is the deployer's blind spot.

Question 2: Does the product produce records under the deployer's control?

The compliance frameworks taking effect in 2026 require the deployer to produce per-decision records on demand. The EU AI Act Article 12 obligation, the Article 19 retention floor, the NIST AI RMF Measure function, and the ISO 42001 audit all assume the records are under the deployer's control rather than the vendor's.

The buying question is whether the product produces records the deployer can retain, query, and export, or whether the records live on the vendor's infrastructure with the vendor's retention and access model. Vendor-controlled records create a dependency that surfaces during a regulatory review or an internal audit.

Question 3: How does the product propagate the verified user identity?

The Article 12 record-keeping requires identification of the natural person involved. The NIST AI agent identity framework requires identity propagation from the user through the AI system to the downstream actions. The product's architecture has to consume the verified identity from the deployer's identity provider, attach it to the request, and record it in the audit record.

Products that operate on application-level service credentials produce records that identify the application rather than the natural person. The audit record's identity field is one of the most-tested fields during regulatory review, and the gap shows up quickly.

Question 4: Is the enforcement inline or post-hoc?

Inline enforcement produces a decision at the moment of the request. Post-hoc detection produces a record of what happened after the model has already responded. The two patterns produce different evidence and address different parts of the compliance frame.

The buying question is which pattern the product implements, what the latency budget is for the inline pattern, and how the post-hoc detection feeds back into the policy. The Mandiant 22-second handoff time and the per-decision evidence obligation both push toward inline as the primary layer.

Question 5: What does the policy language actually express?

Policy languages vary in expressiveness. Some products express policy in terms of allowlist and blocklist patterns on prompt content. Some express policy in terms of regex rules on the prompt. Some express policy in terms of identity, role, data classification, model destination, and oversight routing, with composable rules and inheritance.

The buying question is whether the policy language can express the deployer's actual authorization model. A simple language is faster to set up; a richer language supports the compliance frameworks' dimension requirements. The decision depends on the deployer's regulatory scope and the policy maturity.

Question 6: How does the product handle data classification?

The data classification of the prompt drives much of the policy decision. The product's classification has to align with the deployer's existing data classification model: public, internal, confidential, restricted, with the AI-specific categories (PII, PHI, MNPI, customer data) layered on top.

The buying question is which classifier the product uses, whether the classifier supports the categories the deployer's regulatory scope requires, and whether the deployer can extend the classifier with custom patterns. Off-the-shelf classifiers cover the common categories; deployer-specific data classes typically require extension.

Question 7: How does the product fit into the deployer's identity stack?

The product has to integrate with the deployer's identity provider: Active Directory, Okta, Azure AD, Ping, or the equivalent. The integration covers user authentication, group membership for role-based policy, and the token format the application uses to attach identity to the request.

The buying question is whether the integration is native to the identity provider or whether it depends on a custom integration the deployer has to build. Native integrations reduce the operational cost and the failure surface. Custom integrations work but add maintenance and create dependencies that show up during identity provider migrations or upgrades.

Question 8: What is the operational deployment topology?

The product can deploy as a SaaS service the deployer routes traffic to, as a self-hosted service inside the deployer's infrastructure, or as a hybrid with the control plane SaaS and the data plane on-premise. Each topology has trade-offs around data residency, latency, and operational responsibility.

The buying question is which topology fits the deployer's data residency requirements (GDPR, sector regulations), the deployer's latency budget for the AI traffic, and the deployer's operational capacity to run an additional service. Sector frameworks like DORA add operational resilience requirements that affect the topology choice.

Question 9: What evidence does the product produce for regulatory reviews?

The compliance frameworks expect specific record content, retention, and access. The product has to produce records that satisfy the framework's requirements without the deployer having to reconstruct them.

The buying question is whether the product's records map to the specific frameworks the deployer faces. For an EU deployer, the records have to satisfy Article 12 and Article 19. For a US healthcare deployer, the records have to support HIPAA audit. For a mortgage lender, the records have to satisfy Fannie Mae LL-2026-04. The product's record format has to be either directly aligned or trivially mappable.

Question 10: How does the vendor support the deployer through the compliance review process?

The deployer is the one accountable to the regulator. The vendor's role is to support the deployer's ability to demonstrate compliance. The support takes the form of documentation (System and Organization Controls reports, ISO 27001 certificates, technical documentation supporting the deployer's own conformity assessment), audit cooperation (providing records during regulatory review), and product-level evidence (technical attestations the deployer can submit as part of the regulatory file).

The buying question is what evidence the vendor produces by default and what additional evidence the vendor can produce on request. Vendors that operate as critical infrastructure for the deployer's compliance posture should have explicit commitments around the support model.

How to weight the questions for the buying decision

The ten questions do not all carry the same weight for every buyer. The weighting depends on the deployer's regulatory scope, the deployer's existing security stack, and the AI usage pattern.

For deployers facing the EU AI Act August 2, 2026 deadline, the highest-weighted questions are around per-decision records, identity propagation, and inline enforcement, since these are the questions the regulatory review will actually test. For deployers facing sector-specific frameworks (HIPAA with AI, DORA, Fannie Mae LL-2026-04), the sector's record format and the vendor's audit support carry weight. For deployers with mature CASB and identity stacks, the integration questions move up the weighting because the operational cost of integration is real.

The buying decision is a fit decision against the deployer's specific compliance footprint and operational reality, not a feature-checklist comparison across vendors.

DeepInspect

This is the architecture the ten questions map onto. DeepInspect sits at the AI request boundary as a stateless proxy between the application and the LLM provider, covering the API surface, the agent surface, and the SaaS embedding surface for traffic the deployer can route through the proxy.

The records are produced under the deployer's control, with the per-decision content satisfying the EU AI Act Article 12 and Article 19 obligations, the NIST AI RMF Measure function, the ISO 42001 management system audit, and the sector frameworks (HIPAA, DORA, Fannie Mae LL-2026-04). The identity propagation reads the verified user identity from the deployer's identity provider, with native integrations for the major providers and a documented integration pattern for custom ones.

The enforcement is inline, with the policy evaluation overhead measured in single-digit milliseconds in production tests. The policy language expresses identity, role, data classification, model destination, and oversight routing, with composable rules and inheritance. The data classification covers the standard categories (PII, PHI, MNPI, customer data) with deployer-specific extension supported.

If your AI security buying decision is converging on the architectural fit question and you are evaluating against the August 2, 2026 EU AI Act deadline, book a free audit conversation with our compliance team.