Modelo por demanda: vender IA B2B sem quebrar na contaB2B AI on demand without wrecking the margin

Every B2B AI deal in Brazil reaches the same point in the conversation. Legal joins the call and asks:

"Will this data train someone else's model? Is it isolated from other clients' data? Where does it run?"

Good questions. And the answer most vendors give — "we use the OpenAI API with zero retention" — is technically true and commercially insufficient, because it doesn't answer the second question, which is the one the client is actually asking: does what's mine stay mine?

Trying to answer that properly is how we stopped treating "the model" as something shared and started treating it as something that turns on and off per client.

The deadlock

There are two obvious ways to serve models in B2B and both are bad for opposite reasons.

Pure multi-tenant. One model, one queue, everyone inside. Cheap, simple, and you spend your life explaining isolation in audits. Leak one prompt across tenants and the conversation is over.

A dedicated instance per client. Clear isolation, easy contract to sign, and you've just bought an idle GPU per client. With thirty mid-sized clients using three hours a day, you're maintaining thirty cards to use 12% of them. The math doesn't close.

The deadlock is real. What breaks it isn't picking a side — it's noticing that dedicated doesn't have to mean permanent.

Dedicated for the length of the request

What worked for us: each client has a configuration — weights, adapters, prompts, knowledge base, credentials — and that configuration becomes a live environment only while a job runs. Job ends, environment dies. Work arrives again, it comes back up.

Isolation doesn't come from the machine belonging to them. It comes from no process ever holding two clients' data at the same time.

@app.function(gpu="A10G", timeout=600)
def run_job(tenant_id: str, payload: dict) -> dict:
    cfg = load_config(tenant_id)       # weights, adapter, prompts
    ctx = open_context(tenant_id)      # isolated storage and credentials
    return execute(cfg, ctx, payload)  # the container dies after this

The detail that makes it worth anything is that the container is discarded at the end. There's no leftover state to leak to the next request, because within that process there is no next request.

On the contract side this becomes a sentence legal can actually read: each client's processing occurs in a dedicated, ephemeral execution environment, with no shared persistence between clients. That's much stronger than "we filter by tenant_id in the WHERE clause", which is what most SaaS actually has.

What the client really gets

Tuning without contamination. A client with its own vocabulary — in real estate, every network calls the same thing three different names — gets its own adapter. It improves for them and changes nothing for anyone else. Different from "we tweaked the global prompt and hoped".

Model choice per client. One wants the best output and pays for it. Another wants the cheapest that passes acceptance. Because the model is a configuration parameter, both fit in the same product without a fork.

Offboarding that means something. A client cancels, you revoke the configuration and their data stops existing in the flow — no stray vector sitting in a shared index nobody knows how to repartition. I've watched good companies stall for six months trying to answer "how do you delete what's mine from your index?".

What hurts operationally

It isn't free. Three real costs:

Configuration becomes a product. Thirty clients with different weights, adapters and prompts is thirty things to version, test and roll back. Without a versioned registry for that, you don't have a product, you have thirty hacks sharing a name. It took us a while to accept that this registry is the important part of the system, not an infra detail.

Cold start per client. Each client's first request of the day is the slow one. Worth measuring, and if a human is waiting on that endpoint, keep it warm through their known peak window — which in Brazilian B2B is reasonably predictable, because everyone works the same business hours.

Testing multiplies. A pipeline change has to pass across N configurations, not one. Without a per-tenant regression suite, your first improvement becomes your first incident.

And there's a non-technical cost: pricing. Variable usage with variable cost is beautiful in engineering and terrible in sales if you sell a flat subscription. Either the price follows volume, or you design the plan with an explicit usage cap. Getting this wrong doesn't break the system, it breaks the margin — which is worse, because it takes longer to show up.

Where LGPD fits

Everywhere, and it deserves its own post, but the short version is: this architecture doesn't make you compliant by itself. It makes your answers verifiable.

When the client's data protection officer asks who the sub-processors are, where data is processed, how long it's retained and how it's deleted, you need answers that are written down and tested. The difference is that with ephemeral per-client execution those answers are demonstrable rather than being privacy-policy promises.

Having the right architecture and the wrong paperwork loses the deal just the same. The paperwork is part of the product too.

The test I'd use

If your average client uses AI for less than six hours a day and their legal team asks about isolation, on-demand per-client models are probably the right shape.

If they consume most of the capacity, permanently dedicated wins again — and at that point it's a contract discussion, not an architecture one.

The mistake I made was treating this as an infrastructure decision. It's a product decision: it defines what you can promise, what it costs to keep that promise, and how fast you can onboard the next client without turning into a consultancy.