What is AI consultancy

What is AI consultancy, in practice?

AI consultancy is advisory and engineering work that helps an organisation decide whether, where and how artificial intelligence or automation should change a real business process. In practice, a sound engagement starts with a workflow, not a model or a platform. It asks what triggers the work, what outcome it serves, who owns it and which systems it touches.

The useful distinction is between selling technology and reducing uncertainty. A consultant earns their fee when the organisation knows more precisely what can be automated, what must stay human and how success will be judged. A polished demo can be part of that work. However, a prototype only explains a method. It does not prove a return on investment, time saved or a client result.

What a consultant should hand over before anything is built

The most reliable sign of serious AI consultancy is a bounded discovery output delivered before implementation. It should cover one process and make scope comparable across proposals. That way you judge consultants on clarity, not on enthusiasm or a favourite tool.

Ask for a document that separates what was observed in your environment from assumptions and future options. Some dependencies need personal access, provider approval or business authorisation, and these should be listed openly rather than buried inside a delivery estimate. If an arrow on a diagram cannot be traced to a real interface and an accountable person, that arrow is decoration.

• A workflow map with named owners
• A verified inventory of integrations, not an assumed one
• Data classification and clear boundaries on what may be read
• Permissions defining which actions the system may take
• Human review gates and who staffs them
• Failure cases, with a named recovery owner
• Explicit non-goals
• A measurement plan agreed before launch

Four details that decide whether you can rely on the advice

The first is an explicit business objective. "We need AI" is not an objective. "Reduce manual rework on a named process" is one, especially when you already measure a baseline. Without that anchor, nobody can later tell whether the project worked.

The second and third are controlled data and human review. Know which data the system may read, which actions it may take, and where a person approves, corrects or stops it. Results from these systems shift with the business setting, the tools already in place and the cleanliness of the inputs. Review points are therefore how errors get caught before they reach customers or ledgers, not a formality.

The fourth is production measurement. A test environment flatters. Before launch, agree on what will be recorded once the workflow runs for real, such as volumes, exceptions, corrections and time to recover, and decide who reads those figures. This is what turns a pilot into a system someone can operate.

When good AI consultancy says 'not yet'

An honest first engagement may conclude that part of a process should stay manual. Several conditions can make automation premature: low volume, heavy judgement, unclear ownership, or interfaces that cannot be accessed reliably. That conclusion is a legitimate deliverable rather than a failure, because it protects you from an impressive system nobody can run safely.

Be cautious with a consultant who never recommends restraint. If every discovery ends with the same platform and a larger build, the advice is probably shaped by what is being sold rather than by your process. Asking a consultant to describe a case where they would advise against automating is a quick way to test this.

Example: applying the checklist to a hypothetical request

Example (hypothetical, for illustration only): a finance team asks for "AI to handle supplier invoices". A useful consultant would first narrow this to one trigger, such as an invoice arriving in a shared mailbox. They would then name one owner in accounts payable and list the systems involved, for instance the mailbox and the accounting software.

Discovery might find that extracting invoice fields is a reasonable automation candidate, while approving unusual amounts should stay with a person. The output would list the data the system may read and forbid it from posting payments on its own. It would also define what happens when extraction fails and set a production measure, such as the share of invoices that need manual correction. Only after that would tool choice be discussed.

• Can you name the process owner?
• Can you describe the trigger and the intended outcome in one sentence?
• Have the interfaces been verified rather than assumed?
• Do you know what the system must never do?
• Is there a figure you will track after launch?
• Decision rule for this example: if two or more answers are no, fund discovery rather than implementation.

How to read this guidance

This article is published by Victor Laybats, an engineer in Paris offering AI and automation services. His public material describes work that runs from defining scope through deployment and ongoing follow-up. The guidance reflects that documented approach and the public sources cited. It is not based on a study, competitor testing or reported client outcomes.

Use it as a framework for questioning any consultant, including this one. Your own context, data and constraints should determine the scope. Any claim of results should come with evidence you can check yourself.