How do we conduct an AI risk assessment for a new use case?

Conducting an AI risk assessment for a new use case starts by clearly defining what the system will do, who it affects, and what happens if it produces a wrong or biased output, since the risk profile of an internal drafting assistant is entirely different from a system that screens job applicants or prices insurance. The next step is classifying the use case against a recognized risk tier, whether the EU AI Act's unacceptable, high, limited, and minimal categories or an organization's own risk matrix, followed by mapping what data flows into and out of the system and how sensitive it is. The assessment should then evaluate both technical risks, such as hallucination rate, bias across different groups, and exposure to prompt injection, and legal or regulatory risk specific to the jurisdiction and industry involved. Every identified risk needs a documented mitigation and an honest statement of the residual risk remaining after mitigation, since no AI system reaches zero risk, and the assessment should require sign-off from a governance committee before launch rather than being treated as a formality. Material changes to the model, data, or use case should trigger a fresh assessment rather than relying on the original one indefinitely. Nanobase AI runs this structured risk assessment process before deploying any new AI use case for a client.

A risk assessment is a scoring exercise, not a narrative

An AI risk assessment written as a paragraph describing why a use case seems reasonably safe is hard to compare across projects and easy to write around when a stakeholder is eager to launch. Scoring the use case on defined likelihood and impact dimensions, then mapping that score to a required set of controls, produces a consistent and auditable result that a narrative assessment does not.

A likelihood-by-impact scoring rubric

Impact should be scored against concrete criteria specific to the use case, such as whether an error affects one person or many, whether it touches a legal or financial outcome, and whether it involves sensitive categories of data; likelihood should reflect the model's known error rate for this task type and how much unreviewed autonomy the system has. A use case scoring in the elevated tier typically requires the full control set described below, while a minimal-tier use case, such as an internal drafting assistant with human review of every output, needs proportionately less.

The five-gate workflow

1. Intake. The requesting team submits a description of the use case, the data it touches, and who is affected, feeding into the organization's broader AI governance intake process.
2. Classification. The governance committee scores likelihood and impact using the rubric above, or against the EU AI Act's own risk tiers if the use case falls within its scope, as covered in is our chatbot high-risk under the EU AI Act.
3. Mitigation design. For every identified risk, the team documents a specific mitigation and the residual risk remaining after it, since no AI system reaches zero risk.
4. Sign-off. The governance committee reviews the completed assessment and mitigations, approving, rejecting, or requiring changes before development proceeds to production.
5. Post-launch monitoring. The use case is re-assessed on a defined schedule, or immediately if the model, data, or use case changes materially, rather than relying on the original assessment indefinitely.

Common mistakes that get an assessment reopened

A frequent mistake is scoring impact based on the intended use case rather than realistic misuse, which understates risk for systems that are easy to repurpose beyond their original design. Another is treating the assessment as complete once mitigations are documented, without verifying the mitigations were actually implemented as described before launch, which leaves a gap between the paper assessment and the deployed system. A third is skipping re-assessment after a model upgrade, on the assumption that a newer, presumably better model carries the same or lower risk, when model changes can shift error patterns in ways the original assessment never evaluated.

Frequently asked questions

How does this risk assessment relate to a DPIA?

They overlap where personal data is involved but are not identical; the risk assessment here covers the full range of AI risk including bias, hallucination, and operational failure, while a DPIA specifically addresses privacy risk to individuals under GDPR, and a single use case often needs both.

Should low-risk use cases skip the assessment entirely?

A lightweight version of the intake and classification steps should still run for every use case, since skipping the process entirely for anything assumed to be low-risk is exactly how a genuinely higher-risk use case slips through unclassified.

What triggers a re-assessment after launch?

A change to the underlying model, a change in the data the system processes, an expansion of the use case beyond its original scope, or a defined periodic review interval should all trigger a fresh assessment rather than relying on the original approval indefinitely.

How Nanobase AI helps

Nanobase AI runs this structured, scored risk assessment process before deploying any new AI use case for a client, building the mitigation plans and monitoring cadence into the AI governance program rather than treating the assessment as a one-time approval formality.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.