AI Readiness Assessment: Free Tool and Evidence Guide

An AI readiness assessment examines whether the conditions needed for a particular AI use are understood and supported by evidence. It connects the business purpose to the current workflow, permitted data, decision ownership, evaluation, operating capacity and cost. The useful result is a defensible next step: investigate a gap, narrow the scope, seek a bounded pilot decision or defer the idea.

Use the interactive checklist above for one proposed use case. It records your own view of the evidence and produces a downloadable Markdown copy. It does not inspect your systems, compare your company with an industry benchmark or authorize deployment. The guide below explains how to substantiate the answers and use them in a decision review.

What does AI readiness mean in practice?

Readiness depends on what the company wants to do. A draft-generation experiment using approved material has different prerequisites from a system that changes customer records or influences consequential decisions. Begin by defining the use, affected people and permitted actions. A broad claim that the company is ready for AI can hide important differences between workflows.

Separate organizational preparation from solution performance. A business may have clear ownership and resources while the proposed system still fails representative evaluation. Conversely, an impressive demonstration can exist without an operating owner or permitted production data. Both kinds of evidence matter, but neither substitutes for the other when deciding what can proceed.

Microsoft's AI Readiness Assessment illustrates the breadth of the topic: its public description covers business strategy, governance and security, data, experience, organization, infrastructure and model management. It is a separate Microsoft assessment with its own questions and recommendations. Our short checklist is an original preparation tool, not a reproduction or validation of that assessment. Source: Microsoft AI Readiness Assessment.

A useful assessment makes uncertainty visible. It can identify what the team knows, what it assumes and what it has not checked. This helps decision owners choose a proportionate next commitment. It should not convert missing information into optimistic scores simply because the organization wants to start a pilot or has already selected a vendor.

How to use the interactive evidence checklist

Choose one workflow before answering. The eight questions cover purpose, current process, data access, source fitness, authority, evaluation, operating capacity and cost. Keep that same scope throughout. If one answer refers to a small internal trial and another assumes a company-wide rollout, the resulting review will not describe a coherent decision.

Select Evidence available only when you can point to material someone can review. Partly documented means relevant work exists but an important part remains unfinished. Not in place identifies an absent prerequisite. Not sure records uncertainty; it is a useful answer when you have not spoken to the relevant owner or inspected the evidence.

Unanswered questions remain separate from reported gaps. You can review an incomplete checklist to see what still needs attention, then change answers as information arrives. The summary updates from your selections. No overall readiness percentage is calculated, and selecting Evidence available for every item still calls for an owner to review the adequacy of that evidence.

Download the checklist to keep a record. Add the use-case description, evidence references, responsible people and review dates locally. The page retains responses only while it remains loaded; reloading resets them. Use the downloadable copy as a working discussion document, not an approval certificate or a substitute for the company's actual decision and change processes.

Define a business outcome before discussing models

Describe the problem in the language of the people doing the work. For example, a support team may spend time locating approved answers across several sources. State the desired change and the current difficulty without assuming that a language model is the only solution. Better source organization or a simpler workflow may address part of the problem.

Identify who benefits and who owns the outcome. A project can save effort in one step while adding review or correction work elsewhere. Include those downstream effects in the definition of value. Ask the sponsor to explain what would make the change worthwhile and what result would lead the company to stop or choose another approach.

Bound the proposed behavior. Record who will use it, which information it can access and whether it recommends, drafts or acts. Include excluded uses that could otherwise be inferred from a broad product description. These boundaries guide data review, evaluation and operating decisions, and make later scope changes easier to recognize.

If the company has several ideas and cannot choose a priority, use the AI strategy consulting guide first. Readiness assessment becomes more useful when the investment question is specific enough to examine. It can then test the prerequisites for the next step instead of becoming a general discussion about the future of AI.

Establish a baseline for the whole workflow

Observe representative examples of how the work happens today. Record the steps, handoffs, delays and exceptions relevant to the intended outcome. Include cases where the process fails or requires specialist intervention. A baseline drawn only from straightforward examples can make a proposed improvement look more reliable or valuable than it is likely to be in use.

Choose measures that fit the decision. Depending on the workflow, useful observations may include time to an acceptable result, correction effort, unresolved cases or consistency against an agreed standard. Explain how each measure is collected and what it excludes. Avoid translating every possible benefit into an invented financial return when the evidence does not support that calculation.

