Generative AI, GDPR and the EU AI Act in 2026: what an analyst and a manager need to know

Using an AI assistant on an analytics project

An assistant writes an answer that sounds right, not one that has been checked, so you brief it well and then question what it says.

A general-purpose assistant sits on a language model: it produces the text that best fits your request and what it learned in training. That makes it a good drafter and explainer, and an unreliable source wherever the answer has to be exact. The deck sets the two sides next to each other.

A prompt is a brief, written as for a new analyst

1. Context and data dictionary. Who you are, which decision is at stake, which tables and columns exist, and what a single row stands for.
2. Task. One job per request; five questions in one prompt tend to come back as five thin answers.
3. Format. Something you can verify, such as a query you will run yourself, a table or three sentences.
4. Constraints. What it must not assume or touch, and a closing request to list the assumptions it made.

The structure of the table goes into the prompt, never its rows: the assistant writes the query, and the group runs it in DuckDB on the real file. The first answer is then treated like the work of a quick but junior colleague. Ask which orders the query dropped and why, ask again with a correction and a row count you can verify, and ask for the strongest case against your own conclusion, so the objection comes up before the meeting rather than during it.

The workshop runs at the top level of the course's AI scale: assistant use is expected, and each group reports one output it kept, one it rejected and the check that made the difference. Any assistant will do, free tiers included. The same rule as in Session 1 applies at work: describe the structure of company data to an approved tool, and never paste personal or confidential records into a public one, since consumer versions may keep conversations.

Back to contents.

Plausible errors and the five checks

The dangerous mistakes are the ones that run without complaint and return a believable number, so the check must match what is at stake.

The deck ranks errors by how hard they are to see. A column name the assistant made up fails loudly: the query stops. A join that multiplies rows runs and returns a total that looks fine; you notice only if you compare it with a total you trust. Worst of all is a hallucination, a confident statement or a reference to a study that does not exist, sometimes under a real author's name: nothing in the output warns you.

Worked example: a query that runs and lies

The example is the orders-by-state query from SQL for managers, redrafted by an assistant with an extra join to the items table and a plain COUNT(*). States come out in a sensible order, yet each order is counted once per item it contains. Summing the column and setting that sum against the size of the orders table exposes the inflation in seconds; the repair is to count distinct order identifiers, or to remove a join the question never required.

Not every output deserves all five. A figure headed for the recommendation slide needs at least the first two; any sentence that cites a study needs the third. Each check is logged in a line (tool, task, what was compared with what), and those lines become the half-page AI-use appendix of the final brief. A vague statement that AI was used everywhere tells the reader nothing; honest disclosure is never held against a group.

Back to contents.

What the GDPR asks of an analytics project

Data are personal as soon as someone can be identified, even indirectly, and then the project needs a lawful basis, a compatible purpose and no surplus data.

The General Data Protection Regulation, Regulation (EU) 2016/679, protects people rather than files. Article 4(1) defines personal data as any information about a person who is identified or can be identified. In analytics the risk seldom sits in the name column: it comes from ordinary details (a date, a postcode, an amount) that single someone out once combined.

One basis applies per use, and it is settled before the work starts, not found afterwards. Consent is not the default many people assume; internal analytics often rests on contract or on legitimate interests, the latter only after a genuine balancing test. Two principles of Article 5 come up every day. Purpose limitation: data gathered for one purpose are not reused for an incompatible one, such as delivery addresses turned into neighbourhood profiles. Data minimisation: take only what the question needs. Measuring late deliveries does not require customer names, and fewer columns also mean fewer errors.

Pseudonymisation swaps direct identifiers for codes, but whoever holds the correspondence table can reverse it, so the GDPR keeps applying. Only data that nobody can link back to a person by reasonable means are anonymous and fall outside the regulation, and that bar is high: deleting names and e-mail addresses rarely suffices while dates, places and amounts remain. The Olist file was published as anonymised open data, which is why the class can work on it freely.

Four questions to ask of any project, in this order

1. Personal data? Directly, indirectly or through a combination. If not, the GDPR stops here.
2. Which lawful basis? One per use, decided up front.
3. Same purpose? Is the reuse compatible with why the data were collected?
4. Only what is needed? Does the analysis need to know who each person is?

Back to contents.

The EU AI Act: four tiers, providers and deployers

The AI Act regulates what an AI system is used for, with rules that tighten as the risk to people grows.

The AI Act is Regulation (EU) 2024/1689. As a regulation it applies directly in every Member State, without national transposition. It entered into force on 1 August 2024 and its obligations arrive in stages. Apart from its chapter on general-purpose AI models, it does not regulate a technology: it regulates uses, according to the risk they create for health, safety and fundamental rights. A single language model can therefore be minimal risk when it drafts marketing e-mails and high-risk when it ranks job applicants.

Whatever the tier, two things still apply: the AI literacy duty of Article 4, and the GDPR together with every other law. Obligations are also shared along the value chain. The provider develops a system and places it on the market, for instance the vendor of a CV-screening tool. The deployer uses a system under its own authority, for instance Olist screening its own applicants with that tool. A manager is most often on the deployer side; a company that builds its own system, even on someone else's model, can become its provider.

What a deployer of a high-risk system must do (in substance)

1. Follow the instructions. Use the system as its provider specifies.
2. Assign oversight. Give human oversight to people with the competence to exercise it.
3. Monitor and keep records. Watch how the system behaves and retain the logs under the deployer's control.
4. Inform. Tell workers and affected people where the Act requires it.

None of these duties requires understanding the model's internals; all of them require that someone stays in charge of how it is used.

Back to contents.

The 2026 amendment and the dates that matter

An amendment in force since July 2026 pushed back the high-risk deadlines, so the date that applies depends on the kind of use.

