Before the Algorithm Arrives: Five Questions to Settle When a Consultant Proposes Automation

There was a period, not long ago, when a consultancy proposing to use artificial intelligence was making a statement. Today it is closer to a disclosure, offered almost in passing. The tooling has become ordinary; the commercial consequences have not.

For buyers, the difficulty is that automation is genuinely valuable and genuinely hard to see. A model that drafts a first-pass review, clusters a survey, or reconciles data across systems can compress weeks into days. The same model can also introduce errors at a scale no individual analyst could match, and can quietly relocate expertise out of the client organisation and into a subscription nobody in the business controls.

Neither reflex serves the client. Refusing automation on principle forfeits real efficiency; accepting it without questions forfeits something more important. What follows are five questions worth putting to any consultancy that intends to automate part of an engagement in 2026 — and the answers that should give a UK buyer confidence.

1. Where exactly does automation enter the work?

Ask for the engagement to be described in three layers: the input, the processing and the deliverable. Then ask which of those layers a model touches, and at what point a human intervenes.

Some vendors will say the assistant drafts and a consultant reviews. That is a reasonable answer, but it invites the follow-up: how much is drafted, and what does review mean in practice? A review of a two-page synthesis is materially different from a review of a two-hundred-page tranche of evidence. Where the human check is a skim rather than an examination, the proposal should say so plainly rather than describing the process as "consultant-led".

2. What happens to our data, and where does it sit?

For UK organisations this is where the conversation must become precise. Which systems will hold client material, in which jurisdiction, under what retention period, and who at the consultancy can access it? If a third-party model provider is involved, is client data used for training, and can that be contractually excluded?

A serious supplier will have answers ready and will not treat the question as an accusation. Where the engagement touches personal data, ask for the data protection impact assessment, and check the arrangement against the consultancy's obligations as a processor under UK GDPR. Regulated sectors — financial services, health, education — will want the same answers tested against their own supervisory expectations, and it is reasonable to ask whether the consultancy has worked under those constraints before.

3. Who checks the output, and how would we know if it were wrong?

Accuracy is not a binary quality that a model either has or lacks; it varies by task, by dataset and by how well the work is specified. Ask what validation the consultancy will apply, what error rate it has observed on comparable work, and what happens when a discrepancy is found mid-engagement.

The strongest answers include a named quality reviewer, a documented sampling approach, and a willingness to show the client a worked example of a caught error. The weakest answer is a reassurance that the tool is "highly accurate". Confidence is not a control.

4. What is the fee actually buying?

Automation changes the cost base of an engagement. It does not automatically change the price. That is a commercial negotiation, not a scandal, but the client is entitled to understand the basis on which the fee was constructed.

Three pricing models are defensible: a price reflecting the value of the outcome regardless of effort; a time-and-materials arrangement transparently adjusted for reduced hours; and a fixed fee that acknowledges efficiency and passes some of it on to secure the work. What deserves scrutiny is a fee that retains the effort-based logic of the pre-automation world while the underlying work has been compressed. Ask directly how the introduction of tooling has affected the estimate, and expect a coherent answer rather than a shrug.

5. Who owns what, and who answers when it goes wrong?

Intellectual property in consultancy work is often left vague, and automation makes the vagueness expensive. If a model produces the first draft, the prompts and the pipeline may have real commercial value. Clarify what the client owns at the end: the output, the templates, the workflow, the prompts, or some combination.

Accountability matters more still. If an automated element produces a flawed analysis that informs a board decision, the client needs to know that the consultancy stands behind the deliverable as a professional judgement, not as a transmission of machine output. An engagement letter that shifts responsibility toward the tool is an engagement letter that has misunderstood its purpose.

Putting the answers in writing

These five areas do not need a separate artificial intelligence schedule in every contract, but they do need to appear somewhere in the paperwork. A short annexe covering data handling, validation, ownership and liability is usually sufficient, and its absence is itself informative.

A balanced conclusion

The consultancies using these tools well are not the ones advertising them loudest. They are the ones who can explain, in plain terms, where the machine ends and the adviser begins — and who are comfortable being held to that boundary. That is the standard worth buying against, and it is available to any client willing to ask.