Por que a IA na saude exige uma abordagem regulatoria tripla

Sistemas de inteligencia artificial aplicados a saude operam em um territorio onde o erro nao e apenas comercial — e clinico, e potencialmente fatal. Diferente de outros setores de alto risco, a saude brasileira impoe uma camada regulatoria tripla sobre qualquer software que auxilie diagnosticos, tratamentos ou monitoramento de pacientes: a ANVISA regula o produto, o CFM disciplina a pratica medica, e o PL 2.338 estabelece governanca de IA. Para uma software house que constroi esses sistemas sob medida para hospitais, clinicas e healthtechs, compreender essa arquitetura regulatoria nao e opcional — e pre-requisito de engenharia.

Segundo pesquisas recentes, 41,9% das empresas brasileiras ja utilizam inteligencia artificial em algum grau. O setor de saude esta entre os que mais rapidamente adotam a tecnologia, impulsionado por promessas de diagnosticos mais rapidos, triagem mais precisa e reducao de custos operacionais. Mas adocao sem conformidade e bomba-relogio. As multas do PL 2.338 chegam a R$ 50 milhoes; o AI Act europeu preve penalidades de ate 35 milhoes de euros; e a ANVISA possui estrutura sancionatoria propria que pode resultar em interdicao do produto. Neste artigo, vamos detalhar como construir sistemas de diagnostico assistido por IA que atendam simultaneamente a ANVISA, ao CFM e ao PL 2.338 — e por que isso exige uma software house com experiencia em dominios regulados.

A camada regulatoria #1: ANVISA e o Software como Dispositivo Medico (SaMD)

A Resolucao da Diretoria Colegiada (RDC) 657/2022 da ANVISA e o marco que define quando um software deixa de ser apenas software e passa a ser um dispositivo medico. O criterio e objetivo: se o fabricante declara finalidade diagnostica, terapeutica ou de monitoramento, o software e classificado como SaMD (Software as a Medical Device) e cai sob regulacao sanitaria.

Essa classificacao nao depende da complexidade tecnica — depende da intencao de uso declarada. Um algoritmo de machine learning que sugere possibilidades diagnosticas a partir de imagens de raio-X e SaMD. Um sistema que organiza prontuarios eletronicos sem emitir sugestoes clinicas nao e. A fronteira e a finalidade declarada pelo fabricante, e essa declaracao tem consequencias regulatorias diretas.

Classes de risco ANVISA para SaMD

A ANVISA classifica dispositivos medicos em quatro classes de risco (I a IV), e cada classe determina o caminho regulatorio:

• Classe I (risco baixo): softwares que auxiliam funcoes administrativas com impacto clinico minimo. Processo simplificado de notificacao.
• Classe II (risco medio-baixo): softwares que fornecem informacoes para decisao clinica, mas sem substituir julgamento medico direto. Notificacao simplificada, porem com documentacao tecnica mais robusta.
• Classe III (risco medio-alto): softwares que influenciam diretamente decisoes diagnosticas ou terapeuticas. Registro completo obrigatorio, incluindo evidencias clinicas de desempenho e seguranca.
• Classe IV (risco alto): softwares que impactam diretamente funcoes vitais ou tratamentos de alto risco. Registro completo com estudos clinicos, auditoria de boas praticas de fabricacao e vigilancia pos-mercado.

Para sistemas de diagnostico assistido por IA — aqueles que analisam imagens medicas, dados laboratoriais ou sinais vitais e sugerem hipoteses diagnosticas — a classificacao tipica recai sobre Classes III ou IV. Isso significa que o processo regulatorio exige registro completo, evidencias clinicas, e monitoramento continuo apos a comercializacao. Nao ha atalhos.

Implicacoes para a arquitetura de software

A RDC 657/2022 nao e apenas um formulario a preencher — ela impoe requisitos que afetam diretamente a arquitetura tecnica do sistema. A ANVISA exige rastreabilidade de versoes, documentacao de ciclo de vida do software, gestao de riscos conforme ISO 14971, e processos de verificacao e validacao que demonstrem que o software faz o que promete fazer com a seguranca que promete ter. Para sistemas baseados em IA, isso inclui documentacao de datasets de treinamento, metricas de desempenho (sensibilidade, especificidade, AUC-ROC), e planos de monitoramento de drift — a degradacao gradual da performance do modelo ao longo do tempo.

