An AI readiness assessment for established businesses

An AI readiness assessment tests whether an established business has a worthwhile use case, suitable information, accountable people and the operating controls needed to use AI effectively. The result should be a clear decision about what to pilot, what to prepare and what should remain outside the proposed scope.

Readiness is rarely an organisation-wide yes or no. A business may be ready to test assisted drafting from approved material while being poorly prepared to connect an AI system to sensitive operational records. It may have excellent software but unclear process ownership. It may have a strong commercial idea and no reliable way to evaluate the output.

The useful question is therefore specific: are we ready for this use case, in this part of the operation, with these consequences? This guide sets out a practical assessment for SMEs and larger businesses that already trade, employ people and need improvements that survive beyond a demonstration.

Start with the business outcome

Describe the outcome in terms the organisation can observe. Reduce the time needed to prepare a first draft of a routine proposal. Help staff locate approved product information. Suggest a category for incoming service requests. These statements are easier to evaluate than a broad ambition to become AI-enabled.

Identify the current baseline and the person who owns it. If nobody knows how often the task occurs or how long it takes, the first step may be a short period of evidence gathering. An approximate baseline can still be useful when its limitations are clear; an invented one cannot support a credible investment decision.

Ask whether the outcome needs AI. A structured form, better search, clearer templates or an integration may solve much of the problem. Readiness includes the willingness to choose a simpler approach when it meets the requirement. Otherwise the assessment becomes a justification for a technology decision that has already been made.

Define the use case boundary

State what the system receives, what it may produce and what it may do with that output. Drafting a suggested response is a different use case from sending it automatically. Summarising an approved document is different from giving unrestricted access to every file the business holds.

Name the users, departments, languages and document types included in the first evaluation. If the organisation operates internationally, do not assume success in one language proves suitability everywhere. Terminology, customer expectations and underlying systems can differ even when the interface looks similar.

List exclusions and escalation points. The pilot may exclude contractual commitments, payment instructions or decisions affecting access to a service. A boundary is useful only if the workflow can recognise when it has been reached and route the case to someone with the right authority.

Check the information the task depends on

Identify the source material and the person responsible for its accuracy. A knowledge assistant needs approved, current information; document extraction needs representative examples; a drafting tool needs clear instructions and a reliable way to distinguish a suggestion from an approved record.

Look for conflicting versions, missing fields, ambiguous labels and outdated material. A large document collection is not automatically a useful knowledge base. The organisation needs to know which source wins when two documents disagree and how a correction reaches the system.

Assess access as carefully as content. Staff should not gain indirect access to information they are not permitted to view simply because an assistant can retrieve it. Test the intended permission boundaries with representative roles. Keep an inventory of the sources included in the pilot so later expansion is deliberate rather than accidental.

Understand the process around the model

A model is one component of an operating workflow. Map how a request arrives, what information is supplied, where the result appears and who takes the next action. Identify which stages use fixed rules and which involve interpretation or judgement.

Check whether the existing process is stable enough to evaluate. If different departments use incompatible definitions or nobody can explain the completion condition, introducing AI may make the inconsistency harder to see. Clarifying the process can be a prerequisite rather than a separate administrative exercise.

Include exception handling. What happens when the source is incomplete, the output is unsupported or a connected service is unavailable? The organisation needs a visible queue and a manual route, not a hope that users will notice every problem and invent a workaround when needed.

Give the use case an accountable owner

Someone must be responsible for the business outcome after the pilot team leaves. That owner needs enough authority to involve users, agree the process and decide whether performance remains acceptable. A supplier can support the system, but it cannot replace the organisation's accountability for how it is used.

Separate business ownership from technical administration where appropriate. The person who can change a configuration may not be the person authorised to change the approval policy. Record who approves releases, who reviews incidents and who can suspend the workflow.

Check available capacity. If the proposal relies on staff review, make that workload explicit. If the organisation has no time to maintain source documents or respond to exceptions, readiness is limited even when the technical connection is straightforward. The assessment should identify that resourcing need before it becomes a production problem.

Establish an evaluation set

Collect a representative selection of inputs for the agreed task, using appropriate permissions and data handling. Include ordinary cases, ambiguous cases and meaningful exceptions. The selection should reflect the operation rather than only the examples that make a demonstration look successful.

Define what an acceptable output looks like. For extraction, that might concern correct fields and the handling of missing information. For drafting, it might concern factual accuracy, completeness, tone and whether unsupported statements are introduced. Different dimensions may need different review methods.

Keep some cases separate from configuration work so the final evaluation is not merely a rehearsal. Record the limitations of the sample. A small pilot can establish whether further investment is justified; it does not establish that every possible input will be handled correctly or that performance will remain unchanged indefinitely.

Test how errors will be detected

Ask what the user sees when the system is uncertain or wrong. A polished paragraph and a neat interface can conceal a serious mistake. Useful controls make the source visible, highlight fields requiring attention and make correction or escalation easy.

Do not rely on a confidence-looking number unless its meaning and relationship to actual performance have been established for the task. A score that appears precise can create more assurance than the evidence supports. Evaluate whether reviewers can identify the important failures in practice.

Consider errors of omission as well as incorrect statements. A summary may leave out a condition that changes the meaning of a document. An extracted record may omit a second delivery address. The evaluation should reflect the consequences of those omissions, not just whether the output reads well.