The amending text is Regulation (EU) 2026/1744, nicknamed the Digital Omnibus on AI. Its publication in the Official Journal came on 24 July 2026, and it took effect three days later, on 27 July 2026. Its most visible effect is on the calendar of high-risk obligations. The deck's timeline, checked in September 2026, reads as follows.

December 2027 is roughly when the students of this course will hold their first management roles, which is why the deck dwells on it. The amendment also reworded Article 4: the 2024 text asked providers and deployers to ensure a sufficient level of AI literacy among their staff, the amended text asks them to take measures that support it. The wording is softer, the direction unchanged, and the duty still covers every provider and deployer whatever the tier. The deck's two versions are paraphrases; quote Article 4 only from the consolidated text on EUR-Lex.

Back to contents.

Classifying an AI use in three questions

Ask whether the use is banned, then whether it is on the high-risk list, then whether it talks to people or generates content.

The method, asked in this order (the first yes gives the heaviest regime)

1. Is it a banned practice? If so, it is neither built nor used.
2. Is it on the high-risk list, or part of a regulated product? If so, duties fall on both provider and deployer.
3. Does it talk to people, or generate text, images, audio or video? If so, transparency duties apply, possibly on top of a higher tier.

Three noes leave a minimal-risk use, which still carries the AI literacy duty. And in every case, personal data bring the four GDPR questions back. The deck stresses that this is a simplified reading: good enough to know which questions to raise, not a legal opinion.

Worked example: the late-delivery model

The deck applies the method to the model built in Predictive analytics for decision-makers, which flags orders likely to arrive late for the operations team. It scores orders, not people, so it is not a banned practice. Delivery planning appears nowhere on the high-risk list, and no regulated product embeds the model. It neither chats with customers nor generates content; it flags orders for staff. The result is minimal risk, with Article 4 still applying to Olist. Two caveats complete the answer. The orders carry customer numbers, so the GDPR applies. And if the same scores were used to allocate work to couriers or to rate their performance, the use would fall under employment (Annex III, point 4) and become high-risk: the model is identical, the tier is not.

Groups then classify three uses Olist is considering (a churn score feeding marketing offers, a vendor's CV-screening tool, a customer-support chatbot) and, for each, state what the tier asks of Olist and one GDPR question it raises. Recruitment and credit scoring are the usual examples of allowed but high-risk uses; social scoring, the usual example of a ban.

Back to contents.

Accountability and sovereignty

Responsibility for a decision never passes to a machine, and choosing an AI tool also means choosing where data go and which law applies.

The second AI rule of the course, Own it, mirrors how responsibility works in a company: saying the AI produced a figure justifies nothing. Whoever signs a recommendation built with AI answers for the decision and its reasons, for the data given to the system, and for the checks run or skipped.

• Where are prompts and uploaded files processed and stored?
• Which law governs the company that provides the tool?
• What happens to your processes if its terms or prices change next year?
• What European or open-weight alternatives are there, and at what cost in money, effort and skills?

These questions frame a ten-minute discussion. European assistants exist (the deck names Le Chat from Mistral AI, explicitly not as a recommendation), as do open-weight models, which a company may host on machines under its own control. Every option settles part of the list; none settles all of it. The closing case asks what a company would require of a single assistant for all its staff, and what it would accept to give up; a good answer names the sacrifice and explains why it is acceptable for that use.

Back to contents.

Key takeaways

1. An answer from an AI assistant is a draft until a check you can name has confirmed it.
2. Brief the assistant with the structure of the data and a data dictionary, never with personal or confidential rows.
3. Replacing names with codes does not make data anonymous; while a key exists, the GDPR still applies.
4. Each processing of personal data rests on a single lawful basis picked in advance, and consent is just one option among six.
5. Under the AI Act, what a system is used for decides its tier, and high-risk duties for recruitment and credit scoring apply from 2 December 2027.
6. The AI literacy duty of Article 4 and the GDPR apply whatever the tier.
7. Whoever signs the recommendation, not the tool, is accountable for it.

Glossary

Data dictionary

List of the tables, their columns and what one row represents, given to an assistant instead of the data.

Hallucination

A false statement or reference produced with full confidence by a language model.

AI-use appendix

Short appendix to the brief listing each tool, the task it did and how the output was checked.

Personal data

Any information about a person who is identified or identifiable, directly, indirectly or by combination.

Lawful basis

One of the six grounds listed in GDPR Article 6 that make a use of personal data lawful.

Purpose limitation

GDPR principle: data collected for one purpose are not reused for an incompatible one.

Data minimisation

GDPR principle: process only the data the purpose requires.

Pseudonymisation

Replacing direct identifiers with codes; the data remain personal because the codes can be linked back.

Provider

Under the AI Act, whoever develops an AI system and places it on the market.

Deployer

Under the AI Act, whoever uses an AI system under its own authority, often the buying company.

High-risk system

AI use listed in the Act, such as recruitment or credit scoring, that carries strict obligations.

AI literacy

Article 4 duty on every provider and deployer to support their staff's understanding of AI.

Open-weight model

A model whose parameters are published, so a company can run it on infrastructure it controls.

The other notes of the course

One public summary per deck, in the order of the course.

Previous: Predictive analytics for decision-makersNext: Pitching data insights

1. Session 1From data to decisions
2. Session 2Data visualisation and storytelling
3. Session 3SQL essentials for managers
4. Session 4Predictive analytics for decision-makers
5. Session 5Generative AI, GDPR and the AI Act
6. Session 6Pitching data insights

All the notes, as a reading list

About these notes

Written by the lecturer from the slides of the deck, as a public summary: the key ideas, the formulas and one worked example. The exercises, their solutions, the tests and the grading stay in the deck, for the students of the course.

Revision: 16 October 2026.