Using Cloud AI Without Sending Personal Data Abroad

Every few weeks I get a version of the same message. Usually from a bank, sometimes from an insurer, a telco or a government agency. Often in the Middle East or Africa, sometimes in Europe. "We can't send customer data abroad. We don't have GPUs. And our board wants an AI agent live this quarter."

Until recently the answer was that you had to choose: protect the data, use the best models, or move fast. You could have two of the three, never all three. In this article I'll walk through the options these organizations have, what each one costs, and how our new privacy shield lets you use the best cloud models while personal data stays in your own environment.

Four options, each with a catch

Look at the options such an organization actually has. There are really four, and every one of them costs you something.

Option one is a regional private cloud with GPUs. If there is a sovereign or regional cloud in your country that offers GPU capacity, you can run your own models there and keep the data in the region. That's a good option, when it exists. In many countries it doesn't yet, and where it does, GPU capacity is scarce, expensive and often reserved for the biggest customers. The model choice is limited to whatever open models the provider can host. And you still need a team that knows how to run models in production.

Option two is on premises with your own GPUs. If you already have GPUs, or the budget to buy them, personal data never leaves the building. Great. But you need serious hardware, people who know how to run it, and patience. Delivery times are long, prices are steep, and cloud GPU quota isn't easy to get either. Even we have had GPU quota requests turned down in the region we wanted, and we do this for a living. And after all that, you run the open models you can host, not the best models on the market.

Option three is to use the cloud models as they are. Fast, cheap to start and the best quality available. But every name, account number and national ID in the conversation travels to a data center in another country. In a lot of places that's simply not allowed. Egypt's data protection law only allows transfers abroad under strict conditions. Nigeria's NDPA restricts cross border transfers to countries with adequate protection or approved safeguards. Saudi Arabia's PDPL has its own framework for transfers outside the Kingdom. And many of these countries don't have a local region where the big AI models run.

Option four is to wait for the GPUs to arrive, for a local cloud region to open or for the regulator to publish clear guidance. That feels like the safe choice, but waiting has a price too, it's just harder to see on a budget line. Your customers already use AI assistants from global apps every day and compare your service to them. Your competitors are building experience with real conversations, real edge cases and real governance, and that experience compounds. Your own teams don't learn anything while the project sits on hold. And the guidance you're waiting for may never come as a blanket yes. Regulators tend to assess what you actually built, not what you might build one day.

So: privacy, quality, speed. Pick two. I hated that answer. So we built something that makes it obsolete.

What the privacy shield does

The idea is simple. The personal data stays with you. Only the question travels.

You run the Blits.ai platform in your own data center or private cloud. When a customer writes "I am Jan de Vries, please link IBAN NL91 ABNA 0417 1643 00 to my profile", the privacy shield finds the personal parts before anything leaves your environment and replaces them with typed placeholders. The cloud model receives: "I am PERSON_1, please link IBAN IBAN_1 to my profile." It knows it's dealing with a person and an account number, so it can reason, confirm and refer back. It just never learns which person or which account. When the answer comes back, the shield puts the real values in again. Your customer reads a normal reply and notices nothing.

Three things make this more than a clever find and replace.

It covers every path, including the question. Personal data also sneaks in through the conversation history, through the results of your own systems, through the knowledge base and through the customer profile. All of it passes the shield. Your core banking lookup still gets the real IBAN, because that call runs inside your environment.

It checks instead of guesses. An IBAN is only an IBAN if the checksum is right. A card number has to pass the Luhn check. Emirates ID, Saudi national ID, Qatar ID and the Dutch BSN each have their own validation. That's why an order number never gets mistaken for a bank account.

It needs no GPU and no extra container. The detection runs inside our backend, on the servers you already have, and adds a few milliseconds to a turn. No model to host, no sidecar to keep alive, nothing that has to call out to the cloud to decide what's personal.

The best cloud models do the thinking. Your servers keep the secrets.

The privacy shield settings: the Blits.ai standard set with what the model sees instead, your own entries, and the words that must never be hidden.