Uma software house que constroi SaMD precisa integrar esses requisitos desde o sprint zero. Retrofitar conformidade em um sistema ja desenvolvido e ordens de magnitude mais caro e mais arriscado do que projetar para conformidade desde o inicio.

A camada regulatoria #2: CFM e a Resolucao 2.454/2026

Enquanto a ANVISA regula o produto, o Conselho Federal de Medicina regula a pratica. A Resolucao CFM 2.454/2026, com vigencia a partir de agosto de 2026, estabelece o marco etico e deontologico para o uso de inteligencia artificial na medicina brasileira. O texto e inequivoco em dois pontos fundamentais.

Primeiro: medicos podem utilizar IA como ferramenta de apoio a decisao clinica. A resolucao reconhece explicitamente o valor da IA como suporte — analise de imagens, correlacao de dados, sugestao de hipoteses diagnosticas, otimizacao de protocolos. O CFM nao e contra a tecnologia; e a favor de limites claros.

Segundo — e aqui esta o limite inegociavel: as decisoes finais sobre diagnostico, tratamento e prognostico devem ser humanas. A resolucao proibe expressamente que a comunicacao de diagnostico ou decisao terapeutica seja delegada a IA sem intervencao do medico. Nao importa quao preciso seja o modelo, nao importa quantos milhoes de parametros ele tenha — a ultima palavra e do profissional de medicina.

O que isso significa para o design de sistemas

Para quem constroi software, a Resolucao 2.454/2026 traduz-se em requisitos concretos de design de interface e fluxo de dados:

• Human-in-the-loop obrigatorio: todo fluxo que envolva sugestao diagnostica deve incluir um ponto de validacao humana antes que qualquer resultado chegue ao paciente. Isso nao pode ser um botao “confirmar” que o medico clica automaticamente — a interface deve exigir engajamento ativo.
• Transparencia de confianca: o sistema deve comunicar ao medico o nivel de confianca da sugestao, as evidencias que a fundamentam, e as limitacoes conhecidas do modelo para aquele tipo de caso.
• Auditoria de decisoes: cada interacao entre o medico e a sugestao da IA deve ser registrada — o que o sistema sugeriu, o que o medico decidiu, e a justificativa quando houver divergencia.
• Proibicao de comunicacao autonoma: o sistema nao pode enviar resultados diagnosticos ou terapeuticos diretamente ao paciente por qualquer canal (app, SMS, e-mail, portal) sem que o medico tenha revisado e autorizado especificamente aquela comunicacao.

Esses requisitos nao sao cosmeticos. Eles afetam a modelagem de dados, a arquitetura de microservicos, o design de APIs internas, e o frontend. Um sistema que trata a supervisao humana como camada adicional — um “wrapper” em cima de um modelo autonomo — esta arquiteturalmente errado. A supervisao humana deve ser componente estrutural, nao decorativo.

A camada regulatoria #3: PL 2.338 e a governanca transversal de IA

O Projeto de Lei 2.338, que tramita como o principal marco regulatorio de inteligencia artificial no Brasil, classifica sistemas de saude como alto risco. Essa classificacao alinha-se ao AI Act europeu, que enquadra IA diagnostica no Anexo III como alto risco, e impoe um conjunto de obrigacoes que se somam — nao substituem — as exigencias da ANVISA e do CFM.

Obrigacoes do PL 2.338 para sistemas de alto risco

