Data residency in Kazakhstan needs factual proof

A vendor's claim that "data is stored in Kazakhstan" proves nothing until the vendor shows which data, in which system, and at which address. In an LLM service, one request quickly splits into several objects: the original prompt, an attachment, the model response, a technical log, a trace, a quality-control record, a cache, and a backup. Each object may have its own route and lifetime.

A procurement form that asks "do you comply with localization requirements?" almost always gets a confident "yes." Verification starts later: the team requests a flow map, compares it with contracts and network observations, and then follows one test request through deletion. A vendor that actually controls data placement can answer these questions without spending a week polishing marketing language.

First define what must stay in the country

A location requirement must be tied to data categories and your organization's role, or the discussion will collapse into wordplay. Paragraph 11 of Kazakhstan's Rules for the Collection and Processing of Personal Data says that an owner, operator, and third party must store personal data in a database located in the Republic of Kazakhstan. The Law on Personal Data and Its Protection defines processing to include accumulation, storage, alteration, use, depersonalization, blocking, and destruction. This does not mean that every computation involving every type of information is automatically prohibited abroad. It does make clear that one local database is insufficient if a working copy of personal data keeps appearing in a foreign log.

Article 16 of the same law deals separately with cross-border transfer. Storage and transfer therefore require two different checks. A vendor may keep the main database in Almaty while sending the prompt to a model abroad. It may also process the request inside the country while exporting traces to a foreign observability system. In both cases, the statement about a Kazakh database remains literally true and operationally incomplete.

Before requesting documents, the system owner should inventory the data. This includes more than obvious names, national identification numbers, phone numbers, and medical details. Free text may contain customer messages, trade secrets, internal identifiers, contract fragments, and employee data. Mark separately any data that policy prohibits sending to an external model even after masking.

Record four decisions:

• which fields count as personal, confidential, or public information;
• where each category may be stored, processed briefly, and backed up;
• whether depersonalized data may go to foreign models and who validates the quality of depersonalization;
• which sector-specific requirements apply to a bank, government body, clinic, or critical infrastructure operator.

This register does not replace legal advice. It gives architects testable boundaries and stops a vendor from deciding on its own that a prompt "did not count as stored."

The flow map must show every copy

A good flow map answers where a byte-level copy of the request appears, from the incoming API through final destruction. A picture with boxes labeled "client," "cloud," and "LLM" is useless for verification. Request a component-level map with boundaries for countries, legal entities, and runtime environments.

The map should include the API gateway, load balancer, queue, masking service, model router, inference server, object storage, operational database, cache, logging system, tracing, monitoring, backup storage, and support tools. Each edge needs a protocol, encryption method, data category, and transfer condition. Each node needs an operator, physical location, retention period, and the identifier of the related contract or schedule.

Do not accept "data passes in transit" without a technical definition. A process buffer, retry queue, crash dump, and response cache all create copies, even if briefly. Ask whether the HTTP request body is written after 4xx and 5xx errors, whether it enters distributed tracing, and whether an engineer can download it into a support ticket. Failure paths are where the real system most often diverges from the tidy normal-operation diagram.

Ask for the diagram source and a flow table, not just a PDF. A minimum row looks like this:

flow_id: F-017
source: api-gateway-kz
source_location: Kazakhstan, Almaty, DC-1
destination: inference-cluster-kz
data: prompt_redacted, model_parameters
purpose: inference
transport: TLS 1.3
persistence_at_destination: none
logs_body: false
subprocessor: Vendor Legal Name
retention: process_memory_only
evidence: config-export-2026-07-15

This format helps because teams can cross-check it, not because it looks polished. A flow_id can point to a firewall rule, routing configuration, test log, and contract clause. When the vendor changes a model or logging system, it updates specific rows instead of redrawing the entire story.

Prove a data center address through the chain of custody

A physical data center address must lead to the rack or allocated segment where the service runs. A data center operator's certificate confirms the scope of its audit, but it does not prove that your data is in the audited building. Likewise, a contract with a Kazakh cloud says nothing about an external model API called from that cloud.

Request the facility owner's legal name, postal address, labels for the primary and backup data centers, the party to the colocation or cloud lease, and a description of the allocated resources. If rack numbers cannot be disclosed for security reasons, the vendor can show them to an auditor under an NDA or provide an attestation report that includes your service in scope. Refusing to name even the city, legal entity, and facility makes the claim impossible to verify.

Kazakhstan's Rules for the Operation of Data Centers define a data center as an infrastructure facility with computing resources, telecommunications equipment, and storage and processing systems. That is a useful frame: an office or company registration address is not the address of such a facility. A registration extract for a Kazakh limited liability partnership proves the counterparty's jurisdiction, not the disks' location.

Compare four documents:

• a contract or letter from the facility operator stating the address and service;
• a current asset inventory listing clusters, volumes, and storage systems;
• the certificate or technical audit scope that names the facility;
• the architecture diagram linking those assets to your API.

