GDPR, KVKK and LLM prompts: what counts as personal data

Every prompt that contains a customer's name is a small data-processing decision. Most people do not think about it that way, which is understandable: the interface looks like a chat window, not like a data export. This article explains, at a general level, how the two frameworks that matter most for European and Turkish teams define personal data, why an LLM prompt falls inside those definitions, and what pseudonymization changes. It is background, not legal advice; for a specific case, talk to your data protection officer or a lawyer.

What counts as personal data

EU GDPR

Article 4(1) of the GDPR defines personal data as any information relating to an identified or identifiable natural person. "Identifiable" is broad: a person can be identified directly (a name) or indirectly (an ID number, location data, an online identifier, or a combination of factors such as job title plus employer plus city). The test is whether someone, using means reasonably likely to be used, could link the information to a person.

Practical consequences:

• Names, email addresses, phone numbers, addresses, national ID numbers, IBANs, licence plates and IP addresses are personal data.
• Free text can be personal data too. "The 42-year-old head of finance in the Munich office" identifies someone even without a name.
• Data about employees, customers, patients, applicants and suppliers' contacts all counts. Being "business" data does not make it exempt.

Article 9 defines special categories: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade-union membership, genetic and biometric data, health data, and data about sex life or sexual orientation. Processing them is prohibited unless a specific exception applies. HR files, medical letters and many legal documents contain this kind of data.

The regulation also distinguishes roles: the controller decides why and how data is processed; the processor processes it on the controller's behalf under a contract. When your team pastes client data into a hosted AI service, your organization is usually the controller and the provider is a processor (or, in some setups, an independent controller). Either way, the controller stays responsible.

Finally, transfers of personal data outside the EU/EEA are only allowed under specific mechanisms (adequacy decisions, standard contractual clauses and similar). Sending data to a service that stores or processes it in another country is a cross-border transfer and needs a basis.

Turkish KVKK

Turkey's Law No. 6698 on the Protection of Personal Data (KVKK) follows a similar structure. Article 3 defines personal data as any information relating to an identified or identifiable natural person, and Article 6 lists special categories (race, ethnic origin, political opinion, philosophical belief, religion, sect or other beliefs, appearance and dress, membership of associations, foundations or unions, health, sexual life, criminal convictions and security measures, and biometric and genetic data). KVKK uses the terms data controller (veri sorumlusu) and data processor (veri işleyen). Article 9 restricts transfers of personal data abroad, and the rules and mechanisms for that transfer have been updated in recent years, so check the current text and the Board's guidance.

The core message is the same as under the GDPR: if the data can be linked to a person, it is personal data, and moving it to a foreign service is a transfer that needs a legal basis and safeguards.

Why a prompt is processing (and often a transfer)

"Processing" in both frameworks covers almost anything you can do with data: collecting, recording, storing, adapting, retrieving, disclosing by transmission, and so on. Pasting a document into an AI assistant is at least:

• disclosure by transmission to the provider,
• storage in the conversation history for as long as it is retained,
• and, if the provider's servers are in another jurisdiction, a cross-border transfer.

Whether the provider trains on the content is a separate question. Even with training disabled, the transmission and storage happened. This is why "we turned off training" is not a complete answer to a compliance question. The relevant questions are: what is our legal basis, do we have a processor agreement with the provider, where is the data stored, and did we minimize what we sent?

What pseudonymization changes

Article 4(5) GDPR defines pseudonymisation as processing personal data so that it can no longer be attributed to a specific person without additional information, provided that additional information is kept separately and protected. Recital 26 adds that data which has been rendered truly anonymous, so the person is not or no longer identifiable, is not covered by the regulation at all.

That gives you two levels:

1. Pseudonymized data is still personal data, because someone holding the mapping table can re-identify people. But the GDPR explicitly recognizes it as a risk-reducing safeguard (Articles 25 and 32 mention it as an example of an appropriate technical measure). Sending pseudonymized text to a provider that never sees the mapping table is much easier to justify than sending raw text.
2. Anonymized data falls outside the GDPR. In practice, true anonymization of free text is difficult; a summary of a very specific dispute may still identify the parties. Treat pseudonymization as the realistic target and anonymization as the exception.

KVKK also uses the concept of anonymization (anonim hâle getirme) and, in Board guidance such as the generative AI guide (in Turkish, summarized in our KVKK guides post), techniques such as masking and pseudonymization as safeguards. The logic transfers directly.

The key operational detail is in the definition itself: the additional information (your mapping table) must be kept separately. If you upload the mapping table with the document, you have not pseudonymized anything.

What this looks like in practice

Consider a support-ticket export you want an assistant to categorize:

The assistant can still classify, summarize and draft a reply. The provider received no name, no email and no real phone number. Your mapping table stays on your device, and you restore the values in the reply with a de-anonymizer.

A practical policy for teams

You do not need a long document. Six rules cover most situations:

1. Anonymize before AI, by default. Names, companies, contact details, IDs and financial identifiers are replaced with consistent labels before anything is pasted or uploaded.
2. Never send special-category data (health, beliefs, union membership, biometric data, criminal records) to a general-purpose assistant, even pseudonymized, unless a DPO has approved the specific use.
3. Use the organization's account, not personal ones, so a processor agreement and retention terms apply.
4. Keep mapping tables local and short-lived. They are the re-identification key.
5. Use tools that do not create another processor. A browser-based anonymizer that runs entirely on the device, such as Unformation, does not receive the data at all, so there is no new processor to contract with. See the security page for how that is verified.
6. Record the decision. A one-line entry in your processing record ("AI assistant X, pseudonymized input only, provider account Y") satisfies most auditors' first question.

Summary

Under both the GDPR and KVKK, anything that identifies a person is personal data, and putting it into a hosted AI prompt is processing and usually a transfer. Pseudonymization does not remove the data from scope, but it is a recognized safeguard that dramatically lowers the risk, provided the mapping table stays separate. Make it the default step, and do it with a tool that keeps the file on your device.

Start with a document now: anonymize it in your browser, works with Wi‑Fi off, no account.