IA local em saúde: inteligência sem vazar dados

Todo projeto de IA clínica passa, cedo ou tarde, pela mesma pergunta do jurídico: “esse dado de paciente vai para onde?”. Na maioria dos pilotos que vejo, a resposta é desconfortável — para uma API de terceiro, numa nuvem fora do controle da instituição, sob um contrato que ninguém leu com atenção. É aqui que o piloto trava, não na qualidade do modelo.

A inversão é simples de enunciar: em vez de o dado sair do hospital, o modelo entra nele.

O bloqueio real não é técnico, é de perímetro

Um dado de saúde é dado pessoal sensível pela LGPD (art. 5º, II), com regras de tratamento mais rígidas (art. 11). Mandar esse dado para uma API externa é, tecnicamente, uma transferência — e toda transferência multiplica superfície de risco: mais um contrato, mais um log fora do seu controle, mais uma parte que pode vazar, ser comprometida ou mudar de política de uso sem aviso.

IA local resolve isso invertendo a direção do movimento: o modelo — os pesos, o binário, a inteligência — é que atravessa a rede uma vez, na instalação. Depois disso, ele roda dentro do perímetro da instituição, sobre os dados que já estão lá. Nenhum prontuário sai para ser processado.

O que “IA local” cobre na prática

• LLMs on-premise. Modelos de linguagem rodando em servidor da própria instituição (ou de um provedor de nuvem privada contratado, com isolamento de instância) — não uma chamada de API para fora.
• RAG local. Retrieval-augmented generation sobre uma base de conhecimento (protocolos clínicos, prontuários, literatura) que nunca sai do ambiente controlado — a busca e a geração acontecem dentro do mesmo perímetro.
• Pipeline de desidentificação antes de qualquer exportação. Quando um dado precisa sair — para pesquisa, por exemplo — ele passa por uma ferramenta como o anonimiz.ar antes, não depois.

Quando um modelo menor local basta — e quando não basta

Nem todo problema clínico precisa do maior modelo disponível. Tarefas bem definidas — estruturar uma nota de evolução, classificar um texto livre em categorias CID/CIAP, extrair campos de um laudo — costumam rodar bem em modelos menores, de poucos bilhões de parâmetros, com fine-tuning ou RAG bem desenhado. É a maioria dos casos de uso que aparecem no dia a dia de um hospital.

O dado não é só intuição de quem implementa: uma revisão sistemática recente sobre modelos de linguagem pequenos (SLMs) em medicina clínica encontrou que versões adaptadas ao domínio, de até 4 bilhões de parâmetros, atingem uma mediana de 91% do desempenho dos maiores modelos de referência — e a correlação entre “mais parâmetros” e “mais acerto” não é estatisticamente significativa nessas tarefas [2]. Um benchmark independente de 26 modelos rodando em hardware de consumo (uma GPU de 12GB, o tipo de placa que cabe num desktop, não num datacenter) já registrou desempenho clinicamente aceitável em suporte à decisão de UTI [3]. E RAG local já mostrou ganho de qualidade mensurável num caso de uso real — consultoria de meio de contraste em radiologia — sem que nenhum dado saísse do ambiente controlado [4].

Um modelo maior — e, com ele, mais hardware — só se justifica quando a tarefa exige raciocínio aberto, contexto muito longo, ou uma qualidade de linguagem que o modelo pequeno simplesmente não entrega (por exemplo, um assistente de triagem que precisa lidar com ambiguidade clínica real, não só extrair campos). Nesses casos, vale considerar um modelo intermediário local antes de aceitar a dependência de uma API externa.

	Modelo pequeno local (até ~8B)	Modelo intermediário local	API de nuvem (modelo de fronteira)
Onde roda	Servidor da instituição	Servidor/nuvem privada da instituição	Infraestrutura do fornecedor
Dado do paciente sai do perímetro?	Não	Não	Sim, a cada chamada
Casos de uso típicos	Estruturação de nota, classificação CID/CIAP, extração de campos	Triagem com ambiguidade clínica, resumo longo	Raciocínio aberto de fronteira
Custo recorrente	Baixo — hardware próprio, sem custo por chamada [3]	Médio — investimento em GPU amortizado	Alto e variável — cobrança por uso [1]
Dependência de terceiro	Nenhuma após a instalação	Nenhuma após a instalação	Contínua

Ordem de grandeza de hardware

Para dar um chão realista à conversa (números aproximados, não uma cotação — a decisão certa depende do caso de uso, não de uma regra fixa):

• Modelos pequenos (até a casa de 8 bilhões de parâmetros) já rodam bem numa única GPU de consumo com 12–24GB de memória — o tipo de hardware acessível a um hospital pequeno ou a um núcleo de pesquisa, não só a operações de grande porte [3].
• Modelos intermediários pedem uma GPU profissional (mais memória, mais banda) — o tipo de investimento que um hospital de médio porte consegue justificar se a IA tocar vários fluxos, não um só.
• Modelos de fronteira, do tamanho dos maiores disponíveis hoje, exigem múltiplas GPUs ou clusters — e aí a pergunta muda de “local ou nuvem” para “vale a pena esse caso de uso específico pagar esse custo”.

O diagnóstico certo é decidir isso caso a caso, não comprar hardware antes de saber qual modelo o problema realmente exige — é exatamente o que a Semana 1 do Sprint IA Saúde faz.

Por que muitos hospitais não podem simplesmente usar a nuvem

Não é só cautela — em 2026, uma parcela relevante de hospitais e redes de saúde está formalmente impedida de usar LLMs hospedados em nuvem pública por exigência de governança de TI, cláusulas contratuais de residência de dados de operadoras, ou legislação estadual de privacidade equivalente [1]. Nesses casos, “IA local” deixa de ser preferência e vira o único caminho tecnicamente viável dentro da política já assinada.

O que isso não resolve sozinho

Rodar local não é uma varinha mágica de compliance. O dado continua sendo tratado — a base legal, o registro de operações e a governança continuam obrigatórios pela LGPD. E cada modelo, mesmo local, precisa de avaliação de viés e de segurança: um modelo mal configurado pode vazar dado por outras portas (logs, cache, backup mal segmentado) — auditoria de cada prompt e resposta, com identidade de usuário e versão do modelo, é prática recomendada mesmo em ambiente isolado [1]. A arquitetura local-first reduz a superfície de risco mais óbvia — a rede — mas não substitui o resto da disciplina.

---

Esse é o fundamento técnico da nossa consultoria de IA local e preservadora de privacidade. Se sua instituição quer avaliar onde a IA cabe sem que o dado do paciente saia de casa, fale com a gente: ai@sciereli.com.br.

Referências

1. Petronella Cybersecurity News. Private LLM Deployment: Enterprise Self-Hosted AI. 2026.
2. Small Language Models in Clinical Medicine: A Systematic Review of Performance, Safety, and Deployment Feasibility. ResearchGate, 2026.
3. Benchmarking Large Language Models for Intensive Care Unit Clinical Decision Support: A Dual Safety Evaluation of 26 Models on Consumer Hardware. medRxiv, 2026.
4. Retrieval-augmented generation elevates local LLM quality in radiology contrast media consultation. PMC, 2026.