Aprenda como estruturar um Relatório de Não Conformidade (RNC/NCR): campos, numeração, evidências, criticidade, disposição, correção, reteste, ações e fechamento.

Confira!

O Relatório de Não Conformidade — RNC, também chamado NCR (Nonconformance Report ou Non-Conformity Report, conforme a convenção adotada) — é o registro usado para documentar um requisito não atendido, a evidência do desvio, sua avaliação, a disposição técnica, as ações executadas e o fechamento. Em Engenharia, ele cria rastreabilidade entre a condição encontrada e a decisão que permitiu corrigir, rejeitar, reparar, substituir ou aceitar formalmente o item sob condições definidas.

Não existe um formulário universal de RNC aplicável a todo projeto. A ISO 9001 exige controle de saídas não conformes e tratamento de não conformidades e ações corretivas, mas o formato documental precisa ser definido pelo sistema de gestão e pelo contrato. Um bom RNC deve ser simples o suficiente para ser usado no campo e completo o suficiente para sustentar engenharia, fiscalização, auditoria, medição, comissionamento e handover.

O que é um RNC ou NCR

RNC é o documento ou registro eletrônico que materializa o processo de não conformidade. A não conformidade é o fato técnico — um requisito não atendido. O RNC é o mecanismo de governança que preserva esse fato, acompanha decisões e reúne evidências até o encerramento.

Essa distinção é importante. Uma organização pode ter uma NC sem um formulário formal de RNC, mas, em empreendimentos de maior complexidade, deixar o tratamento apenas em e-mails, mensagens ou atas costuma gerar perda de rastreabilidade.

O RNC deve responder, no mínimo:

  • o que foi encontrado;
  • qual requisito não foi atendido;
  • onde ocorreu;
  • qual item está afetado;
  • qual evidência comprova o desvio;
  • qual é a criticidade;
  • que contenção foi adotada;
  • qual disposição foi aprovada;
  • quem deve corrigir;
  • como a correção será verificada;
  • se existe causa sistêmica;
  • se é necessária ação corretiva;
  • quem possui autoridade para fechar;
  • quais documentos e registros ficam vinculados.
Estrutura lógica de um Relatório de Não Conformidade do registro ao fechamento

Identificação

Requisito e evidência

Criticidade e contenção

Disposição técnica

Correção

Reinspeção ou reteste

Ação corretiva quando aplicável

Fechamento

Estrutura lógica de um Relatório de Não Conformidade do registro ao fechamento

RNC não é apenas um formulário

O erro mais comum é tratar o RNC como uma folha a ser preenchida e arquivada. O documento só gera valor quando representa um workflow real.

Um RNC pode estar “completo” administrativamente e ainda ser tecnicamente fraco. Isso acontece quando descreve a falha sem citar requisito, possui fotografia sem localização, registra apenas “corrigido”, não informa quem aprovou a disposição, fecha antes do reteste ou deixa de atualizar documentos afetados.

O formulário é a interface. A governança é o processo por trás dele.

RNC, NC, NCR, CAR e punch item

TermoUso prático
NCnão conformidade; o desvio em relação ao requisito
RNCRelatório de Não Conformidade; registro usado para controlar o desvio
NCRsigla internacional comum para o relatório de não conformidade
CARCorrective Action Request; solicitação de ação corretiva
Punch itempendência de conclusão; pode ou não ser uma NC
RFIsolicitação de informação; não substitui NC já constatada

A nomenclatura deve ser definida no Plano da Qualidade e no procedimento do empreendimento. A consistência do fluxo é mais importante que a escolha entre RNC e NCR.

A ISO 9001 exige um formulário específico?

Não. A ISO 9001 estabelece requisitos para controlar saídas não conformes e tratar não conformidades e ações corretivas, mas não determina um layout universal. O registro pode ser um formulário, um workflow digital em CDE ou plataforma de engenharia, ou outro mecanismo capaz de preservar informação documentada apropriada.

Em projetos com múltiplas empresas, disciplinas e contratos, um registro estruturado normalmente é necessário para evitar decisões dispersas em e-mails.

Quando abrir um RNC

Abra RNC quando existe evidência de que um requisito aplicável não foi atendido e o desvio exige tratamento formal.