• Avaliacao de impacto algoritmico: antes de colocar o sistema em producao, o operador deve conduzir uma avaliacao que identifique riscos de discriminacao, erros sistematicos, e impactos sobre grupos vulneraveis.
• Supervisao humana significativa: nao basta ter um humano “no loop” — a supervisao deve ser efetiva, com autoridade real para contestar, modificar ou vetar as decisoes do sistema.
• Transparencia e explicabilidade: os usuarios (medicos) e os afetados (pacientes) devem ter acesso a informacoes claras sobre como o sistema funciona, seus limites, e os dados utilizados.
• Registro e rastreabilidade: logs completos de operacao devem ser mantidos por periodo definido, permitindo auditoria a posteriori.
• Governanca de dados: o sistema deve cumprir LGPD com rigor especial para dados de saude (dados sensiveis, Art. 11), e a ANPD ja sinalizou que IA combinada com dados biometricos e de saude sera alvo prioritario de fiscalizacao em 2026-2027.

As multas previstas no PL 2.338 chegam a R$ 50 milhoes por infracao. Para efeito de comparacao, o AI Act europeu preve penalidades de ate 35 milhoes de euros. Estamos falando de valores que podem inviabilizar empresas inteiras — e de responsabilidades que recaem tanto sobre o desenvolvedor do sistema quanto sobre o operador que o coloca em uso.

Tabela comparativa: requisitos por regulacao

A tabela abaixo sintetiza as exigencias de cada camada regulatoria e como elas se sobrepoem. Para quem desenvolve sistemas de diagnostico assistido por IA, todas as colunas se aplicam simultaneamente.

Arquitetura tecnica para conformidade: os 7 pilares

Construir um sistema de diagnostico assistido por IA que atenda simultaneamente a ANVISA, CFM e PL 2.338 exige decisoes arquiteturais deliberadas desde a concepcao. Abaixo, detalhamos os sete pilares tecnicos que uma software house experiente implementa para garantir conformidade sem sacrificar usabilidade.

Pilar 1: Separacao rigorosa de camadas (modelo vs. decisao)

O modelo de IA deve operar em uma camada isolada que produz sugestoes, scores de confianca e evidencias. A camada de decisao — onde o medico avalia, modifica ou rejeita a sugestao — deve ser arquiteturalmente separada. Essa separacao nao e apenas boa pratica de engenharia; e requisito regulatorio. O CFM exige que a decisao final seja humana, e a ANVISA exige rastreabilidade do que o software produziu vs. o que foi efetivamente utilizado clinicamente.

Na pratica, isso significa microservicos distintos: um servico de inferencia que recebe dados clinicos e retorna sugestoes probabilisticas, e um servico de workflow clinico que apresenta essas sugestoes ao medico, coleta sua decisao, e registra o desfecho. Nunca um unico endpoint que recebe dados e devolve “diagnostico”.

Pilar 2: Audit trail imutavel

Cada interacao entre o sistema de IA e o profissional de saude deve ser registrada em log imutavel — append-only, com hash encadeado ou tecnologia equivalente que impeca alteracao retroativa. O registro deve conter: timestamp, dados de entrada (anonimizados para fins de auditoria), sugestao do modelo, score de confianca, decisao do medico, e justificativa em caso de divergencia.

Esse audit trail atende simultaneamente a tres regulacoes: tecnovigilancia da ANVISA (rastreabilidade de incidentes), responsabilidade medica do CFM (prova de que a decisao foi humana), e requisito de logs do PL 2.338 (auditoria algoritmca). Uma unica implementacao, tres conformidades.

Pilar 3: Explicabilidade integrada ao modelo

Um sistema que diz “probabilidade de pneumonia: 87%” sem explicar por que chegou a esse numero e insuficiente para conformidade. O PL 2.338 exige explicabilidade; o CFM exige que o medico tenha informacoes para exercer julgamento clinico. Isso significa implementar tecnicas como SHAP values, attention maps, ou explanations textuais que indiquem quais caracteristicas dos dados de entrada mais contribuiram para a sugestao.

Para imagens medicas, mapas de calor (heatmaps) sobrepostos a imagem original — mostrando as regioes que mais influenciaram a classificacao — sao pratica consolidada e bem recebida pela comunidade medica. Para dados tabulares (laboratoriais, demograficos, historico clinico), rankings de features com contribuicoes positivas e negativas explicitas.

Pilar 4: Gestao de consentimento granular

