Privacidad y HIPAA con IA: Lo Que Todo Médico Debe Saber

El mayor error al usar inteligencia artificial en medicina puede ocurrir antes de que la IA responda.

Un médico copia una nota clínica, un informe o una consulta de paciente en una herramienta de IA.

La respuesta puede ser correcta.

El resumen puede ser útil.

Y aun así puede existir un problema serio de privacidad.

La pregunta que debería venir antes es:

¿Esta información puede enviarse a esta herramienta bajo este contrato, esta configuración y esta jurisdicción?

Ese detalle cambia completamente el uso profesional de ChatGPT, Claude, Gemini, ambient scribes, buscadores clínicos y sistemas de IA integrados al EHR.

En salud, privacidad no es una nota de rodapé.

Es parte del diseño del workflow.

HIPAA no significa simplemente “usar una herramienta segura”

Nos Estados Unidos, HIPAA regula o tratamento de protected health information em determinados contextos.

Mas dizer:

“esta ferramenta é HIPAA compliant”

é simplificar demais.

O uso real depende de fatores como:

tipo de organização;
tipo de dado;
contrato;
configuração;
quem recebe a informação;
como ela é armazenada.

Em muitos cenários, é necessário avaliar também a existência de um Business Associate Agreement (BAA).

A referência oficial continua sendo o U.S. Department of Health & Human Services.

O produto importa mais que a marca

Uma mesma empresa pode oferecer:

produto de consumo;
plano empresarial;
API;
solução healthcare específica.

As políticas de uso de dados podem ser diferentes.

Por isso, não pergunte:

“Claude pode receber PHI?”

Pergunte:

qual produto Claude, em qual plano e sob qual contrato?

O mesmo vale para:

OpenAI;
Google;
Microsoft;
qualquer outro fornecedor.

Essa distinção é fundamental para Trustworthiness.

Uma conta pessoal pode não ter as mesmas garantias de um produto empresarial

Ferramentas de consumo geralmente têm:

configurações próprias;
políticas próprias;
controles diferentes.

Produtos comerciais podem oferecer:

contratos empresariais;
controles de dados;
administração;
retenção diferenciada;
BAA em cenários específicos.

Nunca suponha equivalência.

OpenAI publica controles específicos para dados empresariais

OpenAI declara que, por padrão, não utiliza dados de produtos empresariais como ChatGPT Business, Enterprise e API para treinar seus modelos. A empresa mantém documentação específica em Enterprise Privacy.

Isso é relevante.

Mas não responde tudo.

Ainda precisamos saber:

retenção;
logs;
acesso;
localização;
uso específico.

“Não treinar” não significa “não processar”.

Anthropic também diferencia produtos

Anthropic publica políticas distintas para produtos de consumo e comerciais.

Em produtos empresariais, a empresa afirma não usar inputs e outputs para treinamento por padrão em determinados cenários. A documentação pode ser consultada em Anthropic Privacy Center.

Novamente:

isso é uma parte da avaliação.

Não a avaliação inteira.

Microsoft tem uma posição forte em healthcare

Microsoft oferece soluções específicas para saúde, incluindo Dragon Copilot, e mantém informações de segurança e compliance no Microsoft Trust Center.

Em ambientes hospitalares, isso pode ser relevante porque a ferramenta já nasce mais perto de:

EHR;
infraestrutura empresarial;
contratos de saúde.

Mas mesmo assim o hospital precisa revisar:

nosso uso específico está autorizado?

HIPAA não é uma certificação simples

Existe um erro frequente:

“é HIPAA certified?”

HIPAA não funciona exatamente como um selo único universal de certificação de produto.

O foco deve ser:

controles;
contratos;
obrigações;
uso adequado.

Um fornecedor pode oferecer suporte a workloads sujeitos a HIPAA.

Isso não significa que qualquer configuração está automaticamente adequada.

O BAA merece atenção

Um BAA define obrigações entre covered entity e business associate.

Antes de usar um fornecedor com PHI, pergunte:

existe BAA?
cobre este produto?
cobre esta região?
cobre este workflow?

