All posts
GDPRSovereign AISME

GDPR-compliant AI for companies: what really matters

13 min readThomas Stermole
Concept graphic: a densely meshed data cluster inside the EU on the left, a third-country zone with a few distant systems on the right; at the border between them, a glowing shield icon representing lawful transfer safeguards such as the DPF and Standard Contractual Clauses.

AI has arrived in the mid-market — unfortunately often through the back door. Employees use ChatGPT because it makes their work faster, copying quotes, customer data and contracts into a tool whose data flows nobody in the company oversees. The legitimate question that follows is rarely "Is AI allowed?", but rather: How do we use AI without losing control over our data?

There is a lot of half-knowledge circulating around this topic — from "AI in companies is forbidden" to "with a German provider you are automatically safe." Both are wrong. This guide clears that up and shows what actually matters for GDPR-compliant AI. Without scaremongering, without wagging a finger. Whether the EU AI Act bans ChatGPT & Copilot from August 2026 is covered separately in the article ChatGPT & Copilot at work.

Short answer: An AI solution is not GDPR-compliant solely because it is hosted in the EU or supplied by a particular provider. What matters is the specific purpose, the data being processed, the legal basis, a possible data processing agreement, data location and international transfers, retention periods, access rights and the technical configuration. For sensitive company data, EU-hosted or fully self-operated systems are usually easier to control than public consumer AI.

Last substantively updated: 17 August 2026

What "GDPR-compliant AI" really means — and what it doesn't

First, the most important clarification: "GDPR-compliant AI" is not a product you buy, and not a seal a provider sticks on its website. It is a property of your usage — that is, of which data you process, how, where, and on what legal basis.

From this follow two widespread misconceptions that can become expensive:

Misconception 1: "An EU provider is automatically compliant." The provider's location is just one factor among several. Depending on the use case, a European tool also needs a legal basis, a data processing agreement (DPA) and traceable documentation. Geography alone does not protect you.

Misconception 2: "Local AI is automatically GDPR-compliant." Self-hosting can avoid international transfers when no external components transmit data. But it does not make you automatically compliant. Even if a model runs on your own server, you still need a legal basis, purpose limitation and appropriate transparency. Sovereignty is half the battle, not the whole of it.

GDPR compliance therefore does not arise from one checkbox, but from the interplay of several levers. Let's look at the most important one first.

The real crux: where do your data flow?

As soon as personal data are transferred to or processed by a US recipient, the rules for international transfers apply as well. This is exactly where the legal uncertainty sits — and where the market sells the most fear. So here is the sober state of play as of 17 August 2026:

Transfers to the USA are not categorically illegal. Since 2023, the EU-US Data Privacy Framework (DPF) has provided an adequacy decision by the European Commission, enabling transfers to participating certified US companies. In September 2025, the General Court of the European Union dismissed the action in case T-553/23.

The honest assessment, however, is this: the DPF is currently valid, but its further development needs to be monitored. Appeal C-703/25 P is pending. The adequacy decision also rests on US legal safeguards whose continued operation the European Commission must monitor; its predecessors, Safe Harbor and Privacy Shield, were invalidated by the Court of Justice. Companies should therefore avoid basing their entire AI strategy on a single transfer mechanism without an alternative.

Also important: even if the DPF applies, it only legitimises the transfer. You still need a DPA and a legal basis for the actual processing purpose.

In practice, the commitments of each business product must be assessed separately. OpenAI's current Data Processing Addendum provides for an adequacy decision or Standard Contractual Clauses, depending on the transfer from the EEA. OpenAI does not use inputs and outputs from ChatGPT Business and Enterprise for training by default. European data and inference residency, however, is available only to eligible Enterprise and Edu customers and, according to the provider, does not cover every type of CPU processing, metadata or external integration. A Business plan alone is therefore not a sufficient privacy assessment.

The three levers for GDPR-compliant AI

From practice, three levers can be distilled on which compliance is decided. Anyone who answers these three cleanly has the essentials under control.

1. The data location. Where do storage and the actual AI inference take place? In a US cloud, in an EU data centre, or on your own infrastructure? Fully self-operated processing can avoid an international transfer, provided that external APIs, telemetry, support access and connected services do not introduce corresponding transfers.

2. Model and provider. Do you use a closed API or an open-source model that you can operate yourself? Does the provider use inputs or outputs for training? Is there a robust DPA? With self-operated open-source models, you can control technically and organisationally whether and where inputs, documents and log data are transferred.

