The biggest AI risk? Thinking there is only one kind

Anyone following the latest AI news could easily get the impression that each risk is bigger than the last. AI agents have suddenly been found capable of gaining access to real-world systems during safety tests. The NCSC warns (please note: this website is only available in Dutch) about sensitive business information ending up outside an organisation through the use of AI. Meanwhile, there is debate about politicians using AI for parliamentary questions and other communications, article (Dutch). And then there is the AI Act, under which certain applications are formally classified as high-risk AI. As a board member, making sense of all this is no easy task. After all, are we actually talking about the same kind of risk in each of these cases? No. And that is precisely where the problem begins.

We use the term ‘high risk’ to refer to quite different questions. Sometimes, it concerns a legal classification that determines which rules apply. At other times, it concerns potential harm to people, technical unpredictability, information security, reputation, or strategic consequences for the organisation. These perspectives may overlap, but they are not interchangeable.

A single red-amber-green score for ‘AI risk’ may look reassuringly straightforward, but it can actually conceal important differences and nuances. Good AI governance should therefore not start by asking how high the AI risk is. The first question should be: which risk or risks are we actually talking about?

High-risk AI is not a general risk score

Take the term that has perhaps become best known in the legal world surrounding AI: high-risk AI under the AI Act. This is, first and foremost, a legal classification. You do not simply assess how dangerous an application feels in practice and then attach a label to it. The AI Act itself determines when an AI system qualifies as a high-risk AI system. Article 6 of the AI Act broadly provides two routes:

• The first concerns AI systems that are themselves regulated products, or are used as a safety component of such products, where the product is required to undergo a third-party conformity assessment under certain EU product legislation.
• The second concerns specific areas of use listed in Annex III, including recruitment and selection, education, creditworthiness, access to essential public services, and certain applications relating to elections. For such AI applications, the Act does provide a filtering mechanism for less risky uses of AI within such an area, but this mechanism is itself quite narrowly defined. The European Commission has since elaborated on these classification rules in draft guidelines containing practical examples.

NB: Before reaching that stage, however, it is also necessary to consider whether an application might be prohibited altogether. Under Article 5 of the AI Act, certain AI practices are not high-risk AI but are simply prohibited because the European legislature considers such AI practices too risky. Examples include certain forms of biometric emotion recognition in the workplace and in educational institutions, or subliminal manipulation of vulnerable persons.

The important point, however, is this: classifying something as ‘high-risk AI’ is not a general statement about the level of risk it poses to your organisation.

An AI application may cause substantial financial or reputational damage while still falling outside Article 6. Conversely, a system may legally qualify, and continue to qualify as high-risk AI even where the concrete risks have been substantially reduced through appropriate design and risk-control measures.

The classification primarily tells you which legal regime applies and which obligations come with it. It does not give you the complete picture of how much anxiety the system should or should not be causing your board.

A DPIA asks a different risk question

The distinction becomes clear as soon as you consider the GDPR alongside the AI Act. Here too, we encounter the term ‘high risk’, but with a different meaning. Under Article 35 GDPR, a Data Protection Impact Assessment (DPIA) is required where processing is likely to result in a high risk to the rights and freedoms of natural persons. Here, the focus is specifically on assessing the consequences of a particular processing operation for people.

There are European guidelines on this, as well as situations in which the Dutch Data Protection Authority requires a DPIA, but the assessment remains broader than a predetermined list. Even outside those situations, the nature, scope, context and purposes of processing may mean that a DPIA is required.

This creates an important distinction. An AI system may fall outside the AI Act’s high-risk regime but nevertheless require a DPIA because it processes personal data. Conversely, classification as a high-risk AI system does not automatically mean that every use of such a system poses a high privacy risk under the GDPR. Certainly, in many cases the two can and will overlap, but this is not necessarily always the case.

The next question is different too. A DPIA involves identifying risks to data subjects and determining which measures are needed to mitigate those risks. If a high residual risk remains despite those measures, prior consultation with the data protection supervisory authority is required before the processing begins. So we have two legal regimes, both using the terminology of ‘high risk’, but applying different tests. And that is not the end of the story.

Legal labels do not tell you what can actually go wrong

In addition to determining which laws apply, an organisation obviously also needs to understand what might actually happen in practice.

This is becoming increasingly important as AI systems not only generate text but are increasingly able to act as agents and perform actions. A conventional chatbot primarily provides answers. An agent may also be able to open files, retrieve information, execute code, send messages, access accounts, or make changes to systems. This fundamentally changes the risk profile.

Recent incidents during safety evaluations at organisations including OpenAI and Anthropic show that AI agents can unexpectedly gain access to systems outside the environment for which they were intended. The easy newspaper headline would then be ‘the AI escaped’. For risk management purposes, a different analysis is more useful. The potential harm results from a combination of model behaviour, the technical environment, the tools available to the system, access rights, and the security measures surrounding it.

For your organisation, therefore, the question is not simply: How powerful is this AI system? At least as relevant is the question: What have we allowed this system to do? An AI system that is only permitted to draft text has a different risk profile from an agent that can independently send emails, access customer files, initiate payments, execute code, or delete data.

This may seem like a technical issue, but it is just as much a governance issue. Which permissions are necessary? When is human approval required? Which actions should never be performed autonomously? How are actions logged, monitored, and, where necessary, reversed? The well-known security principle of least privilege is therefore particularly relevant to AI agents.

