KVKK compliant AI architecture: where should the data live?

In an AI project that involves personal data, the first question is not which model to use but where the data will live. It is a decision that cannot be changed later: once the architecture is built, changing the hosting model means rewriting the system.

Note: KVKK is Türkiye's Personal Data Protection Law (Law No. 6698). This article is an architectural guide, not legal advice. Make compliance decisions together with your legal counsel.

What are the three architectural options?

When is masking enough?

In most enterprise scenarios, personal data travels in the context without adding anything to the quality of the answer. Summarising the terms of a contract does not need the other party's national ID number; classifying a support request does not need the customer's name.

A masking layer replaces personal data with placeholders before the text goes to the model, and puts it back when the answer returns. Set up properly, it lowers both the risk and the token cost.

The limit of masking is this: when the personal data is the answer, masking does not help. In "what are this customer's past requests?", the identity is at the centre of the question.

What does regional hosting solve, and what does it not?

The major providers offer data processing in a European region, and their enterprise tiers commit that the data you send is not used for training. For many organisations that is a sufficient level of assurance.

What it does not solve is that the data has entered a third party's system. In some sectors and under some contracts, that is unacceptable regardless of technical safeguards. At that point the discussion is no longer about architecture but about compliance, and legal makes the call.

Is running a model on your own infrastructure realistic?

As of 2026, open weight models match what closed models could do a few years ago on many enterprise tasks. For document question answering, classification and summarisation, the gap is acceptable for most uses.

That part is realistic. The unrealistic part is assuming the cost is zero. When you run the model on your own infrastructure, GPU hardware or rental, the work of updating models, and responsibility for scaling and outages all move to you. With constant, high volume use, the total cost of ownership can fall below the cloud; for an internal tool used now and then, it usually does not.

Where does data leak?

Even in carefully designed systems, leaks usually come from one of these three places:

• Logs. Debug logs store the prompt and the answer in plain text. This is the most often missed point.
• Evaluation sets. Real user queries are copied as test data, and that copy now sits outside access control.
• The vector database. Embeddings are assumed to be "anonymous", yet in most setups the original text sits right next to them as metadata.

Architecture checklist

1. Write down, as a table, which class of data goes where, and get legal sign-off on it.
2. Index access control at the level of the document chunk: filter at query time, do not hide afterwards.
3. Put logs behind the masking layer and define a retention period.
4. Treat the vector database with the same security classification as the main database.
5. Test that a deletion request reaches the vector index too: if a record deleted from the main table stays in the index, you are not compliant.
6. Read the provider contract for the product you use; consumer interface terms and API terms are not the same.

Summary

The right question is not "cloud or our own server" but "which data really has to go to the model". In most projects, an honest answer shows that only a very small part needs to be sent, and at that point the compliance discussion becomes a much easier one.