Dates and names must match. An old certificate for a retired data center, an invoice for one rack, and a diagram containing three clusters do not add up to proof. Ask the vendor to explain the gap and retain the answer in the assessment record.

Server room photographs, a phone geotag, and a site tour provide weak supplementary evidence. They do not show the routing of a specific tenant. A sample of resources from the management console or configuration register, signed by the responsible employee and tied to your project identifiers, carries much more weight.

Backups and logs often break the neat story

The primary database may sit in Kazakhstan while backups, logs, and diagnostic exports leave the country. Different teams design these systems, and a vendor sometimes contracts for them separately. Assess them as independent storage locations, not as footnotes to the main database.

For backups, request the policy, job configuration, destination region, frequency, retention, encryption method, key owner, and restoration procedure. A configuration snapshot of the backup job should show the storage name and region. A successful restore report proves that the copy works, but only the configuration and facility operator's records prove its location.

Pay special attention to immutable copies. Protection against deletion is useful against ransomware, but it conflicts with a promise to delete customer data immediately. The vendor must state the maximum time a deleted object remains in a protected copy and explain how it prevents that object from returning to production. A promise to "delete everywhere within 24 hours" does not fit a 30-day immutable archive.

Logs need a separate field map. A safe record containing a status code, token count, model identifier, and random request ID differs from a record containing the full prompt. Ask about API gateway logs, application logs, WAF events, traces, intrusion detection, billing, and support systems. A field may be named message, payload, exception, or span.attribute; calling the whole system a "technical log" does not depersonalize its contents.

Run a controlled test: send a unique string such as RESIDENCY-CHECK-8F31, then ask the vendor to search every accessible system for it. The expected result matters in either direction. If bodies are not logged, the search should return zero matches and the vendor should show the field-exclusion settings. If the string is needed for debugging and was retained, you now have a list of systems, retention periods, and access rights to agree on.

A subprocessor starts where someone else's system sees data

The subprocessor register must include every outside legal entity whose system receives request content or can access it. A page of model logos is not enough. You need the full legal name, country of incorporation, role, data categories, processing location, storage location, and basis for engagement.

Separate model providers from infrastructure contractors. One supplies GPUs and a model, another stores backups, a third receives logs, and a fourth handles support requests. Even if the principal vendor calls the last one a "technical partner," access to an export containing prompts puts it in the processing chain.

A multi-model router needs more than a plain list. Request a matrix containing the model, provider, endpoint, execution country, request-retention mode, use of data for training, availability of a no-retention mode, and fallback rules. Automatic fallback can take a request outside the approved boundary during an outage. Block it with a routing policy for sensitive data instead of relying on a manager's promise.

The contract should require advance notice of a new subprocessor and give the customer a reasonable way to object. Version the schedule containing the register. For each change, the vendor should provide an impact assessment for flows and localization before enabling the component in production.

There is an awkward question: can foreign hardware or software support staff see data during remote diagnostics? The vendor should describe bastion access, session approval, activity recording, export restrictions, and the emergency procedure. Saying "they do not have permanent access" does not answer what a temporary administrator can do.

Test deletion with one object through the final copy

A deletion policy matters only when it links an event, a technical operation, and evidence. The wording "data is deleted when the purposes of processing end" does not say who starts deletion, how quickly it reaches replicas, or what happens inside a backup.

Ask the vendor to describe the lifecycle for contract termination, deletion of an individual record, retention expiry, and withdrawal of consent. Each event needs a process owner, target time, systems in scope, exceptions, and a confirmation format. Legal counsel checks the basis and mandatory periods; engineers check whether the process can run as described.

The best acceptance test uses a synthetic object that is easy to recognize and cannot be confused with real data. Create a request with a unique identifier, wait for it to appear in approved storage, and then submit a deletion request. The vendor should show this sequence:

1. the ticket received a number, timestamp, and verified requester;
2. the operational database, object storage, cache, and search index no longer return the object;
3. logs contain only an approved operation identifier without the source text;
4. the backup was either cleaned or the object was blocked until the copy expires naturally;
5. a signed confirmation lists the checked systems and known remnants.

Do not demand impossible physical overwriting of every SSD block. Modern distributed storage removes a logical reference, performs cryptographic erasure, or releases a block on its internal cycle. Demand the exact mechanism, timing, and assurance that a deleted object will not return after restoration. The wording must match the actual technology.

Ask separately about derived data: embeddings, indexes, caches, evaluation sets, and labeling examples. If the vendor says a depersonalized derivative no longer relates to the data subject, request the depersonalization method and an assessment of re-identification risk. Replacing a national identification number with a stable hash often leaves a record linkable and does not automatically make it anonymous.

The contract turns a presentation into an obligation

