AI is now built into every platform. Is your programme ready for what that means?

The assumption that no longer holds

Traditional implementation programmes were designed around a straightforward premise: the platform does what you configure it to do. Configuration decisions are made, tested, and documented. The system behaves predictably. Change management addresses the process and behavioural shifts that come with a new tool.

AI changes that premise.

When a platform includes AI-assisted workflow routing, AI-generated reporting, or machine-learning-driven recommendations, the system is no longer behaving purely on the basis of what you configured. It is learning. It is suggesting. It is making decisions in places where humans used to make them. And in most implementation programmes, there is no formal process for deciding which of those decisions should be delegated to the machine, and which should remain with the people.

Who is setting that agenda

The vendor.

AI feature sets are enabled by default, or recommended by the implementation partner as standard practice. Clients accept configurations they do not fully understand, under time pressure, with no independent voice in the room to ask the governance question.

The commercial incentive is not aligned with the client's. Platform vendors benefit from AI adoption. Higher usage creates stickiness. Embedded AI features make migration harder. The implementation partner is focused on go-live, not on whether the AI-assisted approval workflow the client just accepted is consistent with their risk framework, data governance policy, or regulatory obligations.

None of that is anyone's stated problem. Which is why it becomes the client's undisclosed one.

Three governance questions most programmes are not asking

Data governance

AI features consume and generate data. Whose data? For what purpose? Under what retention and access policies? Most data governance frameworks were not written with AI-generated outputs in mind. Programmes that do not resolve this before go-live create a liability, not a capability.

Decision rights

When an AI-assisted process makes a recommendation and a user accepts it without review, who is accountable for that decision? Most organisations have not drawn that line. It needs to be drawn before the system is live, not after the first error surfaces.

Change management scope

Preparing people for a new system and new processes is difficult enough. Preparing them for a system where some of their decisions will be made by an algorithm, and equipping them to interrogate that algorithm when it is wrong, is a fundamentally different challenge. Most change management plans on ERP and HRIS programmes have not caught up with that reality.

What client-side leadership looks like in this environment

It means having someone in the room who understands the AI layer well enough to ask the right questions, before the vendor has embedded the answers into the configuration.

That is not a technology role. It is a governance and programme leadership role. It requires sufficient platform fluency to know where AI is active, the discipline to establish decision rights before go-live, and the independence to ask the vendor why, rather than accepting the default because the project timeline says so.

The organisations that come out of their implementations with genuine AI-enabled capability, rather than AI-embedded risk, will be the ones that treated this as a governance question from day one.