Pakistan's data localisation rules, and what they mean for AI

Pakistan's Personal Data Protection Bill has been through several drafts, and the direction of travel in all of them is consistent: certain categories of personal data are expected to be processed and stored on infrastructure inside the country, with cross-border transfer subject to conditions rather than assumed.

For most software that is a hosting question, answered once. For anything using a large language model it is a question that gets answered again on every request, usually by default and usually without anyone deciding.

A prompt is a data transfer

This is the part that gets missed. When an application puts a customer's message, a medical note, a CNIC number or a transaction history into a prompt, that content leaves the country the moment the request does. A model call is not a computation on data you are holding. It is a transfer of that data to whoever operates the endpoint, followed by a computation there.

It does not matter that the payload is transient, or that the provider says it does not train on it. The transfer happened, and under a localisation regime the transfer is the regulated event.

Three questions worth being able to answer

Most teams can answer none of the three. Not because they were careless, but because the usual inference stack was not built to answer them: a request goes to an endpoint, capacity is allocated wherever it is cheapest at that moment, and the location is an implementation detail the API does not expose.

• For a given request, in which country was the model actually executed?
• What was retained after the response was returned, and by whom?
• Can you produce that answer per request, months later, without asking a vendor?

What residency looks like when it is real

Residency is a claim you can check, not a badge. On P/9, requests to the PK NPU-native pool are served on hardware P/9 operates inside Pakistan, and the request log records what served each call. The gateway retains no prompt and no completion on any route: a log row carries the model, the key, the project, the status, the timings, the token counts and the settled cost, and nothing of what was said.

That last part matters more than it sounds. A provider that keeps prompts has to be trusted about where they are kept and for how long. A provider that never writes them down has removed the question rather than answered it.

Sovereignty is not the same as privacy

These get conflated and they are different requirements. Privacy is about who may read the data. Sovereignty is about whose law governs the machine it sits on. A provider can be excellent on the first and still leave you exposed on the second, because a server in another jurisdiction answers to that jurisdiction regardless of the contract you signed.

For a bank, a hospital, a telco or a government department in Pakistan, the second question is usually the one that decides whether a project ships.

A practical position to take now

The bill is not the only reason to sort this out, and waiting for a final text is not a strategy: procurement questionnaires already ask, and the answer takes longer to build than to promise. A workable position is to classify what a prompt may contain, route anything sensitive to a pool inside the country, keep the evidence per request, and be able to show all three without raising a support ticket.

None of that is exotic. It is the discipline that was applied to databases years ago, applied now to the endpoint that sees more sensitive text than the database does.