AI transformation for companies with something to lose

When the current generation of AI models arrived, the prediction was upheaval. If a company adopted AI to the fullest extent possible, whole categories of business processes and jobs would have to shift, and for a few months it looked like that shift was imminent.

Then the practical world caught up. People running actual businesses had no time to track weekly model releases, no slack to build AI skills alongside their day jobs, and no appetite for the security, compliance, and cultural risks of a rushed rollout. Faced with a choice between disruption and waiting, most chose waiting. Adoption moved fastest where there was the least to lose: startups building from scratch, and companies whose markets AI had already broken, forcing them to find a new strategy. For established businesses in healthcare, logistics, or distribution, with predictable revenue, long client relationships, and a decent layer of technical debt, it stayed business as usual, even as everyone talked about AI.

The trouble with waiting is that the bill arrives all at once. Software-as-a-service companies are living this now: customers churn quietly, without complaints or negotiations, because they rebuilt part of their stack with AI tools and simply stopped needing the subscription. For traditional businesses that don't transform, the same process is coming with a delay. It looks like business as usual right up until it doesn't.

This is the gap we work in. Alongside building data platforms and software for our clients and for private equity portfolio companies, we've spent the past year developing AI transformation services and taking them to market: helping companies work out where AI genuinely fits their operations, building the first working implementations, and getting them adopted by the people who actually run the processes. Sitting in the middle of this shift means we see how it plays out behind the curtain, in real organizations rather than in keynote slides, and we see which approaches move things forward and which quietly stall.

Nobody has a guaranteed recipe. But some approaches succeed far more often than others, and the same patterns keep repeating across engagements. This article is written for the people who have to make these calls: the management boards of traditional companies, and the operating partners who oversee them. To keep it practical rather than theoretical, the sections below follow one recent example: an established B2B company, roughly four decades in business, with physical warehouses, hundreds of employees, and a partner and reseller network in the tens of thousands, which brought us in around a new recurring-revenue service line. Details have been generalized, but the mechanics are exactly as they happened.

Don't pitch the enterprise transformation

The temptation with a company like this is to go big. Physical warehouses, hundreds of employees, tens of thousands of partner and reseller relationships: the theoretical potential for AI is everywhere you look. We deliberately didn't go there, for two reasons.

First, we only saw a slice of the company. We had spent a year building the platform behind the new service line, which meant we understood that system deeply and the rest of the organization barely at all. Walking in with "we'll transform your company" would have been a claim we couldn't back. Second, a business that has operated profitably for forty years is not shopping for disruption. Nobody who built something that works wants to hear that it should be turned upside down because AI arrived.

So we scoped the AI conversation to the terrain we actually knew. This turned out to be more than a defensive move, because that terrain was greenfield: a new line of business, a new system, with data already flowing in from the legacy sources but none of the legacy processes attached. It is dramatically easier to build something AI-native beside the old core than to rewire the core itself. If you're deciding where to start inside your own company, look for the same conditions: a new offering, a new market, a new operational unit. Somewhere you can move without asking twenty-year-old processes for permission. And treat anyone who promises to transform your whole enterprise in a single engagement with suspicion, because nobody who has actually seen inside a company like yours believes that's how it works.

Find the team with a mandate

Most of the knowledge you need for any improvement sits with people, not in documentation. And in traditional companies, that knowledge is unevenly distributed to a degree that surprises everyone involved. At one point in this engagement, a change the client themselves wanted sat blocked for two months because the one accountant who understood the mechanism was on vacation, and nobody else could make the call. Even managers on the client side, including recent hires brought in to modernize, often couldn't say who owned a given process.

This has two implications. You need genuine access to the team, because they hold the map. And you need management with the will and the mandate to change things, because access without a mandate produces workshops, not results.

In practice, the best entry point is the most forward-looking group you can find. In our case it was a small cluster of newer employees, people who had joined specifically to build the new business line and hadn't yet absorbed the institutional caution. They sat somewhat apart from the legacy core, which gave the work a different license. Prove something real with a team like that, and you earn the backing to go further. Try to move the whole organization at once, and you get the three-month deliberation instead.

Prototypes beat presentations

We know this because we started the conventional way. We prepared a thorough presentation on AI best practices and walked the client through it. The response was polite and familiar: interesting, we're thinking about it internally, we'll come back to you in a quarter. That sentence is where most AI initiatives go to die. Internal deliberation without concrete material to react to rarely converges on anything.

So we stopped waiting. We set up a weekly session and switched from telling to showing. The format that worked was a clickable prototype: a single self-contained HTML file that runs offline, needs no logins, no staging environment, and no accounts on any of our tools. We dropped each one onto the client's own file share. The prototypes were styled to match the layout of the product their team already uses every day. Colors were approximate and everyone knew it; the layout was the point, because familiarity is what lets a manager click through a proposed workflow and immediately judge whether it fits how their people actually work. And because it's just a file, they could forward it internally, walk their own leadership through it, and have the conversation without us in the room.

Over a few weeks we produced ten of these covering six process areas. Each took days, sometimes hours. That speed was only possible because a year of delivery work had accumulated into reusable context: project tickets, meeting transcripts, internal notes, the client's public materials, all packaged into instructions our AI tooling draws on. Every fragment of understanding about how the client operates compounds into the next prototype.

