How Large Regulated Enterprises Actually Buy AI
The enterprise AI purchasing journey seen from the security gate: the five stages, the three evaluation layers, and the residency traps hiding in vendor documentation.
Most published accounts of enterprise AI procurement are written by people selling into it. This one is written from the other side of the table: how the security gate actually behaves inside large, heavily regulated organisations, where a security sign-off is a precondition for a purchase order.
No organisation, vendor commercial term, or evaluation in flight is identified here. Where a product is named, the claim is one its own public documentation makes, and the citation is inline. Where this article describes how a decision gets made, it describes the general pattern rather than any particular case. Every external factual claim carries an inline reference to a primary source.
The gap between how vendors think this process works and how it actually works is wide, and expensive on both sides. A second gap has opened underneath it: between the middle of 2025 and August 2026, the EU changed its own high-risk deadlines by binding regulation, the first sweeping US state AI statute was repealed before it took effect, the protocol everyone standardised agents on rewrote its authorization model, and the first publicly reported AI-orchestrated intrusion campaign and the first agent-driven breach of a major AI platform both became matters of public record. A gate designed in 2024 is now checking for the wrong things.
This first half covers how the buying decision is actually made. A second half, following shortly, covers what the gate should be checking for, which is where the 2026 changes bite.
Part 1. The journey#
The five stages, and where the time actually goes#
Stage 1: Use case intake and governance approval. A business line has a problem it wants to solve with AI. Before anyone talks to a vendor, the use case goes to an AI governance function, usually alongside model risk. The questions are: is this a permitted use, what risk tier does it fall into, who owns it, and who pays for it. A surprising number of ideas die here, and they die for policy reasons rather than technical ones. This is also where the risk tier gets set, and that tier determines everything downstream: the depth of security assessment, whether model risk review is required, and whether a human must remain in the decision loop.
Stage 2: Sourcing, buy, build, or extend. The first question is never “which vendor.” It is “can we do this on something we have already approved.” An organisation that has stood up an internal model gateway and one or two approved model-hosting platforms will route everything it can through them, because the marginal cost of a new use case on an approved platform is a fraction of the cost of a new vendor. Going to market is the exception. When it happens, the shortlist is usually two or three names.
This is the single most under-appreciated fact in AI sales. The competitor is rarely another vendor. It is the platform the buyer already has, plus a sprint of internal engineering.
Stage 3: Risk screening. Several tracks run in parallel: cyber security, data privacy and legal, model risk and responsible AI, and third-party risk. This is where the majority of elapsed time goes and where most vendors are actually decided. The rest of this article is mostly about this stage.
Stage 4: Commercial and procurement. Negotiation starts only once the risk tracks are clear or clearly conditional. What procurement inherits from the security track is not a yes or a no. It is a list of conditions with costs attached: the total cost of risk mitigation, which is frequently a larger number than the licence and which is the number that actually decides marginal deals.
Stage 5: Onboarding and continuous assurance. Purchase is not the end state. Re-assessment on a defined cadence, monitoring for new vulnerability classes, evaluation re-runs when the underlying model version changes, and a defined trigger set for reopening the decision.
(Elapsed time varies too widely between organisations to be worth a number, and it is not publicly measured. The ordering is the reliable part: a narrow-blast-radius SaaS tool clears faster than a platform-level commitment, anything touching sensitive data or taking autonomous action runs longer, and anything agentic sits at the long end, for the reasons the second half of this article covers.)
Part 2. It is not a scorecard#
Vendors assume evaluation is a weighted scorecard, so they optimise for the average. In practice it has three distinct layers, and they behave differently. Understanding which layer a question belongs to is the difference between a fast pass and a six-month stall.
The three-layer structure below is a way of describing how these assessments behave in practice. It is not a published framework and not a standard.
Layer one: binary kill gates#
A small number of criteria are pass/fail. If one fails, nothing else is scored and the evaluation stops.
- Training and retention. Will our data be used to train your models? What is retained, where, for how long, by whom, and under what legal compulsion? Note that this is not one question but four, and vendors routinely answer only the first.
- Data residency and sovereignty. Where does the data physically sit, including during abuse monitoring, incident review, and any cross-region failover, and can a regulator follow it?
- Isolation. Can traffic be kept off the public internet, and can we prove it?
- Contractual accountability. Data processing agreement, breach notification commitments, right to audit.
These are binary because they are not compensable. There is no control a buyer can build on its own side that makes an unacceptable retention posture acceptable. If your data has already left under terms you cannot live with, no gateway rescues you.
Layer two: weighted, scored controls#
Once the kill gates clear, the scored section is mostly about operational security. The question is not “are you secure” but “can we run you securely, at scale, and reconstruct what happened afterwards.”
- Key handling and revocation. Can we hold the key, and revoke it ourselves in an incident without opening a support ticket?
- Identity granularity. How finely can permissions be scoped, to the service, the workload, or the specific model version?
- Telemetry. Can prompt and response telemetry reach our own logging estate, under our own retention rules, at investigation-grade fidelity?
- Control tunability. Are content filtering and sensitive-data controls extensible to our data patterns, or fixed?
- Incident response. Notification commitments, test evidence, and what the vendor will actually do at 2am.
A low score here does not usually mean rejection. It means conditions, an owner, and a date.
Layer three: conditional acceptance#
The most commercially significant layer, and the one vendors under-use in their positioning. If a gap can be compensated by a control the buyer already operates, the answer becomes yes-with-mitigation rather than no. No native data-loss prevention for our identifier formats? Our gateway does it. Weak jailbreak filtering? We enforce our own on egress. No per-team quota? The gateway meters it.
This is why a vendor with an honest gap list often clears faster than one insisting it has none. A buyer can only compensate for gaps it can see. A vendor who oversells completeness does not remove the work; it defers the discovery, and by then the buyer has also lost confidence in everything else it was told.
Compressed into one line for a vendor: state what you retain, show how you can be isolated, and be specific about what you do not do.
Part 3. Approval is a pattern, not a product#
In an organisation of this profile, approval is rarely granted to a product. It is granted to a deployment pattern. The same model, from the same provider, can be allowed under one pattern and refused under another. That distinction is where most vendor confusion originates.
A typical allowed pattern: the application authenticates against enterprise identity rather than carrying static API keys; it calls an internal model gateway rather than a provider endpoint directly; the gateway holds provider credentials, applies data-loss prevention and masking on egress, enforces per-team quota, and writes full request and response telemetry to internal logging; egress leaves through a private network path; and identity permissions name specific model identifiers rather than a wildcard.
That last point matters more than it looks. Approving “the provider” means approving every model in their catalogue, including ones released next month that nobody has evaluated. Approving a versioned model identifier means the catalogue cannot expand into production without passing back through the gate.
The residency and tenancy traps that are hiding in plain sight#
Several of the most consequential properties of a deployment are configuration flags, not product properties, and the defaults frequently do not do what a buyer assumes. All four of the following are verifiable in vendor documentation.
“Provisioned” and “region-pinned” are orthogonal axes. Azure’s deployment-type documentation distinguishes global from regional provisioned deployments, and separately documents a developer tier that can run in any Azure region with no SLA and no data-residency guarantee (Microsoft Learn, deployment types). Buying reserved capacity and buying data residency are two different purchases, and it is possible to buy the first while believing you bought the second.
Cross-region inference means what it says. Amazon’s documentation states that “[y]our data remains in the AWS Regions where it originally resides” and that “[b]y default, the data remains stored only in the source Region”, and then, in the same passage, that “your input prompts and output results might move outside of your source Region during cross-Region inference,” and that “[t]o the extent we store data for abuse detection, your input prompts and output results will be stored in the destination region” (AWS, geographic cross-region inference). Both statements are true simultaneously. Which one governs your risk assessment depends on whether your control objective is storage or processing, and most control objectives are written without making that distinction.
Provisioned throughput is usually a quota construct, not an isolation construct. Bedrock documents provisioned throughput as capacity purchased in model units with commitment terms, with no tenancy, isolation or dedicated-hardware guarantee stated (AWS, provisioned throughput). Google documents Vertex AI provisioned throughput as dedicated quota, sized in generative AI scale units and enforced by quota checking, again without a dedicated-hardware claim (Google Cloud, use provisioned throughput). If your architecture diagram has a box labelled “dedicated inference” because you bought provisioned capacity, check the documentation again.
Zero data retention often has endpoint carve-outs, and they tend to be the endpoints you most want. OpenAI’s data-controls documentation lists ZDR-eligible endpoints and the ineligible ones, conversations, assistants, threads and vector stores, which retain data until deleted. The same page documents that API data is not used for training by default, a default abuse-monitoring retention window of 30 days, regional storage across a set of jurisdictions including the EEA and the UK, a separate modified-abuse-monitoring option, and Private Link and IP allowlist options (OpenAI, data controls). The stateful, retrieval-adjacent surfaces are precisely the ones a serious application uses, so “we have ZDR” is incomplete until you know which endpoints the application calls.
None of this is vendors behaving badly. It is all published. The resolution of the documentation is simply finer than the resolution of most security questionnaires, and the gap between them is where bad assumptions live.
The primitives, and who supplies them#
The publicly documented isolation primitives, stated neutrally with sources:
| Primitive | Documented at |
|---|---|
| Private network path | Bedrock VPC endpoints via AWS PrivateLink; OpenAI Private Link and IP allowlist |
| Customer-managed keys | Azure OpenAI CMK via Key Vault, covering uploaded training data and fine-tuned models |
| Tunable guardrails | Bedrock Guardrails, including automated reasoning checks; Azure Prompt Shields |
| Configurable log retention | Azure Monitor data retention and archive tiers |
| Provider isolation from customer data | AWS states model providers “don’t have access to Amazon Bedrock logs or to customer prompts and completions” |
The point is the shape of the question: which of these primitives exist natively, which must the buyer build, and what does building them cost?
Part 4. “Once the gates are cleared, vendors are basically equivalent”#
For classic SaaS this is broadly true. For generative AI it is false, because the attestations were designed for a different threat model.
What a SOC 2 report actually covers#
The applicable criteria remain the 2017 Trust Services Criteria with revised points of focus (2022). A SOC 2 examination tests whether the service organisation’s own stated controls operated effectively against the security, availability, processing integrity, confidentiality and privacy criteria. The AICPA’s SOC suite of services lists no AI-specific offering and no AI-specific criteria.
It follows that nothing in the criteria compels coverage of training-data provenance, model evaluation, red-teaming, prompt-injection resistance, model versioning and rollback, or fine-tuning data segregation, unless the service organisation volunteered those as its own controls and the auditor tested them. So: read Section III and the complementary user entity controls. Do not accept the cover page.
What ISO/IEC 42001 actually certifies#
ISO/IEC 42001:2023 is an AI management system standard, governance process requirements, not AI-specific technical controls. Google Cloud’s own compliance page makes the point explicitly, noting the standard does not mandate specific AI controls. Treat a certificate as evidence that a vendor has an AI governance function, not that a given model is safe.
Adoption at platform level is now broad, and each certification names a scope: AWS announced accredited certification in November 2024 covering Bedrock, Q Business, Textract and Transcribe; Anthropic certified in January 2025; Microsoft publishes its certification scope on the Service Trust Portal; Google Cloud lists the in-scope Gemini and AI services; and OpenAI lists 42001 alongside 27001, 27701, SOC 2 Type 2 and CSA STAR Level 1.
Two consequences worth putting in a questionnaire. First, scope inheritance does not work the way vendors imply, “we are on a certified platform” says nothing about the model provider’s own management system, and an open-weight model served through a certified platform inherits platform certification only. Read the scope statement and check whether the specific service is named. Second, ask who accredited the certification body: ISO/IEC 42006:2025 sets requirements for bodies auditing and certifying AI management systems, and whether a certificate was issued under it is a fair and increasingly answerable question.
The AI-specific assurance market, as it stands#
| Artefact | Independently tested? | Certifiable? | Covers AI-specific technical risk? |
|---|---|---|---|
| SOC 2 Type 2 | Yes | No (attestation) | Only if the vendor volunteered the controls |
| ISO/IEC 27001 | Yes | Yes | No |
| ISO/IEC 42001 | Yes | Yes | Management system only, not model behaviour |
| ISO/IEC 23894 | No | No | Guidance only |
| ISO/IEC 27090 | n/a | n/a | Not yet published |
| HITRUST AI Risk Management | Optional | No | Governance; mapped to ISO 23894 and NIST AI RMF |
| HITRUST AI Security | Yes | Yes | Yes; mapped to NIST, ISO and OWASP |
| CSA STAR for AI Level 1 | Self-assessed | No | Yes, via AI-CAIQ |
| CSA STAR for AI Level 2 | Yes (requires 42001) | Yes | Partly |
| AIUC-1 | Yes, plus recurring red-teaming | Yes | Yes, agent-specific |
Three observations a buyer can act on.
The CSA AI Controls Matrix segments its control set by role, model providers, orchestrated service providers, application providers, AI customers and cloud service providers. That segmentation is the most useful feature of the whole assurance landscape for a procurement gate, because it lets you ask a vendor only the controls that apply to their position in the value chain, and tells you which controls you own as the AI customer.
AIUC-1, added to the STAR registry in June 2026, is the only scheme I have found that imposes recurring adversarial testing rather than a point-in-time audit. For agentic systems, where the attack surface changes with every tool you connect, point-in-time is close to meaningless.
And every independently tested AI-specific artefact in that table is younger than two years. The assurance market has not caught up with the deployment, and a competent security gate has to close that gap itself, and should say so to its own leadership rather than implying the certificates cover it.
So where does the divergence actually live?#
- Granularity of isolation. Can a buyer permit one model and deny the rest, or is the unit of approval the whole service?
- Key ownership. In an incident, can the buyer revoke access itself, immediately?
- Tunability of controls. Generic sensitive-data detection catches well-known identifier formats. It does not catch organisation-specific customer identifiers, internal reference codes, or a name and a partial address appearing across two conversational turns.
- Forensic depth. Not “do you produce logs” but: do they land in the buyer’s account, under the buyer’s retention policy, at investigation-grade fidelity?
Gates establish whether a vendor can be secure. The scored layer establishes whether we can operate them securely. Those are different questions.
Part 5. The regulatory picture actually shifted, and mostly in one direction#
If your architecture review deck still cites a 2024 compliance calendar, it is wrong in specific and consequential ways.
The EU deferral is binding law, not a proposal. Regulation (EU) 2026/1744 of 8 July 2026, “amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI)”, entered into force on 27 July 2026. Under it, stand-alone Annex III high-risk obligations move from 2 August 2026 to 2 December 2027, Annex I embedded high-risk obligations from 2 August 2027 to 2 August 2028, and national regulatory sandboxes to 2 August 2027 (Council of the EU, final adoption 29 June 2026). The instrument also narrows the “safety component” definition, excluding systems providing only user assistance, optimisation or convenience, which shrinks Annex I scope and is worth re-running your inventory against (Orrick analysis of the eight changes).
But the 2 August 2026 milestone still bit. Article 50 transparency obligations commenced. AI-interaction disclosure, machine-readable marking of synthetic content, notice for emotion recognition and biometric categorisation, deepfake disclosure by deployers, and disclosure of AI-generated text published on matters of public interest (European Commission on the AI Act regulatory framework). The Commission’s supervisory and fining powers over general-purpose AI models also commenced on that date, though the underlying GPAI obligations have applied since August 2025 (enforcement of Chapter V).
A concrete, checkable vendor question came out of this. The Commission finalised a Transparency Code of Practice for AI-generated content in July 2026, setting expectations including multi-layered machine-readable marking, detection tooling made available to regulators and researchers, and watermark-detection interoperability by 2 February 2027 (Paul, Weiss client memo). You can ask a generative AI vendor whether they are a signatory and which marking techniques they implement, and the answer is verifiable. (The signatory count reported in press coverage, around 190 by end-July 2026. I could not confirm against a Commission register; treat it as indicative.)
Nobody can claim conformity to a harmonised standard, because none has been cited. Presumption of conformity requires a standard to be both published and cited in the Official Journal, and no CEN-CENELEC JTC 21 deliverable for the AI Act has reached that point (AI Act standards tracker; CEN-CENELEC on accelerating AI standardisation). A vendor claiming to be “AI Act compliant” against a harmonised standard is claiming something that does not exist.
The same retreat happened in the United States, harder. Colorado’s SB 24-205, the first broad US high-risk AI statute, was repealed and replaced before it took effect. SB 26-189, the Automated Decision-Making Technology Act, signed in May 2026 and effective 1 January 2027, eliminates the duty of care to mitigate algorithmic discrimination risk and the annual impact-assessment mandate, replacing them with disclosure obligations: developer documentation on intended use and known risks, deployer notice to consumers, adverse-outcome disclosure, and record retention (Crowell & Moring analysis; Finnegan overview).
Read those together and the pattern is unmistakable. Both major high-risk AI regimes retreated within the same window, and what survived in both was transparency and documentation. A security gate built around impact assessments is now ahead of the law. A gate built around provenance, marking, documentation and disclosure is exactly on it.
The rest of the picture, briefly, because a multinational buyer plans to the strictest applicable regime. California’s SB 53 and AB 2013 from January 2026 and SB 942 from August 2026; Texas TRAIGA from January 2026, notable because conformance with the NIST AI RMF operates as an affirmative defence; Illinois HB 3773 from January 2026 with a private right of action (Cooley, state AI laws; Baker Botts on the US AI law update); South Korea’s AI Framework Act in effect from 22 January 2026 with extraterritorial reach, output labelling and a domestic-representative requirement (Library of Congress); and federal preemption pressure via executive order, which cannot displace state law without congressional action (White & Case).
Next in this series: what your AI security gate should actually check, covering the threat model the assurance market does not reach, the model supply chain, retrieval, agents, and the five incidents that should change your questions.
I write about AI/ML security and threat modeling, the grounded version, read from the research rather than the marketing. If that’s your thing, subscribe to the newsletter.