Review data and supplier arrangements

Document which services receive information, what they do with it and which settings apply to the proposed account. Avoid relying on a generic claim that a tool is secure or compliant. The actual configuration, contract and use case determine what needs checking.

Where personal information is involved, involve the organisation's appropriate data protection or legal adviser. Relevant obligations depend on the processing and jurisdiction. The ICO's AI guidance provides a starting point for UK organisations, but a web guide cannot settle the requirements of a particular deployment.

Ask about retention, access, incident reporting, subcontractors and the consequences of switching supplier. Record what is confirmed and what remains under review. Sensitive production information should not be used to resolve an unanswered procurement question through an informal trial account.

Include security in the operating design

Define the minimum permissions the use case needs. A tool that suggests a category does not necessarily need permission to edit customer records or send messages. Separating interpretation from execution can limit the effect of an incorrect or manipulated output.

Treat incoming documents, web pages and messages as untrusted material. A workflow must not assume instructions inside that material are authorised business commands. Test how the proposed system handles requests that conflict with its intended purpose or attempt to obtain information outside the user's access.

Agree how credentials, configuration changes and logs are protected. Logs should help investigate failures without becoming an unnecessary store of confidential prompts and outputs. The assessment should produce practical requirements that the implementation can test, rather than a list of reassuring security adjectives.

Build a credible commercial case

Estimate the complete cost of the pilot and likely ongoing operation. Include preparation, integration, evaluation, licensing, review effort, support and staff training. If the project depends on cleaning a document collection, include that work rather than treating it as a free prerequisite.

Separate released capacity from cash savings. Saving time can be commercially valuable when it enables more work, improves service or avoids a future hire. It does not automatically reduce the current payroll. State how the organisation expects to use the capacity and which benefits can actually be measured.

Test the assumptions. What happens if adoption is lower, exceptions are more common or the review takes longer than expected? A business case that remains useful under cautious assumptions is a stronger basis for a pilot than one that needs every optimistic estimate to be true.

Assess staff readiness through real tasks

Do not reduce staff readiness to whether people are enthusiastic about AI. Ask whether they understand the proposed role of the system, can recognise its limits and know when to escalate. Useful training should use the organisation's actual tasks and foreseeable failure cases.

Invite experienced staff to challenge the design. They may identify language, context or exceptions that a technical team has missed. A concern about losing a useful check is not automatically resistance to change; it may reveal a requirement that should be preserved.

Test the working experience, including correction and recovery. If users must open several systems to verify a small suggestion, the workflow may not be worthwhile. Readiness improves when the team has helped shape a process it can use confidently, rather than being asked to endorse a tool after selection.

Use readiness gates instead of a single score

A broad numerical score can hide a critical weakness. Strong commercial value does not compensate for an unresolved permission boundary. Clean data does not compensate for the absence of a process owner. Identify a small set of conditions that must be met before the pilot progresses.

These could include an agreed use case, an accountable owner, suitable test material, approved supplier arrangements, a manual fallback and defined evaluation measures. Record each as met, unmet or requiring evidence, with an owner and next action. The assessment becomes a preparation plan rather than a certificate.

Where a condition is unmet, ask whether it can be resolved proportionately. The answer may be a narrower pilot, different source material or a conventional workflow. Deferring one use case is not a judgement that the business cannot use AI anywhere; it is a decision about the particular proposal.

What the final assessment should give you

Consider a fictional wholesaler evaluating an assistant for product enquiries. Its approved catalogue is reasonably current, but staff also keep private notes containing old specifications and negotiated customer terms. Giving the assistant access to every folder would create ambiguity about which information is authoritative and who may see it. The business can be ready for a useful pilot without being ready for that unrestricted design.

A narrower first version could use a controlled catalogue, show the source of each suggested answer and require staff approval before a response leaves the organisation. The assessment would still need to test outdated documents, questions outside the catalogue and requests involving customer-specific terms. It would identify who maintains the source and how changes are reviewed. This is an illustrative design exercise, not evidence of a delivered client result.

The readiness decision might therefore be conditional: proceed with a limited internal evaluation after the approved source collection and access arrangements are confirmed. Do not connect private commercial records in the first stage. Measure whether staff can verify the suggestions more efficiently than finding the information themselves, while monitoring incorrect or unsupported answers. Expansion would require a new decision about the additional information and consequences.

That outcome is more useful than describing the business as generally ready or unready. It preserves a worthwhile opportunity while giving the project a boundary the organisation can understand, test and govern. It also makes the preparation work visible to the person authorising the budget, rather than leaving it to emerge unexpectedly after a tool has been purchased.

Expect a concise decision summary supported by inspectable detail. It should state the use case, expected value, material assumptions, readiness gaps and recommended next step. Management should be able to see why a pilot is proposed and what would make it pause.

Ask for an evaluation plan, a preparation backlog and a clear division of responsibilities. Agree whether implementation is included or separately commissioned. A useful assessment should allow the business to make an informed choice about suppliers rather than binding it to the adviser who wrote the report.

Explore 114 Labs AI consultancy if your organisation needs an independent readiness assessment. We work from a specific operating problem, compare credible approaches and help establish the evidence needed for a controlled next step.