AI and GDPR — What SMBs Need to Know in 2026

If the question in 2024 was still whether SMBs should use AI at all, by 2026 the only question is how. Microsoft Copilot has been rolled out organisation-wide in many companies, ChatGPT accounts have become standard equipment for sales and marketing teams, and proprietary RAG systems built on Claude or Llama are running in production. It is precisely at this moment that many management teams realise that GDPR requirements do not wait — and that a missing legal basis, a missing data processing agreement (DPA), or an overlooked Data Protection Impact Assessment (DPIA) can be costly in an audit. This article explains what German SMBs concretely need to consider in 2026, identifies the five key GDPR pressure points for AI deployments, covers what belongs in a DPA with OpenAI or Anthropic, evaluates the Schrems II situation today, and provides a 10-point checklist to lock down a rollout properly. For the broader strategic picture, see our AI Guide for SMBs.

Why AI and GDPR Must Be Considered Together in 2026

The German Data Protection Conference published its "Guidance on AI and Data Protection" in 2024 and updated it twice in 2025. The core message: the GDPR applies in full to AI systems as well, supplemented since August 2024 by the EU AI Act — the two regulatory frameworks overlap but do not replace each other. Anyone who deploys an AI application in production without properly documented GDPR requirements risks fines of up to €20 million or 4% of annual turnover, personal liability for management, and reputational damage in supplier audits.

In day-to-day operations, data protection officers typically encounter three scenarios: uncontrolled use of personal ChatGPT accounts, semi-formal deployments with a business-tier subscription but no documented legal basis, and a properly planned rollout — which is exactly where we want to take you.

The Five GDPR Pressure Points in AI Deployments

Of the GDPR's 99-plus articles, five topics are truly decisive for AI deployments. Anyone who has properly documented these five points is well positioned when faced with supervisory authorities and auditors.

1. Legal basis under Art. 6 GDPR. In practice three bases are relevant: consent (lit. a — problematic in an employment context; a works agreement under § 26 BDSG is preferred), contract (lit. b — where the AI tool is causally necessary to deliver the service), and legitimate interest (lit. f — with a documented balancing of interests).

2. Purpose limitation under Art. 5(1)(b) GDPR. Data may only be processed for the original purpose for which it was collected. Feeding customer data from contract fulfilment directly into a fine-tuning pipeline constitutes a change of purpose — one that requires its own legal basis or a compatibility assessment under Art. 6(4).

3. Data minimisation under Art. 5(1)(c) GDPR. Do not put full documents into a prompt when an extract suffices; do not use real names when pseudonyms are sufficient; do not use real test data when synthetic data serves the purpose.

4. Transparency under Art. 13 and 14 GDPR. Data subjects must know that and how their data is being processed in an AI system — this requires an updated privacy notice, a record of processing activities under Art. 30, and employee information. Art. 22 prohibits automated individual decisions with legal effect except in three narrowly defined cases.

5. Data subject rights under Art. 15 to 22 GDPR. Access, rectification, erasure, and objection — these rights must remain exercisable even when AI systems are in use. Practical solutions are covered in the data subject rights section below.

Data Processing Agreements with AI Providers — What Belongs in the DPA

As soon as an external AI provider processes personal data on your behalf, a Data Processing Agreement (DPA) under Art. 28 GDPR is mandatory. This applies to ChatGPT Enterprise, Claude for Work, Microsoft Copilot, Google Gemini for Workspace, every specialised AI SaaS, and also to self-hosted open-source models as soon as an external cloud provider supplies the infrastructure. The following ten points should appear in every DPA:

