AI Risk Assessment Template: Decide What Must Be Fixed Before Launch

AI Risk Assessment Template: Decide What Must Be Fixed Before Launch

An AI risk assessment template turns one proposed AI use case into a documented launch decision. It records the business purpose, people and data affected, likely harms, existing controls, evidence, accountable owners and review dates. The output should be go, conditional go or stop, never a vague score without action.

Updated August 23, 2026

TL;DR: Assess a specific use case, not AI in the abstract. Write down the decision the system will support, who could be affected, which information it will receive, what happens when it is wrong and who can stop it. Score likelihood and impact separately, but do not treat multiplication as judgment. Require evidence for every important control. Low-risk drafting assistance may pass with approved tools, data rules and human review. Customer decisions, sensitive information, money movement, safety or employment decisions need deeper review and may require qualified legal, privacy or security advice. Finish with one of three outcomes: go, conditional go with named actions, or stop. Reassess after material changes and real incidents.

What is an AI risk assessment template?

An AI risk assessment template is a working document used to decide whether a particular AI use case is safe and sensible enough to launch. It connects the intended business result to possible harm, controls, evidence, ownership and a review date.

The phrase particular use case matters. “Our company uses AI” is too broad to assess. “The support team uses an approved assistant to draft replies, but a trained employee reviews every message before it is sent” is specific enough. It identifies the team, task, tool, output, reviewer and point of control.

A useful assessment should answer seven questions:

• What business result are we trying to improve?
• What exactly will the AI produce, recommend or decide?
• Which employees, customers, suppliers or other people could be affected?
• What business or personal information will enter the system?
• What could go wrong, and how serious would the consequence be?
• Which controls reduce that risk, and what evidence proves they work?
• Who can approve, pause, change or retire the use case?

The assessment is not a compliance certificate. It does not prove that a system is lawful, fair or secure. It creates a disciplined record that helps business leaders spot missing decisions before those gaps become customer complaints, data exposure, financial loss or operational disruption.

NIST describes its AI Risk Management Framework as voluntary guidance for improving how organizations include trustworthiness in the design, development, use and evaluation of AI systems. Its practical sequence is to govern, map, measure and manage risk throughout the lifecycle. Source: NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, published July 26, 2024, updated April 8, 2026 and accessed August 23, 2026.

For a smaller business, the lesson is simple: do not build an enterprise committee before you can describe the use case. Start with one owner, one worksheet and one real launch decision. Add specialist review when the consequences demand it.

Why should a business assess AI risk before launch?

AI adoption often begins with individual experimentation. A manager finds a useful tool, an employee connects a document, or a team adds an AI feature already included in software it pays for. The business can receive value quickly, but ownership, data rules and review controls may lag behind.

The gap is visible in current research. ISACA's 2026 AI Pulse Poll surveyed more than 3,400 digital trust professionals and reported that only 38% of organizations had comprehensive AI policies. Only 11% of respondents strongly agreed that their organizations gave sufficient attention to ethical standards in AI implementation. Source: ISACA, 2026 AI Pulse Poll, published May 5, 2026 and accessed August 23, 2026.

Policy alone is not enough, but the figures show why managers cannot assume that somebody else has already set the rules.

Microsoft and LinkedIn's 2024 Work Trend Index found that 75% of global knowledge workers were using AI at work and that 78% of AI users brought their own AI tools to work. The survey covered 31,000 people across 31 countries. Source: Microsoft and LinkedIn, 2024 Work Trend Index Annual Report, published May 8, 2024 and accessed August 23, 2026.

Those figures do not mean every personal AI tool creates a disaster. They mean the real starting point may be wider than the approved software list. An assessment forces the team to identify what is actually happening, which information enters which tool and who owns the outcome.

IBM's 2025 Cost of a Data Breach research covered 600 organizations that had experienced breaches. Among organizations reporting an AI-related security incident, 97% said they lacked proper AI access controls. The report also found that 63% of the breached organizations either lacked an AI governance policy or were still developing one. Source: IBM, Cost of a Data Breach Report 2025, published July 30, 2025 and accessed August 23, 2026.

Do not use a global breach average to predict your own loss. Use the evidence to ask better local questions. Could an employee paste a customer list into an unapproved service? Can a former contractor still access the AI workspace? Does the tool retain prompts? Can a customer-facing output be sent without review? Can the business reconstruct why a recommendation was accepted?

The cheapest risk to fix is the one found before launch.

When does an AI use case need a formal assessment?

Run a documented assessment before launch when AI touches a material business decision, sensitive information or a person outside the team. The depth should match the consequence.

A lightweight review may be enough when the system drafts internal meeting summaries from non-sensitive information and a person checks the result. A deeper review is appropriate when the system influences hiring, credit, pricing, eligibility, health, safety, legal positions, money movement, customer commitments or access to essential services.

