Use AI as Devil's Advocate for Decisions: A Practical Guide

Use AI as Devil's Advocate for Decisions: A Practical Guide

To use AI for decisions without losing control, give it the role of devil's advocate: ask it to present objections, risks, opposing scenarios and weak assumptions in your proposal. You stay responsible for the choice, and the AI simply widens the list of weak points you need to examine. The result depends on three things: well-described context, instructions that block automatic agreement, and a human check of everything it returns.

Key takeaways

• AI works better as a structured counterweight than as a decision maker: ask for objections, risks and opposing scenarios, and keep the choice yourself.
• Without an explicit instruction, models tend to validate what you present. Tell it to disagree, point out weak assumptions and say what would change its conclusion.
• The quality of the objections depends on the context you provide: goal, constraints, alternatives and what you already ruled out.
• Every objection needs human triage: verify facts, discard the generic ones and record what was accepted or rejected.
• Customer and employee data need a rule before use, not after.

Why AI agrees with you too much

When a manager describes a decision to an AI assistant, the tone of the question already carries the expected answer. If you write, "I'm thinking of opening a second location, what do you think?", the model usually returns a friendly analysis with points in favor, a caveat or two and an encouraging conclusion. That is not malice. It is the behavior of a system trying to be helpful that, when in doubt, follows the person it is talking to.

The problem is that management decisions rarely fail from lack of enthusiasm. They fail because of an assumption nobody questioned, a risk that stayed out of the conversation or a scenario that seemed unlikely. A good devil's advocate exists to make uncomfortable what has become too comfortable.

So the request has to change. Instead of asking for an opinion, you ask for a specific job: find where the decision can fail. The difference looks small, but it changes the kind of answer you get.

What to prepare before asking for objections

Generic objections are the most common failure. If the model knows nothing about your business, it returns warnings that fit any company: "consider cash flow", "assess the competition". Nobody decides better from that. Anthropic describes context engineering as the careful choice of what goes into the model's window, and the principle applies to an ordinary conversation too: little information, but relevant.

Before asking for any critique, gather these items in a short text:

• The decision in one sentence, including what you are inclined to do.
• The real goal: what needs to improve and how you will know it improved.
• The alternatives you considered, including doing nothing.
• The constraints: deadline, team, available budget (without sharing sensitive figures), contracts and legal obligations.
• The evidence you have and where each piece comes from.
• What you do not know and would like to know.
• Who will be affected: customers, team, partners.
• How reversible it is: if it goes wrong, can you go back?

That last item is the most overlooked. An easy-to-undo decision calls for less analysis than one that commits the company for a long time. Telling the model this helps calibrate how deep the critique should go. And writing this summary has its own benefit: many people notice a gap before even sending the message.

Step by step: seven requests in sequence

Do not ask one enormous question. Run the conversation in stages, each with a clear job. This sequence works well for mid-sized management decisions, such as hiring, switching suppliers, launching a service or changing a process.

• Step one, role and rule: tell the model it will act as a critic, must not praise or agree out of politeness, and must separate fact from assumption.
• Step two, assumptions: ask for a list of the assumptions implied in your decision and, for each, what would happen if it were false.
• Step three, objections: ask for the strongest objections an experienced, skeptical manager would raise, ordered by impact.
• Step four, opposing scenarios: ask for two or three plausible scenarios in which the decision goes wrong, with the chain of events that leads there.
• Step five, pre-mortem: ask the model to imagine the decision has failed and to write the most likely causes, as in a post-incident review.
• Step six, what was not seen: ask it to list the information missing for a good decision and how to get it cheaply.
• Step seven, reverse defense: ask for the best argument in favor of the alternative you discarded, to test whether discarding it was fair.

An example request for step three, in one line:

Act as an experienced, skeptical critic: list the five strongest objections to the decision below, order them by impact, state which assumption each one attacks and say what would change your assessment.

Note the end of the request. Asking for "what would change your assessment" forces the model to name a verifiable criterion, which is more useful than a loose warning.

Illustrative scenario: adding a second customer support shift

Imagine a services company that serves customers on WhatsApp and is considering a second shift of human support because messages pile up in the late afternoon. The owner leans toward hiring. He writes the summary with the items from the previous section and asks for objections.

The model attacks the central assumption: is the pile-up caused by a lack of people, or by a specific type of message that could be resolved earlier? It suggests an opposing scenario in which the new shift is hired, the pile-up continues because the cause is requests for duplicate documents and repeated questions, and the new team inherits the same queue. In the pre-mortem, it points out that nobody had defined how to measure whether the second shift worked.

None of this is an order. The owner checks his own records to see which message types make up the queue, finds that part of it really is repetitive and decides to test a smaller change first, before hiring. In another possible outcome, he would confirm the queue is varied and go ahead with the hire, now with a written success criterion. In both cases, the decision is his and is better grounded. For the support side, it is also worth reading about what to automate and what to keep human in AI customer support.

