AI Risk Assessment Prompt: Stress-Test Any Major Decision

What an AI Risk Assessment Prompt Does

An AI risk assessment prompt is a structured instruction that makes an AI model surface, rank and mitigate the ways a plan could fail — before you commit to it. Done properly it is not one prompt but three, run in sequence, each feeding the next. The output is a scored matrix of failure modes with safeguards attached, not a bullet list of worries.

The version we teach at PromptPeakAI is the Failure-First Audit: frame the plan and its unstated assumptions, force a total failure and work backwards to the causes, then score each cause and attach a safeguard with a trigger condition.

One boundary worth drawing early. If your task is to produce the document — a risk register with owners and dates for a project that is already approved — that is a different job, and our walkthrough on how to create a risk assessment using ChatGPT covers it end to end. This page is about the decision you have not made yet.

The three-pass structure is the whole point. Ask for risks in a single message and the model has to guess your plan, invent the failure modes and rank them all at once — so it defaults to the safest, most generic set it knows. Splitting the job means each pass has something concrete to work from.

Why AI Agrees With Your Plan

Ask a model “what are the risks of this plan?” and you are asking a system trained to be helpful to critique something you have obviously invested in. It reads the enthusiasm in your framing and matches it. The result is hedged, symmetrical and useless: three mild risks, three reassurances, no ranking.

The second framing is not a trick. It is the pre-mortem, a technique the cognitive psychologist Gary Klein set out in Harvard Business Review in 2007. Klein’s article cites 1989 research by Mitchell, Russo and Pennington finding that prospective hindsight — imagining an outcome has already happened — raises people’s ability to correctly identify reasons for that outcome by around 30%.

In practice, a reliable AI risk assessment prompt carries four things a casual one leaves out:

• A role with a stake in finding problems, not in being agreeable
• A stated failure that has already happened, at a named point in time
• An explicit ban on praise, hedging and reassurance
• An instruction to flag unknowns rather than fill them in

Grammar does most of that work. “What could go wrong” invites speculation. “It went wrong — explain why” demands an account. Models respond to that shift the same way teams do, which is why the framing matters more than the tool you run it in.

Two things make it stick. Give the model a role with a stake in finding problems, which our guide to writing a role that changes the output unpacks properly. Then ban the behaviour you don’t want — the technique covered in negative constraints. Both appear in the prompts below.

Run the Failure-First Audit

Twenty minutes, three prompts, one chat window. Keep all three passes in the same conversation so the model carries the framing forward — starting a fresh chat for each pass throws away the context that makes pass two specific.

Before anything gets stress-tested, the model needs to know what it is looking at and — more usefully — what your plan takes for granted. This pass is the one people skip, and skipping it is why the output comes back generic.

You are reviewing a business decision I have not yet committed to. Do not evaluate it yet.

The decision: [one sentence — what you are proposing to do]
Context: [budget, timeline, team size, who signs off, what it replaces]
Constraints: [anything fixed — contract dates, headcount, regulatory limits]

Do two things only:

1. Restate the plan in six bullets, in my language, so I can confirm you have understood it.
2. List every assumption the plan depends on but does not state. Separate them into: assumptions about people, assumptions about systems, assumptions about timing, and assumptions about money.

Do not suggest improvements. Do not comment on whether the plan is good.

Read the assumption list before moving on. If something on it is wrong, correct it in the chat now — an assumption you leave standing becomes a risk the model never tests.

Now the inversion. You are not asking for risks; you are asking for an autopsy of a failure that has already happened. The date matters — a specific future point makes the account concrete rather than theoretical.

Change roles. You are now an independent auditor brought in after the fact. You are paid to explain failures, not to reassure anyone.

It is [date, roughly when the outcome would be visible]. The plan above went ahead and failed badly enough that it was reversed. Leadership has asked you what happened.

Write the account. Cover:
- The eight most plausible causes, most likely first
- Which unstated assumption from your earlier list each cause traces back to
- The earliest visible signal that each one was starting to happen
- Who inside the organisation would have noticed it first

Rules:
- Do not compliment the plan or note anything that went well.
- Do not use the words "may", "might" or "could" — write it as something that happened.
- If a cause depends on a fact you do not have, say "requires human verification" instead of guessing.

Eight causes with no priority is still not a decision. The third pass turns the account into something rankable and attaches a countermeasure to each line — plus the trigger that tells you when to use it.

Stay in the auditor role. Turn your account into a decision table.

For each of the eight causes, give me:
- Cause (six words maximum)
- Likelihood: High, Medium or Low
- Impact if it happens: Severe, Major or Minor
- One preventive safeguard we could put in place before starting
- The trigger — the specific, observable thing that tells us this risk has started

