Conformidade HIPAA e IA: o que um BAA não cobre

O essencial

• O BAA, o contrato que a HIPAA impõe perante fornecedores, reparte a responsabilidade sobre o dado. Nada diz sobre a exatidão, a equidade ou a segurança clínica do modelo, que é onde se concentra a maior parte do risco.
• A HIPAA abdicou de regular a inteligência artificial. A proposta de revisão da Security Rule apresentada em janeiro de 2025 limita-se a um pedido de contributos sobre IA e não introduz qualquer garantia específica.
• A regra que vincula verdadeiramente a IA clínica nos Estados Unidos chama-se Section 1557. As suas obrigações sobre ferramentas de apoio à decisão assistencial são exigíveis desde 1 de maio de 2025.
• A HTI-1 obriga o software de saúde certificado a expor 31 atributos de origem para o apoio à decisão preditivo, que servem também de questionário de diligência devida já preparado para qualquer fornecedor de IA.
• Uma conformidade HIPAA aplicada à IA sustenta-se quando um único conjunto de controlos responde em simultâneo à HIPAA, à Section 1557, à HTI-1, à FDA e, para quem opera dos dois lados do Atlântico, ao Regulamento europeu da IA.

O que a HIPAA cobre realmente quando a IA toca em dados de saúde

Quase todos os conteúdos dedicados à conformidade HIPAA e à IA começam no mesmo ponto: escolher um fornecedor disposto a assinar um BAA, verificar a cifragem, garantir que a ferramenta não treina os seus modelos com as vossas consultas. O conselho está certo e é também a menor parte do problema. A HIPAA compõe-se de dois blocos operacionais. A Privacy Rule regula a forma como as informações de saúde protegidas, as chamadas PHI, podem ser usadas e divulgadas. A Security Rule regula as garantias administrativas, físicas e técnicas aplicáveis à sua forma eletrónica. Um fornecedor de IA que receba, armazene ou trate PHI por conta de uma entidade abrangida torna-se business associate, e ambas as regras o alcançam através do contrato. O que a HIPAA não faz é regular o modelo. O texto nada diz sobre a proveniência dos dados de treino, sobre o desempenho por subpopulação, sobre a deriva de calibração ou sobre a adequação clínica de uma recomendação. Essas questões pertencem a outros regimes, e são precisamente elas que determinam se uma utilização de IA prejudica um doente. Duas zonas de fronteira pesam mais do que as equipas imaginam. A primeira é a anonimização. Os dados tratados pelo método Safe Harbor ou certificados por Expert Determination saem do perímetro da HIPAA, razão pela qual tantos projetos de IA em saúde assentam em corpora anonimizados. Os modelos de grande dimensão corroem esse conforto, porque a memorização e o cruzamento de elementos em texto clínico rico podem devolver um conjunto de dados à identificabilidade por caminhos que a avaliação original nunca considerou. Se o vosso certificado de anonimização é anterior ao modelo, não cobre o modelo. A segunda zona de fronteira é o próprio perímetro. A HIPAA aplica-se em função de quem detém o dado, e não do grau de sensibilidade do dado. Um verificador de sintomas dirigido ao público, uma aplicação de bem-estar ou um assistente conversacional destinado diretamente ao doente, se não contratarem com nenhuma entidade abrangida, ficam em regra totalmente fora da HIPAA e recaem antes sob o FTC Act e a Health Breach Notification Rule. O dado de saúde não transporta a HIPAA consigo. É a relação contratual que o faz. Esta distinção reproduz a que ordena todas as restantes avaliações de impacto realizadas na vossa organização, e lê-se com proveito ao lado das diferenças entre avaliação de impacto sobre a privacidade, AIPD e FRIA, uma vez que um programa de IA em saúde raramente precisa de apenas uma delas.

O BAA é necessário e não é suficiente