Exemplos típicos:

  • material divergente da especificação;
  • equipamento diferente do aprovado;
  • teste reprovado;
  • execução fora de desenho válido;
  • dimensão fora de tolerância;
  • ausência de rastreabilidade obrigatória;
  • configuração lógica fora da baseline;
  • item instalado sem aprovação requerida;
  • lote sem documentação exigida;
  • requisito técnico incorreto em documento emitido.

Quando usar outro fluxo

Nem toda ocorrência deve virar RNC. Pendência de atividade em andamento pode ser controlada como pendência; dúvida antes da execução pode ser RFI; alteração proposta deve passar por change management; punch list organiza itens de conclusão.

A regra prática é identificar se existe requisito não atendido. Se sim, a ocorrência pode demandar RNC, mesmo que também esteja relacionada a RFI, punch list ou mudança.

Campos essenciais de um RNC

Um modelo robusto pode ser organizado em blocos.

BlocoCampos recomendados
Identificaçãonúmero, projeto, contrato, disciplina, data, emissor
Localizaçãoárea, sistema, subsistema, TAG, lote, equipamento
Requisitodocumento, revisão, item ou cláusula, critério de aceite
Evidênciadescrição, fotos, medição, teste, anexos
Classificaçãotipo, criticidade, impacto, origem
Contençãoação imediata, responsável, data
Disposiçãoretrabalho, reparo, substituição, rejeição, concessão
Correçãoação executada, responsável, prazo
Causacausa imediata e causa raiz quando aplicável
Ação corretivaação, responsável, prazo, eficácia
Verificaçãoreinspeção, reteste, evidência final
Aprovaçõesexecutora, QA/QC, engenharia, Owner conforme regra
Fechamentodata, status, responsável, comentários finais

Numeração do RNC

A numeração precisa ser única e rastreável. Não existe padrão obrigatório, mas uma convenção pode incorporar projeto, disciplina e sequência, por exemplo PROJ-QA-RNC-001, CLIENTE-EL-RNC-0042 ou SITE-CIV-NCR-017.

Evite códigos excessivamente complexos. Se o sistema já armazena metadados como disciplina e contrato, o identificador pode ser simples. O requisito central é que não mude depois de emitido.

Renumerar RNCs quebra referências cruzadas em atas, relatórios e Data Books. Se a classificação for corrigida posteriormente, preserve o número e registre a alteração no histórico.

Status do workflow

Estados precisam ter significado objetivo. Uma sequência típica pode incluir:

  1. aberto;
  2. contenção em andamento;
  3. aguardando disposição;
  4. disposição aprovada;
  5. em correção;
  6. aguardando verificação;
  7. aguardando ação corretiva;
  8. fechado;
  9. reaberto.

Evite status vagos como “resolvido” sem definir se isso significa correção executada, reinspeção concluída ou aprovação final.

Como escrever a descrição da não conformidade

Um RNC só é defensável quando separa requisito, fato observado e evidência. Em auditorias técnicas, registros vagos costumam ser uma das primeiras fontes de disputa entre fiscalização e contratada.

Conheça a Auditoria Técnica de Engenharia

Uma boa descrição separa requisito e condição encontrada.

Estrutura recomendada

Requisito: identificar documento, revisão, item ou critério que determina a condição esperada.

Condição encontrada: registrar objetivamente o que foi observado, medido ou testado.

Evidência: relacionar fotografias, registros de inspeção, medição, resultados de teste ou documentos.

Essa estrutura é superior a frases como “instalação errada”, que misturam julgamento e fato.

Referência documental e revisão

O RNC deve indicar a revisão do documento válida no momento da execução. Essa informação é essencial quando o projeto possui mudanças frequentes.

Sem revisão, pode surgir uma disputa legítima: a equipe executou conforme Rev. 02, enquanto a fiscalização avaliou usando Rev. 03 emitida depois. O controle de configuração precisa permitir reconstruir qual baseline estava vigente.

Evidência fotográfica

Fotografia precisa de contexto. Sempre que possível, registre visão geral do local, detalhe do desvio, identificação do item ou TAG e referência dimensional quando necessária.

