Segurança da informação · LGPD

Sigilo por construção. A coluna sensível está ausente, não trancada.

A identificação é descartada na porta sem termo, ou vai ao cofre isolado. Quem reabre é o servidor do app — nunca o modelo — nominal por apólice e sempre registrado. Minimização acontece na entrada, não na saída.

Agregado por padrãoO que sai para a corretora vem em grupos de pelo menos 5 vidas. Diagnóstico nunca aparece por pessoa fora do acesso médico com termo.
Ninguém abre nome ou CPF sem termoTermo de sigilo nominal, por profissional e apólice, 12 meses. Cada abertura fica registrada: quem, quando, qual, por quê.
A IA nunca recebe identidadeSó agregado e hash cruzam a fronteira para o modelo. Nome e CPF não entram no prompt.
Uma corretora não vê a outraIsolamento por linha desde a primeira migration, testado antes de cada entrega: a sessão de A retorna zero linhas de B.
O portão da ingestão

Com termo, a identificação vai ao cofre. Sem termo, é descartada na porta.

Entrada
Operadora envia nome · CPF · endereçoAlgumas operadoras mandam. Não importa: a regra é a mesma.
Termo de sigilo vigente para (profissional × apólice)?
Sem termo
Identificação DESCARTADA na portaMinimização na entrada. O resto do dado entra por hash ou agregado.
Com termo
Cofre de identidade — isoladoInacessível ao agente de leitura. Reabertura só pelo servidor do app, nominal, gravada em log de reidentificação.

A trava vive no cofre, não no chamador — mesmo o agente chamando direto é barrado. Vestir “médico” não cria termo: o termo é nominal, por 12 meses, com o hash do PDF assinado (o PDF não sobe ao servidor — o navegador calcula o SHA-256).

Eixo N · individualização
N0 agregadogrupos ≥ 5 vidas
N1 hashpseudonimizado — segue sensível
N2 cofretermo nominal + log
Eixo C · clínico
C0 sem CIDcorretora
C1 grupo de causaRH · sem ficha
C2 fichamédico · auditor

Persona = uma região em N × C × escopo. Não é uma view filtrada: é um mart físico por nível — o dado que a persona não pode ver não existe na camada que ela consulta.

● log de reidentificação · apólice 4471-Bimutável
10:02:14Dra. Ana L.Revelou hash 7f3a…c19e · finalidade: auditoria de OPME · caso #A-0417a91f_c4
09:58:41app serverTermo 2026-0311 verificado · vigente até 14/03/2027 · SHA-256 do PDF confere7be0_1d
09:47:03agente_leituraSELECT no cofre de identidade — NEGADO (revoke · deny-by-default)e3c8_92
09:46:55validadorTentativa de religar modo confiável dentro de uma consulta — BLOQUEADO41d7_aa
09:31:20Thiago R.Tentou abrir hash 21be…88d0 — SEM TERMO para a apólice · bloqueado, registrado9f2b_77
09:12:08RLSSessão do tenant A consultou beneficiários — 0 linhas do tenant B (provado em teste)c0d4_31

Não existe caminho para nome ou CPF que não passe por esse log: quem, quando, qual beneficiário e com que finalidade. Registro ilustrativo.

A fronteira de confiança

O modelo nunca vê identidade — só hash e agregado cruzam a fronteira.

O app orquestra agentes especialistas que propõem consultas somente-leitura, filtradas por um validador e pelo teto da persona. O que sai da infraestrutura health[ops] para o provedor do modelo é dado desidentificado mais o dicionário de schema. Nome e CPF nunca entram no prompt.

Usuário
PersonaCorretora, RH ou médico. O teto da persona é aplicado nos dois bancos — o modelo não cruza o que ela não pode ver.
perguntacontexto
health[ops] · servidor da aplicação
Orquestrador + agente especialistaClassifica a intenção, roteia e propõe SQL somente-leitura. O validador barra alteração de sessão, DDL e escrita; impõe limite e timeout.
  • 80% gold · Postgres (RLS, cofre isolado)
  • 20% raw · warehouse, por intenção
  • pack regulatório · pack atuarial · dicionário de schema
só hash /
agregadoresposta + tool calls
Provedor do modelo
Claude (Anthropic)Raciocínio adaptativo, streaming, laço de ferramentas, saída estruturada. Recebe dado desidentificado + schema. Nome e CPF nunca entram no prompt.
“Multi-agente” é engenharia de agentes, não fine-tuning. Cada especialista = system prompt + ferramentas + intenções permitidas + pack de conhecimento. Sem treinar pesos com o seu dado. O modelo propõe; o validador decide. Uso auditado em log de atendimentos.
Postura

Quatro pilares — e uma lista do que não existe aqui.

Fail-closed, sempre

Toda flag de visibilidade nasce falsa. Um bug que fecha demais é um chamado de suporte; um que abre demais é um incidente. Escolhemos o primeiro.

Agregado por padrão

Tudo que sai para a corretora vem em grupos de pelo menos 5 vidas, e diagnóstico nunca aparece por pessoa. A identidade, quando autorizada, é aberta pelo servidor da aplicação — nunca pelo modelo de IA.

Acesso ⟂ login

Allowlist por pessoa (quem pode) é independente do SSO (como entra). Nunca autorizamos por domínio de e-mail.

Isolamento provado

RLS multi-tenant desde a primeira migration. Agente com whitelist deny-by-default. Tenant A não vê linha de B — testado antes de cada entrega, não só prometido.

  • Chave que ignore o isolamento entre clientes. Não existe no projeto. Se um dia for inevitável, é decisão do CTO, em cofre de segredos, restrita a um endpoint.
  • Autorização por domínio de e-mail. Liberar um domínio libera a corretora inteira quando só duas pessoas deveriam entrar. A allowlist é por pessoa.
  • Senha das bases do cliente guardada na plataforma. Registramos apenas onde a credencial vive.
  • CID individual na saída. Sempre agregado. Persona de saúde enxerga CID; a corretora recebe sigilo fechado. O agente aponta divergência e cita a norma — não conclui nexo causal.
  • Dado identificado no prompt do modelo. Nome e CPF não cruzam a fronteira. Quem abre o cofre é o servidor do app, com termo, e fica registrado.
número → evidência → fonte

Veja o que o health[ops] encontraria na sua carteira.

30 minutos, com a sua carteira e a série da ANS na mesa. Você sai com 3 achados prioritários — número, evidência e fonte — e decide se quer ver o resto.

ou escreva para vinicius@healthops.com.br