What is AI readiness?

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.

Why AI readiness is not a technology question

Ask an IT function whether the organisation is ready for AI and the answer will describe infrastructure, integration and data quality. All three are necessary. None of them is the thing that fails.

What fails is the boundary. Before AI, a system did what it was configured to do, and a person made the judgement calls. The boundary between the two was visible in the process design, and accountability followed it. AI moves the boundary without announcing that it has moved, because the feature that relocates it is presented as an enhancement rather than as a change to who decides.

An approval workflow that surfaces a recommendation has not automated the approval. It has changed the default. The person still clicks, so the audit trail still shows a human decision, and in most organisations that is where the enquiry stops. Six months later nobody can say which approvals were judgements and which were confirmations.

Readiness, in the only sense that matters, is whether the organisation drew that boundary deliberately before the system did it for them.

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.

How to assess AI readiness

An AI readiness assessment is only useful if it tests behaviour rather than intent. Four questions do most of the work, and none of them requires a specialist to answer.

Where is AI already active in the platforms you run? Most organisations cannot produce the list. Features have been enabled by default, switched on during configuration, or delivered in a release note nobody read. An inventory of where the technology is already making or shaping decisions is the first honest measurement of readiness, and it is usually the most uncomfortable.

For each of those, who approved the delegation? Not who configured it. Who decided that this class of decision should move. If the answer is the implementation partner or the release cycle, the delegation happened without a decision.

What is the standard the output is checked against? A recommendation is only as good as the reference point used to challenge it. Organisations that cannot name the standard are not reviewing outputs. They are receiving them.

What happens when it is wrong? Follow one hypothetical error end to end. Who notices, how quickly, what gets rolled back, who is accountable to the customer or the employee affected. If the path breaks at any point, that break is the readiness gap and no amount of infrastructure closes it.

Four questions, all answerable from evidence that already exists. An assessment that scores intention will return a comfortable result. An assessment that scores these will return a useful one.

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.