First: I'm not a lawyer. What follows is what I learned building and selling AI software to Brazilian companies, and every point here was checked — or corrected — by someone who is. If you're using this to decide something serious, do the same.
That said: the part of Brazil's data protection law (LGPD) that most gets in the way of selling AI isn't legal. It's engineering.
The question that kills the proposal
I've watched more than one project stall on a single question from the client's data protection officer:
"If we terminate the contract, how do you delete our data?"
Sounds simple. Then you remember that data went into a shared vector index, became embeddings, showed up in prompt logs, landed in a cache, and is possibly sitting in an eval someone saved to compare models.
The honest answer would be "I'm not entirely sure". That answer loses the deal — and it should.
The right to erasure is in Article 18 and isn't new. What AI did was multiply the places data spreads to, without anyone updating the map. You can't delete what you can't locate.
Controller or processor: find out which you are
This decides the rest of the contract and it's where I've seen most people get it wrong.
In the typical B2B SaaS arrangement, the client is the controller — they decide why and how data is processed — and you are the processor, acting on their behalf. Which means the legal basis isn't your choice: it's theirs. Your job is to operate inside what they defined and to be able to prove that's all you did.
Where this becomes a problem: the minute you use client data to improve your product — training, evaluating, tuning — you may be processing for your own purpose. That's a different conversation. Not forbidden, but it requires a legal basis, transparency, and very likely a specific clause most standard contracts don't have.
The rule I adopted: client data doesn't become product improvement without an explicit clause. If you want to use it, negotiate it. If you didn't negotiate it, don't use it. That closes off an entire category of unpleasant discussion months later.
"Sub-processor" is the word for your model provider
Every model API you call is a sub-processor. Every one. And the client has the right to know who they are and to be notified when the list changes.
Two annoying consequences and one good one:
Annoying one: switching model providers isn't purely a technical decision. If the contract lists sub-processors and requires prior notice, your vendor migration has a contractual clock on it.
Annoying two: international transfer has its own rules. If the model runs outside Brazil — and it almost always does — that's an international transfer of personal data. The ANPD approved standard contractual clauses precisely to give this a predictable path, and most large vendor contracts already ship an equivalent. Worth checking that yours does, rather than assuming.
The good one: that list, once assembled, is the most underrated commercial asset you can have. Walking into the security call with the table already filled in — provider, purpose, country, transfer basis, retention — changes the tone of the whole meeting. I've seen it cut due diligence from weeks to days.
Automated decisions: the article almost nobody reads
Article 20 gives data subjects the right to request review of decisions made solely on the basis of automated processing that affect their interests.
If your agent approves, rejects, scores or ranks people, this reaches you. Two things I now require of our systems because of it:
A record of the why. Storing the output isn't enough. You need to be able to reconstruct which information the decision was made on. It's one of the reasons I built Credence — the provenance trail that helps you debug an agent is the same one that answers a review request.
A human in the right place. "Human review" isn't a bulk-approve button. It's someone with enough information to disagree. If the reviewer only sees the final score, the process is decorative.
What architecture solves, and what it doesn't
I wrote about per-client on-demand models and the LGPD connection is direct, but I want to be precise about the boundary.
It solves: demonstrable isolation, because no process holds two clients' data; verifiable deletion, because configuration and storage are per client; and real retention limits, because the environment is ephemeral by construction.
It doesn't solve: legal basis, purpose, notice to data subjects, contracts, and the processing inventory. That's paperwork, and no architecture substitutes for it.
The common mistake — I made it — is assuming good isolation engineering covers compliance. It covers the demonstrable part. The declared part is still written by people.
The minimum kit I bring to the call
After repeating this many times, it became a folder I open on screen:
- Data flow map: what comes in, where it's processed, what persists, for how long.
- Sub-processor list with country and transfer basis.
- Retention policy per data type, with an actual number, not "as needed".
- Deletion procedure, including indexes, caches and logs — tested, not just written.
- Incident plan: who notifies, within what window, through which channel. Notifying the authority and affected subjects is a legal obligation with a reasonable-time expectation; not the moment to improvise.
- Impact assessment when processing carries higher risk — profiling, automated decisions, sensitive data.
None of this is sophisticated. It's just done beforehand instead of afterward.
On Brazil's AI bill
There's a bill moving through Congress to regulate AI specifically, with obligations graded by risk. I won't bet on final text or timing — any prediction I make here ages fast.
What can be said with some confidence: the requirements showing up in every serious proposal are the ones you should already have. Know what the system does, record how it decides, be able to explain it, be able to delete.
Whoever built that because a client asked will find the regulation tedious. Whoever didn't will find it expensive.