Use these triggers:

• The tool receives customer, employee, financial, health, confidential or regulated information.
• The output affects a person's opportunity, treatment, price, access or employment.
• A wrong output could cause financial loss, physical harm, discrimination, privacy harm or serious reputational damage.
• The system acts automatically or sends content without human approval.
• The AI comes from a vendor whose data use, retention or change process is unclear.
• The result is hard to reverse after it reaches a customer or another system.
• The team cannot explain how success and failure will be measured.
• The use case changes a process that already carries legal, contractual or safety duties.

Also assess existing use cases when the tool, data, purpose, affected population or level of automation changes. Moving from “draft a reply” to “send the reply” is a material change. Adding customer records to a tool previously used only for public information is another. A vendor changing its model or retention terms may also justify review.

Do not hide behind the label “pilot.” A small pilot can still expose real data or affect real people. Bound the pilot by user count, duration, data type, allowed actions and stop conditions. A pilot is controlled learning, not permission to skip controls.

What information should you collect before scoring risk?

Scoring too early creates false precision. First build a clear picture of the use case.

Record the business purpose in measurable terms. “Use AI for support” is weak. “Reduce the time required to prepare a first reply while maintaining the current quality and escalation standard” is testable. Name the baseline, target and time window.

Describe the workflow from input to action:

• Who starts the task?
• What information enters the AI tool?
• What does the tool produce?
• Who reviews the output?
• What action follows?
• Where is the result stored?
• Who monitors exceptions?

List every relevant party. That includes the business owner, day-to-day users, people affected by outputs, the tool provider, connected software providers and the person responsible for privacy or security. If the business does not have specialist roles, name the external adviser or senior owner who will review high-consequence issues.

Create a simple data inventory. Classify inputs as public, internal, confidential, personal, sensitive personal, customer-owned or restricted by contract. Record whether the provider can retain, train on, share or process the information in another location. Do not accept “the vendor is secure” as evidence. Link to the contract term, setting, assurance report or documented provider answer that supports the conclusion.

Define the human role precisely. “Human in the loop” is decorative language unless the reviewer has time, information, competence and authority to reject the output. State when review happens, what the person checks, how disagreement is handled and whether the system can proceed without approval.

Finally, collect the current safeguards. These may include approved accounts, access restrictions, data filtering, a review checklist, customer disclosure, logging, output sampling, incident handling, vendor commitments and a manual fallback. The assessment should evaluate real controls, not planned controls presented as finished.

Which AI risks should a non-technical manager examine?

Use plain business categories. The goal is not to sound sophisticated. It is to notice how the use case could fail.

Accuracy risk asks whether the system could produce incorrect, incomplete or invented information. The consequence depends on the task. A weak internal headline is annoying; an invented refund promise or wrong eligibility decision is material.

Data and privacy risk asks whether the system receives information it should not receive, keeps it longer than expected, exposes it to the wrong person or uses it for a different purpose. Check both employee behavior and vendor terms.

Fairness risk asks whether performance or outcomes differ across relevant groups. This matters especially when the output affects access, opportunity, pricing or treatment. Historical data can contain old patterns that should not become future policy.

Security risk asks who can access the system, whether accounts are shared, how access is removed, what connected tools can do and what happens if a prompt, document or output is malicious or exposed.

Operational risk asks whether the business can continue when the AI is unavailable, slow or wrong. A manual fallback, clear escalation route and limit on automated actions can prevent one failure from stopping the wider process.

Customer and reputation risk asks whether people know when AI is involved, whether the output matches the company's promises and whether a complaint can reach a responsible person. A technically accurate answer can still be inappropriate, confusing or off-brand.

Vendor risk asks whether the provider can change the product, model, price, data practice or service level in a way that affects the business. Record data rights, deletion, support, incident notification, subcontractors, portability and exit options.

Legal and contractual risk asks whether the use case is affected by laws, sector rules, employment duties, consumer promises or customer contracts. A general template cannot answer that question for every business. Use qualified advice when the consequence or uncertainty is material.

The NIST Generative AI Profile groups practical concerns such as confabulation, privacy, information security, harmful bias, human over-reliance and value-chain integration. It also emphasizes actions across governance, mapping, measurement and management rather than treating risk as a one-time checklist. Source: NIST AI 600-1, Generative Artificial Intelligence Profile, published July 2024 and accessed August 23, 2026.

What should the AI risk assessment template contain?

Copy the fields below into a spreadsheet or document. Add links to evidence rather than writing unsupported “yes” answers.

Write risk statements in a cause-event-consequence form. For example: “Because support agents can paste customer records into an unapproved assistant, confidential information could be retained outside the approved environment, causing contractual, privacy and trust harm.” That statement is easier to control than “data risk: high.”

