AI Readiness Assessment for a Small Business

An AI readiness assessment is a structured review of a business objective, workflow, data, software, risk and team capacity. Its purpose is to recommend a sensible next decision, not to award the company a generic maturity score.

For a small business, the useful question is rarely “Are we ready for AI?” as a whole. A business can be ready to automate document classification and not ready to let an agent update financial records. Readiness belongs to a specific use case.

The OECD SME AI Readiness Tool reflects this broad view by asking about digital foundations and AI use across business functions. The SAS AI readiness research for small and midsize businesses also frames readiness across strategy, governance, data, skills, processes and measurement. These are useful lenses, but an implementation decision still needs workflow-level evidence.

What should the assessment answer?

A commercially useful assessment should make five decisions easier:

1. Which workflow is worth improving first?
2. Where can AI add value that normal automation cannot?
3. What dependencies must be resolved before a pilot?
4. What can go wrong, and where must a person remain responsible?
5. How will the business know whether the change helped?

If an assessment produces only a long list of tools, it has not answered those questions.

Start with the business objective

“Use AI” is not an objective. Reducing time spent locating an approved policy, routing enquiries to the right owner or extracting fields from supplier documents can be.

Write the objective in observable language:

• Who experiences the problem?
• How often does it happen?
• What happens today?
• What delay, error or cost does it create?
• What outcome would be meaningfully better?
• Which outcome must not occur?

Do not invent a financial return before the baseline and implementation cost are understood.

Review the workflow, including exceptions

Most process diagrams describe the happy path. AI implementation fails in the exceptions: missing information, ambiguous language, conflicting records, unavailable systems and users who bypass the intended process.

Map:

• the trigger
• inputs and their formats
• current decisions
• handoffs
• approvals
• common exceptions
• systems of record
• final responsibility

A broken process does not become reliable because an AI model is placed inside it.

Decide whether AI is necessary

Use ordinary automation when the input is structured, rules are stable and outputs must be predictable. Use AI when constrained interpretation, classification, summarisation or natural-language interaction provides clear value.

Many dependable systems combine both:

• rules validate required fields
• AI interprets unstructured text
• rules route low-risk cases
• a person reviews uncertain or consequential cases
• the system records the action

This design is often less exciting in a demo and more useful in operation.

Examine data and access

An AI system cannot safely use “all company data” as a vague requirement. Identify the authoritative sources, content owner, sensitivity, access rules, update frequency and retention needs.

Questions include:

• Are examples representative of real work?
• Is the source accurate enough for the decision?
• Can the system access it through a supported method?
• Should every user see the same information?
• Can personal or confidential data be minimised?
• What happens when the source changes?

Data readiness is not only cleanliness. It is also ownership and permission.

Plan human oversight

The appropriate level of oversight depends on the consequence and reversibility of an action. The OECD AI Principles include human-centred values, transparency, robustness and accountability. The NIST AI Risk Management Framework organises ongoing work around governing, mapping, measuring and managing risk.

For a small-business workflow, translate those ideas into practical controls:

• tell users when AI is involved where relevant
• limit tool and data access
• require approval for high-impact actions
• show sources for knowledge answers
• record actions and changes
• define escalation
• test before and after release
• assign a business owner

The framework does not need to be bureaucratic. It needs to be explicit.

Assess team readiness

Users need more than a launch demonstration. They should understand what the system does, what it does not do, how to review output, how to report a problem and who owns the next decision.

Look for:

• an accountable business sponsor
• a workflow owner
• users available for interviews and testing
• agreement on acceptable change
• capacity to update documentation and source content

Resistance can be rational if the system changes responsibility without explaining accountability.

Define measurement before building

Select measures that fit the workflow. Possible examples include time to route a request, percentage of outputs requiring correction, unanswered knowledge questions, exception rate, adoption and cost per completed process.

Do not optimise one metric at the expense of the actual outcome. Faster replies are not better if they are inaccurate or sent without the necessary approval.

Record the baseline where possible. If no baseline exists, the pilot may need an observation period.

How should opportunities be prioritised?

Score each candidate on:

• business relevance
• frequency and friction
• quality and accessibility of inputs
• integration feasibility
• consequence of error
• reversibility
• stakeholder readiness
• ability to measure
• ongoing ownership

The highest-value idea is not always the best first pilot. A smaller use case may prove the delivery model, reveal system constraints and create reusable components.

What should the output contain?

A useful assessment can produce:

• an opportunity map
• prioritised use cases
• readiness gaps
• a recommended pilot
• expected dependencies
• risk and human-review requirements
• a staged implementation roadmap
• assumptions that still need verification

It should also say what not to automate.

A simple readiness test

You may be ready for a pilot when you can name the workflow owner, representative inputs, current baseline, systems involved, approval boundary and success measure.

If those are unclear, the first engagement should resolve them before development begins.

Review WebMastra’s AI readiness assessment or describe your current workflow.