How to govern an AI implementation project

The problem is ownership, not capability

Organizations rarely struggle to find an AI use case. They struggle to move one from demonstration to routine operation. A pilot is approved, a vendor is engaged, an internal enthusiast produces a convincing result, and then the initiative stalls in the space between the proof of concept and the business process it was meant to change.

In many cases, the underlying problem is structural. A pilot has a sponsor but no delivery owner. It has a budget but no baseline. It touches data owned by one function, a process owned by another and a risk position owned by a third — and no one is accountable for reconciling them. When the pilot succeeds, the organization discovers that success was the easy part.

Governing an AI implementation therefore begins with an unglamorous decision: naming the person accountable for delivery, and defining what they are accountable for. Everything else follows from that.

Prioritize use cases against implementation cost, not novelty

A credible AI portfolio is prioritized on two axes: the operational value of the outcome, and the real cost of implementing it — data access, process change, integration, training and oversight. Novelty is not a criterion.

In practice this means scoring each candidate against a small number of honest questions: which decision or task changes; who owns the data required; what the process looks like after adoption; who reviews the output; and what happens when the model is wrong. Use cases that cannot answer the last two questions are not ready for implementation, regardless of how impressive the demonstration was.

• Which specific task or decision changes
• Who owns the data and grants access
• What the process looks like after adoption
• Who reviews and accepts the output
• What the failure mode is, and who absorbs it

Run pilots with an exit condition

A pilot without a defined exit condition becomes permanent. Before it starts, the organization should agree what result would justify scaling, what result would justify stopping, and by when that judgement will be made. Both outcomes must be acceptable answers; a pilot that can only succeed is not an evaluation, it is a commitment already made.

The exit condition should be expressed in operational terms — cycle time, error rate, cost per case, throughput, quality of review — and measured against the current baseline. If the current baseline has never been measured, measuring it is part of the pilot.

Treat data and access as the critical path

In many AI implementations, data access, integration and operating ownership become more critical than model performance alone. What matters is access: which systems hold the data, who authorizes its use, how it is cleaned and refreshed, and what constraints apply to it under contract or regulation.

These dependencies belong in the plan as named items with owners and dates, not as assumptions. A pilot that quietly ran on an exported spreadsheet has not demonstrated that the production version can run at all. Making data dependencies explicit early can materially reduce avoidable implementation delays.

Plan adoption as delivery, not as communication

Adoption fails when it is treated as an announcement. The people whose work changes need to know what they are expected to do differently, what they remain responsible for, and where their judgement still overrides the system.

That requires concrete delivery work: revised process documentation, review responsibilities, training, a support route for the first weeks, and a feedback loop that reaches the people maintaining the solution. It also requires an honest position on oversight — which outputs are checked, by whom, and how exceptions are recorded.

Report to management in the same format as any other project

AI initiatives benefit from being reported exactly like other delivery: current position, progress against milestones, open risks, decisions required and dependencies at risk. Specialist vocabulary should not enter the executive report; the sponsor needs to know whether the initiative is on track and what is being asked of them.

A short, fixed-cycle status of this kind does something a demonstration cannot. It gives management a continuous basis for deciding whether to accelerate, hold or stop — while the decision still costs little.

The governance minimum

For most organizations, an adequate structure is small: a named delivery owner, a prioritized use-case list, a pilot with an exit condition, a dependency register that includes data and access, an adoption plan, and a fortnightly one-page status. None of it is specialized to AI. That is precisely why it works.