• Specific description of the processing purposeWhat type of data is processed, for what purpose, and to what extent. "Provision of an AI service" is too vague — a concrete listing of data categories and processing activities is required.
• Data residency and storage locationGeographic specification of which data centres store and process the data. EU locations (Germany, Netherlands, Ireland) are the clean choice. The clause must be binding, not merely "as a rule".
• Sub-processing transparently listedAll sub-processors with name, registered office, and function. OpenAI uses Microsoft Azure as a sub-processor; Anthropic uses AWS — this must appear explicitly in the DPA, with a right to approve new sub-processors.
• Training opt-out expressly regulatedA clear assurance that your data will not be used to train or improve the models. This clause is standard in business tiers and absent in consumer tiers — and that is where the legal difference lies.
• Technical and organisational measuresA concrete list of TOMs under Art. 32 GDPR — encryption at rest and in transit, access controls, tenant isolation, penetration-test frequency, certifications (ISO 27001, SOC 2 Type II).
• Deletion and return obligations after contract terminationA binding deadline for deleting all customer data after contract end, with written confirmation. Typically 30 to 90 days. Logs and backups must be covered as well.
• Support for data subject requestsThe provider must assist with access, erasure, and other requests — with a clearly documented process and response time. Self-service tools in the admin portal are a clear advantage here.
• Audit and inspection rightsThe right to verify compliance with the DPA — either through proprietary audits or independent certifications such as ISO 27018 and C5 (BSI Cloud Computing Compliance Criteria Catalogue).
• Data breach notification obligationsA binding deadline for notifying you of data breaches — typically 24 or 48 hours, so you can meet your own 72-hour reporting deadline under Art. 33 GDPR.
• Liability and insurance coverageA clear liability provision with adequate caps and confirmation that the provider holds cyber insurance. Notably low liability caps are a negotiating point.

The major providers — Microsoft, Google, OpenAI, Anthropic, Amazon — now offer standard DPAs that largely cover these points. Read them in full before signing, or have them reviewed by your data protection adviser; standard DPAs are updated regularly and versions differ.

Training Data — What May Go In and What May Not

The riskiest area in AI deployments is using data for training and fine-tuning. Two GDPR principles collide directly here: purpose limitation and data minimisation. Personal data may only flow into a training pipeline if a separate legal basis exists and the original purpose of collection covers the training use — or a documented compatibility assessment under Art. 6(4) has been carried out.

In practice this means: customer data from the CRM, applicant data from recruiting, and employee data from personnel files may not simply be used for internal fine-tuning. Safe options are anonymised data, synthetic data, own business documents without personal reference, and data for which explicit consent or a works council agreement exists. A frequently overlooked point: even with OpenAI or Anthropic, a training opt-out is a standard contractual term for business tiers — in the free consumer version the opposite is the default, making it unsuitable for any business use involving personal data.

US Providers and the Schrems II Effect — EU Data Residency

The CJEU ruling Schrems II of July 2020 struck down the Privacy Shield and plunged data transfers to the US into a legal grey area for years. Since July 2023 the successor — the EU-US Data Privacy Framework — has applied on the basis of an adequacy decision. US companies certified under the Framework can again be treated as a safe third country. OpenAI, Anthropic, Google, Microsoft, and Amazon are all certified.

Nevertheless, EU data residency remains advisable for several reasons: political stability (a new legal challenge to the Framework is already underway), audit efficiency, smoother works council negotiations, and sector regulators such as BaFin that recommend EU processing.

In practice this means: for Microsoft Copilot, select EU data residency in your M365 tenant; for Google Workspace, choose the EU data region option; for OpenAI, use ChatGPT Enterprise with EU residency or the Azure OpenAI option (West Europe, Sweden Central); for Anthropic, the EU region in AWS Bedrock or the native EU data residency available since 2025. Comparative background on the deployment question can be found in our cluster on LLM On-Premise vs Cloud.

Making Sub-Processing Transparent

A point frequently underestimated in practice: AI providers rarely operate alone. OpenAI processes a large portion of its workloads on Microsoft Azure, Anthropic on AWS, and some specialised providers on Google Cloud Platform — this makes the cloud hyperscaler a sub-processor with its own processing access. Under Art. 28 GDPR this sub-processing must be transparently documented in the DPA.

AI Provider	Primary Sub-Processor	EU Data Residency Available	DPA Relevance
OpenAI (ChatGPT Enterprise / API)	Microsoft Azure	Yes (EU tenant, Azure regions)	Both DPAs required
Anthropic (Claude / API)	Amazon Web Services	Yes (EU region since 2025)	Both DPAs required
Microsoft Copilot (M365)	Own Azure infrastructure	Yes (EU data residency selectable)	Microsoft DPA covers this
Google Gemini for Workspace	Own GCP infrastructure	Yes (EU region selectable)	Google DPA covers this
Mistral AI (La Plateforme)	Azure / GCP / own	Yes (France primarily)	Mistral DPA covers this

The record of processing activities under Art. 30 GDPR and the privacy notice presented to data subjects must reflect this sub-processing chain — otherwise the transparency obligation under Art. 13 GDPR is violated. A frequent audit finding: the company lists OpenAI as a processor but forgets Microsoft Azure as a sub-processor, even though Azure actually provides the servers.

