Data protection in AI projects is usually the last question asked and the one that causes the most delay. Türkiye's personal data protection law (KVKK, Law No. 6698), like the EU's GDPR, does not set separate rules for AI; but the moment customer emails, invoices, contracts or employee data are sent to a language model, all existing obligations apply.
Note: this article is general information, not legal advice. Concrete projects should be assessed with your legal and compliance team.
1. Which data, for which purpose?
The first step is a data inventory: which data will the AI process, which of it is personal, which is sensitive? The processing purpose must be clearly defined and privacy notices reviewed accordingly. "Let's send everything just in case" is risky both legally and technically.
2. Data minimisation and masking
- Only the fields needed for the task are sent to the model.
- Names, national ID numbers, phone numbers and IBANs are masked or pseudonymised before sending if they are not needed.
- In document-processing scenarios, retention of intermediate copies is limited once the output is written to the ERP.
3. Provider choice and cross-border transfers
With a cloud-based model, data is very likely transferred abroad. KVKK's cross-border transfer provisions changed in 2024, introducing new mechanisms such as standard contracts; GDPR has its own transfer rules. When choosing a provider, ask:
- Is submitted data used to train models? (Most enterprise APIs say no; confirm it contractually.)
- How long is data retained, and in which region is it processed?
- Is an appropriate transfer mechanism and contract in place?
For sensitive scenarios, on-premise models are also an option.
4. Secure architecture
- Keys on the server: API keys and system instructions are never sent to the browser.
- Access filtering: in RAG-based assistants, users only get answers from documents they may access.
- Controlled ERP writes: model output goes through an approval step and standard interfaces, not straight into the database, so authorisation rules still apply.
- Logging and audit trail: who got which result, when, with which data; since logs can contain personal data too, access to them is restricted.
- Abuse protection: public-facing assistants use rate limits and protection against prompt-injection attempts.
5. Process and accountability
Technical measures are not enough on their own. At the start of the project, controller and processor roles must be clarified, records of processing updated, and employees told which data must not be entered into AI tools. If no corporate tool is provided, employees start pasting company data into general-purpose tools, which is an invisible data leak.
Short checklist
- Is the data inventory and processing purpose written down?
- Is unnecessary personal data masked?
- Have the provider contract, retention and training policy been confirmed?
- Have access filtering and logging been tested?
- Have usage rules for employees been published?
Data protection is not a brake on AI projects; it is a prerequisite for scaling them. In AI solution architecture, these decisions come to the table in the first design meeting.
