How to Do an AI Risk Assessment (Small Team Guide)

An AI risk assessment maps every AI tool in use, scores each use case by likelihood and impact, assigns concrete controls to high-priority risks, and produces a risk register you can show auditors, enterprise customers, and regulators. One person can complete a first-pass assessment in half a day.

At a glance: Four risk layers to assess — data exposure (prompts, training data), output quality (wrong or biased outputs), operational risk (vendor lock-in, outages), and compliance risk (GDPR, EU AI Act, sector-specific rules). Score each use case 1–9 (likelihood × impact). High-priority risks (score 6–9) need one concrete, verified control each. The output is a prioritised control backlog and a living risk register.

What you are assessing

An AI risk assessment covers four layers:

1. Data risk — what data could be exposed via AI tool usage (prompts, training, outputs)
2. Output risk — what harm could result from acting on bad AI output (wrong code, incorrect advice, biased decisions)
3. Operational risk — what happens if the tool disappears, changes pricing, or gets compromised
4. Compliance risk — which regulations you may be breaching through current AI use, even inadvertently

Step 1 of 7 — Map your AI use cases

List every AI tool your team uses (including shadow AI — tools people use without formal approval). For each tool, note:

Tip: Run a quick Slack poll or 1:1s to find shadow tools. You will almost always discover two or three not on the official list.

Data sensitivity classes to use:

• Public — no restrictions; can be shared externally
• Internal — confidential to the company but not regulated
• PII — personal data as defined under GDPR or equivalent privacy laws
• Regulated — health records, financial data, credentials, legal privilege, children's data
• Trade secret — proprietary models, source code with competitive value, unreleased product plans

Step 2 of 7 — Score each use case

Rate each use case on two dimensions:

Likelihood of harm (1–3):

• 1 = Low: tool handles only public or internal non-sensitive data
• 2 = Medium: tool sees confidential internal data, codebase, or aggregated customer data
• 3 = High: tool sees customer PII, regulated data, health data, or credentials

Impact if harm occurs (1–3):

• 1 = Low: embarrassment or minor rework
• 2 = Medium: customer complaint, contractual breach, or significant rework
• 3 = High: regulatory breach, data breach notification, legal liability, or reputational damage

Risk score = Likelihood × Impact

Step 3 of 7 — Regulatory risk overlay

Before moving to controls, run a quick regulatory check for each high-priority use case. Ask three questions:

Is this a high-risk AI system under the EU AI Act? High-risk categories include: employment and recruitment screening, credit scoring, access to education, law enforcement, critical infrastructure, and some healthcare applications. If yes, additional requirements apply (conformity assessment, human oversight, logging).

Does the tool process personal data under GDPR or equivalent? If yes, you need a lawful basis, a Data Processing Agreement with the vendor, and a record of the processing activity. Customer-facing AI tools almost always trigger this.

Does this use case involve automated decision-making with legal or significant effects? GDPR Article 22 and some sector rules require humans to be able to explain and override AI decisions that significantly affect individuals. Document your human review mechanism.

Record findings in a "regulatory flags" column in your risk register. You don't need legal sign-off for every flag — the goal is to ensure nothing is invisible.

Step 4 of 7 — Identify controls for high-priority risks

For each high-priority risk, assign one concrete control. Examples:

One control per risk is enough to start. Perfect coverage later beats no coverage now.

Step 5 of 7 — Build the control backlog

Translate your controls into tasks with owners and deadlines:

For each control, define verification: how will you know it is actually in place? A deadline without a check is just a hope.

Step 6 of 7 — Document and assign owners

For each control:

• Name the owner (a person, not a team)
• Set a deadline (30, 60, or 90 days)
• Define how you will verify it is in place

Use a simple spreadsheet. You do not need risk management software.

What makes a good control owner:

• Understands the technical context (not just the risk)
• Has the authority to make the change
• Is not so overloaded that a 2-hour task sits for 3 months

If no one owns it, it does not get done. Governance without owners is theatre.

Step 7 of 7 — Schedule your next review

Add a calendar reminder for:

• Monthly: check for new tools or use cases added since last review
• Quarterly: re-score existing risks with updated information; check control effectiveness
• Annually: full assessment refresh; re-check regulatory requirements; update threat model

Connecting to vendor due diligence

Your risk register should drive vendor evaluations, not the other way around. When a use case scores High on data risk, the vendor evaluation must verify:

• Where data is processed and retained
• Whether training on your data is opt-in or opt-out
• What happens to your data if you cancel

Use the AI vendor evaluation checklist to run this consistently. Link the completed checklist to the relevant row in your risk register so there is a clear paper trail.

Connecting to incident response

Your risk assessment predicts the most likely incidents. Your incident response plan should cover the top-three scenarios from your High-priority risks. When building or reviewing the AI incident response playbook, cross-reference the risk register: does each High risk have a corresponding response scenario?

Common mistakes to avoid

Skipping shadow AI. The tools you don't know about cause the incidents. Spend 30 minutes finding them before you write a single control.

Treating low-likelihood risks as zero. A 1-in-20 chance of a GDPR breach is not zero. Score it, assign a control, and move on.

Making controls too vague. "Train the team" is not a control. "All employees confirm AI policy annually with a signed acknowledgment" is a control.

Not assigning owners. A control without a named owner does not get implemented. If no one owns it, write "unowned" in the register and flag it for the next leadership review.

Treating the assessment as a one-time project. The risk landscape changes when you adopt new tools, enter new markets, or regulations update. Schedule reviews before they are needed.

Output of a good risk assessment

At the end of this process you should have:

• A use-case inventory (4–20 rows for most small teams)
• A risk register with scores, priorities, and regulatory flags
• A control backlog with owners and deadlines
• A vendor evaluation trail for high-risk tools
• A review schedule

