Implantação de LLMs em Setores Regulamentados: Roteiro HIPAA, SOC2 e GDPR para 2026

O desafio técnico de implementar um modelo de linguagem grande em uma empresa regulada não é, principalmente, um problema de aprendizado de máquina. Os modelos existem, funcionam e são capazes o suficiente para casos de uso clínicos, financeiros e de seguros sérios. O desafio é a arquitetura em torno do modelo: quem controla os dados, para onde eles fluem, o que é registrado, quem aprovou o fornecedor e como a equipe de conformidade pode demonstrar tudo isso a um regulador.

A Medtronic, com 90.000 funcionários e portfólios de dispositivos regulados pela FDA, executa IA em produção. A Innovaccer processa informações de saúde protegidas em escala dentro de uma plataforma de inteligência clínica governada. A Aviva, operando sob o GDPR do Reino Unido, usa IA em fluxos de trabalho de seguros. A Siemens Healthineers tem IA implementada em várias jurisdições regulatórias simultaneamente. Estes não são provas de conceito. São implementações de produção em escala empresarial que passaram por revisão legal, de conformidade e de segurança de TI.

A arquitetura que tornou cada uma dessas implementações possível é o tema deste guia. Ele abrange os requisitos regulatórios específicos para saúde, serviços financeiros e seguros, as decisões técnicas que esses requisitos impulsionam e como uma implementação governada e isolada por VPC se parece na prática para equipes que se preparam para passar pelo mesmo processo de aprovação.

O Que Diferencia a Implementação de IA em Setores Regulados

As diferenças entre a implementação de IA regulada e não regulada não são principalmente técnicas. Os modelos subjacentes são os mesmos. A diferença reside na obrigação legal, na estrutura de responsabilização e na carga de auditoria, e essas coisas mudam as decisões de arquitetura desde o início.

• As regras de tratamento de dados são definidas externamente. Em ambientes regulados, os usos permitidos dos dados são definidos por estatuto, não por julgamento de engenharia. Um sistema de IA que envia registros de pacientes para uma API externa pode ser tecnicamente elegante e, simultaneamente, constituir uma violação do HIPAA. A sofisticação técnica da implementação é irrelevante para o padrão legal. O que importa é para onde os dados foram e se eles tinham autorização para ir para lá.

• Sistemas de IA estão agora no escopo de auditoria regulatória. Reguladores em saúde, serviços financeiros e seguros esperam cada vez mais que as organizações documentem quais dados seus sistemas de IA acessaram, quais decisões esses sistemas influenciaram, quem autorizou a implementação e como foi o processo de supervisão humana. A regra de segurança do HIPAA exige salvaguardas apropriadas, incluindo criptografia em repouso e em trânsito, com base na avaliação de risco. O ônus de demonstrar conformidade recai sobre a organização em todos os momentos.

• Seu fornecedor de IA está no seu escopo de conformidade. Qualquer fornecedor que cria, recebe, mantém ou transmite informações de saúde protegidas em seu nome é um Parceiro de Negócios (Business Associate) sob o HIPAA e legalmente exige um BAA assinado antes que as PHI toquem sua infraestrutura. A maioria das ofertas padrão de API de LLM públicas não são cobertas por BAA por padrão e exigem acordos empresariais ou modelos de implementação alternativos. AWS Bedrock e Azure OpenAI Service oferecem opções elegíveis para BAA com requisitos de configuração específicos, mas a elegibilidade não é o mesmo que conformidade.

• A residência de dados pode eliminar completamente as opções de SaaS. Uma seguradora europeia que processa dados pessoais cobertos pelo GDPR não pode legalmente rotear esses dados através de infraestrutura baseada nos EUA sem um acordo de Cláusulas Contratuais Padrão ou outro mecanismo de transferência de GDPR aprovado. Muitos produtos de gateway de IA SaaS são baseados nos EUA, o que significa que a documentação de transferência de dados da UE para os EUA deve ser concluída antes que qualquer implementação técnica comece. Para algumas organizações e alguns tipos de dados, isso elimina completamente a opção de SaaS.

