An AI risk profile is the core artefact of assurance work. Everything else — the monitoring plan, the control set, the board paper — derives from it. Done well it is two to six pages. Done badly it is a colour-coded matrix nobody has read since the workshop that produced it.
This is a method. It assumes you have been handed a system somebody else built and asked whether it is safe to run.
Step 1 — Establish the boundary
Write down what is inside the assessment and what is not: the model, the application around it, the data it reads, the systems it writes to, the humans in the path, and the period the assessment covers.
The boundary is what makes every later statement meaningful. “This system performs adequately” is not a claim until someone can say adequately at what, for whom, and over what window.
Failure mode: assessing the model when the risk lives in the application. A well-behaved model behind a badly designed interface that presents outputs as certainties is a risky deployment with a fine model in it.
Step 2 — Extract the operative claim
Find the sentence the organisation is actually relying on. It is rarely the stated one.
Stated: “It summarises support tickets.”
Operative: “It reduces handling time without increasing escalations or misrouting regulated complaints.”
The operative claim is the thing that, if false, means the deployment has failed. Write it down and get the business owner to agree to it in writing. This step alone justifies most assurance engagements — a surprising number of teams discover they have never agreed what the system is for.
Failure mode: accepting the stated claim because it is easier to test.
Step 3 — Identify who is affected, and how they can be harmed
List the parties: users, subjects of decisions, third parties, the operating organisation. For each, state how this system could make things worse for them, in plain language.
Keep it concrete. “Bias” is not a harm. “A claimant whose first language is not English receives a lower priority score and waits four weeks longer” is a harm, and it is testable.
Failure mode: listing harms as abstract categories. Categories cannot be tested, so they survive to the final report unexamined.
Step 4 — Map the failure modes
For each harm, ask what would have to go wrong to produce it, and be specific about the mechanism. The recurring ones:
- Distribution shift — the population it meets is not the one it learned from.
- Silent degradation — performance decays with no error raised.
- Automation bias — the human reviewer defers rather than reviews.
- Boundary violation — the system is used outside its intended scope, usually because it works well enough that people extend it.
- Upstream change — a vendor updates a model underneath you with no release note.
- Irreversible action — for agentic systems, something that cannot be undone.
Failure mode: stopping at model failures. Most real incidents involve a correct output used wrongly, or a correct output arriving at the wrong moment.
Step 5 — Assess what evidence exists
For each failure mode, ask what evidence you have that it is being managed, and grade it honestly:
| Grade | Meaning |
|---|---|
| Tested | Evidence exists, is dated, and someone could reproduce it |
| Asserted | Someone competent says so; no artefact |
| Assumed | Nobody has considered it |
This grading is the single most useful thing in the artefact, because it converts an argument about risk appetite into a statement of fact about what is known. Executives disagree about how risky something is. They rarely disagree that “assumed” is a bad place for a high-consequence failure mode to sit.
Failure mode: treating a vendor’s marketing claim as tested. It is asserted, at best.
Step 6 — Rank by consequence, not by likelihood
Likelihood estimates for AI failure modes are mostly fiction — there is rarely a base rate. Consequence is knowable: how bad is it, how many people, how quickly would you notice, can it be reversed.
Rank on consequence and use likelihood only to break ties. This inverts the standard risk matrix and produces better decisions, because it stops teams discounting catastrophic outcomes with a confident-sounding “unlikely” nobody can substantiate.
Failure mode: the 5×5 heat map. It launders guesses into numbers, and the numbers get quoted downstream without the caveats.
Step 7 — State residual risk and get it accepted
List what remains after existing controls, and have the person with authority accept it in writing.
This is the step most often skipped, and it is the one that matters after an incident. A risk identified, not mitigated, and not accepted is an unowned risk — and the record shows the organisation knew about it and did nothing. Acceptance converts that into a decision someone made with their eyes open, which is a defensible position.
Failure mode: acceptance by silence. Circulating the profile is not acceptance.
What the finished artefact contains
- Boundary and period
- The operative claim, agreed
- Affected parties and concrete harms
- Failure modes mapped to harms
- Evidence grade per failure mode
- Consequence-ranked priorities
- Residual risk, with named acceptance
- What would change this assessment
The last item earns its place. An assessment that cannot be invalidated is not an assessment. Name the events — a model version change, a new population, a volume threshold — that would require this to be redone.
The test of a good profile
Hand it to someone competent who disagrees with you. If they can identify exactly where they disagree and what evidence would settle it, the profile works. If they can only say it “feels optimistic”, it is not an assurance artefact — it is an opinion with formatting.
Producing one of these, for a deployment context you have not seen before, is the core task assessed in the Certified AI Assurance Practitioner examination.