Como Construí um Agente de IA em Saúde com Foco em Privacidade Usando MCP e LLMs Locais

A maioria das demonstrações de IA na saúde tem um erro fatal: elas enviam dados de pacientes para a nuvem. Isso não é apenas uma má prática — é um campo minado regulatório. Violações da HIPAA podem custar $50.000 por incidente, e "mas nosso fornecedor de IA disse que era seguro" não é uma defesa.

Decidi construir ferramentas de IA para a saúde que resolvem esse problema no nível da arquitetura. Nenhum dado do paciente nunca sai da máquina. Zero chamadas de API na nuvem. Conformidade total com a HIPAA por design, não por política.

Aqui está como construí um conjunto de agentes de IA para a saúde — incluindo um resumidor de intake de pacientes, um intérprete de resultados de laboratório, um desidentificador de EHR e um assistente de documentos médicos — todos rodando localmente com Gemma 4 via Ollama.

O Problema com a IA na Saúde Baseada em Nuvem

Toda vez que uma organização de saúde envia dados de pacientes para uma API de LLM na nuvem, ela está criando:

1. Uma responsabilidade da HIPAA — PHI (Informações de Saúde Protegidas) transmitidas a um terceiro requer um Acordo de Associado Comercial, criptografia em trânsito e em repouso, e trilhas de auditoria
2. Um ponto único de falha — interrupções da API significam que seu fluxo de trabalho clínico para
3. Um custo que escala linearmente — cada encontro com o paciente significa outra chamada de API, e os custos de token se acumulam rapidamente na saúde, onde os documentos são longos
4. Um problema de confiança — pacientes e provedores perguntam cada vez mais "para onde vão meus dados?"

A solução não é evitar a IA — é trazer a IA para os dados em vez de enviar os dados para a IA.

Arquitetura: LLM Local + Padrão MCP

Minha arquitetura usa três componentes principais:

┌─────────────────────────────────────────────┐
│           Aplicação Clínica                  │
│  (Streamlit UI / FastAPI / CLI)             │
├─────────────────────────────────────────────┤
│           Camada do Servidor MCP            │
│  (Definições de ferramentas, modelos de prompt,│
│   manipuladores de recursos FHIR)           │
├─────────────────────────────────────────────┤
│           Tempo de Execução do Ollama       │
│  (Modelo Gemma 4, inferência local,        │
│   transmissão de rede zero)                 │
└─────────────────────────────────────────────┘
         ↕ Tudo permanece no localhost

A camada do Protocolo de Contexto do Modelo (MCP) é o que torna isso modular. Em vez de codificar interações de LLM, cada capacidade de saúde é exposta como uma ferramenta MCP:

• summarize_intake — processa formulários de intake de pacientes em resumos clínicos estruturados
• interpret_lab_results — analisa valores de laboratório em relação a faixas de referência com contexto clínico
• deidentify_ehr — remove PHI de registros eletrônicos de saúde enquanto preserva o significado clínico
• analyze_document — análise de documentos multi-agente para registros médicos

Por que MCP?

O MCP fornece uma interface padronizada entre modelos de IA e ferramentas. Para a saúde, isso significa:

• Interoperabilidade — qualquer cliente compatível com MCP pode usar as ferramentas de saúde
• Componibilidade — encadear várias ferramentas (por exemplo, desidentificar → resumir → sinalizar riscos)
• Testabilidade — cada ferramenta pode ser testada de forma independente com entradas/saídas conhecidas
• Trilha de auditoria — cada invocação de ferramenta é registrada com entradas e saídas

Construindo o Resumidor de Intake de Pacientes

Deixe-me explicar uma ferramenta em detalhes. O Resumidor de Intake de Pacientes pega formulários de intake não estruturados e produz resumos clínicos estruturados.

O Desafio

Os formulários de intake de pacientes são bagunçados. Eles contêm descrições em texto livre misturadas com terminologia médica, abreviações e formatos variados. Um intake típico pode ler:

"52F, apresentando dor lombar x 3 semanas, pior ao sentar. PMH: DM2 em metformina 500mg BID, HTN em lisinopril 10mg diariamente. Sem alergias conhecidas. História familiar: mãe teve MI aos 62 anos."

Um clínico pode interpretar isso instantaneamente. Um LLM precisa de um prompting estruturado para extrair as mesmas informações de forma confiável.

A Solução

class IntakeSummarizer:
    def __init__(self, model="gemma4"):
        self.client = ollama.Client()
        self.model = model

    def summarize(self, intake_text: str, format: str = "estruturado") -> dict:
        prompt = self._build_prompt(intake_text, format)
        response = self.client.generate(
            model=self.model,
            prompt=prompt,
            options={"temperature": 0.1}  # Temperatura baixa para precisão clínica
        )
        return self._parse_response(response["response"], format)

    def _build_prompt(self, text: str, format: str) -> str:
        return f"""
Você é um assistente de documentação clínica. 
Resuma o seguinte formulário de intake de paciente em um {format}"