Red Flags in an AI Consulting Brief: 12 Warning Signs to Spot Early

Every bad engagement had warning signs in the original brief. The trouble is that when you're hungry for work — or excited about a technically interesting project — it's easy to dismiss signals that, in hindsight, were obvious.

Here are 12 warning signs that experienced AI consultants have learned to treat seriously. None of them are automatic disqualifiers. All of them deserve a direct conversation before you sign anything.

1. "We just need someone to implement what we've already designed"

This phrase usually means one of three things: the design is incomplete and someone hopes you won't notice, the design is wrong and there's internal disagreement they're hoping to resolve by hiring an external party, or they want an executor rather than an expert and will resist your professional judgement throughout delivery.

Ask to see the design documentation before any commercial discussion. What you see will tell you everything.

2. The budget was set before the scope was defined

You can always spot this one because the brief includes a budget figure but describes only a vague objective. "We have £150k and we want an AI solution for customer service." That budget was set by someone who read an article, not someone who understood the problem.

Not necessarily a dealbreaker — but you need to understand how the number was arrived at and whether it has any flexibility if discovery reveals different requirements.

3. "The data's all there, it just needs tidying"

Translation: nobody has actually looked at the data. "It just needs tidying" is what people say when they're aware there's a data problem but haven't scoped it. In practice, it can mean anything from a few inconsistent formats to years of records spread across seven legacy systems with no consistent identifiers.

Make data assessment a standalone piece of work before any modelling or development commitment. Price it separately. Protect yourself.

4. The previous consultant left under unclear circumstances

Sometimes people leave because the project ended. Sometimes they leave because of the client. Ask directly: why did the last engagement end? A good client will tell you honestly. A client who gets defensive or vague about it is a client who may have the same dynamic with you.

5. Multiple senior stakeholders with conflicting views are mentioned in the same paragraph

If the brief references the CTO wanting one thing, the CDO wanting another, and the CEO "excited about AI generally", the project doesn't have alignment — it has a political problem that you'll be expected to navigate from the outside. Delivery is impossible without a clear decision-maker. Identify who that is before you start.

6. "We need this by [unrealistic deadline]"

Deadlines set before scope is defined are almost always wrong. A client who insists on a delivery date before agreeing what's being delivered is either under external pressure they haven't disclosed or has unrealistic expectations about what's involved. Either way, that deadline will be your problem when the project overruns.

7. The brief mentions AI without mentioning the problem

Technology-first thinking. "We want to implement a machine learning model" or "We're exploring how LLMs can transform our business" — these describe a technology, not a problem. Ask what specific operational outcome they're trying to achieve and you'll either get clarity or get a very long pause.

8. "We've already spoken to [Big 4 firm] but they were too expensive"

Sometimes a genuine opportunity. Sometimes a client who wants Big 4 delivery at startup prices. Understand why the previous conversation didn't proceed — was it purely cost, or were the larger firm's requirements (data access, governance, timeline) also a factor?

9. IP ownership terms that haven't been discussed

A brief that doesn't mention IP ownership, or assumes by default that all output belongs to the client, is a brief that will cause problems. If you're building models, frameworks, or code that you'd want to reuse — whether that's your prompt library, your data pipeline architecture, or your evaluation methodology — you need to establish this before you start, not after.

10. "We don't need a formal contract, we work on trust"

Every consultant who has heard this has a story. You need a contract. Not because you don't trust them — because contracts protect both parties and make trust unnecessary when things get complicated. Clients who resist formal agreements are either naive about professional practice or have learned that informal arrangements serve them better. Neither is reassuring.

11. The brief was written by someone who won't be involved in the project

Procurement or senior leadership wrote the brief, but day-to-day delivery will involve different stakeholders. The expectations in the brief may not match what the delivery team actually wants. This is especially common in large organisations. Ask who you'll be working with and have a conversation with them before you commit.

12. You feel like you have to win this one

Not in the brief — in your own head. The most reliable warning sign of all is the one you generate yourself. When you need the revenue, or you're excited about the technology, or the client is prestigious, it's easy to suppress the doubts that would otherwise stop you. The engagements that turn into disasters are disproportionately the ones where the consultant knew something was off but pushed through anyway.

Trust your read. Raise the issue. If it can't be resolved, walk away cleanly.