A foto deve estar vinculada ao RNC de forma estável. Nomes genéricos como IMG_4521.jpg dificultam auditoria meses depois.

Medição e resultado de teste

Quando a NC nasce de medição ou teste, o RNC deve relacionar o relatório original e preservar contexto: instrumento, método, condição, critério de aceitação, resultado e responsável.

A reprovação inicial não deve desaparecer quando o teste é repetido após correção. O histórico mostra o que ocorreu e por que o reteste foi necessário.

Localização e rastreabilidade física

Em obra, use informações suficientes para localizar novamente o item:

  • área;
  • pavimento;
  • ambiente;
  • eixo;
  • circuito;
  • TAG;
  • trecho;
  • equipamento;
  • lote;
  • coordenada ou referência BIM, quando disponível.

O objetivo é permitir que outra pessoa reinspecione sem depender da memória do emissor.

Classificação da origem

Classificar a origem ajuda a identificar tendências. Categorias úteis incluem projeto, suprimentos, fabricação, recebimento, armazenamento, construção, montagem, configuração, documentação, teste e comissionamento.

Evite dezenas de categorias sobrepostas. A taxonomia deve ser estável para que dashboards tenham significado.

Classificação da criticidade

Criticidade precisa seguir critérios, não percepção individual.

NívelCritério ilustrativo
Baixoimpacto local e facilmente reversível
Médioimpacto funcional ou documental relevante
Altorequisito crítico ou risco de retrabalho significativo
Críticosegurança, requisito legal, missão crítica ou bloqueio de operação

Também podem ser considerados detectabilidade, extensão, acessibilidade futura, custo e efeito em interfaces.

Contenção no próprio RNC

Se existe risco de propagação, registre contenção imediatamente.

Ao encontrar um lote de componentes inadequados, por exemplo, pode ser necessário bloquear novas instalações, segregar materiais e identificar pontos já executados com o mesmo lote.

Contenção deve possuir responsável, prazo e evidência. Ela não substitui a correção definitiva.

Proposta de disposição

A disposição responde o que fazer com o item não conforme. As opções podem incluir retrabalho, reparo, substituição, rejeição, retorno ao fornecedor, reclassificação ou aceitação sob concessão.

Evite respostas como “corrigir”. A proposta deve descrever método e condições.

Quem aprova a disposição

A autoridade depende do contrato e da criticidade. A executora normalmente propõe; QA/QC verifica o processo; Engenharia pode avaliar impacto técnico; o Owner pode precisar aprovar qualquer alteração ao requisito original.

Um princípio importante é separar execução de autoridade de aceite. Quem executa não deve alterar unilateralmente requisito do cliente.

Concessão e aceite como está

Quando a condição permanecer diferente do requisito original, a decisão deve registrar impacto técnico, justificativa, restrições, efeito sobre garantia, necessidade de atualização documental e autoridade que aprovou.

Aceitar sob concessão não apaga a história da NC. Ao contrário, o registro deve preservar exatamente por que o desvio foi aceito.

Correção executada

A descrição da correção precisa ser auditável.

Fraco: “corrigido conforme solicitado”.

Melhor: “componente Y removido e substituído por modelo X; conexões refeitas; identificação atualizada; teste funcional repetido conforme relatório RT-014”.

O segundo registro permite entender o que mudou e qual evidência sustenta o fechamento.

Reinspeção e reteste

Após a correção, a conformidade precisa ser verificada. Em alguns casos basta reinspeção visual; em outros, é necessário repetir medição, teste funcional, ensaio de desempenho ou etapa de comissionamento.

Se a correção alterou uma interface, o reteste pode precisar se estender a sistemas adjacentes.

Causa raiz no RNC ou em documento separado

Depende da complexidade. NCs simples podem usar um campo no próprio RNC. Investigações maiores podem gerar relatório de causa vinculado.

O RNC deve funcionar como registro mestre e não necessariamente armazenar toda análise dentro do mesmo documento.

Correção x ação corretiva

Correção trata o item. Ação corretiva atua sobre a causa para evitar recorrência.

Exemplo:

  • correção: substituir os equipamentos instalados incorretamente;
  • causa: equipe usou lista de materiais obsoleta;
  • ação corretiva: alterar controle de revisão e bloquear acesso a versões superadas.

