As soon as an AI feature processes customer names, emails, support tickets or documents, the GDPR applies — and in Switzerland the revised Data Protection Act as well. The language model is not a legal special case but another recipient and another processing step. The questions are the familiar ones: on what basis is data processed, who receives it, where is it stored, for how long, and can data subjects exercise their rights? What is new is that these questions are easily overlooked with AI features because the processing is hidden in code.
Settle the legal basis
For most features in a B2B SaaS, the provider acts as its customer's processor. The customer decides which data enters the product and needs its own legal basis. The provider must ensure the AI processing is covered by the mandate: a ticket summary feature is something else than using the same tickets to improve your own models. The latter is separate processing for your own purposes and needs its own basis — which is often exactly where it fails.
In B2C the provider is the controller. An AI feature the user actively triggers usually rests on contract performance. For background analysis, profiling or reusing inputs for training, that is generally not enough.
The model provider as sub-processor
Using an external language model via API means passing data to a service provider. It is a sub-processor and must appear on the sub-processor list promised to customers in the data processing agreement. With the model provider itself you need a processing agreement covering that inputs are not used for training, how long they are retained and how security incidents are reported. The major providers offer such terms for their business APIs; they should still be read and documented.
Where data is processed
If processing takes place outside the EEA and Switzerland, it is an international transfer. For the US, check whether the provider is certified under the Data Privacy Framework; otherwise standard contractual clauses and an assessment of access risks are required. Many B2B customers in the DACH region now require processing in Europe anyway. Several model providers and cloud platforms offer European regions, sometimes with a different model range than the global API. This decision should be made early because it shapes architecture and contracts.
Data minimisation in the prompt
The most effective protection is not to send personal data to the model where it is not needed. To categorise support tickets the model needs the content, but rarely names, email addresses or phone numbers. These can be replaced by placeholders before sending and reinserted after the answer. Conversation histories and search results should also be cut to what is necessary — which lowers costs as a side effect.
Special care applies to sensitive data: health information, religious beliefs, biometric characteristics. If an AI feature can process such data, for instance because users type free text, it belongs in the risk assessment even if that is not the intended purpose.
Logs are personal data too
Prompts and answers are often logged for quality assurance and debugging. These logs contain the same personal data as the original request and follow the same rules: purpose limitation, limited retention, restricted access. They are also part of an access request and must be included when data is erased. A fixed retention period and pseudonymised logs solve most problems.
Transparency towards users
The privacy policy must name the AI processing: which data, for what purpose, which recipients, which countries. Since 2 August 2026 the EU AI Act's transparency obligations also apply: people must be able to recognise that they are interacting with an AI system unless it is obvious. For decisions made solely by automated means with significant effects on people, Article 22 GDPR sets additional limits. Most SaaS features support people in decisions and do not fall under it — but that should be recorded with reasons.
When an impact assessment is needed
New technologies, large-scale processing, profiling or sensitive data are typical triggers for a data protection impact assessment. An AI feature that evaluates job applications, summarises health information or analyses employee behaviour almost certainly needs one. A feature that rephrases text the user enters usually does not. The distinction should be documented, because customers ask exactly that in supplier audits.
A starter checklist
- Is the AI processing covered by the mandate or purpose?
- Is the model provider contractually bound and on the sub-processor list?
- Where is data processed, and on what basis is it transferred?
- Is personal data minimised before sending?
- Do logs have a retention period and are they part of access and erasure processes?
- Does the privacy policy name the AI processing, and is the AI interaction recognisable?
Anyone who can answer these questions properly has a solid basis for most AI features. Innopulse implements these requirements in its own products and supports SaaS providers with technical and organisational implementation; for individual legal questions we recommend specialised counsel.