Why is the assistant not a high-risk AI system under the EU AI Act?

Its use is not listed in Annex III, which defines high-risk by use case.

It processes no personal data capable of affecting anyone’s rights.

Its provider has completed a conformity assessment for the system.

Generative and agentic systems sit outside the Act’s risk tiers.

Which assessment does Aldermere NOT owe on these facts?

A fundamental rights impact assessment under EU AI Act Art. 27.

A data protection impact assessment under GDPR Art. 35, before starting.

A transfer risk assessment, if inference runs outside the EEA.

A legitimate interests assessment, if it relies on that basis.

Which control most directly addresses the risk of an unreviewed email reaching a client?

Requiring a person to approve each outbound artefact before it is sent.

Instructing the model in its system prompt to take care when emailing.

Logging every email the assistant sends, with the prompt that produced it.

Running the fixed evaluation set before each model or prompt change ships.

Why is GDPR Art. 22 not engaged by the assistant as described?

No decision is being made about the respondents themselves.

A human reviews each draft before it is sent to the client.

The respondents agreed to analysis when they took the survey.

The outputs are aggregated, which removes all personal data.

Governing an agentic AI system: a worked example

Everything else on this site teaches the pieces. This page runs one system through all of them — what you classify, what that triggers, what you have to write down, and what you actually build.

The 30-second version

Classify first, under both regimes, and write down why. The classification decides which assessments you owe — and on this system the EU AI Act produces a much lighter load than people expect, because the use is not in Annex III. Almost all of the obligation is GDPR and contract. The genuinely hard part is not the paperwork but the agentic design: what the system may reach, what it may do on its own, and where a human stands between a draft and a client.

The scenario

Aldermere Insight is a 400-person customer-experience consultancy based in Dublin. Its core business is running satisfaction and NPS surveys on behalf of enterprise clients: the client commissions the research, Aldermere fields the survey to that client’s customers, and delivers analysis back.

Aldermere wants to deploy an agentic assistant built on a third-party foundation model. Client-side analysts ask it questions in natural language — “why did NPS fall in the Nordics last quarter?” — and it plans its own approach, queries the data warehouse holding respondent-level records including free-text verbatims, runs the analysis, drafts a client-facing summary, and can schedule follow-up surveys and email drafts to client contacts.

The respondents are individuals — the clients’ customers. They answered a survey. They were told their responses would be analysed to improve service. Nobody asked them about an AI assistant.

Step 1 — Decompose before you classify

“An AI chatbot” is not a governable unit. Break it into what the system does, what data each capability touches, and what goes wrong — because the classification often turns on one capability rather than on the system as a whole.

Capability	Data it touches	What goes wrong
Answers analyst questions in natural language	Respondent-level survey records, including free-text verbatims	Confidently wrong answers presented to a client as analysis
Queries the warehouse and runs its own analyses	All client datasets it has been granted access to	Reaching across the boundary between one client’s data and another’s
Drafts client-facing reports and slides	Aggregates, plus quoted verbatims	A quoted verbatim that identifies a respondent, or reveals health or other special-category detail
Schedules follow-up surveys	Respondent contact details	Contacting people for a purpose they were never told about
Emails draft summaries to client contacts	Whatever the draft contains	An unreviewed, irreversible outbound action — the highest-consequence step in the chain

Step 2 — Three classification questions

Every obligation downstream hangs on these three answers. Get them wrong and you will do the wrong work diligently.

What is Aldermere under the GDPR?

Processor — and controller for one slice

For the survey data it analyses on a client’s instructions it is a processor: the client decides why the data is collected and what is done with it. The moment Aldermere uses the same respondent data to improve its own assistant, it decides that purpose itself and is a controller for that processing, needing its own lawful basis and its own transparency. Art. 28(10) is explicit: a processor that determines purposes and means is a controller in respect of that processing. This is the single most commonly missed step in this fact pattern.

What is Aldermere under the EU AI Act?

Provider and deployer, both

It builds the assistant on a third party’s general-purpose model and supplies it to clients under its own name, which makes it the provider of that AI system. It also uses the assistant in its own business, which makes it a deployer. The two roles carry different duties and it owes both sets. The foundation-model vendor remains the GPAI model provider and carries the GPAI obligations; Aldermere is downstream of those.

What risk tier does the system fall in?

Not high-risk — limited-risk with transparency duties

Nothing here is a prohibited practice, and the use is not in any Annex III category. What remains is Art. 50: a system intended to interact directly with natural persons must be designed so those persons know they are dealing with AI. Art. 4 AI literacy applies to providers and deployers regardless of tier. That is a much lighter load than people expect, and it is the correct answer.