Data Subject Rights: Access, Erasure, and Objection for LLM Outputs

The biggest operational hurdle with AI systems is data subject rights. When a customer requests access under Art. 15 GDPR, you need to know what data about them exists in which AI system — and in which conversations they appear. Three mechanisms help:

Conversation logging with search functionality. Enterprise tiers (ChatGPT Enterprise, Claude for Work, Copilot, Gemini for Workspace) provide admin consoles with content search. For an access request, search by name, email address, or customer number and export the results.

Erasure workflow in the admin portal. For Art. 17 requests, delete all conversations relating to the data subject; logs and backups follow the DPA deletion deadlines.

Model weights and training data. Without proprietary training, the right of access and erasure is limited to conversation logs — the model weights themselves are not considered personal data under the prevailing interpretation. This is the most important practical simplification and a strong reason to avoid fine-tuning with personal data.

Art. 22 GDPR deserves special attention: for automated individual decisions with legal effect, a prohibition applies with three exceptions. AI-assisted pre-screening of applicants and credit assessment typically fall under this — the solution is a documented human decision-making step.

Data Protection Impact Assessment — When Is It Mandatory?

Art. 35 GDPR requires a Data Protection Impact Assessment (DPIA) where processing is likely to result in a high risk to the rights and freedoms of natural persons. German supervisory authorities have published negative lists — where three criteria apply, a DPIA is practically always mandatory. In AI deployments, the following constellations typically trigger the DPIA obligation:

• Applicant screening with AI pre-selection — automated assessment with potential legal effect
• Employee analytics (people analytics) — systematic monitoring with profiling characteristics
• Customer profiling and behavioural prediction — for example for churn forecasting or cross-sell scoring
• Credit and risk assessment with AI — classic profiling under Art. 22
• Biometric procedures — facial, voice, and behavioural recognition
• AI in sensitive domains — health, religious beliefs, sexual orientation, ethnic origin
• Large-scale monitoring of public spaces — camera analysis in access areas

A DPIA typically takes two to six weeks and consists of a systematic description of the processing, an assessment of necessity and proportionality, a risk assessment, and a description of the safeguards adopted. Where residual risks remain, the supervisory authority must be consulted under Art. 36 — this has significantly delayed several high-profile AI deployments in recent years. Incorporate the DPIA into your rollout planning early, not just before the go-live date.

Pre-Rollout Checklist — 10 Points

• 1. Use case and data types documentedWhich personal data is processed at which step, specifically? This answer comes first and determines all subsequent points.
• 2. Legal basis under Art. 6 GDPR identified and documentedConsent, contract, or legitimate interest — with a documented balancing test if lit. f is chosen. For employee data, a works council agreement under § 26 BDSG.
• 3. DPA under Art. 28 GDPR concludedWith the AI provider and all relevant sub-processors. Pay attention to EU data residency, training opt-out, and deletion obligations.
• 4. Record of processing activities updatedArt. 30 GDPR — the AI processing is recorded as a separate activity, with all data categories, recipients, and retention periods.
• 5. Privacy notice updatedInformation under Art. 13 and 14 GDPR — data subjects learn about the AI use, the providers involved, the transfers, and their rights.
• 6. Employees informed or works council agreement concludedFor AI applications affecting employees, co-determination under § 87 BetrVG applies. Involve the works council early, not only when the go-live is announced.
• 7. DPIA completed where mandatoryFor high risk under Art. 35 — with documentation, residual risk assessment, and supervisory consultation under Art. 36 where necessary.
• 8. Technical and organisational measures implementedArt. 32 GDPR — encryption, access control, deletion processes, logging, training opt-out activated, sensitive-data filter where available.
• 9. Processes for data subject rights establishedWho responds to an access request within 30 days? Which search tools are used? Who performs deletions in the admin consoles? These responsibilities belong in the data protection management system.
• 10. Training and usage policy communicatedEmployees know what they may and may not enter, which tiers are approved, and what escalation paths exist in case of doubt. A brief awareness training covers this. See also our GDPR IT Security Checklist.

Anyone who works through these ten points properly has solidly covered the GDPR component of an AI rollout. The remaining topics — EU AI Act, sector-specific supervision, cyber insurance — build on this foundation. For deeper coverage of the AI Act side, see our cluster on the EU AI Act for SMBs.

Frequently Asked Questions