A data protection impact assessment (DPIA) is mandatory when processing is likely to pose a high risk to people's rights and freedoms (Art. 35 GDPR). With AI on your own data, a RAG system, that's often the case, but not always. A DPIA for AI isn't a punishment; it's the structured way to find and reduce risks before you launch. This post helps you decide whether you need one and shows what goes in.
- A data protection impact assessment is mandatory when processing is likely to pose a high risk to people, and with AI on personnel, customer or health data that's often the case.
- As a rule of thumb, if two of the nine European criteria apply you usually need a DPIA, and generative AI usually meets one of them already.
- Self-hosting doesn't replace the DPIA, but it removes risks such as third-country transfers and makes the measures easier to prove.
When is a DPIA for AI mandatory?
Article 35(3) GDPR names three cases where a DPIA is always required: a systematic and extensive evaluation of personal aspects leading to decisions with legal effect, large-scale processing of special categories such as health data, and systematic large-scale monitoring of publicly accessible areas.
On top come the supervisory authorities' lists (Art. 35(4)). Germany's data protection conference (DSK) explicitly lists, as entry no. 11, the use of artificial intelligence where it processes personal data to steer interaction with data subjects or to evaluate personal aspects, for example in customer support.
For everything else, European data protection authorities set out nine criteria (guidelines WP 248). If two apply, a DPIA is usually needed. That threshold is reached quickly: generative AI usually counts as new technology, so one more criterion is enough.
In shortMandatory when a high risk is likely. AI is on the German regulators' list, and from two of nine criteria a DPIA is usually required.
The self-test: nine criteria for your AI project
Tick what applies to your project. The result doesn't replace your data protection officer's review, but it shows where you stand.
No sign of high risk. Still document why you're not doing a DPIA.
A typical example: a knowledge assistant that searches HR handbooks and works agreements processes employee data (vulnerable data subjects) with generative AI (new technology). That's two criteria. An assistant over public product documentation only often meets just one.
In shortCount the criteria that apply. From two, plan the DPIA before launch.
What do German regulators say about RAG?
In October 2025 the DSK published its own guidance on generative AI systems using the RAG method. The key points for your DPIA:
- Data protection by design. RAG can enable smaller, locally operated models and avoid transfers to third parties.
- Not a free pass. RAG doesn't remove the problems of a language model that was trained unlawfully.
- Purpose limitation through roles. Staff should only be able to query what fits their purpose. That needs a role and permissions concept.
- Deletion is possible. Entries in reference documents and the vector database can be deleted selectively.
- Accuracy. RAG can improve accuracy, but false statements about people can't be fully ruled out.
The DSK stresses that the assessment must be made case by case, and that the use must be designed to comply with data protection from the start.
In shortRAG can enable data protection by design, but it needs roles, a deletion concept and a case-by-case assessment.
What goes into a data protection impact assessment for AI?
Article 35(7) GDPR sets four parts: a description of the processing and its purposes, an assessment of necessity and proportionality, the risks to data subjects, and the measures against them. With RAG, it's best to go through the system's building blocks one by one:
Risks and measures per building block
What gets ingested.
Risk: more personal data ends up in the index than needed, such as whole drives. Measure: choose sources deliberately, exclude folders with personnel files, separate by project.
Where passages are stored.
Risk: deleted documents survive as passages. Measure: deleting at the source triggers deletion in the index; set and prove retention periods.
What staff type in.
Risk: histories show who asked what. Measure: switch storage off or set periods, restrict access to histories, involve the works council.
Who generates the answer.
Risk: transfer to a model provider, possibly outside the EU. Measure: a local model for confidential data, otherwise a provider with a DPA and a checked region.
What the system records.
Risk: logs are suitable for monitoring behaviour. Measure: fix the purpose (security, investigation), regulate access, limit retention.
Before you start: seek your data protection officer's advice if you've appointed one (Art. 35(2)). If a high risk remains after all measures, you must consult the supervisory authority (Art. 36).
In shortFour required parts under Art. 35(7), best worked through block by block: knowledge base, vector database, chats, model, logs.
How the deployment model shortens the DPIA
Self-hosting doesn't replace the DPIA. But it changes several lines in the risk register in your favour, and some disappear entirely.
AI service from an external provider
- transfer to the provider, possibly to a third country
- a new processor you have to assess
- deletion and logs with the provider
- evidence comes from the provider
Self-hosted with RAGSuite
- no transfer for the platform
- no new processor for the platform
- retention periods and audit log on your servers
- with a local model no request leaves your network
With RAGSuite you separate projects, define roles, set retention periods with receipts and switch off chat and search storage where you don't need it. Every answer names its source, which makes accuracy checkable.
And RAGSuite Engine? There, RAGSuite is your processor, with a data processing agreement and a data centre in Germany. So the line "new processor" stays, and you assess it like any other: location, sub-processors, deletion and evidence. Which language models run there is listed with the sub-processors. For personnel files or health data, running it on your own servers is often the shorter route to approval.
In shortYour own servers remove transfers and a new processor from the risk register; in RAGSuite Engine you assess RAGSuite as your processor.
And if no DPIA is needed?
Then record why. "We assessed it and decided no DPIA is needed, for these reasons" is part of accountability (Art. 5(2) GDPR). Review the decision when something changes: new sources, a different model, more users (Art. 35(11)).
Read more about data protection duties on our page AI data protection. How RAGSuite handles roles, retention periods and logs is shown on Administration & security and in the Trust Center. How to involve the works council is covered in AI and the works council.
This is general information, not legal advice. Decide with your data protection officer whether your project needs a DPIA.
In shortEven without a DPIA, document the reasons and review again when sources, model or user numbers change.
Turn what you've read into your DPIA, with the free DPIA template or in a call with Stefan.
Frequently asked questions
Is a DPIA mandatory for every use of AI?
No. It's mandatory when processing is likely to pose a high risk to people. AI over public content without personal data often doesn't. With personnel, customer or health data it usually does, because generative AI counts as new technology and one further criterion is then enough.
Who is responsible for the DPIA?
The controller, meaning your company, not the software vendor. If you've appointed a data protection officer, seek their advice (Art. 35(2) GDPR). The vendor provides information about its system, such as data flows, deletion and logs, which you need for the assessment and its documentation.
Does the DPIA have to be finished before launch?
Yes. The DPIA takes place before processing starts, so before real personal data is ingested. A pilot with test data is possible beforehand. If something material changes later, such as new sources or a different model, review the DPIA again (Art. 35(11) GDPR).
Does the DPIA replace an assessment under the EU AI Act?
No, the two sit side by side. Deployers of high-risk AI use the provider's information for their DPIA (Art. 26(9)), and some must also carry out a fundamental rights impact assessment (Art. 27). An internal knowledge assistant is usually not high-risk. This is general information, not legal advice.
Do I need a DPIA for RAGSuite Engine?
That doesn't depend on the provider but on your data and purposes. If your AI processes personal data with a likely high risk, you need a DPIA, whether in RAGSuite Engine or on your own servers. In RAGSuite Engine, include the data processing agreement and the sub-processors in the assessment.
Sources
- DSGVO Art. 35 und 36 (EUR-Lex): DPIA and prior consultation
- Leitlinien zur DSFA, WP 248 rev. 01 (Art.-29-Gruppe, vom EDSA bestätigt): the nine criteria
- DSK: Liste der Verarbeitungstätigkeiten, für die eine DSFA durchzuführen ist: entry on AI
- DSK: Orientierungshilfe zu generativen KI-Systemen mit RAG-Methode (Okt. 2025): German regulators' view
- EU AI Act, Reg. (EU) 2024/1689 as amended by Reg. (EU) 2026/1744: Art. 26 Abs. 9, Art. 27
Stefan works with customers in public administration and regulated industries. He writes about the GDPR, the EU AI Act, works councils and tenders.