Step 3 — Show your working on “not high-risk”

This is the conclusion most likely to be challenged, so it is the one to evidence. Walk Annex III and record why each category is out. The reasoning is the deliverable, not the verdict.

Biometrics	No biometric data is processed.
Critical infrastructure	The assistant manages no infrastructure.
Education and vocational training	No access, admission or assessment decisions.
Employment and worker management	Respondents are customers, not staff. This flips if the same tool is pointed at employee-engagement surveys and informs decisions about individuals.
Essential private and public services	No creditworthiness scoring, no life or health insurance pricing, no benefit eligibility.
Law enforcement, migration, justice	Not applicable.

What remains: Art. 50 transparency, because analysts interact with it directly and must know it is AI, and Art. 4 AI literacy, which applies to providers and deployers at every tier and has been in force since 2 February 2025.

Step 4 — The legal analysis that actually bites

Purpose limitation is where this is won or lost

Analysing satisfaction data to report satisfaction is the purpose the respondent was told about. Grounding an assistant on the same records to answer a client’s questions about that data is, in most readings, the same purpose carried out with a new tool. Training or fine-tuning a model on those records is a different purpose, and Art. 5(1)(b) compatibility has to be argued rather than assumed. The practical consequence: retrieval over client data is a much easier position to defend than fine-tuning on it, and that is a design decision, not a legal one.

The lawful basis is the client’s to hold, not Aldermere’s

As processor, Aldermere does not need its own Art. 6 basis for the client work — the client needs one, and Aldermere needs instructions. For its own model-improvement purpose it does need a basis, and legitimate interests is the usual candidate, which means a documented balancing test and a working Art. 21 objection route.

Free-text verbatims are the special-category problem

Nobody designs a satisfaction survey to collect health data, and respondents volunteer it anyway — "I was in hospital and could not get through to anyone". Once it is in the free text it is Art. 9 data, and Art. 9 prohibits processing unless an exception applies. The realistic controls are detection and redaction on ingest, keeping verbatims out of anything client-facing unless reviewed, and never letting the agent quote raw text unchecked.

Art. 22 is not engaged here, and it is worth knowing why

Art. 22 bites on a decision based solely on automated processing that produces legal effects concerning the data subject or similarly significantly affects them. The subjects here are respondents, and nothing is being decided about them — the output is aggregate insight for a client. Add an agent that flags a named complainant for account action and the analysis changes completely.

Transparency to respondents is the client’s duty, and Aldermere’s problem

The Art. 13 notice was issued by the client when the survey went out. If it describes analysis but says nothing about AI-assisted analysis, the honest position is that the notice needs revisiting. Aldermere cannot fix it — the controller must — but a processor that notices an infringing instruction is required by Art. 28(3) to say so.

The model vendor is probably a transfer

If inference runs in a US region, personal data is leaving the EEA and Chapter V applies: adequacy or Art. 46 safeguards, and where safeguards are relied on, a transfer risk assessment. This is the obligation most often missed, because the fact pattern says "our cloud provider’s US region" rather than "an international transfer".

Client confidentiality is not a GDPR question at all

The worst commercially plausible failure — the assistant answering one client using another client’s data — is a contract and security failure before it is a data-protection one. It will not be caught by a DPIA looking only at respondent harm, which is why the design review has to ask it separately.

Step 5 — Which assessments are triggered

Knowing which instruments you do not owe, and why, is as much of the job as completing the ones you do.

DPIA

Required

GDPR Art. 35. Large-scale processing, innovative technology, and special-category data arriving unbidden in verbatims. On the EDPB criteria this clears the bar comfortably. The client is the controller and owes it; Aldermere supplies the system detail under Art. 28(3)(f). Where high residual risk remains, Art. 36 prior consultation follows.

Legitimate interests assessment

Required if LI is relied on

Only for Aldermere’s own model-improvement purpose, and only if it picks legitimate interests as the basis. The three-part test is recorded: legitimate interest, necessity, and the balance against respondents’ rights.

Transfer risk assessment

Required if data leaves the EEA under safeguards

GDPR Chapter V. Not needed where an adequacy decision covers the destination; needed where SCCs are the mechanism.

FRIA

Not required

EU AI Act Art. 27 applies to deployers that are public bodies, private entities providing public services, or deployers of the creditworthiness and life/health insurance Annex III uses. Aldermere is none of these, and in any case Art. 27 attaches to high-risk systems, which this is not.

Conformity assessment and CE marking

