Rodar um modelo on-device elimina totalmente a necessidade de um BAA?

Para a inferência local em si, sim, porque nenhum PHI é divulgado a um terceiro. Você ainda precisa considerar o papel do fornecedor do software. Se o runtime local, o shell do workspace ou qualquer plano de gerenciamento puder receber PHI via telemetria, logs ou sessões de suporte, o fornecedor atua como business associate e um BAA é apropriado. O padrão seguro é confirmar por escrito que o fornecedor não recebe PHI do dispositivo por padrão e desativar qualquer telemetria opcional que possa carregar conteúdo. Fallbacks em nuvem sempre exigem um BAA com o provedor do modelo em nuvem.

Podemos usar ChatGPT, Copilot ou Gemini em fluxos HIPAA?

Sim, mas apenas nas configurações enterprise específicas que o fornecedor concordou em cobrir sob BAA, e apenas nas superfícies explicitamente nomeadas nesse acordo. A OpenAI cobre a API e certos tenants ChatGPT Enterprise ou Edu. A Microsoft cobre Azure OpenAI Service e tenants Copilot qualificantes. A Google cobre o Gemini em tiers qualificantes do Workspace, excluindo NotebookLM e Gemini no Chrome. Tiers free e standard de consumidor não são cobertos. O problema mais difícil é o comportamento da força de trabalho: bloquear as superfícies de consumidor na camada de rede ou navegador importa tanto quanto o contrato.

Como logs de auditoria diferem para AI versus acesso tradicional ao EHR?

Logs de auditoria tradicionais do EHR capturam acesso a registros por usuário, horário e ação. Logs de auditoria de AI precisam capturar o prompt, o modelo e a versão, o contexto recuperado, a resposta, o usuário, o workspace e quaisquer ferramentas que o modelo invocou. Também precisam capturar decisões de roteamento para nuvem quando um fallback BYOK é usado. Retenha esses logs junto com os do EHR sob a mesma política de retenção, armazene em um repositório à prova de adulteração e alimente o mesmo SIEM que seu time de segurança já monitora, de modo que a atividade de AI faça parte da resposta normal a incidentes e não de um silo paralelo.

E sobre as mudanças de 2026 na Security Rule?

Recentes regulamentações do HHS movem várias salvaguardas antes 'addressable' para o status de exigidas, com ênfase reforçada em criptografia, autenticação multifator, inventário de ativos incluindo sistemas de AI que tratam ePHI e prazos mais apertados de reporte de incidentes. Trate qualquer assistente de AI como ativo dentro do escopo para análise de risco, documente os fluxos de dados e confirme que seu runbook de resposta a incidentes atende às janelas de notificação mais curtas. Coordene com seu privacy officer as datas exatas de vigência e as expectativas de transição aplicáveis à sua organização, já que a postura de enforcement e eventuais extensões podem mudar após a publicação.

← Resources

USECASE · 2026-03-12

AI privada para saúde: workspaces alinhados ao HIPAA sem lock-in de nuvem

AI alinhada ao HIPAA não exige enviar PHI para um modelo de terceiros. Um workspace on-device-first com fallback BYOK opcional para nuvem, logs de auditoria, RBAC e um BAA assinado onde qualquer nuvem é tocada pode atender à maioria dos requisitos de entidades cobertas.

O que a HIPAA realmente exige de um assistente de AI

*Este artigo é orientação geral e não constitui aconselhamento jurídico ou de compliance; o privacy officer da sua entidade coberta tem a palavra final.*

A HIPAA foi escrita em torno do dado, não da ferramenta que o lê, então um assistente de AI é tratado como qualquer outro membro da força de trabalho ou business associate que toca informação protegida de saúde. A Privacy Rule governa usos e divulgações permitidas de PHI e o padrão do mínimo necessário. A Security Rule exige salvaguardas administrativas, físicas e técnicas, incluindo controle de acesso, controles de auditoria, integridade, segurança de transmissão e uma análise de risco documentada. A Breach Notification Rule estabelece o dever de notificar indivíduos afetados, o HHS e, em incidentes maiores, a mídia, quando PHI não protegida é divulgada sem autorização.

Recentes regulamentações do HHS sinalizaram que sistemas de AI que criam, recebem, mantêm ou transmitem ePHI devem ser inventariados e analisados quanto a risco como qualquer outro ativo, com criptografia em trânsito e em repouso, autenticação multifator e resposta tempestiva a incidentes. A obrigação não muda porque a entidade lendo o prontuário é um modelo.

Onde ChatGPT, Copilot e Gemini falham para PHI

