Prompt Engineering 10 min read Updated Jul 9, 2026

How to Ask AI for Risks Before You Accept Its Answer

AI hands you a clean recommendation that reads as ready to use — and never shows you which assumption breaks it, which edge case sinks it, or what needs a human's eyes. Here's how to run a separate risk pass on an answer before you accept it.

Build an Adversarial Risk-Reviewer Prompt

When the answer looks finished and the risks are still hidden

AI hands you a recommendation and it reads like a decision already made: "Publish the updated refund policy today," "launch CSV-only next week," "send this email to the whole list." It's clean, confident, and shaped like something you can just do. What it doesn't include is the part you actually need before acting: which assumption the whole thing rests on, which edge case quietly breaks it, what's expensive to reverse, and where a human really ought to look first. The answer optimized for looking finished, and "finished" and "safe to act on" are not the same thing.

That gap is what this guide is about. Left to itself, a model gives you the recommendation and keeps the risks to itself — not out of malice, but because a hedged answer full of caveats reads as less helpful than a crisp one. The fix is to make the risk surfacing its own step: before you accept an answer, run a separate pass over it — a quick risk analysis of the answer itself — that asks what could go wrong, which assumptions are weak, what the failure modes are, and what needs checking before use. A pass like that turns a clean recommendation into a reviewable one. It doesn't make the answer safe, and it doesn't prove the risks are complete — the model produces candidate risks, and you're the one who decides which are real, which are overblown, and whether to act.

Why the model gives you a clean answer and keeps the risks

A model is trained to be helpful and decisive, and a confident recommendation scores as more helpful than the same recommendation buried under a paragraph of what-ifs. So the default is to deliver the polished version and leave the risks implicit — they were considered, maybe, but they didn't make the cut because they'd muddy a clean answer. Telling it to "double-check your answer" barely helps, because a model asked to review its own work tends to defend it, not attack it. Here's what stays hidden when nobody runs a real risk pass:

  • The load-bearing assumption. The whole recommendation rests on one unconfirmed thing — "CSV is fine," "legal already approved this" — and it's never flagged as the thing to check first.
  • The edge cases. The answer works for the normal path and says nothing about the empty input, the huge input, the in-flight transaction, or the user who isn't supposed to have access.
  • The reversibility. "Publish it," "send it," "make it public" are one-way doors, and the cost of being wrong is never weighed against the cost of waiting.
  • The human-review points. The places where legal, security, or an actual owner should weigh in get folded into a confident "do this" instead of being called out.
  • The weak evidence. A recommendation inferred from a single note or one data point reads exactly as firm as one backed by real evidence.

Step 1: Make the risk pass a separate step, with an adversarial stance

The single most important move is to stop asking for the answer and its risks in the same breath. Take the recommendation the model gave you, hand it back, and run a distinct pass whose only job is to find how it could fail. The framing that makes this work is adversarial: instead of "is this good?", the instruction is "do not defend this answer — look for the ways it breaks, the assumptions that could be wrong, and what would make it unsafe to act on." A model told to find problems finds different things than one told to confirm.

Be honest with yourself about one limit while you do this: a model reviewing its own answer is not an independent reviewer. It shares the blind spots that produced the answer in the first place, so the adversarial stance raises the odds of catching a problem without making the review a real second pair of eyes. Running the pass in a fresh session, or against a different model, gets you closer to genuine independence. Either way, the pass is a way to surface candidate risks earlier — not a guarantee that the serious one didn't slip through.

Step 2: Build the reviewer as a standing behavior

If you run risk passes more than once, don't retype the instruction each time — capture the reviewer as a reusable persona. The System Prompt Generator is built for this: its role, must-do, must-not-do, and escalation fields map cleanly onto a risk reviewer. Role: a skeptical reviewer whose job is to find how an answer fails. Must do: surface weak assumptions, edge cases, and failure modes, and flag what needs human review. Must not do: defend the answer, approve it, or claim the risk list is complete. Escalation: name where a person should verify before acting. The tool assembles that into a prompt you paste into your own assistant — it builds the reviewer; the model does the reviewing, and you judge what it finds.

NewPrompt already has personas that bake this stance in, worth reading as models of the tone. The Startup Advisor Role Prompt is a devil's-advocate advisor built to "name the riskiest assumption in any plan and how to test it cheaply" and to attach the biggest risk and its mitigation to every recommendation — its own note is that this "turns the model from cheerleader into devil's advocate," which is exactly the shift you want. It gives startup advice rather than reviewing an arbitrary answer, so borrow the stance, not the domain: the useful part is a persona that hunts for the weak assumption instead of agreeing with you.

Step 3: Give it the risk categories so "risks" isn't vague