Technical material ages quickly, so move material claims into the contract and its schedules. The obligation should cover specific territories, data categories, systems, and change procedures, not the phrase "local service."

In the data schedule, record approved storage and processing locations, a ban on unapproved cross-border transfers, the subprocessor register, retention for logs and copies, the deletion process, support-access rules, and the duty to report an incident. State which document takes priority, or general website terms may conflict with the signed schedule.

An audit right does not have to mean unrestricted access to the data center. A workable structure can have several levels: an annual independent report, remote configuration review, evidence samples on request, and an on-site audit after a material incident. Define response times, acceptable redaction of other customers' data, and the duty to remediate a discrepancy.

Record change control. Moving backup storage, connecting a new model, replacing the logging system, and granting remote access alter the evidence you approved. The vendor should notify you before the change, attach an updated map, and allow time for risk assessment. The contract can permit an emergency change with a short reporting deadline afterward, but the change still needs a record.

Liability should match the potential harm, but a penalty alone does not keep data inside the country. A technical route restriction, a configuration change log, and a right to stop processing are stronger controls. The contract makes sure nobody can quietly disable them after acceptance.

Verification must be reproducible, not trust based

A one-time folder of certificates becomes stale after the next release. Build an evidence register in which every claim has an owner, source, collection date, validity period, and repeatable check. A quarterly review then takes hours instead of becoming another procurement project.

For the claim "sensitive prompts are processed only in Kazakhstan," the package may include a flow-table row, routing rule, allowlist of endpoints, network log from a test request, and contract with the local cluster operator. Each document has a gap on its own. Together they establish the design, configuration, and observed behavior.

Run the network test from your side and, if possible, while the vendor observes it. Record DNS responses, destination address, TLS connection, request ID, chosen model, and route label. IP geolocation is a clue, not final proof: an address may use anycast or a proxy. Compare the observation with configuration and the network owner's records.

Test negative claims. If the vendor says it does not log request bodies, request the redaction configuration, a marker test, and a description of log access. If it does not use data for training, find that restriction in the contract with the final model provider and in the setting for the specific endpoint. The top-level vendor's policy does not bind a subprocessor unless the contract chain repeats the restriction.

A simple evidence-quality scale helps. A self-declaration describes intent. A policy defines a process. Configuration shows the current rule. A log and test show execution. An independent audit checks a sample and the boundaries of control. Do not substitute one level for another or call a certificate proof of a fact outside its scope.

Red flags appear in the precision of the answers

A weak vendor uses absolutes and avoids concrete nouns. It promises "complete localization" without naming storage systems. It says data "never leaves the boundary" but cannot draw that boundary on a map. It cites an NDA when you ask for a subprocessor's country and role, although you are not asking for configuration secrets.

Contradictions are especially worrying. The policy says logs live for seven days, the search interface returns a month of data, and the contract sets no period. A manager promises zero retention while an engineer describes a mandatory diagnostic record after an error. Do not pick the convenient version. Record the inconsistency as a defect and request one corrected answer with evidence.

The phrase "the model is not trained on your data" addresses only one risk. Data may still be stored for abuse monitoring, manual review, billing, or debugging. Ask separately about every purpose, period, and recipient. Encryption also does not prove localization: an encrypted copy abroad is still a copy abroad, and the key's location raises a separate access question.

Refusal to run a deletion test also says something. Production systems should resist arbitrary actions, but a vendor can run the test in a dedicated tenant or show a recent protocol for an equivalent check. If nobody can demonstrate the process anywhere, nobody has probably tested it since the last architecture change.

Do not require a perfect document on day one. A gap may be closed by an agreed deadline if a technical control temporarily limits the risk. But evidence cannot be replaced by a roadmap. A future local facility says nothing about the current route.

Acceptance should produce a verifiable evidence package

Approve an LLM service based on a connected package of evidence, not a single vendor letter. It should contain boundary claims, a diagram and flow table, facility addresses, an asset register, backup and logging settings, a subprocessor list, a deletion procedure, contract terms, and test results. Every gap needs a risk, owner, and remediation date.

Issue the decision by data class and route. A service may be suitable for public text through external models and unsuitable for personal data. A local cluster may be approved for sensitive prompts while foreign fallback stays blocked. This conclusion is more precise than "the vendor complies" and easier to turn into an API gateway rule.

With AI Router, teams can choose models on GPU infrastructure in Kazakhstan when they need in-country storage and local processing, while PII masking, audit logs, and key-level limits help enforce access boundaries. You should still test those capabilities in your tenant with the same maps, configurations, contracts, and tests you would require from any vendor.

Close acceptance with a control object. Send a synthetic prompt, retain the request ID, confirm the chosen route, find the allowed traces, initiate deletion, and obtain a report on remnants in backups. If the vendor can reproduce this path six months after a platform update, you have a working control. If it cannot, the polished address of a Kazakh data center remains an address, not proof of what happened to your data.