AI needs an operating model. Not just a pilot.

Start with the work.

My starting point for enterprise AI is a practical question: which piece of work should become easier, faster, or more reliable? “We need an agent” is a solution looking for a problem. “Our employees cannot get a dependable answer without navigating several systems” is a problem worth understanding.

I've deployed two AI agents to production. That experience has made the gap between a pilot and an owned service especially relevant to my point of view. A useful pilot makes the problem concrete. It identifies the people affected, establishes a baseline, and defines what a better outcome looks like. Without that foundation, a compelling demonstration can be mistaken for progress.

Design the operating model alongside the solution.

Before expanding a pilot, I want clarity on ownership, permitted actions, data access, and the point at which a person must take over. An assistant that recommends an action and an agent that executes it require different controls. That distinction belongs in the design from the beginning.

As a hypothetical employee support workflow, this might mean starting with answers grounded in approved knowledge, showing where those answers came from, and routing uncertain cases to a named support team. More consequential actions should have explicit approval boundaries and a record of what happened.

Measure the entire workflow.

Time saved is useful, but incomplete. I would also look at answer quality, rework, escalation, adoption, and the cost of running and supporting the service. If employees spend the time they saved checking unreliable output, the workflow has not improved.

The next investment should follow evidence of value, with clear limits on what we are willing to risk.

I favour small, measurable deployments that teach us something specific. Expand what works. Redesign what does not. Stop when the evidence no longer supports the investment. That is how an AI initiative becomes an organisational capability.

Make the next decision explicit.

Consider a hypothetical employee knowledge assistant. Before a trial, I would agree which questions it is intended to answer and what counts as an unacceptable response. The evaluation should include ordinary questions, ambiguous requests, outdated policy material, and questions outside its remit. A good answer is more than fluent text: it needs to be correct, appropriately scoped, and useful to the person asking.

I would then bring the operational owner into the review. Who updates the source material? Who examines failures? What happens when the model or a connected system changes? Those responsibilities need time and capacity, not just names on a slide. The pilot should leave us with a decision: expand a defined use case, repair a specific weakness, or stop. I’m still learning how these systems evolve, but that discipline gives experimentation a useful direction.

Ideas and perspectives are my own. Writing and editing assisted by AI.