This article accompanies Hour 3: EU AI Act Scope, Obligations and Governance in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.
A software vendor describes a new AI feature as "low risk". It summarises team messages, highlights recurring blockers, suggests coaching prompts for managers and produces a weekly dashboard of "engagement indicators".
The tool is not being used to recruit anyone. It is not a medical device, credit scoring system or law enforcement system. It may not obviously fall into a high-risk AI Act category on first review. But it uses employee data, creates performance-related inferences and may influence how managers assess staff.
That is the governance trap. AI Act classification is essential, but it is not the whole answer. A system that is not prohibited or high-risk under the AI Act can still raise GDPR concerns around lawful basis, fairness, transparency, data minimisation, employee monitoring, profiling, special category inferences, retention, access controls and DPIA requirements.
For DPOs and privacy leads, the practical discipline is to run both tracks. Classify the AI system under the AI Act. Then ask what the processing means under GDPR. Do not let a "low-risk" AI label flatten the data protection analysis.
This article is general CPD-support information, not legal advice on a specific AI feature, workplace monitoring arrangement or AI Act classification.
The AI Act Categories Do Different Work From GDPR
The EU AI Act uses a risk-based structure. Some AI practices are prohibited. Some systems are high-risk and subject to detailed obligations. Some systems are subject to transparency obligations, often described in practical guidance as limited-risk or transparency-risk systems. Many AI uses may be minimal or no-risk under the AI Act.
Those categories matter. A prohibited practice should not proceed unless a specific legal exception applies. A high-risk AI system may require extensive provider documentation, risk management, data governance, human oversight, logs, conformity work and deployer controls. A transparency-risk system may require people to be told they are interacting with AI, or that content has been generated or manipulated by AI.
GDPR asks related but different questions. Is personal data processed? What is the purpose and lawful basis? Is special category data involved? Are people monitored or profiled? Are decisions made solely by automated means with legal or similarly significant effects? Is the processing fair and transparent? Is a DPIA required? Can the organisation explain and control the data flows?
The same tool can therefore have two different risk stories. It might be low or limited-risk under the AI Act but high enough risk under GDPR to require a DPIA. It might be high-risk under the AI Act because it is used in employment, education, essential services or another Annex III context, while the GDPR analysis focuses on lawful basis, Article 9 conditions, data subject rights, retention and human review. Or it may be prohibited under the AI Act and also unlawful or unfair under GDPR.
The labels are not interchangeable. "Not high-risk under the AI Act" does not mean "low privacy risk". "DPIA completed" does not mean "AI Act role mapping and classification completed".
Prohibited AI and Privacy Red Lines
Article 5 of the AI Act prohibits a set of AI practices because their risks are considered unacceptable. The details matter and should be checked against the law before a real decision is made. For privacy teams, the important point is that several prohibited practices sit close to data protection concerns: manipulation, exploitation of vulnerability, certain forms of social scoring, certain biometric practices, certain emotion recognition in workplace or education contexts, and some remote biometric identification scenarios.
If a proposed use appears to sit near a prohibited practice, the privacy team should not treat it as a normal DPIA with more mitigations. The first question is whether the use is allowed at all. The evidence should show the proposed functionality, affected people, purpose, legal basis claimed, exception relied on if any, and senior decision route.
For example, an employee wellbeing tool that claims to infer emotional state from video calls should not be waved through because it is "only internal". The AI Act may prohibit certain emotion recognition uses in the workplace, subject to limited exceptions. GDPR would also raise difficult questions about necessity, fairness, transparency, special category data or inferences, employee power imbalance and proportionality.
The practical rule is simple: where the AI Act may prohibit the practice, stop classification drift early. Do not let the project be reframed as a productivity feature until the legal issue has been resolved.
High-Risk AI and GDPR Accountability
High-risk AI systems are not high-risk merely because they feel important. The AI Act identifies high-risk systems through product safety links and listed areas in Annex III, including areas such as biometric identification or categorisation, critical infrastructure, education and vocational training, employment, access to essential private and public services, law enforcement, migration and border control, administration of justice and democratic processes.
For privacy teams, the most common trigger points are likely to be employment, recruitment, education, access to services, customer eligibility, fraud detection, health-related workflows, biometric processing and decision support affecting people.
If an AI system is high-risk under the AI Act and processes personal data, GDPR governance should be substantial. That does not mean the same document must do everything. It does mean the organisation should avoid contradictory records. The AI Act file should not say the system recommends decisions about applicants while the DPIA says it is only used for administrative support.
In a high-risk context, GDPR work should usually examine:
- the exact decision or workflow the AI affects;
- whether the organisation is controller, processor or joint controller;
- lawful basis and, where relevant, Article 9 or Article 10 conditions;
- transparency wording for affected people;
- data minimisation and input-data controls;
- accuracy, bias, fairness and contestability;
- automated decision-making and meaningful human involvement;
- retention, access and logging;
- vendor evidence, transfers and security;
- DPIA findings, residual risk and sign-off.
Human review deserves particular care. A policy saying "all outputs are reviewed by a human" is weak if staff are not trained, do not have authority to depart from the AI output, cannot understand the system's limits, or are measured in a way that discourages challenge.
Limited-Risk AI Can Still Be GDPR-Heavy
Limited-risk or transparency-risk AI is where many organisations will feel a false sense of ease. Chatbots, AI-generated content and certain synthetic media disclosures may look manageable because the AI Act obligation is often framed around transparency rather than full high-risk controls.
But GDPR risk depends on processing context. A chatbot that answers generic website FAQs may be relatively straightforward. A chatbot that handles health queries, customer complaints, debt support, employee grievances or student welfare concerns is different. The transparency obligation under the AI Act may be only one part of the governance picture.
The same is true for AI writing assistants, meeting assistants and productivity tools. A feature that drafts neutral text may be low-risk in one setting. The same feature may become privacy-sensitive if staff use it to summarise disciplinary hearings, infer employee performance, classify customer vulnerability, or generate case notes that affect services.
The privacy team should therefore ask: what personal data goes in, what inferences come out, who relies on the output, and what could happen to the person concerned?
Worked Example: Employee Engagement Dashboard
Return to the opening scenario. A vendor offers an AI feature inside an enterprise collaboration platform. The feature summarises team messages, identifies blockers, suggests coaching prompts and gives managers weekly engagement indicators.
The facts the privacy team starts with are limited. The vendor says the feature is optional and "not high-risk". The HR team says it will help managers support staff. The IT team says the tool is part of an approved platform. No one has yet confirmed exactly what message content is analysed, whether private chats are included, whether health or union-related information could be inferred, how long outputs are retained, or whether managers will use indicators in performance discussions.
The risk question is not simply "is this high-risk under the AI Act?" It is: what is the AI Act category for each planned use, and what GDPR controls are required before employee data is processed in this way?
| Review point | Draft conclusion | Evidence needed before approval |
|---|---|---|
| AI Act category | May not be high-risk if used only for general team support, but needs review if outputs affect employment decisions or performance management. Avoid any emotion recognition or prohibited workplace use. | Use-case description, vendor functionality statement, disabled features list and confirmation of no emotion recognition or sensitive biometric categorisation. |
| GDPR role | Employer is likely controller for use of employee data. Vendor role must be confirmed for hosting, support, telemetry and model improvement. | Data processing agreement, vendor privacy terms, subprocessors, transfer information and model training position. |
| Lawful basis and fairness | Legitimate interests or another basis may be considered, but employee power imbalance and reasonable expectations require careful assessment. | Legitimate interests assessment or equivalent reasoning, employee consultation or communications plan and fairness assessment. |
| DPIA | Likely needed if monitoring, profiling or systematic analysis of employee communications is involved. | DPIA screening and, if triggered, full DPIA before rollout. |
| Transparency | Staff need clear information about what is analysed, what is not analysed, who sees outputs and how outputs may be used. | Employee notice update, manager guidance and FAQs that avoid vague "AI may be used" wording. |
| Data minimisation | The tool should not analyse more channels, history or sensitive content than necessary. | Configuration record, excluded channels, retention settings and access controls. |
| Human review | Managers must not treat indicators as performance ratings or disciplinary evidence without separate review and HR process. | Manager training, policy wording, prohibited-use list and escalation route. |
| Review trigger | Any move from team support into performance, absence, disciplinary, promotion or redundancy decisions should reopen both AI Act and GDPR analysis. | Register trigger, governance owner and review date. |
This example shows why AI Act and GDPR analysis need to sit together. A narrow AI Act review might conclude that the feature is not high-risk in its first configuration. A proper privacy review would still identify employee monitoring, inferences, transparency, minimisation and fairness risks.
What Evidence Should Exist Afterwards
After the review, the organisation should have a short decision record explaining the AI Act category assumed for the specific configuration and the reasons for that assumption. It should state which features are enabled, which are disabled, and which uses are out of scope.
It should also have a GDPR evidence pack. For the employee dashboard example, that may include DPIA screening or a full DPIA, a legitimate interests assessment or other lawful basis reasoning, employee transparency wording, vendor due diligence, data-processing terms, transfer information, configuration settings, retention decisions, access controls, manager training and a prohibited-use list.
The register should not simply say "approved". It should say approved for what. Approved for team-level support is not the same as approved for individual performance assessment. Approved for aggregated indicators is not the same as approved for message-level monitoring. Approved with private chats excluded is not the same as approved with all employee communications included.
Where residual risk remains, the record should show who accepted it and on what basis. If a risk is too high, the decision should say what is blocked or suspended. That clarity is more useful than a comforting but vague statement that the tool has been "privacy reviewed".
Checklist for DPOs and Privacy Teams
For each AI use case, ask:
- what AI Act category is being assumed, and what facts support that conclusion;
- whether any prohibited practice may be engaged, especially around manipulation, vulnerability, biometric categorisation, emotion recognition, social scoring or remote biometric identification;
- whether the use falls into a high-risk area such as employment, education, essential services, biometric processing, law enforcement, migration, justice or democratic processes;
- whether AI Act transparency obligations apply, including chatbot disclosure, deepfake disclosure or AI-generated content marking;
- what personal data is processed, including inferred data and sensitive or special category data;
- who is affected, and whether there is vulnerability, dependency or power imbalance;
- the GDPR role, lawful basis, transparency route and data subject rights impact;
- whether a DPIA is required because of monitoring, profiling, new technology, systematic assessment or significant effects;
- what human review means in practice and whether people can challenge, correct or override outputs;
- which use changes would reopen the assessment.
The checklist should be used early, before teams have already trained staff, switched on integrations or built workflows around the output. Once a tool becomes normal operational furniture, the cost of correcting the governance record goes up.
How This Connects to AI/DPIA Lifecycle Support
The strongest governance model keeps AI Act classification, GDPR assessment and operational controls connected through the lifecycle. At intake, the organisation captures the use case and role. At assessment, it checks AI Act category and GDPR risk. At deployment, it records controls, transparency, human review and training. During use, it monitors change, complaints, incidents and vendor updates.
XpertDPO's AI Governance and DPIA Lifecycle Support is designed for exactly that connection point. It helps organisations avoid two common mistakes: treating AI Act classification as though it answers all privacy questions, and treating a DPIA as though it answers all AI Act questions.
XpertDPO's DPIA Support and DPO Support are relevant where a use case involves employees, customers, vulnerable people, profiling, decision support, sensitive data or unclear human review. In those cases, a structured second look can prevent a weak assumption from becoming a live governance problem.
What This Means for CPD
For Event B Hour 3, the practical learning is that AI Act risk categories are a starting point, not a substitute for privacy judgement. DPOs and privacy leads should be able to classify the AI use, spot when a prohibited or high-risk issue may arise, and then ask the GDPR questions that still matter.
The smallest safe next step is to pick one AI use case described internally as "low-risk" and test that label. What is the AI Act category? What personal data is used? What inferences are created? Who is affected? Is a DPIA needed? What transparency is given? What human review actually happens? If the answers are missing, the low-risk label is not yet evidence.
This article is intended to support the learning covered in Hour 3 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event B: Full-Day AI, Technical Privacy & Emerging Technology Training.