# GDPR and AI Presentations: A Practical Compliance Checklist
> A working GDPR checklist for AI presentations from a certified DPO: lawful basis, minimization, vendors, transfers, retention, security, and human release.
- Author: [Maximilian Betz](https://www.offgen.ai/en/authors/maximilian-betz)
- Published: 2026-08-25
- Updated: 2026-08-25
- Category: Security & EU Regulation
- Labels: Security & EU Regulation, Regulated Industries
- Canonical URL: https://www.offgen.ai/en/blog/gdpr-ai-presentations-checklist
> This article is for information only and does not constitute legal advice.
## Evidence for this article

This article supports its claims with 6 sources. Key sources include:

1. [Regulation (EU) 2016/679 (General Data Protection Regulation)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=en) (EUR-Lex)
2. [Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en) (European Data Protection Board)
3. [Orientierungshilfe KI und Datenschutz](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf) (Datenschutzkonferenz)

[Full source list](#sources)
I get asked the same question in almost every enterprise deal: "Is your tool GDPR compliant?"

I understand why people ask it. I also have to say, as someone who has sat on the data protection officer side of the table: it is not a question anyone can honestly answer with yes. The GDPR does not certify software. It governs what you do with personal data. Two companies can run the identical tool, and one of them is fine while the other has a problem, because they feed it different data for different purposes under different contracts.

So this is the checklist I actually use. Not the legal textbook version. The one that helps a team get to a defensible decision without stalling the project for three months.

<Callout title="Scope and legal review">
  This is operational guidance, not legal advice. Roles and lawful bases depend on your specific workflow, contracts, data, and jurisdiction. Have your privacy and legal teams approve the use case before you process personal data.
</Callout>

## Assess the processing, not the software [#assess-the-processing-not-the-software]

There is no special GDPR category called "AI presentation." The regulation applies the moment a presentation workflow touches personal data. Someone pasting interview notes into a prompt, a system retrieving a consultant CV, a model summarizing customer records, a slide about named employees.

And presentations hold more personal data than people assume. Obvious things: names, photos, contact details, performance ratings, salaries, customer transactions, health information, biographies. Less obvious things: a person identifiable from a unique role, a deal history, an office, a chronology, or just an unusual combination of facts on one chart.

Map the whole chain before you judge the tool:

1. Who provides the source files and prompts?
2. Which systems extract, store, retrieve, or generate content?
3. Which providers and subprocessors receive data?
4. Where is the data processed, and where is it supported from?
5. What ends up in logs, telemetry, backups, or human review queues?
6. Who can see the sources, the draft, and the final deck?
7. How long does each copy stick around?

The finished PowerPoint file is one processing location out of many. An assessment that stops there, and plenty do, has skipped the prompts, the retrieval index, the logs, and the backups.

## The checklist [#the-checklist]

### 1. Write down the purpose, scope, and owner [#1-write-down-the-purpose-scope-and-owner]

One short use case record before rollout. "Use AI for PowerPoint" is not assessable. "Draft quarterly account review slides from the approved CRM export, for relationship managers in Germany" is.

Document the business purpose and expected benefit, the categories of people and personal data, the source systems and recipients, the business owner and system owner and privacy contact, the inputs and outputs that are off limits, and whether anyone makes decisions about individuals based on the output.

When the purpose changes, reassess. Approval for proposal drafting does not silently extend to employee evaluation or customer profiling. That is the failure mode I see most often: a use case approved once and then quietly stretched.

### 2. Get roles and lawful basis right [#2-get-roles-and-lawful-basis-right]

Work out who is controller, joint controller, or processor for each part of the workflow. Where a vendor acts as processor, Article 28 requires appropriate contractual terms. Where a provider uses your input for its own purposes, the role analysis looks different and deserves a careful read.

Then identify and document a lawful basis for each purpose. Contract performance, legal obligation, legitimate interests, consent. You do not get to pick whichever is most convenient. Special category data under Article 9 needs an additional condition on top.

### 3. Minimize before the prompt, not inside it [#3-minimize-before-the-prompt-not-inside-it]

The safest personal data is the data your AI workflow never receives. Minimize at source. Do not rely on instructing a model to ignore what you should not have sent.

What works in practice:

* select only the rows, columns, pages, or sections you need;
* replace direct identifiers with controlled references where you can;
* aggregate small groups and suppress sensitive outliers;
* strip comments, speaker notes, hidden slides, and document metadata;
* keep confidential deal data separate from reusable public content;
* connect approved excerpts instead of whole mailboxes or shared drives.

And a reminder that saves a lot of arguments: removing a name is not anonymization. If a colleague can work out who it is from what remains, it is still personal data and the GDPR still applies.

### 4. Assess the provider properly [#4-assess-the-provider-properly]

Vendor review has to go past the badge on the website. Ask for specifics:

| Area                    | Evidence to request                                                              |
| ----------------------- | -------------------------------------------------------------------------------- |
| Processing instructions | DPA, service description, purpose limitations                                    |
| Model improvement       | The contractual setting for whether your inputs or outputs are used for training |
| Subprocessors           | Current list, locations, purpose, change notification process                    |
| Transfers               | Processing locations, transfer mechanism, supplementary measures                 |
| Retention               | Configurable periods for prompts, files, logs, backups, support copies           |
| Access                  | Tenant isolation, roles, least privilege, SSO, administrator controls            |
| Security                | Relevant controls, testing, incident process, supporting evidence                |
| Assistance              | Support for rights requests, deletion, DPIAs, audits, breaches                   |

A DPA is necessary wherever Article 28 applies. It is not sufficient on its own. I have reviewed setups with an immaculate contract and a configuration that contradicted it on three points. Check that the settings and the actual data flows match what you signed.

### 5. Follow the data across borders [#5-follow-the-data-across-borders]

Identify every location from which personal data can be processed, including remote support and subprocessors. Where data leaves the EEA, document the mechanism and the assessment behind it. Do not infer data residency from a vendor's headquarters or a reassuring line on a pricing page. Ask where support engineers sit.

### 6. Set access and workspace boundaries [#6-set-access-and-workspace-boundaries]

Enterprise identities, role based permissions, controlled workspaces, least privilege. Separate teams, clients, mandates, or confidentiality tiers wherever their members should not be able to retrieve each other's content.

Review access at onboarding, role changes, project closure, and offboarding. Pay particular attention to administrators, service accounts, shared links, exports and support access. Those are the four places where carefully designed boundaries usually leak.

### 7. Control sources and generated claims [#7-control-sources-and-generated-claims]

Retrieval should favor approved, attributable sources, and every material claim needs enough provenance for a reviewer to find the underlying record and its effective date.

A plausible generated sentence must not become a new fact. This matters most for CVs, employee information, transaction histories, medical claims, customer metrics, and management commentary. Incorrect personal data is not only an accuracy problem under the regulation. It can do real damage to someone's career.

### 8. Build a release gate that means something [#8-build-a-release-gate-that-means-something]

Assign reviewers by risk, not by who is available.

| Content                                           | Required review                                   |
| ------------------------------------------------- | ------------------------------------------------- |
| Names, roles, contact details                     | Source or record owner                            |
| Financial or performance information about people | Business owner, plus privacy or legal as required |
| Special category or highly confidential data      | Explicit specialist approval                      |
| External claims and citations                     | Subject matter owner                              |
| Client facing final deck                          | Accountable presenter or engagement lead          |

Whoever reviews has to see the sources, the unresolved gaps, and what changed. A reviewer looking at polished slides with no provenance is approving the design, not the content.

### 9. Configure retention and actually test deletion [#9-configure-retention-and-actually-test-deletion]

Set separate retention periods for source uploads, prompt history, generated drafts, final decks, audit logs, and backups. Align them with purpose, legal obligations, records schedules, and client commitments.

Then test it. "Deleted after 30 days" is a weak commitment if nobody can tell you which copies, indexes, and backups that covers. Ask the vendor to walk you through a deletion, once, before you sign.

### 10. Support transparency and individual rights [#10-support-transparency-and-individual-rights]

Update privacy information, records of processing activities, internal notices, and request procedures where required. Work out in advance how your team would locate, correct, export, restrict, or delete relevant data across prompts, stores, logs, and presentations. Discovering that mid request is unpleasant.

If a generated presentation feeds into a decision with significant effects on a person, bring privacy and legal in early. A human clicking "approve" does not automatically resolve questions about automated decision making.

### 11. Screen for a DPIA [#11-screen-for-a-dpia]

Document whether the use is likely to create high risk. Look at the nature and sensitivity of the data, the scale, systematic monitoring, evaluation or scoring, vulnerable people, matching of datasets, novel technology, and what happens if it goes wrong or leaks.

If the screening points to likely high risk, complete the DPIA before processing starts. Record mitigations and residual risk. A DPIA written after launch to fill a gap in the file is paperwork, not an assessment.

### 12. Prepare for the bad day [#12-prepare-for-the-bad-day]

Connect the tool to your existing incident process. Employees need to know how to report a wrong upload, a cross client exposure, suspicious access, an unsafe generated disclosure, or a lost export, and they need to know it will not go badly for them when they do.

The response team needs vendor contacts, the relevant logs, containment options, and a route to assess notification duties without losing hours to escalation.

## The one page approval record [#the-one-page-approval-record]

For each approved presentation workflow, keep a single record with:

<Checklist>
  * Named business owner and approved purpose.
  * Data categories, people, sources, recipients, and prohibited content.
  * Controller/processor analysis and lawful basis.
  * DPA, subprocessors, processing locations, and transfer assessment.
  * Security, access, retention, deletion, and incident controls.
  * DPIA screening outcome and specialist approvals.
  * Required human review and final release owner.
  * Approval date, review date, and what triggers a reassessment.
</Checklist>

If you cannot fill this in for a tool your teams already use, that is the finding.

## What good looks like [#what-good-looks-like]

A mature workflow does not rely on every employee remembering data protection law at 6pm the day before a board meeting. It makes the safe path the easy path:

* approved sources are connected, instead of copied into whatever tool is open;
* access follows the user and the client context;
* prohibited data is blocked or clearly signposted;
* source references stay visible during review;
* retention and training settings are controlled centrally, not per user;
* the native PowerPoint output can be inspected and corrected;
* an accountable human releases the final deck.

That is the design principle we build to at offgen, and it is what I look for when I assess anyone else's tool: privacy encoded in the workflow, judgment and accountability left with people. If a vendor's answer to a privacy question is "the user is responsible for what they upload," they have handed you the problem and called it a feature.

Our own documentation for this review sits in the [data processing agreement](/en/data-processing-agreement) and the [trust center](/en/security/trust-center). Read them the way I would read a competitor's, looking for the parts that are specific.
## Frequently asked questions

### Does the GDPR prohibit using AI to create presentations?

No. The GDPR is technology neutral. It governs the processing of personal data, so the questions that matter are purpose, lawful basis, minimization, transparency, processor arrangements, transfers, security, retention, and individual rights.

### Can employees paste personal data into a public AI presentation tool?

Only if your organization has explicitly approved that tool for that use case, after looking at the data, purpose, legal basis, contract terms, retention, model training settings, transfers, access controls, and security. A consumer account someone signed up for last Tuesday is not approved by default.

### Is a data processing agreement always required?

A DPA under Article 28 is required where the provider processes personal data on your behalf as a processor. You have to assess the actual roles. What the contract calls itself does not settle the question.

### Do we need a data protection impact assessment for AI presentation software?

A DPIA is required where the processing is likely to result in a high risk to individuals. Run a documented screening first, and involve the DPO or legal counsel where the data, scale, monitoring, profiling, vulnerable people, or novel technology could push it into high risk.

### Does removing names make presentation data anonymous?

Usually not. People stay identifiable through combinations of role, employer, deal, location, dates, financial values, or free text context. Pseudonymized data is still personal data whenever reidentification is reasonably possible.

### Who remains responsible for an AI generated presentation?

Your organization and the accountable employees. Purpose, data use, accuracy, confidentiality, review, and release stay with you. No vendor and no model takes over the controller's obligations or the presenter's professional responsibility.
## Sources

1. [Regulation (EU) 2016/679 (General Data Protection Regulation)](https://eur-lex.europa.eu/eli/reg/2016/679/oj?locale=en) — EUR-Lex, 2016-04-27; accessed 2026-08-25.
2. [Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models](https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en) — European Data Protection Board, 2024-12-17; accessed 2026-08-25.
3. [Orientierungshilfe KI und Datenschutz](https://www.datenschutzkonferenz-online.de/media/oh/20240506_DSK_Orientierungshilfe_KI_und_Datenschutz.pdf) — Datenschutzkonferenz, 2024-05-06; accessed 2026-08-25.
4. [Regulation (EU) 2024/1689 (Artificial Intelligence Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj?locale=en) — EUR-Lex, 2024-07-12; accessed 2026-08-25.
5. [Data Processing Agreement](https://www.offgen.ai/en/data-processing-agreement) — offgen; accessed 2026-08-25.
6. [Trust Center](https://www.offgen.ai/en/security/trust-center) — offgen; accessed 2026-08-25.
## Related articles

- [PowerPoint Automation for Regulated Industries: The Complete Guide](https://www.offgen.ai/en/blog/powerpoint-automation-regulated-industries)
- [How to Automate Consulting Proposals with AI Without Losing Quality](https://www.offgen.ai/en/blog/automate-consulting-proposals-ai)
- [EU AI Act AI Literacy: A Practical Training Plan for Professional Teams](https://www.offgen.ai/en/blog/eu-ai-act-ai-literacy-training-plan)
- [EU AI Act for Deployers: What Applies in 2026 and What Comes Later](https://www.offgen.ai/en/blog/eu-ai-act-deployer-checklist)