Um business associate agreement cumpre três funções úteis. Vincula o fornecedor à Privacy Rule e à Security Rule, delimita as utilizações permitidas das PHI e obriga-o a notificar violações de dados. Dispensar esse contrato é indefensável. Quando um fornecedor trata indevidamente PHI sem contrato assinado, o Office for Civil Rights considera a ausência do acordo uma infração autónoma, que acresce a tudo o resto. O histórico sancionatório confirma que a questão merece seriedade. Em 23 de abril de 2026, o OCR anunciou acordos com quatro entidades por violações associadas a ransomware, num total de 1 165 000 dólares e mais de 427 000 pessoas afetadas, cada um acompanhado de um plano de ações corretivas de dois anos sob monitorização. A supervisão de fornecedores está na base de uma parcela crescente destas coimas, e o envolvimento de terceiros nas violações de dados de saúde duplicou de 15 para 30 por cento em termos homólogos em 2025. Assinem, portanto, o contrato. E reparem depois no que ele não vos comprou. Um BAA assinado não vos diz que versão do modelo está em produção. Não regista os dados com que o modelo foi treinado, nem se a população de treino se assemelha à vossa população assistida. Não mede o desempenho por idade, sexo, língua ou regime de cobertura. Não deteta que um fornecedor tenha substituído em silêncio o seu modelo de base numa entrega trimestral. E não produz um único documento que possam entregar a um auditor que pergunte por que motivo um determinado doente recebeu uma determinada recomendação. Estas lacunas são trabalho de governação, e não de compras. Pertencem ao mesmo lugar que o resto do vosso modelo de conformidade e governação: um inventário, um responsável, uma classificação de risco, um resultado de teste, uma cadência de monitorização e um registo de decisão. O contrato reparte a culpa depois da falha. A governação torna a falha menos provável e demonstrável nos dois sentidos.

Onde a HIPAA para: a reforma de 2025 contornou a IA

Quem espera que seja a própria HIPAA a responder à questão da IA fará bem em ler o que aconteceu no último procedimento normativo. Em 27 de dezembro de 2024, o Department of Health and Human Services anunciou uma proposta de modernização da Security Rule, publicada no Federal Register em 6 de janeiro de 2025. Trata-se da primeira revisão substancial desse texto em cerca de duas décadas. Nos fundamentos de cibersegurança a proposta é ambiciosa: inventários de ativos, mapeamento de rede, autenticação multifator obrigatória, requisitos de cifragem e eliminação de boa parte da flexibilidade que permitia tratar as garantias como facultativas. Quanto à inteligência artificial, quase nada faz. A IA surge apenas num pedido de contributos, ao lado da computação quântica e da realidade virtual e aumentada, no qual se pergunta ao público como deveria a Security Rule tratar as PHI eletrónicas usadas por tecnologias emergentes. O OCR teve a oportunidade de fixar regras de base para a IA e a aprendizagem automática e preferiu recolher opiniões. O prazo encerrou em 7 de março de 2025 com perto de 5000 contributos, e o texto definitivo continua por publicar. A leitura operacional é simples. Quando a regra final chegar, elevará o vosso patamar mínimo de segurança, o que ajuda. Não vos dirá como validar um modelo, como testar desempenhos desiguais, nem que provas conservar sobre uma recomendação algorítmica. Reduzir a obrigação em matéria de IA à HIPAA equivale a pedir a uma lei escrita para arquivos que responda sobre inferência. O quadro completo distribui-se por vários regimes ao mesmo tempo, e é por isso que o mapa global das leis de IA interessa mesmo a um prestador exclusivamente norte-americano.

Section 1557: a regra que vincula mesmo a sua IA clínica

