EU AI Act Provider and Deployer Obligations for Privacy Teams

This article accompanies Hour 3: EU AI Act Scope, Obligations & 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.

The EU AI Act is not a GDPR amendment. It does not replace controller and processor analysis, DPIAs, lawful basis, transparency duties or data subject rights. It adds a separate governance layer for AI systems and general-purpose AI models.

That distinction matters. If the AI Act is treated as “the AI team’s problem”, privacy teams may miss the evidence they need for GDPR accountability. If it is treated as “GDPR with a new label”, organisations may miss the AI Act’s own role mapping, product obligations, conformity evidence, transparency rules and post-deployment monitoring duties.

For DPOs, privacy leads and legal teams, the better first question is: what AI systems are being used, who is acting in which role, what is the risk category, and what evidence exists before the system affects people?

This article gives a governance-focused overview for privacy teams. It is general information, not legal advice on a specific AI system, product category or deployment. The implementation timetable should also be checked close to publication and before any formal compliance decision, particularly where high-risk AI systems are affected.

Why Privacy Teams Are Pulled Into AI Act Readiness

Many AI systems process personal data directly. Others generate inferences about people, support decisions about individuals, monitor behaviour, rank people, produce recommendations, or alter the way services are delivered. Even where an AI system is not primarily a “privacy tool”, it may create privacy, fairness, transparency and accountability questions.

The European Commission describes the AI Act as a risk-based framework for AI developers and deployers, with categories such as prohibited practices, high-risk systems, transparency-risk systems and minimal or no-risk systems. It also confirms that the AI Act entered into force on 1 August 2024, with different application dates for different parts of the regime.

For privacy teams, that staged timetable is important because AI governance work is already live. Prohibited AI practices and AI literacy obligations have applied since 2 February 2025. General-purpose AI model obligations started to apply from 2 August 2025. Transparency obligations under Article 50 are due to apply from 2 August 2026. The Commission’s 2026 implementation pages also refer to a revised high-risk timeline following the AI Omnibus political agreement, including 2 December 2027 for certain high-risk areas and 2 August 2028 for product-integrated systems. Check the dates again at publication.

The key point is simpler than the timetable: organisations need an AI governance record before there is a regulator question, complaint, audit request or board paper. That record should connect privacy, procurement, security, legal, product, HR, operations and risk.

Provider, Deployer and Other AI Act Roles

The AI Act uses its own role language. It is related to, but different from, GDPR role language.

In broad terms, a provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its authority, except for purely personal non-professional use. Importers and distributors sit in the supply chain. Product manufacturers may have AI Act responsibilities where an AI system is integrated into a regulated product. Providers of general-purpose AI models have specific obligations because their models can be used in many downstream systems.

That sounds tidy until it meets real procurement and product practice. A business may buy an AI-enabled SaaS product, configure it heavily, fine-tune a model, white-label a third-party system, integrate model outputs into its own service, or change the intended purpose over time. Those changes can matter.

Article 25 of the AI Act is especially relevant to governance discussions because it deals with responsibilities along the value chain. A deployer, importer, distributor or other third party may be treated as a provider of a high-risk AI system if, for example, it places its own name or trade mark on the system, makes a substantial modification, or changes the intended purpose in a way that makes the system high-risk. In practical terms, role mapping cannot be a one-off label added at procurement. It needs to be reviewed when the system is configured, modified, repurposed or embedded into another workflow.

The following table is deliberately simplified. It is a starting point for governance triage, not a substitute for legal classification.

Privacy teams do not need to become product conformity specialists overnight. They do need enough role clarity to ask who supplies documentation, who explains intended purpose, who controls input data, who monitors outputs, who handles incidents, who informs affected people, and who updates the record when the system changes.

AI Act Role Mapping Is Not Controller and Processor Mapping

One of the most useful privacy contributions to AI Act readiness is also one of the easiest to miss: AI Act role mapping and GDPR role mapping answer different questions.

Under GDPR, the analysis focuses on personal data processing. Who determines the purposes and means? Who processes on behalf of whom? Are there joint controllers? Is a vendor an independent controller for some processing and a processor for other processing? Is special category data involved? Is profiling involved? Is a DPIA required?

Under the AI Act, the analysis focuses on the AI system or model and the actor’s place in the AI value chain. Who developed it? Who places it on the market? Who uses it under their authority? Who substantially modifies it? Is it prohibited, high-risk, subject to transparency obligations, GPAI-related, or minimal/no-risk? What technical, operational and documentary evidence is required?

Those analyses can overlap, but they should not be collapsed.

A vendor may be an AI Act provider because it places an AI system on the market under its name. For some personal data processing, it may act as processor. For other processing, such as product analytics, fraud monitoring or model improvement, it may act as an independent controller. The customer may be an AI Act deployer while also being a GDPR controller for its own use of the tool. If the customer materially modifies the system or changes the intended purpose, the AI Act role analysis may change even where the GDPR controller analysis looks familiar.

