---
title: "AI risk: the risks your firm actually carries when it uses AI"
canonical: https://www.grcmana.io/vault/ai-governance/ai-risk
published: 2026-10-23
updated: 2026-10-23
author: "Harry West"
framework: "AI Governance"
control: "Guide AI risk: the risks your firm actually carries when it uses AI"
journeyStage: fundamentals
---

# AI risk: the risks your firm actually carries when it uses AI

## Key takeaways

AI risk is the chance that an AI system a firm builds, buys or lets staff use causes legal, data, output, supplier, operational, security or reputational harm. Most of it extends risks the firm already manages. Whether the firm is a provider or a deployer decides which risks it carries, and each category belongs in the existing risk register with a named owner.

- **Provider or deployer** — Under EU AI Act Article 3, a provider develops an AI system and places it on the market under its own name. A deployer uses one under its authority.
- **DPIA trigger** — The ICO says that in the vast majority of cases, using AI involves processing likely to result in a high risk to individuals, so a UK GDPR DPIA is required.
- **EU reach** — The EU AI Act covers providers placing AI on the EU market wherever they are based, and non-EU providers and deployers whose AI output is used in the EU.
- **AI literacy** — EU AI Act Article 4 asks providers and deployers to take measures to support their staff's AI literacy. The Commission says no specific level is mandated and no certificate is needed.

Your product team has shipped an AI feature, half the company uses an AI assistant, and an enterprise customer's security review now asks a new question: what are your AI risks, and who owns them? AI risk sounds like a new discipline. For most firms of 25 to 250 people, it is mostly the risk you already manage, arriving through a new channel.

This guide gives founders, CTOs and security leads at UK B2B tech firms a short list of AI risk categories, a worked example for each, and a way to record them in the risk register you already run, with an owner and the evidence a customer will ask for.

## What is AI risk?

AI risk is the chance that an AI system you build, buy or let staff use causes legal, operational, data, third-party or security harm to your firm or its customers. Most of it extends risks you already carry. The job is to name the categories, give each one an owner and record them in your existing risk register.

The risks of AI are not exotic for a 50-person software firm. A wrong answer in a customer-facing feature is a product defect. Customer data sent to a model provider is a data protection question. An AI feature switched on inside a tool you already pay for is a supplier change. What differs is how these risks behave.

Four properties make AI risk harder to manage than ordinary IT risk:

- **Probabilistic outputs.** The same input can produce different answers. The NCSC notes that generative AI "can get things wrong and present incorrect statements as facts", the flaw known as hallucination. You cannot test every output in advance.
- **Change over time.** A model provider can update the model under your feature without a release on your side, and performance can drift as the data it sees changes.
- **Opacity.** It is often hard to explain why a model produced a given output, which matters when a customer or a regulator asks.
- **Embedded vendor AI.** Much of the AI in your firm arrives inside software you already use, so it never passes through a procurement decision.

None of this calls for a separate AI risk method. It calls for an honest list of where AI touches your firm.

## Does AI risk depend on whether you build or use AI?

Yes. Under the EU AI Act, your role decides your obligations. A provider develops an AI system and places it on the market under its own name. A deployer uses an AI system under its own authority. Most UK tech firms deploy the AI tools their staff use and provide any AI feature they sell under their own name.