Eis a regra que quase nenhum guia sobre conformidade HIPAA para a IA menciona, e já está em vigor. A Section 1557 do Affordable Care Act proíbe a discriminação com base em raça, cor, origem nacional, sexo, idade e deficiência nos programas e atividades de saúde que recebem financiamento federal. O HHS aprovou uma regra definitiva em 6 de maio de 2024, em vigor desde 5 de julho de 2024, que estende expressamente esses princípios àquilo que designa por ferramentas de apoio à decisão assistencial. A definição é deliberadamente ampla. Abrange ferramentas, mecanismos, métodos e tecnologias, automatizados ou não, usados para apoiar uma decisão clínica, incluindo por isso algoritmos clínicos, pontuações de risco, lógicas de triagem e modelos de aprendizagem automática. As entidades abrangidas dispuseram de 300 dias a contar da entrada em vigor para se adaptarem às disposições sobre apoio à decisão, o que fixou o prazo em 1 de maio de 2025. A obrigação tem duas partes. Primeiro, realizar esforços razoáveis para identificar as ferramentas de apoio à decisão em uso que empreguem raça, cor, origem nacional, sexo, idade ou deficiência como variável de entrada. Segundo, realizar esforços razoáveis para mitigar o risco de discriminação daí decorrente. Ambas as obrigações são contínuas. Não se trata de uma declaração que se assina uma vez e se arquiva. Coloquem estes dois verbos ao lado do conselho de compra que domina os resultados de pesquisa. Nenhuma cifragem identifica uma variável de entrada. Nenhum BAA mitiga uma disparidade. A regra alcança o modelo, e o dever recai sobre a entidade abrangida, não sobre o fornecedor.

Como se apresentam os esforços razoáveis, em prova

As autoridades não aceitam intenções. Aceitam registos. Para cada ferramenta de apoio à decisão clínica, um processo defensável contém uma ficha de inventário com designação, versão e finalidade clínica; uma revisão documentada das variáveis de entrada que assinale qualquer característica protegida ou o seu substituto imediato, como código postal, língua preferida ou situação de cobertura; resultados de desempenho desagregados pelos subgrupos que a regra enumera; uma decisão de mitigação escrita e fundamentada, incluindo a de aceitar um risco residual; uma cadência de monitorização com limiares definidos; e um responsável designado pelo nome. Este conjunto probatório responde ainda à maior parte do que pedirá um auditor de IA, e completa-se naturalmente com uma posição clara sobre o lugar do clínico no circuito. Numa ferramenta consultiva, a diferença entre supervisão humana no circuito e sobre o circuito determina exatamente se uma medida de mitigação é real ou apenas nominal.

HTI-1 e a camada de transparência dentro do processo clínico

Enquanto o OCR abdicava de regular os modelos, o programa de certificação do software de saúde fazia-o de qualquer modo. A regra definitiva HTI-1, aprovada pelo Assistant Secretary for Technology Policy, antes ONC, criou um critério de certificação dedicado às Decision Support Interventions. Introduz os primeiros requisitos de transparência do género sobre algoritmos preditivos integrados em software de saúde certificado. Os sistemas certificados têm de apresentar ao clínico atributos de origem estruturados: 13 para o apoio à decisão baseado na evidência e 31 para o apoio à decisão preditivo. São esses 31 atributos a parte verdadeiramente interessante. Descrevem a finalidade e a utilização prevista da intervenção, o processo de desenvolvimento, os dados usados para treinar e validar o modelo subjacente, a forma como o desempenho foi medido, o modo como a equidade foi avaliada e a manutenção da intervenção ao longo do tempo. O objetivo declarado consiste em permitir que uma organização julgue se uma intervenção preditiva é equitativa, apropriada, válida, eficaz e segura, um teste que o programa resume na sigla FAVES. Daqui decorrem duas consequências para qualquer programa de conformidade HIPAA aplicado à IA. Em primeiro lugar, se a vossa ferramenta preditiva reside em software de saúde certificado, essa documentação já existe e têm direito a obtê-la. Muitas equipas de conformidade nunca a solicitaram. Em segundo lugar, e com maior utilidade prática, esses 31 atributos formam um questionário de fornecedores diretamente reutilizável para a IA que não está certificada por ninguém. Um fornecedor incapaz de descrever a sua população de treino, o seu método de validação ou a sua avaliação de equidade está a dizer-vos alguma coisa, e a administração federal já decidiu que essas perguntas têm resposta. Usem-nos ao decidir se uma capacidade de IA pertence à vossa plataforma governada ou ao conjunto disperso de ferramentas que a rodeia.

