Self-hosted AI: use artificial intelligence without leaking data (or violating the LGPD)

An analyst pastes a spreadsheet with names, taxpayer IDs, and amounts into a public AI assistant for a "quick summary". The answer comes back in seconds — and the data has just left your company, crossed the border, and landed on a server you don't control. Nobody saw it. No alarm went off. And, technically, you may have just processed personal data without a legal basis.

This is the most common AI incident in companies today — and the quietest. It's not a hacker; it's competent people trying to work better. The problem isn't the intent. It's the architecture: when the intelligence lives in a third party's cloud, every piece of data you send it leaves your house.

01The leak nobody sees

When you send a prompt containing sensitive data to a public AI, three things slip out of your control at once: where the data goes (third-party servers, often outside the country), how long it is retained, and what it can be used for afterwards. You didn't sign up for that — but your customer's data just did.

And since there is no "leak" in the dramatic sense — nothing gets hacked, nothing hits the press — the risk stays invisible until the day it has to be explained. To a customer. To an audit. To the ANPD, Brazil's data protection authority.

02Why the LGPD comes into play

The LGPD doesn't prohibit using AI. But it demands three things that public AI, the way it's usually used, tramples over: a legal basis for processing that data, minimization (sending only what's necessary — and a raw prompt almost never is), and care with international transfers. Pasting personal data into a third-party chatbot tends to fail all three at once.

The point isn't legalese meant to scare you. It's that these three requirements, when you take them seriously, all point to the same technical solution.

03The answer isn't banning AI — it's changing where it runs

Many companies' knee-jerk reaction is to block AI tools. That doesn't work: the productivity gain is real, so people find a way — and the usage goes underground, which is even worse. The better way out is to invert the architecture.

Language models can run on your own infrastructure — local inference, isolated per client (with tools like Ollama), on-premise or self-hosted. The data is processed in-house and never goes to anyone's cloud. You keep the intelligence and the control. And since the code and the environment are yours, there is no lock-in: nothing ties you to a vendor.

04The missing lock: stopping sensitive data at the door

Running models in-house covers the internal use case. But sometimes an external AI service is genuinely useful — and then you need a lock on the exit door: something that inspects what is about to leave and blocks whatever is sensitive before it becomes a request.

That's the role of a DLP layer for AI. In our case, it's ZDZAIShield: it sits in the path of calls to public AIs and blocks (HTTP 403) any attempt to send sensitive data — the request never even reaches the third party. Public AI stays available for what's harmless; anything that is PII stops at the door. The difference between a policy that asks for caution and a control that guarantees it.

05What you gain

It's not just about avoiding fines. It's being able to use AI for real — on the data that matters, the internal kind — without turning every use into a risk. It's the LGPD satisfied by design, not by a document nobody reads. And it's the peace of mind of answering, when someone asks "where does our data go?", with one short sentence: nowhere we don't control.

AI and privacy are not a trade-off you have to accept. With the right architecture — intelligence that runs under your roof and a lock that holds sensitive data at the door — you can have both. That is, in fact, the honest standard we hold ourselves to: where there's AI, we say so; and where there's data, it stays under your control.