RAG knowledge assistant for GDPR

No, a DPIA is not automatically required for every internal document assistant, but many will need one once they index documents containing personal data at scale or touch special category data. Article 35(1) requires an assessment where processing is likely to result in a high risk to people's rights and freedoms, and Article 35(3) lists cases such as large-scale processing of special category data. Whether your assistant crosses that line depends on what is indexed, who queries it and how logs are kept. Document the screening decision either way, and confirm the threshold with your DPO and your national supervisory authority's published guidance.

The triggers that most often apply to document corpora are the following:

• Special category data under Article 9, such as health information, trade union membership, or religious beliefs appearing in HR files, case notes or support tickets.
• Large-scale processing of customer or citizen records, where the number of people and the range of data types are both substantial.
• Combinations of datasets that were collected for different purposes and are now joined in one index.
• Data about vulnerable individuals, such as employees in disciplinary procedures or children.

A policy handbook with no personal data carries far less risk than a folder of case files, so screen by content, not by file type.

Query logs can create systematic monitoring of staff, which regulators treat as a risk factor. If the assistant records who asked what, when, and which documents were returned, you are building a record of individual employee behavior, and that record needs a justification, a retention limit and access controls. Article 35(3)(c) addresses systematic monitoring of publicly accessible areas, and national lists often add employee monitoring, so check your authority's list. Log only what you need for security, audit and answer quality, and state the purpose in your records of processing.

Article 35(7) sets the minimum content. It must describe the processing and its purposes, assess necessity and proportionality, assess the risks to individuals, and list the measures planned to address them. For a RAG assistant, that means describing the source systems and document types, the embedding and retrieval flow, where vectors and logs are stored, which models process the text, who can query the assistant and how erasure requests reach source files, chunks and embeddings. Involve the DPO, and seek the views of data subjects or their representatives where appropriate under Article 35(9).

Article 36(1) requires prior consultation with the supervisory authority when a DPIA indicates that processing would result in a high risk that the controller cannot mitigate with reasonable measures. The consultation is a formal step, and the authority can respond with written advice or use its other powers. In practice, you should first try to reduce the residual risk through narrower indexing, stronger access controls and shorter log retention. Confirm the procedure, timelines and any national list of processing requiring a DPIA with your DPO and the authority's website before you rely on it.

The EU AI Act does not replace the GDPR assessment, but it adds obligations that overlap with it. Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your assistant is high-risk depends on its use case, so classify it first. Keep your DPIA and your AI Act documentation linked, since the same query logs may serve both purposes and both need retention decisions.

Your organization, and specifically the controller and DPO, owns the DPIA, and nothing in the GDPR requires an external firm to write one. The assessment depends on facts only your organization holds, such as which data sources are connected and who holds which roles. A technical partner can document the architecture, the data flows, access controls, log retention settings and erasure procedures so the assessment reflects the system as built. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. The GDPR requires no certificate, and the DPIA is an internal assessment, not a sign-off from a third party.

The cost depends on the scope written into the statement of work, not on a standard package. DeployOpen fixed-scope engagements are quoted from written inputs: the number and type of source systems, how many permission models must carry into answers, whether erasure tooling must be built or integrated, how much DPIA support is required, and where the stack will be hosted. Each of these is paid as effort for analysis, configuration, integration and testing, and some costs recur, such as hosting, model inference, upgrades and retained support. Ask any partner to split the quote into one-time build work and recurring operations, and to state which inputs the price assumes. DeployOpen does not publish a price list, so request a quote against your own inventory.

The timeline depends mostly on your readiness, not on the software. Platform setup is usually the shortest part. The longer items are the data inventory, agreeing a lawful basis and retention rule for each source, mapping permissions from your identity system, deciding what stays out of the index, and completing the DPIA where one is needed. If those decisions are open when work starts, the schedule moves. Ask the partner to show which milestones depend on your sign-offs and which depend on their team, and to tie the agreed schedule to written scope before work begins.

Most of the inputs that decide the design come from your side. Expect to provide a named data protection officer or privacy lead who can approve the lawful basis and retention decisions, an inventory of the document sources with their owners and the personal data they hold, and access to the identity system that governs who can read each source. You will also need a list of the users and groups, a decision on which collections are in scope, and the people who will review answer quality. A partner can help structure these inputs, but the legal decisions remain with your controller function.

An internal team can build it, provided it has skills in several areas at once: platform administration, retrieval engineering, identity integration, security hardening, and evaluation. The harder parts are usually not the installation. They are erasure across source files, chunks and embeddings, permission filtering at retrieval time, and documenting the decisions for an assessor. Assess your team against those specific tasks. If the gaps are in the middle of that list, a fixed-scope engagement can cover the parts you lack while your staff keep ownership of the platform afterwards.

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the controller's or processor's responsibility for compliance. What you need is evidence that you made and recorded the decisions: lawful basis, minimization, erasure handling, security of processing under Article 32, and a DPIA where one is required. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications.

Article 83 sets the maximum fines, which are EUR 10 million or 2% of total worldwide annual turnover for infringements such as those in Articles 25 to 39, and EUR 20 million or 4% for infringements of the principles, lawful basis, data subject rights and transfer rules, whichever is higher in each case. Fines are not set by the design alone, but the design determines whether you can demonstrate compliance. Practical examples include indexing personal data you had no basis to reuse, being unable to delete a record from embeddings after an erasure request, and letting a user retrieve a document their permissions should block. Design these controls before ingestion, not after an authority asks.

The license determines what you can run internally and what you can offer to others. Dify's license forbids operating a multi-tenant environment from the source without written authorization, and Open WebUI's license restricts altering its branding beyond listed limits, including a 50 end user threshold in any rolling 30 day period. For an internal assistant, confirm the terms that apply to your user count and deployment model before choosing the platform. A partner should state these limits in writing as part of the scope.