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.
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
| Termo | Uso prático |
| NC | não conformidade; o desvio em relação ao requisito |
| RNC | Relatório de Não Conformidade; registro usado para controlar o desvio |
| NCR | sigla internacional comum para o relatório de não conformidade |
| CAR | Corrective Action Request; solicitação de ação corretiva |
| Punch item | pendência de conclusão; pode ou não ser uma NC |
| RFI | solicitaçã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.
| Bloco | Campos recomendados |
| Identificação | número, projeto, contrato, disciplina, data, emissor |
| Localização | área, sistema, subsistema, TAG, lote, equipamento |
| Requisito | documento, revisão, item ou cláusula, critério de aceite |
| Evidência | descrição, fotos, medição, teste, anexos |
| Classificação | tipo, criticidade, impacto, origem |
| Contenção | ação imediata, responsável, data |
| Disposição | retrabalho, reparo, substituição, rejeição, concessão |
| Correção | ação executada, responsável, prazo |
| Causa | causa imediata e causa raiz quando aplicável |
| Ação corretiva | ação, responsável, prazo, eficácia |
| Verificação | reinspeção, reteste, evidência final |
| Aprovações | executora, QA/QC, engenharia, Owner conforme regra |
| Fechamento | data, 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:
- aberto;
- contenção em andamento;
- aguardando disposição;
- disposição aprovada;
- em correção;
- aguardando verificação;
- aguardando ação corretiva;
- fechado;
- 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.
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ível | Critério ilustrativo |
| Baixo | impacto local e facilmente reversível |
| Médio | impacto funcional ou documental relevante |
| Alto | requisito crítico ou risco de retrabalho significativo |
| Crítico | seguranç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.
| Indicador | Leitura gerencial |
| abertas x fechadas | capacidade de acompanhar o fluxo |
| backlog total | passivo acumulado |
| idade média e máxima | velocidade e casos envelhecidos |
| criticidade | risco do estoque |
| disciplina | concentração técnica |
| fornecedor | desempenho da cadeia |
| causa | padrões recorrentes |
| reincidência | eficácia de ações corretivas |
| reabertura | qualidade do fechamento |
| impacto em gates | efeito 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
| Campo | Exemplo ilustrativo |
| RNC | PROJ-EL-RNC-023 |
| Sistema | QGBT-01 |
| Requisito | desenho aprovado Rev. 05 |
| Condição | componente instalado diverge do especificado |
| Evidência | fotos e inspeção IQ-044 |
| Criticidade | alta |
| Contenção | bloqueado para energização |
| Disposição | substituir e repetir testes |
| Responsável | contratada elétrica |
| Verificação | reinspeção + teste funcional |
| Status | aguardando 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
- requisito identificado;
- evidência inicial preservada;
- disposição aprovada;
- correção executada;
- reinspeção ou reteste concluído quando necessário;
- interfaces verificadas;
- causa e ação corretiva tratadas quando aplicáveis;
- eficácia avaliada quando requerida;
- documentos finais atualizados;
- anexos completos;
- fechamento aprovado pela autoridade definida;
- 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.
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
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.
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.
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.
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.
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.
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
- Não Conformidade: o que é, tipos, tratamento, causa raiz e ação corretiva na Engenharia
- Engenharia da Qualidade: o que é, responsabilidades, métodos e aplicação em projetos e obras
- Controle de Qualidade (QC): o que é, como funciona e aplicação na Engenharia
- Garantia da Qualidade (QA): o que é, como funciona e aplicação na Engenharia
Conteúdos técnicos correlatos
- Controle de Documentos em Engenharia: processo, revisões, transmittals e rastreabilidade
- Data Book de Obra: o que é, estrutura, documentos e critérios de aceite