Then:
- Sort the table by Likelihood x Impact, worst first.
- Below the table, name the two causes that are cheapest to prevent relative to their impact.
- Name any cause where no safeguard exists. Say so plainly rather than inventing one.

Output as a table. No preamble.

Adapt It to Your Decision

The three passes don’t change. What changes is the context you paste into pass one and the failure window you name in pass two. A campaign fails visibly in eight weeks; a vendor migration takes two quarters to go wrong.

Choose that window carefully — it is the single setting most people get wrong. Name a date too close and the model only finds launch-day problems; name one too distant and it drifts into market speculation you cannot act on. Pick the point at which your organisation would first be forced to admit the decision had not worked.

For decisions with knock-on effects across departments — budget cuts especially — add one instruction to pass two, because first-order consequences are the ones you already know about.

Extend the account. For each of the top three causes, trace the second-order effect: what breaks next, in a different team, three to six months later. Name the team.

Then name one third-order effect you consider genuinely plausible, and say why. If you cannot find one, say so rather than inventing it.

Get a Table, Not a Bullet Dump

Most people lose the value of this workflow at the last step. The analysis is sound, the output is a wall of nested bullets, and nobody in the room can scan it. Ask for the structure explicitly — our guide on how to specify format so AI output is usable goes deeper on the general principle.

Copy the table straight into your slide or document. If you need the findings condensed further for leadership, the same content compresses well using the approach in our guide to writing an executive summary.

Keep Company Data Out of It

This is the point where most people either overshare or abandon the workflow entirely. Nothing in an AI risk assessment prompt requires real names to work. Neither is necessary. The analysis works on structural abstractions — you get the full stress-test from “Vendor A, three-year term, 40% renewal uplift” without ever naming the vendor.

The plan-versus-tier question also comes up constantly, and the answer surprises people: paying does not change your privacy position. On consumer accounts — free and paid alike — your conversations feed model training unless you change a setting. Business and enterprise accounts exclude your content by contract, and that is the real dividing line, as our guide to whether ChatGPT is safe to use at work sets out.

In ChatGPT, the control sits in Settings under Data Controls, and OpenAI’s own data policy confirms that business and enterprise content is excluded from training by default while individual accounts are not. Claude carries an equivalent toggle in Privacy Settings; Gemini’s sits under Activity.

Make the Go or No-Go Call

The table is input, not verdict. What turns it into a decision is a single rule you set before you look at the results: which quadrant can you not live with, and what would have to be true for you to proceed anyway?

Set that rule before the table exists, not after. Reading a scored matrix and then deciding what counts as unacceptable is how teams talk themselves past the one risk they should have stopped for. Most managers who use this regularly write the rule into the meeting invite.

When the call needs writing up rather than just making, one more prompt turns the table into something a committee can act on.

Write a decision brief for a leadership group who will read it in three minutes and have not seen the analysis.

Structure:
- Recommendation in one sentence: proceed, proceed with conditions, or re-scope.
- The three risks that drive that recommendation, one line each.
- The conditions we are asking them to fund or approve.
- The one thing we could not mitigate, stated plainly.

No jargon. No hedging. If the recommendation is to stop, say stop.

That output slots directly into the wider case you are building, which our walkthrough on how to write a business case covers in full.

What This Method Cannot Do

Worth being blunt, because a scored table looks more authoritative than it is. The model has no access to your organisation’s history, no memory of the last three projects that failed for political reasons, and no way to know which of your stakeholders quietly opposes this.

The invented-constraint problem deserves its own attention, because it is the failure mode most likely to embarrass you in a meeting. Our explainer on why AI makes things up covers the mechanism; for the practical checking routine, use the approach in our guide to fact-checking AI research before you put your name on it.

When the Output Goes Wrong

Five failure modes account for nearly everything that goes sideways with an AI risk assessment prompt sequence. Each one traces back to a missing instruction rather than a limitation of the tool.

One more that is harder to spot: the model agreeing too readily when you push back. If you challenge a risk and it immediately withdraws it, the framing has slipped. Restate the auditor role and ask it to defend the finding instead.

There is also the trap of running the audit and then filing it. A risk table is only useful if someone is watching for the triggers on it, which in practice means three small habits:

• Put the two highest-scored triggers on a standing meeting agenda
• Name one person per safeguard, by name, before the work starts
• Re-run the audit if the scope or the budget changes materially

Run this once on something small — a tool purchase, a process change — before you point it at the decision that actually keeps you up at night. The workflow takes twenty minutes; learning to trust it takes one round where it catches something you genuinely missed.

Keep the AI risk assessment prompt sequence saved somewhere you will find it again, because the second run takes ten minutes rather than twenty. And when the decision is behind you, the same discipline in reverse is worth an hour — which is what our guide to writing a lessons learned report is for.