Responsibility, Law & Governance
GDPR Compliance
The old questions, asked anew: legal basis for data in prompts and training, data processing agreements with the API provider, storage locations, deletion concepts, data subject rights. It gets delicate where models memorize personal data or providers continue training on inputs. Whoever builds GDPR into the design instead of checking afterward spares themselves the painful rebuilds.
An example
A team asks whether a cloud model is “GDPR-compliant.” The question cannot be answered that way, because compliance is not a property of a product but of a processing operation. What can be answered: Which personal data goes in? On what legal basis? Is there a data processing agreement? Where is it processed? How long is it stored? How is an access or deletion request fulfilled? Six questions, six answers, and then the assessment stands.
A closer look
To be clarified are legal basis, purpose limitation, data minimization, storage locations, data processing and the rights of data subjects. With models comes the practical question of how access and deletion should apply once data has ended up in training.
Why it matters
The hardest of these questions in practice is the last one. An access request must also cover what sits in logs, vector databases and caches — and that is exactly where little thought is given during construction. Anyone planning an AI application should therefore decide early how data gets back out, not only how it gets in. The second recurring point: prompt inputs are processing. What employees type into a chat window is subject to the same rules as a database entry. This is an overview, not legal advice.
Commonly misunderstood
“The data stays in Europe” answers only part of the question. Purpose, retention and whether inputs are used for training are the more frequent stumbling blocks.