That is your AI governance foundation. Everything else — policies, checklists, vendor reviews — plugs into this register.

Emerging risks to include in 2026

The risk landscape changes faster than most quarterly cycles. These categories were uncommon in assessments two years ago and are now appearing in small-team incidents:

Prompt injection via external inputs If your AI tool processes external content — emails, documents, web pages — an attacker can embed instructions in that content that hijack the model's behaviour. A customer service bot that reads emails is vulnerable if an attacker sends a crafted email instructing the bot to reveal system prompts or perform unintended actions. Control: input sanitisation; output review for unusual patterns; model instructions that explicitly reject overrides from input content.

Training data leakage via fine-tuned models If your vendor fine-tunes models on your data (even with an opt-in), and those models serve multiple customers, there is a theoretical risk that your data surfaces in responses to other users. Control: confirm your vendor's data isolation architecture in writing; prefer vendors where fine-tuned models are not shared across tenants. For a checklist of which major providers do not train on API data by default, see privacy-first AI APIs.

AI-generated disinformation about your brand or products Competitors or bad actors can use AI to generate reviews, social posts, or customer support content impersonating your brand. This is not a traditional data risk — it is a reputational risk that requires monitoring, not just internal controls.

Dependency on AI availability for critical workflows If a key workflow (customer support, code review, data processing) depends on a single AI provider, a service outage creates a business continuity risk. Control: document critical AI dependencies; test manual fallback procedures quarterly.

Add these categories to your use-case inventory as a "risk type" column so they are assessed systematically rather than as ad hoc additions.

Integrating risk assessment with your governance cadence

A risk register that is only updated annually becomes a historical artefact, not a governance tool. Connect it to the operating rhythm:

• Monthly: confirm no new high-risk tools have been added outside the inventory
• Quarterly: re-score risks that have changed (new tool features, team changes, new regulatory guidance); close completed controls; add emerging risks to the backlog
• After incidents: immediately re-assess the affected use case; add the incident to the risk register as evidence that the likelihood estimate was correct

The risk register also drives the AI usage audit — the audit's sampling phase should prioritise the highest-scoring risks in the register.

What a completed risk register looks like

A well-maintained register for a 15-person team typically has:

• 10–20 use-case rows
• 2–5 rows scored as High priority (6–9)
• 5–8 rows at Medium priority (3–5)
• 3–5 rows at Low priority (1–2)
• 80% or more of High-priority rows with a named control and owner
• At least one row added or updated in the last 30 days

If your register has 50 rows, it has grown beyond what a small team can meaningfully maintain — consolidate related use-cases into a single row with multiple controls. If it has fewer than 5 rows after a complete tool inventory, either the team uses very few AI tools (unlikely) or the inventory is incomplete.

Involving cross-functional teams in the assessment

The risk assessment is more accurate when it is not run by one person in isolation. Different roles bring different risk visibility:

Engineering: Knows which tools have API access to production systems, what data flows through model APIs, and which tools are integrated into automated pipelines (rather than just used by individuals).

Sales and marketing: Often the most active users of generative AI for customer-facing content. Knows where AI outputs go to customers without additional review. Likely aware of customer concerns or contractual restrictions that create compliance risk.

Operations / finance: Manages vendor relationships and contracts, which means they can access DPA status and data processing terms. Also aware of which AI tools have enterprise agreements with governance controls vs. consumer-tier terms.

Legal: Understands the regulatory requirements specific to your industry and geography. Essential for any use case involving automated decisions about individuals, regulated data, or cross-border data transfer.

HR: Knows whether AI is used in recruiting, performance management, or HR analytics — all of which carry heightened risk under EU AI Act, GDPR, and equal employment law in many jurisdictions.

A practical approach: send the draft use-case inventory to one person in each function with a single question: "What is missing or scored wrong?" You will get 3–5 additions from each, and the resulting register is far more complete than any individual could produce.

Communicating risk findings to leadership

Once the risk register is complete, you need to present findings in a way that drives action. Most leaders do not engage with spreadsheets of risk scores. The most effective format:

One page summary: Three to five sentences on the scope of the assessment, the number of tools reviewed, and the headline finding (e.g. "We identified three high-priority risks, of which two have no control assigned. The highest-priority risk is customer PII exposure via our AI support tool, which does not have a signed DPA.").

Top three risks, each with a proposed control and named owner: Leaders approve the control, not the risk — give them something to say yes or no to.

Two metrics to track over time: Risk count by tier and average time to close a control are enough to show the program is working.

A 10-minute leadership briefing with this format is more likely to produce resource allocation than a detailed risk register review.

Key Takeaways

• A small-team AI risk assessment maps data, output, operational, and compliance risk — not just technical vulnerabilities
• Score each use case on likelihood × impact (1–3 each) to get a 1–9 priority score
• Add a regulatory overlay for EU AI Act, GDPR, and sector-specific rules before assigning controls
• Each high-priority risk needs one concrete, verified control — not a vague "process improvement"
• Connect the register directly to vendor evaluations and the incident response plan so they reinforce each other
• For high-risk AI deployments, follow the risk register with a structured red team session to verify that controls hold under adversarial conditions
• Review quarterly; full refresh annually

References

1. National Institute of Standards and Technology — AI Risk Management Framework (AI RMF 1.0)
2. ISO — ISO/IEC 42001: AI Management Systems
3. European Parliament and Council — EU AI Act
4. OECD — OECD AI Principles
5. ICO — Guidance on AI and data protection
6. Related: Red Teaming AI Systems: A Governance Guide — structured adversarial testing to verify risk controls hold under attack conditions before deployment
7. Related: AI Governance for Small Teams: Complete Guide — the full framework this risk assessment fits into, with sector-specific compliance requirements and the complete implementation checklist