The template should also record assumptions. If the team believes every output will be reviewed, state how review is enforced and measured. If it believes the vendor does not train on business data, link to the contract or setting. An assumption without evidence is an open action, not a completed control.

How should you score likelihood and impact without fooling yourself?

Use a small scale and write the reason behind every rating. A three-point scale is usually enough for a manager-led assessment.

Likelihood can be:

• Low: the failure is unusual under normal use and effective controls have been tested.
• Medium: the failure is plausible, controls depend on people or evidence is limited.
• High: the failure is expected, has already occurred or controls are missing.

Impact can be:

• Low: limited inconvenience, easily corrected, no sensitive information or material external effect.
• Medium: customer complaint, rework, limited financial loss, contract concern or temporary disruption.
• High: serious harm to a person, material financial loss, sensitive data exposure, legal consequence, safety issue or major operational interruption.

You may multiply likelihood by impact to create a priority number, but do not let arithmetic approve the use case. Some consequences require a hard stop even when the estimated likelihood is low. A rare safety event, unlawful decision or exposure of highly sensitive information cannot be averaged away.

Score inherent risk before new controls and residual risk after controls are verified. This prevents the team from confusing an important risk with a badly controlled risk. A high-consequence use case may proceed only with strong safeguards and appropriate approval; a moderate use case with no owner may still need to stop.

Test with representative examples. Include ordinary cases, edge cases, incomplete information, conflicting instructions and situations where the right answer is to escalate. If different customer groups may experience different outcomes, inspect results by those groups. Record sample size, date, tool version, pass criteria and failures.

Do not bury disagreement. If sales rates impact low and customer operations rates it high, record both views and resolve the underlying assumption. The disagreement may reveal that one team sees a recovery route the other does not.

Which controls should be required before an AI launch?

Choose controls that change the workflow, not statements that merely express good intentions.

Start with access. Use approved business accounts, limit permissions to the people who need them and remove access when roles change. Avoid shared accounts. Keep a current list of users and connected systems.

Control the data. State which information may and may not enter the tool. Where possible, remove unnecessary personal or confidential information before processing. Confirm provider retention, training and deletion settings. Restrict exports and connected actions to the minimum needed.

Define human review. Name the reviewer, review point and rejection criteria. Give the reviewer enough context and time to challenge the output. High-volume work with impossible review targets is not meaningfully supervised.

Set action limits. A drafting tool should draft, not silently send. A recommendation tool should not change a customer's price or status without the approved decision process. Limit transaction value, audience size or action type until the evidence supports expansion.

Add monitoring. Sample outputs, track overrides, record complaints, watch for data exposure and compare the business measure with the baseline. Monitor both benefit and harm. A faster process that creates more corrections is not an improvement.

Prepare recovery. Keep a manual fallback, incident contact, pause mechanism and record of what the AI changed. The team should know how to stop the workflow and how to correct affected records or communications.

Review the vendor. Ask who can access data, where it is processed, how long it is retained, whether it trains provider models, how changes are communicated and how the business can export or delete its information. Match the depth of review to the consequence.

IBM's 2025 report found that organizations with high levels of shadow AI had an average of $670,000 more in breach costs than organizations with low or no shadow AI. The same research reported that 60% of AI-related security incidents led to compromised data and 31% led to operational disruption. Source: IBM, 2025 Cost of a Data Breach findings, published July 30, 2025 and accessed August 23, 2026.

Those are enterprise breach findings, not a price tag for your business. Their practical value is to show that access, approved-tool use and operational recovery belong in the launch decision.

How do you make a go, conditional-go or stop decision?

Do not end the assessment with “medium risk.” End with an accountable decision.

Choose go when the business purpose is clear, the use case is bounded, important risks have tested controls, residual risk fits the business's tolerance and monitoring has an owner. Record the approver and next review date.

Choose conditional go when the use case can proceed only after named actions are completed. Each condition needs an owner, due date, evidence and verification step. “Improve security” is not a condition. “Restrict the workspace to six approved support users, disable provider training on business data and attach a screenshot plus administrator sign-off before the pilot starts” is testable.

Choose stop when the purpose is weak, sensitive data use is unjustified, the consequence is unacceptable, controls cannot be verified, ownership is missing or the team lacks the expertise to make the decision. Stop can mean redesign, seek qualified advice, choose another tool or abandon the use case.

Set explicit hard stops before testing. Examples include sending confidential information to an unapproved service, allowing an AI output to make a prohibited decision, launching without a manual fallback for an essential process or failing to identify who can pause the system.

Document dissent and unresolved questions. A senior person's enthusiasm is not evidence. If the assessment team cannot agree because facts are missing, the correct status is conditional or stop until those facts exist.

