What 'enterprise-ready' actually means in CX-AI.

Every CX-AI vendor claims to be enterprise-ready. The phrase has done so much work in the past 18 months that it has stopped meaning anything. We propose a definition. Enterprise-ready is the set of commitments a vendor has made and can demonstrate on procurement security review, regional deployment, regulatory liability, identity, audit, approvals, and exit. A vendor either has those commitments on paper, in the architecture, and in a working customer reference, or they do not, and the procurement team can detect the gap with a ten-question checklist.

Open any CX-AI vendor homepage and search for the word "enterprise." You will find it next to a SOC 2 badge, a Fortune 500 logo wall, and a vague paragraph about security and reliability. Read the same homepages again, this time looking for the specific commitments a regulated buyer has to confirm before signing: a deployment-region matrix, a signed BAA template, the identity-provider integration list, the audit-row schema written into the buyer's system of record, the exit clause in the MSA. The second pass turns up almost nothing. Procurement asks the question and gets the marketing answer; the contract reaches security review at week 10 and stalls. We have seen this cycle three times in our own pipeline.

The bait-and-switch on the word "enterprise"

The bait-and-switch runs the same way every time. The vendor publishes a SOC 2 Type II report and a logo wall of two or three Fortune 500 customers, and the website conflates two distinct claims: "we sell to enterprises," which is a sales-stage assertion about the contract list, and "we are enterprise-ready," which is an architecture-and-commitments assertion about the product. The marketing surface treats them as interchangeable, and a serious procurement team does not.

A useful test is to ask the vendor what enterprise-ready means in their own words. The bait-and-switch vendor lists the customer logos and pivots to the demo. The architecturally honest vendor walks through their security documentation, deployment options by region and cloud, regulated-vertical agreements they have signed, identity-provider integrations, audit-row schema written back to the buyer's CRM, approval-flow primitives, and the MSA exit clause. If the vendor cannot name those seven categories without consulting a slide, they have not built the thing the homepage advertises.

"We sell to enterprises" is a sales-stage assertion. "We are enterprise-ready" is an architecture-and-commitments assertion. The marketing surface treats them as interchangeable. A serious procurement team does not.

Procurement-ready: documentation that survives 90-day security review

A serious enterprise security review takes 90 days and runs on artifacts the vendor has to hand over under NDA. The minimum viable set is a SOC 2 Type II report current within 12 months and unqualified in the auditor's opinion, an ISO 27001 certificate mapped to the buyer's control framework, an ISO 42001 certificate or a current pathway to one (AI-specific governance is now table stakes), a penetration-test summary from a credentialed third party dated within the last year, and an EU AI Act conformity assessment for any vendor selling into the EU.

Sierra is the strongest in this dimension. The Trust Center lists ISO 42001 and EU AI Act conformity alongside the standard SOC 2, ISO 27001, GDPR, and HIPAA set, with the AI-specific items surfaced prominently. Decagon has a Trust Center and the standard set, with less emphasis on AI-specific certifications. Ada ships a Trust Center scoped to consumer-CX use cases. The ranking reflects which buyer cohort each vendor is built to serve.

Region-ready: your cloud, your region, your data residency

A vendor that runs only in their own cloud, in their own region, on their own multi-tenant infrastructure, is not enterprise-ready for buyers whose data cannot leave a specific jurisdiction. Region-ready is a four-axis matrix: cloud (AWS, Azure, GCP, on-prem), region (US, EU, UK, Middle East, APAC, GovCloud), tenancy (multi-tenant, single-tenant, dedicated-instance, customer-managed), and key sovereignty (vendor-controlled, customer-managed via KMS, hardware-isolated via HSM). Most vendors ship one cell: US, AWS, multi-tenant, vendor-controlled keys. That is fine for most consumer-CX deployments and inadequate for any buyer with a data-residency obligation. Sierra documents single-tenant options for the largest deployments; Decagon and Ada are multi-tenant US-first. None of the three publish a deployment matrix.

BAA-ready: signed agreements for regulated verticals

Regulated verticals are gated on signed agreements that are not optional. A vendor either has the legal infrastructure to accept HIPAA liability or they do not. Same for the EU GDPR DPA, the UK DPA addendum, the UAE PDPL addendum, the California CPRA addendum, and the financial-services exhibit that names the OCC and FFIEC guidance the vendor agrees to be measured against. Each means the vendor has accepted specific liability terms in front of a specific regulator, and the buyers who need those terms cannot legally deploy a vendor who has not signed them.

The clean test is to ask the vendor for the BAA template, the DPA template, and the cross-border-transfer exhibit upfront, in week one. A vendor who can hand all three over within 48 hours has done the work. A vendor who has to escalate to legal for each one has not, and the escalation pattern is the answer.

Identity-ready: your IdP, your SSO, your SCIM

