A useful business AI risk assessment explains what could go wrong in a specific task, who could be affected, what checks make the use acceptable and what remains uncertain. It ends in a reasoned decision with limits and a review trigger. A score on its own cannot provide that explanation.
Define a proposal that can be assessed
Our fictional wholesaler wants AI to turn approved product specification sheets into draft catalogue descriptions. An editor will verify every factual statement against the current specification before publication. The tool will not set prices, invent performance claims or publish directly. The supplier and account configuration still need checking.
The desired benefit is less time assembling a first draft. That is an assumption to test, not a measured saving. The business outcome is an accurate description produced with less total effort, including preparation, checking and correction.
Identify whose interests matter: customers relying on a specification, colleagues handling returns, and the business making the claim. Record the source material, account used and destination of the output. A change from catalogue drafting to personalised customer advice would need its own assessment.
Follow a plausible error through to its consequence
The assistant combines two similar models and adds a capacity that belongs to the other one. If the editor sees only fluent prose, the mistake could reach the catalogue and affect a purchase. The safeguard must therefore help the editor verify the model and its source, not simply ask them to read for quality.
A second failure is an obsolete specification. The output may accurately repeat the wrong source. Put somebody in charge of maintaining the approved source set and withdrawing superseded sheets. Model accuracy alone cannot solve a document-control problem.
A third failure is review becoming impractical. During a busy period, editors may lack time to trace every claim. Treat reviewer capacity as part of the operating conditions. If the check cannot be completed, return to the manual process or reduce throughput; do not silently remove the safeguard to preserve the promised saving.
Finally, consider supplier dependency. Establish what happens if the service is unavailable or its output changes. Keep a usable manual process and the source material outside the assistant so the business can continue.
Test the safeguard rather than assuming it works
Prepare a small, representative set of product sheets with similar model names, missing specifications, conflicting versions and a request for an unsupported claim. Decide in advance which failures prevent approval. For this proposal, any published factual statement without verified source support is unacceptable.
Have the intended editor complete the task using the proposed workflow. Record wrong claims, omissions, time spent finding evidence and whether the reviewer notices the deliberately difficult cases. Keep the source version and the test conditions with the results so the team can repeat the check after a change.
A successful sample does not prove all future outputs will be correct. It can show whether a limited trial is justified and whether the review process is usable. If the reviewer repeatedly misses a particular error, redesign the task or stop the proposal. Writing “human in the loop” does not repair it.
Record the decision and the unresolved conditions
Fictional worked record
- Proposal
- Draft catalogue descriptions from the approved current product sheets; editor publishes only after source verification.
- Current decision
- Proposed supervised trial. Not yet approved: supplier checks and representative testing remain outstanding.
- Failure to control
- Unsupported or obsolete product claims reaching customers.
- Required checks
- Editor verifies each claim and model against its source; source owner maintains current sheets; manual fallback remains available.
- Evidence needed
- Test outputs, corrections, reviewer results and total task time. No benefit result is asserted yet.
- Owner
- Catalogue manager can pause the trial; commercial lead accepts any remaining business risk within established authority.
- Review trigger
- Trial completion, supplier change, new product category, source changes, missed factual error or insufficient review capacity.
When the evidence arrives, record what changed the decision. Approval might be limited to one category and one trained editorial team. Widening the audience or permitting direct publication would be a new decision. Name the person who checks whether a trigger has occurred.
This operational assessment is separate from EU AI Act classification and any data protection assessment. A low operational score is not a legal risk category. Where personal-data processing is likely to create high risks for individuals, a DPIA may be required; use the DPC guidance linked below to assess that question.
For ownership and escalation, read AI governance in practice. The assessment is only useful if somebody can act on its conditions.
Sources and scope
See the DPC guide to Data Protection Impact Assessments for the GDPR assessment requirement, and the NIST AI Risk Management Framework for broader voluntary risk-management guidance. This example is Acuity’s original practical illustration, not a prescribed legal or certification template.
Written by Acuity AI Advisory. AI Register Ireland is owned and operated by Acuity. Examples are invented for this guide; they are not client cases or measured outcomes. This is practical governance guidance, not a legal assessment of your organisation.
Source links and product references checked on 2 October 2026.