Why this matters in some regions more than others

Four situations where I think this changes the math.

Regions without a local AI cloud: if the nearest region running frontier models is in another country, option three was off the table for anything involving customer data. With the shield, only placeholders cross the border. There's a legal angle here that's getting interesting: in September 2025 the European Court of Justice ruled in EDPS v SRB that pseudonymized data can fall outside the definition of personal data for a recipient that has no reasonable way to re identify the people behind it. When you run the platform yourself, the link between a placeholder and the real value is stored encrypted in your own database. Nobody at a model provider, and nobody at Blits.ai, can look it up.

I want to be careful here. That ruling is EU law, every country has its own rules, and pseudonymized data is still personal data for you as the controller. This is a conversation for your DPO and your lawyers, not a loophole. But it's a very different conversation from "we send the full transcript to another continent."

A private cloud, but no GPU capacity: some countries do have a regional or private cloud, just without the GPU capacity to run serious models, or with a waiting list for it. That is exactly where the shield fits best: run the platform on normal servers in that cloud, keep every personal value in the region, and let the cloud models do the reasoning on placeholders.

Organizations without GPUs: plenty of banks, insurers and government agencies run solid data centers full of normal servers and no AI hardware at all. They can run our platform there today. The shield lets those normal servers handle everything sensitive, while the heavy lifting happens in the cloud models. No hardware project before the AI project.

Anyone who wants to start now: on premises, the shield is on by default for every tenant with a single setting. In our managed cloud, a tenant switches it on in the menu. You can be live in weeks, not after a procurement cycle for hardware that may arrive next year.

Where it stops

I'd rather tell you the limits than have you find them in production.

Voice is harder, so we built for it. When the assistant speaks an account number, the voice provider has to know it. You choose per assistant: say the real value, say a safe hint like "the account ending in 6300", or use a self hosted voice for that sentence. When the customer speaks, cloud speech recognition hears the audio before any text exists, so no text based shield can help at that point. That's why the Blits.ai platform makes every customer aware of it. In chat and in the app, a short notice appears next to the microphone. On a phone call, the assistant says it once at the start. Both ask customers to type sensitive details instead of saying them. And for the strictest environments, we run speech recognition on your own servers, so the audio never leaves either.

Names in free text are never perfect, so we scan twice. Account numbers are easy, they have checksums. Names don't. The shield uses the verified customer profile, context like "my name is", name lists for seven languages and your own lists. Every piece of input is scanned on its way in, and the complete prompt is scanned once more right before it leaves your environment, so nothing slips through between steps. Every turn records which types were replaced and whether the final scan caught anything, and in the test chat your team can see exactly what the cloud model received. If a detector isn't available, the default is fail closed: the turn doesn't go to the cloud at all.

On top of that, every organization has its own sensitive data: policy numbers, internal customer IDs, case references. You add your own patterns with their own placeholder, an allow list for words that must never be hidden, like your product names, and a deny list for words that must always be hidden. This is where our experience from years of projects in banking and other regulated sectors comes in. We'd be glad to go through your own conversations with you, tune the patterns and lists to your use cases and markets, and make the shield as watertight as it can be before you go live.

Test Chat with "Show what the AI saw": on the left the conversation as the customer has it, on the right exactly what the cloud model received and answered. Below the input, the notice that asks customers to type sensitive details.

The shield doesn't replace your legal assessment, but it makes it a lot easier.

Start with the cloud, move on premises later

Our platform is model agnostic, so this isn't a dead end. Start today with the shield and the best cloud models. When your GPUs arrive, or a local region opens, move the most sensitive workloads to a model you host yourself. That's a configuration change, not a rebuild. As I wrote before, the best AI model doesn't exist. The best setup for this year is rarely the best setup for next year, so don't lock yourself in.

If your organization is one of the many that sent me that message (a bank, an insurer, a telco or a government team), the answer is no longer "pick two." Bring a transcript from your own customer service and we'll show you exactly what the cloud would see. Tell me about your setup and I'll walk you through it.