Ask the people doing the work to review the process description. Written procedures can differ from actual practice, particularly around exceptions and informal handoffs. Those differences are relevant to implementation and adoption. Record them without treating them automatically as employee failure; they may reveal constraints the official procedure does not address.

Preserve the baseline and its limits so that later evaluation compares like with like. If the pilot handles a narrower case set or uses different staffing, explain the difference. A reduction in one task's duration does not establish an improvement in the complete workflow if review, support or unresolved-case handling grows at the same time.

Confirm data access and inspect source fitness

Identify the sources needed for the proposed use and the people responsible for them. Confirm the permitted access and handling conditions with the appropriate owners. A technically accessible dataset is not necessarily available for every purpose or product configuration. Record unresolved permissions and dependencies before committing to a delivery plan that assumes they are settled.

Examine representative material for the qualities the workflow needs. Depending on the use, relevant questions may concern completeness, consistency, freshness, definitions and provenance. Focus on the actual task. A source can be useful for one analysis and inadequate for another, so a broad statement that the company's data is clean provides limited evidence.

Look for missing and conflicting information. In a policy-answering workflow, two current-looking documents may disagree. In a reporting workflow, teams may use different definitions for the same business term. Decide who resolves those issues and how the accepted definitions or sources will be maintained. An AI system does not remove the need for source ownership.

Record the result as evidence with limits. State which sources and samples were reviewed and which were not. Avoid presenting a small sample as proof of complete coverage. If the main gap is collection, transformation or delivery of reliable data, scope that dependency using the data engineering consulting guide before treating it as a minor AI configuration task.

Establish decision, security and operating ownership

Name the business sponsor, the person responsible for operating the workflow and the technical owner of the implementation. Identify who can approve a trial, change its scope and pause it. These roles can be held by existing people, but their authority and available capacity should be explicit. An owner listed in a document must be able to perform the responsibility.

Map access and actions around the proposed solution. Consider the source systems, integrations, user permissions and actions available to the workflow. Have the appropriate technical and security reviewers examine the relevant boundaries. This assessment should produce questions and evidence for the actual design rather than declaring the solution secure because the vendor publishes a security page.

Assign privacy, contractual and legal dependencies to qualified reviewers where needed. Record whether a decision is resolved, conditional or still pending. A readiness checklist cannot supply those approvals by itself. Keep material conditions visible in the plan so that a team does not interpret an overall positive assessment as permission to bypass an unresolved requirement.

Use the AI governance consulting guide to connect ownership to approval evidence, changes and response arrangements. Readiness is a point-in-time decision aid; governance maintains those responsibilities as the use evolves. The assessment should identify who will carry the work forward after the initial review or consulting engagement ends.

Define evaluation before selecting a pilot outcome

Write acceptance criteria in terms of observable workflow behavior. For an assistant, a criterion might concern support from approved sources or how it responds when information is unavailable. For another use, it may concern the correctness of a proposed action or the effort needed to review it. Explain the criteria and their consequences instead of relying on an unexplained accuracy label.

Choose representative cases, including difficult or incomplete inputs relevant to the proposed use. Keep track of how the cases were selected and whether the team has repeatedly tuned against them. Where practical, retain additional cases for acceptance review. A demonstration set is useful for showing behavior but can give a misleading picture if it is the only evidence collected.

Evaluate the people and process around the output. Can a reviewer find the necessary context, detect important errors and reject or escalate a suggestion? Is the required time available? Human review is a proposed operating control whose effectiveness needs examination, not an automatic reason to regard the workflow as acceptable.

Define the next decision before beginning the pilot. Record its scope, evaluation method, review point and stop conditions. The pilot should resolve a specified uncertainty. If the team discovers a different use or wants more autonomy, record that as a new scope decision rather than quietly expanding the trial beyond the conditions originally discussed.

Work through an example without hiding a blocker

Consider a hypothetical support team proposing an assistant that drafts responses from approved help articles. The team has a documented purpose and has observed the existing process. It knows who owns the help library, but has not resolved access to some restricted material. This example illustrates assessment reasoning; it does not report client performance or authorize a particular deployment.

