An AI readiness checklist is a list of specific checks that establish whether your organisation can run a particular AI use case, covering the data it needs, the tools people can reach, the rules governing both, and who owns the outcome.
The 12 checks below sit under those four areas. Each one can be completed in under an hour by one person with no budget, each has a stated pass and fail, and each changes a decision you are about to make. If a check cannot come back bad, it is not on the list.
That last rule removes most of what appears on published checklists. "Is your data clean, centralised and well governed?" is a reasonable question and a poor check: nobody can answer it in an hour, and no leadership team in history has written "no" beside it. What an ops lead needs on a Monday is 12 things they can go and find out, two or three of which will come back worse than anyone expected.
What makes something worth putting on an AI readiness checklist?
Four rules, and they cut most published checklists to about a third of their length. An item earns its place only if it passes all four.
One person, under an hour. If it needs a workshop, a consultant or a steering group, it is a project rather than a check.
No budget and no procurement. Everything below can be done with the access an ops lead or chief of staff already has.
Capable of failing. There has to be a real answer that reads "no". This is the rule that does the work.
Changes a decision. A fail either stops something, reorders something, or tells you who to go and talk to this week.
The four areas are data, tool access, governance and people, which is the same structure used in what an AI readiness assessment measures. They fail independently. A company can be in poor shape on data and still get real value from putting its people through training next month, because being unready in one area does not hold the other three hostage.
The 12 AI readiness checks
Pick one use case before you start, because readiness is a property of a use case rather than of a company. "Draft first-pass responses to supplier queries" is testable. "Use AI in operations" is not. Every check below is written against that one use case.
1. Can a tool reach the documents your use case needs?
Open the three documents the work depends on and try to select the text. Scanned PDFs, screenshots pasted into slides and spreadsheets with merged cells are where this breaks, and they are far more common in finance and HR than anyone admits.
Pass: you can select and copy the text from all three. Fail: any of them is an image. Changes: a fail moves you to a different first use case rather than to a document conversion project.
2. Is the data current enough to answer with?
Find the most recent record in the source your use case would read, and look at its date. Not the system's launch date, the newest row in it.
Pass: it was updated within the period the work needs, whether that is a day or a quarter. Fail: the last entry is older than the answer would have to be. Changes: a fail tells you the problem is a process nobody maintains, which no tool fixes.
3. Has anyone recorded whether that data is personal data?
Ask whoever holds the record of processing activities whether the source is covered, and whether a data protection impact assessment exists. The ICO's guidance on accountability and governance in AI sets out when a DPIA is required, and processing personal data with new technology usually triggers one.
Pass: someone can name the register and say whether the source is in it. Fail: nobody knows who keeps it. Changes: a fail is a two-week conversation with legal, started now rather than after the pilot.
4. What AI is already inside the software you pay for?
Take the last 12 months of software invoices and mark every product that has shipped an AI feature. Most organisations are already paying for four or five, including ones bought for another reason entirely.
Pass: a written list exists and someone owns it. Fail: nobody has one. Changes: a fail usually removes the need to buy anything for the first use case, which is the cheapest finding on this list.
5. Can the people who need the tool sign in today?
Open the admin console and compare licences bought against accounts that signed in during the last 30 days. Then check which tier those licences are, because features named in a business case often sit one tier up.
Pass: the people doing the work have working accounts on the right tier. Fail: seats are assigned and dormant, or the tier is wrong. Changes: dormant seats are a change and procurement problem, not a skills one, and training them harder will not move it.
6. Does the tool inherit permissions people already have?
Assistants embedded in your existing stack read what the signed-in user can already read. Microsoft states that Microsoft 365 Copilot only surfaces organisational data to which individual users have at least view permissions, so loose SharePoint and Teams sharing becomes a search engine pointed at your own company. Pick one person, sign in as them if you have the rights, and search for a term from a document they should not see.
Pass: nothing sensitive comes back. Fail: anything does. Changes: a fail makes permission remediation the first project, ahead of any rollout, and there is more on that in the Copilot readiness checks.
7. Who can approve a new AI tool, and how long do they take?
Submit a real request for a real tool and time it. This is the least glamorous check here and the one that most often turns out to be the binding constraint.
Pass: a named person, and a response time you can state in days. Fail: "it goes to the leadership team", which means it goes nowhere in under six weeks. Changes: a fail means the approval route gets fixed before the pilot, or the pilot waits on it.
8. Can three people in different teams tell you what must never go into an AI tool?
Ask them. Do not send them the policy first. You are testing whether the rule is known, not whether it is written, and those are different questions with different fixes.
Pass: all three give broadly the same answer. Fail: you get three answers, or three shrugs. Changes: a fail is a communication job rather than a drafting job, and the sections an AI policy needs are only useful once people can recite the one that matters.
9. Where does someone report an AI mistake?
Ask the person most likely to make one. An error that reaches a customer needs a route that exists before it happens, and an AI-specific route rather than a general IT ticket, because the triage is different.
Pass: a named route someone can describe. Fail: silence, or "I suppose I'd tell my manager". Changes: a fail is an hour of work to fix and the cheapest risk reduction available to you.
10. Is there a named owner, or a committee?
Write down the one person who can approve spending on this and stop it if it is not working. A single name, not a group.
Pass: one name with both powers. Fail: a steering group, a working group, or a name with the authority to start but not to stop. Changes: without an owner there is no programme, only an intention, and every other item on this list will wait on a meeting.
11. Can anyone in the organisation build and deploy an automation?
Ask whether a named person could build a working automation in a tool like n8n, Power Automate or Zapier and put it into production this month. Not whether they could learn to; whether they could now. This is where most organisations find out how thin that layer is: asked how much of their workforce can build with AI, 75% of 500 UK AI decision makers surveyed by ivee in August 2026 say either that they have no idea, or that fewer than 1% of their workforce knows how to build and deploy an AI automation.
Pass: you can name the person and the last thing they shipped. Fail: you cannot name anyone, or the honest answer is "no idea". Changes: a fail sets the shape of the first use case, because assistive work needs nobody to build anything while automation does.
12. Do you have a before number?
State today's figure for the work you want to change: hours per week, items per month, days to turn something round. One number, written down, before anything starts. Most organisations skip this and then cannot answer the only question the board asks six months later. It is the same gap 500 UK AI decision makers described when asked about proving AI ROI in August 2026: 96% cannot show the numbers on their organisation's AI spend.
Pass: you can state the number and where it came from. Fail: you would have to estimate it. Changes: capture it this week, because it is unrecoverable later. If you want a rough sense of what the time saved would be worth annually, the AI training ROI calculator turns hours saved per person per week and team size into a figure.
How long does this take, and who needs to be there?
Two working days, spread across a fortnight, for one person with a bit of organisational standing. The checks themselves take under an hour each; the waiting is what stretches it, particularly checks 3 and 7, where you are timing somebody else's response on purpose.
One person should run it, not a group. You need 20 minutes each from whoever administers your main software estate, whoever holds the record of processing activities, and one person who does the work the use case would change. A chief of staff or ops lead is the right owner. A committee is not, for the reason set out in check 10.
What do you do with the items that fail?
Sort them into blockers and costs, then act only on the blockers before the pilot. A fail on check 6 stops a rollout, because you would be publishing your own files to your own staff. A fail on check 2 does not stop anything; it tells you which use case to pick instead.
Resist the urge to convert 12 results into a single percentage. A score of 75% hides which three failed, and the identity of the failures is the entire output of the exercise. Two organisations scoring the same can have completely different problems and completely different next moves.
Expect two or three fails. A clean sheet almost always means the checks were answered from memory rather than run, and a checklist scored so that nobody fails is a lead magnet wearing a clipboard.
What an AI readiness checklist cannot tell you
It cannot tell you whether the use case is worth doing. That is a judgement about value, effort and appetite, and no check produces it. You can pass all 12 and still have picked work that saves four minutes a fortnight.
It also will not tell you how good your people will get, or how long that takes. Readiness describes the conditions; capability is measured separately and improves on a different timescale.
One disclosure, since it affects how you read the above: ivee sells AI training and runs readiness diagnostics, so we have an interest in you concluding that this is worth doing properly. The counterweight is that all 12 checks above are free, need nobody from outside, and several of them will tell you that your first move is a permissions fix or a conversation with legal rather than anything we sell.
FAQs: AI readiness checklists
How to assess AI readiness?
Pick one specific use case, then check four areas against it: whether the data it needs is reachable and current, whether the people who would use the tool can sign in and at what permission level, whether there is a known rule and an approval route, and whether one named person owns the outcome. Assessing readiness in general, without a use case, produces a document rather than a finding.
What does AI readiness mean?
AI readiness means the conditions for a specific piece of AI work are in place: the data is reachable, the tools are accessible and appropriately permissioned, the governance exists and is understood, and someone is accountable. It is not a measure of how advanced an organisation is, and it is not a score. A company can be ready for one use case and unready for the next.
What is the 10/20-70 rule for AI?
It is BCG's rule of thumb for where value in an AI transformation comes from: 10% from the AI application itself, 20% from the underlying data and technology, and 70% from workflow redesign, culture, governance and human-AI collaboration. For a readiness checklist the implication is direct. Nine of the 12 checks above are about permissions, rules, ownership and process rather than about the model, and that ratio is not an accident.
How to conduct a readiness assessment?
Run the checks yourself first, then bring people in for the ones that failed. Give each check a stated pass and fail before you start, so a result cannot be talked into being fine, and write down the evidence rather than the opinion. Collecting views in a workshop produces consensus, which is not the same thing as a finding and is considerably harder to act on.
Run the three you suspect will fail
Most people reading this already know which two or three items will come back badly. Start there, because confirming a suspicion in an hour is worth more than a full pass that took a fortnight. If what comes back is a mess, or you cannot tell whether a fail is a blocker or a cost, book a call with ivee and we will work through the results with you.