Se o RNC não diferenciar esses conceitos, o sistema tende a fechar ocorrências sem aprender.

Verificação de eficácia

Uma ação corretiva pode exigir observação posterior. Emitir um novo procedimento não prova eficácia. É preciso verificar se novas entregas seguem o processo corrigido e se a recorrência desapareceu.

Uma prática possível é fechar a NC física e manter a ação corretiva sistêmica em workflow próprio até validar eficácia.

RNC de projeto

RNC também pode tratar documentos de engenharia. Exemplos: cálculo incompatível com requisito, desenho sem interface necessária, especificação divergente do contrato ou lista de materiais inconsistente.

A correção precisa avaliar impacto em documentos derivados, compras e execução já realizada.

RNC de fornecedor e fabricação

Em vendor inspection, o NCR deve estar ligado a pedido, item, lote, desenho e ITP. Dependendo da criticidade, pode bloquear expedição até aprovação da disposição e reinspeção.

Reparos relevantes podem exigir procedimento específico, testemunho do Owner e inclusão no Data Book.

RNC de obra

Em campo, localização é essencial. Quando existem dezenas de ocorrências repetidas, pode ser mais eficiente abrir uma RNC sistêmica com lista dos itens afetados em vez de centenas de registros idênticos, desde que cada ocorrência continue rastreável.

O objetivo é controlar o problema sem criar burocracia que inviabilize o próprio fechamento.

RNC de software e automação

Evidências podem incluir versão, firmware, configuração, log, screenshot, parâmetro, backup e ambiente de teste. A correção pode exigir change management e teste de regressão.

Um parâmetro incorreto em PLC, relé, firewall ou VMS pode ser uma NC mesmo sem qualquer defeito físico visível.

RNC em FAT e SAT

Falhas durante FAT e SAT devem estar vinculadas aos procedimentos e critérios de aceitação. O procedimento do projeto precisa definir quais classes de NC bloqueiam expedição, instalação, energização, operação ou aceite final.

Não se deve liberar equipamento crítico apenas porque a data de embarque chegou, ignorando RNCs relevantes.

Relação entre RNC e Data Book

RNCs relevantes fazem parte do histórico técnico. O Data Book deve permitir visualizar que desvios ocorreram, como foram tratados e quais permaneceram sob concessão.

Ocultar registros fechados elimina informação útil. O projeto pode incluir índice de RNCs e anexos conforme criticidade e regra documental.

Relação entre RNC e As Built

Se a disposição aprovada modifica a condição final, o As Built precisa refletir a decisão. Aceitar uma solução diferente no RNC e manter o desenho antigo cria inconsistência entre campo e documentação.

O fechamento deve verificar impacto documental antes de encerrar.

Relação entre RNC e medição contratual

O contrato precisa definir se uma NC bloqueia medição ou pagamento. Dependendo da criticidade, o serviço físico pode estar executado mas ainda não ser tecnicamente aceitável.

Possibilidades incluem bloqueio de medição, retenção, reconhecimento parcial ou aceite com pendência. A regra deve existir antes do conflito.

RNC e gestão de mudanças

Quando a disposição altera o baseline, pode ser necessário abrir change request. O RNC registra o desvio; o processo de mudança avalia e aprova consequências sobre requisito, custo, prazo, interfaces e documentação.

Os dois registros devem ficar vinculados.

Dashboard de RNCs

Quando a quantidade de RNCs cresce, planilhas isoladas rapidamente perdem controle de responsáveis, documentos, prazos e aprovações. A governança precisa transformar a base em workflow rastreável.

Veja a solução de Gestão de Pendências, RFIs e Não Conformidades

A base deve produzir inteligência.

IndicadorLeitura gerencial
abertas x fechadascapacidade de acompanhar o fluxo
backlog totalpassivo acumulado
idade média e máximavelocidade e casos envelhecidos
criticidaderisco do estoque
disciplinaconcentração técnica
fornecedordesempenho da cadeia
causapadrões recorrentes
reincidênciaeficácia de ações corretivas
reaberturaqualidade do fechamento
impacto em gatesefeito sobre marcos