A vendor whose only login surface is email and password is not enterprise-ready in any defensible sense. Identity in 2026 means SSO via SAML or OIDC against the buyer's identity provider (Okta, Azure AD, Google Workspace, Ping), SCIM for automated provisioning and deprovisioning so the security team can revoke access when an employee leaves without filing a vendor ticket, and a custom RBAC model that maps to the buyer's group structure so that "claims adjusters in the Phoenix office" inherits permissions from the IdP group of the same name. The diagnostic is to provision a user from the IdP live, see the RBAC role attached automatically, then deprovision and confirm the vendor seat is gone within 60 seconds.

Audit-ready: rows in your CRM, not the vendor's dashboard

Every AI action the system takes ought to write a row into the buyer's system of record, with the operator's identity in the actor field, the reasoning trace in the explanation field, and the tool call in the action field. The row lives in the CRM the team already uses, queryable by the buyer's auditor without a vendor support ticket. This is the operator-led and CRM-native architecture (it has its own essay on this blog). The enterprise-ready point is that vendor-dashboard logging is not audit-ready in the way an auditor cares about. When the auditor pulls a record, they pull it from the system of record; if the AI action is not there, the formal answer is that it did not happen. Ask the vendor to demonstrate the audit row in your Salesforce, your Epic, your HubSpot, or whatever the team actually uses. The vendor either pulls up a sample row and points at the cells, or they pivot to their own platform UI. The pivot tells you where the audit story actually lives.

Vendor-dashboard logging is a parallel evidence layer the auditor cannot subpoena from your system. If the AI action is not in your CRM, the formal answer is that it did not happen.

Approval-ready: human sign-off on the actions that matter

Some actions cannot run autonomously: a claims adjuster approving a payment over a threshold, a clinical decision that affects a treatment plan, a refund above the operator's default authority, a contractual commitment that creates a billable SLA. The regulated buyer needs the AI to propose, queue, and surface the action to a human for approval before the action fires. The product primitives are a proposal queue where the AI can only suggest, a confirmation surface where the operator can approve or modify or reject, a threshold model where the system knows which actions are auto-approvable, and an override path where the operator can fire an action the AI did not propose. A vendor whose product cannot demonstrate these four primitives in a live demo is not approval-ready, regardless of what their architecture diagram suggests.

Exit-ready: leave in 30 days with your data

Vendor lock-in is a deal-killer once the buyer's procurement team reads the contract. Enterprise-ready means the buyer can leave the vendor in 30 days and take their data with them. The customer records never moved to the vendor's cloud, because the data lived in the buyer's CRM the whole time. Transcripts and audit history are exportable in a documented format, or replicated continuously into the buyer's data lake. The replacement vendor can be plugged in without rebuilding the data layer, because the data layer was never the vendor's to begin with. A vendor who has thought about this hands over an exit clause that names the 30-day window, the export format, the deletion attestation, and the contractual remedy if any of the three are missed.

The ten-question procurement checklist

A buyer can hand the following list to a vendor in week one of a sales cycle. The vendor either answers each item with an artifact (a document, a customer reference, a live demo) or they answer with a roadmap promise. The ratio of artifacts to promises is the enterprise-ready score.

One. Provide your SOC 2 Type II report, ISO 27001 certificate, ISO 42001 certificate or pathway, and the most recent third-party pentest summary, all under NDA, within 48 hours. Two. Name the cloud, region, and tenancy combinations you have deployed into production, with a customer reference for each cell. Three. Hand over your BAA, DPA, and any regulated-vertical addendum the buyer needs (HIPAA, GDPR, UK DPA, UAE PDPL, financial-services exhibit) as templates, in week one. Four. List the identity providers you integrate with via SAML or OIDC, confirm SCIM support, and demonstrate a live IdP-driven provisioning and deprovisioning round-trip. Five. Demonstrate the audit row written into the buyer's actual system of record, not the vendor dashboard, with the operator's name in the actor field.

Six. Show the proposal queue, the confirmation surface, the threshold configuration, and the operator override path, in a live demo, in under ten minutes. Seven. Walk through the exit clause in the MSA: 30-day data export, deletion attestation, contractual remedy, and the file format the data lands in. Eight. Name the AI-specific governance framework the product is certified against or building toward (EU AI Act, ISO 42001, NIST AI RMF), with the conformity-assessment scope written out. Nine. Confirm whether the product runs in single-tenant mode for buyers who require it, with a customer reference for a single-tenant deployment in the region the buyer cares about. Ten. Name the operator of record. The audit row carries a human name in the actor field, because the AI is not a legal person and a regulator looking at the row will need to find the human.

The ten items cover documentation, deployment, contracts, identity, audit, approvals, exit, AI governance, tenancy, and operator-of-record. Each is verifiable with a concrete artifact. Vendors who answer eight or more cleanly are enterprise-ready in a meaningful sense. The category will converge on something close to this list, because regulated buyers will keep refusing to sign with vendors who cannot answer the ten questions. We would rather be the kind of vendor that treats the badge as the entry fee and the ten answers as the actual product, and we are writing the post so the buyers can tell the difference at week one instead of week ten.