Scalexa Consulting / practical guide

AI Readiness for UK Founders: What to Assess Before Commissioning AI Work

AI work is easier to commission well when the business can explain the problem, the evidence available and the decision it wants to improve. This guide is an earlier step than an AI platform risk audit: it helps UK founders decide whether the right next move is process improvement, data preparation, bounded discovery or a production engagement. It is also different from the fractional CTO question, which is about the need and shape of senior technology leadership.

Start with the business need, not the AI solution

Begin with the customer or business problem that needs attention. Describe the people affected, the workflow where the friction appears, the outcome that should improve and the cost of leaving the situation as it is. “We should use AI” is not yet a commissioning brief; “this part of the service takes too long, creates avoidable rework and limits the team’s capacity” gives a partner something to investigate.

Keep the proposed technology open while you clarify the need. The answer may be a process change, better search, a conventional software feature, a data clean-up or an AI-assisted workflow. A useful early conversation tests whether there is a valuable decision or task to improve, rather than treating an AI solution as the outcome.

Make the problem concrete

  • Which customer, team or business outcome is under pressure?
  • Where in the current workflow does the problem occur, and who owns it?
  • What would be different for the people involved if the problem improved?
  • What is the cost, delay or missed opportunity of doing nothing for now?

Define what success would need to look like

Set decision criteria before choosing a model, supplier or implementation approach. Decide which signals would show useful progress, what level of quality is acceptable, how much human review is expected and which constraints cannot be traded away. These criteria do not need to be perfect, but they should be specific enough to compare a proposed approach with the current process.

Include the outcomes that would make the work unacceptable. Consider accuracy, consistency, speed, cost, explainability, privacy, security, user experience and operational effort in the context of the use case. A bounded experiment becomes more useful when the team knows what it is trying to learn and what evidence would justify continuing, changing direction or stopping.

Agree the decision criteria

  • Which measurable or observable signals would show that the business problem is improving?
  • What quality threshold, human review or fallback is needed for the workflow?
  • Which budget, time, privacy, security, integration or operational constraints apply?
  • What result would mean the proposed approach should be changed or stopped?

Assess data readiness

Review the data the proposed work would need before assuming it is ready. Establish who owns it, where it lives, how access is granted, what its provenance is and whether the structure and quality match the task. Look for missing fields, inconsistent definitions, stale records, duplicates, unrecorded decisions and important context that exists only in people’s heads or disconnected systems.

Also make the handling conditions visible. Identify permissions, personal or confidential information, retention expectations, security controls, supplier boundaries and the work required to make the data usable. “We have lots of data” is not the same as having a reliable, accessible and appropriately governed source for evaluation or day-to-day use. If the evidence is not ready, data foundations may be the right next step.

Test whether the data can support the work

  • Who owns the data, who can grant access and who is accountable for its use?
  • Can the source, meaning, quality, freshness and structure of important fields be explained?
  • Which permissions, privacy, security, retention and supplier decisions apply?
  • What preparation, integration or data-quality work is needed before evaluation can be credible?

Useful next reads

Assess people, process and operational readiness

An AI workflow still needs people who own the outcome and a process that can absorb the change. Identify the accountable business owner, the users who will work with the output, the person responsible for technical decisions and the people who can review, correct or pause the workflow. Check whether the proposed change fits how work is actually done, including exceptions and hand-offs.

Look beyond the first build. Integration constraints, monitoring, support, training, review effort and ongoing ownership affect whether a useful prototype can become a dependable service. If nobody has capacity to operate the result, investigate the process or ownership gap before committing to a larger delivery scope. The question is not only whether a system can be built, but whether the organisation can use and improve it responsibly.

Check the operating conditions

  • Who owns the business outcome, technical decisions, human review and ongoing operation?
  • Where will the workflow fit, and what exceptions or manual hand-offs must it support?
  • What integrations, monitoring, support, training and change capacity are available?
  • Who can review performance, respond to problems and decide whether the approach should continue?

Useful next reads

Choose the smallest useful next step

The right next step may not be an AI build. A no-AI process improvement can remove the underlying friction; data foundations can make a later evaluation possible; and a discovery engagement can clarify the problem, options and evidence without pretending the answer is known. A bounded pilot can test a narrow workflow with explicit measures, while a production engagement is appropriate only when the use case, operating conditions and ownership justify building for sustained use.

Choose the smallest step that can change the decision. State what it will examine, what access it needs, what it will produce and which result would move the business forward. Evidence from a pilot should answer a business question, not merely show that a demo can generate an output. A useful result may be permission to proceed, a better-defined scope, a data workstream or a well-supported decision not to continue.

Match the step to the uncertainty

  • Use process improvement when the main constraint does not require AI to change.
  • Choose data foundations when ownership, access, quality or structure is the main unknown.
  • Use discovery or a bounded pilot to test a specific question with agreed evidence and limits.
  • Move towards production only when the workflow, ownership, evaluation and operating path are ready to support it.

Useful next reads

Prepare a better brief for an AI partner

A partner can make better decisions with a brief that separates what is known, what is assumed and what is still open. Describe the problem and intended users, the current workflow, the data sources and access conditions, the constraints, the outputs you need and how success will be evaluated. Include the people who can answer questions and the person who owns the business decision.

Be clear about the delivery boundary. Ask what the proposed work will and will not cover, what it needs from your team, what evidence it will leave behind and how the next decision will be made. This keeps a first conversation focused on fit and learning rather than allowing an attractive technical possibility to become an undefined commitment.

Include these commissioning questions

  • What problem, users, workflow and business outcome are in scope?
  • What data, permissions, constraints, integrations and internal capacity are available?
  • What outputs, evaluation method, ownership and decision criteria should the work produce?
  • What is explicitly out of scope, what remains open and what would change the recommendation?