A LGPD classifica dados de saude como sensiveis (Art. 11), e a ANPD sinalizou que IA combinada com dados biometricos e de saude sera alvo prioritario de fiscalizacao em 2026-2027. O sistema deve implementar consentimento granular: o paciente deve poder autorizar ou recusar especificamente o uso de seus dados para (a) assistencia clinica com IA, (b) treinamento de modelos, e (c) pesquisa. Cada finalidade exige consentimento separado, revogavel, e rastreavel.

Arquiteturalmente, isso implica um servico de gestao de consentimento que intercepta o fluxo de dados antes de qualquer processamento por IA, verificando permissoes granulares e bloqueando processamento nao autorizado. Nao basta um checkbox generico no cadastro do paciente.

Pilar 5: Monitoramento de drift e vigilancia pos-mercado

Modelos de IA degradam. Dados do mundo real divergem dos dados de treinamento. Populacoes mudam. A ANVISA exige tecnovigilancia — monitoramento continuo da performance do dispositivo medico apos a comercializacao. Para SaMD baseado em IA, isso significa monitorar metricas de desempenho (sensibilidade, especificidade, taxa de falsos positivos e negativos) em producao, comparando continuamente com os benchmarks estabelecidos durante a validacao clinica.

Alertas automaticos devem ser disparados quando metricas caem abaixo de limiares pre-definidos. Dashboards de monitoramento devem ser acessiveis a equipe de qualidade regulatoria, nao apenas a equipe tecnica. E o sistema deve ter capacidade de rollback — reverter para uma versao anterior do modelo se a degradacao for critica — sem interromper o atendimento clinico.

Pilar 6: Versionamento regulatorio de modelos

Cada versao do modelo de IA e, do ponto de vista regulatorio, uma versao potencialmente diferente do dispositivo medico. A ANVISA pode exigir nova notificacao ou aditamento de registro quando o modelo e retreinado com novos dados ou quando a arquitetura do modelo muda significativamente. O sistema deve implementar versionamento rigoroso de modelos — nao apenas controle de versao de codigo, mas registro completo de cada versao do modelo com seus datasets de treinamento, hiperparametros, metricas de validacao, e data de deploy.

Isso vai alem do MLOps convencional. E MLOps regulatorio — onde cada modelo em producao tem um dossiê tecnico equivalente ao que foi submetido a ANVISA, atualizado a cada retreinamento.

Pilar 7: Testes de bias e equidade

O PL 2.338 exige avaliacao de impacto que identifique riscos de discriminacao. Para IA em saude, isso e particularmente critico: modelos treinados predominantemente com dados de populacoes especificas podem ter desempenho inferior para outros grupos demograficos — diferente cor de pele em dermatologia, diferentes faixas etarias em cardiologia, diferentes biotipos em radiologia.

O sistema deve incluir, desde a fase de desenvolvimento, testes de equidade que avaliem desempenho do modelo segmentado por genero, faixa etaria, etnia e outras variaveis demograficas relevantes para o dominio clinico especifico. Disparidades significativas devem ser documentadas, mitigadas quando possivel, e comunicadas transparentemente quando nao puderem ser eliminadas.

Licoes de dominios regulados: o caso LawrAI

A Mind Group, como software house especializada em sistemas sob medida, acumula experiencia pratica na construcao de sistemas de IA em dominios onde conformidade nao e opcional. O caso mais ilustrativo e o LawrAI — uma plataforma de IA juridica que, embora opere em dominio diferente da saude, compartilha os mesmos desafios estruturais de conformidade.

O LawrAI utiliza arquitetura RAG (Retrieval-Augmented Generation) para fornecer analises juridicas a mais de 20.000 usuarios. O dominio juridico, assim como o medico, e sensivel por natureza: erros podem resultar em perda de direitos, prejuizos financeiros significativos, ou decisoes judiciais equivocadas. As restricoes sao analogas:

