In sensitive enterprise workflows, the binding constraint on deploying AI is rarely the model. It's permission to deploy AI transformations in a high-risk mission-critical environment. Most AI startups today are dabbling in expensive pilots in client sandboxes. The right to put a system inside a regulated, mission-critical process is earned over years and granted to almost no one. When evaluating an AI-native vertical strategy, the first question is "who is already trusted to be in the room?" That answer was usually set long before the technology exists.
Imagine two companies trying to win a global insurance carrier's AI-assisted liability assessment. One is a venture-backed startup with an incrementally superior model that requires tearing down existing systems and processes and adoption of new systems and process in return for AI efficiencies excluding token costs. The other is the services firm that has partnered on the carrier's subrogation recoveries for 15 years and offers an evolutionary path to increased productivity by adopting AI. The risk of a high-cost error outweigh the benefits in this case and many other high-risk enterprise business cases. The frontier models are making AI technology available to anyone willing to pay so on the technology, the differences are incremental. On who gets the business, the advantage goes to the aligned incumbent rather than the startup chasing its next round of funding.
The gap between the single-minded startup and the longtime partner that can reimagine a longstanding and complex business in an AI-native model is the first pillar of the Embedded Trust Advantage. In regulated, high-stakes workflows, the customer relationship is the gating asset. It determines who is even allowed to compete, before the solution is evaluated.
Retention metrics at embedded vertical incumbents (illustrative targets based on Lateral analysis).
Why the embedded services partner is aligned for AI native success
Consider that insurance subrogation partner. Over 15 years it has handled tens of thousands of claims across auto, property, and commercial lines including investigating liability, negotiating settlements, managing litigation when it came to that. The relationship has survived three claims-system migrations, two executive-team turnovers, and a merger. The data has been audited and inspected by internal reviews and regulatory authorities. When the carrier's leadership decides to pilot AI-assisted liability assessment, they may run pilots with startups to show thought leadership and be responsive to top-down AI mandates. Eventually, they call their longstanding partner and rely on them for the long-term implementation.
Fifteen years of consistent performance on sensitive financial recoveries gives the services incumbent a seat at the table. The work is handed to the partner the customer already trusts to be inside the most sensitive parts of the business. RFPs are often required protocols at large companies but RFP vendor ratings reward familiarity, tenure and reliability. In this AI bubble environment, we think that some of the partnerships announced between major frontier-model companies and well-funded startups have become the cost of marketing, often with limited practical use and no long-term business case.
What 'permission to deploy' actually requires
The reason trust gates the competition is structural, not sentimental. Deploying AI into a core enterprise workflow requires three things the customer has to actively grant: access to sensitive data, integration into the systems that run the business, and tolerance for the inevitable errors that occur while a model is being refined. None of those are given to a vendor the customer met last quarter.
This is where a startup runs into a wall. A startup adopting the latest model needs the customer's real data to prove it works. The customer will not hand regulated claims files, adjuster notes, and litigation history to an unknown party to find out. The data is often messy and difficult to corral into a neat package anyway which makes it virtually impossible to train without a canonical reference. The challenger faces a cold-start problem with no obvious solution: it can't demonstrate value without access, and it can't earn access without a track record it hasn't been allowed to build. The incumbent cleared that bar years ago, by doing the unglamorous work reliably, long before AI was on the agenda.
At Lateral, we look for high-quality embedded vertical services incumbents who post 90%-plus gross retention and partner strategically with Fortune 500 clients that operated in regulated industries or otherwise high-risk, high-reward enterprise business cases. Customers don't churn out of a relationship that is wired into their mission-critical operations and has earned the right to be there — and that same trust is what lets the incumbent expand into adjacent work, including AI, even if it has to re-compete each time.
Measuring the substance of the customer relationship - embedded vs. transactional
The fallacy is assuming that any services company with a long and impressive customer list has a moat. Many services companies are neither embedded nor trusted. Real relationships are measured in years of mission-critical delivery. They survive system migrations, reorganizations, and changes of sponsor. The vendor sits inside the workflow rather than adjacent to it. And the customer brings new problems to the vendor unprompted rather than putting them out to tender. Transactional relationships through a value added reseller (VAR) or business process outsourcer (BPO) may look superficially similar but operate differently. They're measured in purchase orders, not years. They sit next to the workflow — taking an order, shipping a product, invoicing — without ever being trusted with the decisions inside it. When something new comes up, it goes to procurement and out to bid. A long history of transactions is not embedded trust. It's a series of disconnected purchases that happen to share a logo.
The distinction matters fundamentally for a founder running one of these businesses, because the first pillar om our AI transformation framework is the one that unlocks the other two. Customers share the sensitive data that becomes the proprietary training signal — and bring the hard problems that build domain expertise — only with partners they trust. Without the relationship, there is no data access and no privileged seat from which to develop expertise. Permission to deploy comes first.
From permission to patient outcomes
Permission to deploy lowers the cost of the one thing AI deployments always require: tolerance for error during refinement. Managing the downside risks of AI errors is a major element of AI adoption. Models don't arrive finished and plug-and-play. Model results improve through correction on real data, and the early versions will be wrong in ways that matter and can be harmful to customers, subject to headline risk and financial losses. A customer extends that patience only to a partner it trusts and errs on the side of avoiding errors rather than pushing the marginal technology improvement. The services incumbent iterates toward a working system on live workflows while a challenger, in Mark Zuckerberg's famous saying, moves fast and breaks things. Permission isn't just access but also the partnership to navigate the imperfections of AI and to work through the bumps to get to the best solution.
Permission to deploy isn't a one-time advantage. The same trust that lets an incumbent run the first AI implementation leads the second and the third competing — the land-and-expand dynamic that shows up with the opportunity to generate net revenue retention above 110% at the best vertical franchises. Each successful deployment widens the scope of business the vendor is trusted with. Every expansion occurs within an existing relationship focused on productivity returns and outcomes rather than through a fresh sales cycle against a procurement department that is short-term minded and cost-centric.
What's next
The next pillar in our AI transformation framework is the proprietary data generated by doing the work — and our view of what really constitutes "proprietary data".