Not required

EU AI Act Art. 43 is the pre-market gate for high-risk systems only. Offering it anyway would not be a harmless extra — a CE marking on a system outside the regime misrepresents its status.

AI system impact assessment

Not law, do it anyway

ISO/IEC 42005. It is the only instrument in this list that asks about harms with no personal-data dimension — client-facing inaccuracy, over-reliance, and the cross-client confidentiality failure. The DPIA will not reach them.

Step 6 — The document set

Every artefact this deployment needs, who owns it, and whether it is law or good practice. “Practice” items are not optional in any organisation running a management system — they are simply not what a regulator will fine you for missing.

Document	Hook	Owner	Status	When
Entry in the AI use-case register	Internal governance	AI governance lead	Practice	At intake, before any build
Updated Art. 30 records of processing	GDPR Art. 30	Client (controller) and Aldermere (processor)	Required	Before processing starts
DPIA	GDPR Art. 35	Client, with Aldermere’s input	Required	Before processing starts
Legitimate interests assessment	GDPR Art. 6(1)(f)	Aldermere, for its own purpose	Required if relied on	Before that processing starts
Data processing agreement	GDPR Art. 28	Client ↔ Aldermere	Required	Before processing starts
Sub-processor authorisation and notice	GDPR Art. 28(2)	Aldermere	Required	Before the model vendor touches data
Transfer mechanism plus TRA	GDPR Ch. V	Aldermere	Required if applicable	Before the first transfer
Revised privacy notice	GDPR Arts. 13–14	Client	Required if the notice no longer describes the processing	Before or at collection
Art. 50 AI disclosure in the interface	EU AI Act Art. 50	Aldermere as provider	Required	At first release
AI literacy training record	EU AI Act Art. 4	Aldermere, both roles	Required	In force since 2 February 2025
Vendor model card and instructions for use	Vendor obligation, and your evidence	Obtained from the model vendor	Practice	During due diligence
System card for the assistant itself	ISO/IEC 42001 practice	Aldermere as provider	Practice	Before release, kept current
Evaluation report and red-team findings	ISO/IEC 42001 practice	Engineering, reviewed by governance	Practice	Before the go-live gate
Human oversight protocol	Design control	Operations	Practice	Before release
Monitoring plan and thresholds	ISO/IEC 42001 practice	Operations	Practice	Live from day one
Incident procedure covering AI failure modes	GDPR Arts. 33–34 for breaches	Aldermere	Required in part	Before release

Step 7 — Controls for the agentic part

This is what separates governing an agent from governing a model. The model produces text; the agent decides what to reach for and what to do next. Most of the residual risk lives here, and none of it is addressed by a DPIA.

Scope the tools, not the prompt

An agent is bounded by what it can call, not by what it has been told. Give it a read-only warehouse role scoped to one client at a time, and no ability to widen its own access. Instructions in a system prompt are a preference; a database grant is a control.

Separate reading from acting

Querying data, drafting a report and sending an email are three different risk classes. Reading can be autonomous. Drafting can be autonomous. Anything that leaves the building — an email to a client contact, a survey invitation to a respondent — needs a person to approve that specific artefact, not a person who once approved the workflow.

Ground every claim and cite it

Retrieval over the client’s own data, with the answer carrying references back to the records it used, converts an unverifiable assertion into something an analyst can check in seconds. It is also the difference between a defensible output and one nobody can reconstruct.

Build a refusal path and reward using it

The dangerous answer is the plausible one to a question the data cannot support — a segment with eleven respondents, a quarter with no fieldwork. The assistant needs an explicit "not enough data to answer that" route, and the evaluation has to test that it takes it.

Hold a fixed evaluation set

A hundred or so questions with known-correct answers drawn from real client work, run before every model or prompt change. Without it there is no way to tell an improvement from a regression, and vendor model updates arrive whether you are ready or not.

Red-team the boundary you most need to hold

Specifically: try to make the assistant answer about client A while working for client B, try to make it reproduce a verbatim identifying a respondent, and try prompt injection through the free-text fields, which are attacker-controlled input that arrives looking like data.

Log enough to reconstruct a decision

Prompt, retrieved records, tool calls, output, reviewer, timestamp. This is what answers a client asking where a number came from, and what makes an incident investigable rather than a matter of opinion.

Keep a kill switch that a non-engineer can reach

A feature flag that disables the assistant, or an individual tool, without a deployment. Whoever is on call at the weekend must be able to use it.

Step 8 — The go-live gate