• Supervisao humana obrigatoria: assim como a Resolucao CFM 2.454/2026 exige que a decisao final seja do medico, o sistema juridico exige que a decisao final seja do advogado. O LawrAI foi projetado para sugerir, fundamentar e auxiliar — nunca para decidir autonomamente.
• Dados sensiveis: dados juridicos, como dados de saude, sao protegidos por sigilo profissional e pela LGPD. A arquitetura de gestao de dados do LawrAI implementa isolamento de dados por cliente, criptografia em repouso e em transito, e controle de acesso granular.
• Rastreabilidade: cada sugestao do sistema e rastreavel — qual fonte juridica foi utilizada, qual trecho fundamentou a analise, e qual foi a decisao do profissional. Esse mesmo padrao de audit trail se aplica integralmente a sistemas de saude.
• Escalabilidade com conformidade: escalar de PoC para 20.000 usuarios mantendo conformidade nao e trivial. Exige infraestrutura que preserve garantias regulatorias sob carga — e exatamente o tipo de desafio que uma software house resolve para seus clientes.

A experiencia com o LawrAI demonstra que os padroes arquiteturais de conformidade sao transferiveis entre dominios regulados. A camada de supervisao humana, o audit trail imutavel, a explicabilidade integrada, e a gestao rigorosa de dados sensiveis sao padroes que a Mind Group aplica em qualquer sistema construido para dominios de alto risco — saude, juridico, financeiro, ou governamental.

O papel da software house vs. o papel da healthtech

Um equivoco frequente no mercado e assumir que a conformidade regulatoria e responsabilidade exclusiva da healthtech que comercializa o produto final. Na realidade, a cadeia de responsabilidade se estende a quem constroi o software — e aqui que o papel da software house se torna critico.

A ANVISA responsabiliza o fabricante do dispositivo medico. Quando uma healthtech contrata uma software house para construir seu sistema de IA, o codigo produzido, a arquitetura implementada, e os processos de qualidade adotados durante o desenvolvimento tornam-se parte do dossiê regulatorio. Uma software house que nao compreende os requisitos da RDC 657/2022 produzira um sistema que exigira refatoracao cara e demorada para passar pelo registro — se e que passara.

Alem disso, o PL 2.338 distribui responsabilidade entre desenvolvedor e operador. A software house que constroi o sistema e co-responsavel pelas garantias tecnicas de conformidade: explicabilidade, rastreabilidade, gestao de bias, e robustez do sistema. Ignorar essa co-responsabilidade nao e apenas risco regulatorio — e risco juridico direto.

Fluxo pratico: do briefing a operacao conforme

Como uma software house com experiencia em dominios regulados aborda um projeto de diagnostico assistido por IA? O fluxo abaixo ilustra as etapas criticas, diferenciando-as de um projeto de software convencional.

Fase 1: Discovery regulatorio (4-6 semanas)

Antes de escrever uma linha de codigo, e necessario mapear completamente o cenario regulatorio do produto especifico. Qual a finalidade clinica declarada? Qual a classe de risco ANVISA resultante? Ha requisitos adicionais do CFM para a especialidade medica envolvida? Quais dados serao processados e quais obrigacoes da LGPD se aplicam? Esse mapeamento define a arquitetura, nao o contrario.

Fase 2: Arquitetura para conformidade (2-4 semanas)

Com o mapeamento regulatorio em maos, projeta-se a arquitetura tecnica que atenda simultaneamente aos requisitos de todas as regulacoes aplicaveis. Os sete pilares descritos anteriormente sao implementados como componentes arquiteturais, nao como “features” adicionais. A decisao de usar microservicos vs. monolito, cloud vs. on-premise, modelo proprietario vs. open-source — todas sao influenciadas pelos requisitos regulatorios.

Fase 3: Desenvolvimento com QMS integrado (12-24 semanas)

O desenvolvimento segue um Quality Management System (QMS) integrado ao ciclo de desenvolvimento agil. Cada sprint inclui atividades de verificacao e validacao, revisao de riscos (ISO 14971), e atualizacao de documentacao regulatoria. O “definition of done” de cada feature inclui criterios regulatorios, nao apenas criterios tecnicos.

Fase 4: Validacao clinica e submissao regulatoria (8-16 semanas)

Para Classes III e IV da ANVISA, sao necessarios estudos clinicos que demonstrem seguranca e eficacia do software. A software house suporta esse processo com infraestrutura de coleta de dados clinicos, analise estatistica de desempenho do modelo, e preparacao do dossiê tecnico para submissao. A validacao clinica nao e responsabilidade exclusiva da software house — e um esforco conjunto com o cliente e, tipicamente, com uma consultoria regulatoria especializada — mas a capacidade tecnica de suportar esse processo e diferencial critico.

