Residency Answers Where. Sovereignty Answers Who Decides.
Data residency is a storage question: which physical jurisdiction holds the bytes at rest, and where the processing happens. Data sovereignty is a control question: whose decisions govern that data and its processing, and how much of that decision-making you can inspect after the fact. The two overlap but they are not the same property, and a system can satisfy one perfectly while failing the other completely. A model served from a data centre inside Türkiye by a provider who can silently change its weights, its safety filters or its retention policy gives you residency and almost no sovereignty. That distinction is the subject of this article, and its consequences reach every layer of the architecture.
The conflation shows up constantly in Turkish RFPs. A requirement will read that data shall be held in Türkiye and then stop there, as though the geography of the disk settles the matter. The vendor answers honestly that storage is domestic, the box is ticked, and nobody asks the follow-up questions that actually decide the outcome: who can push a new model version, with what notice period, and what happens to your prompts in transit. We have read tender documents where the residency clause ran to two pages and the change-management clause did not exist at all. The result is a contract that is auditable on geography and silent on everything that moves model behaviour week to week.
The follow-up questions are simple to write and uncomfortable to answer. Can the provider change the model behind an endpoint without telling you? Most can, and most do. Can you pin a version, and for how long is that pinned version supported? Can you get the safety-filter configuration in writing? Are your prompts used for training, and is that a contractual commitment or a settings toggle someone can flip? Who inside the provider can read a prompt during an incident, under what authority, and is that access logged in a form you can request? A sovereignty review is mostly this list, asked patiently, with the answers written into the contract rather than the sales deck.
Framed this way, sovereignty is a property of your evidence, not of your map. You have sovereignty over a workload when you can reconstruct, months later, which model version produced a given output, what data reached it, who approved the configuration and what has changed since. That is an engineering problem before it is a legal one, and it overlaps heavily with the controls you already need for privacy in AI systems: request logging, prompt redaction, retention windows, and access control on the log store itself. Teams that build those controls get a large part of their sovereignty story for free, whichever deployment posture they eventually choose.
Three Deployment Postures, and What Each Actually Buys
The first posture is the public multi-tenant API. It buys you the strongest models, immediate access to new releases, no capacity planning, and a per-token cost that scales down to zero when nobody is using it. What it does not buy is control over model versions, the jurisdiction of processing, or the retention path of your payloads beyond whatever the terms of service promise. It is the correct default for anything that is not personal data, not trade secret and not regulated: internal drafting, code assistance on public repositories, summarising material you would be willing to publish. Teams that refuse this posture on principle usually end up paying five to ten times more for capability they could simply have rented.
The second posture is a private or dedicated cloud region: the same provider and the same model family, but with a contractual commitment to processing in a named region and, in the better offerings, a dedicated capacity pool your traffic does not share. This buys real residency, usually credible isolation, and often a longer version-pinning window. It does not buy sovereignty over the model itself. The weights remain the provider's, the update cadence remains theirs, and if they deprecate a model family you migrate on their schedule rather than yours. It also does not remove the transfer question if the named region sits outside Türkiye, which for most global providers it still does.
The third posture is fully kurum içi: open-weight models on hardware you control, inside your own network. This is the only posture that gives you all three properties at once, because the data never leaves, the weights do not change unless you change them, and the entire inference path is yours to instrument. You pay for that with capital expenditure, an operations burden that does not go away, a capability gap against frontier models, and responsibility for every safety behaviour the provider used to handle on your behalf. It is the right answer for a narrow set of workloads and an expensive mistake for everything else, which is why the economics section below matters more than the architecture diagram.
Be honest about the middle ground, because that is where procurement conversations most often go wrong. A dedicated region is not a lower-hassle version of kurum içi; it is a different risk profile with a different failure mode. Equally, kurum içi is not automatically more secure, and a badly operated GPU cluster on a flat network with no prompt logging is worse than a well-configured managed endpoint. The choice between open-weight and closed models follows this posture decision, it does not substitute for it. Decide what you need to be able to audit first, then decide which weights you can realistically obtain and operate.
KVKK Cross-Border Transfer Is the Actual Driver
For Turkish enterprises the sharp constraint is rarely a general fear of the cloud; it is Article 9 of Law No. 6698, which governs transfers of personal data abroad. When your application sends a prompt containing personal data to an endpoint processed outside Türkiye, that is a transfer, and it needs a lawful route. The routes available in the statute are an adequacy decision covering the destination, an undertaking or standard contract between the parties with the required approval step, or the explicit consent of the data subject. Each carries different operational weight, and choosing between them is a legal decision your counsel makes, but the architecture has to be built so that whichever route is chosen can actually be evidenced.
Article 9 does not sit alone. The processing still needs a lawful basis under Article 5, and if the prompts touch special-category data such as health records, biometric data, union membership or religious belief, Article 6 adds conditions that a generic consent flow will not satisfy. Article 10 requires that you actually tell people what you are doing, which for an AI feature means the notice must describe the processing in terms a person can recognise rather than a paragraph about advanced technologies. Article 12 puts the security obligation on you as the data controller, the veri sorumlusu, and it does not transfer to your model provider simply because you signed a data processing agreement with them.
The architectural consequence is specific: the transfer happens at the API call, so that is where your control has to sit. In practice this means a classification step before the model call, a redaction or tokenisation layer that strips direct identifiers when the workload allows it, and a routing decision that can send a request to a domestic endpoint when the classifier says it must. It also means logging the decision and not only the outcome, because an audit six months later will ask why a particular request went where it went. Building this once, as shared infrastructure, is far cheaper than retrofitting it into every AI feature your teams ship.
Turkish Language Capability Constrains the Model Shortlist
Turkish is agglutinative, and that has practical consequences for every open-weight model you might self-host. A single Turkish word can carry what English spreads across five or six words, with suffix chains encoding possession, case, negation, tense and question all at once. Models trained overwhelmingly on English handle common Turkish fluently and then degrade in exactly the places that matter to an enterprise: rare inflected forms, domain compounds, proper nouns with suffixes attached, and the vowel-harmony variants of the same suffix. The failure mode is not obvious gibberish, which would at least be easy to catch. It is a confidently wrong case ending that changes who owes what to whom in a contract summary.
Tokenisation efficiency is the number nobody checks until the invoice arrives. In the tokenisers we test, an equivalent passage of Turkish typically consumes somewhere between 1.5 and 2 times the tokens of its English counterpart, and the gap is widest on legal and technical registers with long suffix chains. That multiplier hits you three times over: cost per request, latency, and effective context window, since a 32k-token window holds materially less Turkish document than the same window holds English. Before you shortlist a model, run your own corpus through its tokeniser and compute characters per token. It takes an afternoon of work and it regularly changes the ranking.
Domain vocabulary is the second filter. A model that scores well on general Turkish can still be unusable on Turkish insurance policies, tender specifications, medical discharge summaries or court decisions, because the vocabulary, the abbreviation conventions and the sentence structures are unlike anything in its pretraining mix. This is where a smaller model adapted on your own material regularly beats a larger general one, and where small language models become genuinely interesting for kurum içi deployment: a 7B to 14B model that fits on a single accelerator and knows your document types can outperform a 70B generalist on the tasks you actually run.
None of this can be settled from a leaderboard. Public Turkish benchmarks are thin, sometimes translated rather than natively written, and almost never representative of your document mix. Build a private evaluation set instead. We typically start with 300 to 800 labelled examples per task, drawn from real production documents, split so that the hardest 20 percent are deliberately over-represented. Score with a rubric a domain expert wrote, not with a similarity metric. Re-run it against every model you shortlist and against every version bump you accept. The set costs one to three weeks of expert time to build and it is the single most reusable artefact in the whole programme.
The Honest Economics of Running It Yourself
Start with the entry ticket, because it is higher than people expect. A serious kurum içi deployment is not one accelerator; it is at least two for availability, one more for development and evaluation, and in practice a spare, because a failed card on a Tuesday should not take your AI features offline. Add the host servers, the network, rack space and the power distribution to support them. You can rent instead of buying, which converts capital expenditure into a monthly line and gives you an exit, but rental only stays cheaper while your utilisation is low, and low utilisation is precisely the condition under which you should not be self-hosting at all.
Utilisation is the single number that decides everything. Amortised hardware costs the same at three percent load as at eighty, while an API bills only what you use. In the deployments we see, a single 80 GB-class accelerator serving a quantised 7B to 14B model sustains roughly 20 to 60 concurrent streaming requests before latency degrades noticeably, and enterprise traffic is spiky. A working-day pattern with a sharp morning peak leaves average utilisation somewhere between 10 and 25 percent unless you deliberately backfill the troughs with batch work. If you cannot name the batch workload that will fill your nights, assume your utilisation will be low and price the business case accordingly.
Then come the recurring costs nobody puts in the business case. MLOps is not a side duty: a production kurum içi stack with monitoring, evaluation, model updates and incident response takes two to four full-time engineers in steady state, and one engineer is a single point of failure. Open-weight releases arrive fast enough that a refresh every three to six months is normal, and each refresh means re-running your evaluation set, re-tuning prompts and re-validating guardrail behaviour. Power is arithmetic: a 6 kW node running continuously draws about 4,400 kWh a month, and at a facility efficiency ratio of 1.4 to 1.8 you are actually paying for roughly 6,000 to 7,900 kWh once cooling is counted.
Put together, the break-even is high. We typically see self-hosting start to win when you can keep accelerators above roughly 40 to 60 percent average utilisation, which for most enterprises means sustained traffic in the tens of millions of tokens per day rather than the hundreds of thousands. Below that, and setting the compliance requirement aside, kurum içi is simply more expensive per unit of work, often several times more once staff time is counted honestly. This is the part of the conversation where the right advice is frequently to not do this yet: run the workload on an API, measure real volume for a quarter, and revisit the build once you have a demand curve instead of a forecast.
The Hybrid Pattern Most Turkish Enterprises Land On
After the arithmetic, most organisations converge on the same shape. A small open-weight model runs kurum içi and handles the workloads that genuinely cannot leave: prompts containing customer identifiers, HR records, unredacted contracts, and anything under a sector regulator's specific expectations. Everything else goes to a commercial API, where the capability is better and the cost per unit of work is lower. Between them sits a routing layer that makes the decision per request. This is not a compromise anyone designed on a whiteboard on day one; it is where teams end up after they discover that only ten to twenty percent of their traffic carries the sensitivity that was driving the entire architecture.
The routing layer earns its keep only if it is boringly deterministic about the sensitive path. Classification runs first and errs toward the local model, because the cost of a wrong routing decision is asymmetric: sending a low-sensitivity request to the local model wastes a few cents of GPU time, while sending a high-sensitivity one abroad is a reportable event. The layer needs per-request logging of both the classification and the destination, a kill switch that forces everything local, prompt-level redaction on the outbound path, and identical evaluation harnesses on both sides so that quality differences are measured rather than assumed. Budget four to eight weeks to build this properly.
Classifying the workloads is a business exercise rather than a technical one, and it goes faster than teams expect once someone senior is in the room. Public-facing content work, including marketing copy, documentation drafts and measuring how your brand surfaces in AI answer engines and generative search, contains no personal data and has no residency argument at all. Internal analytics on aggregated, non-identifying data usually does not either. What remains is a much shorter list than the initial fear suggests, and shrinking that list with redaction, pseudonymisation and field-level suppression is usually cheaper than expanding your GPU estate to serve it.
Air-Gapped Deployment and What You Actually Give Up
Air-gapping is a real requirement in defence, in parts of critical infrastructure and in some government work, and it is occasionally adopted elsewhere as a comfort measure by organisations that have not costed it. A genuine air gap means no outbound network path at all: models, dependencies, container images and data arrive on physical media through a review process, and nothing leaves. The engineering is well understood and not especially exotic. The cost is that every convenience you currently get from being connected becomes a manual, scheduled, staffed procedure, and the gap between your environment and the outside world widens every single week whether or not anyone is watching it.
Concretely, here is the list. Model updates stop being a pull and become a quarterly import with a full re-evaluation before promotion. Threat intelligence, meaning new prompt injection patterns, jailbreak families and poisoned package advisories, does not reach you automatically and someone has to carry it in. Managed evaluation services are unavailable, so your evaluation harness becomes software you maintain. Telemetry does not flow out, which means no vendor can diagnose your incident for you. Patching cadence drops from weekly to whatever your change window allows, typically quarterly, and that applies to the CUDA stack and inference server as much as the operating system. Support becomes advisory rather than hands-on.
Agentic workloads are the hardest thing to put behind an air gap, and it is worth knowing that before you commit. An agent's value comes largely from the tools it can reach, and in a sealed environment that set is limited to internal systems whose schemas you must maintain by hand. The safety picture also changes, because much of what keeps AI agents in production well behaved is fast iteration on guardrails informed by fresh attack patterns, and you have just slowed that loop to a quarter. Air-gap the model serving if you must, but keep the agent surface deliberately narrow and the human approval step mandatory.
Vendor Exit Is a Sovereignty Question
Sovereignty includes the ability to leave, and that ability is built or lost in ordinary engineering decisions long before anyone opens the contract. Prompts are the easiest asset to keep portable and the most commonly neglected: keep them in version control as data rather than embedded in application code, with the model-specific formatting isolated behind an adapter. Evaluation sets matter even more, because they are what lets you prove that a replacement model is good enough. If your evaluation lives inside a vendor's platform and cannot be exported with its labels and scores intact, you have quietly turned switching from a migration into a research project.
Embedding lock-in is the expensive one and it is rarely priced in. If your retrieval index was built with a proprietary embedding model, those vectors are only meaningful to that model and you cannot mix them with vectors from another. Switching means re-embedding the entire corpus and rebuilding the index. For a corpus of a few million chunks that is typically one to four days of GPU time plus a re-tuning cycle for retrieval quality, and it has to happen while the old index is still serving traffic. An open-weight embedding model you can host yourself removes this dependency entirely, usually at a modest and measurable quality cost that is worth paying.
Fine-tuning artefacts are the third trap. On most managed platforms the adapter you paid to train is not a file you can download; it exists only as a served endpoint, and your training data plus a recipe is all you actually own. Ask, before you start, whether you receive the weights. Then read the exit clauses: notice period, data return format and window, where thirty to ninety days is typical, deletion certification, and what happens to your fine-tuned artefacts if the vendor deprecates the base model. A vendor whose answers here are vague is telling you something useful about how much sovereignty the relationship really offers.
The Regulatory Touchpoint: EU AI Act and Türkiye
If you sell into the European Union, place systems on the EU market, or your outputs are used there, the EU AI Act reaches your deployment decisions. The Act is Regulation (EU) 2024/1689. It entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions. The prohibited-practices rules in Article 5 and the AI-literacy obligations have applied since 2 February 2025, and the obligations on providers of general-purpose AI models in Articles 51 to 56 have applied since 2 August 2025. None of this depends on where you host, because it follows the market you serve, which is why kurum içi deployment is not by itself a compliance answer.
The high-risk timeline has moved, and a great deal of published guidance has not caught up. Regulation (EU) 2026/1744 of 8 July 2026, the Digital Omnibus on AI, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026, amending Regulations (EU) 2024/1689, (EU) 2018/1139 and (EU) 2023/1230. It deferred the Annex III standalone high-risk categories, covering biometrics, critical infrastructure, education, employment, migration, asylum and border control, from 2 August 2026 to 2 December 2027, and set Annex I product-embedded high-risk systems such as lifts, toys and machinery to apply from 2 August 2028.
Two corrections follow. First, any page still telling you that high-risk obligations apply in full from 2 August 2026 is out of date; check the European Commission's regulatory framework pages and the EUR-Lex text of the amending regulation rather than secondary summaries, and treat undated compliance posts with suspicion. Second, the transparency obligations in Article 50 were not delayed and took effect on 2 August 2026 as scheduled. Article 50(2) gives systems already on the market a grace period for synthetic-content marking until 2 December 2026, and the new prohibitions introduced by the omnibus carry a grace period to the same date. Our full AI Act timeline sets the dates out in order.
In Türkiye there is no dedicated AI law in force. Regulation proceeds by applying existing instruments: Law No. 6698 on the protection of personal data, the Turkish Penal Code, Law No. 5651 and the Turkish Commercial Code. Several bills have been submitted to the Grand National Assembly and none has been enacted, so planning around a specific future statute is speculation rather than strategy. KVKK has published guidance on generative AI and the protection of personal data, which is guidance rather than binding regulation but is a reasonable statement of supervisory expectations. The practical posture is to build to the KVKK obligations you already have and keep the documentation the AI Act would ask for, because retrofitting it later costs more.
How We Approach This at HatsonTech
Our first deliverable on a sovereignty engagement is not an architecture; it is a map. We trace every AI-touching data flow to the point where a payload crosses a boundary, mark what personal data is in it, name the lawful route under Article 9 wherever a transfer happens, and record which of those flows a person could actually reconstruct from logs today. That exercise usually takes two to four weeks on a mid-sized estate, and it routinely finds two things: workloads treated as sensitive that contain no personal data at all, and one or two quiet flows nobody had inventoried, generally inside a tool a team adopted without going through procurement.
For the workloads that do have to stay kurum içi, we select open-weight models against a Turkish evaluation set built from the client's own documents rather than a public benchmark, measure tokeniser efficiency on that corpus, and test the smallest model that could plausibly work before the largest one that would certainly work. Where a general model is not accurate enough on domain vocabulary, adaptation on client data is the next step, and that is the large language model training and fine-tuning work we do. It is usually parameter-efficient adaptation on a modest, well-labelled set rather than full retraining, because the evaluation set is what determines whether it worked.
We also say no fairly often. If a workload is spiky, low-volume and free of personal data, self-hosting it is a way to spend money on hardware and headcount to obtain something you could rent; the honest recommendation there is an API endpoint with a redaction layer and a written change-management clause. If the requirement is genuinely an air gap, we price the operational reality of quarterly imports, a maintained evaluation harness and no vendor telemetry, rather than the day-one build, because that is where these programmes actually succeed or fail. Sovereignty is worth paying for when you can name precisely what it protects.