• Trilhas de auditoria não são opcionais, e as estruturadas são melhores. Todo acesso a dados regulados, incluindo acesso assistido por IA, deve gerar um registro de auditoria. Para o HIPAA, esse registro deve incluir carimbo de data/hora, identidade do acessador, a ação realizada e uma referência à PHI acessada. Sistemas de IA que geram esses registros automaticamente em formato JSON estruturado são implementáveis. Sistemas que exigem correlação manual de logs após o fato criam lacunas de conformidade que os reguladores não aceitam como equivalentes.

Saúde: Requisitos HIPAA para Implementações de LLM

O HIPAA abrange qualquer sistema que lida com Informações de Saúde Protegidas (PHI). Uma implementação de LLM está no escopo se o modelo puder receber PHI em prompts, se a PHI aparecer no contexto de geração aumentada por recuperação passado para o modelo, ou se as saídas do modelo alimentarem decisões sobre pacientes individuais. Resumo de notas clínicas, análise de registros de pacientes, ferramentas de assistência diagnóstica e suporte à autorização prévia se enquadram dentro deste limite.

Três regras do HIPAA moldam diretamente a arquitetura de implementação de LLM. A Regra de Privacidade governa para que a PHI pode ser usada e quem pode acessá-la, incluindo o padrão de mínimo necessário que limita a exposição de dados ao que é exigido para a tarefa específica. A Regra de Segurança exige salvaguardas administrativas, físicas e técnicas para PHI eletrônica, incluindo controles de acesso, registro de auditoria e segurança de transmissão. A Regra de Notificação de Violação estabelece o que acontece quando os controles falham. Todas as três têm requisitos de implementação técnica que se manifestam na forma como a infraestrutura de IA é projetada, e não apenas nos documentos de política.

Isolamento de PHI: Por que a maioria das APIs de LLM em nuvem não são adequadas para casos de uso clínicos

• As ofertas padrão de API para consumidores da OpenAI, Anthropic e Google geralmente não são projetadas para cargas de trabalho regulamentadas pela HIPAA e tipicamente não fornecem Acordos de Associado Comercial (BAAs) para seus endpoints públicos. Quando PHI é transmitida a um serviço de terceiros que atua como associado comercial sem um BAA em vigor, isso constitui uma violação de conformidade com a HIPAA. Este é um dos modos de falha mais comuns em implantações iniciais de IA empresarial que avançam mais rapidamente do que seus processos de governança de fornecedores.

• AWS e Microsoft fornecem Acordos de Associado Comercial HIPAA que cobrem serviços elegíveis específicos dentro de suas plataformas. A AWS inclui serviços elegíveis em seu BAA padrão, enquanto a Microsoft oferece cobertura por meio de seu Adendo de Proteção de Dados de Serviços Online. No entanto, a conformidade depende do uso apenas de serviços abrangidos e de sua configuração correta. Criptografia em repouso e em trânsito, registro de auditoria e controles IAM de privilégio mínimo são necessários. Assinar um BAA é um pré-requisito, não o estado final da conformidade.

• Para casos de uso clínicos envolvendo PHI, a implantação de modelos isolados por VPC ou auto-hospedados oferece a fronteira arquitetônica mais limpa. Quando os modelos são executados dentro da própria conta de nuvem da organização, a PHI permanece dentro do perímetro empresarial e não é exposta a provedores de modelos externos. Isso elimina a necessidade de um BAA separado com um fornecedor de API de modelo de terceiros, embora um BAA com o provedor de nuvem subjacente (por exemplo, AWS ou Azure) continue sendo exigido como parte da postura geral de conformidade.

• Para organizações que precisam usar APIs de modelos externos em cenários limitados, a mascaramento ou desidentificação de dados pode ser um padrão viável. Campos sensíveis são removidos ou tokenizados antes que a solicitação seja enviada, e reconstruídos apenas dentro do ambiente controlado após o retorno da resposta. Para que isso seja compatível, a transformação deve garantir que nenhuma PHI identificável seja exposta ao serviço externo, e o processo deve ser documentado, validado e demonstrável aos auditores como parte dos controles de conformidade da organização.

Requisitos de Log de Auditoria HIPAA para Sistemas de IA

