Putting a number on the risk of an AI automation can be useful. It can also create false confidence if nobody remembers where the number came from.
A risk calculator is best treated as a triage tool: it helps decide which cases deserve more scrutiny. It should not declare a system “safe” because it scored 8 instead of 12.
With AI, risk depends on more than the model. It depends on what data the system touches, what it may do on its own, how many people are affected, and how easily a bad decision can be corrected.
Define the decision before scoring it
“Use AI in finance” is too broad to evaluate. “Let a model suggest the accounting category for an invoice, with human approval before posting the entry” is concrete.
That is also very different from “allow an agent to approve and pay invoices below a threshold automatically.” Both use AI; the second has direct action authority and financial exposure.
A useful assessment starts by writing the workflow in one line: input → decision or action → affected person/system → ability to correct.
Four questions that change the level of review
| Factor | Practical question |
|---|---|
| Sensitivity | What data can the system see, and what harm could exposure or misuse cause? |
| Reversibility | If it is wrong, can the action be undone without lasting consequences? |
| Scale | Does an error affect one person or propagate to hundreds or thousands? |
| Rights / regulation | Does the decision touch employment, credit, health, essential services, or another regulated area? |
These are not the only possible factors. They are a simple enough starting point to keep the assessment from becoming a consulting project before the use case has even been tested.
The same AI can create very different risk
Case A: a model suggests a reply to a routine customer question. An employee reviews it before sending. The information is not especially sensitive and an error can be corrected with another message.
Case B: a system ranks job applicants and automatically rejects those below a threshold. The decision can affect employment opportunities, operate at scale, and be difficult for the rejected applicant to detect or challenge.
You do not need a sophisticated formula to see that Case B deserves stronger controls.
In the European Union, for example, the AI Act classifies specified uses in employment and recruitment as high-risk, subject to the regulation’s conditions and exceptions. That is a good example of why an internal score can never replace legal review for a real use case.
Do not mix risk with compliance
A workflow can be operationally low-risk and still violate a specific legal or contractual requirement. It can also satisfy a checklist and remain a bad idea.
Keep two layers separate:
- Risk assessment: what can go wrong, who is affected, and how serious it would be.
- Compliance review: which laws, contracts, internal policies, or regulatory commitments apply.
The NIST AI Risk Management Framework follows a similar logic: manage AI risk throughout the lifecycle and adapt practices to organizational context. NIST does not provide one universal number that certifies an automation.
Use a simple scale without pretending it is probability
If you need to compare several use cases, score each factor from 1 to 5. Read the result as a review priority, not a mathematical probability of failure.
Cases with sensitive data, low reversibility, and wide reach should escalate. If the workflow also touches rights or a regulated process, that may trigger legal review regardless of the total.
Some factors should act as flags, not numbers that can be averaged away. A serious discrimination risk does not disappear because implementation is cheap and vendor support is excellent.
What a useful assessment should produce
More than a red-yellow-green light, it should leave behind:
- a concrete description of the workflow;
- the factors that raised or lowered concern;
- assumptions that have not yet been tested;
- a named owner for the review;
- a date or condition for reassessment.
That makes it possible to understand the decision later when the model, data, integration, or user population changes.
When a spreadsheet is enough
For a small team with a handful of use cases, a shared sheet may be better than a dedicated platform. The habit matters more than the software: record the case, apply consistent criteria, document flags, and assign an owner.
A specialized platform becomes more useful when the organization has many assessments, several business units, approval chains, evidence requirements, history, and access controls. Buying it before the process exists often creates an elegant repository nobody maintains.
ScalarPivot’s AI Risk Calculator is designed as a first-pass filter. Use it to structure the conversation and identify where more scrutiny is needed—not as a compliance seal.
The goal is not to turn judgment into a number. It is to prevent an automation from reaching production before anyone has written down what can go wrong and who is responsible if it does.
