Know what to automate, and what not to.

Companies rarely fail to adopt AI because the technology doesn't work. They fail because the organisation wasn't ready for it in ways that only become visible after the investment is made. Readiness is less about tooling and more about whether a handful of underlying conditions are actually in place.

Problem clarity decides whether the result can be judged

When the current problem, who experiences it, and what a measurable improvement would look like can't be described clearly, there's no real way to judge afterward whether an AI solution helped. Vague problems tend to produce solutions that are just as hard to evaluate.

Workflows hide their own exceptions

Mapping the current steps, handoffs, and approval points usually surfaces more exceptions than expected, and not every repetitive task is actually a good automation candidate. The exceptions and edge cases are where most AI pilots run into trouble, not the common case that made the pitch look easy.

Data existing and data being usable are different claims

Most organisations already hold the data an AI system would need, but existing isn't the same as usable. What matters is whether the data is accurate enough, can be accessed lawfully, and has an owner responsible for its quality and availability, not just whether a record of it exists somewhere.

Governance decided late gets decided badly

What the system may do, what requires human approval, how sensitive information is handled, and how decisions get reviewed afterward are governance questions that are far easier to answer before a system is chosen than after it's already live and handling real cases.

Ownership doesn't end at launch

A product without a named owner after launch tends to drift. Subject-matter experts, technical delivery, security, and the people using the workflow every day all need a stake in it, or the system quietly stops matching how the work actually changes.

Scope decides whether a pilot proves anything

A pilot chosen for visibility rather than learnability rarely produces a clear result either way. The use cases that prove something are the ones where the value can be observed, the risk can be managed, and the team can learn quickly, usually a smaller, reliable workflow rather than a broad programme with no clear owner.