Seu software de laudo com IA precisa de registro na Anvisa? Como ler a RDC 751 antes de assinar

Por que a pergunta "tem registro na Anvisa?" quase sempre nasce torta

A pergunta pressupõe que exista uma resposta binária válida para qualquer software de saúde, e não existe. A Anvisa regula dispositivos médicos, e software só é dispositivo médico quando a finalidade de uso declarada pelo fabricante o coloca dentro dessa definição. É por isso que dois produtos que usam exatamente o mesmo modelo de linguagem podem terminar em regimes diferentes: um deles diz que apoia a redação de um documento sob autoria médica, o outro diz que identifica achados em imagem. A tecnologia é a mesma; a promessa não é, e é a promessa que a norma lê.

O efeito prático dessa confusão é que a diligência de compra costuma parar no lugar errado. Pede-se um número de registro, recebe-se um "não se aplica", e a conversa acaba — sem que ninguém tenha lido a única frase que importa, que é a finalidade de uso escrita pelo fabricante. Essa frase é o documento que amarra tudo o que vem depois: classificação de risco, obrigações de instrução de uso, e o que o fornecedor pode ou não pode dizer no material comercial.

Este texto é escrito do ponto de vista de quem assina o contrato, não de quem submete o dossiê. Não substitui parecer regulatório nem jurídico. O objetivo é que o leitor termine capaz de fazer três perguntas específicas e de reconhecer, na resposta, se o fornecedor sabe do que está falando.

O que a RDC 751/2022 realmente classifica?

A RDC 751/2022 é a norma geral de regularização de dispositivos médicos: ela define as classes de risco, de I a IV, e os regimes correspondentes de notificação e registro. Software entra por regra própria — a Regra 11 —, que transpõe para o sistema brasileiro a lógica do IMDRF: o risco cresce conforme a informação produzida pelo software influencia decisão clínica e conforme a gravidade da condição do paciente envolvido. Um software cuja saída informa uma decisão em situação crítica não pode ser classificado como um software cuja saída organiza um documento administrativo.

Dois eixos, portanto, e não um. O primeiro é o peso da informação: ela trata, diagnostica, orienta tratamento, informa decisão clínica ou apenas apoia processo. O segundo é o contexto: condição crítica, séria ou não séria. A combinação dos dois é que produz a classe. Isso explica por que a resposta certa a "qual a classe de risco desse produto?" nunca é um número solto — é um número acompanhado da finalidade de uso que o justifica.

Para quem compra, a leitura útil dessa regra é ao contrário: em vez de perguntar a classe, descreva o uso que você pretende dar ao produto dentro do seu serviço e verifique se ele cabe na finalidade declarada. Um produto declarado como assistivo de redação usado, na prática, para priorizar fila por gravidade está sendo usado fora da finalidade — e o desvio é do serviço, não do fabricante.

O que a RDC 657/2022 acrescenta que ninguém lê

A RDC 657/2022 é a norma específica de software como dispositivo médico e complementa o arcabouço geral com requisitos de conteúdo. Ela estabelece que informações complementares precisam constar da instrução de uso ou do próprio software: procedimento de atualização, indicações de compatibilidade e incompatibilidade, informação de cibersegurança, alertas e advertências. Não é formalidade de dossiê — são justamente os pontos que decidem se o produto continua seguro depois de instalado.

Vale reler a lista pensando em software que muda sozinho. "Procedimento de atualização" é a pergunta de quem precisa saber o que acontece com o comportamento clínico do produto quando o fabricante publica uma versão nova sem avisar. "Incompatibilidade" é a pergunta de quem opera um parque heterogêneo de estações e navegadores. "Cibersegurança" é a pergunta de quem responde por dado de paciente. Os três aparecem em toda análise de incidente e quase nunca aparecem em proposta comercial.

• Como o fornecedor informa uma mudança de comportamento do produto, e com quanta antecedência.
• Quais versões de navegador, estação e integração são suportadas — e quais deixaram de ser.
• O que o produto registra sobre o próprio funcionamento, e por quanto tempo esse registro sobrevive.
• Quais alertas e advertências o produto exibe ao usuário, e em que momento do fluxo.

Onde fica um software que só escreve o laudo?

Um produto que capta o ditado do radiologista, transcreve, estrutura o texto conforme o modelo da casa e devolve o documento para revisão tem uma finalidade descritível em uma frase: apoiar a redação de um laudo cuja autoria, revisão e assinatura permanecem do médico. Ele não interpreta a imagem, não emite diagnóstico autônomo, não assina e não libera. Essa é a finalidade de uso que a Laudos.AI declara publicamente, com o papel assistivo e os limites escritos em /metodologia e /conformidade — e é o mesmo texto que precisa aparecer em contrato, não só em página institucional.