The same is true internally. An HR team using an AI tool to shortlist candidates may think of itself as a business user. For AI Act purposes, the organisation may be a deployer of a high-risk system. For GDPR purposes, it may be the controller for candidate data and may need a DPIA, clear notices, retention controls, human review and safeguards against unfair or excessive processing.

This is why AI governance registers should not contain only one “role” field. A useful register should separately record AI Act role, GDPR role, risk category, personal data use, affected people or groups, record owner and review date. It does not need to be elaborate, but it does need to show what the organisation thinks it is doing and why.

What Provider Obligations Mean in Governance Terms

For high-risk AI systems, providers carry the heavier compliance burden. Article 16 sets out obligations including compliance with the high-risk requirements, quality management, documentation, logs where under the provider’s control, conformity assessment, EU declaration of conformity, CE marking, registration, corrective action, cooperation with competent authorities and accessibility requirements.

For privacy teams, the provider’s obligations matter even when the organisation is “only” buying the tool. A deployer cannot operate a sensible governance model if the provider cannot explain the intended purpose, limitations, human oversight measures, logging, performance, accuracy, robustness, cybersecurity and risk controls. Procurement should capture AI Act evidence as well as GDPR evidence.

A provider evidence pack for a high-risk or potentially high-risk AI system should answer practical questions:

• What is the system’s intended purpose and reasonably foreseeable misuse?
• What risk classification has the provider reached, and what is the rationale?
• What instructions for use and human oversight measures are supplied?
• What logging, monitoring, incident and corrective-action processes exist?
• What data governance controls apply where training, validation or testing data is relevant?
• What information is available for DPIA, fundamental rights impact assessment or equivalent governance records?

That evidence is not a box-ticking exercise. It affects whether the deployer can use the system lawfully and safely in its own context. A provider’s generic statement that a tool is “AI Act compliant” is not enough for a privacy team trying to assess a specific HR, healthcare, education, financial services, housing, insurance, public services or customer decision-support use case.

Provider obligations also matter for general-purpose AI. Article 53 requires GPAI model providers to maintain technical documentation, provide information to downstream providers that intend to integrate the model, put in place a copyright compliance policy, and publish a summary of training content using the AI Office template. Additional obligations apply to GPAI models with systemic risk.

Most organisations will not be GPAI model providers. Many will, however, use GPAI-enabled services. Privacy teams should ask whether the organisation is simply using a hosted capability, integrating a model, fine-tuning it, exposing outputs to customers, or building a new service on top of a third-party model. The answer affects both AI Act governance and GDPR analysis.

What Deployer Obligations Mean in Governance Terms

Deployers are not passive customers. For high-risk AI systems, Article 26 places obligations on deployers around appropriate technical and organisational measures, use in accordance with instructions, competent human oversight, input data where under the deployer’s control, monitoring, suspension and escalation where risk arises, incident communication, log retention, workplace information duties and cooperation with authorities.

That translates into a familiar but demanding governance pattern. Before deployment, the organisation needs to know what the system is for, who may use it, what training they need, what data may be entered, what human review means, which outputs may be relied on, and what happens when the system behaves unexpectedly.

For privacy teams, the input-data point is particularly important. Many AI risks are not created by the model alone. They arise because staff paste excessive personal data into a tool, use live customer data for testing, upload special category data without a clear purpose, or repurpose a system beyond the provider’s instructions. Deployer governance should include acceptable-use rules, data minimisation controls, prompt and upload guidance, retention decisions, access controls and escalation routes.

Article 27 adds another layer for certain high-risk AI deployments. Some deployers, including public bodies and certain private entities, must carry out a fundamental rights impact assessment before deploying specified high-risk systems. The AI Act makes clear that, where obligations are already met through a GDPR DPIA, the fundamental rights impact assessment complements the DPIA. That is a useful design principle even beyond strict Article 27 cases: do not create competing assessment documents that say different things about the same system.

In practice, privacy teams should connect the records. If there is a DPIA, AI risk assessment, fundamental rights assessment, procurement assessment, security review and model governance review, they should share a common description of the system, intended purpose, affected people, data flows, human oversight, monitoring and escalation arrangements.

Transparency, AI Literacy and Limited-Risk Systems

The AI Act is often discussed through the lens of high-risk AI, but high-risk systems are not the whole story. Some systems are subject to transparency obligations even where they are not high-risk.

Article 50 includes obligations for certain provider and deployer scenarios. Providers may need to inform people when they are interacting with an AI system and mark synthetic audio, image, video or text outputs in a machine-readable way. Deployers may need to inform people exposed to emotion recognition or biometric categorisation systems, and disclose deepfakes or certain AI-generated public-interest text.