Fase 5: Operacao e vigilancia continua

Apos o registro e a entrada em operacao, o sistema requer monitoramento continuo de performance (drift detection), gestao de incidentes de tecnovigilancia, e atualizacoes que mantenham conformidade a medida que regulacoes evoluem. A software house que construiu o sistema e frequentemente a mais capacitada para operar essa vigilancia tecnica — e esse e um servico recorrente que agrega valor ao longo de toda a vida util do produto.

Erros comuns que comprometem conformidade

Na experiencia da Mind Group construindo sistemas em dominios regulados, ha padroes de erro que se repetem em projetos de IA para saude conduzidos sem expertise regulatoria:

• Tratar conformidade como fase final: “primeiro desenvolvemos, depois regularizamos” e a formula mais cara de falhar. Requisitos regulatorios devem informar a arquitetura, nao ser “bolted on” no final.
• Confundir human-in-the-loop com checkbox: um botao de “aprovar” que o medico clica reflexivamente nao constitui supervisao significativa nos termos do PL 2.338 nem atende a exigencia do CFM de decisao humana efetiva.
• Ignorar bias de dataset: treinar com dados predominantemente de uma populacao e deployar para populacoes diversas sem avaliar disparidades e receita para discriminacao algoritmca — e para sancoes regulatorias.
• Subestimar versionamento de modelos: cada retreinamento e, potencialmente, um novo dispositivo medico para a ANVISA. Sem versionamento rigoroso, a rastreabilidade regulatoria colapsa.
• Negligenciar pos-mercado: considerar que o trabalho termina no registro ANVISA e ignorar que a tecnovigilancia e obrigacao permanente — e que modelos de IA degradam inevitavelmente.

O cenario internacional como referencia

O Brasil nao esta regulando em vacuo. O AI Act europeu, com vigencia a partir de 2025-2026, classifica IA diagnostica como alto risco no Anexo III e impoe requisitos detalhados de conformidade que servem como benchmark global. O FDA americano possui o Digital Health Center of Excellence e frameworks especificos para SaMD com IA/ML, incluindo o Predetermined Change Control Plan — um mecanismo que permite ao fabricante planejar antecipadamente como o modelo sera atualizado sem necessidade de nova submissao completa para cada modificacao.

A ANVISA participa do International Medical Device Regulators Forum (IMDRF) e alinha suas regulacoes progressivamente com padroes internacionais. Para uma software house brasileira que constroi sistemas com ambicao de operacao internacional, projetar para conformidade com multiplas jurisdicoes desde o inicio nao e prematuridade — e economia. Retrofitar conformidade com o AI Act em um sistema projetado apenas para o mercado brasileiro custa ordens de magnitude mais do que projetar para ambos desde a concepcao.

O que esperar de 2026-2027: tendencias regulatorias

O cenario regulatorio para IA em saude esta em movimento acelerado. As tendencias mais relevantes para quem desenvolve sistemas nesse espaco incluem:

• ANPD como agente ativo: a Autoridade Nacional de Protecao de Dados sinalizou que IA combinada com dados biometricos e de saude sera alvo prioritario de fiscalizacao em 2026-2027. Sistemas que processam dados de saude com IA estao no radar.
• Convergencia regulatoria: espera-se maior coordenacao entre ANVISA, ANPD, e a futura autoridade de regulacao de IA prevista no PL 2.338. Para quem constroi sistemas, isso significa preparar-se para auditorias coordenadas, nao isoladas.
• Sandboxes regulatorios: a ANVISA e a ANPD tem explorado modelos de sandbox que permitem testar inovacoes em ambientes controlados antes de submissao formal. Participar desses sandboxes e oportunidade estrategica.
• Padronizacao de evidencias de IA: normas especificas para documentacao e validacao de sistemas de IA em saude estao em desenvolvimento, incluindo atualizacoes da IEC 62304 (ciclo de vida de software de dispositivo medico) para contemplar especificidades de machine learning.

