Turkish companies can send personal data to OpenAI or Claude, both US-based providers, but only through one of the cross-border transfer mechanisms KVKK requires since its Article 9 was amended by Law No. 7499 in 2024. Because Turkey currently has no KVKK Board adequacy decision covering the United States, a company must instead rely on an approved safeguard, most commonly a commitment letter, referred to as a taahhutname, that the sender and the foreign recipient sign and file with the Kurul, or in narrower cases on the explicit, informed consent of each individual whose data is involved. Binding corporate rules are also available for transfers within a corporate group. Sending raw customer or employee data to a US-hosted LLM without one of these mechanisms in place is a KVKK violation regardless of how the data is used downstream. The simplest way to avoid the whole transfer analysis is to mask or anonymize personal data before it reaches the model, since properly anonymized data falls outside KVKK's scope entirely, or to use a self-hosted model kept inside Turkey. This is general information and not a substitute for a KVKK-specific legal review. Nanobase AI sets up masking, self-hosting, or transfer-mechanism compliance depending on what a client's use case requires.
Why every prompt to a US-based LLM is a cross-border transfer
Sending a prompt containing personal data to OpenAI's or Anthropic's API is not a gray area under KVKK; it is a textbook cross-border personal data transfer, since both companies process data on infrastructure located outside Turkey. Before Law No. 7499 amended KVKK's Article 9 in 2024, this required either explicit consent from each individual or an adequacy decision, neither of which scales for an AI product processing continuous customer or employee prompts. The amended Article 9 introduced a broader set of transfer mechanisms modeled on GDPR's approach, which is what makes an OpenAI or Claude integration practically workable at scale.
The available transfer mechanisms, ranked by practicality
| Mechanism | How it works | Practical fit for LLM use |
|---|---|---|
| Adequacy decision | Kurul designates the destination country as offering adequate protection | Not available for the US currently |
| Commitment letter (taahhütname) | Sender and foreign recipient sign a Kurul-published commitment and file it | Most commonly used mechanism for US-based AI vendors |
| Binding corporate rules | Approved intra-group data transfer rules | Relevant mainly for multinational corporate groups, not typical vendor use |
| Explicit consent | Each individual consents to the specific transfer | Impractical at the volume and speed of typical AI application traffic |
For most companies integrating OpenAI or Anthropic, the commitment letter is the mechanism that actually fits the operational reality of an AI product, since it does not require per-transaction consent. The commitment letter is the mechanism that scales to continuous AI traffic; per-transaction consent simply does not.
What filing a commitment letter involves
- Confirm the specific OpenAI or Anthropic entity and data processing terms that will govern the transfer, since the commitment letter needs to reflect the actual contractual relationship.
- Complete the Kurul's published commitment letter template, which requires both the Turkish sender and the foreign recipient to make specific undertakings about data protection standards.
- File the signed commitment letter with the Kurul as required under the current procedure.
- Maintain the underlying data processing agreement with the vendor alongside the commitment letter, since the two serve different but related purposes.
A commitment letter is a KVKK-specific instrument, distinct from the standard contractual clauses used for GDPR transfers, so a DPA built for a GDPR-only company usually needs a KVKK-specific addition rather than reuse as-is.
Reducing exposure regardless of the transfer mechanism chosen
Having a valid transfer mechanism in place satisfies KVKK's legal requirement, but it does not reduce the volume of personal data actually crossing the border. Masking or redacting personal identifiers before a prompt is sent, and routing only the minimum necessary content to the external model, cuts the practical exposure even when the legal mechanism is already sound. For especially sensitive categories, such as health or biometric data, some companies choose to keep that specific processing on a private, in-country model rather than relying on any cross-border mechanism at all. A valid transfer mechanism satisfies the law, but reducing what actually crosses the border is what reduces the real-world exposure. This is general information, not legal advice, and the appropriate transfer mechanism should be confirmed with counsel familiar with current KVKK procedure.
Frequently asked questions
Does a data processing agreement with OpenAI satisfy KVKK on its own?
No. A DPA governs the contractual processor relationship, but KVKK's cross-border transfer requirement is a separate legal mechanism, most commonly the commitment letter, that must be satisfied independently of the underlying vendor contract.
Is the commitment letter a one-time filing or does it need renewal?
The commitment letter is tied to the specific transfer relationship described in it; a material change in the recipient, the data categories, or the processing purpose generally requires updating or refiling rather than relying on the original filing indefinitely.
Can a Turkish company avoid this entirely by using a self-hosted, open-weight model?
Yes, if the model runs on infrastructure located in Turkey or otherwise does not send personal data outside the country, no cross-border transfer occurs and the KVKK Article 9 mechanism requirement does not apply to that specific processing.
Does using Anthropic or OpenAI through a cloud marketplace like AWS Bedrock change the analysis?
The transfer analysis still depends on where the data is actually processed and stored, not the storefront it was purchased through, so a Turkish company should confirm the actual processing region and applicable entity terms regardless of the procurement channel.
How Nanobase AI helps
Nanobase AI helps Turkish companies choose between compliant cross-border use of commercial LLM APIs and fully in-country on-premise deployment when KVKK transfer risk needs to be minimized rather than managed. This is part of our AI security and compliance practice, building on the broader lawful-basis picture in how KVKK affects AI and LLM use in Turkey.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.