These rules sit close to privacy transparency work. If an organisation already maintains privacy notices, employee notices, candidate notices, chatbot disclosures, call scripts or public information pages, AI Act transparency should be reviewed alongside them. The aim is not to turn every notice into a legal lecture. The aim is to avoid people being misled about whether they are interacting with an AI system, being assessed by it, or seeing AI-generated or manipulated content.

AI literacy is also not limited to high-risk systems. Article 4 requires providers and deployers to take measures, to their best extent, to ensure a sufficient level of AI literacy among staff and others dealing with operation and use of AI systems on their behalf, taking account of technical knowledge, experience, training, use context and affected people.

For DPOs, this is a practical bridge between law and behaviour. A policy sitting on an intranet will not prevent risky AI use if staff do not understand what counts as personal data, what must not be uploaded, when human review is needed, or when a system should be escalated. AI literacy records can also support the organisation’s wider accountability story: who was trained, on what, for which systems, and how the training matched the risk?

The Questions Privacy Teams Should Ask Before Deployment

The following checklist is intentionally compact. It can be used in procurement, DPIA screening, AI register intake, legal review or DPO challenge.

Use the checklist early. Once a system is embedded in a workflow, it is harder to unwind unclear roles, missing evidence, weak notices, over-broad input data or unrealistic human oversight.

Evidence That Should Connect Across the Lifecycle

The practical discipline is evidence connection. Privacy teams do not need to own every record, but they often see the gaps between records.

An AI system inventory may say the tool is used for “productivity”. A procurement file may say it is an enterprise SaaS product. A DPIA screening record may say no personal data is involved. Staff may in practice use it to summarise customer complaints, rank sales leads, screen CVs, generate case notes or draft employee performance feedback. Those are different risk stories.

A useful AI governance record should therefore connect the lifecycle: intake and discovery; role mapping; risk classification; data protection analysis; vendor and contract review; deployment approval; transparency and communications; human oversight; monitoring; and change control. Each stage should use the same factual description of the system, even where different legal tests are being applied.

This is where the AI/DPIA lifecycle matters. DPIAs are not only one-off documents for launch approval. For AI systems, they may need to support privacy accountability, AI Act readiness, board assurance, internal audit, procurement governance, regulator response and complaint handling.

XpertDPO’s AI Governance and DPIA Lifecycle Support is designed around that connection point: helping organisations align AI use case review, DPIA evidence and governance records without turning every project into a sprawling compliance exercise.

Where DPO Support Is Most Useful

Many organisations can handle low-risk AI governance through ordinary procurement, security and data protection processes, provided those processes have been updated for AI. Specialist DPO or privacy support becomes more valuable where the facts are tangled or the consequences for people are material.

Common examples include AI tools used in HR, recruitment, education, healthcare, financial services, insurance, legal services, public services, access to essential services, biometric processing, monitoring, profiling, scoring, fraud detection or decision support. These use cases can involve overlapping AI Act, GDPR, employment, equality and sectoral issues.

Support is also useful where the organisation is unsure whether it is still a deployer or has moved closer to provider responsibilities through branding, integration, fine-tuning, substantial modification or changed intended purpose. The governance risk is not only that the legal label is wrong. It is that the evidence model underneath it is wrong: the wrong team owns monitoring, the wrong contract captures incident duties, or the wrong notice describes the use.

For in-house DPOs, useful external support is often a structured second opinion: testing assumptions, sharpening the record, and keeping ownership inside the organisation. XpertDPO’s DPO Support, DPIA Support and Board / Legal Privacy Assurance pages are relevant where AI Act readiness is tied to privacy governance, board confidence or regulator-facing evidence.

Practical Takeaway for CPD and Governance

For CPD Event B Hour 3, the learning point is not that privacy teams must become full AI Act compliance owners. They should not quietly absorb every AI governance responsibility just because personal data is involved.

The learning point is that privacy teams are well placed to insist on a disciplined evidence model. They already understand accountability, DPIAs, notices, vendor review, retention, rights, incident response and risk assessment. The AI Act adds new legal roles and obligations, but the practical work still depends on clear facts, documented decisions, proportionate controls and reviewable evidence.

The smallest safe next step for most organisations is an AI register review focused on role mapping and evidence quality. Pick the systems already in use or closest to deployment. For each one, confirm the AI Act role, GDPR role, risk category, personal data use, affected people, provider evidence, DPIA or assessment status, human oversight, transparency position, monitoring owner and review date.

That will not answer every legal question. It will, however, show where the organisation has a reliable governance story and where it is relying on assumption. For AI governance, that distinction is often the difference between a manageable review and an avoidable scramble.

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.