Finally, separate launch approval from scale approval. A ten-user pilot with sampled outputs is not evidence for company-wide automation. Define what the pilot must prove, which incidents cause a pause and which results justify expansion.

What should the first 30 days after approval look like?

The assessment continues after launch because real use reveals behavior that a workshop cannot predict.

In week one, keep the scope narrow. Confirm that only approved users have access, prohibited data is not entering the tool, reviews happen at the promised point and the manual fallback works. Inspect every important exception.

In week two, compare output quality with the baseline. Measure accuracy, correction rate, review time, escalations and the business outcome. Ask affected employees where the process creates pressure to bypass controls.

In week three, inspect impact and incidents. Look for customer complaints, unexpected group differences, confidential information, wrong actions, access problems and vendor changes. Test whether logs and recovery records are complete enough to investigate a problem.

In week four, make a scale, change or stop decision. Expand only if the use case delivers the intended result and controls work under real conditions. Update the assessment with evidence, failures, changes and the next review date.

Review again after a material change, significant incident, new data source, broader user group, higher level of automation or important vendor update. A calendar review every quarter or six months may also fit, but event-based review matters more than ceremony.

Keep the risk register live. Close actions only when evidence is attached. Retire use cases that no longer produce enough value to justify their cost and oversight. Good governance is not paperwork around permanent software; it is the ability to change course when the facts change.

How does Wavicle turn the assessment into a safer working system?

Wavicle starts with the business workflow. We clarify the result, baseline, affected people, data, decision points and current failure modes before recommending a tool or build.

For a proposed AI use case, we can help create the assessment record, map the workflow, define review gates, identify the smallest useful pilot and turn vague concerns into testable conditions. The business still owns the risk decision, and qualified legal, privacy or security specialists should handle questions that require their judgment.

Next, we translate approved controls into the operating process. That can include access rules, allowed-data checks, human approval steps, action limits, logging, alerts, fallback routes and a simple monitoring dashboard. The point is not to produce an impressive document. The point is to make the approved behavior the easiest behavior.

We also define acceptance measures before implementation. A support-drafting pilot might track preparation time, correction rate, escalation quality, customer complaints and prohibited-data events. A sales assistant might track research time, factual corrections, opt-out handling and manager approval. The measures must cover both value and harm.

If the assessment shows that the use case is not ready, that is useful. Fixing the workflow, data or ownership first is cheaper than automating confusion. If the case is sound, the assessment becomes the launch plan and evidence checklist.

If you have an AI use case but no defensible go or stop decision, book a free AI workflow and risk review with Wavicle. Bring the proposed workflow, tool and data types. We will help identify the smallest safe pilot, the controls it needs and the business result it must prove.

What are the frequently asked questions about AI risk assessments?

Is an AI risk assessment the same as an AI policy?

No. An AI policy sets organization-wide rules such as approved tools, prohibited data, human review and accountability. A risk assessment applies those rules to one specific use case and records its purpose, harms, controls, evidence and launch decision. Most businesses need both, but they do different jobs.

Is an AI risk assessment the same as an AI readiness assessment?

No. Readiness asks whether the organization has the strategy, data, people, process and governance needed to adopt AI. Risk assessment examines one proposed use case in detail. A business can be generally ready for AI and still reject a particular high-risk or poorly controlled use case.

Who should own the AI risk assessment?

The business owner who benefits from the use case should remain accountable. Process, data, privacy, security, legal, HR or finance owners may contribute depending on the consequence. Do not assign the entire decision to an IT administrator or vendor that does not own the business outcome.

How often should an AI risk assessment be updated?

Update it after material changes to the tool, model, data, purpose, users, affected population or level of automation. Review after incidents and before scaling a pilot. A regular quarterly or six-month review can help, but event-based review is essential.

Can a small business use a spreadsheet for AI risk assessment?

Yes. A well-owned spreadsheet with clear fields, evidence links, actions and review dates is better than expensive governance software nobody maintains. Move to a specialized system only when the number of use cases, reviewers, obligations or evidence records makes the spreadsheet unreliable.

Does a low risk score mean the AI use case is safe?

No. The score is a prioritization aid, not proof. Check the written reason, quality of evidence, hard-stop conditions and residual risk. Some severe consequences require stronger approval or rejection even when estimated likelihood is low.

Can the AI vendor complete the assessment for us?

The vendor should provide evidence about its product, data handling, security, changes and support. It cannot decide how your workflow affects customers, employees, contracts or business operations. Treat vendor answers as inputs to your decision, not as independent approval.

What is the safest AI use case to assess first?

Start with a bounded internal task using non-sensitive information, limited users, human review and an easy manual fallback. The use case should have a measurable business result and low consequences when an output is wrong. Use the first assessment to build the team's decision habit before tackling higher-consequence work.