Introducing GDPR-compliant AI in your company: step by step

1. Define purpose and legal basis

Before choosing a tool, write down what it is for: answering questions about internal policies, drafting texts, searching contracts, research. The purpose determines everything else — which data is processed, which legal basis applies and whether a data protection impact assessment becomes necessary.

If the system processes personal data, every processing operation needs a legal basis under Art. 6(1) GDPR, in companies usually legitimate interest (point f) or performance of a contract (point b). For employee data, Art. 88 GDPR and Section 26 of the German Federal Data Protection Act (BDSG) also apply; the scope of the latter has been disputed since the CJEU ruling of 30 March 2023 (C-34/21). Special categories such as health data (Art. 9 GDPR) need a basis of their own.

• Name concrete use cases, not “AI for everyone”
• Record data categories: internal documents without personal data, customer data, employee data, special categories
• Data minimisation (Art. 5(1)(c) GDPR): what is not needed does not go into the system
• Set retention periods for documents, chat histories and logs

2. Choose a provider

The choice of provider decides how much work lies ahead of you. Do not just ask for an “EU region” — ask who operates the service and who can technically access the data.

• Provider’s registered office: a company in the EU, ideally in Germany, with jurisdiction and contract under European law
• Server location: for application, database, document storage, backups and language models — each layer separately
• Third-country transfers (Art. 44 et seq. GDPR): if data goes to the US, for example, you need an adequacy decision such as the EU-U.S. Data Privacy Framework for certified recipients, or standard contractual clauses with a transfer impact assessment
• CLOUD Act: US providers can be compelled to hand over data even if it is stored in an EU data centre — a server location in Frankfurt does not change that
• Training on customer data: exclude it contractually, explicitly including inputs (prompts) and answers
• Subprocessors: a complete list with registered office, purpose and processing location, notice before changes
• Deletion and export: what happens to documents, vectors and backups on deletion and at contract end?

Vryne is built to these criteria: an operator based in Germany, application, data and language models in German data centres, no US cloud provider and no training on customer documents. Which layer runs where and which service providers are involved is publicly documented.

• → Digital sovereignty: where each layer of Vryne runs
• → Vryne’s subprocessors with registered office and processing location

3. Sign a data processing agreement under Art. 28 GDPR

If the provider processes personal data on your behalf, a data processing agreement (DPA) is mandatory. With AI tools that is practically always the case: user names and the content of prompts are already personal data.

Art. 28(3) GDPR sets out what the agreement must cover at a minimum:

• Subject matter, duration, nature and purpose of processing, types of data and data subjects
• Processing only on documented instructions, confidentiality of the persons involved
• Technical and organisational measures under Art. 32 GDPR, usually as an annex
• Conditions for subprocessors — check whether the model providers are listed
• Support with data subject rights and data breaches, deletion or return at contract end
• Evidence and audit rights for you as the controller

Vryne’s DPA with TOM annex and list of subprocessors is publicly available as a PDF — you can review it before signing up.

• Vryne’s DPA under Art. 28 GDPR with TOM annex (in German)
  PDF
• → Trust & security: TOMs, hosting and documents for your review

4. Update your record of processing activities (Art. 30 GDPR)

The use of AI gets its own entry in the record of processing activities. The exemption for companies with fewer than 250 employees rarely applies in practice, because a permanently used application is not occasional processing.

• Name and purpose of the processing
• Categories of data subjects and personal data
• Recipients, including provider and subprocessors
• Transfers to third countries and their safeguards — or a note that none take place
• Retention periods and a reference to the technical and organisational measures

5. Check whether a data protection impact assessment is required (Art. 35 GDPR)

A data protection impact assessment (DPIA) is mandatory if processing is likely to result in a high risk to the rights and freedoms of individuals — especially when using new technologies. The German supervisory authorities also publish a list of processing operations that always require a DPIA.

Indicators that a DPIA is required:

• large-scale processing of special categories, such as health data
• systematic evaluation of people, such as applications or performance
• monitoring or analysing the behaviour of employees
• decisions with legal or similarly significant effects for data subjects

An assistant that answers questions about internal policies and manuals without personal data usually does not need a DPIA. Still, document the check as a threshold assessment and involve your data protection officer (Art. 35(2) GDPR).

6. Define technical and organisational measures (Art. 32 GDPR)

Besides the provider’s measures, you need your own rules on who sees what in the system and how long data stays.

• Role and permission concept: who may see and search which document collections?
• Separate areas for confidential records such as personnel or client files
• Encryption in transit and at rest
• Usage logging — with a clear rule on who may view the logs and for what
• Deletion concept for documents, chat histories and backups
• Procedure for data breaches: notification to the supervisory authority within 72 hours (Art. 33 GDPR)

• → Trust & security: TOMs, hosting and documents for your review

7. Involve the works council (Section 87(1) No. 6 BetrVG)

Under the German Works Constitution Act, the works council has a right of co-determination over technical equipment that is suitable for monitoring employee behaviour or performance. According to the Federal Labour Court, objective suitability is enough — no intention to monitor is required. An AI system provided by the company with user accounts and logs therefore usually falls under this.

Involve the works council early: it must be informed during planning (Section 90 BetrVG) and may call in an expert when AI is introduced (Section 80(3) BetrVG). A works agreement covering purpose, approved tools, the exclusion of performance and behaviour monitoring, access to logs and training is common.

8. Train employees and document AI literacy

Since 2 February 2025, Art. 4 of the EU AI Act requires companies that use AI systems to ensure sufficient AI literacy among their staff. Training should at least explain how generative AI produces answers and why it makes mistakes, which data must not be entered, that every result is checked and when AI content is labelled. Record who attended what and when.

• → Guide: the AI literacy obligation under Art. 4 AI Act

9. Issue an AI policy

The policy sums up the everyday rules: which tools are approved, what must not go into them, who to contact and what happens in case of violations. Without it, employees fall back on private accounts — so-called shadow AI, where company data ends up with third parties uncontrolled.

• → Guide: AI policy for employees with template
• AI policy template
  PDF Markdown

10. Start a pilot, evaluate, roll out

Start with a small group and a clearly defined set of documents, such as the quality manual or the works agreements. After a few weeks, evaluate: are the answers correct, are the sources traceable, were there wrong inputs or data protection questions?

Then roll out in stages, update the record, TOMs and policy, and plan a regular review — at least once a year and with every new tool.

• Checklist for a GDPR-compliant AI rollout
  PDF Markdown