A quantidade absoluta de RNCs não deve ser interpretada isoladamente. Uma organização que registra problemas com transparência pode ter números maiores que outra que simplesmente não documenta desvios.

Envelhecimento do backlog

Classificar por faixas ajuda a enxergar passivos: até 7 dias, 8–30, 31–60, 61–90 e acima de 90 dias, por exemplo. As faixas devem ser adaptadas ao projeto.

RNC antiga pode representar disputa técnica, peça aguardada, gargalo de aprovação ou item esquecido. A criticidade precisa ser analisada junto com a idade.

Priorização do backlog

Uma RNC crítica recente pode ter prioridade maior que uma NC documental antiga. A priorização pode combinar criticidade, idade, impacto em marcos e dependências.

Marcos relevantes incluem FAT, expedição, energização, SAT, recebimento provisório, operação assistida e handover.

Exemplo simplificado de RNC

CampoExemplo ilustrativo
RNCPROJ-EL-RNC-023
SistemaQGBT-01
Requisitodesenho aprovado Rev. 05
Condiçãocomponente instalado diverge do especificado
Evidênciafotos e inspeção IQ-044
Criticidadealta
Contençãobloqueado para energização
Disposiçãosubstituir e repetir testes
Responsávelcontratada elétrica
Verificaçãoreinspeção + teste funcional
Statusaguardando correção

O exemplo ilustra estrutura; não é modelo obrigatório.

Erros comuns em RNCs

  • abrir sem citar requisito;
  • registrar opinião em vez de fato;
  • anexar evidência sem contexto;
  • usar “erro humano” como causa final;
  • aceitar disposição sem autoridade;
  • fechar sem reinspeção ou reteste quando necessário;
  • esquecer impacto em As Built;
  • não preservar histórico;
  • misturar RFI, mudança e NC;
  • transformar RNC em punição e incentivar ocultação.

Como digitalizar o processo

Um sistema digital deve controlar identificador, permissões, workflow, histórico, anexos, responsáveis, prazos, notificações, vínculos com documentos/TAGs, dashboards e trilha de auditoria.

O ganho não é substituir papel por tela; é conectar informação e evitar múltiplas fontes de verdade.

Permissões e segregação de funções

O sistema pode separar quem abre, responde, propõe disposição, aprova, verifica e fecha. Essa segregação protege integridade e evita fechamento unilateral.

Em projetos menores, os papéis podem ser acumulados, mas a autoridade precisa permanecer clara.

SLA e escalonamento

Prazos podem variar por criticidade. RNC crítica pode exigir contenção imediata; alta pode exigir disposição rápida; itens de baixa criticidade podem seguir rotina normal.

Os prazos reais devem vir do contrato ou procedimento. O sistema deve escalar itens vencidos e mostrar impacto em marcos.

Reunião de qualidade

Reuniões periódicas devem focar exceções: RNCs críticas, vencidas, reincidentes, bloqueios de decisão, concessões, causas sistêmicas e fornecedores com tendência negativa.

Ler centenas de linhas sem priorização consome tempo e não melhora governança.

Auditoria do processo de RNC

Auditar RNCs significa verificar se requisitos estão identificados, criticidade é coerente, disposições têm autoridade, correções foram verificadas, ações corretivas são eficazes, prazos são gerenciados e documentação final reflete decisões.

A ISO 19011:2026 é referência atual para princípios e condução de auditorias de sistemas de gestão.

Preparação para handover

Antes do encerramento, reconcilie RNCs com punch list, lista mestra de documentos, FAT/SAT, testes de comissionamento, As Built, Data Book e concessões.

A equipe precisa saber quais itens bloqueiam aceite e quais podem permanecer sob condição formalmente aprovada.

Checklist de fechamento de RNC

  1. requisito identificado;
  2. evidência inicial preservada;
  3. disposição aprovada;
  4. correção executada;
  5. reinspeção ou reteste concluído quando necessário;
  6. interfaces verificadas;
  7. causa e ação corretiva tratadas quando aplicáveis;
  8. eficácia avaliada quando requerida;
  9. documentos finais atualizados;
  10. anexos completos;
  11. fechamento aprovado pela autoridade definida;
  12. rastreabilidade preservada para o handover.

