---
title: "AI consulting for businesses: what a project should deliver"
url: https://zerofive.ai/en/blog/strategy/ai-consulting-what-a-project-delivers
canonical: https://zerofive.ai/en/blog/strategy/ai-consulting-what-a-project-delivers
language: en
published: 2026-09-11
updated: 2026-09-18
author: "ZeroFive.AI"
tags: AI consulting, AI adoption, AI governance, AI assessment
abstract: "The documents an AI consulting engagement must leave behind: inventory, risk assessment, acceptance criteria and accountability, phase by phase."
---

# 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](https://www.nist.gov/itl/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](/en/services) page and in the [practical AI adoption framework guide](/en/blog/strategy/ai-adoption-framework-practical-guide-enterprises), or begin with a [self-assessment of your company](/en/start-ai-rating).

If you would rather discuss it directly, you can [book an assessment meeting](https://calendly.com/fabiolalli/zerofive): in thirty minutes we clarify scope, constraints and which documents would genuinely help in your case.