A visao da Mind Group

“Construir IA para saude sem dominar o cenario regulatorio e como erguer um predio sem engenheiro estrutural — pode ate ficar de pe por um tempo, mas o risco de colapso e real. Na Mind Group, aprendemos com o LawrAI que sistemas em dominios sensiveis exigem que conformidade seja componente de arquitetura, nao camada de verniz. Quando um cliente nos procura para construir um sistema de diagnostico assistido, a primeira conversa nao e sobre tecnologia — e sobre regulacao. A tecnologia vem depois, a servico da conformidade e do resultado clinico.”

Jose Goncalves, CEO da Mind Group

Por que a escolha da software house define o sucesso regulatorio

A conformidade regulatoria de um sistema de diagnostico assistido por IA nao e determinada apenas pelo produto final — e determinada pelo processo que o produziu. A ANVISA, ao avaliar um SaMD para registro, analisa nao apenas o software em si, mas a evidencia de que ele foi desenvolvido seguindo boas praticas de fabricacao, com gestao de riscos documentada, com verificacao e validacao rastreavels, e com um QMS que garanta a reproducibilidade do processo.

Uma software house sem experiencia em dominios regulados pode produzir um software funcional — mas o dossiê regulatorio sera insuficiente, a documentacao sera incompleta, e as decisoes arquiteturais terao sido tomadas sem considerar implicacoes regulatorias. O resultado e um produto que funciona tecnicamente, mas que nao pode ser legalmente comercializado como dispositivo medico. E a diferenca entre um prototipo de laboratorio e um produto de mercado.

A Mind Group, como software house que constroi sistemas sob medida para clientes em dominios regulados, integra competencia tecnica com compreensao regulatoria. A experiencia com o LawrAI — levando um sistema de IA em dominio sensivel de PoC a 20.000 usuarios com conformidade — e evidencia pratica dessa capacidade. Para healthtechs, hospitais e clinicas que precisam construir sistemas de diagnostico assistido por IA, a escolha de uma software house que entende tanto de codigo quanto de regulacao nao e luxo — e gestao de risco.

Perguntas frequentes

Qual a diferenca entre um software de gestao hospitalar e um SaMD regulado pela ANVISA?

A diferenca esta na finalidade declarada. Um software de gestao hospitalar que organiza prontuarios, agendamentos e faturamento nao e SaMD — ele nao tem finalidade diagnostica, terapeutica ou de monitoramento clinico. Um sistema que analisa dados clinicos e sugere hipoteses diagnosticas, monitora sinais vitais com alertas clinicos, ou auxilia decisoes terapeuticas e classificado como SaMD pela RDC 657/2022 e deve passar pelo processo regulatorio da ANVISA correspondente a sua classe de risco (I a IV). A fronteira e a intencao de uso declarada pelo fabricante, e essa declaracao tem consequencias regulatorias diretas que afetam desde a arquitetura do software ate o processo de comercializacao.

A Resolucao CFM 2.454/2026 proibe o uso de IA na medicina?

Nao. A Resolucao CFM 2.454/2026 reconhece e autoriza explicitamente o uso de IA como ferramenta de apoio a decisao clinica. O que a resolucao proibe e a delegacao de decisoes finais — diagnostico, tratamento e prognostico — a sistemas de IA sem intervencao do medico. A IA pode sugerir, fundamentar e auxiliar, mas a decisao final e a comunicacao ao paciente devem ser atos medicos, realizados por profissional de medicina. A proibicao especifica e contra a comunicacao de diagnostico ou decisao terapeutica ao paciente por meio de IA sem que o medico tenha revisado e autorizado.

Quais sao as multas para sistemas de IA em saude que nao estejam em conformidade?