This is also why the approach lands when generic demos don't. Everyone can produce impressive AI output quickly now, and buyers have seen plenty of it. They're tired of examples that prove AI can do interesting things in the abstract. What cuts through is a proposal embedded in their interface, their process, their data structures. A generic demo says "AI is capable." A specific prototype says "this is your Tuesday morning, minus forty minutes."

For a board evaluating AI proposals, this doubles as a filter. A partner or an internal team that can only show you slides hasn't done the work of understanding your operation yet. Ask for something you can click through yourself and forward to the person who actually runs the process in question.

The anatomy of a useful proof of concept

Every prototype we built followed the same shape: a queue of work, an AI assessment, a human decision, and a measurable outcome.

The queue is wherever decisions pile up, such as approval requests, incoming documents, or overdue payments. The AI assessment assembles the full picture a person would otherwise gather by hand: payment history, current exposure, external credit data, prior incidents, all summarized with a recommendation. The human decision is the part we refused to design away. In a business like this, someone accountable signs off, and that isn't a limitation to apologize for; it's the design. The AI's job is to compress a fifteen-minute information hunt into a one-minute review. One prototype extracted data from uploaded invoices and presented it field by field for a person to confirm or correct before anything touched the accounting system. Another drafted payment reminders in the appropriate tone and language, with escalation levels, and let the person send or schedule a call. A third pushed the day's pending decisions into the chat tool the team already opens every morning.

The measurable outcome closes the loop. Even at prototype level, we showed a small counter: this run saved roughly seven minutes of one person's work. It sounds like a gimmick until you watch what it does to the conversation. Individually it's a nice touch; aggregated, it becomes the hard number that justifies the next phase.

There is also a quieter benefit to this anatomy. Because the human stays in control at every step, the team experiences the AI as something that clears their queue rather than something that circles their job. Introducing change in small, legible steps is how you get the people who hold all that undocumented knowledge to participate instead of bracing.

Iterate weekly, and stay honest

The delivery rhythm mattered as much as the artifacts. Each week we presented one or two prototypes on the regular call, always framed against something the client had actually said: based on what you mentioned last time, here's how that could work; click through it and tell us if this matches what you had in mind. Feedback came back, we implemented it within days, sent the updated file, and collected the next round the following week. Each cycle made the eventual specification more real before anyone wrote a line of production code.

Honesty held the whole thing together. The client knew these were fast mockups, that production would look and behave differently, and that a feature shown in an afternoon's prototype still takes real engineering to build properly. That candor paid twice. There were no inflated expectations to walk back later. And the prototypes themselves made complexity visible: when a screen assembles data from four different systems, the client can see why the real version costs what it costs. We also ran our own feasibility check against each prototype, and the answer was encouraging: roughly three quarters of what we showed was buildable with data already in the system, and most of the gap was about capturing more historical detail, not inventing anything exotic.

Measure it or it didn't happen

This lesson comes from our private equity work, but it applies to any management board: don't do AI transformation for its own sake. State what a given project is supposed to accomplish, and measure the baseline before you touch anything. How long does the process take today? What does it cost? How many people touch it? Many companies don't have these numbers, which is a finding in itself, and gathering them is the first task rather than an excuse to stall.

With a baseline you can state a thesis: this review process goes from twelve minutes to two. Then you instrument the work and prove it, or you don't, and either way you've learned something concrete. AI work is unusually measurable when you prepare for it, and measured savings do something that feature lists never do: they de-risk the next investment for the people approving budgets. Measurement also keeps the incentives clean on both sides, since success gets defined in your operational numbers rather than in a vendor's delivered functionality. As a buyer, it even gives you leverage to push for pricing tied to outcomes instead of hours, which tends to keep everyone honest.

The boring prerequisites

One more thing, briefly, because it stops more companies than anything technical. Before any of the above, a company needs a baseline AI policy: which tools are approved, under what agreements, where the data flows, and whether it needs to stay within a given jurisdiction. None of this is hard anymore. The major AI labs offer enterprise agreements that keep your data out of training and let you constrain deployment regions, including EU residency where that matters. But it has to be settled deliberately, because in our experience this is exactly where many companies stall: not at the ambitious step, at the first one. It deserves an article of its own. For now, the point is simply that the legal and tooling baseline comes before the first pilot, not after.

Where this leads

Micro-improvements are the start, not the destination. The largest gains come later, from redesigning processes to be AI-native rather than sprinkling AI onto processes designed for a pre-AI world. But that is advanced work, done one workflow at a time, and it only becomes possible once the earlier steps have built trust, data, and measurement into the organization. The sequence that works looks unglamorous on paper: settle the policy baseline, find the willing team in the greenfield corner of the business, show them clickable proposals built on their own reality, measure everything, and let each proven improvement fund the appetite for the next. A series of small transformations that compound, instead of one big one that never gets approved.

The companies that come through this period well won't be the ones that made the boldest announcements. They'll be the ones that started while everything still looked fine, because business as usual is a lagging indicator.