Rethinking Control in the Age of AI Delivery
In late 2020, I was sitting in the logistics planning for the UK vaccination program, on a team that knew that both the Pfizer and the AstraZeneca vaccines were coming before most of the country did. I was used to planning tech projects, not a country-wide vaccination. What I remember is thinking about how difficult it is to control just one small logistical plan, let alone something on the scale of the entire country.
Control—the entire practice of program, project, and workstream delivery management—is again on my mind, now that I'm working on AI program delivery. Every business runs on process and system controls when it operates, from a balance sheet to a P&L. Controls represent the processes and procedures that reduce the risks of failure in delivery.
The traditional, established practice is to surround technology delivery with controls: multi-level plans, governance, phased delivery, and agile practices like peer review. Scope the work, build a plan, and adjust as things change. Once work is completed, the cycle starts again, repeating over the life of the program.
But what does control look like for a multi-thousand-user AI technology rollout program?
In theory, AI implementations should still be subject to controls: a business case, technology architecture sign-off, scope turned into a rapid MVP, formal user sign-off, and go-live acceptance criteria. Yet AI is also a personal instrument, a tokenized digital worker that applies institutional knowledge to a workflow.
Delivery programs haven't been able to establish reliable controls over digital workers or personal assistants. AI shows up overnight, in multiple shapes, in every corner of the enterprise. Organizations want to control tokens, but the traditional, formal shape of an implementation program hasn't entirely worked.
So what controls should the program keep as-is, and which should evolve for AI delivery?
Some things should stay exactly as they are, namely the core strategy and foundations of a delivery program. An assured, estimated L1 plan is still essential (L1 meaning the top-level plan in a large program, the kind of language that will resonate with delivery managers who remember L0 through L5 planning from the massive programs of the past). AI platform ownership is another constant, what agile calls product ownership. Delivery governance and architectural and design authority round out the list.
Everything else can loosen.
An institutional AI platform needs to serve both the enterprise and each individual employee who relies on an agent. That dual role calls for less delivery control, not more. The AI delivery team needs to act more like gardeners than architects, cultivating each prompt, agent, and use case.
A global insurance client recently showed us what good looks like.
Our program lead scoped the initial deployment tightly, with carefully defined use cases. The plan, ownership, and governance stayed firmly in place, with approvals sitting over workflows that were shared organization-wide.
After the program ended, business departments kept innovating and building new agentic workflows on their own. What didn't change was who owned the platform and who held architectural authority over how new agents got built—and that's exactly what let departments build in parallel without the whole thing drifting apart.
Our enterprise AI rollout had matured to the point where it no longer needed formal program delivery controls. Our looser approach enabled better cultivation of AI across the organization. Keep the plan, ownership, governance, and architectural authority. Do not hesitate to rethink, or even scale back, other delivery controls.
