Book a Call
Back
Strategy & ROI

What an AI Readiness Assessment Should Actually Cover

What an AI Readiness Assessment Should Actually Cover
A readiness assessment that ends in a maturity score is wasted money. It should end in a ranked list of things to build.
Max Doyle
Max Doyle
6 Oct 2026
•
11
min read
•
Updated

An AI readiness assessment should cover five areas: the processes you'd change, the data they run on, the systems an AI would have to work inside, the people who would use and own it, and the risks it brings. It should end with a ranked list of things to build, each with an owner, a data status and a first step. If yours ends with a maturity score, you've paid for a benchmark.

What is an AI readiness assessment?

An AI readiness assessment is a short, structured look at where AI could do real work in your business and what's in the way.

Most of them are built on a maturity model. You rate the company from one to five on strategy, data, technology, talent, governance and culture, and get back a radar chart and an average. The board likes it. Nobody knows what to do on Monday.

The problem is the unit. Readiness belongs to a use case, not a company. A business can be ready to automate supplier invoice matching and nowhere near ready for demand forecasting, and both facts disappear into the same 2.8 out of 5. Gartner makes the same point about data: it only counts as AI-ready if it's representative of the use case it's meant to serve.

A company-wide score also produces a company-wide plan. Raise data maturity, write a governance framework, train everyone. Each item is sensible. Together they're a year of preparation with nothing built at the end of it.

Nobody is ready for AI. You're ready for something specific, or you're not.

What should an AI readiness assessment cover?

Five areas, looked at one use case at a time: processes, data, systems, people and risk. Each one should hand you something you can act on.

Intersect's readiness scope. Five areas and what each should hand you. Processes: the 10 to 20 most time-heavy repeatable processes, mapped with the people who run them; you walk away with a shortlist with volume, time per run and the steps AI would take. Data: the data each shortlisted process runs on, its owner, quality and permissions; you get a data status per use case: usable now, fixable in weeks, or a project of its own. Systems: the systems the work happens in, their APIs, licences, admins and security review; you get an integration map per use case with effort and named approvals. People: daily users, the owner after launch, current AI use and spare capacity; you get a named owner per use case and a read on how much change is realistic. Risk: what each use case touches, the rules that apply and unapproved AI already in use; you get a risk rating and required controls per use case, plus an AI use policy if you lack one.
Intersect's readiness scope: five areas, each with the output you should walk away with.

The order matters. Processes come first because they decide which data, systems and people are worth looking at. Start with data and you'll end up auditing everything you own.

Processes

Start with the work, not the org chart. List the processes where people spend the most time on repeatable steps, then sit with the people who run them. Count how often each one runs, how long it takes, how many handoffs it has and where the rework happens.

This is the area that predicts value. In McKinsey's 2026 State of AI survey, nearly three-quarters of AI high performers said they'd fundamentally redesigned workflows, against about a quarter of everyone else. You can't redesign a workflow nobody has mapped.

You walk away with: A shortlist of processes, each with its volume, time per run and the specific steps AI would take on.

Where it goes wrong: Assessing departments instead of processes. "Finance" isn't a use case. "Matching supplier invoices to purchase orders" is.

Data

For each process on the shortlist, find the data it actually runs on. Where it lives, who owns it, how complete it is, whether it sits in a database or in PDFs and inboxes, and whether you're allowed to use it for this.

Skip this and the project dies later instead. Gartner predicts that through 2026, organisations will abandon 60% of AI projects that aren't supported by AI-ready data. In its survey of 1,203 data management leaders, 63% said their organisation lacked the right data practices for AI or weren't sure (Gartner, February 2025).

You walk away with: A data status for each use case: usable now, fixable in weeks, or a project in its own right.

Where it goes wrong: Auditing the whole data estate. You don't need a data strategy to start. You need to know the state of the three or four sources the first use case touches.

Systems

An AI that can't read from and write to the systems where the work happens is a chat window. Check the specific systems each use case touches (ERP, CRM, practice management, shared inboxes, document stores), whether they have usable APIs, which licence tier you're on and who administers them.

Then ask IT how long a new integration takes to get through security review. That number belongs on the plan.

You walk away with: An integration map for each use case: what connects easily, what needs work, and whose approval it needs.

Where it goes wrong: Accepting "we're on Microsoft 365" as an answer. The question is whether the agent can read the right fields and write back to the right place.

People

Every use case needs two people: someone who will use it daily and someone who will own it after launch. Find out who they are, how the team already uses AI, and how much spare capacity they have to change the way they work.

You walk away with: A named business owner for each use case and an honest read on how much change the team can take.

Where it goes wrong: Running a company-wide survey on attitudes to AI. A sentiment score won't tell you who owns the invoice agent in March. A use case with no owner goes to the bottom of the list, whatever its numbers.

Risk

Work out what each use case would touch and what it needs before it ships. Customer data, financial decisions and anything a regulator reads all raise the bar.

So does the AI your staff already use. In a 2026 survey of 1,250 office workers at large companies in the US, UK, Australia and Japan, 66% said they'd used AI tools they believed company policy didn't allow, and 34% had entered customer data into public AI tools (PagerDuty and Wakefield Research, June 2026; vendor research).

You walk away with: A risk rating for each use case with the controls it needs (human review, logging, limits on what data it sees), plus a one-page AI use policy if you don't have one.

Where it goes wrong: Treating risk as a sign-off at the end. Risk is one of the ranking factors. A high-value use case that touches regulated advice can rank below a medium-value one that doesn't.

