Is your business actually ready for AI?

Your data has to be reachable

AI cannot use knowledge trapped in a filing cabinet, a PDF nobody can query, or a system with no export. Readiness usually means getting the information somewhere it can be accessed first.

That work is unglamorous and it is most of the project. Teams are frequently surprised that the AI portion of an AI project is the small part, and that the majority of the effort goes into plumbing.

It is also work that pays off regardless. Data you can reach is useful for reporting, for integration, and for whatever you decide to do next, even if the AI idea is abandoned.

The process has to be stable enough to encode

If a workflow is being redesigned next quarter, building on it now means throwing the build away with the process. The same applies to processes wrapped around a system you are actively considering replacing.

Stability does not mean perfection. It means the shape of the work is settled enough that the assumptions you encode will still hold in six months.

Where a process is genuinely in flux, the honest recommendation is to wait, or to automate at a layer that will survive the change.

Someone has to own the outcome

Projects without a named owner drift. Someone inside the business needs to care whether this works, and to have enough authority to make decisions when the design meets reality.

That person does not need to be technical. They need to know the process well enough to say when the output is wrong, which is a completely different qualification and much harder to substitute.

When nobody will take that role, it is usually a signal that the problem is not painful enough to justify the project.

You have to be able to say what wrong looks like

Before anything is built, somebody has to be able to look at an output and judge it. If nobody in the business can reliably distinguish a good result from a plausible-looking bad one, you cannot evaluate the system and you cannot safely deploy it.

This is the readiness criterion most often missed, because it sounds obvious and is frequently untrue in practice. Plenty of processes produce output that only one person can assess, and sometimes not even them.

Where that is the case, the first piece of work is defining the standard, not building the system.

You need a way to tell if it worked

Decide the measure before the build. Hours returned, errors avoided, response time cut, percentage of cases handled without escalation. Any of these is fine; having none is not.

Baseline it first, while the old process still exists. Once it is gone, the previous cost becomes a matter of recollection, and recollection is generous in whichever direction suits the person recalling.

Without a measure, every conversation about the system becomes an argument about impressions, and the system survives or dies on politics rather than results.

Somebody has to be prepared to switch it off

Set a review date before you start. Ninety days is usually about right: long enough for novelty to fade, short enough to still act.

Then look honestly, including at the possibility that it did not work. The ability to retire something is what makes it safe to try things in the first place.

A portfolio where nothing is ever switched off is not a portfolio. It is an accumulation, and every item in it has a maintenance cost somebody is paying.