• A Regra de Segurança da HIPAA exige que entidades cobertas e associados comerciais implementem controles de auditoria que registrem e examinem a atividade em sistemas que lidam com PHI eletrônica. Na prática, isso significa que os sistemas devem gerar logs que capturem eventos de acesso de forma a apoiar a investigação e a responsabilização. Embora a regulamentação não prescreva campos exatos, implementações padrão da indústria incluem carimbos de data/hora, identidade do usuário ou sistema, a ação realizada e os dados ou sistema acessados. Para implantações de LLM, isso se estende à captura de qual usuário ou agente iniciou uma solicitação, qual modelo a processou e contexto suficiente para reconstruir o que ocorreu. Métricas de uso agregadas por si só não são suficientes para apoiar auditorias ou investigações de incidentes.

• A HIPAA exige que a documentação relacionada aos controles de segurança, incluindo registros de auditoria quando aplicável, seja retida por um mínimo de seis anos. Além disso, os sistemas devem implementar controles de integridade para proteger os logs contra alteração ou exclusão não autorizada. Na prática, isso é frequentemente alcançado por meio de mecanismos de armazenamento à prova de adulteração, como configurações de gravação única e leitura múltipla (WORM), controles de acesso rigorosos e sistemas centralizados de gerenciamento de logs que impedem a modificação por equipes operacionais.

• A HIPAA exige mecanismos para identificar e autenticar usuários de forma única que acessam sistemas contendo ePHI. Como resultado, os logs de auditoria devem ser capazes de atribuir eventos de acesso a um indivíduo específico ou identidade de sistema. Implementações que dependem apenas de contas de serviço compartilhadas ou chaves de API sem atribuição em nível de usuário criam lacunas na responsabilização e dificultam o cumprimento dos requisitos de auditoria e investigação. Em sistemas de IA modernos, isso geralmente exige a integração de controles de acesso cientes da identidade, para que as ações realizadas por meio de agentes ou gateways possam ser rastreadas até o usuário de origem.

Requisitos de Controle de Acesso

• A HIPAA exige que o acesso à PHI seja controlado por meio de salvaguardas técnicas e administrativas, incluindo identificação de usuário única, autenticação e controles de acesso baseados em função. Além disso, a Regra de Privacidade impõe o padrão de “mínimo necessário” para o uso e divulgação de PHI. Na prática, isso significa que o acesso deve ser provisionado e gerenciado por meio de um processo documentado, com permissões alinhadas à função do usuário. Para sistemas de IA, isso tem duas implicações. Primeiro, o acesso deve ser vinculado a identidades individuais por meio do provedor de identidade da organização, e não a chaves de API compartilhadas que não podem ser atribuídas a usuários específicos. Segundo, os controles baseados em função devem garantir que os usuários possam acessar apenas as capacidades de IA apropriadas para sua função, por exemplo, separando fluxos de trabalho de faturamento de fluxos de trabalho clínicos com diferentes exposições de PHI.

• O padrão de mínimo necessário se aplica a como a PHI é usada dentro de um sistema, não apenas a qual usuário inicia o acesso. Em sistemas de IA, isso se estende aos dados incluídos nos prompts e contexto do modelo. Passar registros completos de pacientes quando apenas um subconjunto de campos estruturados é necessário pode não estar alinhado com o princípio do mínimo necessário. Embora a HIPAA não defina explicitamente como isso se aplica aos prompts de IA, espera-se que as organizações limitem a exposição de PHI ao que é exigido para a tarefa. Impor isso na camada de infraestrutura, por exemplo, por meio de um gateway de IA que aplica políticas de dados cientes do contexto com base na função do usuário e no caso de uso, é uma abordagem para garantir a adesão consistente em vez de depender da implementação em nível de aplicativo.

Serviços Financeiros: SOC2 e Requisitos Regulatórios para Implantações de LLM

Empresas de serviços financeiros que implantam LLMs enfrentam um ambiente regulatório em camadas. Os requisitos SOC2 Tipo II se aplicam à infraestrutura de tecnologia. As orientações da OCC, Federal Reserve e FINRA sobre IA e risco de modelo se aplicam a modelos usados em decisões financeiras. E as disposições da Lei de IA da UE para sistemas de IA de alto risco, aplicáveis às operações da UE a partir de agosto de 2026, adicionam outra camada para organizações internacionais. Esses frameworks se sobrepõem de maneiras que criam requisitos arquitetônicos específicos para gateways de IA e infraestrutura de implantação de modelos.

Controles SOC2 Tipo II para Infraestrutura de IA