One list, one meeting, one named person who says yes or no. If an item cannot be closed, the decision is to accept it explicitly and record who accepted it — not to leave it open.

Classification recorded, with reasons, and signed off
DPIA complete; residual risk accepted by a named owner, or Art. 36 consultation done
DPA and sub-processor authorisation executed; transfer mechanism in place
Vendor terms confirm inputs are not used to train the vendor’s models
Per-client data isolation tested by someone trying to break it
Evaluation run and passed; red-team findings closed or explicitly accepted
Art. 50 disclosure visible in the interface
Outbound actions gated behind human approval
Logging verified end to end on a real query
Monitoring thresholds set, with an owner and an alerting route
Kill switch tested by the person who would actually use it
AI literacy training delivered to analysts and reviewers

Step 9 — After go-live

What to monitor

Refusal rate and its direction, evaluation scores rerun on a schedule, reviewer override rate on drafts, retrieval relevance, cost and latency, and every cross-client access denial. A rising override rate is the earliest honest signal that quality has slipped.

Erasure is harder than it looks

A respondent exercising Art. 17 has to be removed from the source system, the warehouse, the retrieval index, any cached responses, and any evaluation set built from real data. Each is a separate deletion path and each needs testing. If the model has been fine-tuned on that data the problem becomes genuinely hard, which is the strongest practical argument for retrieval over fine-tuning on personal data.

Incidents include the quiet ones

A personal-data breach triggers Arts. 33–34 on the familiar timetable. But the failure that actually happens is an assistant producing a materially wrong figure that reached a client deck. That is not a breach and it is still an incident: it needs the same detection, containment, correction, record and review, and it needs to reach the risk register.

Re-assess on change, not on the calendar

New data category, new client sector, a new tool granted to the agent, a vendor model upgrade, or any move toward decisions about individuals. Each reopens the classification. An annual review will miss all of them.

What would change the answer

The classification is not a property of the technology. Change one fact and the whole obligation set moves — which is exactly how exam scenarios are built, and how real deployments drift.

Change the fact pattern to…	…and this happens
The surveys are of the client’s own employees, and results inform individual management decisions	Annex III employment use — likely high-risk. Conformity assessment, Art. 26 deployer duties, and a FRIA if the deployer is in scope.
The assistant scores individual respondents for creditworthiness	Annex III essential-services use. High-risk, and a FRIA is owed by the deployer.
Aldermere fine-tunes on respondent data	A new purpose with its own basis and compatibility argument, and erasure becomes a problem you cannot fully solve.
The assistant emails respondents directly without review	Individual-level automated action. Revisit Art. 22, and revisit whether respondents were told.
Outputs are published as public thought-leadership	AI Act Art. 50(4) disclosure for AI-generated text published to inform the public on matters of public interest comes into view.
Aldermere substantially modifies the foundation model and releases it	It may take on GPAI provider obligations itself, not just AI system provider obligations.

Where practitioners get this wrong

Starting with the AI Act

It is the newest instrument so it gets read first, and on this fact pattern it produces the smallest obligation. The GDPR and the contract chain carry almost all the weight. Classify under both, then work in order of what actually binds.

Treating "we are the processor" as the end of the analysis

It is true for the client work and false the moment the firm uses the data for its own ends. Roles are per-processing, not per-company, and one system can put an organisation on both sides of the line at once.

Assuming personal data plus AI equals high-risk

High-risk is a defined list, not a feeling about sensitivity. Read Annex III and say which entry applies. If none does, say so and record why — that reasoning is the deliverable.

Governing the model and forgetting the agent

Most of the residual risk here is not in the model’s outputs but in what the system is permitted to do with them: which data it can reach, which actions it can take, and whether a person stands between a draft and a client.

Writing the DPIA after the build

Art. 35 says prior to processing. A DPIA produced to ratify decisions already made is not an assessment, and its recommendations are the ones nobody can afford to act on.

Which assessment, and who owes it — the five instruments side by side.
Roles and how they change — controller, processor, provider, deployer.
GDPR vs EU AI Act — same words, different meanings.
Article numbers — the ones worth knowing cold.

Test yourself

Five questions on what is above, with every option explained. Your score is kept in this browser and shown on your dashboard, and saved to your account if you are signed in.

Quick check: governing the agentic assistant1 / 5 · score 0

Aldermere starts using client survey data to improve its own assistant. What changes?

AIt becomes a controller for that processing and needs its own lawful basis.
BIt stays a processor throughout, because the data never leaves its systems.
CIt becomes a joint controller with the client for all survey processing.
DNothing changes, because the purpose is still analysing satisfaction data.