How should an AI readiness assessment run?

A proper one is a real piece of work. For a mid-sized business looking across several departments, plan on about six weeks, with most of the effort in the middle, where people sit with the work and open up the data.

Six weeks, five stages, a typical shape for a mid-sized business. Week 1, scope and long list: you give a sponsor and two hours of leadership time; you get the long list. Weeks 2 to 3, sit with the work: you give an hour or so with each process owner; you get the shortlist. Weeks 3 to 4, open the data and systems: you give read-only samples and an hour with IT; you get a data status and integration map. Week 5, risk and ranking: you give two hours of risk or legal and a half-day workshop; you get the draft Build List. Week 6, readout and first build: you give the decision-makers in one room; you get a first build ready to start.
A typical six-week assessment for a mid-sized business, with what you give and get at each stage.

Bigger groups run the middle stages once per business unit, which is where an assessment turns into a three-month programme. That's fine, as long as each unit gets its own list and the first build doesn't wait for the last unit to finish.

What should you get at the end of an AI readiness assessment?

A ranked list of things to build. We call it the Build List. Every row is one use case with its value, data status, systems and approvals, owner, risk rating and a first step with a rough cost and timeline. Then a decision: build now, fix something first, or park it.

Intersect's Build List, illustrative example for a mid-sized distributor. 1, supplier invoice matching in accounts payable: build now. Value about 60 hours a week; data usable now, POs in the ERP and invoices as PDFs by email; ERP has an API, security review about 3 weeks; owner is the finance operations manager; medium risk, a person approves mismatches over a set amount and every match is logged; first step a six-week pilot on one supplier group. 2, customer contract review in sales operations: fix data first, because contracts are spread across email and two drives with no register. 3, demand forecasting in supply chain: park, because there are only 18 months of usable history, promotions aren't recorded and nobody owns it.
An illustrative Build List. Every row gets a decision: build now, fix first or park.

The ranking is the point. A good assessment makes the trade-offs you'd otherwise argue about for months: this before that, and that one not at all. Expect the park pile to be the longest. If nothing gets parked, nobody made a decision.

How the list gets ranked

Not with a weighted average across everything. A good list applies four rules, in this order:

  1. No owner, no build. A use case without a named business owner is parked, whatever its value.
  2. Data sets the tier. If the data it needs is a project of its own, it goes to "fix first". The fix becomes its own row.
  3. Risk sets the controls. If the controls can't be in place for a pilot, it drops a tier until they can.
  4. Value over effort. Whatever clears the gates is ordered by the hours or money it saves against the cost and time of the first build.
Gates first, maths second. A weighted score lets a big number hide a missing owner.

Process maps, a data inventory and an AI use policy come with it. Every page of that should exist to support a row on the list. If it doesn't, it's padding.

How do you tell a useful assessment from a box-ticking one?

Ask to see the output before you sign. Then ask these:

  1. Can we see an anonymised example of what we'll get? If it's mostly radar charts and a maturity score, keep looking.
  2. Will you talk to the people who do the work? Leadership interviews tell you what people think happens. The process owners tell you what does.
  3. Will you look at our real data and systems? A questionnaire asking "how would you rate your data quality?" gets you a guess with a number on it.
  4. How is the list ranked, and can we change the weights? Value, effort, data, risk and ownership should all count, and you should be able to see how.
  5. Does the first item come with a cost and a timeline? Without one, you finish where you started, with nicer slides.
  6. Are you tied to a platform? If every recommendation runs on the same vendor's product, the assessment was a sales process.

When don't you need an AI readiness assessment?

When you already know the process you want to change and its data sits in one or two systems you control. Skip the assessment and scope a pilot. Assessments are for when you have more ideas than certainty.

Don't commission one if nobody will fund anything on the list in the next two quarters. In our view an assessment has a shelf life of about six months before the systems, the team and the tools have moved on.

Small firms rarely need the formal version. A 20-person practice can get most of the way with a day spent alongside the people who do the work.

And maturity scores aren't useless. They're a fair way to track progress year on year or give a board a benchmark against peers. Put the score in the appendix, behind the list.

What to do next

Before you buy an assessment, write down three processes you think AI could take on. For each one, name who owns it and where its data lives. If you can fill in all three, you may be ready to scope a pilot instead. If you can't, that gap is exactly what an assessment should close, and you now know what to ask for. It's the work our Consulting & Strategy team does, with Data Foundations picking up the rows marked "fix data first".

Get a ranked list, not a score

Bring us the processes you think AI should take on. We'll tell you which one we'd build first, what's in the way of the others, and which we'd leave alone. Book a call

FAQs

Is an AI audit the same as an AI readiness assessment?

The terms overlap, but an AI audit usually means reviewing the AI you already use: which tools, what data they touch, whether they meet your policies. A readiness assessment looks forward at what to build. A good one includes a light audit as part of the risk area.

How long does an AI readiness assessment take?

About six weeks for a mid-sized business looking across several departments, and longer for a group with several business units. Most of the time goes on sitting with the work and opening up real data and systems. If a proposal runs to six months for one business, it's probably assessing the whole company instead of the use cases.

Do we need clean data before we start?

No. Working out which data is good enough for which use case is part of the job. Cleaning everything first is the slowest way to start, because most of it won't be used by the first few builds.

Who needs to be involved?

A sponsor who can fund the first build, the people who run each shortlisted process, whoever administers the main systems, and someone from risk or legal for an hour or two. Leadership interviews alone won't find the work.

Related reading

Sources