IA self-hosted: usar inteligência artificial sem vazar dados (nem infringir a LGPD)

Um analista cola uma planilha com nomes, CPFs e valores num assistente de IA público para "resumir rápido". A resposta vem em segundos — e o dado acabou de sair da sua empresa, atravessou a fronteira e foi parar num servidor que você não controla. Ninguém viu. Nenhum alarme tocou. E, tecnicamente, você pode ter acabado de tratar dado pessoal sem base legal.

Esse é o incidente de IA mais comum nas empresas hoje — e o mais silencioso. Não é hacker; é gente competente tentando trabalhar melhor. O problema não é a intenção. É a arquitetura: quando a inteligência mora na nuvem de um terceiro, todo dado que você manda para ela sai da sua casa.

01O vazamento que ninguém vê

Quando você envia um prompt com dado sensível a uma IA pública, três coisas fogem do seu controle de uma vez: para onde o dado vai (servidores de terceiros, muitas vezes fora do país), por quanto tempo fica retido, e para quê ele pode ser usado depois. Você não assinou por isso — mas o dado do seu cliente, sim.

E como não há "vazamento" no sentido dramático — nada é hackeado, nada aparece na imprensa — o risco fica invisível até o dia em que precisa ser explicado. A um cliente. A uma auditoria. À ANPD.

02Por que a LGPD entra nessa

A LGPD não proíbe usar IA. Mas ela cobra três coisas que a IA pública, do jeito que costuma ser usada, atropela: base legal para tratar aquele dado, minimização (mandar só o necessário — e um prompt cru quase nunca é), e cuidado com transferência internacional. Colar dado pessoal num chatbot de terceiro tende a falhar nos três de uma vez.

O ponto não é jurídico-para-assustar. É que essas três exigências, quando você as leva a sério, apontam todas para a mesma solução técnica.

03A resposta não é proibir IA — é mudar onde ela roda

A reação instintiva de muita empresa é bloquear as ferramentas de IA. Isso não funciona: a produtividade é real, então as pessoas dão um jeito — e o uso vira clandestino, pior ainda. A saída melhor é inverter a arquitetura.

Modelos de linguagem podem rodar na sua própria infraestrutura — inferência local, isolada por cliente (com ferramentas como o Ollama), on-premise ou self-hosted. O dado é processado dentro de casa e não vai para a nuvem de ninguém. Você mantém a inteligência e o controle. E, como o código e o ambiente são seus, não há lock-in: nada te prende a um fornecedor.

04A trava que falta: barrar o sensível na porta

Rodar modelo em casa resolve o caso de uso interno. Mas às vezes um serviço externo de IA é útil de verdade — e aí você precisa de uma trava na porta de saída: algo que inspecione o que está prestes a sair e barre o que for sensível antes de virar requisição.

É o papel de uma camada de DLP para IA. No nosso caso, é o ZDZAIShield: ele fica no caminho das chamadas a IAs públicas e bloqueia (HTTP 403) o envio de dado sensível — o pedido nem chega ao terceiro. A IA pública continua disponível para o que é inofensivo; o que é PII para na porta. A diferença entre uma política que pede para ter cuidado e um controle que garante.

05O que você ganha

Não é só evitar multa. É poder usar IA de verdade — nos dados que importam, os internos — sem transformar cada uso num risco. É LGPD atendida por desenho, não por um documento que ninguém lê. E é a tranquilidade de responder, quando alguém perguntar "para onde vai o nosso dado?", com uma frase curta: não vai a lugar nenhum que a gente não controle.

IA e privacidade não são um trade-off que você precisa aceitar. Com a arquitetura certa — inteligência que roda na sua casa e uma trava que segura o sensível na porta — dá para ter as duas. Essa é, aliás, a régua honesta que a gente aplica: onde há IA, apontamos; e onde há dado, ele fica sob o seu controle.