The concept of ‘systemic risk’ under the AI Act also illustrates how ‘risk’ can mean something different again. This concept is used in relation to certain very powerful general-purpose AI models whose risks may propagate at scale throughout the AI value chain. Providers of such models are subject to additional obligations relating, among other things, to evaluation, risk mitigation, incidents, and cybersecurity. Once again, this is a different concept from the ‘high-risk AI system’ referred to in Article 6.

What information travels with your AI?

An application may work perfectly well from a technical perspective and legally fall outside the AI Act’s high-risk regime, yet still be entirely unsuitable for certain types of information.

The NCSC warns, for example, that employees using generative AI may cause sensitive information to end up on servers outside their own organisation. A blanket ban does not necessarily solve this problem: employees may simply turn to a personal phone, laptop, or account instead.

Here, the question changes again. Not: is this high-risk AI? But, for example: where do our prompts and files end up? Which supplier processes them? Are other parties involved in the chain? Is data stored or reused for other purposes? Which sources can an AI agent access? And what information might it, in turn, send to external search engines, APIs, or other connected services? The answers may simultaneously be relevant to the GDPR, contractual confidentiality obligations, the protection of trade secrets, cybersecurity, supplier management, and internal information classification.

This illustrates precisely why a single AI Act check can never replace your complete risk assessment. The legal classification is important, but it does not automatically tell you whether your particular implementation is responsible.

Context changes the risk

Some risks arise not because the technology changes, but because the context in which you use the same technology changes.

This can be seen, for example, in recent discussions about politicians’ use of AI. Using AI to make an internal document easier to read may attract little attention. Using AI to help draft parliamentary questions, campaign materials, or a message that is explicitly presented as personal may be received very differently.

From a technical perspective, the difference need not be significant. From a societal perspective, however, expectations regarding authenticity, involvement, and responsibility are very different. This creates reputational risk that cannot be inferred from the technical characteristics of the AI system. The relevant question therefore becomes not only: is this permitted?, but also: what can our target audience reasonably expect from us?

Sometimes, the law does intervene. The AI Act contains specific rules for certain AI intended to influence elections or voting behaviour: this may, in turn, qualify as high-risk AI under the AI Act. (This is discussed in further detail in the draft guidelines on high-risk AI). In addition, the transparency obligations under Article 50 of the AI Act, applicable since 2 August 2026, may be relevant to certain AI-generated or manipulated content, particularly public-facing messages on matters of public interest.

But something being legally permitted does not automatically make it socially appropriate. Compliance and reputation are not the same thing.

Doing nothing is a risk as well

With all these considerations, organisations may be tempted to keep AI at arm’s length as much as possible for the time being. But there is no risk-free route there either.
Organisations that systematically exclude useful AI applications may miss out on productivity, speed, innovation capacity, and experience with the technology. While others are learning which applications work and which do not, your own organisation gains little knowledge.

A strict ban may also encourage shadow use. The NCSC points out that, where generative AI is prohibited, employees may still use it on their own devices. In that case, the use takes place outside the approved environment, without contractual safeguards, technical security, logging, or internal oversight.

That does not, of course, automatically make falling behind more serious than, for example, discrimination, a major data breach, or an infringement of fundamental rights. These are different types of consequences that cannot meaningfully be compressed into a single number.

But choosing not to use AI is also a decision with potential consequences. An organisation that assesses only the risks of adopting AI is implicitly comparing a concrete AI application with an imaginary scenario in which doing nothing is both cost-free and risk-free.

So what should be on the board’s agenda?

Good AI governance therefore does not require a single universal AI risk score, but rather a number of different questions that should consciously be considered alongside one another:

• What value do we want to create? What problem are we solving, and what benefits do we expect?
• Which legal regimes are relevant? Consider the AI Act (including its transparency obligations), a DPIA, a FRIA, sector-specific rules, contracts, and other relevant legislation.
• Which people may be affected? Consider customers, employees, citizens, other affected persons, and the public interest.
• What data and confidential information are being used? Map suppliers and intermediaries as well as storage, transfers, and potential reuse.
• What can the system actually do? Distinguish between advising, reading, sending, publishing, deciding, making payments, modifying, and deleting.
• How much autonomy is the system given? Determine where human oversight is required and where hard technical limits are necessary.
• What happens if we do not use the system? Take account of shadow use, missed value, outdated processes, and lost opportunities for organisational learning.
• Who is responsible? Establish ownership, logging, monitoring, incident procedures, review points, and specific stop criteria.

The aim is not to reduce all these questions to a single number after all. It is precisely the differences between the answers that give the board the information it needs to make a considered, well-balanced decision.

There is no single biggest risk

Which AI risk is the biggest depends on the application, the people affected, the information being used, the permissions granted to the system, and the role of your organisation. A single universal answer would mainly create a false sense of certainty.

Good AI governance therefore does not mean eliminating every risk. It means understanding which types of risk you are taking, what value you expect in return, and where your boundaries lie. So, if you ask me what the biggest AI risk is, my answer is: thinking there is only one kind, and that once you have addressed it, your job is done.

Not sure which assessments your AI application requires, or how to bring together the different legal, technical, and organisational perspectives? Our Certified AI Compliance Officers (CAICO^®) would be happy to help.