Is your business ready for an AI project? Questions before you invest

A convincing AI demonstration can leave a director with an awkward decision. The technology appears capable, but it is still unclear whether using it will improve the business.

An AI readiness assessment should help you make that decision for a particular process. It needs to establish what is worth testing, what has to be prepared first and what evidence would justify further investment.

You do not need a company-wide maturity score to begin. Choose one piece of work, involve the people who do it and examine the conditions under which a change would be useful.

Name one process and its owner

“Use AI in customer service” is too broad to assess. “Draft a response to an incoming product enquiry using approved product information, for a member of the team to review” gives you something to examine.

That example is illustrative, not a client result. It identifies an input, an output and a person who remains responsible. It also leaves room to decide whether drafting is actually the part of the process that needs help.

Walk through the current work from start to finish. Find out where staff wait for information, repeat a task or correct an earlier mistake. Speak to the people dealing with exceptions, not only the person who designed the process.

Appoint a business owner who can answer questions, make scope decisions and judge whether the result is useful. A technical trial without that involvement can prove that a model produces output while leaving the operational question unanswered.

Measure the current work before estimating a saving

Record a representative sample of the process as it works today. Useful measures might include handling time, waiting time, corrections, cases escalated and work left unfinished.

Be specific about what you measure. If a response takes an hour to reach a customer, that could include five minutes of writing and a long wait for approval. Faster drafting would affect only part of the delay.

Include variation. Straightforward enquiries, incomplete requests and unusual cases may have different costs and consequences. A trial that only includes the easiest examples will tell you little about the support burden after launch.

Use the baseline to write a testable aim. For instance, a proposed trial might try to reduce total handling effort while preserving the team's agreed standard for factual accuracy. Set the actual threshold with the people accountable for the process; do not borrow a generic productivity percentage.

Check whether the problem needs AI

Some work is repetitive because systems do not exchange information. Other work follows stable rules but lacks an automated step. An integration, a better form or conventional automation may solve those problems without asking a model to interpret anything.

In our work with Concordia, we used browser automation to move application information into a system that did not provide the API we needed, then synchronised the resulting sponsorship numbers. That was a conventional automation project. It should not be presented as evidence of AI performance.

For your process, identify the judgement or interpretation you think an AI system would provide. If you cannot name it, examine the simpler alternatives first. If you can, define where that judgement starts and ends.

Establish what information the system may use

A trial needs representative information that the team is authorised to use in the proposed setup. Identify its owner, how it is kept current and whether access depends on a person's role.

For the product-enquiry example, old product sheets and contradictory internal notes could make review difficult even before a model is introduced. Establish which source takes precedence and who resolves a conflict.

Ask your security and privacy colleagues to assess the proposed handling of the information. Include where it would be processed, who could access it, what would be retained and how it would be removed. Resolve those questions before moving real customer or staff information into a trial.

Record gaps plainly. Missing permissions, incomplete records or an unreliable source do not become acceptable because a demonstration used a neat sample. They are preparation work, and may change whether the idea is worth pursuing.

Decide what an incorrect result would mean

List the mistakes you need the trial to expose. A draft might invent a product feature, use an obsolete policy, reveal information to the wrong person or confidently answer an enquiry that should be escalated.

For each type of mistake, decide how it would be detected, who would deal with it and what consequence is unacceptable. Define what the system should do when information is missing or contradictory.

“A human will check it” needs its own plan. The reviewer needs enough context, time and authority to reject a result. Measure that review effort. If checking an answer takes longer than writing it, faster generation has not established a saving.

Our internal Watchkeeper project illustrates a deliberate limit on authority. It reviews server evidence and alerts the team, while changes to the server and its expected baseline remain human decisions. It is an internal operating example, not a claim that AI can certify security or independently run a customer's infrastructure.

Design a trial that can change your mind

Write the decision criteria before choosing the best-looking outputs. Use examples that represent the intended work, including difficult cases and cases where the correct response is to ask for help.

Reserve some examples for evaluation instead of using every example to refine the setup. Have people who understand the process assess the result against the agreed criteria. Record corrections and failures as well as successful outputs.

Keep the first trial within a scope where mistakes can be reviewed before they affect customers or business records. State the actions it may take and the access it needs. More autonomy can be considered later, with evidence about the additional risk and benefit.

A successful trial supports a further decision. It does not by itself establish that a live service will cope with every workload, supplier change or exception.

Include the work after the demonstration

Before approving implementation, identify who would maintain source information, investigate failures, monitor quality and manage supplier changes. Include integration work, user training and the process for turning the feature off or falling back to the existing workflow.

Estimate costs around the actual expected use. Model charges are only one part. Review time, support, data preparation and integration may materially affect the case for proceeding. Keep uncertain assumptions visible so a cheap trial does not quietly become an open-ended operating commitment.

If the opportunity remains worthwhile, our AI consulting and automation work can help assess those practical dependencies and the options for implementation.

A checklist for the investment decision

Use this as a working record for one proposed use case. Write an answer and a named owner for each item. It is a suggested assessment structure, not a certification or a numerical readiness score.

1. What task would change, and who owns the result?
2. What does the current process cost in effort, delay and corrections?
3. Why might AI help, and which simpler alternatives have been considered?
4. Which information may be used, and who maintains and approves it?
5. What could go wrong, and which consequences are unacceptable?
6. Who would review the output, and how will their effort be measured?
7. Which examples and criteria will determine whether the trial succeeds?
8. What integrations, support and ongoing costs would follow a successful trial?
9. Who decides whether to proceed, narrow the scope or stop?

For broader risk-management work, NIST's AI Risk Management Framework is a voluntary reference for considering trustworthiness through the design, use and evaluation of AI systems. The checklist above is our proposed practical starting point for this buying decision, not an implementation of the full framework.

Proceed, prepare, narrow the scope or stop

Proceed to a bounded trial when the task, owner, information and decision criteria are clear enough to test. Prepare first when access or the baseline is missing. Narrow the scope when a useful part of the process can be evaluated with less risk or effort.

Stop when the likely benefit cannot justify the review and operating work, the necessary information cannot be used, or a simpler change addresses the problem. Reaching that conclusion before a large implementation is a useful result.

If you have a process in mind, discuss an AI assessment with us. Bring an explanation of the work and its constraints; do not send sensitive records with an initial enquiry. We can agree what evidence is needed and how to examine it before proposing the next step.