How to separate useful objections from noise

A long list of risks gives an impression of rigor, but much of it may be irrelevant, repeated or even made up. The NIST AI Risk Management Framework organizes AI risk management around governing, mapping, measuring and managing, and the idea works here on a small scale: listing risks is not enough, you have to assess them and decide what to do about each one.

Use this filter for each objection the model presents:

• Is it specific to my case, or would it fit any company?
• Does it depend on a fact I can verify? If so, verify before accepting.
• What is the impact if it proves true, and is it reversible?
• Is there a cheap action that reduces the risk, or a test that confirms it?
• If I ignore it, who pays and when?

Then sort each objection into three groups: accepted (changes the plan), to verify (needs data) and rejected (with a written reason). The written reason matters. Rejecting an objection on conviction is legitimate, but recording why helps you review the decision later, if reality disagrees.

Also be wary of the model's factual claims about markets, laws and competitors. It can be confidently wrong. If an objection cites a rule, confirm it at the official source. For text that will circulate inside the company, the checklist for reviewing AI-generated text helps you avoid passing errors along.

How not to outsource your judgment

The risk of the method is reversing the roles: the AI proposes, you approve without thinking. The OECD principles for AI address human oversight and accountability, and the practical point is simple: the person who signs the decision must be able to explain it without citing the tool.

A few practices that keep judgment in the right place:

• Write your position before consulting the AI. That way you can tell whether it really changed anything or only confirmed what you already thought.
• Ask for objections, not verdicts. Avoid asking "should I do this?" and prefer "where can this fail?".
• Compare with people. Take the strongest objections to those who know the operation, such as whoever runs finance or customer service.
• Define who decides and when. A round of critique with no deadline becomes procrastination.
• Recognize the limits. Some decisions should not be handed to AI, such as those involving layoffs, health or people's rights. The article on what not to delegate to AI in business goes deeper on this boundary.

If the decision involves treating people through automated processing, Brazil's LGPD has its own rules on review, and it is worth knowing Article 20 and the right to review. Using AI to critique your own decision is different from letting it decide about someone, but the boundary deserves attention.

Data, privacy and recording the decision

To get a good critique, the temptation is to paste everything: spreadsheets, contracts, customer conversations. Resist it. Anonymize, summarize and use only what is necessary. Customer names, employees' personal data and confidential contract terms are rarely essential for the model to find a weak assumption.

Three practical precautions:

• Define inside the company which AI tools may receive which types of information. The company policy for employee ChatGPT use shows how to separate what is allowed from what is banned.
• Understand where the data goes. If the tool processes information outside Brazil, the question of international data transfer when using AI providers comes into play. The ANPD, at gov.br/anpd, is the official reference for guidance.
• Keep a short record: the decision, the objections raised, what was accepted, what was rejected and the criterion for reviewing it. One page is enough.

This record has a second use. After some time, you can compare what happened with what the critique predicted and adjust how you ask. It is cheap learning that almost nobody takes advantage of.

How this fits the method: map, limit, pilot, transfer

The same reasoning we use to bring AI into processes applies to using it in decisions. Mapping means describing the decision, the assumptions and the evidence before asking for anything. Limiting means restricting the data that goes in and making clear that the AI only critiques and never decides. Piloting means testing the method on one or two real, low-risk decisions and checking whether the objections surfaced something you had not seen. Transferring means turning what worked into a team playbook, with the standard request, the triage filter and the record, so different managers can repeat the process. If you want to measure whether the practice pays off, the article on how to measure an AI automation pilot offers decision criteria that adapt well.

Frequently asked questions

Can I let AI make management decisions on its own? It is not recommended for significant decisions. AI does not know the company's full context, can be confidently wrong and does not answer for the consequences. Use it to broaden the analysis, and keep the decision and the responsibility with a person.

Do I need a specific tool to use AI as a devil's advocate? No. An ordinary chat assistant is enough, as long as you provide context, define the critic role and run the conversation in stages. What changes the result is the quality of the request and the triage, more than the brand of the tool.

How do I stop AI from inventing risks that do not exist? Ask it to separate fact from assumption, state which assumption each objection attacks and say what would need to be verified. Then confirm anything factual in reliable sources and in your own data. An objection that cannot be verified should be treated as a hypothesis, not as a warning.

Can I use customer and employee data in this analysis? Ideally you will not need to. Summarize and anonymize, and send only what the critique requires. If personal data is unavoidable, first confirm that the tool is permitted by company policy and how LGPD applies to the case.

Sources

• NIST: AI Risk Management Framework
• OECD: AI Principles
• Anthropic: Effective context engineering for AI agents
• ANPD: Autoridade Nacional de Proteção de Dados