Como a Owner’s Engineering usa o RNC

Para o Owner, o RNC é ferramenta de conformidade contratual e engenharia. Ele permite acompanhar performance de fornecedores, separar opinião de evidência e impedir que desvios sejam aceitos informalmente.

A Owner’s Engineering pode participar da abertura, análise, aprovação de disposição, verificação, escalonamento e consolidação para o handover.

Quando recuperar uma base de RNCs

Projetos em andamento podem acumular registros inconsistentes. Sinais de recuperação necessária incluem duplicidades, RNCs sem requisito, status indefinidos, itens fechados sem evidência, backlog antigo, planilhas divergentes, concessões informais e falta de vínculo com documentos.

A recuperação normalmente envolve saneamento da base, taxonomia, criticidade, reconciliação de evidências e definição de governança.

Considerações finais

O RNC é um registro técnico de decisão, não um simples formulário. Quando bem estruturado, conecta requisito, condição encontrada, evidência, criticidade, disposição, correção, verificação e aceite.

Em empreendimentos complexos, essa rastreabilidade protege o Owner, reduz discussões subjetivas, melhora o desempenho de fornecedores e cria uma base confiável para auditoria, comissionamento e handover. O melhor RNC permite reconstruir, meses ou anos depois, o que ocorreu, por que determinada decisão foi tomada e como foi demonstrado que o risco foi tratado.

No fechamento de obra, RNC, punch list, testes, As Built e Data Book precisam convergir. A fiscalização técnica ajuda a impedir que um item seja considerado concluído fisicamente sem que a evidência de conformidade esteja completa.

Conheça o Apoio Técnico à Fiscalização de Obras e Contratos

Referências técnicas

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 9001:2015 — Sistemas de gestão da qualidade — Requisitos. Rio de Janeiro: ABNT, 2015.

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9000:2026 — Quality management — Fundamentals and vocabulary. Genebra: ISO, 2026. Disponível em: https://www.iso.org/standard/9000

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 9001:2015 — Quality management systems — Requirements. Genebra: ISO, 2015. Disponível em: https://www.iso.org/standard/62085.html

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19011:2026 — Guidelines for auditing management systems. Genebra: ISO, 2026. Disponível em: https://www.iso.org/standard/19011

[5] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 10005:2018 — Quality management — Guidelines for quality plans. Genebra: ISO, 2018. Disponível em: https://www.iso.org/standard/70398.html

[6] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 10006:2017 — Quality management — Guidelines for quality management in projects. Genebra: ISO, 2017. Disponível em: https://www.iso.org/standard/70376.html

[7] PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge — PMBOK Guide. 8. ed. Newtown Square: PMI, 2025.

Perguntas frequentes
O que é um RNC?

RNC é o Relatório de Não Conformidade, registro utilizado para documentar um requisito não atendido, evidências, criticidade, disposição, correção, verificações e fechamento.

RNC e NCR são a mesma coisa?

Em muitos projetos, sim. NCR é a sigla em inglês normalmente usada para Nonconformance Report ou Non-Conformity Report. O procedimento do empreendimento deve padronizar a nomenclatura.

A ISO 9001 exige um formulário específico de RNC?

Não. A norma exige controle e informação documentada apropriada para não conformidades, mas não impõe um modelo universal de formulário.

O que deve constar em um RNC?

Identificação, requisito, condição encontrada, evidência, localização, criticidade, contenção, disposição, correção, responsáveis, prazos, verificação, ações corretivas quando aplicáveis, aprovações e fechamento.

Quem deve aprovar um RNC?

Depende do contrato e da criticidade. A parte executora pode propor disposição, mas alterações de requisitos do cliente normalmente precisam de autoridade técnica ou contratual apropriada.

Uma fotografia basta para fechar um RNC?

Nem sempre. O fechamento deve demonstrar atendimento ao critério aplicável. Pode exigir reinspeção, medição, reteste, análise documental ou atualização de configuração além da fotografia.

Materiais técnicos complementares

Conteúdos principais sobre o tema

Conteúdos técnicos correlatos

Soluções relacionadas

Serviços relacionados