Four things that change once AI is in the programme
Each of these is a programme decision with a technical consequence, and none of them belongs to the delivery team alone. Each closes with an owner and a test you can run this week.
One: the unit of delivery stops being "done"
Every other workstream on your plan delivers something finished. A module goes live, a migration completes, a ticket closes. A model does not finish. It is trained on a world that then carries on changing.
Your supplier base shifts. A product line launches. A process is redesigned. The pattern the model learned stops matching the business it runs in, and nothing throws an error, because software that breaks raises an alert while a model that degrades just keeps answering in the same confident tone.
So monitoring belongs in the programme scope from the start, not in a later phase. Decide what you watch: the share of cases sent to a human, how often somebody overrides the suggestion, how quality moves against a fixed set of test cases, and the cost per call, which is an infrastructure signal that something upstream has changed.
This is ordinary operations work that belongs where your other watching already happens, so if a network operations centre already watches your estate, model drift belongs on the same wall rather than in a notebook nobody opens.
This is also the line between intelligent automation and scripted automation, because a bot does the same thing forever until you change it, which is why business process automation with RPA is a different kind of project with a different kind of risk.
Owner: operations, with the team that built it. Test: name the person who gets the drift alert, and what they do next.
Two: the review step becomes the design
In most transformation projects, approval is a workflow detail settled late, but with AI it is the design, because it is the thing standing between a useful suggestion and an unreviewed decision.
Three questions settle it. Who approves the output, and at what value or risk does that move up a level? What is recorded when they do, so the decision can be explained months later? And what happens when nobody responds, which is the case that quietly breaks every approval process ever built?
Get this wrong in one direction and nothing ships, because every output waits for a committee; get it wrong in the other and nobody checks anything, which is worse and takes longer to notice.
There is also a hard line here: a system that suggests to a person who then decides is a productivity feature. A system where nobody reviews the output is making the decision, and if that decision is about a person, the date further down applies.
Owner: the process owner, with risk or compliance. Test: for each output, who signs, at what threshold, and what is stored.
Three: data ownership stops being an IT topic
Every prediction, every suggestion, every extracted field lands against a record. A customer, a supplier, a material, a claim, a patient. If those records disagree with each other, everything built on top inherits the disagreement, and nobody sees it happen.
The test takes ten minutes and it settles the argument: pick one supplier and count how many versions of it exist across your systems. If the answer is more than one, a model treats them as different suppliers, and your forecast is wrong in a way no dashboard shows.
What that needs is not a data project but a named person per core record type who decides what the fields mean and who may create new ones. That is a business role, not an IT one, and it is the single item on this page that transfers to every future system regardless of which platform you end up on.
Do it now rather than during. Our posts on AI and machine learning in data management and on data management and governance cover the ownership and the governance halves of it.
Owner: a business data owner per record type. Test: can somebody name who approves a new supplier record?
Four: the cost line changes shape
This is the one that surprises finance, and it surprises them after the pilot rather than before.
Traditional enterprise software costs what the licence costs, and the number does not move when more people use it, while AI costs per use. Every document read, every question asked, every summary drafted carries a cost, and the total grows with adoption. A pilot with forty users tells you almost nothing about four thousand.
There are no prices in this article, because they change and because yours depend on your volumes and your deployment. What matters is asking the right shape of question before you commit.
Four questions cover it. What does one transaction cost to process today? What will it cost through the AI path? How does that change at ten times the volume? And who signs for the difference?
Where the workload runs decides most of the answer, which is why the deployment decision and the AI decision belong in the same conversation. Our post on the role of cloud computing in digital transformation covers that side properly.
Owner: finance, with the infrastructure lead. Test: state the cost per transaction at ten times current volume.