A FDA e a fronteira entre funcionalidade e dispositivo

Parte da IA clínica constitui um dispositivo médico regulado, e a fronteira é mais ténue do que a maioria dos compradores supõe. A FDA tinha autorizado mais de 1350 dispositivos com IA no início de 2026, aproximadamente o dobro do total de 2022. Um software que analisa uma imagem, calcula uma pontuação de risco para uma patologia identificada ou conduz a uma conclusão diagnóstica entra frequentemente nessa categoria. Um software que resume uma nota, redige uma carta ou encaminha uma mensagem, em regra não. A questão decisiva diz respeito à finalidade declarada, ou seja, diagnosticar, tratar, mitigar ou prevenir uma doença, e à possibilidade de o clínico apreciar de forma independente o fundamento da recomendação. A aprendizagem automática pressiona a regulação dos dispositivos num ponto preciso: um dispositivo autorizado deve manter-se conforme à autorização, ao passo que um modelo tende a mudar. A resposta da FDA chama-se Predetermined Change Control Plan e permite ao fabricante obter autorização prévia para um perímetro definido de alterações futuras do modelo, dentro da utilização prevista aprovada. A adoção permanece escassa: cerca de 10 por cento das autorizações de IA de 2025 incluíam um plano aprovado. Para quem implementa a tecnologia, daqui resulta um controlo concreto. Perguntem a cada fornecedor de IA clínica se o modelo está sujeito a um plano de controlo de alterações, como serão informados de uma atualização do modelo e o que acontece às vossas provas de validação quando o modelo muda por baixo delas. Um retreino silencioso pode retirar um produto da sua utilização prevista autorizada e da vossa própria cobertura de testes no mesmo momento. É um problema de medição e monitorização, que corresponde diretamente às funções Measure e Manage do NIST AI Risk Management Framework.

Se também opera na Europa: a camada do Regulamento da IA

Muitas organizações que lidam com PHI norte-americanas não são organizações norte-americanas. Fornecedores europeus de saúde digital, sociedades de investigação por contrato, fabricantes de dispositivos e grupos hospitalares com parcerias de investigação do outro lado do Atlântico suportam obrigações HIPAA por contrato e obrigações europeias por lei. Para eles, a conformidade HIPAA é apenas o rés do chão. Uma IA que seja um dispositivo médico, ou que constitua um componente de segurança de um, é automaticamente de alto risco nos termos do Regulamento da IA. Na prática, os dispositivos das classes IIa, IIb e III do MDR e das classes A a D do IVDR enquadram-se normalmente na categoria de alto risco. Os dispositivos da classe I do MDR, que dispensam organismo notificado, não chegam lá por essa via, embora possam ser abrangidos se desempenharem uma função enumerada no anexo III. O anexo III acrescenta ainda duas utilizações próximas da prestação de cuidados, de alto risco sem serem dispositivos: o atendimento de chamadas de emergência e a triagem de doentes em contexto de urgência, e a avaliação de risco e a fixação de preços nos seguros de vida e de saúde. Seguradoras e plataformas de triagem partem muitas vezes do princípio de que o Regulamento da IA é um assunto de dispositivos. Não é. Os prazos mudaram em 2026. Após o Digital Omnibus adotado em junho de 2026, as obrigações aplicáveis aos sistemas de alto risco autónomos do anexo III vigoram a partir de 2 de dezembro de 2027, ao passo que a IA alojada num dispositivo regulado pelo MDR ou pelo IVDR dispõe de prazo até 2 de agosto de 2028. Em março de 2026, os dispositivos médicos com IA continuavam a ser certificados exclusivamente ao abrigo do MDR e do IVDR, não lhes sendo ainda aplicáveis as obrigações de alto risco do Regulamento. Esse desfasamento é tempo de preparação, e não uma dispensa. Para as organizações portuguesas vale a pena recordar que a CNPD se tem pronunciado sobre tratamentos automatizados em contexto clínico e que os Serviços Partilhados do Ministério da Saúde definem requisitos próprios de interoperabilidade e segurança para as soluções que ligam ao Sistema Nacional de Saúde. As avaliações já produzidas nesse âmbito cobrem boa parte do que o Regulamento virá a exigir. Como referência sobre as obrigações em si, mantêm-se centrais os deveres de fornecedores e responsáveis pela implantação.

