Dictionary

GDPR (General Data Protection Regulation)

GDPR is the European regulation that governs how organisations process personal data. It does not ban data use, but it requires a clear purpose, a lawful basis, data minimisation, security, retention discipline, and respect for people's rights.

What is GDPR?

GDPR stands for General Data Protection Regulation. In Dutch it is called the AVG. It is Regulation (EU) 2016/679, and it has applied across the European Union since 25 May 2018.

GDPR sets the rules for processing personal data. It protects people in the EU and can also apply to organisations outside the EU when they offer goods or services to people in the EU or monitor their behaviour.

The common misunderstanding is that GDPR forbids using customer data. It does not. It says you need a clear purpose, a lawful basis, proportionate data use, appropriate security, and a way to respect people's rights. Reporting, analytics, automation, and AI can all be possible, but they need to be designed deliberately.

For data teams, this is daily work. A sales dashboard with customer names, a CRM export into a warehouse, a support-chat dataset, website logs with IP addresses, or a model trained on customer emails can all involve personal data.

Key concepts for data work

Personal data
GDPR defines personal data broadly. It includes information relating to an identified or identifiable person. Names count, but so can customer IDs, device IDs, IP addresses, location data, badge numbers, and combinations of attributes that point back to a person.

Controller and processor
The controller decides why and how personal data is processed. The processor processes it on the controller's behalf. If your company stores customer data in a cloud warehouse, your company is usually the controller and the cloud provider is usually a processor. The data moved, but the responsibility did not disappear.

Lawful basis
Every processing activity needs one of the Article 6 lawful bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Internal reporting often relies on contract or legitimate interests, but legitimate interests still needs a balancing test. It is not a blank cheque.

Purpose limitation
You collect data for a purpose and should not quietly reuse it for an incompatible purpose. A support transcript collected to resolve a ticket is not automatically training data for an AI model.

Data minimisation and storage limitation
Use what is necessary and keep identifiable data no longer than needed. That can clash with the instinct of a warehouse, which wants to keep history forever. The practical answer is often to preserve transaction history while removing or breaking links to identifiable people when they are no longer needed.

What GDPR means for reporting and warehouses

A data warehouse attracts personal data. CRM brings contacts, ecommerce brings delivery addresses, support systems bring messages, and web analytics brings identifiers.

Access must match need
Not everyone needs row-level detail. Account managers may need their own customers. Finance may need invoices. Leadership may need aggregated trends. Use workspace permissions, model security, row level security, object level security, masking, and export controls where appropriate.

Deletion and correction requests travel downstream
A request to erase or correct data does not stop at the CRM. Copies in warehouses, exports, dashboards, test data, and shared folders matter too. Without data lineage, these requests become detective work.

Processors need contracts
Article 28 requires a processor arrangement when a supplier processes personal data on your behalf. That includes many cloud, analytics, BI, automation, and AI tools.

International transfers need a transfer mechanism
Sending personal data outside the European Economic Area must meet Chapter V conditions, such as an adequacy decision or standard contractual clauses plus the required assessment. Check where the data is stored and where support or sub-processors can access it.

GDPR and AI

AI projects are still data processing. If you train, fine-tune, evaluate, or prompt a system with personal data, GDPR applies.

The European Data Protection Board's Opinion 28/2024 on AI models makes the central point: whether an AI model can be considered anonymous must be assessed case by case. A model trained on personal data is not automatically anonymous just because the original records are no longer visible.

Practical questions:

  • What personal data goes into prompts, logs, training sets, or evaluation sets?

  • Which lawful basis covers that use?

  • Did people receive clear information about it?

  • Does the supplier reuse inputs or outputs for its own model training?

  • Can sensitive data be removed, pseudonymised, aggregated, or replaced with safer test data?

Article 22 also matters for fully automated decisions that have legal or similarly significant effects on a person. Credit refusal, hiring, insurance, access to services, and similar decisions need special care and often human intervention.

GDPR and the AI Act are separate. GDPR governs personal data. The AI Act governs AI systems and their risk obligations. In many projects, both apply.

Supervision and fines

Each EU Member State has a data protection authority. In Belgium, that is the Belgian Data Protection Authority, the GBA/APD. It handles complaints, investigates, gives guidance, and can impose sanctions.

GDPR fine ceilings are high. For the most serious infringements, the maximum is 20 million euro or 4 percent of worldwide annual turnover, whichever is higher. For other infringements, the maximum is 10 million euro or 2 percent. In practice, a case often begins with a complaint, questions, or an investigation. The organisation that can show its purposes, legal bases, data flows, retention choices, and security measures is in a much better position than the one that cannot.

What to watch out for in a data stack

Aggregates can hide personal data underneath
A dashboard may show only totals, but the underlying model may let people export customer-level rows. Secure the model, not just the visual.

Pseudonymised is still usually personal data
If a code can be linked back to a person with additional information, GDPR still applies. Pseudonymisation reduces risk; it does not usually remove the data from scope.

Shadow copies count
Test databases, CSV exports, inbox attachments, and notebook extracts are all processing if they contain personal data. The fewer copies, the easier governance becomes.

Retention needs design
If you need long-term trends, consider anonymised, aggregated, or disconnected history instead of keeping identifiable records indefinitely.

This is not legal advice
GDPR decisions depend on context. For high-risk, sensitive, or novel processing, involve legal, privacy, and security specialists early.

Last Updated: July 7, 2026 Back to Dictionary
Keywords
gdpr general data protection regulation avg privacy personal data lawful basis data governance data warehouse ai act row level security data lineage anonymisation pseudonymisation