A procurement team approves an AI-enabled recruitment tool, a product team embeds a large language model into customer support, or a business unit automates credit decisions. Each project can trigger obligations that are related but not interchangeable. The AI Act versus GDPR question is therefore not a choice between two compliance programmes. It is a question of how to operate one joined-up governance model that manages personal data, AI-specific risk and accountability from design through deployment.
For organisations expanding into or serving the EU, the distinction matters commercially as well as operationally. A GDPR programme alone will not evidence the controls expected for an AI system. Equally, an AI Act workstream that overlooks data protection can fail at the point where data is collected, tested, monitored or used to make decisions about people.
AI Act versus GDPR: different regulatory purposes
The GDPR governs the processing of personal data. Its central questions are familiar to privacy teams: what personal data is processed, on what lawful basis, for which purpose, for how long, with which safeguards, and with which rights for individuals. It applies across technologies, including AI, but it does not regulate AI simply because it is AI.
The EU AI Act is a product and governance framework for AI systems. It uses a risk-based model and addresses risks to health, safety and fundamental rights. Its scope can extend beyond personal data. An AI system trained solely on non-personal industrial sensor data may be outside GDPR while remaining within the AI Act's scope. Conversely, a straightforward HR database may process extensive personal data without being an AI system under the Act.
This difference changes the operational conversation. GDPR asks whether the organisation can lawfully and fairly process data. The AI Act asks, among other matters, whether the system is prohibited, how it should be classified, whether it has been designed and documented appropriately, and whether it can be used with meaningful human oversight.
The two regimes also allocate responsibility differently. GDPR focuses on controllers and processors. The AI Act establishes obligations for providers, deployers, importers, distributors and, in some circumstances, authorised representatives. A business buying an AI tool may be a deployer, but substantial modification, rebranding or changing the intended purpose can shift it towards provider responsibilities. That assessment should be made before the system reaches production, not after a vendor contract is signed.
Where the obligations overlap
Many controls serve both frameworks, but the reason for applying them is not always the same. Data governance is the clearest example. Under GDPR, teams need a lawful basis, purpose limitation, data minimisation, accuracy and appropriate security. Under the AI Act, high-risk systems require relevant, sufficiently representative and suitably governed data sets, alongside examination of potential bias and data gaps.
A data protection impact assessment can identify risks arising from profiling, special category data, large-scale monitoring or automated decision-making. It will not necessarily cover every AI Act requirement. A high-risk AI system may also require a fundamental rights impact assessment by certain deployers, as well as technical documentation, record-keeping, instructions for use and human oversight measures. The assessments can share evidence, owners and review cycles, but they should not be treated as identical documents.
Transparency creates another overlap. GDPR requires clear information about the processing of personal data. The AI Act imposes distinct transparency requirements in specified contexts, such as interacting with certain AI systems or dealing with particular AI-generated or manipulated content. A privacy notice alone is not a complete AI transparency control. User-facing disclosures, operating instructions, escalation routes and evidence of staff training may also be required.
Security has a similar dual function. GDPR requires security appropriate to the risk of processing. AI Act controls may additionally require accuracy, robustness and cybersecurity throughout an AI system's lifecycle. A model that exposes personal data through poor access controls presents a GDPR issue. A model that produces unreliable outputs under foreseeable conditions may also create an AI governance issue even where no personal data is involved.
Classification must come before control design
The most costly implementation error is treating every AI use case as though it carries the same compliance burden. The AI Act differentiates prohibited practices, high-risk AI systems, certain transparency obligations, general-purpose AI models and other systems. The correct route depends on the use case, the organisation's role and how the system is placed on the market or put into service.
Some uses are prohibited. High-risk systems, including systems used in certain employment, education, essential services, law enforcement, migration and critical infrastructure contexts, are subject to more extensive requirements. Systems outside those categories may still need GDPR controls and may be subject to AI Act transparency duties. General-purpose AI introduces another layer, particularly where an organisation develops, modifies or integrates models into downstream services.
Timing also requires disciplined planning. The AI Act entered into force in August 2024. Provisions on prohibited practices began applying in February 2025, and obligations for general-purpose AI models began applying in August 2025. Most provisions apply from August 2026, while requirements for certain high-risk systems have later application dates. An organisation should not use a future compliance date as a reason to postpone system inventory, role mapping or supplier engagement. Those activities take time, especially across multiple business units and jurisdictions.
Build one operating model, not parallel paperwork
A practical programme starts with an AI system register connected to the existing record of processing activities. The register should identify the system's purpose, owner, vendor, deployment locations, data inputs and outputs, affected groups, role under the AI Act, preliminary risk classification, and the assessments and controls attached to it. This creates a reliable starting point for legal, privacy, security, procurement and operational teams.
The next step is to establish a triage process before procurement or development proceeds. A short intake can determine whether personal data is involved, whether the system could affect individuals in a material way, whether it supports a potentially high-risk use, whether it uses a general-purpose model, and whether the organisation is making changes that alter its regulatory role. This is more effective than asking teams to complete lengthy assessments for every low-impact experiment.
For systems that need further review, the programme should connect privacy and AI assessment workflows. The DPIA, AI risk assessment, vendor assessment and, where relevant, fundamental rights assessment should draw from a common evidence base. Teams should be able to see which decisions have been made, who approved them, what residual risks remain and when reassessment is due following a material change.
Vendor governance deserves particular attention. Organisations increasingly rely on model providers, software vendors, cloud platforms and implementation partners, but contractual assurances do not remove deployer responsibilities. Procurement should obtain enough information to understand the system's intended use, data practices, performance limitations, documentation, security controls, incident processes and change-management arrangements. Where the vendor will not provide sufficient information, the organisation may need to restrict the use case, apply compensating controls or select another solution.
Human oversight must be designed for the actual operating environment. A named reviewer who cannot understand the output, override it, challenge it or escalate an issue is not meaningful oversight. For recruitment, lending, health or workplace systems, organisations should define who can intervene, what evidence they need, how decisions are recorded and when the system must be suspended. This is where policy language becomes day-to-day control.
Governance needs legal, privacy and technical ownership
AI governance cannot sit entirely with legal or privacy teams. Legal interpretation is necessary to define obligations and roles. Privacy specialists are needed to manage lawful processing, assessments, data subject rights and international data flows. Technical operations teams must translate requirements into configuration, access management, testing, logging, monitoring and incident response.
That three-team model is particularly valuable for international organisations. A system may be developed in one country, hosted in another, deployed across the EU and used by teams in the UK or APAC. The organisation needs clear ownership that travels with the system, while allowing for local privacy, representative and sector-specific requirements. A central register and consistent workflows create control without forcing every market to invent its own process.
Board reporting should focus on decisions and evidence, not broad statements that AI is compliant. Senior leaders need visibility of the AI estate, high-risk or sensitive use cases, unresolved vendor gaps, assessment status, incidents, policy exceptions and the resources needed to operate controls. This supports informed accountability and avoids compliance becoming a late-stage approval obstacle.
Formiti supports this type of implementation by bringing legal, privacy and technical operations expertise into a single operating model, including AI governance workflows that can be managed alongside DPIAs, DSARs, ROPAs, breach response and vendor risk activity.
The useful question is not whether the AI Act or GDPR takes priority. It is whether each AI use case has a clear owner, a defensible purpose, appropriate data controls, documented risk decisions and a workable route for intervention when the system behaves unexpectedly. Organisations that can answer those questions consistently will be better placed to deploy AI with the control that regulators, customers and their own leadership expect.