"Find the risks" is as vague as "find the problems" — the model will surface whatever's salient and miss whole classes. So hand it the categories to check: factual risk (a claim that might be wrong), assumption risk (an unconfirmed thing the answer depends on), execution risk (it's harder to do than it looks), reversibility risk (how costly to undo if it's wrong), dependency risk (it relies on something outside your control), data or privacy risk, and the places where legal or compliance review is genuinely needed. A concrete checklist turns a vague hunt into a set of specific questions.

Reversibility deserves its own attention, because it changes how much a risk matters. The Software Architect Role Prompt is a good model of the habit — it's built to "distinguish reversible from irreversible decisions and calibrate caution accordingly" and to "name the failure mode each decision guards against." That's the right instinct to import: a risk on a one-way door (publishing, sending, deleting) deserves more caution than the same risk on something you can quietly undo tomorrow. It's an architecture persona, so take the reversibility lens, not the system-design specifics — the point is that "how hard is this to walk back?" belongs in every risk pass, not just technical ones.

Step 4: Ask for a risk table, not a warning paragraph

A prose paragraph of "here are some things to consider" is easy to skim and hard to act on. Ask instead for a risk table: one row per risk, with columns for where it appears in the answer, why it matters, its impact, a self-rated likelihood, how you'd detect or confirm it, a mitigation, who should own it, and a disposition — accept, revise, or verify first. Say plainly that the likelihood column is the model's self-rated caution, not a measured probability, so a "high likelihood" is a flag to look, not a computed number. The Markdown Output Builder pins that table shape so every risk pass comes back in the same structure you can scan.

For a sense of what a rigorous version looks like, the Production Readiness Review is a real failure-mode review — for code, not general answers — that checks a change against its worst day (timeouts, rollback, what breaks at ten times the traffic), tags each finding by severity, and ends with the minimal list of changes that would flip it. It's the closest thing in NewPrompt to a full risk pass, and it models the discipline well: rank by impact, treat missing safeguards as findings, and — as its own FAQ says — treat the verdict as "a structured recommendation, not a clearance." Two honest differences to carry across: it's scoped to a code deploy, and it ends in a SHIP / DO NOT SHIP decision, whereas your risk pass should stop one step earlier, at a risk-aware next step rather than a verdict.

Step 5: End in a risk-aware next step — and don't read silence as safety

The risk pass should not hand you a decision, because the decision is yours. Have it end in a risk-aware next step instead: accept the parts that are low-risk, revise the parts that aren't, and list what to verify before acting on the rest. "Don't publish today; confirm the legal conflict and the cutoff date first; if those clear, publish with a comms note" is a next step you can act on. A flat "do not do this" or "this is fine" is the model overstepping into a call it isn't positioned to make.

And hold onto the most important caveat: when the pass comes back with nothing alarming, that means this pass found no obvious risk — not that none exists. A risk review is not risk verification; it surfaces candidates, it doesn't certify their absence, and a model can miss the exact failure mode that later bites you. So a clean pass lowers your odds of walking into something obvious; it is not a safety certificate. Treat "no major risks found" as weak good news that still leaves the judgment — and the accountability — with you.

Common mistakes

The ways a risk pass turns back into blind acceptance:

  • Asking for the answer and its risks together. In one breath the model optimizes for a clean recommendation; the risks need their own adversarial pass.
  • Saying "double-check this." A model reviewing its own work defends it; you have to explicitly tell it not to defend and to hunt for how it fails.
  • Leaving "risks" undefined. Without named categories — assumption, reversibility, privacy, dependency — the model surfaces the obvious ones and misses whole classes.
  • Reading likelihood as a probability. "High likelihood" is the model's self-rated caution, not a measured number — a flag to look, not a calculation to trust.
  • Treating the risk list as a verdict. It's input to your accept / revise / verify call, not a rejection and not an approval; the decision stays yours.
  • Reading "no obvious risk" as safe. A clean pass means this review didn't find one, not that none exists — it's weak evidence, not a clearance.

A worked example: the refund policy

Take a clean recommendation that's easy to just accept, and watch what a risk pass adds before you act on it.

A clean recommendation vs. a condensed risk pass — impact, likelihood, detection, and disposition per row, with the why, mitigation, and owner captured in the notes beneath 
THE AI's ANSWER (shaped like a decision already made):
  "Recommendation: publish the updated refund policy on the site today. It's
   clearer than the old one and should cut support tickets about refunds."

WHAT THE RISK PASS SURFACES (that the answer left out):
  risk                            impact  likely*  detect / verify           disposition
  new policy conflicts w/ terms   high    med      have legal read both      verify first
  applies to in-flight refunds?   high    med      define the cutoff date    revise
  publishing is hard to walk back high    high     (a one-way door)          verify first
  a signed contract overrides it  high    low      check enterprise terms    verify first
  "cuts tickets" is unbacked      low     high     no evidence given         note only
  customers screenshot the change med     med      plan the comms first      revise
  * likelihood is the model's self-rated caution, not a measured probability

  weakest assumption: that "clearer wording" is the only change -- a policy edit
    can quietly change what customers are actually owed.
  needs human review: legal (terms / contract conflict), support (comms), and an
    owner for the in-flight-refund cutoff decision.

RISK-AWARE NEXT STEP (not a verdict):
  - Don't publish today on the model's say-so.
  - Verify the legal/contract conflict and the in-flight cutoff first; a
    published policy is expensive to walk back.
  - If those clear, publish with a comms note; if not, hold for legal review.

Where this fits in NewPrompt

There's no single "run a risk review" button in NewPrompt, so this is a pass you assemble: the System Prompt Generator builds the skeptical reviewer, the Markdown Output Builder pins the risk table, and the stance itself already lives, in domain-specific form, in assets you can read as models — a production readiness review that hunts a code change's failure modes, a startup advisor built to name the riskiest assumption, an architect who weighs every decision by how hard it is to reverse. None of them is a general risk pass over any answer; together they're proof the discipline is real, and the guide's job is to point it at whatever the model just told you to do.

The boundary here is worth stating flatly, because a risk table looks authoritative and isn't. The pass surfaces candidate risks; it does not verify that they're real, prove that the list is complete, or certify that the answer is safe. A flagged weak assumption is something to check, not a confirmed defect. The likelihood column is caution in words, not a probability. And the risk list is input to your call, never the call itself — accepting, revising, or holding stays with you and whoever owns the outcome. It's also worth keeping separate from its neighbors, since "check before you use" covers several different jobs: this is hunting for how an answer could fail, not reviewing a plan for the steps it's missing, not comparing options against criteria, not sorting an answer's facts from its assumptions, not checking its claims against a source document, and not grading it against a fixed pass/fail bar. Those all have their place; this one asks the question you most want answered before you commit — what's the worst that this gets wrong, and where should I look before I act on it?

Tools for this guide

Each generates the prompt described above — you run it in your own AI assistant.

Tool

System Prompt Generator

Build structured system prompts from role, tone, constraints, and model target.

Prompt Builders
Tool

Markdown Output Builder

Build prompts that produce documents in a fixed structure — headings, sections, and tables.

Structured Output

Ready-made resources

Reusable prompts and templates for the exact steps in this guide.

Resource

Production Readiness Review Prompt

SHIP or DO NOT SHIP: twelve checks on failure modes, observability, rollback, and load — the review that happens before the incident.

Operations
Resource

Startup Advisor Role Prompt

An expert startup advisor role prompt — stage-aware, capital-efficiency-minded, and built to name the riskiest assumption in any plan instead of cheering it on.

Operations
Resource

Software Architect Role Prompt

Make AI act as a software architect — system design, scalability, service boundaries, and trade-offs — instead of jumping straight to code.

Engineering

FAQ

If the risk pass comes back with no serious risks, is the answer safe to accept?

No — and the trap is that a quiet pass changes how the answer feels far more than it changes what you actually know. A review can show you a risk it found; it can never show you the one it missed, so a silent result is the absence of a flag, not the presence of safety. What really moves when the pass finds nothing is your confidence, not the answer's risk. So the accountability for acting is yours either way, flag or no flag: use a quiet pass to stop worrying about the obvious failure modes, and keep your own judgment firmly in charge of everything it couldn't see.

Does running a risk pass verify that the risks it lists are real?

No, and that's an important distinction. The model produces candidate risks — some genuine, some overblown, some it half-invented just to fill the table — and separating those is your job, not the pass's. The value is that it points you at where to look, not that it's done the looking, which is why the disposition column leans on "verify first" for most rows: the pass has surfaced a question, and answering it is a separate act of checking that you perform. A real risk and a piece of noise arrive in the same table, in the same confident tone; telling them apart is the work the pass hands back to you.

Isn't asking the model that wrote the answer to critique it a conflict of interest?

It is — the author of the answer and its reviewer being the same model is a real conflict, and the adversarial framing softens it without removing it. "Don't defend this; find how it fails" pushes a model against its instinct to justify its own work, and that genuinely helps; but a reviewer wired the same way as the author is structurally inclined to miss the same things, so no framing turns a self-review into an independent one. The practical upshot is how much weight to give a clean self-review: read it as a first filter that catches the obvious, not as a second opinion. When the stakes are high, the real second opinion has to come from somewhere the first answer didn't — a different model, or a person who wasn't in the loop.

How is a risk pass different from checking a plan for gaps or comparing options?

Different questions about different things. Checking a plan for gaps asks what's missing from it — the step, the owner, the dependency nobody assigned. Comparing options asks which of several choices is best against your criteria. A risk pass takes one answer you already have and asks what could go wrong with it: which assumption is weak, which edge case breaks it, what's hard to reverse. They often run in sequence — surface the risks, fill the gaps, then choose — but this is specifically the pre-mortem: before you accept the recommendation in front of you, find the ways it fails.