• Gateways de IA e plataformas de implantação de modelos que lidam com dados financeiros estão no escopo das avaliações SOC2 Tipo II quando tocam dados ou sistemas cobertos pela auditoria. Os critérios de serviço de confiança relevantes são CC6 (controles de acesso lógico e físico), CC7 (monitoramento de operações do sistema), CC8 (gerenciamento de mudanças) e CC9 (mitigação de riscos). Cada critério exige controles técnicos específicos que devem estar presentes no ou ao lado do gateway de IA.

• A constatação SOC2 mais comum em implantações de gateway de IA é o controle de acesso inadequado no nível da API: contas de serviço compartilhadas que não podem atribuir acesso a indivíduos, chaves de API armazenadas no código-fonte ou plataformas de IA que não suportam os controles de acesso granulares exigidos pelo CC6. Escolher uma plataforma que se integre ao provedor de identidade empresarial e imponha o RBAC no nível do modelo e da equipe elimina essas constatações antes do início do período de auditoria.

• O SOC2 Tipo II exige evidências contínuas da operação do controle durante o período de auditoria, tipicamente de seis a doze meses. Isso significa que os logs de auditoria devem ser gerados continuamente e retidos durante todo o período, não capturados sob demanda quando os auditores os solicitam. Plataformas de gateway de IA que produzem logs estruturados e contínuos desde o primeiro dia de implantação são significativamente mais fáceis de auditar do que sistemas onde o registro foi adicionado posteriormente. A evidência de auditoria deve mostrar que os controles estavam operando consistentemente durante todo o período, e não apenas no momento da auditoria.

Gerenciamento de Risco de Modelo (SR 11-7) para LLMs

• A orientação SR 11-7 da OCC e do Federal Reserve sobre Gerenciamento de Risco de Modelo se aplica a modelos de IA e LLM usados em decisões de crédito, avaliação de risco e outros processos relevantes para a regulamentação. A orientação exige três coisas para cada modelo no escopo: documentação de propósito, dados de treinamento e metodologia de teste; validação independente contra padrões de desempenho definidos; e monitoramento contínuo com rastreamento de desempenho e detecção de desvio.

• Para LLMs em serviços financeiros, o ônus de documentação SR 11-7 estende-se à infraestrutura na qual o modelo é executado. Qual LLM está sendo usado, por quais equipes, para quais decisões, a que custo, com que latência e com que comportamento de saída observado, tudo isso deve ser documentado e estar disponível para revisão regulatória. Um gateway de IA que captura esses dados automaticamente como parte de seu registro padrão produz a evidência de documentação do modelo como um subproduto das operações normais. Isso reduz o que de outra forma seria um esforço significativo de documentação manual para cada modelo abrangido.

Seguros: Residência de Dados e Requisitos do GDPR

Empresas de seguros que operam em várias jurisdições enfrentam restrições de residência de dados e de transferência transfronteiriça que limitam diretamente as escolhas de arquitetura de IA. O GDPR, o UK GDPR e as leis estaduais de privacidade dos EUA têm disposições que afetam onde e como os dados do cliente podem ser processados, incluindo se podem ser enviados para uma API de modelo de IA para inferência.

• Base para o tratamento de dados do GDPR: Sistemas de IA que processam dados pessoais devem ter uma base legal documentada nos termos do Artigo 6 do GDPR. Para a maioria dos casos de uso de IA em seguros, a base é o interesse legítimo ou a necessidade contratual. Ambos exigem que o processamento seja documentado, proporcional à finalidade e divulgado na política de privacidade da organização. Sistemas de IA que processam dados pessoais sem uma base legal documentada criam exposição regulatória direta sob uma estrutura onde as multas podem atingir 4% do faturamento anual global.

• Restrições de transferência transfronteiriça: O envio de dados pessoais de residentes da UE para infraestruturas de IA fora da UE exige um acordo de Cláusulas Contratuais Padrão ou outro mecanismo de transferência aprovado pelo GDPR. Muitos provedores de SaaS de IA estão sediados nos EUA. A documentação de conformidade para a transferência de dados UE-EUA deve ser preenchida com envolvimento jurídico antes do início da implantação técnica. Para alguns tipos de dados e algumas tolerâncias de risco organizacionais, este requisito exige efetivamente uma implantação europeia ou totalmente isolada por VPC, sem que os dados cruzem fronteiras jurisdicionais.

