Can AI see my code? Where is data processed? What does the data protection officer say? The most important compliance questions for AI development — answered practically.
The Compliance Question
Every CTO evaluating AI development eventually gets a visit from the data protection officer. Or from the legal team. Or from the works council.
The questions are always the same:
- Where is our code processed?
- Who has access to the data?
- Is our code used for training?
- Is this GDPR-compliant?
Klingt interessant?
Here are the answers.
What the GDPR Actually Covers
Personal Data in Code
The GDPR protects personal data. Code itself is rarely "personal" — but:
- Test data with real customer data — If your fixtures contain real email addresses or names, that's relevant
- Configuration files — If connection strings or credentials contain personal data
- Comments and commit messages — "Fix for Mr. Miller's account" contains a name
Code as a Trade Secret
The GDPR isn't the only issue here. Your code is intellectual property. Relevant questions:
- Is code processed on servers outside the EU?
- Can the platform provider access the code?
- Is code used for training AI models?
The Five Most Important Compliance Requirements
1. Data Residency
Requirement: Code and data are processed exclusively in the EU.
Why it matters: As soon as data leaves the EU, additional requirements apply (SCCs, adequacy decisions). Simpler: Stay in the EU.
What to look for:
- Where are the provider's servers located?
- Is data forwarded to sub-processors?
- Is there a self-hosting option?
2. No Use for Training
Requirement: Your code is not used to train AI models.
Why it matters: If your proprietary code flows into a training set, it could — in fragments — appear for other users.
What to look for:
- Contractual assurance (opt-out is not enough, it must be the default)
- Technical implementation (are prompts cached? For how long?)
- Audit capability
3. Access Control
Requirement: Only authorized persons have access to your code.
What to look for:
- SSO integration (SAML, OIDC)
- Role-Based Access Control
- Audit logs: Who accessed what and when?
4. Data Processing Agreement
Requirement: A Data Processing Agreement (DPA) with the provider.
What it must include:
- Purpose and duration of processing
- Type of data processed
- Technical and organizational measures (TOMs)
- Sub-processor list
5. Deletion and Portability
Requirement: Data can be deleted and exported on request.
What to look for:
- How quickly can data be deleted?
- What data is stored in the first place?
- Is there an export option?
Checklist for Provider Evaluation
Before introducing an AI development platform, verify:
- EU data residency available?
- DPA offered?
- SOC 2 or ISO 27001 certified?
- No training on customer data?
- SSO and RBAC supported?
- Audit logs available?
- Self-hosting option for particularly sensitive areas?
- GDPR compliance documentation available?
The Conversation with the Data Protection Officer
Be prepared. Don't come with "I'd like to use AI," but with:
- 1.Concrete use case (what does the AI do with which data?)
- 2.Data flow diagram (where does data flow?)
- 3.Provider's DPA (pre-filled)
- 4.Technical measures (encryption, access controls)
The better prepared you are, the faster you'll get a "yes."
Conclusion
GDPR compliance in AI development is not an unsolvable problem. It requires diligence and the right platform choice.
The good news: Leading providers have understood that compliance in Europe is not a nice-to-have. The tools are there. The contracts are there. You just need to ask the right questions.