Construir a conformidade HIPAA da IA sobre um único conjunto de controlos

Quatro regimes, quatro vocabulários, uma só série de perguntas de fundo. O que é este sistema, quem responde por ele, no que pode falhar, como daríamos por isso e se conseguimos prová-lo. Manter quatro programas de conformidade em paralelo é a forma como as organizações de saúde queimam um ano e mesmo assim chumbam a auditoria. Comecem por um inventário. Todo o sistema de IA que toque em doentes ou em informação de saúde protegida recebe uma ficha, incluindo os que ninguém declarou. Os assistentes de transcrição adquiridos por um único serviço, uma funcionalidade de resumo ativada dentro de uma plataforma já instalada e os clínicos que colam notas num assistente conversacional de consumo entram todos no perímetro, e os três casos são frequentes. O problema da shadow AI pesa mais na saúde do que em qualquer outro sector, porque o benefício clínico é imediato enquanto o circuito de aquisição é lento. Classifiquem depois cada sistema com quatro perguntas binárias. Trata informação de saúde protegida? Influencia uma decisão assistencial? Reside dentro de software de saúde certificado? É, ou contém, um dispositivo regulado? As respostas determinam que obrigações se ativam.

Sustentem o conjunto com um sistema de gestão e não com uma folha de cálculo. A ISO/IEC 42001 fornece a estrutura certificável: política, funções, tratamento do risco, auditoria interna, revisão pela gestão. O NIST AI Risk Management Framework fornece o ciclo de trabalho, ou seja, Govern, Map, Measure e Manage. Nenhum dos dois é uma regulamentação de saúde norte-americana, e é precisamente por isso que funcionam como camada de ligação: são o lugar onde uma prova pode ser produzida uma só vez e oposta a várias obrigações. É o mesmo argumento que sustenta qualquer quadro de governação da IA sério, aplicado a um sector onde as consequências chegam mais depressa.

Perguntas frequentes