Essa pergunta elimina muita ambiguidade.

Dados clínicos devem ser minimizados

Imagine que o médico quer perguntar:

Qual é o melhor formato para explicar hipertensão a um paciente?

Não precisa enviar:

nome;
data de nascimento;
endereço;
número do prontuário.

Pode usar:

adulto de 60 anos com hipertensão recém-diagnosticada.

Quanto menos dado pessoal a tarefa precisa, menos dado deveria ser enviado.

Esse é o princípio de data minimization.

Minimização pode ser a intervenção mais simples

Antes de pensar em criptografia avançada, pergunte:

este dado precisa estar aqui?

Muitas vezes a resposta é:

não.

Remover dado desnecessário reduz risco diretamente.

Anonimizar não é apenas apagar o nome

Substituir:

María García

por:

Paciente A

não garante anonimização.

O documento pode conter:

idade;
cidade;
doença rara;
data;
profissão;
hospital;
evento incomum.

A combinação pode tornar a pessoa identificável.

Esse é um ponto importante também sob GDPR.

Pseudonimização e anonimização são diferentes

Pseudonimização

reduz identificação direta.

Mas permite reidentificação com informação adicional.

Anonimização

busca tornar identificação impraticável.

Em saúde, essa distinção importa muito.

Não trate “Paciente X” como sinônimo automático de dado anônimo.

GDPR adiciona outra camada na Europa

Na União Europeia, dados de saúde são categoria especial de dados pessoais.

O European Data Protection Board e a legislação GDPR estabelecem requisitos específicos.

Para uma clínica na Espanha, é necessário avaliar:

base jurídica;
finalidade;
minimização;
segurança;
retenção;
transferências;
direitos do paciente.

Uma prática permitida nos EUA pode precisar de outra análise na Europa.

HIPAA e GDPR não são equivalentes

HIPAA regula determinados atores e dados em contexto de saúde nos EUA.

GDPR é uma estrutura mais ampla de proteção de dados pessoais.

Por isso:

“cumpre HIPAA”

não significa automaticamente:

“cumpre GDPR.”

O inverso também não.

Para LATAM, verifique país por país

Brasil, México, Colômbia, Argentina e outros países possuem legislações distintas.

Não existe uma regra única chamada:

“privacidade médica na América Latina.”

Esse detalhe importa muito em soluções globais de IA.

O fluxo de dados deveria ser desenhado

Antes de implantar uma IA, crie um diagrama.

Por exemplo:

paciente

↓

consulta

↓

ambient AI

↓

cloud

↓

nota

↓

EHR

Agora pergunte em cada etapa:

que dados entram?
onde vão?
quanto tempo ficam?
quem acessa?

Esse diagrama revela riscos que contratos abstratos podem esconder.

Ambient AI merece atenção especial

Ferramentas como Dragon Copilot ou Nabla podem processar conversas inteiras.

Isso pode incluir:

nome;
sintomas;
família;
sexualidade;
saúde mental;
medicação.

Quanto maior a captura, maior a necessidade de governança.

No artigo DAX Copilot para Notas Clínicas: Cómo Eliminar la Documentación Fuera del Horario vimos como limitar e revisar esse workflow.

Um ditado pós-consulta pode expor menos dados que ambient recording

Essa é uma escolha arquitetural.

Ambient AI

captura tudo.

Dictado controlado

captura apenas o resumo necessário.

A segunda opção pode perder conveniência.

Mas reduzir dados processados.

Privacy by design significa fazer essas escolhas antes da implementação.

Consentimento e transparência também importam

O paciente pode querer saber:

IA está ouvindo?
a conversa é gravada?
onde fica?
o médico revisa?

A clínica deveria ter resposta clara.

Não esperar o paciente descobrir sozinho.

A mensagem precisa ser compreensível

Evite:

“utilizamos sistemas de processamento algorítmico interoperáveis.”

Prefira:

“Usamos una herramienta de IA para ayudar a preparar la nota clínica. El médico revisa el contenido antes de incorporarlo al expediente.”

Clareza aumenta confiança.

