AI consulting for businesses: what a project should deliver

In short. Useful AI consulting does not deliver a deck: it delivers decisions taken and documents that stay inside the company after the consultant leaves. Four artefacts separate a solid engagement from a theoretical exercise: an inventory of systems and use cases, a risk assessment for each one, measurable acceptance criteria, and an accountability model naming who decides and who answers for outcomes. Below is the phase by phase table, with the expected artefact, its approver and the criterion that lets the phase close.

Anyone comparing AI consulting proposals runs into the same problem: they all look alike. Every one of them mentions assessment, roadmap, use cases and change management. The difference is not in the wording, it is in what remains in the company at the end. An engagement should be judged by the verifiable objects it produces, because those are the only things that survive a change of vendor, of sponsor or of priorities.

The test that separates a project from a presentation

An artefact is useful when someone can use it to decide without asking its author for an explanation. A prioritisation matrix without explicit criteria is not an artefact: it is a formatted opinion. A risk register with no named owner becomes obsolete within weeks.

Three questions are enough to evaluate any deliverable:

• Who will use it after the engagement ends, and for which decision?
• How is it updated, how often, and by whom?
• What breaks if the answer never arrives: which decision stays blocked?

If a deliverable fails these three questions, its value ends with the final meeting.

Phases and what each must produce

Phase	Decision to enable	Expected artefact	Approver	Closing criterion
Framing	Where it makes sense to intervene	Map of candidate processes with measurable objectives	Executive sponsor	Scope written down, including what is out
Assessment	How ready the organisation is	Picture of data, skills, processes and governance	Sponsor and function leads	Each dimension backed by evidence, not perception
Portfolio	Which use cases to fund	Use cases scored on value, feasibility, risk and data availability	Steering committee	Priorities ordered against written criteria
Validation	Whether the hypothesis holds	Prototype with acceptance criteria defined up front	Process owner	The result states pass or fail
Production	Whether the system can enter official processes	Technical documentation, controls, monitoring plan	Process owner and risk function	Controls live, not planned
Continuity	Who maintains the system over time	Accountability model and review schedule	Executive leadership	Names, frequencies and thresholds assigned

Sequence matters more than duration. Skipping the assessment funds use cases the organisation cannot absorb. Skipping acceptance criteria produces pilots that never close, because nobody defined success before starting.

The four documents that must remain

Inventory of systems and use cases

This is the foundation for everything else. For each system or use case it should record purpose, data used, who uses it, who is accountable, which process it enters and which decision it influences. Without this list you cannot assess risk, and you cannot answer an internal or external clarification request. The same structure later feeds risk management and documentation obligations, so it is worth building once and reusing.

Risk assessment per use case

Risk is not a property of the technology: it depends on use. The same model can be irrelevant in an internal draft and sensitive in a decision affecting people. The assessment should state the type of impact, who can be affected, which controls exist and who supervises. The NIST AI Risk Management Framework organises this work into four functions, govern, map, measure and manage, and is a practical reference because it requires no certification to adopt.

Acceptance criteria

These are the strongest defence against endless pilots. They must be written before work begins and must include the current baseline, the expected result, the measurement method, the sample, the verifier and what happens if the result does not materialise. A workable criterion can be checked by someone other than the person who built the system.

Accountability model

Every production system needs three names: who uses it in the process, who answers for outcomes, and who verifies that it keeps behaving as expected. Without those roles, human oversight remains a stated principle rather than a real control.

How to read a proposal

Concrete questions serve better than price comparison:

1. Which documents will remain in the company, and in what editable format?
2. Who maintains them after the engagement closes?
3. Which criteria decide whether a use case moves into production?
4. What happens if the assessment shows the initial scope is not the best one?
5. Which skills transfer to internal people, and how is that transfer verified?
6. Which part of the work depends on specific tools or licences, and what survives if those change?

The last question deserves particular attention. Consulting tied rigidly to one platform produces results that travel badly when conditions change, and in AI conditions change often.

A hypothetical example

A services company wants to reduce response time to customer requests. A properly framed project does not start from the tool: it starts from the current measurement, for example average response time and the share of requests needing rework. It then defines what improvement means, which error margin is tolerable, who reviews answers before they are sent during the first months, and when that review can be reduced. At the end the company owns a measurement, a criterion, a control and an owner. This example is illustrative and shows the structure; it does not describe an achieved result.

What to avoid

• Detailed twelve month roadmaps drawn before anyone has checked data quality.
• Lists of forty use cases with no selection criteria.
• Benefit estimates without the matching baseline.
• Deliverables provided only as presentations, with no updatable version.
• Governance described as a principle, with no names and no frequencies.

Next step

If you are evaluating AI consulting, start from an honest picture of where you are: what is already in use, on which data, with which responsibilities assigned. You can read our approach on the Services page and in the practical AI adoption framework guide, or begin with a self-assessment of your company.

If you would rather discuss it directly, you can book an assessment meeting: in thirty minutes we clarify scope, constraints and which documents would genuinely help in your case.