Implementing Agentic AI under the EU AI Act

You are considering deploying AI agents on processes that genuinely matter. Or they are already running, and you are wondering whether you could explain what they do if somebody asked. Below is the core of our implementation guide. The full document — including the checklist, templates and a system instruction you can adopt directly — is further down this page.

1. Establishing where you stand

The four risk levels

The law sorts AI applications by the risk they pose to safety, health and fundamental rights. Each level carries its own obligations.

The trap in this table is assuming a system has one level. It does not. A language model is minimal risk in a marketing assistant and high risk the moment it ranks candidates. Same architecture, same vendor, an entirely different set of obligations.

So classify per use case, not per tool. And record the reasoning: under scrutiny, "we considered it minimal risk" without argument is not an answer.

When is it high risk?

Broadly, in two situations. Standalone systems in critical domains:

• Recruitment and selection of personnel
• Education and vocational training
• Credit scoring and access to essential services
• Medical diagnostics
• Critical infrastructure
• Law enforcement and migration management

And safety components of already regulated products: machinery, medical devices, lifts, toys and comparable categories.

In doubt? Treat it as high risk until the contrary is substantiated. Revising a classification downwards is an administrative act. A system that turns out to be high risk after the fact has to be opened up.

Are you the provider or the deployer?

This is the most expensive question in the entire process, and the most frequently ignored. The provider carries the full package: conformity assessment, technical documentation, registration in the EU database, CE marking. The deployer uses somebody else's system and carries a lighter — but certainly not empty — set of duties.

Where it goes wrong: you legally become the provider the moment you put your own brand name on a high-risk system, or change its intended purpose such that it falls into the high-risk category. Organisations drift into this without noticing. You buy a generic tool, configure it for your own recruitment process, put your logo on it — and you have become the provider of a high-risk system, with a conformity assessment you never carried out.

2. Making human oversight operational

Human oversight is the most effective measure you can take. It is also the measure that most easily stays symbolic: a tick in a process where nobody genuinely looks.

What the supervisor must be able to do

• Detect malfunctions and anomalies — trained people who notice unwanted behaviour in time.
• Review and override decisions — particularly where AI makes decisions affecting people, such as an automatic rejection.
• Stop the system — a designated person holding both the authority and the technical means. Both, not one of the two.
• Review logs and KPIs — assessed periodically and measured continuously.

Oversight must not be symbolic. The person exercising it needs knowledge and competence to understand how the system works and where its limits lie, formal authority to intervene, and support from the organisation to genuinely perform the role. An employee who is formally the supervisor but gets no time to look is not a supervisor. That is a name in a document.

Recording it in four layers

1. Roles — name who is responsible per application and put the validation tasks in the job description.
2. Policy — record the validation duty: AI output is a draft until a human has checked it. Document the escalation path.
3. Audit trail — keep a validation log of who approved what and when. Retain for at least six months for high-risk systems.
4. Training — include AI literacy in your training policy and record that staff were instructed on how systems work, their limitations and their risks.

3. Prompt injection: the layered defence

Prompt injection is the hiding of instructions inside material an AI processes: an email, a website, a PDF, a tender document. The model distinguishes poorly between your instruction and one sitting in the text it processes, and can be hijacked as a result — leaking data, taking unwanted actions, introducing security holes into code.

Agents that read external input are exposed by definition. And no watertight technical solution exists. That is not pessimism, it is the design assumption: build as though the defence will be breached at some point.

Layer 1 — System instructions

Instruction isolation: explicitly instruct the AI to treat text in documents or emails purely as source content, and never as new commands capable of altering earlier instructions. Reporting behaviour: on a possible injection the agent halts, quotes the passage and asks for human confirmation.

Layer 2 — Human-in-the-loop

The primary line of defence, precisely because the technology falls short. Never let agents independently perform actions with customer or financial impact. AI prepares drafts; a human is the final link and checks for illogical or deviant conclusions. That deviation is often the only visible trace of a successful injection.

Layer 3 — Technical filters

Restrict the agent to sources you trust, and be especially careful with RAG solutions containing third-party documents — that is precisely the scenario in which a supplied document can carry instructions. Add output validation for sensitive data and unwanted patterns. And grant permissions by least privilege: a hijacked agent can never do more than its permissions allow.

Layer 4 — Organisational

A validation duty in AI policy, a clear escalation path for anyone who spots an injection attempt, and training in recognising the risks — particularly when having external websites or documents summarised.