Não prometa mais do que o sistema realmente faz

Se o áudio é armazenado por determinado período:

não diga:

“não armazenamos nada.”

Se o fornecedor utiliza subcontratados:

isso precisa ser entendido.

Trustworthiness depende de precisão.

Subprocessors são parte do risco

Um fornecedor pode utilizar:

cloud provider;
analytics;
suporte.

Pergunte:

quem mais processa os dados?

A lista de subprocessadores deveria ser revisada em usos sensíveis.

Transferência internacional pode ser relevante

Se dados saem da UE, por exemplo, podem existir requisitos adicionais.

Não basta olhar país da empresa.

É preciso saber:

onde o dado efetivamente é processado.

Retenção merece uma política específica

Pergunte:

áudio fica quanto tempo?
transcrição fica quanto?
logs ficam quanto?
backups?

Uma nota clínica pode precisar permanecer no EHR.

Mas isso não significa que o áudio bruto precise ficar indefinidamente.

Menos retenção pode reduzir risco

Se o workflow só precisa da transcrição:

talvez o áudio possa ser excluído após processamento.

Isso depende de:

regulação;
política;
finalidade.

Mas é um bom exemplo de minimização temporal.

Os logs também podem conter dados sensíveis

É fácil focar no documento principal.

Mas logs podem registrar:

nome;
prompt;
trecho de texto;
erro.

Por isso, pergunte:

o que aparece nos logs?

Essa é uma pergunta operacional importante.

O prompt também pode conter PHI

Exemplo:

“Paciente João Silva, 67 anos…”

Mesmo sem upload de documento, o prompt já contém dado sensível.

A governança deve considerar texto livre.

Crie templates que evitem identificadores

Por exemplo:

“Adulto de 65–70 años con…”

Isso reduz a chance de o profissional inserir nomes sem necessidade.

Design de prompt também é privacidade.

O acesso interno é outro risco

Não basta confiar no fornecedor.

Pergunte dentro da instituição:

quem pode ver outputs?
quem administra?
quem exporta?

Princípio:

least privilege.

Cada usuário deveria ter apenas o acesso necessário.

Um assistente interno pode violar confidencialidade

Imagine IA conectada ao EHR.

Profissional pergunta:

“mostre casos similares.”

Sem filtros de acesso, pode recuperar registros inadequados.

O problema não é “a IA compartilhou”.

O problema é:

retrieval sem permissão.

A segurança precisa ocorrer antes da geração.

O mesmo vale para RAG clínico

Arquitetura correta:

usuário

↓

permissão

↓

busca autorizada

↓

contexto

↓

modelo.

Não:

modelo vê tudo e promete não mostrar.

Essa diferença é crítica.

Dados sintéticos podem ser excelentes para treinamento

Para:

testes;
demos;
educação;
desenvolvimento;

prefira dados sintéticos quando possível.

Isso reduz necessidade de usar prontuários reais.

Mas sintético precisa representar casos reais

Um dataset sintético perfeito demais pode esconder:

ruído;
abreviações;
inconsistências.

Para testar qualidade operacional, combine:

sintético;
dados adequadamente autorizados.

IA para pesquisa clínica pode precisar de menos PHI que você imagina

Consensus ou PubMed normalmente não precisam saber quem é o paciente.

Pergunta:

“¿Qué evidencia existe para X en adultos con Y?”

é suficiente.

Isso é um grande benefício.

A busca pode ser separada do prontuário.

No artigo Búsqueda Bibliográfica con IA: Consensus, Perplexity y PubMed discutimos exatamente essa separação.

Não envie o prontuário inteiro para responder uma pergunta simples

Se a dúvida é:

qual guideline devo revisar?

extraia:

condição;
idade;
variável clínica relevante.

Não todo o documento.

Isso reduz risco e melhora clareza.

Privacidade também melhora qualidade

Contexto excessivo pode confundir o modelo.

Menos dados irrelevantes:

menos ruído;
menos distração;
saída mais específica.

Privacy by design pode melhorar performance.

O hospital deveria classificar ferramentas

Categoria A

