Everyone seems to be trying AI, and yet almost nobody is doing it at scale.

So what's getting in the way? Architecture.

That was the throughline of a conversation we had at Insurtech Insights with Arron Lamp, who runs technology for Tokio Marine HCC's Public Risk Group. If you wanted to design the hardest possible environment to deploy AI in, it would look a lot like his: 15 lines of business, large and complex risks, unusual vehicles, and policies that are public. This means every decision he makes gets scrutinized.

His framing was simple: make AI work here, and you can make it work anywhere.

What follows are the lessons that came through, and why we think they apply far beyond one carrier.

The problem isn't the model, but the prep

Most AI projects don't stall because the model isn't good enough, but because the work to get ready for AI was never done.

Search "what makes AI successful" and the answer comes back to the same thing every time: consistent, quality, documented, governed data. Not a dataset pulled from the warehouse that means one thing, stitched to something from the modeling team that means another, with the assumption that the model will sort it out. It won't.

This is the part everyone wants to skip. The instinct is to treat AI as the thing that solves the mess, while in reality, the teams that succeed spent the unglamorous time first — getting their data into a usable shape, building the microservices, and making the environment something an AI can actually operate inside. Arron's team spent a little over a year doing exactly that before scaling anything.

The discipline here is the same discipline IT has used to ship reliable software for decades. Can you execute the transaction? Can you trust the output? Can you audit it? Somehow, when the conversation turned to AI, a lot of people forgot they already knew how to do this.

Run AI in the middle, not on the side

A common pattern is to bolt AI onto the edge of the business, as a side process that reads something and hands back an answer. It may do well in demo, but it rarely makes it to production.

The alternative is to run AI in the middle of the environment. That means pulling business logic out of legacy systems and into a layer where it can be orchestrated. In Arron's case, this means migrating to a single JSON structure and running logic as Python on Lambda. Each AI use case then behaves like a native part of the environment, orchestrated alongside everything else, instead of a one-off sitting on the periphery.

When AI lives in the middle, a single use case can be trusted the same way you'd trust a rote calculation — like summing a total insured value. That's the bar. If it can't clear it, it isn't ready.

Don't buy, don't build, rent

One line from the conversation stuck with us:

"I want to rent you, not buy you."

It's worth unpacking, because it's a whole philosophy of working with vendors.

Arron isn't going to build the AI capability in-house. He's deliberate about not staffing an army of PhD data scientists — his point being that the talent is expensive and that's not where his edge is. He's also not "buying" in the sense of locking in, owning it forever, signing one giant contract up front.

Renting means the vendor has to keep earning it. You start small, prove value, and the contract grows as the results do. Stay the best (more accuracy, lower cost, every year) and he keeps paying. Slip, and he can walk away. The leverage stays with the customer.

It ties back to where the real value lives. Don't burn time rebuilding what you can buy. Invest in the things that are uniquely yours (your data and your business logic) and partner with the best to do the rest.

Start with small bites

The ambition is to automate everything, and the common mistake is trying to do it all at once.

Submission processing is a good example. It sounds like one workflow, but it's closer to 20 — ingestion, triage, checking against guidelines, clearance, and more. Trying to land all of it in one shot is how many projects collapse.

So Arron started with loss runs. One well-scoped use case. Prove it works, make it auditable, build trust with the chief risk officer and the teams who have to rely on it — then bring the next thing. By the time you do, you've earned the right to: "that first one worked really well, and here's how we check it."

The bites stay small on purpose. Each one builds the trust and the trail that makes the next one easier.

Keep the workflow deterministic

AI gets used at various steps of the process. The overall workflow stays deterministic.

That's the governance model: human-in-the-loop where it matters, audit trails, runs checked for outliers and extraneous results. And then there are periodic walkthroughs to confirm the output is still right. The goal is predictability and trustability — the "ilities" that let a machine read something, return an answer, and have that answer hold up.

If you can't trust the output the way you'd trust a rote calculation, it doesn't go to production.

The boring work is the work

The teams winning with AI aren't the ones with the flashiest use cases. They're the ones who did the boring work first — the data, the logic, the environment, the governance — and then let AI compound on top of it.

Start small. Prove value. Earn the next step. Do it in the hardest environment you can find, and the rest gets easier.

Thank you Arron for being generous with your time, and Insurtech Insights for the opportunity.