A fronteira fica visível quando se imagina o passo seguinte. No momento em que o mesmo produto passa a ordenar a fila por probabilidade de achado grave, a sinalizar exames para leitura prioritária ou a sugerir uma hipótese diagnóstica a partir do pixel, a informação produzida passa a influenciar decisão clínica de outro jeito, e a conversa regulatória muda. Não é uma questão de intenção do fabricante: é a natureza da saída.

Por isso a pergunta a fazer ao fornecedor não é "vocês têm IA?" — todo mundo tem — e sim "o que exatamente a saída do produto afirma, e quem decide depois dela?". Se a resposta for uma frase que descreve um documento sob autoria médica, ela precisa estar escrita. Se for uma frase que descreve um achado, um risco ou uma prioridade clínica, o enquadramento precisa acompanhar.

Anvisa e CFM cobrem a mesma coisa?

Não. São eixos independentes que às vezes olham o mesmo produto. A Anvisa regula o dispositivo: o que ele é, que risco oferece, o que precisa constar da instrução de uso, quem responde pela colocação no mercado. A Resolução CFM 2.454/2026 regula o ato médico: quem decide, quem responde pela decisão, o que precisa ser registrado e informado quando há apoio de IA na assistência. Um produto perfeitamente regularizado pode ser usado de maneira que viola a resolução, e um uso impecável do ponto de vista deontológico não regulariza um produto que precisaria estar regularizado.

Essa separação tem uma consequência que costuma passar batida na negociação: nenhum dos dois eixos transfere para o fornecedor a responsabilidade do médico que assina o laudo. O contrato reparte obrigações entre as partes — suporte, disponibilidade, segurança, notificação de mudança —, mas a assinatura continua sendo um ato pessoal. Quem trata o certificado do fornecedor como blindagem própria está lendo o documento errado.

O que pedir antes de assinar

A diligência que funciona é curta e escrita. Ela não depende de conhecimento regulatório profundo: depende de exigir que o fornecedor coloque no papel o que já deveria estar no papel, e de comparar esse papel com o que ele diz publicamente. Incoerência entre os dois é o achado mais comum e o mais barato de encontrar.

Vale guardar as respostas junto do contrato, não na caixa de e-mail de quem negociou. Em auditoria, acreditação ou incidente, quem precisa da informação raramente é quem participou da compra — e um documento que ninguém acha equivale a um documento que não existe.

1. A finalidade de uso declarada, em texto integral, e não um resumo comercial dela.
2. O enquadramento regulatório afirmado pelo fabricante, com a justificativa: se é dispositivo, a classe e o número; se não é, por quê.
3. A instrução de uso, com procedimento de atualização, compatibilidades, informação de cibersegurança, alertas e advertências.
4. A política de notificação de mudança de comportamento do produto, com prazo.
5. A frase do material comercial que mais se aproxima de uma promessa clínica — e a confirmação, por escrito, de que ela é compatível com a finalidade declarada.
6. A repartição contratual de responsabilidades ao longo da cadeia, incluindo suboperadores.

O erro mais caro é o silencioso

O risco que aparece nos casos difíceis não é o de comprar um produto irregular — esse costuma ser detectado. É o de comprar um produto corretamente enquadrado como assistivo e passar a usá-lo, com o tempo, como se fosse outra coisa. O desvio acontece devagar e por bons motivos operacionais: alguém percebe que a saída ajuda a decidir o que ler primeiro, alguém passa a confiar no texto sem reler, alguém encurta a revisão porque a fila cresceu. Nenhum desses passos é uma decisão registrada em ata.

A defesa contra isso não é regulatória, é operacional: escrever o uso pretendido, treinar sobre ele, e medir. Se o serviço documenta que o produto apoia a redação sob revisão médica, então a revisão médica precisa ser observável — em tempo, em edição, em registro. É isso que separa uma declaração de finalidade de uso de uma ficção contratual.

Perguntas frequentes

Referências

1. RDC nº 751, de 15 de setembro de 2022 — regularização de dispositivos médicos, classes de risco e regras de classificação · Anvisa
2. RDC nº 657, de 24 de março de 2022 — software como dispositivo médico (SaMD) · Anvisa
3. Software as a Medical Device (SaMD): Clinical Evaluation e Risk Categorization Framework · IMDRF
4. Resolução CFM nº 2.454/2026 — uso de inteligência artificial na medicina · Conselho Federal de Medicina
5. Metodologia e limites declarados do produto · laudos.ai/metodologia e laudos.ai/conformidade

As referências apontam para diretrizes, sociedades e literatura consultadas. Este conteúdo é informativo e não substitui julgamento clínico ou aconselhamento jurídico.