3. Purpose, legal basis and transparency. For which purpose do you process which data, and on what legal basis? Are employees and other data subjects sufficiently informed? Where GDPR Article 30 applies, processing activities must be documented in the relevant record. A supplementary AI inventory is also a useful governance measure and helps keep GDPR and EU AI Act assessments distinct.

Three ways to use AI in a GDPR-compliant manner

There is no single right way, but a spectrum — with honest pros and cons.

US business cloud

  • Effort: generally higher, particularly for international transfers and provider assessment
  • Data control: medium, depending on contract and configuration
  • Speed: usually very quick to introduce
  • Typical fit: ordinary office processes without particularly sensitive data

EU-hosted AI

  • Effort: often medium, provided inference and subprocessors remain in the EU as well
  • Data control: tends to be high
  • Speed: usually quick to introduce
  • Typical fit: SMEs with elevated protection needs and limited internal infrastructure

Self-hosted or on-premise

  • Effort: less transfer assessment, but greater technical operational effort
  • Data control: very high when external data flows are excluded
  • Speed: generally requires more implementation work
  • Typical fit: confidential data, trade secrets and regulated environments

Which path fits depends on your protection needs, your budget and the speed you want. There is no universally best answer — only the one that fits your situation.

Checklist: How companies can identify a GDPR-compliant AI solution

Do not assess only the product name. Check the plan, contract and technical data flow. The following points matter when evaluating GDPR-compliant AI solutions and tools:

  1. Purpose and data categories: Define the task the tool performs and whether personal data, special-category data, employee data or trade secrets are involved.
  2. Legal basis and purpose limitation: Assign every processing activity a valid legal basis and a clearly bounded purpose. "We are testing AI" is too vague.
  3. Data processing agreement: If an external provider processes personal data on your behalf, review a contract under GDPR Article 28, including instructions and security measures.
  4. Storage location and inference: Ask separately where data are stored and where the model actually computes the request. EU storage does not automatically mean EU inference.
  5. Subprocessors: Review current subprocessor lists, their locations, their responsibilities and the process for changes.
  6. International transfers: Identify recipients and the transfer mechanism. Under the DPF, the specific US recipient must be certified; Standard Contractual Clauses may require a transfer assessment and supplementary measures.
  7. Model training: Establish contractually and technically whether inputs, outputs, feedback or logs are used for training or product improvement.
  8. Retention and deletion: Define retention periods for chats, files, embeddings, backups and logs. Check whether administrators can delete them and whether deletion is provided for after the contract ends.
  9. Roles and access controls: Require company accounts, multi-factor authentication, appropriate roles and a controlled joiner-and-leaver process.
  10. Logging: Record the tool, user, time and relevant configuration without unnecessarily logging complete prompts or sensitive content.
  11. Data-subject rights: Check how access, rectification, deletion, restriction and objection can be implemented in practice, including in vector databases and provider logs.
  12. Data protection impact assessment: Assess whether the processing is likely to create a high risk and therefore requires a DPIA under GDPR Article 35.
  13. Transparency: Where required, explain the purpose, data categories, recipients and essential operation clearly to employees, customers or other data subjects.
  14. Processing record and AI inventory: Add the processing activity to the Article 30 record where the conditions apply. Also document the AI system with its owner, purpose, data classes and approval status.

For Austrian companies: The GDPR applies directly in Austria and is supplemented by the Austrian Data Protection Act. The competent supervisory authority is the Austrian Data Protection Authority. The technical selection criteria are broadly the same. The Austrian Data Protection Authority explains the applicable legal sources; obtain qualified legal advice for binding assessments of individual cases.

Which AI infrastructure can be GDPR-compliant?

An architecture is not compliant solely because of its location. The following spectrum helps when assessing which AI infrastructure can be operated in compliance with the GDPR:

  • Public consumer AI: readily available, but often without a DPA, central administration or robust commitments for company data. Usually unsuitable for personal or confidential information.
  • Business SaaS with contractual commitments: may provide a training exclusion, DPA, roles and deletion options. International transfers and the actual configuration still need to be assessed.
  • Business SaaS with EU data residency: reduces storage-related risks. You must still determine where inference, support, telemetry and connected features are processed.
  • Private AI in an EU cloud: isolated instances and controlled data paths provide greater control while the provider handles much of the operation and scaling.
  • Self-hosted in an EU data centre: can avoid international transfers if external APIs, telemetry, support access and other services are controlled as well.
  • Fully on-premise: provides the greatest technical control but moves responsibility for updates, access protection, backups, availability and logging entirely to the company.