É possível usar IA cumprindo a HIPAA? Sim. A HIPAA não proíbe a inteligência artificial, e nada na Privacy Rule ou na Security Rule impede uma entidade abrangida de tratar informação de saúde protegida com um modelo. O que a HIPAA exige é que o fornecedor seja integrado como business associate mediante contrato escrito, que as garantias se apliquem às PHI eletrónicas envolvidas e que a utilização seja permitida pela Privacy Rule. Uma revisão de conformidade HIPAA aplicada à IA deve, por isso, partir da finalidade clínica e não do fornecedor, porque a dificuldade maior está em satisfazer as restantes regras aplicáveis, desde logo a Section 1557. O ChatGPT é compatível com a HIPAA para uso em saúde? A versão de consumo não é. Um modelo nunca é conforme por si próprio; conforme pode ser uma implementação. A conformidade depende de o fornecedor assinar um BAA, de as consultas e respostas ficarem excluídas do treino, da política de conservação e de a configuração suportar controlo de acessos e registo de auditoria. As ofertas empresariais e as API dos grandes fornecedores podem sustentar uma implementação conforme. As interfaces gratuitas de consumo em regra não, razão pela qual colar notas clínicas num assistente público figura hoje entre as violações mais comuns do sector. Um BAA assinado torna uma ferramenta de IA conforme à HIPAA? Não. Um business associate agreement é uma repartição contratual de obrigações sobre o dado. Não avalia o modelo, não verifica a exatidão entre subpopulações de doentes e não cria qualquer registo do motivo pelo qual uma recomendação concreta foi formulada. As autoridades nunca trataram um contrato assinado como prova de que as garantias foram efetivamente implementadas, e as obrigações da Section 1557 recaem sobre a entidade abrangida independentemente do que o fornecedor aceitou. Qual era o prazo da Section 1557 para as ferramentas de apoio à decisão? A regra definitiva foi aprovada em 6 de maio de 2024 e entrou em vigor em 5 de julho de 2024. As entidades abrangidas dispuseram de 300 dias a contar dessa entrada em vigor para se adaptarem às disposições sobre ferramentas de apoio à decisão assistencial, o que fixou o prazo em 1 de maio de 2025. Essas obrigações estão agora ativas e são contínuas, pelo que uma organização que nunca tenha revisto os seus algoritmos clínicos à procura de variáveis protegidas já acumula atraso. A HIPAA aplica-se se a minha IA usar apenas dados anonimizados? Os dados corretamente anonimizados ficam fora do âmbito da HIPAA, seja pela via do Safe Harbor, seja por Expert Determination. A cautela impõe-se porque a anonimização é uma propriedade de um conjunto de dados num dado momento, e não um estado permanente. Texto clínico rico, combinações de quase identificadores e a memorização por parte do modelo podem todos elevar de novo o risco de reidentificação. Se a avaliação é anterior à entrada dos dados numa cadeia de tratamento assente em modelos, mandem revê-la face a essa cadeia em vez de presumirem que se mantém válida. Quem responde quando um fornecedor de IA provoca uma violação de dados de saúde? Podem responder ambas as partes. Os business associates respondem diretamente ao abrigo da HIPAA pelas suas próprias infrações, e as entidades abrangidas continuam responsáveis pela escolha e pela supervisão dos seus fornecedores. Sem contrato, a entidade abrangida expõe-se a uma constatação autónoma só por essa falha. Para além da HIPAA, a responsabilidade por uma recomendação clínica lesiva rege-se pelo direito da responsabilidade médica e do produto, onde a unidade prestadora raramente fica de fora do processo. O vosso processo de notificação de incidentes deve, portanto, pressupor exposição partilhada. Uma organização de saúde europeia que serve doentes norte-americanos precisa da HIPAA e do Regulamento da IA em simultâneo? Na maioria dos casos sim, e perante autoridades distintas. A HIPAA alcança um operador europeu através do BAA que o liga a uma entidade abrangida norte-americana. O Regulamento da IA, o RGPD e o MDR ou o IVDR alcançam-no pelo direito da União. As obrigações sobrepõem-se largamente em gestão de risco, registo, documentação e supervisão humana, pelo que a via eficiente consiste em mapear um único conjunto de controlos sobre ambos os regimes, em vez de manter dois programas em paralelo.

Conclusão

Os resultados de pesquisa sobre conformidade HIPAA e IA descrevem uma decisão de compra. A obrigação real descreve um modo de funcionamento. A HIPAA rege o dado. A Section 1557 rege a decisão, e fá-lo desde maio de 2025. A HTI-1 rege a informação prestada. A FDA rege o dispositivo. Para quem opera dos dois lados do Atlântico, o Regulamento da IA rege o sistema. Nenhuma destas regras é por si só a resposta, e nenhuma se contenta com um contrato assinado acompanhado de uma promessa de cifragem. O que as liga não tem nada de espetacular e é inteiramente alcançável: conhecer cada sistema de IA em serviço, classificá-lo com honestidade, testá-lo face às características que a lei enumera, deixar por escrito o que foi decidido e porquê, e vigiá-lo depois da entrada em funcionamento. É isso a governação da IA, e na saúde faz a diferença entre um programa defensável e uma boa intenção.