Sem dados de pacientes.

Exemplo:

busca de literatura.

Categoria B

Dados desidentificados.

Exemplo:

análise educacional.

Categoria C

PHI.

Exemplo:

ambient scribe.

Agora controles podem variar.

Também classifique por autonomia

Leitura

IA apenas lê.

Sugestão

IA propõe.

Escrita

IA escreve no EHR.

Ação

IA executa algo.

Quanto maior o nível, maior a governança.

Combine as duas matrizes

Exemplo:

PHI + ação

= risco alto.

sem PHI + pesquisa bibliográfica

= risco muito menor.

Isso ajuda a priorizar controles.

Um inventário de IA deveria existir

A instituição deveria saber:

ferramenta;
fornecedor;
finalidade;
dados;
responsável;
contrato;
risco.

Sem inventário, surge shadow AI.

Shadow AI é especialmente perigosa em saúde

Profissional usa:

conta pessoal;
ferramenta gratuita;
celular pessoal.

A organização não vê.

Proibir tudo pode empurrar uso para esse cenário.

Uma abordagem melhor pode ser oferecer:

ferramentas aprovadas;
regras claras;
treinamento.

A política precisa caber na rotina

Uma política de 50 páginas pode ser ignorada.

Uma regra prática:

Verde

Pode usar.

Amarelo

Use apenas ferramenta aprovada.

Vermelho

Não enviar sem autorização específica.

Isso ajuda no momento real de decisão.

Crie exemplos

Verde

“Explique hipertensión en lenguaje simple.”

Amarelo

“Resumir nota clínica desidentificada.”

Vermelho

“Enviar prontuário completo em conta pessoal.”

Exemplos aumentam Experience e compreensão.

Treinamento deve mostrar erros reais

Não apenas:

“cuidado com privacidade.”

Mostre:

prompt com nome;
screenshot;
documento com metadata;
caso de reidentificação.

Isso torna o risco concreto.

Metadados podem identificar paciente

Um PDF pode parecer anonimizado.

Mas metadata contém:

nome do autor;
sistema;
timestamps.

Antes de upload, o processo pode precisar limpar esses campos.

Imagens também contêm metadados

Fotos clínicas podem incluir:

geolocalização;
data;
dispositivo.

Além da imagem em si.

Isso importa em dermatologia e outras áreas.

No artigo IA para Dermatólogos: SkinVision y Apoyo al Cribado de Melanoma discutimos imagens como dados de saúde.

Auditoria é fundamental

Se ocorrer incidente:

precisamos saber:

quem enviou;
qual dado;
para qual sistema;
quando.

Sem logs e processos, investigação fica muito mais difícil.

Mas logs também precisam de proteção

Mais logging melhora auditabilidade.

Mais logging pode aumentar dados armazenados.

É outro tradeoff.

O desenho precisa equilibrar.

Um plano de incidente deve existir

Exemplo:

interromper acesso;
preservar evidência;
avaliar exposição;
notificar responsáveis;
corrigir.

Não espere o primeiro incidente para decidir.

O fornecedor também precisa ter resposta a incidentes

Pergunte:

como vocês notificam breach?

em quanto tempo?

quem é contato?

Isso deveria estar em contrato.

Due diligence precisa ir além do questionário comercial

Solicite:

security documentation;
DPA;
BAA quando aplicável;
subprocessors;
retention policy;
incident response.

Esses documentos dizem mais que o slogan:

“enterprise-grade security.”

Cuidado com ferramentas que mudam termos

Um serviço aprovado hoje pode mudar:

retenção;
subprocessors;
política.

Por isso, revisão não deve ser única.

Monitore mudanças do fornecedor

Pode ser anual ou conforme risco.

Para ferramenta crítica:

mais frequente.

Isso conecta com governança contínua.

Um bom KPI de privacidade

Não é:

“zero incidentes.”

Pode existir subnotificação.

Melhores métricas:

% de ferramentas inventariadas;
% com contrato revisado;
% de usuários treinados;
incidentes reportados.

Isso mede sistema.

“Zero incidentes” pode até ser ruim

