The Gap Between Trying AI and Running It

Most insurers and financial services firms have proved they can try AI. A team builds a pilot, the demo works, and leadership sees the potential. Running AI is a different capability: taking use cases into production, keeping them safe, and doing it again without starting from scratch each time.

The gap between the two shows up in three ways. They look like separate problems. They are not.

1. Pilots everywhere, production nowhere

A pilot proves a model can do a task. Production asks harder questions: what data it may use, who approves it, who supports it when it breaks, and how you will know it still works next quarter. When each team answers those questions on its own, every use case pays the full cost of reaching production, and most stop paying.

The warning sign is a long list of pilots and a short list of systems anyone depends on. Another is the success measure. If no one wrote down what a pilot should change, in numbers, before it started, there is nothing to decide with when it ends.

What helps: define the path to production once, and send every use case through it. Agree the success measure before the build starts, not after the demo.

2. Governance playing catch-up

Governance programs were built for projects the firm commissions. Much of today's AI arrives another way. A vendor switches on an AI feature in a product you already license, or an employee starts using a generative AI tool no one reviewed. None of that passes through a project gate.

The result is a question most firms struggle to answer when an auditor, regulator, or board asks: where is AI in use, what data does it touch, and who approved it?

What helps: start with an inventory that includes AI inside the software you buy, not only the software you build. Then match the depth of review to the risk, so low-risk uses move quickly and high-risk ones get real scrutiny. Governance that slows everything down gets worked around.

3. No operating model

This is the root of the first two. Without a single front door, requests go wherever someone has budget or enthusiasm. Without shared standards, every team decides for itself what "tested" means. Without an owner for support, a system that works at launch has no one watching it afterward.

An operating model does not mean central control of every use case. It means clear answers to four questions: who decides what gets built, what standard it must meet, how it reaches production, and who runs it after launch. Business units still own their use cases and outcomes. The center owns the standards and the path.

What helps: name the owners, open one intake with shared scoring, and put a small first wave of use cases through the new process. The first wave proves the process works and shows what to fix.

One problem, three symptoms

Stalled pilots, lagging governance, and a missing operating model are usually treated as three workstreams with three owners. In practice they are one problem. Fix the operating model, and the path to production and the governance baseline finally have somewhere to live.

If your firm can try AI but struggles to run it, find which of the three hurts most today. Then fix the operating model underneath it.