Out-of-the-box, os tiers de consumidor de ChatGPT, Microsoft Copilot e Google Gemini não são apropriados para PHI. Assinaturas free e standard não vêm com um Business Associate Agreement, e prompts podem ser retidos ou usados para melhoria de modelo sob os termos default.

A nuance importante: cada fornecedor oferece configurações enterprise que podem ser cobertas por BAA. A OpenAI assina BAAs para a API e para o ChatGPT Enterprise ou Edu via contas geridas por vendas. A Microsoft oferece cobertura de BAA para o Azure OpenAI Service e certos tenants Microsoft 365 Copilot, embora o GitHub Copilot e outras superfícies de consumidor sejam excluídos. A Google suporta BAA para o Gemini dentro de tiers qualificantes do Workspace, mas exclui explicitamente o NotebookLM e a superfície Gemini-in-Chrome.

O risco prático é drift da força de trabalho. Um clínico colando um resumo de alta numa aba de chatbot grátis no navegador é, por padrão, uma divulgação fora de qualquer BAA, independente do que o contrato enterprise diga.

A arquitetura on-device-first: modelo local + BYOK opt-in

Uma arquitetura que minimiza a exposição HIPAA inverte o padrão SaaS usual. O modelo default roda no dispositivo do usuário, tipicamente um LLM open-weights quantizado servido localmente, então prompts e generations nunca deixam o endpoint. Quando um clínico precisa de um modelo de raciocínio mais forte, o workspace pode fazer fallback para um provedor de nuvem usando a chave de API da própria organização, sob o BAA daquele provedor, com opt-in explícito por requisição ou por workspace.

Esse é o padrão por trás do osFoundry: um runtime llama.cpp local é o default de primeira classe, e qualquer chamada de nuvem é bring-your-own-key contra um fornecedor que a entidade coberta contratou independentemente. Não há um pool de inferência multi-tenant compartilhado entre o clínico e o modelo.

O benefício de compliance é concreto. Workloads que podem ser tratadas localmente nunca geram um evento de divulgação em nuvem. Workloads que exigem capacidade de nuvem são rastreadas, atribuíveis e sujeitas ao BAA que a entidade coberta já validou.

Auditoria, RBAC, DLP e mínimo necessário na prática

Salvaguardas técnicas são onde a maioria dos pilotos de AI falha na primeira auditoria interna. Quatro controles fazem o trabalho pesado.

Logs de auditoria precisam capturar quem deu o prompt, qual modelo respondeu, quais fontes de dados foram anexadas e o que foi retornado, com armazenamento à prova de adulteração e uma janela de retenção compatível com sua política de retenção de registros. RBAC deve atrelar acesso a modelo, acesso a dataset e acesso a ferramentas ao papel funcional, para que uma conta de recepção não consiga consultar um corpus de oncologia e um papel de billing não possa disparar um gerador de notas clínicas.

DLP pertence à fronteira do prompt. Redação baseada em padrões e classificadores de identificadores antes de qualquer chamada à nuvem aplica o padrão do mínimo necessário de forma programática, não apenas por treinamento. Residência de dados por workspace evita que dados de uma clínica se misturem com os de outra.

Nada disso é invenção AI-específica, mas juntos são o que permite a um privacy officer assinar a aprovação de um modelo tocando um prontuário.

Três fluxos: notas de admissão, prior auth, Q&A operacional

Notas de admissão e de consulta são a workload local de maior valor. Um clínico dita, um modelo local rascunha uma nota estruturada e nada deixa o dispositivo até o clínico assinar e o EHR receber um registro postado pela interface existente. A latência é aceitável em um notebook moderno e a superfície de PHI é apenas o dispositivo.

Prior authorization se beneficia de retrieval. O modelo monta um rascunho de carta a partir do prontuário do paciente e dos documentos de política médica publicados pelo pagador, com citações. Se um modelo mais forte de nuvem for invocado para drafting, o trecho do prontuário é deidentificado na fronteira do prompt e reidentificado no dispositivo após a resposta retornar.

Q&A operacional sobre políticas de RH, códigos de billing e SOPs raramente precisa de PHI e pode rodar inteiramente em modelos locais ou de nuvem com DLP bloqueando PHI. Dividir workloads assim mantém o tráfego de maior risco no dispositivo e o de menor risco na nuvem.

BAA e risco de fornecedor: o que perguntar a qualquer fornecedor de AI

Antes de assinar, percorra uma checklist curta. O fornecedor vai executar um BAA cobrindo exatamente a superfície de produto que você vai usar, e não um produto irmão? Quais endpoints, modelos e consoles específicos estão no escopo, e quais são excluídos por escrito? Qual o default de retenção de dados para prompts, completions, embeddings e artefatos de fine-tuning, e dá para zerar?

