Data protection & compliance · Use cases
GDPR-compliant AI in companies: the citable definition, the legal basis in plain language (processing agreement/DPA, purpose limitation, no training on your input, EU operation, data-subject rights), an objective checklist, roles & permissions with audit logging, a risk matrix by data category and a governance model for the rollout — with answers to the most common questions.
GDPR-compliant AI means that generative AI is operated in a way that the processing of personal data meets the requirements of the General Data Protection Regulation. Six objectively verifiable building blocks are decisive: a data processing agreement (DPA) with the provider, processing within the EU, the contractual assurance that input is not used to train the models, purpose limitation and data minimisation, technical and organisational measures (roles & permissions, logging, secure deletion), and the practical enforceability of data-subject rights. GDPR compliance is therefore not a property of a model but a property of the whole operation — it depends on where data is processed, who has access to it, and whether use is documented in a verifiable way.
How it works
Legally, using an AI platform is usually processing on behalf of a controller: the company remains the controller under the GDPR, and the provider processes personal data on instruction, on the basis of a data processing agreement (Art. 28 GDPR). Five duties follow from that, in plain language. First, purpose limitation: AI may only be used for the defined, documented purpose, not for open-ended further processing — in particular, company input must not be used to train third-party models without a legal basis. Second, data minimisation: only what the task requires belongs in a prompt; special categories of personal data (Art. 9 GDPR, such as health or employment data) require a separate legal basis and tighter controls. Third, operation within the EU or on the basis of permissible safeguards, so no uncontrolled third-country transfer arises. Fourth, technical and organisational measures under Art. 32 GDPR: central permission management, logging of access and secure deletion of data no longer needed. Fifth, data-subject rights (access, erasure, rectification under Art. 15–17 GDPR), which must be enforceable in day-to-day operation. A company AI platform implements these requirements technically: it bundles several models behind one interface with central user and permission management, logs access, limits it on a least-privilege basis, and makes use evidenceable to data protection officers, the works council and auditors.
These recurring tasks can be covered with the same underlying pattern.
Before the first productive use, it is clarified on what legal basis processing takes place and that a data processing agreement (Art. 28 GDPR) with the provider is in place. The DPA governs instruction-bound processing, technical and organisational measures, the handling of sub-processors and deletion after the contract ends. That moves AI use out of a grey area into a documented, auditable processing activity — the foundation of any GDPR compliance.
Use is limited to defined purposes and documented; input and uploads must not be used to train third-party models without a legal basis. On a company platform this is contractually assured and technically implemented, instead of disappearing into the changing terms of private AI accounts. That keeps it controllable what company data is used for, and what it is not.
Only what the task requires belongs in a prompt. Special categories of personal data (Art. 9 GDPR) — health, employment or creditworthiness data, for instance — require a separate legal basis and tighter controls. Pseudonymisation and data masking help reduce personal references before data leaves the organisational boundary. The risk matrix by data category makes visible which data may go into the AI at all.
Administrators manage users, groups and permissions centrally, release data sources deliberately and limit access on a least-privilege basis. Access is logged and reviewed regularly, so it is traceable at any time who accessed what. These technical and organisational measures (Art. 32 GDPR) are the basis for evidence towards data protection officers, the works council and auditors.
Access, rectification and erasure (Art. 15–17 GDPR) must be deliverable in day-to-day operation, not just on paper. That includes a documented deletion procedure for data no longer needed and the ability to remove stored content selectively. A central platform bundles these processes instead of making them impossible across scattered private accounts.
Which data is released and which use cases are permitted is set out by the company in an AI policy — including release levels per data category and a list of permitted and prohibited uses. The rollout follows a governance model: define the policy, set up roles and approvals, train, monitor usage and access. That turns a tool into a demonstrably governed process.
Input
We are a company with 300 employees and want to introduce an AI platform in a GDPR-compliant way. Create a compact release matrix by data category: which kinds of data may go into the AI without restriction, which only pseudonymised, and which not at all? For each category, name the risk, the legal basis required and one concrete protective measure.
Result
| Data category | Into the AI? | Risk | Legal basis / protective measure |
|---|---|---|---|
| Public / anonymous data | Yes | Low | No special basis needed; no personal reference |
| Internal business data (non-personal) | Yes | Low–medium | Confidentiality via roles & permissions; a DPA suffices |
| Personal data (customers, employees) | Only with controls | Medium–high | Art. 6 GDPR + DPA; purpose limitation, least privilege, logging |
| Special categories (Art. 9: health, etc.) | Only pseudonymised / as a rule no | High | Separate basis (Art. 9); pseudonymisation, narrow release |
| Data under professional secrecy | As a rule no | Very high | Only after a separate legal assessment |
In a short demo, we clarify data, ownership and the right workflow for this use case.
Or download the Choosing the right AI platform — the requirements catalogue (PDF, German) as a PDF:
MeinGPT is operated by SelectCode GmbH, which is ISO 27001 certified and has its security reviewed regularly through independent penetration tests (most recently SySS, 2025). Operation takes place in the EU, a data processing agreement (DPA) is standard, and company input is not used to train the models. Access runs through central user and permission management with SSO; calls to internal systems are limited by least-privilege scopes, logged and subject to regular access reviews. The information security management system governs access control, logging, the handling of personal data (including data masking and pseudonymisation) and the secure deletion of information no longer needed; the corresponding policies, the ISO 27001 certification and the penetration-test evidence are available through the Trust Center. Control over data, models and permissions therefore stays inside the company — instead of scattered across private AI accounts — and can be evidenced to data protection officers, the works council and auditors.
These points need to be clarified professionally or organisationally before rollout.
This page does not replace legal advice. Whether a specific processing activity is permissible depends on the individual case and should be clarified with your data protection officer or legal counsel.
A platform provides the technical prerequisites — the decisions about purposes and releases (which data, which use cases) must be made and documented by the company itself.
GDPR compliance is a continuous state, not a tick-box: it must be reassessed whenever the provider, the models or the sub-processors change.
AI results can be wrong; decisions with legal or personal effect need human control, and no automated individual decisions within the meaning of Art. 22 GDPR may be made without review.
Without training and a clear policy, employees route around the platform with private accounts (shadow AI) — then personal data flows uncontrolled, no matter how compliant the platform is.
An AI is GDPR-compliant when the processing of personal data meets the requirements of the General Data Protection Regulation. That includes a data processing agreement (DPA) with the provider, processing within the EU, no use of input to train the models, purpose limitation and data minimisation, technical and organisational measures such as roles & permissions, logging and secure deletion, plus enforceable data-subject rights. GDPR compliance is therefore a property of the operation, not of a single model.
More practical content
Last verified: 2026-07-02T00:00:00.000Z