• Registros de atividades de tratamento nos termos do Artigo 30: O GDPR exige que as organizações mantenham registros das atividades de tratamento que abrangem sistemas de IA, descrevendo a finalidade do tratamento, categorias de dados, transferências internacionais, se houver, e medidas de segurança aplicadas. Os logs de auditoria do gateway de IA fornecem os dados brutos para esses registros, mas devem ser configurados para capturar os campos necessários, incluindo categoria de dados, finalidade do tratamento e destino da transferência, em um formato que a equipe de conformidade possa apresentar a um regulador mediante solicitação.

• Direito de explicação para decisões automatizadas: O Artigo 22 do GDPR restringe decisões totalmente automatizadas que afetam significativamente os indivíduos e concede aos indivíduos o direito a uma explicação significativa de como a decisão foi tomada. Sistemas de IA de seguros que auxiliam na subscrição ou no tratamento de sinistros devem ser projetados com capacidade de revisão humana e geração de explicações incorporadas ao fluxo de trabalho, e não adicionadas como um recurso posterior. A decisão de arquitetura sobre como as recomendações de IA fluem para os tomadores de decisão humanos é uma decisão de conformidade, não apenas uma escolha de design de produto.

A Arquitetura Isolada por VPC: Como Ela Se Parece na Prática

A implantação de LLM isolada por VPC é o padrão de arquitetura que satisfaz a mais ampla gama de requisitos da indústria regulamentada simultaneamente. O isolamento de PHI para HIPAA, a residência de dados para GDPR, os controles de segurança de rede para SOC2 e a responsabilidade operacional para reguladores de serviços financeiros todos decorrem de uma implantação VPC devidamente implementada. Compreender o que isso realmente envolve é o que as equipes de conformidade, infraestrutura e segurança precisam antes de uma conversa de aprovação.

• Gateway de IA dentro do perímetro: O gateway funciona como um serviço conteinerizado dentro da VPC da organização. Todas as chamadas de API do LLM são roteadas através deste gateway interno. Nenhuma aplicação se comunica diretamente com um provedor de modelo externo. O gateway é o único componente com capacidade de saída para APIs externas, e somente quando a arquitetura implantada permite o acesso a modelos externos para casos de uso específicos que não envolvem dados regulamentados. Para implantações totalmente isoladas, mesmo essa saída está ausente.

• Serviço de modelo dentro do perímetro: Para HIPAA e requisitos rigorosos de residência de dados, o próprio LLM é executado dentro da VPC. AWS Bedrock acessado dentro da mesma conta AWS, Azure OpenAI Service dentro de uma assinatura Azure com cobertura BAA apropriada, ou modelos de código aberto auto-hospedados em infraestrutura de GPU dentro da conta da nuvem todos satisfazem este requisito. Em implantações totalmente isoladas, nenhum dado de inferência do modelo sai do limite da conta de nuvem da organização em qualquer ponto do ciclo de vida da solicitação.

• Logs de auditoria em armazenamento próprio do cliente: Todos os logs de auditoria são gravados na própria infraestrutura de registro da organização: CloudWatch, Azure Monitor, Splunk ou um SIEM especificado pelo cliente. Os dados de log, que podem conter informações regulamentadas, nunca transitam para o serviço de registro SaaS de um fornecedor. As políticas de retenção, controles de acesso e configuração de armazenamento à prova de adulteração são gerenciados pela equipe de conformidade da organização, sem depender das configurações de retenção de um fornecedor.

• Sem acesso do fornecedor ao tráfego de produção: Em uma implementação de implantação isolada por VPC devidamente configurada, o tráfego de inferência de produção, o conteúdo dos prompts e as respostas do modelo permanecem dentro do ambiente de nuvem do cliente, em vez de serem roteados através da infraestrutura gerenciada pelo fornecedor. Isso reduz significativamente a visibilidade externa dos fluxos de dados sensíveis e está em conformidade com os requisitos de residência e privacidade de dados. O acesso de suporte, quando necessário, é regido por procedimentos de "break-glass" controlados e com prazo definido, com aprovação explícita do cliente, em vez de acesso persistente. Essa arquitetura minimiza a exposição do fornecedor a dados regulamentados no caminho de produção, embora o relacionamento com o fornecedor para software de plataforma e suporte permaneça dentro do escopo geral de conformidade da organização.

Como a TrueFoundry Resolve a Implantação de LLMs em Setores Regulamentados