As penalidades vem de multiplas fontes. O PL 2.338 preve multas de ate R$ 50 milhoes por infracao para sistemas de IA de alto risco — e sistemas de saude sao expressamente classificados como alto risco. O AI Act europeu, para empresas com operacao internacional, preve penalidades de ate 35 milhoes de euros. A ANVISA possui estrutura sancionatoria propria que pode incluir multas, interdicao do produto, e apreensao — um dispositivo medico operando sem registro pode ser retirado do mercado. Alem disso, o CFM pode instaurar processo etico-disciplinar contra o medico que utilize sistemas em desacordo com a Resolucao 2.454/2026. As penalidades sao cumulativas — violar multiplas regulacoes resulta em multiplas sancoes.

Uma software house pode ser responsabilizada se o sistema de IA que construiu causar dano a um paciente?

Sim. O PL 2.338 distribui responsabilidade entre desenvolvedor e operador do sistema de IA. A software house que construiu o sistema pode ser responsabilizada pelas garantias tecnicas — se o sistema nao implementou explicabilidade adequada, se o audit trail era insuficiente, se testes de bias nao foram realizados, ou se a arquitetura nao garantia supervisao humana efetiva. A ANVISA tambem responsabiliza a cadeia de fabricacao do dispositivo medico. Por isso, contratar uma software house com experiencia em dominios regulados nao e apenas questao de qualidade tecnica — e gestao de risco juridico para ambas as partes.

Conclusao: conformidade como diferencial competitivo

A convergencia de ANVISA, CFM e PL 2.338 sobre sistemas de IA em saude cria um cenario regulatorio complexo, mas navegavel. Para healthtechs e instituicoes de saude que desejam inovar com IA diagnostica, a conformidade nao e barreira — e barreira de entrada que protege quem faz direito. Sistemas construidos com os sete pilares de conformidade desde a concepcao nao apenas atendem a regulacao — eles inspiram confianca clinica, facilitam adocao pelos profissionais de saude, e criam vantagem competitiva sustentavel.

A chave e escolher parceiros de construcao que compreendam tanto a tecnologia quanto a regulacao. A Mind Group, como software house com experiencia pratica na construcao de sistemas de IA em dominios sensiveis — incluindo o LawrAI, que escala IA juridica para mais de 20.000 usuarios com conformidade rigorosa — esta preparada para ajudar sua organizacao a construir sistemas de diagnostico assistido por IA que sejam tecnicamente excelentes, regulatoriamente conformes, e clinicamente confiaveis.

Fontes e referencias

• ANVISA — Resolucao da Diretoria Colegiada RDC 657/2022: Regulamentacao de Software como Dispositivo Medico (SaMD). Disponivel em: gov.br/anvisa
• Conselho Federal de Medicina — Resolucao CFM 2.454/2026: Uso de Inteligencia Artificial na medicina como ferramenta de apoio a decisao clinica. Vigencia: agosto de 2026.
• Senado Federal — Projeto de Lei 2.338: Marco Regulatorio de Inteligencia Artificial no Brasil. Classificacao de sistemas de saude como alto risco.
• Parlamento Europeu — AI Act (Regulamento de Inteligencia Artificial): Anexo III — classificacao de IA diagnostica como alto risco. Penalidades de ate 35 milhoes de euros.
• ANPD — Agenda Regulatoria 2026-2027: IA combinada com dados biometricos e de saude como alvo prioritario de fiscalizacao.
• IMDRF — International Medical Device Regulators Forum: Software as a Medical Device (SaMD) — Definition and Classification.
• LGPD — Lei Geral de Protecao de Dados Pessoais (Lei 13.709/2018): Art. 11 — Tratamento de dados pessoais sensiveis, incluindo dados de saude.
• ISO 14971:2019 — Medical devices — Application of risk management to medical devices.
• IEC 62304:2006/AMD1:2015 — Medical device software — Software life cycle processes.
• FDA — Digital Health Center of Excellence: Artificial Intelligence and Machine Learning (AI/ML) in Software as a Medical Device.

Escrito por José Gonçalves

CEO e fundador da Mind Group (fundada em 2016), software house brasileira sediada em Sorocaba/SP. Lidera o desenvolvimento de sistemas, aplicativos, IA e automações para clientes como Itaipu Binacional, Fisk, Lojas Torra, Febracis e Vertuz. Especialista em arquitetura de software, squads ágeis e integração de Inteligência Artificial em operações B2B.

LinkedIn →