The definitions in Article 3 of the [EU AI Act](https://www.grcmana.io/vault/eu-ai-act) are precise. A provider "develops an AI system or a general-purpose AI model or that has an AI system or a general-purpose AI model developed and places it on the market or puts the AI system into service under its own name or trademark". A deployer is a person or body "using an AI system under its authority", outside personal, non-professional use.

The Act's reach into the UK is real but bounded. Article 2 covers providers placing AI systems on the EU market "irrespective of whether those providers are established or located within the Union or in a third country". It also covers providers and deployers outside the EU "where the output produced by the AI system is used in the Union". A UK firm with no EU customers and no EU-facing AI output may sit outside it entirely.

The same role split is useful even where the Act does not apply, because it shows which risks you create and which you inherit:

| Your role | Typical example | Risks you mainly carry |
| --- | --- | --- |
| Provider | An AI summary feature in the product you sell | Output quality, transparency to customers, how the model was chosen and tested, change control |
| Deployer | A meeting assistant or coding tool your staff use | Data handling, acceptable use, staff training, supplier terms |
| Both | An AI feature built on a third-party model API | All of the above, plus dependency on the model provider |

Under UK GDPR the same thinking applies to personal data. The ICO expects your DPIA to set out "your roles and obligations as a controller", and where AI is outsourced, to consider whether joint controllership exists.

## What are the main categories of AI risk?

Seven categories cover the AI risk a 25 to 250-person firm realistically carries: legal and regulatory, output and liability, data, third-party and embedded vendor AI, operational and resilience, security, and reputational and customer trust. Each one already has a natural owner in your firm. The table gives the short version.

| Category | Natural owner | Regime that makes it a liability | Evidence a customer will ask for |
| --- | --- | --- | --- |
| Legal and regulatory | COO or DPO | UK GDPR; EU AI Act where it reaches you; FCA rules for financial services clients | AI use register, DPIAs, role assessment |
| Output and liability | Head of product | Contracts, consumer and data protection law | Testing records, human review points, customer terms |
| Data | DPO or security lead | UK GDPR, customer contracts | Data flow maps, vendor training and retention terms |
| Third-party and embedded vendor AI | Supplier owner | UK GDPR processor rules, contracts | Supplier assessments, sub-processor list |
| Operational and resilience | CTO | Service levels, contracts | Fallback plans, model change monitoring |
| Security | Security lead | Contracts, UK GDPR security duty | AI coverage in security testing and policy |
| Reputational and customer trust | CEO | None directly; it shows up in renewals and deals | Published AI statement, consistent answers |

### Legal and regulatory risk

Legal and regulatory AI risk is the chance that your use of AI breaks a law that already applies to you. For most UK firms that is UK GDPR first. The ICO says "in the vast majority of cases" AI use involves processing "likely to result in a high risk", which triggers a DPIA.

**Worked example.** You add an AI feature that scores support tickets by customer sentiment. It processes personal data in a new way, so a DPIA is due before launch, and the ICO's [guidance on AI and data protection](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/) sets out what it should cover. If EU customers use the feature, the EU AI Act may also apply to you as a provider. Its Article 4 already asks providers and deployers to "take measures to support the development of AI literacy" among staff. The Commission's [AI literacy Q&A](https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers) confirms there is no required level and "no need for a certificate".

If you serve financial services clients, their regulator matters too. The FCA says it does "not plan to introduce extra regulations for AI" and relies on existing frameworks, such as the Consumer Duty and the Senior Managers and Certification Regime. Those duties reach your clients and, through their contracts, you.

### Output and liability risk

Output risk is the chance that an AI system gives a wrong, biased or unexplainable answer that your firm is responsible for. A customer-facing feature carries your name, not the model provider's. Whoever ships the feature answers for what it says.

**Worked example.** Your AI assistant tells a customer that a feature includes data export when it does not, and the customer relies on it in a procurement decision. The fix is ordinary product discipline: test outputs against known answers, mark where a human reviews before anything binding is said, and make your customer terms describe what the feature is and is not.

Bias belongs here too. The ICO's guidance treats fairness as a data protection matter, including the sources of bias and how to mitigate them. The question of who answers when it goes wrong is covered in [AI accountability](https://www.grcmana.io/blog/ai-accountability).

### Data risk

Data risk is the chance that information entered into, or produced by, an AI system ends up somewhere it should not: used for training, retained longer than agreed, or exposed to people without the right to see it. It is the category closest to your customers, because it touches their data directly.

**Worked example.** An engineer pastes a customer's database extract into a public AI assistant to debug a query. The vendor's consumer terms allow the input to be used to improve the service. Nobody broke a rule, because no rule existed. Two controls close the gap: an acceptable use policy that names which data may go into which tools, and a short list of approved tools whose business terms exclude training on your inputs. Our [shadow AI guide](https://www.grcmana.io/blog/shadow-ai-governance) covers finding the tools already in use.

### Third-party and embedded vendor AI risk

Third-party AI risk is the chance that a supplier adds AI to a service you already use, or relies on a model provider you have never assessed, and changes how your data is handled. It is the easiest category to miss, because no purchase order marks the moment it arrives.

**Worked example.** Your CRM vendor switches on AI call summaries by default. The summaries are generated by a model provider that now appears as a new sub-processor on the vendor's list. Your supplier assessment from last year does not mention it. The NCSC's board questions include whether you understand "your data, model and ML software supply chains" and can ask suppliers the right questions.

The treatment sits in your existing [third-party risk management](https://www.grcmana.io/vault/risk-management/third-party-risk-management) process. We recommend adding two questions to supplier reviews: which AI features are enabled, and which model providers process your data.

### Operational and resilience risk

Operational AI risk is the chance that an AI-dependent process fails, degrades or changes without warning. The common causes are dependency on a single model provider, a model update that changes behaviour, drift in output quality over time, and provider outages or price changes that break a feature's economics.

**Worked example.** Your product's document classification runs on one provider's model. The provider retires the model version you tested, and the replacement classifies a category of contract differently. Customers notice before you do. The treatment is the same as for any critical dependency: monitor output quality against a fixed test set, treat a change of model version as a change you approve where the provider allows it, and decide in advance what the feature does if the model is unavailable.

### Security risk

Security risk is the chance that an AI system is attacked, misused or becomes a route into your environment. For a risk register, it is one category with an owner, not a separate programme. The attack types, from prompt injection to data poisoning, are covered in our guide to [AI security risks](https://www.grcmana.io/blog/ai-security-risks).

The UK government's [AI Cyber Security Code of Practice](https://www.gov.uk/government/publications/ai-cyber-security-code-of-practice) sets out "baseline cyber security principles" for organisations that develop and deploy AI. It is a sensible reference for the controls behind this category.

### Reputational and customer trust risk

Reputational AI risk is the chance that the way you use AI, or a visible AI failure, damages customer confidence even where no law is broken. For a firm selling into regulated customers, it shows up as a stalled deal, a longer security review or a renewal that asks harder questions.

**Worked example.** A prospect asks whether customer data is used to train AI models. Sales says no, the security questionnaire says "under review", and the privacy notice says nothing. Three answers to one question cost more trust than any single answer would. The NCSC tells leaders to understand the "operational and reputational consequences" if an AI system is compromised, and to have a response plan.

## How do you add AI risk to your risk register?

Add AI risk to the register you already keep. Write each category as a risk statement, give it a named owner, score likelihood and impact on your existing scale, and choose a treatment. A separate AI risk register usually becomes a document nobody reads. The NCSC asks boards how AI risks "integrate into your existing governance processes".

A good AI risk register entry looks like any other entry. Here is one for the data category:

| Field | Example entry |
| --- | --- |
| Risk statement | Customer personal data entered into AI tools is retained or used for model training contrary to customer contracts |
| Category | Data |
| Owner | DPO |
| Likelihood and impact | Likely, major (on your existing scale) |
| Treatment | Approved tool list with business terms, acceptable use policy update, staff briefing |
| Evidence | Tool list, policy version, training record, vendor terms on file |
| Review | Quarterly, and on any new AI tool |

Three habits keep AI risk management light. First, use your existing [risk register](https://www.grcmana.io/vault/risk-management/risk-register) and scoring method, so AI risk competes for attention on the same terms as everything else. Second, review the AI entries whenever a new AI tool or feature arrives, not only on the annual cycle. Third, assess individual AI use cases with your normal [risk assessment method](https://www.grcmana.io/vault/risk-management/risk-assessment), and feed the results back into the category entries.

A risk with no owner is not managed. It is merely listed.

## How do ISO/IEC 42001 and ISO/IEC 23894 frame AI risk?

Both standards treat AI risk as part of normal risk management, not a separate discipline. ISO/IEC 42001:2023, the AI management system standard, asks you in clause 6.1 to plan actions on risks and opportunities. ISO/IEC 23894:2023 gives guidance on AI risk management built on ISO 31000. Neither asks for a new method.

Clause 6.1 of [ISO/IEC 42001](https://www.grcmana.io/vault/iso-42001) sits where you would expect, in the planning part of the management system. It covers assessing AI risks, treating them, and assessing the impact of AI systems on individuals and society. If you already run ISO 27001, the structure will feel familiar.

ISO/IEC 23894:2023 is guidance, not a certifiable standard. It is written for organisations that develop, deploy or use AI, and it adapts the ISO 31000 risk process to AI rather than replacing it. The NIST AI Risk Management Framework is a further reference, intended for voluntary use.

For a 25 to 250-person firm, the practical point is reassuring. If your risk process already follows ISO 27001 or ISO 31000, you extend it with AI risk categories and AI-specific questions. You do not rebuild it.

## What AI risk questions do enterprise customers ask?

Enterprise customers now ask a predictable set of AI questions in security reviews: where AI is used, whether their data trains models, who the model providers are, how outputs are checked, and who owns AI risk. Each question has a document that answers it, and most come straight from your register.

| Customer question | Evidence that answers it |
| --- | --- |
| Where do you use AI in the product and internally? | An AI use register listing tools, features and their owners |
| Is our data used to train AI models? | Vendor business terms and your own data handling statement |
| Which AI providers process our data? | Your sub-processor list, including model providers |
| How do you check AI outputs before they reach us? | Testing records and documented human review points |
| Who is accountable for AI risk? | The risk register entries with named owners |
| What happens if the AI feature fails? | Your fallback plan and incident process |

The firms that answer these quickly are not the ones with the most AI controls. They are the ones whose answers all come from the same register.

For the wider structure that holds these answers together, see our [AI governance framework](https://www.grcmana.io/blog/ai-governance-framework).

## What are the most common AI risk mistakes?

The most common AI risk mistakes are structural rather than technical: a separate AI risk register nobody owns, treating AI risk as a security problem only, ignoring AI that arrives inside existing software, and confusing debates about the long-term dangers of AI with the business risks a firm actually carries.

- **A separate AI risk register nobody owns.** It gets written for a board meeting and never reviewed. Put AI entries in the main register, under owners who already attend risk reviews.
- **Treating AI risk as only security.** Security is one category of seven. Many customer questions are about data and outputs, not attacks.
- **Ignoring embedded vendor AI.** Generative AI risks arrive through supplier updates as often as through your own projects. Supplier reviews need to ask about AI features and model providers.
- **Confusing existential debates with business risk.** Frontier AI safety is a serious public question, but it is not on a 100-person firm's register. Your risks are wrong answers, leaked data and suppliers you have not assessed.

The dangerous AI risk is rarely the dramatic one. It is the AI feature nobody wrote down.

## Frequently asked questions

### What are the biggest risks of AI in business?

For most small and mid-sized firms, the biggest risks of AI in business are data leaving your control through AI tools, wrong outputs in customer-facing features, and AI added by suppliers without review. All three can be found in records you already hold: your list of approved tools, your product release notes and your suppliers' sub-processor notices.

### Are the dangers of AI the same as AI risk?

Not in practice. Public debate about the dangers of AI often concerns long-term or society-wide harms. AI risk, for a firm, means the specific legal, data, output, supplier, operational, security and reputational risks created by the AI systems it builds, buys or lets staff use.

### Do we need a separate AI risk register?

No. We recommend keeping one register and tagging the AI entries, so you can filter them when a customer questionnaire or a board report asks for an AI view. A filtered view gives the same answer as a separate register, with no second document to keep in step.

### How are generative AI risks different from other AI risks?

Generative AI risks are mostly sharper versions of the same categories. Outputs are harder to predict and test, staff can paste data into general-purpose tools, and suppliers add generative features quickly. NIST's Generative AI Profile, AI 600-1, can help organisations identify these risks.

### How often should we review AI risks?

Review them on your normal cycle, and also when a trigger arrives. Useful triggers are a supplier's sub-processor notice, a model provider's retirement or terms change, a new AI feature in your own release plan, and a staff request to use a new tool.