AI agents under Türkiye's KVKK

What does KVKK’s agentic AI paper cover?

On 12 March 2026, Türkiye’s Personal Data Protection Authority (KVKK) published “Etken Yapay Zekâ (Agentic AI)”, a Turkish-language paper dated February 2026. The Authority coins its own Turkish terms: “Etken YZ” for agentic AI and “YZ Aracısı” for an AI agent. If your company processes personal data of people in Türkiye, through a local subsidiary, a Turkish customer base or Turkish employees, this paper sets out how the regulator reads the topic.

The paper describes agentic systems as integrated structures that assess their environment, adapt to changing conditions and can start actions with varying degrees of autonomy to reach set goals. It draws the line with examples: a logistics system that re-plans delivery routes around traffic and weather is agentic; a chatbot that answers employee questions with quotes from the company handbook is not. In its travel example, the agent reads the user’s calendar and email, checks the company travel policy, uses booking platforms, and books only after the user approves the plan.

The paper creates no new obligations. It presents itself as a general assessment, frames its recommendations as “points that may be taken into account” and notes it may change as the field develops. It does make one point firmly: the difficulties agents raise do not remove the validity or applicability of data protection rules. KVKK, meaning Law No. 6698, applies to agents in full.

Which personal data risks does the paper see in agents?

KVKK says the general AI risks still apply, but multi-step, autonomous operation changes how they play out. The main points:

• Purpose limitation and data minimisation. An agent can re-decide during a task what data it needs and how to get it, which raises the chance of reaching wider datasets than the purpose requires.
• Legal basis drift. Processing that was lawful at the start can lose its link to the legal basis if, as the task unfolds, it is tied to other purposes or grows to cover more data.
• Inference and re-identification. Agents that combine sources can derive sensitive information from data that looked harmless alone, and data assumed to be anonymous can become linkable to a person.
• Traceability. In multi-agent set-ups it is not always possible to show which agent or step a decision or data use came from.
• Accountability. Responsibility between developers and the organisations deploying the system can blur, which makes it harder to know who answers a data subject’s request.
• Accuracy. If a hallucinated output becomes the next step’s input, errors can flow into internal systems and records about a person can be updated incorrectly over time.
• Security. Every data source and tool an agent connects to widens the attack surface. Manipulated inputs can lead an agent to disclose sensitive information or bypass its safety constraints.

What does KVKK recommend?

The final section takes a risk-based approach: identify and manage the risks of each use case rather than aim to remove them entirely.

1. Meaningful human oversight. Define clearly when and at which stage humans step in. The paper gives three stages: during development, people define and test which data types the agent can access and which decisions it can make; at deployment, extra human review applies to potentially high-risk decisions or processing; after deployment, behaviour is monitored.
2. Transparency and explainability, backed by visibility into how components interact and by technical limits that stop the agent acting outside its purpose.
3. Accuracy, maintained throughout, especially when one step’s output feeds the next.
4. Clear roles. Tasks, authority and responsibility allocated between developers, deployers and other parties.
5. Privacy by design and by default, supported by privacy-enhancing technologies.
6. Risk assessment, using tools such as a data protection impact assessment where appropriate.
7. Governance and training. Review existing data protection mechanisms against how agents work, and train the people who run them.

How do the recommendations become design controls?

The paper stays at the level of principles. The table below is our translation into controls you can build into an agent project. It is our recommendation, not a list of KVKK requirements.

Risk or recommendation in the paper	Design control	In practice
Access to more data than the purpose needs	Minimisation at the tool level	A customer lookup tool returns only the fields the task needs; identifiers such as national ID numbers are masked
Agent acting outside its purpose	Least privilege	Read and write tools are separated; each agent sees only its own tools; access runs on behalf of the user with short-lived credentials
Traceability and accountability	Step-level logging	Every tool call is logged with who it ran for, its parameters and the data it touched; log retention is defined
Extra review for high-risk steps	Human approval for consequential actions	Payments, deletions, messages to customers and decisions that may go against a person do not run without approval
Accuracy	Validation of intermediate outputs	Agent-generated information does not overwrite personal data in core systems without a verifiable source
Security	Input and tool hygiene	Instructions arriving in external content grant no permissions; tool parameters are validated

The law gives human approval a further anchor. Article 11 lets a data subject object to an outcome against them that results from analysis carried out exclusively by automated systems. Keeping consequential decisions about people out of the agent’s sole hands makes that right easier to handle. We cover tool and permission design in more depth in MCP and AI agent integration.

What about cross-border transfers and privacy notices?

The paper does not address these separately, but the law’s requirements do not change for agents.

Cross-border transfer. If your agent sends requests containing personal data to a language model hosted outside Türkiye, you need to assess the transfer rules in Article 9 of Law No. 6698. The exposure is larger than with a single chat app, because an agent also sends the customer records it pulls from tools as context. Tool-level minimisation therefore shrinks the transfer too. We outline the transfer options in our KVKK and generative AI checklist; choose the mechanism with your counsel.

Privacy notice (aydınlatma). Article 10 requires telling people, when data is collected, the purpose of processing, to whom it may be transferred and the legal basis. If an agent reads customer emails and updates your CRM, your notice should cover that purpose and the transfer to the model provider. As the agent’s scope grows, the notice must follow; this is exactly what the paper’s warning on legal basis drift points to.

What should you ask a vendor before buying an agent?

Buying a ready-made agent does not move the responsibility off you; the paper asks for roles to be clearly allocated. At a minimum, ask: which systems does the agent connect to and with what permissions; are tool calls logged and can you access the logs; which actions run without approval; in which country are model calls processed; is your data used for training; and when a data subject request arrives, where will you find their data?

KVKK’s AI agenda continues. According to its announcement of 15 October 2026, the Authority will hold an online symposium on personal data protection in the age of AI on 7 December 2026.

Where to start

1. List the agents your company uses or builds, with the systems and tools each connects to.
2. Map which personal data fields each tool returns, and remove those the task does not need.
3. Separate read and write permissions, and add an approval step for consequential actions.
4. Turn on tool-call logging and set a retention period.
5. Identify where model calls are processed and agree the transfer mechanism with your counsel.
6. Update your privacy notice to match what the agent actually does, and run an impact assessment where appropriate.

Corrplus does not give legal advice. We are the technical team that builds the requirements your counsel sets into your systems. In AI agent development projects we design tool scope, permissions, approval steps and logging from the start; through our AI governance service we review existing agents against these controls. If you want to work out where an agent makes sense in the first place, start with our AI discovery sprint.