Peça a lista de subprocessadores e o mecanismo de notificação quando ela mudar. Confirme criptografia em trânsito e em repouso, postura de gerenciamento de chaves e se chaves gerenciadas pelo cliente estão disponíveis. Exija prazos de notificação de violação que permitam você cumprir sua própria obrigação de notificar pacientes em 60 dias com folga.

Solicite o SOC 2 Type II mais recente e qualquer atestação HITRUST, a cadência de testes de penetração e o runbook de resposta a incidentes. Por fim, confirme por escrito que o fornecedor não vai treinar modelos compartilhados com os dados do seu tenant.

Rollout piloto em 30 dias

Semana um é escopo. O privacy officer, um sponsor clínico e o TI escolhem dois ou três fluxos, escrevem o diagrama de fluxo de dados e atualizam a análise de risco. Identifiquem quais passos podem ser só-locais e quais exigem nuvem e confirmem a cobertura BAA para qualquer superfície de nuvem.

Semana dois é provisionamento. Suba o workspace com papéis RBAC mapeados para títulos funcionais, habilite logging de auditoria para seu SIEM, configure regras de redação DLP na fronteira do prompt e carregue o modelo local nos dispositivos do piloto. Documente o plano de rollback.

Semana três é um piloto supervisionado com cinco a dez clínicos. Acompanhe tempo economizado, taxa de erro contra um gold set revisado por humano e quaisquer disparos de DLP. Faça uma revisão de meio de semana com o privacy officer.

Semana quatro é o go ou no-go. Atualize material de política e treinamento, finalize a divulgação de uso de AI aos pacientes onde aplicável e decida critérios de expansão para a próxima coorte.

Frequently asked questions

Rodar um modelo on-device elimina totalmente a necessidade de um BAA?: Para a inferência local em si, sim, porque nenhum PHI é divulgado a um terceiro. Você ainda precisa considerar o papel do fornecedor do software. Se o runtime local, o shell do workspace ou qualquer plano de gerenciamento puder receber PHI via telemetria, logs ou sessões de suporte, o fornecedor atua como business associate e um BAA é apropriado. O padrão seguro é confirmar por escrito que o fornecedor não recebe PHI do dispositivo por padrão e desativar qualquer telemetria opcional que possa carregar conteúdo. Fallbacks em nuvem sempre exigem um BAA com o provedor do modelo em nuvem.
Podemos usar ChatGPT, Copilot ou Gemini em fluxos HIPAA?: Sim, mas apenas nas configurações enterprise específicas que o fornecedor concordou em cobrir sob BAA, e apenas nas superfícies explicitamente nomeadas nesse acordo. A OpenAI cobre a API e certos tenants ChatGPT Enterprise ou Edu. A Microsoft cobre Azure OpenAI Service e tenants Copilot qualificantes. A Google cobre o Gemini em tiers qualificantes do Workspace, excluindo NotebookLM e Gemini no Chrome. Tiers free e standard de consumidor não são cobertos. O problema mais difícil é o comportamento da força de trabalho: bloquear as superfícies de consumidor na camada de rede ou navegador importa tanto quanto o contrato.
Como logs de auditoria diferem para AI versus acesso tradicional ao EHR?: Logs de auditoria tradicionais do EHR capturam acesso a registros por usuário, horário e ação. Logs de auditoria de AI precisam capturar o prompt, o modelo e a versão, o contexto recuperado, a resposta, o usuário, o workspace e quaisquer ferramentas que o modelo invocou. Também precisam capturar decisões de roteamento para nuvem quando um fallback BYOK é usado. Retenha esses logs junto com os do EHR sob a mesma política de retenção, armazene em um repositório à prova de adulteração e alimente o mesmo SIEM que seu time de segurança já monitora, de modo que a atividade de AI faça parte da resposta normal a incidentes e não de um silo paralelo.
E sobre as mudanças de 2026 na Security Rule?: Recentes regulamentações do HHS movem várias salvaguardas antes 'addressable' para o status de exigidas, com ênfase reforçada em criptografia, autenticação multifator, inventário de ativos incluindo sistemas de AI que tratam ePHI e prazos mais apertados de reporte de incidentes. Trate qualquer assistente de AI como ativo dentro do escopo para análise de risco, documente os fluxos de dados e confirme que seu runbook de resposta a incidentes atende às janelas de notificação mais curtas. Coordene com seu privacy officer as datas exatas de vigência e as expectativas de transição aplicáveis à sua organização, já que a postura de enforcement e eventuais extensões podem mudar após a publicação.