Are you AI ready? Seven questions.

Most AI readiness assessments score ambition. They ask how strategically aligned your AI vision is, how advanced your data culture is, whether you have an AI centre of excellence. An organisation that has thought about AI a great deal and shipped nothing scores well on all of them.

A more useful test is narrower: could you put one AI system into production and keep it there? Seven questions decide that. They are not a maturity model, they do not produce a number, and most organisations fail at least two of them. The failure points are more useful than the score.

1. Can you name one decision that would change?

Not a capability, not a department, a decision or a repeated task. Which claim to escalate. Which customers to call this week. Whether a supplier invoice matches the contract. Something a person does now, often, with a visible cost.

Failing answer: a domain. "Customer service." "Finance." Domains cannot be built against, so they become discovery phases.

Fix: follow the cost. Find the task where people spend the most hours producing the least judgement, and start there. It will be unglamorous. That is the point.

2. Could a build team have the data within a fortnight?

Not "does the data exist". Could a named engineer, starting Monday, get working access to it inside two weeks without a steering committee.

Failing answer: anything that routes through an approval nobody has obtained before, or a system whose owner has left. In Australian mid-market organisations the usual blocker is a vendor-hosted system where the contract does not clearly grant you extract rights, which takes eight weeks to resolve and is nobody's job to start.

Fix: run the access request now, before the project. It is the cheapest thing on this list and the most common cause of a stalled first month.

3. Do you agree on the definitions the answer depends on?

If the output depends on "active customer", "revenue", "on time", or "churn", do two parts of the business define those the same way? Ask them separately and compare the answers rather than convening a meeting, which produces consensus instead of information.

Failing answer: they differ, and nobody owns the resolution. This is the single most common finding we see, and it is a governance problem wearing a technology costume. An AI system built on contested definitions produces confident answers that different parts of the business reject for different reasons, and the project is blamed for the disagreement it exposed.

Fix: settle the three to five definitions your first use case touches, in writing, with a named owner each. Not the whole glossary. Governance that starts with a complete catalogue never finishes.

4. Is there a person accountable for the output?

Someone whose performance changes if the system works, and who has the authority to change the process it feeds. Usually a line manager, rarely the CIO, never a committee.

Failing answer: the project has a sponsor but no owner. Sponsors fund; owners accept the answer and change how their team works because of it. A system with a sponsor and no owner reaches production and is not used.

Fix: name the owner before the build starts and make the first deliverable something they asked for, rather than something the data team found interesting.

5. Could you tell if the system were wrong?

Describe, in one sentence, how you would find out that the output had degraded. If the answer requires the person receiving it to already know the right answer, you do not have a check.

Failing answer: "the users would notice". They notice obvious failure. They do not notice a model that has drifted from 91% to 78% accuracy, which is the failure mode that actually happens.

Fix: decide the monitoring signal before you build: a held-back sample checked monthly, a rate that should stay stable, an exception queue somebody reads. This is also what regulators increasingly ask for. The difference between claiming a control and being able to show it operating is the subject of asserted versus observed compliance.

6. Can you fund a year of running it, not just building it?

Running cost is inference, hosting, monitoring, retraining, and the fraction of someone's week spent looking after it. For a working production system it is commonly 15% to 30% of build cost per year, and for high-volume inference it can exceed build cost entirely.

Failing answer: the business case covers build only, and the run cost is expected to be absorbed. It will be absorbed by the team least able to refuse it, and the system will be quietly retired at the next budget round.

Fix: put a three-year run line in the case, and ask any supplier to quote it. A supplier who cannot has not built one before.

7. Have you decided what happens if it does not work?

A stated kill condition, agreed before anyone is invested. "If it is below 85% agreement with the human reviewers after eight weeks, we stop."

Failing answer: there is no condition, so the project cannot fail, so it cannot finish either. It becomes permanently promising, and it consumes the budget that a second attempt would have needed.

Fix: write the condition into the first phase. It is the cheapest form of risk management available and the one most often skipped because it feels pessimistic.

How to read your answers.

There is no score. There is a pattern.

• Failing 1 and 4 means the problem is not chosen. Nothing technical will help yet. Prioritise use cases with the business, not with IT.
• Failing 2 and 3 means the constraint is data, and specifically access and agreement rather than volume or quality. This is the most common pattern and usually the fastest to clear.
• Failing 5, 6 and 7 means you can probably build it and will struggle to keep it. This pattern shows up in organisations with a successful pilot and nothing in production, and it is an operating-model problem rather than an AI one.
• Failing one question only means start. Fix that one inside the first phase.

If different parts of your organisation would answer these differently, that disagreement is itself the finding, and it is the case for running a formal AI readiness assessment rather than proceeding on the loudest answer. What a real assessment covers is set out in how to run an AI readiness assessment, and what should come out of it in what happens after one.

One last thing worth saying plainly. Readiness is per use case, not per organisation. The same company is ready to automate invoice matching and not ready to put an agent in front of customers, and a single maturity score hides that. We have written about the second half of that problem in where AI agents do not work yet.

General information only, not legal or regulatory advice. Current as at September 2026.