Checklist area	Hypothetical evidence status	Next action
Purpose and outcome	Evidence available	Review the documented drafting-only scope with the sponsor
Current process	Partly documented	Include difficult and escalated cases in the baseline
Data access	Not sure	Confirm which material may be used and by whom
Source fitness	Partly documented	Resolve conflicting help articles with their owner
Decision ownership	Evidence available	Confirm who can approve and pause the bounded trial
Acceptance evidence	Not in place	Define representative cases and unacceptable behavior
Operating capacity	Partly documented	Reserve reviewer time and establish the support route
Cost and alternatives	Not in place	Compare total workflow effort with simpler alternatives

The useful result is a set of assigned questions, not an average of the rows. Strong ownership does not compensate for unresolved data access. A clear purpose does not establish acceptable output behavior. The team can investigate those gaps before seeking a decision on a bounded trial, and the sponsor can change or defer the idea if the prerequisites prove impractical.

Suppose source owners later approve a narrower library. The team updates the scope and evaluation cases to match that library. It does not simply change Data access to Evidence available while leaving the rest of the plan unchanged. The narrower source coverage affects what the assistant can answer, which user expectations are reasonable and how missing information is handled.

When the evidence is ready for review, the responsible owners decide whether it supports the proposed next step. That decision may include conditions and limits. The checklist records preparation for the conversation; the actual approval belongs in the organization's decision process with the relevant evidence and authority attached.

Resource the operating work and compare alternatives

List the work required after the first demonstration: source maintenance, evaluation, review, monitoring, user support, changes and incident response as relevant. Identify who will perform each activity and whether the necessary skills and time are available. A proposal that depends on an unassigned person is not a complete operating plan.

Include training and adoption needs in that discussion. People should understand the permitted purpose, important limitations and how to raise a problem. Observe whether the proposed workflow fits how they work. A system can be technically available while employees lack the context or time to use it effectively, particularly when verification adds unfamiliar responsibilities.

Build a cost view that includes implementation and recurring operation. State assumptions about workload, licensing or usage, review effort, support and the continued fallback process. Use ranges or scenarios where evidence is uncertain. A low-cost prototype does not establish production affordability when it has not exercised the expected workload or operating arrangements.

Compare credible alternatives on the same basis. These can include improving the existing process, configuring an available product or limiting the initial scope. The assessment should preserve the reason for choosing the next investment. It should also make a decision to wait understandable when the expected benefit does not justify the unresolved effort or exposure.

Run a focused evidence review meeting

Ask participants to bring the evidence behind their answers rather than only their preferred ratings. Include the people who understand the workflow, sources, technical approach and operating responsibilities. Walk through disagreements one item at a time. If two people interpret Evidence available differently, identify the actual document or observation and decide what further review is needed.

Finish by recording decisions and unresolved conditions in plain language. Name who will obtain missing evidence and who will judge it. Keep a distinction between permission to investigate an idea and permission to expose real users or data to a pilot. Send the resulting plan through the organization’s normal decision process, with the checklist as supporting material rather than a replacement for accountable approval.

Turn the assessment into an evidence review plan

For every unresolved item, record the next question, the evidence needed, a responsible person and a review point. Distinguish information gathering from implementation work. Confirming a permission may require an owner decision; fixing unreliable source data may require a separate engineering task. Treating both as generic readiness improvement makes planning less actionable.

Review-plan field	What to write
Gap or uncertainty	The specific question that prevents a confident next decision
Evidence needed	The observation, document, test or owner decision that would resolve it
Responsible person	Someone who accepts the work and can obtain the evidence
Dependency	The input or authority required before the work can proceed
Review point	When the findings will be discussed and by whom
Possible decision	Proceed within conditions, investigate further, narrow scope or defer

Use the technology roadmap template when the follow-up involves several dependencies. Keep authorized work separate from later possibilities. An assessment should not turn every improvement idea into an immediate commitment. Prioritize the evidence needed for the chosen use and revisit broader ambitions through the normal investment process.

Repeat the relevant parts of the assessment when the purpose, sources, permissions, users or operating arrangements change. Preserve earlier evidence so the team can see what changed and why a decision was revised. The objective is a maintained understanding of the conditions for the next step, not a permanent readiness badge awarded after one workshop.