Se ninguém reporta pequenos erros:

talvez exista medo ou invisibilidade.

Uma cultura madura incentiva reporte precoce.

E-E-A-T em privacidade médica

Experience

cenários reais e workflows.

Expertise

HIPAA, GDPR, BAA, minimização.

Authoritativeness

HHS, EDPB, fornecedores oficiais.

Trustworthiness

limites, contratos e transparência.

Isso é especialmente importante porque conteúdo superficial pode induzir comportamento inseguro.

Um checklist antes de usar IA com dados de paciente

Preciso realmente enviar esse dado?
Posso remover identificadores?
Ferramenta está aprovada?
Produto específico está coberto?
Existe contrato adequado?
Como dados são retidos?
Quem acessa?
Existe revisão humana?
O paciente precisa ser informado?
Tenho fallback?

Se qualquer resposta é desconhecida:

pare.

Investigue primeiro.

O erro mais comum não é técnico

É cultural.

Profissional pensa:

“uso só uma vez.”

Esse “uma vez” pode incluir o prontuário completo.

Governança precisa tornar o caminho seguro mais fácil que o inseguro.

Ofereça ferramentas aprovadas

Se a organização proíbe tudo:

usuários podem procurar alternativas.

Se oferece uma opção aprovada e simples:

adoção segura aumenta.

Isso é design organizacional.

O objetivo não é impedir IA

É:

usar IA sem perder controle sobre dados clínicos.

Essa distinção importa.

Privacidade não precisa bloquear inovação.

Precisa definir fronteiras.

HIPAA não deve ser usado como selo de marketing

Pergunta ruim:

“é HIPAA?”

Pergunta boa:

como este workflow específico atende nossas obrigações?

Essa mudança melhora muito a avaliação.

O mesmo vale para GDPR

Não:

“é GDPR compliant?”

Mas:

base legal?

finalidade?

retenção?

transferência?

direitos?

Compliance é processo.

Não adjetivo.

A melhor arquitetura é aquela que processa o mínimo necessário

Imagine duas soluções.

A

grava tudo, armazena tudo.

B

captura apenas o necessário, apaga o restante.

Se ambas entregam o mesmo resultado:

B pode ter vantagem de privacidade.

Essa é uma forma de avaliar produto.

IA médica confiável precisa explicar seu fluxo de dados

Fornecedor que não consegue responder:

“onde os dados ficam?”

é um risco.

Transparência é parte da confiança.

A conclusão mais importante

HIPAA e privacidade não transformam IA médica em algo impossível.

Mas mudam a pergunta.

Não devemos começar com:

“essa IA é boa?”

Primeiro:

essa IA pode receber este dado neste contexto?

Depois:

é tecnicamente útil?

Depois:

é clinicamente segura?

Essa ordem reduz risco.

Porque uma ferramenta pode ser excelente clinicamente e inadequada contratualmente.

Ou segura juridicamente e inútil operacionalmente.

A implementação correta precisa das duas coisas.

Em 2026, médicos terão acesso a cada vez mais ferramentas capazes de:

ouvir;
resumir;
buscar;
gerar.

A tecnologia ficará mais fácil.

O desafio será manter algo mais difícil:

controle sobre onde a informação clínica está, por que está ali e quem pode usá-la.

Fuentes y recursos recomendados

Revisión editorial: Este artículo fue preparado con enfoque de Information Gain y E-E-A-T, priorizando fuentes regulatorias y documentación oficial de proveedores. HIPAA, GDPR, contratos, políticas y funcionalidades pueden cambiar. La evaluación debe realizarse sobre el producto y configuración realmente utilizados, no únicamente sobre la marca del proveedor.

Importante: Este contenido tiene fines exclusivamente informativos y educativos y no constituye asesoramiento legal, de privacidad, ciberseguridad ni compliance. Las obligaciones dependen del país, tipo de organización, datos procesados, contratos y workflow concreto. Antes de utilizar herramientas de IA con información clínica identificable, deben consultarse responsables legales, de privacidad, seguridad y compliance correspondientes.