Consultant requirements

What consultant requirements actually cover

When a business team starts evaluating an AI or automation project, 'consultant requirements' usually means two different things at once: what the consultant needs from you to do the work properly, and what you should require from the consultant before letting them near your systems and data. Both matter, and conflating them is a common source of disappointment.

This article focuses mainly on the second sense, because that is where executives have the most leverage and the least experience. A consultant who cannot articulate their own requirements clearly, or who accepts a vague brief without pushing back, is itself a signal worth noting.

Start with an explicit business objective, not a technology wish list

A frequent failure mode is commissioning a project defined by a tool ('we want a chatbot', 'we want to automate emails') rather than by an outcome the business actually needs. A consultant worth hiring should push back on vague briefs and ask what measurable change the project is meant to produce, for whom, and by when.

This is not a formality. Without an explicit objective, there is no way to later judge whether the project succeeded, and scope tends to drift as stakeholders each project their own hopes onto an undefined initiative. Requiring the consultant to write the objective down, in plain business terms, before any technical design starts is a reasonable and low-cost check.

• Ask for the objective in one sentence, stated in business terms, not technical ones
• Ask what would count as a failed outcome, not just a successful one
• Check that the objective is owned by someone with authority to change how work is done, not only by an IT sponsor

Data access and control requirements

Any AI or automation project touches data, and the quality and boundaries of that data largely determine what is achievable. A serious consultant will ask early what data exists, where it lives, who owns it, and what constraints apply to it, rather than assuming access will simply be granted once the project starts.

Executives should require the reverse discipline too: a written description of what data the consultant needs, why, for how long, and under what access controls. Vague requests for 'full access' to systems should prompt questions. Controlled, scoped access aligned to the specific objective is a reasonable baseline requirement, and a consultant should be able to justify any exception to it.

Data quality problems discovered mid-project are far more expensive to fix than problems caught during scoping. Asking the consultant how they intend to assess data quality before committing to a delivery timeline is a fair and useful requirement.

Human review and appropriate safeguards

Because outcomes from an AI or automation project depend heavily on context and on the quality of what feeds into it, no responsible consultant should present a system as something to deploy and then ignore. A requirement worth insisting on is a defined human review step for any output that affects customers, money, compliance or safety, at least until the system's behaviour is well understood in production.

Safeguards should be proportionate to risk rather than uniform. A low-stakes internal automation may need lighter review than a customer-facing process. Ask the consultant to propose where human review sits in the workflow and why, rather than accepting a blanket assurance that 'the system is safe'.

This is also where governance overlaps with practicality: safeguards that make the system unusable defeat the purpose, so the right requirement is a review process sized to the actual risk, not a maximal one applied everywhere.

Measurement after deployment, not just at handover

A project that is only measured at the moment of delivery, using a demo or a test dataset, tells you little about how it will perform once real users and real data are involved. A reasonable requirement is that the consultant defines, in advance, what will be measured in production and over what period, and that they remain involved, or hand over a clear method, for reviewing that data afterward.

This connects back to the explicit objective from the start: if the objective was stated as a measurable outcome, then production measurement is simply the way you find out whether it was achieved. Consultants who avoid committing to post-deployment measurement, or who treat the handover as the finish line, are worth questioning further.

How Victor Laybats approaches these requirements

Victor Laybats provides AI and automation engineering services from Paris and documents an approach intended to run from initial scoping through deployment and follow-up, rather than stopping at delivery. That structure is described publicly so prospective clients can see, before engaging, roughly how a project would be scoped and reviewed.

It is worth being precise about what this means and does not mean: it describes an approach and a set of stated principles, not a guarantee of outcomes. As with any consultant, results depend on the client's context, existing systems and the quality of the data involved, and no claim beyond that is made here.

A short worked example (illustrative only)

Consider a hypothetical mid-sized retailer that wants to automate parts of its customer support inbox. Before agreeing to anything, the business team could require the consultant to state the objective (for example, reducing average response time on a defined category of tickets), specify exactly which data and systems they need access to and for how long, describe where a human will review or override automated replies, and commit to a measurement window after go-live with agreed metrics.

This example is illustrative, not a claim about any real engagement or result. Its purpose is simply to show how the four principles above translate into concrete questions a business team can ask in a first meeting, rather than assumptions to trust on faith.