Why AI-native CX is widening the gap between mid-market and enterprise
For the last two years, the public conversation about AI in customer support has been about vendor capability. Could the model actually do the work? Could it issue the refund, not just draft the reply? Could it read the order, check the policy, update the CRM, and notify the customer in one coherent action? For AI-native operators, that question is now mostly answered. The technology works. I've written about how we built ours at Onepilot in more detail here.
What I want to write about instead is something I've been noticing on the buyer side, because I haven't seen much honest discussion of it. I also have a particular stake in this. I started Onepilot as its technical co-founder and spent the first couple of years writing the platform, which means I've been on the inside of most of the architectural choices that show up in a security review today. The questions buyers ask aren't abstract to me; they map to lines of code I remember writing and decisions I remember the team making. That's part of why this piece exists.
In the last twelve months, I've watched close to ten enterprise sales processes where the binding constraint on time-to-value wasn't capability, integration, or even budget. It was security and procurement review. Timelines in months, not weeks. Across UK, European, and North American buyers, and across sectors. During the same period, our mid-market customers have been going live in around two weeks, sometimes faster on a native stack.
I don't think this is a complaint about procurement. I think it's a structural mismatch that hasn't been named, and naming it might be useful.
What I'm actually seeing
Mid-market brands tend to absorb AI-native support fast. The buying committee is small, the integration footprint is modest, the security review is rigorous but proportionate to the size of the deployment. Two weeks from contract to value is now routine for us. The economics start working in month one.
Enterprise brands tend to take much longer. The same vendor, with the same architecture, can sit in a security and procurement queue for six to nine months before the first ticket is ever handled. The buying committee includes infosec, legal, data protection, sometimes a model risk function, sometimes an AI governance board that didn't exist a year ago. Every layer is doing its job. Each layer was designed for a different era of vendor.
The result is that two organisations buying the same product, at the same time, in the same market, experience very different timelines to value. I find that worth examining.
Why I think this is structural
The standard procurement and security review process was built for SaaS. Static product, assessed once at signing, with risk that stays roughly stable for the contract duration. The templates ask sensible questions: SOC 2, ISO 27001, data residency, sub-processors, encryption at rest, incident response. Vendors who have those answers ready clear the bar. That model worked well for a decade.
AI-native systems don't sit still in the same way. The system in week 12 is not the system in week 1. The playbooks evolve as the operator learns the business. The set of tools the model can invoke expands as integrations mature. The autonomy thresholds shift, conversation by conversation, as confidence grows. A buyer evaluating an AI-native vendor is being asked to assess a snapshot of something that behaves more like a flow.
The questions worth asking are also different, and I don't have a complete list. Some I'd put on it: which data ends up in prompts, and is any of it retained downstream? Is customer data used to train or fine-tune any model, even indirectly through provider defaults? Where does inference run, and what crosses a border to get there? Are credentials ever passed into the LLM context, or are they injected server-side at execution time? Is the model bound to a fixed catalog of tools per workflow, or is it freelancing against a global registry? How are sensitive actions like refunds or account changes gated, and where does that policy live (in the model, or in code)? Most security review templates I've seen don't have a natural place to put answers to questions like these. So vendors attach them as appendices, reviewers treat them as out-of-scope, and the conversation tends to default to the SaaS questions that don't quite fit the situation.
Our DPO and our engineering team have spent more hours than any of us would have predicted working through how to present this kind of material to security reviewers in a way that lands. Some of what's in this piece comes from those conversations.
A pattern from the ten deals
The shape tends to repeat. A CX leader at a large enterprise meets us, sees the product, runs a pilot in a sandboxed environment, gets convinced. They bring it to procurement. Procurement asks for the security questionnaire. We answer it, often with more material than the questionnaire asks for, because the questions don't quite cover what matters. Security review opens. New questions surface, not because something is wrong, but because the reviewer is encountering an architecture they haven't seen before and reasonably wants to understand it from scratch.
What's interesting is how the questionnaire evolves across rounds. The first pass tends to be SaaS-shaped, and you can feel the legal and security side ticking boxes more than probing anything specific. By round two, the reviewer has read the appendices and starts asking different questions, often sharper ones, about how tool authority is scoped or how the audit trail actually works. By round three, the conversation has shifted to specifics like which fields are surfaced to the model from an integration like Shopify or Zendesk, and how new fields are added (in our case, a code change with code review, not a configuration flip). That arc, from generic to specific, is the reviewer doing the work of building a mental model for a new class of vendor. It's healthy. It also takes time.
The number of people in the loop tends to grow with each round. Legal joins. Data protection joins. An AI governance review is initiated, sometimes by a function that was created in the last six months and is still defining its own remit. Our DPO has observed the same shift across questionnaires this year: not just sharper questions, but more interlocutors on every cycle.
I want to be clear that none of this is bad faith. Every reviewer I've dealt with has been doing the work properly. The cumulative effect is just that the total elapsed time runs to six to nine months. In the same period, three mid-market customers might go live and reach 50% automation.
The CX leader who started the process is often the most frustrated person in the room, partly because they can see the gap and have no individual lever to close it.
What some buyers are doing differently
A small number of the enterprise buyers I've worked with handle this better than the rest, and the things they share might be worth naming, even if I'm not certain they generalise.
They've built an AI-specific review path, parallel to the standard SaaS one, that asks questions calibrated for this kind of vendor. The questions are concrete: show us the audit log for a single conversation end to end. Show us how a sensitive action like a refund is gated. Show us what happens when a tool call returns a 5xx error. Show us how identity verification works when the email on the ticket doesn't match the email on the account. These are not gotchas; they're the right questions, and vendors with real answers can produce them in hours. Vendors with bolted-on AI wrappers tend to get filtered out earlier, which seems healthy.
They've also adjusted for the fact that what they're buying behaves more like a flow than a snapshot. Their contracts include change-notification clauses for material model or playbook updates. Their governance reviews are scheduled more frequently than annually. They've stopped trying to evaluate only the version they signed.
I don't have enough data points to say this is the right answer. These are just the patterns I've seen in buyers who seemed less stuck.
What I'm not sure about
I don't know how this resolves. There's a version of the next two years where industry standards catch up, procurement templates get rewritten, and the gap closes on its own. There's also a version where it widens, because mid-market companies keep absorbing operational savings that enterprise can't match on the same timeline. I genuinely don't know which is more likely, and I'd be cautious of anyone who claims to.
What I'd offer instead is a smaller observation. The cost of long enterprise review cycles for AI vendors doesn't show up cleanly on procurement's spreadsheet, because there's no line item for "agents doing data-movement work while we wait for security to finish." But the cost is real, and it's worth being honest about it on both sides of the table. Vendors who can't articulate their governance story shouldn't expect to move faster. Buyers whose templates were written for a different generation of vendor probably shouldn't expect those templates to keep working unchanged.
I'm interested in hearing from people on the buyer side who've thought about this. Not because I have the answer, but because I suspect the people closest to it haven't been writing about it publicly, and I'd rather learn from them than guess.
