Red Flags in an AI Consulting Proposal: What to Check Before Signing

Red Flags in an AI Consulting Proposal: What to Check Before Signing

A bad AI consultancy usually shows itself in the proposal: it promises results without having seen your process, talks about tools before it talks about the problem, and never says what your company keeps at the end. To spot the risk before you sign, look for promises with no metric, silence about data, limits and handover, and clauses that lock you in to the vendor. A good proposal is specific about what will be done, what will not be done and how you decide to stop.

Key takeaways

• A promised result before anyone has seen your process is the cheapest red flag to detect and one of the most reliable.
• What the proposal leaves out (baseline, data, permissions, evaluation, exit) matters more than what it says.
• A pilot with no agreed metric and no stop criterion is a demo, not a pilot.
• If accounts, prompts and workflows stay only with the vendor, the engagement turns into renting knowledge.
• You can test a proposal with simple questions before signing, and the quality of the answers is already part of the evaluation.

Which promises in an AI consulting proposal signal risk?

Promises are not the problem in themselves. The problem is a promise that cannot be verified or that does not depend on what the consultancy will find out. Be wary when you see something like:

• Guaranteed results before diagnosis. Nobody knows whether a customer service or back-office flow will work well before looking at real messages, real rules and real exceptions.
• Total automation. Phrases like "the agent handles everything on its own" ignore that every process has judgment cases, and that someone must take over when the AI should not decide.
• A fixed deadline and fixed scope with no discovery phase. If the proposal already knows what will be built without talking to the people who run the process, the scope was copied from somewhere else.
• Technology as the protagonist. A proposal that spends more pages on the model, the platform or a proprietary method than on your process is selling a product, not consulting.
• Accuracy promised with no way to measure it. Saying the agent "answers correctly" only means something if the proposal explains how correctness will be assessed and by whom.
• Success stories with no context. A result from another client, with no description of process, data and limits, does not transfer to your reality. A vendor that quotes client results without permission also raises a separate question about confidentiality.

A quick test: swap your company name for a competitor in a different industry. If the proposal still makes sense without any other change, it is too generic.

What a good proposal must say that many leave out

Omissions are more dangerous than exaggerations because they do not show up when you read. Compare the proposal with this list and mark what is not written down:

• Baseline: how the process works today, how long it takes, who does it, where it goes wrong. Without this, nobody can say later whether it improved.
• Data: what information the AI will read, where it lives, who on the vendor side has access and what happens to it when the contract ends. In WhatsApp conversations this involves personal data, and LGPD compliance for AI on WhatsApp requires a legal basis and records, not just a generic compliance sentence. (LGPD is Brazil's data protection law.)
• Permitted actions: what the agent can only read, what it can write and what needs human approval. A proposal that does not separate reading from writing leaves the risk decision for later.
• Human handoff: when and how the conversation passes to a person, with what context and during which hours. The WhatsApp AI agent human handoff playbook shows the level of detail to expect.
• Evaluation: which test cases will be used, who writes them and how failures become fixes. The practice of evaluating agents with real examples is described in material such as Anthropic's guide to evals for AI agents.
• Decision records: logs that let you understand why the agent answered or acted a certain way.
• Variable costs: what is charged for model usage, messages and infrastructure, and who pays for each part. The first proposal does not need figures, but it does need clarity on what is fixed and what varies.
• End of the work: what will be delivered, documented and handed over.

Which scope and contract problems lock a company in?

Some problems only appear once the project is already moving. Read the contract looking for them:

• Elastic scope. Verbs like support, follow up and optimize with no associated deliverable allow indefinite billing while nothing gets finished.
• A pilot that is really a demo. If the pilot runs on sample data, with no real integration and no real users, it proves little. A real pilot has a real flow, clear limits and an agreed metric. The AI pilot charter template lists the minimum fields.
• Vendor-owned accounts and access. If the agent runs in the consultant's account, with prompts and workflows you cannot export, leaving becomes expensive or impossible.
• Undeclared subcontracting. Part of the work may be done by third parties who will also have access to your data. The proposal should say who they are.
• Invisible maintenance. Models change, integrations break and business rules shift. If the proposal does not mention monitoring and maintenance, or treats them as a favor, the agent degrades silently.
• No stop criterion. A contract that only plans for expansion gives you no right to say the pilot did not work and end it.
• Unclear ownership. Documentation, prompts, evaluations and code need a defined owner.

How to test the proposal before signing: step by step

You do not need to be technical to run this check. You need one meeting and the right questions.

• Step one: ask the consultancy to describe your current process on one page, including the exceptions it already knows about. If it cannot, the diagnosis has not happened yet.
• Step two: ask what the pilot's success metric will be and who measures it. Write the answer down, together with today's reference value.
• Step three: ask for the list of actions the agent will be able to execute and which ones need human approval. Compare it with what you would let an intern do alone.
• Step four: ask where the data will be stored, who can access it and how it is deleted at the end. If customer conversations are involved, bring your company's data protection officer into the discussion. In Brazil, the national data protection authority (ANPD) is the official reference for guidance.
• Step five: ask how failures are detected. Request an example of a log or an evaluation report, with fictional data.
• Step six: ask what happens if the pilot does not reach the metric. The answer should include stopping without a disproportionate exit penalty.
• Step seven: ask what will be delivered at the end so your team can operate on its own. Documentation, access, evaluations and training should all appear.

If you want to formalize this, the AI agent RFP template has requirements you can copy into your request for proposal.

Illustrative scenario: two proposals for the same problem

Imagine a services company that receives many requests for duplicate invoices and appointment bookings on WhatsApp and wants to reduce the load on its team. This is an illustrative scenario, not a real client.

The first proposal promises an agent that handles everything, with a fixed deadline and a proprietary platform. It does not describe the current process, cites no metric, says nothing about human handoff and states only that data will be "handled securely." The contract has an ongoing monthly fee and does not mention exit.

The second proposal starts with a short diagnosis: collect the most frequent conversations, choose which flow will be the pilot (for example, appointment booking only) and record how much time the team spends on it today. It lists what the agent can look up and what it can only propose, defines when the conversation goes to a person, describes the logs and schedules a decision meeting at the end of the pilot with three possible outcomes: expand, adjust or stop. It delivers documentation and access at the end.

The second proposal may cost more reading and preparation effort, but it gives you something the first does not: the ability to say no with information. For the booking flow itself, the article on automatic appointment scheduling on WhatsApp with AI helps you understand what should be covered.

How the map, limit, pilot and hand over method answers these risks

Each step of a serious method corresponds to a red flag you saw above. Mapping means recording the process and the baseline before promising anything. Limiting means defining which data the agent reads and which actions it can take, with human approval wherever there is risk. Piloting means running a real flow, with logs and an agreed metric, and deciding based on it. Handing over means delivering documentation, access and evaluations so your team, or another vendor, can operate it.

This follows the same logic as public risk management references such as the NIST AI Risk Management Framework, which organizes the work around mapping, measuring and managing the risks of AI systems. It also fits Anthropic's advice in Building effective agents: start with the simplest solution and add complexity only when it is justified. If the proposal you received has no equivalent of these steps, it is worth asking why.

How to decide: proceed, request a revision or decline

Use this reading as a guide once you have analyzed the proposal:

• Proceed, when there is a diagnosis, an agreed metric, limits on data and actions, a stop criterion and a handover plan, even if the scope is small.
• Request a revision, when the proposal is technically strong but omits one or two items, such as human handoff or ownership of the artifacts. Send it back with written questions and watch the quality of the reply.
• Decline or pause, when there is a guaranteed result, no baseline, data with no declared limit or a contract with no exit.
• Compare with another option, when you do not yet know whether you need consulting, custom development or an off-the-shelf tool. The buyer scorecard for evaluating AI agent development companies helps you put proposals side by side against the same criteria.

A proposal that passes these checks can still go wrong, but the error will be visible early and cheap. That is the goal.

Frequently asked questions

How do I spot a bad AI consultancy if I am not technical? Read the proposal looking for three things: a success metric with a reference value, limits on data and actions, and a stop criterion. If any is missing, ask for it in writing. How the consultancy responds tells you more than the document does.

Is it worth requiring a pilot before a larger contract? Yes, as long as the pilot covers a real flow, with logs and an agreed metric. A pilot without those elements is for selling, not for deciding. The article on how to measure an AI automation pilot covers metrics and decision gates.

Is a consultancy that uses third-party tools a problem? Not necessarily. The point is transparency: which tools, who has access to the data, and whether you can move the configuration to another account in the future. The risk is hidden dependency, not the tool.

What should I do if I already signed and noticed red flags? Go back to the contract and identify what it says about deliverables, data access and termination. Ask for a meeting to define the metric and the next decision point in writing, and request copies of documentation, prompts and access. If the answer is evasive, consider closing the current cycle instead of expanding.

Sources

• NIST: AI Risk Management Framework
• Anthropic: Demystifying evals for AI agents
• Anthropic: Building effective agents
• ANPD: Autoridade Nacional de Proteção de Dados