A TrueFoundry é implantada inteiramente na conta de nuvem do cliente na AWS, Azure ou GCP. Nenhum dado de produção, incluindo conteúdo de prompt, respostas de modelo, parâmetros de invocação de ferramentas MCP ou dados de log de auditoria, sai do perímetro da empresa para alcançar a infraestrutura da TrueFoundry. Esta não é uma opção de implantação. É a arquitetura padrão para implantações empresariais, não um nível premium.

• Implantação isolada por VPC por padrão: A TrueFoundry é implantada na própria conta de nuvem do cliente usando infraestrutura como código. O gateway de IA, o gateway MCP, a interface de usuário de gerenciamento e o armazenamento de logs de auditoria são executados dentro do perímetro do cliente. Quatro opções de implantação cobrem todo o espectro, desde SaaS totalmente gerenciado sem custo de infraestrutura até Control Plane completo mais Gateway Plane dentro da conta do cliente, com um custo de infraestrutura de aproximadamente US$ 800 a US$ 1.000 por mês. Para cargas de trabalho regulamentadas, as Opções 3 e 4 garantem que nenhum dado transite pela infraestrutura da TrueFoundry. O acesso de suporte da TrueFoundry utiliza procedimentos de "break-glass" documentados com aprovação do cliente.

• Logs de auditoria estruturados alinhados a HIPAA, SOC2 e GDPR: Cada chamada de LLM gera uma entrada de log de auditoria JSON estruturada via cabeçalho X-TFY-LOGGING-CONFIG. No nível do gateway, REQUEST_LOGGING_MODE: ALWAYS em implantações auto-hospedadas garante que cada solicitação seja capturada sem desvio de configuração. Os campos de log cobrem identidade do usuário, modelo, contagem de tokens, latência, custo, decisão de política e saída. Os logs são exportados via OpenTelemetry para Grafana, Datadog, Splunk ou qualquer SIEM compatível com OTLP. Em implantações auto-hospedadas, os dados de log são gravados no próprio armazenamento AWS S3, GCS ou Azure Blob do cliente no formato Parquet com retenção configurável. O S3 Object Lock no modo WORM satisfaz o requisito de retenção à prova de adulteração da HIPAA para o mínimo de seis anos.

• Integração SSO com sistemas de identidade clínica e empresarial: A TrueFoundry se integra com Okta, Azure Active Directory, PingFederate e qualquer provedor de identidade compatível com SAML 2.0 ou JWKS. O provisionamento de acesso segue o processo padrão de gerenciamento do ciclo de vida da identidade da organização. Desenvolvedores que ingressam em uma equipe obtêm acesso ao gateway de IA através do mesmo fluxo de trabalho IdP que provisiona seus outros sistemas. Desenvolvedores que saem têm o acesso revogado através do mesmo fluxo de trabalho de desligamento. Não há um sistema de credenciais de gateway de IA separado para manter ou auditar independentemente.

• Catálogo de modelos aprovados para cargas de trabalho regulamentadas: Os administradores da plataforma definem quais modelos são aprovados para quais tipos de dados e casos de uso. Uma equipe clínica não pode rotear prompts contendo PHI para um modelo não elegível para BAA porque o gateway impõe políticas de modelo para caso de uso na camada de roteamento antes que a solicitação saia do perímetro. Essa imposição de política ocorre no gateway de IA, não na camada de aplicação, o que significa que ela se aplica consistentemente, independentemente de qual aplicação ou agente inicia a solicitação.

• Implantações de produção verificadas em setores regulamentados: A Medtronic, com portfólios de dispositivos médicos regulamentados pela FDA, executa a TrueFoundry em produção. A Siemens Healthineers a utiliza em operações globais de tecnologia médica com exposição regulatória em múltiplas jurisdições. A Innovaccer processa aproximadamente 17 milhões de solicitações de inferência de IA clínica por mês dentro do AWS GovCloud sob HIPAA, sem que nenhum dado saia de seu limite de nuvem, usando o gateway da TrueFoundry com OpenTelemetry alimentando painéis Grafana. A Aviva executa a TrueFoundry para operações de seguros no Reino Unido sob GDPR. A ResMed a utiliza para aplicações de saúde digital. Estas são implantações de produção em escala empresarial com aprovação de conformidade regulatória, não pilotos.