
Your board meeting is in six weeks and one director has already asked, twice, what the company is doing about AI. Your CFO wants to know what it will cost. Your head of engineering says the data is “mostly fine.” Your operations lead has signed up for three AI tools on a company card. Nobody can tell the board, with evidence, what the company is ready to do.
An AI readiness assessment gives you that answer. It is a structured review of your strategy, data, infrastructure, skills and governance that shows which AI projects your company can support today, which gaps would cause a pilot to fail, and what to fix first. The output is a short list of decisions with owners, not a score to frame on the wall.
Below you will find a self-assessment checklist you can use with your leadership team, a simple way to score it, and what to do at each maturity level once you have your results.
What an AI Readiness Assessment Should Tell You
A useful assessment ends with three things. The first is a readiness level for each of the five areas, backed by evidence rather than opinion. The second is a list of launch blockers, the gaps serious enough to stop a project regardless of how strong everything else looks. The third is a recommended next step: foundation work, a focused pilot, or scaling something that already works.
Be clear about the scope before you start. You can assess the company as a whole, or you can assess readiness for one specific use case, such as summarizing support tickets or forecasting inventory. Company-wide reviews are good for planning budgets and hiring. Use-case reviews are better for deciding whether to approve a particular project, because a company can be ready for one idea and far from ready for another. Many teams do a light company-wide pass first, then a closer look at their top two or three candidates.
It also helps to separate readiness from a few related terms. An AI strategy decides where AI fits in your business goals. An AI audit reviews systems already in use. Readiness sits between them: it asks whether your foundations can support the strategy before you spend money building.
The AI Readiness Checklist
Work through each area with the people who own it. For every item, mark yes, partly or no, and write down the evidence. “Our CRM data is clean” is a claim. “We sampled 300 records and 12% were missing an industry field” is evidence. If nobody can produce evidence, mark the item no.
Strategy
- We have named two to five business problems where AI could help, each with a cost or revenue figure attached.
- Each candidate use case has an executive sponsor who will defend its budget.
- Each use case has a baseline metric we already track, such as handle time, conversion rate or error rate.
- We know which AI capabilities we will buy, which we will configure and which we might build.
- Leadership agrees on what level of risk is acceptable for customer-facing AI.
- AI plans are part of the product or operating roadmap, not a separate innovation budget.
Data
- We know where the data for our top use cases lives and who owns each source.
- We have checked a real sample of that data for gaps, duplicates and outdated records.
- We have confirmed that we are permitted to use the data this way, given what customers and partners were told when it was collected.
- Sensitive data (personal, health, financial) is labeled and access is restricted.
- Data can move between systems through reliable pipelines rather than manual exports.
- Someone is responsible for data quality as an ongoing job, not a one-off cleanup.
Infrastructure
- The systems AI would read from and write to have documented, stable APIs.
- We can control what an AI service can access through roles and permissions.
- We have estimated cost per request at current and expected volumes.
- We know what happens to the user experience if an AI service is slow or unavailable.
- Logging and monitoring can capture AI inputs, outputs and actions.
- Our architecture could add AI features without a major rebuild, or we know what would need to change.
Skills
- We have, or can hire or contract, people who can integrate AI services into our products and systems.
- We have someone who can design tests for AI output and judge whether quality is good enough.
- Subject experts are available to review outputs in their area, such as legal, clinical or financial content.
- A product owner can manage an AI feature like any other product, with a backlog and success metrics.
- Staff who will use AI tools have had training on what the tools do well and when to override them.
Governance
- A named group approves new AI use cases and reviews their risks.
- We have a written policy on which AI tools staff may use and what data they may put into them.
- High-impact outputs and actions have a human review step.
- We can explain to a customer or regulator how an AI-assisted decision was made.
- Someone can pause or switch off an AI system, and knows how.
- Legal and compliance advisors have reviewed the rules that apply in our sector and markets.
For governance, the NIST AI Risk Management Framework is a widely used, free reference. Its four functions (govern, map, measure, manage) give your team shared language for risk without forcing a rigid process. It is a starting point, not legal advice, so involve your own advisors for anything regulated.
How to Score Your Results
Give each area a level from 1 to 4 based on the checklist and the evidence behind it.
| Level | What it looks like | Typical evidence |
| 1. Exploring | Interest and ideas, little in place | Vendor demos, informal tool use, no owners |
| 2. Building foundations | Some work underway, clear gaps remain | Partial data inventory, draft policy, one sponsor |
| 3. Ready to pilot | Basics in place for a controlled test | Sampled data, approved use case, review process, budget |
| 4. Ready to scale | Pilots have proved value and are monitored | Results against baseline, monitoring, trained users |
Two rules keep the scoring honest. First, score each area separately and resist averaging them into one number. A company with strong strategy and weak data should be treated as blocked on data, whatever the average says. Second, agree on launch blockers before you score. Common blockers include having no permission to use the data, no named owner, no way for users to correct or escalate an output, and no plan to monitor results after launch. Any blocker overrides every other score for that use case.
Watch for optimism as well. Teams tend to rate their own area generously, so ask a second person to check the evidence for any area scored 3 or 4. If you want an outside view, M7’s AI consulting team runs scalability and architecture evaluations and AI risk and compliance analysis, which gives you an independent read on the infrastructure and governance areas, where self-scoring is hardest.
What to Do at Each Maturity Level
Your lowest-scoring area usually decides your next move. Here is how to respond at each level.
Level 1: Exploring
Your job is to turn interest into a short, ranked list. Hold a working session with department heads to collect use case ideas, then score each one on business value, feasibility and risk. Pick two or three for a closer look.
At the same time, put a basic AI use policy in place, because staff are almost certainly using public AI tools already. The policy should say which tools are approved and what data must never go into them. Resist the pull to buy a platform at this stage; you do not yet know what you need it to do.
Level 2: Building foundations
Most companies land here, and it is the level where spending on the right foundation work pays back most. Fund the specific gaps the checklist exposed for your top use case, not a general “data transformation” program. If the use case needs clean customer records, clean those records. If it needs an API your CRM does not expose, build or buy that connection.
Name an executive sponsor and a product owner now, and capture baseline metrics so a future pilot has something to beat. This is also the time to train the people who will use the first AI tools, so the pilot is not their first contact with them.
Level 3: Ready to pilot
Run one pilot with a small group of users, a clear start and end, and success criteria you wrote down in advance. Choose a use case where a person reviews the output, such as drafting replies or summarizing documents, so mistakes stay internal while you learn.
Plan for about 90 days. Spend the first month setting up, testing against real examples and briefing users. Spend the second running the pilot with weekly reviews. Use the third to compare results with your baseline and decide whether to expand, change or stop. Write down your stop conditions before you begin, which makes that final decision much easier.
Treat the pilot as a product, with user research and design, not only an engineering task. If people do not trust the output or cannot fit it into their day, the numbers will not move however good the model is. Our article on enterprise AI UX strategy covers how to design for trust and adoption.
Level 4: Ready to scale
Scaling brings new problems: costs that grow with usage, more edge cases, model updates from vendors, and more people relying on the output. Before widening access, confirm that monitoring tracks quality as well as uptime, that someone reviews a sample of outputs every week, and that you retest whenever a vendor changes its model.
This is also the point to document how each AI system works, what data it uses and who owns it. That documentation makes audits, staff changes and new use cases far easier. Then return to your ranked list and run the next use case through the checklist, using what the first pilot taught you.
Common Mistakes in AI Readiness Assessments
Treating it as a survey. Sending a questionnaire to department heads produces confident answers and little evidence. Pair every answer with a data sample, a system check or a conversation with the people who do the work.
Assessing the company but not the use case. “We are a 3 on data” means little until you ask, data for what? Readiness for an internal search tool and readiness for automated credit decisions are very different questions.
Ignoring the people who will use the tool. Frontline staff know the edge cases and the workarounds. They also decide whether a tool gets used. Watching them do the task today, using methods from a usability testing process, often reveals more than any interview with their managers.
Letting the assessment become the project. A readiness review should take weeks, not quarters. If it turns into a long report with no decisions, it has failed. Keep the final output to a few pages, and lead with blockers and recommended next steps.
Skipping the reassessment. Readiness changes as you fix gaps and adopt new tools, and as regulations change. Run the checklist again before each major new use case and at least once a year.
Turn Your AI Readiness Assessment Into a Plan
The value of an assessment is in the decisions that follow it: which use case to try first, which gaps to fund, and who owns each one. A modest pilot that works will build more support for AI inside your company than an ambitious one that stalls on data or trust.
If you want help turning your results into a plan, M7 develops AI-driven roadmaps that sequence foundation work and pilots, and can automate documentation of the systems and decisions involved so your team keeps a clear record as you scale. Talk to our team about where your assessment landed and what to tackle first.
Frequently Asked Questions
Can we run an AI readiness assessment ourselves?
Yes. A small cross-functional group can work through the checklist above in a few working sessions, plus time to sample data and check systems. Outside help is most useful when you lack people who can judge AI quality or architecture, or when internal politics make honest scoring difficult.
How long does an AI readiness assessment take?
A focused review of one or two use cases usually takes a few weeks, depending on how quickly you can get data samples and schedule time with system owners. A company-wide review takes longer because more teams and systems are involved.
Who should be involved?
Include an executive sponsor, the owners of the relevant data and systems, someone from security or IT, legal or compliance where relevant, and people who do the work the AI would affect. Leaving out the last group is the most common gap.
Do we need to be at level 4 everywhere before using AI?
No. Many useful pilots can run at level 3 in the areas that matter for that use case. What matters is that there are no launch blockers for the specific project and that the risk of a wrong output is matched by human review.







