The EU AI Act and GDPR: A Practical Compliance Framework for AI
UIT, UIB, UIC, UID Cross-institute lecture
Series Cross-Institute Series | Level Basic (Free)
Duration 25 minutes | Access Free
Delivering institutes: UIT (Institute of Technology); UIB (Institute of Business); UIC (Institute of Communication); UID (Institute of Design)
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to prepare your brain. Play the isochronous tone track (40Hz gamma frequency) with your eyes closed. Gamma-frequency tones before a learning session raise attention and make the material easier to absorb.
[Audio player: UNOP Pre-Lecture Isochrone (40Hz, 5 minutes)]
In this Lecture
The Hook: The Demo That Was Legal on Friday
A product team ships an assistant that drafts customer replies. On Monday, a member of the leadership team asks two questions in the same breath: do we have to tell people they are talking to an AI, and can we keep the chat transcripts to train next year's model?
Both questions are answerable, and neither answer comes from reading the code. The first comes from the EU AI Act, which has transparency duties that started to apply on 2 August 2026. The second comes from the GDPR, which governs the personal data in those transcripts no matter what the AI Act says. The same feature sits inside two regimes at once, and each regime asks a different question.
Most teams fail at the seam. They read a summary that says the AI Act was postponed, so they conclude that nothing applies. Or they treat the GDPR as a privacy policy document rather than an operating rule, so they never ask which lawful basis carries the processing. Or they assume their vendor carries the responsibility, when several duties sit on the deployer and cannot be moved by contract.
This lecture gives you a method. It maps your use case, classifies it under the AI Act, identifies the duties that actually fall on you, and records the evidence. It is cross-institute because the answer does not depend on your discipline: a hiring model in a business team, an analytics pipeline in a technology team, a generative campaign in a communication team, and a deceptive interface in a design team all meet the same two regimes.
One commitment before we start: this lecture is a framework, not a legal opinion. Where regulation applies, the regulation comes first, and this framework is how you organise compliance with it. Dates, thresholds and duties change, so verify the current text before you rely on anything here.
Step 1: Know Which Regime You Are In
Two European instruments govern most AI work done for or with people in the European Union, and they answer different questions.
The EU AI Act (Regulation (EU) 2024/1689) regulates the AI system and its use. It classifies systems by risk, sets duties on the organisations that build and use them, and adds transparency requirements for certain uses. It regulates the practice, whatever data is involved.
The GDPR (Regulation (EU) 2016/679) regulates personal data. It asks whether you have a lawful basis for processing, whether the processing is necessary and minimal, whether people are told, and whether you have assessed the risks to them. It regulates the data, whatever the technology is.
You therefore do not choose between them. A single AI system can be in scope of both, in scope of one, or in scope of neither, and the two tests are independent. A model trained on no personal data still has AI Act duties. A non-AI spreadsheet full of customer records still has GDPR duties.
Two scope questions settle most cases quickly.
First, for the AI Act: does the system reach the EU market or affect people in the EU? Article 2 also catches providers and deployers outside the EU where the output of the system is used in the Union. The test is where the output lands, not where your company is registered or where the model runs.
Second, for the GDPR: does the processing involve personal data of people in the EU, and are you a controller or a processor for it? A controller decides why and how the processing happens. A processor acts on a controller's instructions. You can be a controller for one activity and a processor for another, and AI vendors frequently sit on both sides depending on the feature.
Write those two answers down before you read another summary. Most confusion in this area comes from teams arguing about obligations before they have agreed on scope.
Step 2: Classify the System Under the AI Act
The AI Act is a risk-tiered regulation. The tier, not the technology, determines what you owe. There are four tiers, and the classification is a property of the intended use, not of the model.
Prohibited practices. Article 5 bans a closed list of uses outright, in force since 2 February 2025. The list covers manipulative and exploitative techniques that distort behaviour and cause significant harm, social scoring by public authorities, untargeted scraping of facial images to build recognition databases, emotion inference in the workplace and in education, biometric categorisation to infer sensitive attributes, and the exploitation of vulnerabilities of specific groups. The Digital Omnibus added further prohibitions covering non-consensual sexual deepfakes and child sexual abuse material, applying from 2 December 2026. If a use is prohibited, no amount of documentation cures it: the answer is not to ship it.
High-risk systems. Two routes lead here. Article 6(1) covers AI that is a safety component of a product already regulated under the Union harmonisation legislation listed in Annex I, such as machinery, medical devices or vehicles, where a third-party conformity assessment is required. Article 6(2) covers the standalone uses listed in Annex III: biometric identification and categorisation, critical infrastructure management, education and vocational training, employment and worker management, access to essential public and private services including creditworthiness assessment, law enforcement, migration and border control, and the administration of justice. A screening tool that ranks job applicants and a model that scores creditworthiness are the familiar examples. An exemption exists where a system performs a narrow procedural task or does not materially influence the outcome, but it is narrow and the record of your reasoning matters.
Limited-risk, meaning transparency duties. Article 50 covers uses that are not high-risk but affect how people understand what they are dealing with: AI systems that interact directly with a person, systems that generate synthetic audio, image, video or text, emotion recognition and biometric categorisation systems, and deepfakes or AI-generated text published on matters of public interest. This tier is where most commercial deployments land, and it is the one that became enforceable earliest. Step 4 sets out its dates.
Minimal-risk. Everything else, which is most AI in practice: spam filters, back-office automation, recommendation ordering with no external human counterpart. The AI Act imposes no specific obligation beyond the literacy duty in Article 4. That does not mean no rules apply: the GDPR, consumer law, sector rules and your own contracts still govern.
Classify in writing, with the Annex III category named or the exclusion stated. A classification with no reasoning behind it is the first thing an authority will ask you to produce.
Step 3: Identify Your Role, Provider or Deployer
The AI Act assigns duties to roles, not to companies. Getting the role wrong is the most common cause of both over-compliance and a surprise obligation.
A provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name or trademark. Placing a system under your own brand makes you a provider, even when you did not train the model. For high-risk systems, Article 16 places the heavy duties on the provider: a quality management system under Article 17, technical documentation, record keeping, the relevant conformity assessment before release, an EU declaration of conformity, the CE marking, registration in the EU database where required, and corrective action when a problem appears.
A deployer uses an AI system under its own authority. Article 26 places the deployer duties on organisations that run a high-risk system: use it according to the instructions for use, assign competent human oversight, manage the input data within your control, keep the automatically generated logs for at least six months, inform the provider and the authority of serious incidents or risks, and, for workplace use, inform workers' representatives and the workers concerned. Public authorities that deploy high-risk systems also register their use.
The Article 50 split runs paragraph by paragraph, and this is the part most summaries get wrong. The duty to tell a person they are interacting with an AI system, Article 50(1), sits on the provider. The duty to mark synthetic output in a machine-readable way, Article 50(2), sits on the provider. Disclosure of emotion recognition and biometric categorisation, Article 50(3), sits on the deployer. Disclosure of deepfakes and of AI-generated text published on matters of public interest, Article 50(4), sits on the deployer.
Two practical consequences follow. First, no supplier contract moves a deployer duty, so read Article 50 again for your own configuration and not just for your vendor's. Second, two duties are yours even when the model is not: the Article 4 literacy measures, which apply to providers and deployers alike, and the GDPR accountability that follows your processing regardless of who built the system.
White-labelling is the trap. If you put your own brand on a vendor's assistant, you are the provider for the purposes of the AI Act, and the chatbot disclosure duty in Article 50(1) becomes yours to design and evidence.
Step 4: Read the 2026 Calendar Correctly
The AI Act applies in phases, and the phases changed in 2026. Regulation (EU) 2026/1744, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred the high-risk regime and left the transparency and literacy duties where they were. Read the calendar in order and the shape becomes clear.
Applicable now, and already enforceable. The general provisions and definitions, and the AI literacy duty in Article 4, have applied since 2 February 2025. The prohibitions in Article 5 have applied since the same date. The obligations on providers of general-purpose AI models have applied since 2 August 2025, and the governance structures and national penalty regimes were due by then too.
2 August 2026. The majority of the Act's rules started to apply, together with enforcement. The Article 50 transparency rules apply from this date. So does enforcement by national and European authorities of the general-purpose AI obligations, the prohibitions, the transparency rules and AI literacy. The European Commission adopted final guidelines on the Article 50 transparency obligations on 20 July 2026, which is the reference to read for how the duties are meant to operate in practice.
One narrow grace period. Article 50(2) requires providers of generative systems to mark synthetic output in a machine-readable and detectable way. For systems already on the market before 2 August 2026, this specific marking duty has a transition to 2 December 2026. Anything placed on the market after 2 August 2026 is in scope from day one. The other Article 50 duties, including the chatbot disclosure, have no such transition.
2 December 2026. The added prohibitions on non-consensual sexual deepfakes and child sexual abuse material apply, and the Article 50(2) transition for existing systems ends.
2 August 2027 and 2 December 2027 and 2 August 2028. Member States should have at least one AI regulatory sandbox operational by 2 August 2027. The high-risk obligations for the Annex III standalone uses apply from 2 December 2027, deferred from 2 August 2026 by the Omnibus. The high-risk obligations for AI embedded in products under Annex I apply from 2 August 2028.
Two errors follow from misreading this calendar. The first is treating the high-risk deferral as a general postponement, when Article 50 and Article 4 stayed on schedule. The second is treating the deferral as a cancellation, when conformity assessment, technical documentation, human oversight and registration are all still coming, and the sixteen months are preparation time rather than a reprieve from the work.
Two cautions. Verify the current text of the regulation before you rely on a date, because amendments after this lecture are possible. And confirm the position in your own jurisdiction as well, because the Act sits alongside national law and the GDPR sits alongside national implementations.
Step 5: Apply GDPR to the AI Lifecycle
The GDPR is not an AI regulation, and that is exactly why it applies to your AI work without a special clause. Four requirements carry most of the weight.
A lawful basis before the processing starts. Article 6 requires one of six bases for any processing of personal data: consent, contract, legal obligation, vital interests, public task, or legitimate interests. The choice is not interchangeable, because each base carries its own consequences. Consent must be freely given, specific, informed and withdrawable, which is difficult to obtain for data you already hold. Legitimate interests require a documented three-part assessment: a genuine and specific interest, necessity, meaning no equally effective and less intrusive route, and a balancing test in which the interests and rights of the people concerned do not override yours. The European Data Protection Board has confirmed in its guidance that legitimate interests can support AI development, subject to that test, and that a generic interest such as improving our AI is not enough. Name the specific objective.
Data minimisation, applied at the point of collection. Article 5 requires personal data to be adequate, relevant and limited to what is necessary. For AI, that means filtering before you collect or train, rather than cleaning the dataset afterwards. This is the requirement most commonly under-implemented, because pipeline design usually optimises first and filters later.
Transparency about the processing. Articles 13 and 14 require you to tell people what you do with their data, including where you obtain it indirectly. At AI training scale, individual notification is often impossible, and a narrow disproportionate-effort exception exists. If you rely on it, you are expected to compensate with clear public information and an accessible route to object. A privacy notice that says nothing specific about model training does not satisfy this.
A data protection impact assessment where the risk is high. Article 35 requires a DPIA for processing likely to result in a high risk to rights and freedoms. Large-scale processing for AI training and consequential automated decisions are treated as high-risk in practice, and the EDPB's guidance confirms that AI systems classified as high-risk under the AI Act require a DPIA. The AI Act reinforces the point from the other direction: Article 26(9) requires deployers to use the provider's information under Article 13 of the AI Act to carry out their DPIA.
One further rule that surprises business and communication teams: Article 22 restricts decisions based solely on automated processing that produce legal effects or similarly significant effects. A screening, pricing or eligibility decision made by a model, with no meaningful human involvement, needs a specific basis and explicit safeguards, including the right to obtain human intervention and to contest the outcome.
Treat the four requirements as one file, not four projects. The lawful basis, the minimisation decision, the transparency wording and the DPIA all describe the same processing, and an authority will read them together.
Step 6: What Changes for Training and for Inference
The GDPR analysis splits across the AI lifecycle, and treating the lifecycle as one activity is the most consequential simplification teams make.
Training is processing. Using personal data to train or fine-tune a model is processing under the GDPR, whether or not you keep the data afterwards. You need a valid basis before the training run, and a basis assembled afterwards is not a basis. In its Opinion 28/2024 on AI models, the EDPB set out this position and tightened the legitimate-interest test for training: the interest must be concrete, the necessity test applies to the composition of the training data, and the balancing test weighs factors such as web-scraped sources, sensitive categories, vulnerable groups and the practical irreversibility of training.
Web scraping has been addressed directly. In July 2026 the EDPB adopted draft Guidelines 03/2026 on web scraping in the context of generative AI. The guidance confirms that publicly accessible does not mean unrestricted: the GDPR applies to the collection, storage, organisation and retrieval involved in scraping, and a controller relying on legitimate interests must run the balancing test with the reasonable expectations of the people concerned at the centre. Signals from a site, such as a robots.txt entry, an ai.txt file or a CAPTCHA, weigh against the expectation that its content will be reused for model training. The mitigating measures the guidance expects are operational: exclude sensitive sources and sites used mainly by minors, limit collection to freely accessible data, publish clear information and an opt-out route, delete or anonymise promptly, and engineer against memorisation and regurgitation. The guidelines were in public consultation at the time of writing, so check their final status before relying on a specific paragraph.
Anonymity is assessed, not assumed. A trained model is rarely anonymous by default, because a model trained on personal data may still reproduce or reveal that data through extraction, regurgitation or inference. Any claim that a model falls outside the GDPR because it holds no personal data needs a documented assessment of how likely that is, on a model-by-model basis.
Inference is a separate operation with its own basis. Deployment processes personal data too: the prompt, the context, the output and the logs. Where inference feeds decisions that affect a person, the Article 22 safeguards apply on top of the Article 6 basis. And where you reuse deployment data to retrain or improve the model, that is a new purpose, so it needs a fresh basis rather than inheriting the training basis. A feedback loop that logs prompts for retraining without a purpose analysis is one of the most common findings in a review.
Special category data has no general AI exemption. Article 9 restricts processing that reveals health, biometric data used for identification, and other sensitive categories to a closed list of conditions. Public availability alone does not make data manifestly made public for this purpose. Where you process sensitive data for AI, name the Article 9 condition you rely on.
Roles along the value chain. Article 25 of the AI Act places responsibilities on distributors, importers and others in the chain, and the GDPR splits controller from processor. When you use a vendor's model, you remain accountable for your own processing, so ask for the evidence you need, in writing: how the model was trained, what the vendor asserts about lawful bases, and how the vendor handles access, objection and erasure requests that reach into the model.
The Practical Compliance Framework: Four Artifacts
Here is the working method. It produces four artifacts in one week for one system, and the artifacts are what you show when someone asks.
Artifact 1: The use case map. One page. What the system does, who it affects, where the output lands, and which jurisdictions and sectors are in play. Name the direct users, the subject individuals represented in the data, the third parties who bear the spillover, and your own organisation. For each, note what they receive, what they can lose, and what recourse they have.
Artifact 2: The classification record. One page. The AI Act tier you assign and why, naming the Annex III category or the exclusion you rely on, plus your role, provider or deployer, for each part of the system. Add the GDPR side: controller or processor, the lawful basis for each processing operation, and whether a DPIA is required and completed.
Artifact 3: The duty list. One page. Every obligation that actually falls on you, with an owner and a date, drawn from the two regimes rather than from a vendor's summary. Expect the list to look like this: a chatbot disclosure live at the start of the interaction, a synthetic-content marking check in the publishing flow, a deepfake disclosure rule for campaign media, literacy measures for the teams using AI, an Article 30 processing record updated for the AI activity, a DPIA for the high-risk processing, and a contest route for consequential decisions.
Artifact 4: The evidence pack. The folder that holds what you can prove: the classification memo, the legitimate-interest assessment, the DPIA, the DPIA sign-off, screenshots or session records showing the disclosure served at the start of a real interaction, the marking check on published output, the literacy policy with its training record, the vendor answers in writing, the log retention decision, and the incident procedure. The evidence pack is not decoration. It is the difference between asserting compliance and demonstrating it.
Run the four artifacts in order, because each depends on the previous one. You cannot list duties before you know your role, and you cannot prove compliance before you have decided what you owe. Revisit the classification when the use case changes, since a new prompt, a new data source or a new customer-facing channel can move the tier.
Governance as CI-First: Verification, Documentation, Accountability
A compliance framework that nobody runs is a document. The CI-First approach, Co-Intelligence First, is what turns it into a practice, and it maps onto governance with unusual precision.
The human is the ruler, the machine is the amplifier. In the CI-First model, the judgement calls with consequences belong to a named person, and AI accelerates the work around them. Compliance is exactly that shape. The classification, the lawful basis, the DPIA conclusion and the go or no-go decision are calls with consequences, so they belong to a named human. The machine is genuinely useful in the same workflow: enumerating the Annex III categories you might fall under, drafting the legitimate-interest assessment, translating regulation summaries, generating the processing record, stress-testing your own evidence pack, and keeping the register current.
Verification before assertion. Do not claim compliance you have not tested. Ask the system to show the disclosure at the start of a real interaction. Publish a test item and check that the marking is present. Walk a contest request through to a response. Verification is the same discipline the engineering team applies to a release, and here it is what separates a defensible position from an assertion.
Documentation as the accountability mechanism. If a decision cannot be written down and signed, it should not be made. The discomfort of recording that you accept a specific residual risk, and why, is the mechanism through which governance stops being decorative. The classification record and the evidence pack are the institutional memory of that decision, and they are the first thing requested when something goes wrong.
A single register, not scattered files. Keep one place where each AI system has its classification, its lawful basis, its owner and its next review date. The register is what lets you answer the question that arrives without warning: which systems do we run, and what do we owe for each.
Review on change, not just on a calendar. A quarterly review will miss the model upgrade, the new data source or the new channel that changes the analysis. Add the framework to your change process, so that a material change triggers a re-classification rather than waiting for the next cycle.
Step 7: The DPIA That Survives a Question
A data protection impact assessment is the document most likely to be read by someone hostile to your project. A regulator, a customer's security team or your board will take it, pick one sentence and ask you to prove it.
The first failure is describing the system instead of assessing the risk. A DPIA that lists the architecture, the model and the vendor is a technical summary. The assessment names a specific harm to a specific group and then says what you did about it. "The system processes applicant data" is a description. "A model rejects candidates on a score the applicant cannot see, so the rejection is indistinguishable from a decision nobody made" is a risk.
The second failure is a measure with no owner and no date. "Access controls in place" is not a measure. "Access to the training extract is limited to the two engineers named in the register, reviewed on 1 March 2027" is a measure, because it can be checked and it can be overdue.
The third failure is a conclusion that has not been tested. If the DPIA says the disclosure is shown at the start of every interaction, someone should have opened the product and looked.
A worked example. A business team deploys an assistant that drafts replies to customer complaints, and copies the transcripts into a warehouse for a future retraining run. The harm is a real one: complaint transcripts carry health details, financial difficulty and family circumstances, and the people who wrote them did not expect their words to train a model.
The measure set is short and every item is dated. Retention: the warehouse receives transcripts stripped of names, account numbers and contact details, and keeps them for ninety days before a quarterly review. Lawful basis: legitimate interests for service quality, with the three-part test written out. Transparency: the customer is told that an assistant drafts the reply and that the transcript is used to improve the service, with a route to object.
Then the honest conclusion. The residual risk is that a determined extraction attempt pulls a fragment of a real complaint from the model. The assessment records that the risk is accepted, because the data is stripped before training and the retention is short. Acceptance with reasons is defensible. Silence is not.
Two habits keep a DPIA useful after the first week. Keep it short enough to re-read, and re-open it on change rather than on a calendar. A DPIA that has not moved since launch is evidence of a process that stopped.
The Questions That Decide the Real Cases
Across the reviews that go wrong, the same six questions decide the outcome.
Who is the subject, and what can they lose? Name the people, not the data category: applicants, workers, patients, customers in financial difficulty. If you cannot name what a person can lose, you have not found the risk yet.
Which decision does the output change, and can a person contest it? A model that orders a work queue is not the same as a model that removes a person from it. The second needs a human route and a written contest procedure.
Where did the training data come from, and what did the people expect? A licensed dataset, an internal archive and a web scrape carry different expectations, and the balancing test turns on that difference.
Who can be asked for evidence, and by when? Every duty needs a name against it. A duty list without owners is a wish list.
What would make you stop? Write the condition down before launch. A pre-agreed stop condition, such as an extraction test that reproduces real personal data, turns a governance document into an operating rule.
When is the next review, and what pulls it forward? Date it and name the change events that trigger it early.
Feynman Summary: Explain It Like You Are 12
Imagine your class runs a snack stand, and there are two sets of rules pinned to the wall.
The first set is about the machine you built. It says some machines are banned, some are allowed only if you put a big safety label on them, some just have to tell people they are machines, and the rest are fine. That set of rules also says who is responsible: the person who built the machine, or the person who plugs it in and uses it.
The second set is about the people in your notebooks. It says you may only keep a note about someone if you have a real reason, you must not keep more notes than you need, you must tell people what you are writing down, and if your plan could hurt someone, you have to write down the danger and how you will handle it first.
You do not get to choose one set. If you build a machine that also uses people's notes, both sets apply. So you do four things: you write down what your machine does, you decide which rule it falls under, you list what you owe for it, and you keep the papers that prove you checked. If you cannot show the papers, you have not really done it.
Mindmap: The Complete Picture
The mindmap gathers the lecture into one view: the two regimes, the four risk tiers, the provider and deployer split, the amended 2026 calendar, the GDPR duties across training and inference, and the four artifacts that make the framework auditable.
UNOP Sound (University 365 Neuroscience Oriented Pedagogy)
Take five minutes to consolidate your memory. Play the isochronous tone track (10Hz alpha frequency) with your eyes closed. Alpha-frequency tones after a learning session support consolidation, helping move what you just learned from short-term to long-term memory.
[Audio player: UNOP Post-Lecture Isochrone (10Hz, 5 minutes)]
Practical Exercise: Classify and Evidence One Real System
Choose one AI system your team runs today or plans to launch. Work with one colleague from a different function. Two sessions of ninety minutes.
Part 1: Map and classify (90 minutes)
Write the use case map: what the system does, who it affects, where the output lands, which jurisdictions and sectors are in play.
Determine scope for both regimes. Does the AI Act reach it, and does the GDPR apply to the processing?
Assign the AI Act tier and write the reasoning. Name the Annex III category or the exclusion you rely on.
Name your role for each part of the system: provider, deployer, or both.
For the GDPR, name the lawful basis for each processing operation and decide whether a DPIA is required.
Part 2: Duties and evidence (90 minutes)
Build the duty list from the two regimes, not from a vendor summary. Give every item an owner and a date.
Read the AI Act Article 50 duties against your own configuration, and decide which of the four fall on you.
Check the disclosure or marking in the running system, not in the specification. Record what you saw.
Start the evidence pack. Put the classification memo, the lawful basis assessment and the current privacy wording in one folder.
Ask your AI vendor, in writing, how the model was trained, what they assert about lawful bases, and how access, objection and erasure requests are handled.
A checkpoint after thirty days
Re-read the four artifacts. Name one change you made because of the exercise. If nothing changed, the framework has become ritual: simplify it until it bites.
Applied CI-First connection
You made the classification and the lawful-basis calls: those carry consequences for real people, and they belong to a named human. The machine was a useful assistant throughout: enumerating the Annex III categories, drafting the legitimate-interest assessment, translating the regulation, generating the processing record, and testing whether your evidence pack would survive a question. The accountability for what ships stays exactly where it started: on the person whose name is on the classification record.
Glossary
Term | Definition |
EU AI Act | Regulation (EU) 2024/1689, the risk-tiered European regulation for AI systems placed on or used in the EU market. |
Digital Omnibus on AI | Regulation (EU) 2026/1744, published 24 July 2026, which amended the AI Act and deferred the high-risk deadlines. |
Provider | An organisation that develops or places an AI system on the market under its own name, carrying the Article 16 duties for high-risk systems. |
Deployer | An organisation that uses an AI system under its own authority, carrying the Article 26 duties and several Article 50 disclosure duties. |
Prohibited practice | A use banned outright by Article 5 of the AI Act, from social scoring to workplace emotion inference and untargeted facial scraping. |
High-risk AI system | An AI system in an Annex I regulated product or an Annex III use case, subject to the conformity, documentation and oversight regime. |
Annex III | The list of standalone high-risk uses: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice. |
Article 50 transparency | The duty to disclose AI interaction, mark synthetic output, and label deepfakes and AI-generated public-interest text. |
Article 4 AI literacy | The duty on providers and deployers to take measures supporting AI literacy among their staff, in force since 2 February 2025. |
GDPR | Regulation (EU) 2016/679, the general data protection regulation governing the processing of personal data. |
Lawful basis | One of the six Article 6 conditions that makes a processing operation lawful, such as consent, contract or legitimate interests. |
Legitimate interests | The Article 6(1)(f) basis, requiring a documented three-part test of purpose, necessity and balancing. |
Data minimisation | The Article 5 principle that personal data must be limited to what is necessary for the stated purpose. |
DPIA | Data protection impact assessment under Article 35, required for processing likely to result in a high risk to rights and freedoms. |
Article 22 | The GDPR restriction on decisions based solely on automated processing that produce legal or similarly significant effects. |
Controller | The organisation that determines the purposes and means of the processing. |
Processor | An organisation that processes personal data on a controller's instructions. |
5M2S | 5 Minutes to Success, University 365's microlearning format. |
Quiz: TEST YOUR UNDERSTANDING
1. Which statement about the two regimes is correct?
A) The AI Act replaces the GDPR for AI systems
B) The AI Act regulates the AI system and its use, the GDPR regulates the personal data, and both can apply at once
C) The GDPR applies only to AI systems placed on the EU market
D) Only one regime applies to any given system
2. Under the AI Act as amended in 2026, which duty applied from 2 August 2026 without a general deferral?
A) The Annex III high-risk obligations
B) The Annex I embedded high-risk obligations
C) The Article 50 transparency obligations
D) The Member State regulatory sandboxes
3. Who carries the Article 50(4) duty to disclose a deepfake?
A) The provider of the generative model
B) The deployer who uses the system to produce or publish the content
C) The hosting provider of the website
D) Nobody, if the content is labelled elsewhere
4. What does the EDPB require for a legitimate-interest claim to train a model on personal data?
A) A general statement that the data improves the AI
B) A documented three-part test: a specific interest, necessity, and a balancing test against data subject rights
C) Prior consent from every data subject in all cases
D) Nothing, because publicly available data is exempt
5. When you reuse logged prompts and outputs to retrain a model, what does the GDPR require?
A) Nothing further, because the training basis covers it
B) A fresh assessment, because reuse for training is a new purpose with its own basis
C) Only a privacy notice update
D) Deletion of the logs after six months
6. What is the deployer's obligation where a high-risk system is used in the workplace?
A) To obtain consent from each worker
B) To inform workers' representatives and the affected workers, and to keep the logs
C) To redesign the model
D) To publish the source code
Answers: 1-B, 2-C, 3-B, 4-B, 5-B, 6-B
Related Resources
U365 INSIDE Publications
Lecture: Ethics and AI: A Practical Framework for Every Field: the harm map and control set that this compliance framework builds on
Lecture: The CI-First Workflow: Applied to Any Field: the ownership model behind the governance section
Lecture: AI Safety and Alignment: Why Hallucinations Happen: the technical family of accuracy and reliability failures
Lecture: Crisis Communication in the AI Age: what happens when disclosure and evidence were missing
External Resources
EU AI Act Service Desk, implementation timeline: the official calendar as amended, including the Digital Omnibus note: ai-act-service-desk.ec.europa.eu
EU Artificial Intelligence Act, article-by-article text: the full amended text, articles and annexes: artificialintelligenceact.eu
European Commission, a European approach to AI: the policy context behind the regulation: digital-strategy.ec.europa.eu
GDPR, official text: Regulation (EU) 2016/679 in the Official Journal: eur-lex.europa.eu
European Data Protection Board: opinions, guidelines and consultations, including the AI models opinion and the web scraping guidelines: edpb.europa.eu
NIST AI Risk Management Framework: the risk-management structure referenced across the framework: nist.gov
Related U365 Lectures
Lecture 1: The CI-First Workflow: Applied to Any Field (UIT, UIB, UIC, UID, Cross-Institute Series)
Lecture 4: The AI Product Launch: From Code to Market (UIT, UIB, UIC, UID, Cross-Institute Series)
Lecture 5: Ethics and AI: A Practical Framework for Every Field (UIT, UIB, UIC, UID, Cross-Institute Series)
U.Copilot for This Lecture
Discuss this lecture with U.Copilot, your AI chat companion trained on this content.
Copy and paste the following prompt into the U.Copilot chat on university-365.com:
You are U.Copilot for Lectures, an AI chat companion specially trained on University 365 lecture content. You are helping a Fellow who just completed the cross-institute lecture "The EU AI Act and GDPR: A Practical Compliance Framework for AI". Your role is to help the Fellow build the four artifacts for a real AI system. You can: - Build the use case map, including subject individuals and third parties - Walk the AI Act classification, naming the Annex III category or the exclusion - Determine the role split: provider, deployer, or both, for each part of the system - Identify which Article 50 duties fall on the Fellow's own configuration - Draft the legitimate-interest assessment and the DPIA outline - Assemble the duty list with owners and dates, and structure the evidence pack Always maintain U365's CI-First approach: the classification, the lawful basis, the DPIA conclusion and the go or no-go decision belong to named humans, and AI accelerates enumeration, drafting, translation and stress-testing. Never present an unverified legal statement as fact. Point to the primary source, state the date of the version you are relying on, and recommend qualified advice for the Fellow's jurisdiction. Dates and duties in this area change: if the Fellow needs a current position, say so and direct them to the official texts. Use the UP-Context Method: provide context-rich, role-aware responses that account for the Fellow's field, sector, jurisdiction and regulatory environment.
Next Steps
Write the two scope answers for one system you run: does the AI Act reach it, and does the GDPR apply to the processing.
Classify in writing and name the Annex III category or the exclusion you rely on.
Name your role for each part of the system, and read the Article 50 duties against your own configuration rather than your vendor's summary.
Verify the live behaviour, not the specification: check the disclosure in a real interaction, the marking on published output, and the contest route end to end.
Start the evidence pack and add it to your change process, so a material change triggers a re-classification.
Compliance is not a document you file once. It is a working method: map the use case, classify it honestly, identify the duties that fall on you, and keep the evidence that proves you checked. Applied once to a real system, the framework stops being a reading exercise. It becomes a procedure you can point to, audit, and improve.
IMPORTANT NOTICE
This lecture is published by University 365 as part of its INSIDE Publications Hub. The content is free to read for all visitors. Lectures in this series may be part of a structured academic program leading to a Micro-Credential for your Career (MCC). To enroll in an academic program, visit university-365.com/tuition.
This lecture is educational and does not constitute legal advice. This is a framework, not a legal opinion. Regulation and standards develop quickly and differ by jurisdiction: verify current texts and obligations against the primary sources linked above, confirm the position in your own jurisdiction, and take qualified advice before relying on any framework in your organization.
Copyright University 365, Inc. All rights reserved. This content is protected under University 365's copyright policies. For permissions or inquiries, contact uda@university-365.com.
Published by the Department of Academics, University 365.
Lecture delivered by the UIT, UIB, UIC, UID in collaboration.
Martin Swartz, Dean of Academics, UDA
Signed for the academic year 2026.
Comments