The gap
Enterprise AI programs stall in pilot. Not because they lack ambition. Not because they picked the wrong model. Because there is a structural gap between an approved strategy and a system a board can audit.
A decision gets made. A build starts somewhere else. A demonstration looks finished in a sandbox. The operating team inherits it later, and the board asks when it will be production. Accountability was split across those steps, so nobody can answer.
The organizations that get through this do not do it with a better deck. They hold a different standard for what counts as done.
I call that standard the Operator Model.
Three habits that show up when AI actually ships
1. The decision is in service of a build
A roadmap is useful when it reduces the risk of a build. It is not a substitute for one. When an agent has to handle an outage inquiry or retrieve a policy, the useful question is the thinnest slice that can face real work with its limits already defined.
2. Trust is engineered
Observability, evaluation, and boundaries are part of the system. Every production agent needs a record of queries and responses, traceable tool calls, a check before each change, a person in the loop at defined limits, and a view of cost from the start.
If you cannot say what the agent did last Tuesday, it is not production. It is a demonstration that happens to be running.
3. One line of ownership
The people who scope the problem stay through deployment and leave behind something an operations team can run. A long handoff from decision, to build, to internal operations is where accountability disappears. That is especially costly in a regulated environment.
Forward-deployed teams already work this way. A regulated enterprise cannot always copy their structure. It can still require the same standard of whoever is accountable for the agent.
What usually gets inverted
Most enterprise programs reverse the model:
| The standard | The usual program |
|---|---|
| A thin slice on real work within weeks | A sandbox proof that runs for months |
| Evidence from the first day | Logging promised for later |
| A bounded agent, with escalation | An open-ended chatbot |
| A named outcome | Activity, and a vague definition of success |
| Controls that let the work proceed | Controls that only block it, or no controls at all |
The result is familiar. The demonstration is impressive. The audit is not. The workflow a customer actually touches never starts.
The same standard, in a regulated enterprise
Utilities, financial services, and retail cannot treat a mistake as a later patch. A wrong outage window draws a regulator. An uncited compliance answer is a model-risk problem. A returns agent that ignores policy creates an operational liability.
The standard adapts. It does not get softer:
First, see what already exists
Inventory the pilots. Map one workflow from end to end. Say what evidence the board will ask for, and what the agent is not allowed to do.
Then put a narrow slice on real work
A bounded agent, action limits, traces, evaluations, and a view of cost. Fail where someone is watching, before failing where a customer is.
Then make it operable
A check before every model or prompt change. Runbooks. Artifacts an audit team can use. A named owner after the builders step back.
Then call it production
Not "AI enabled." One workflow, measurable, observable, and governable.
Observability is the missing layer
Tracing, evaluation, drift detection, and cost are often added after go-live. Operators who are serious about the system put them in first.
For an enterprise agent, that layer answers four questions a board or a regulator will ask:
- What did the agent do? The query, the response, the tools it called.
- Was it correct? Evaluations, citations, and a check for answers that were not grounded.
- When did behavior change? Drift, and a gate before the next change ships.
- What did it cost, and who can stop it?
Without that layer, governance is a policy document. With it, governance is something you can inspect.
What this means for a leadership team
If you are a CIO, CDO, or operating leader between a pilot and production, the model is a filter:
Do not accept an open-ended chatbot with no limit on what it can do
Do not accept a build that has no evaluation and no trace in scope
Do not accept a split in which the people who framed the decision leave before the system runs
Require one workflow that can be audited, then repeat the pattern
You do not need the structure of a research lab. You need one line of ownership that can build, show its evidence, and answer for the outcome.
Where I sit
I lead AI architecture and delivery for regulated-industry clients at PwC, including utilities, financial services, and retail. Views here are my own and do not represent PwC.
Related: Why the AI Roadmap Never Reaches Production · Agent Observability: What Boards Actually Need