EU hosting can reduce the international-transfer issue, but it does not automatically resolve legal basis, purpose limitation, permissions, deletion or documentation. For many SMEs, a private EU cloud can be a pragmatic middle ground: more technical control than public SaaS, but less infrastructure work than a fully on-premise system. Whether that AI hosting can be used in compliance with the GDPR depends on the actual process.

For a detailed technical comparison of public cloud, EU hosting, private cloud, on-premise and hybrid, see Private AI vs public cloud.

Which path fits your company?

A simple technical decision path starts with the highest protection need of the intended data:

  • No confidential or personal data: A controlled business-cloud service may be sufficient.
  • Personal data with manageable risk: Review the contract, DPA, provider, configuration and EU hosting or another valid transfer mechanism.
  • Trade secrets, internal documents or sensitive customer data: Give preference to assessing a private EU cloud or a self-operated system.
  • Special-category data or a regulated environment: Plan for an isolated private-cloud or on-premise architecture and qualified legal review.

This is technical orientation, not a final legal assessment. The Sovereignty Check turns protection needs, current data flows and operational effort into a traceable architecture decision.

Technical proof: sovereign AI under real constraints

What does this look like when public-cloud AI is not acceptable for sensitive company data? The references overview documents a fully self-hosted AI platform built for experdoo. The starting point was a regulated environment, sensitive company knowledge and a requirement not to use external public-cloud AI for that data.

The implementation included:

  • a fully self-hosted AI architecture,
  • a RAG system for internal knowledge from documents, policies and business processes,
  • several AI agents for research, summarisation and decision support,
  • a multi-tenant architecture with clear separation of data and permissions.

This does not mean that self-hosting is automatically GDPR-compliant. It demonstrates the technical difference: data flows, access, knowledge sources and system boundaries can be deliberately controlled instead of inherited from a standard SaaS setup. If company knowledge should be made usable through RAG from existing data sources, see RAG implementation & AI integration.

What this means in practice

The most common mistake is not choosing the wrong tool. It is making no conscious choice at all while the team continues using public tools without control. This shadow AI in the workplace is not purely a discipline problem; it is often the result of a missing practical tool. Once the team has a secure, fast alternative, the incentive to work around the rules decreases.

That is the core of GDPR-compliant AI in practice: a clearly defined and documented AI workplace where you know where your data are instead of merely hoping. If a problematic upload has already happened, AI incident response supports the initial technical assessment and documentation.

Note: This article offers professional orientation but does not replace legal advice. For a binding assessment of your specific case, please consult qualified legal counsel.

Frequently asked questions

Is ChatGPT GDPR-compliant? Whether ChatGPT can be used in compliance with the GDPR depends on the plan, contract, configuration and purpose. ChatGPT Business and Enterprise do not use business data for training by default, and a Data Processing Addendum is available. EU data and inference residency are limited to eligible Enterprise and Edu customers and do not cover every type of processing.

Which AI is GDPR-compliant? None "out of the box." What matters is the purpose, data categories, legal basis, contracts, data flows, deletion, access controls and documentation. EU-hosted or self-operated solutions can reduce international-transfer and control risks, but they do not replace this assessment.

Do I need a data processing agreement (DPA)? If an external service provider processes personal data on your behalf, a contract under GDPR Article 28 is generally required. This point may not apply to a fully self-operated system without an external processor, but the other GDPR obligations remain.

Do my data absolutely have to stay in the EU? Not necessarily. Transfers to certified US companies can currently rely on the DPF; depending on the recipient, Standard Contractual Clauses and supplementary measures may also be available. Processing in the EU reduces the transfer burden but does not automatically satisfy every GDPR requirement.

Is local AI automatically GDPR-compliant? No. Self-operation can avoid international transfers if external APIs, telemetry, support access and connected services are controlled as well. Legal basis, purpose limitation, permissions, deletion, security and transparency are still required.


Want to know where your company stands today — and which AI usage is feasible in a sovereign and compliant way? The Sovereignty Check creates clarity within a week: where data flow today, what falls under the EU AI Act, and which processes can be automated safely.

Next step

Sounds relevant for your company?

In a no-obligation initial call, we clarify within 30 minutes whether and where getting started is worthwhile for you — honestly and without sales pressure.

Request an initial call