What it takes to move AI beyond the pilot

A pilot and a production system are easy to confuse in a meeting. They are not the same thing:

• Production system, built inside the platforms the business already uses, with an owner, an approval path and a record of everything it did.
• The pilot, which proves that a model can produce a plausible answer on a clean example, in front of the people who asked for it.

That is not nothing, but it is the smallest part of the problem, and it is the part that has been getting easier every year while the rest has not moved.

The demonstration is the easy part

A pilot proves that a model can answer. A system has to answer on the work the business actually runs on.

That work is not clean. It arrives late, in the wrong format, from an older system, with an exception attached that nobody ever wrote down. The chart below is illustrative: it shows how much of that work each approach handles once it leaves the demonstration, against the effort it takes to get there.

* Illustrative figures. How we measure: the written blueprint

Where it stops

A pilot needs to address the exceptions, the systems of record and the question of who approves its actions. Each one changes what the production system has to do, beyond producing a plausible answer.

None of the three appear in a demonstration, because a demonstration is built to avoid them. That is why the meeting goes well and the project does not.

*The vendor platform's figure is an estimate, pending a full review.

A pilot also degrades as the work gets longer. A case that crosses three teams and a month of history is not the case it was shown. A system built for operation keeps the case whole, from the first request to the last record it touches, across every handoff.

What a system has that a pilot does not

A system has an owner inside the business, an approval path for anything it changes, and a record of what it read and what it did. It runs where the data already lives, so nothing has to be copied out to make it work.

Every connection is written down in the blueprint and reviewed by the client's engineers before anything runs. A connection looks like this:

import os
from connectors import Environment
from connectors.systems import policy_admin, claims, document_store, approvals, audit_log

env = Environment(token=os.getenv("CLIENT_ENVIRONMENT_TOKEN"))
run = env.process.open(
    process="commercial-renewals",
    systems=[
        policy_admin(),        claims(),        document_store(),        approvals(owner="Head of Underwriting"),        audit_log(),    ],
)

The system runs inside the client's own environment, so nothing is migrated and nothing is replaced. It decides which record to read and when, often checking several systems across several steps, and hands the case to a person with the working attached wherever no rule exists.

Building for continuing operation

A system is built to be operated, not demonstrated. Four things make that possible:

Start where the work is

We start by sitting with the people who do the job and writing down how it actually runs. What gets built comes from that, not from a template and not from whatever the model happens to be good at. The comparison below is illustrative.

*Reconciliation here means matching two records that should agree, with the rule for when they do not.

A production system is also wrong less often in the way that matters: when it does not know, it says so and hands the case on, where a pilot answers confidently and moves on.

Then stay

Lyrion scopes, builds and operates its systems, in two parts after the scoping session:

• build inside the client's own platforms, under their controls
• operate after go-live, by the same engineers who built it

Tell us about the process you want handled

Start with aScoping SessionOrTalk to us

Staying involved means learning from production and bringing that understanding back into the work. When something breaks, it is ours until it is fixed.