Framework de As-Built em Engenharia: planejamento, governança, validação e aceite

Sumário executivo

O As-Built de engenharia deve ser tratado como um processo de gestão da informação da condição executada, e não como uma atividade gráfica concentrada no fim da obra. O objetivo deste framework é estabelecer uma arquitetura prática para transformar projeto, mudanças de campo, levantamentos, registros de execução, testes, documentos de fornecedores e decisões de engenharia em uma baseline final verificável para aceite, operação, manutenção e futuras intervenções.

A tese central é simples: o melhor As-Built começa antes da obra. Quando requisitos documentais, responsabilidades, regras de redline, matriz de documentos, critérios de verificação, formatos, status e evidências são definidos apenas no encerramento, o proprietário passa a reconstruir retrospectivamente informações que deveriam ter sido produzidas e controladas durante a implantação.

O método proposto organiza o processo em doze etapas e cinco gates de qualidade. Ele integra As-Built, Document Control, MDR, controle de mudanças, levantamento da condição existente, comissionamento, punch list, Data Book e handover em uma única cadeia de governança.

O resultado esperado não é apenas uma coleção de arquivos finais. É um conjunto de informações em que seja possível responder, de forma rastreável: o que foi executado, o que mudou, quem aprovou, como foi verificado, qual revisão representa a condição final e quais evidências sustentam o aceite.

Problema que o framework resolve

Os principais problemas de As-Built raramente são apenas erros de desenho. Eles decorrem de falhas de processo: redlines produzidos sem identificação de revisão, fotografias sem vínculo com ativos, alterações de campo não formalizadas, documentos de fornecedores incompatíveis com o projeto final, listas que não acompanham plantas, ajustes de comissionamento que não retornam aos diagramas e pacotes entregues sem critério de completude.

Quando isso acontece, o arquivo denominado “As-Built” pode ser apenas a última versão disponível, e não a representação confiável do ativo. A consequência aparece depois do aceite: manutenção trabalha com premissas erradas, expansões exigem novo levantamento, falhas são investigadas com documentação contraditória e a organização paga novamente para reconstruir sua própria informação.

Resultado esperado

Princípio 1 — As-Built é processo, não carimbo

O termo “As-Built” colocado no carimbo de um desenho não prova que a informação representa o executado. Para que a condição seja tecnicamente defensável, deve existir uma cadeia de produção e validação suficiente para relacionar a informação ao campo e às mudanças ocorridas durante a implantação.

Essa cadeia normalmente combina:

• projeto de referência e suas revisões;
• redlines controlados;
• registros de mudança;
• RFIs e decisões de engenharia;
• levantamentos e medições;
• documentos de fornecedores;
• registros de inspeção e testes;
• configurações finais;
• comissionamento;
• punch list;
• revisão e aprovação final.

O Projeto As-Built em Engenharia aprofunda a metodologia de elaboração. Este whitepaper trata da governança completa do processo.

Princípio 2 — requisitos de informação precisam nascer na contratação

O contrato deve dizer o que significa uma entrega As-Built aceitável. Expressões genéricas como “entregar todos os desenhos conforme construído” não definem disciplinas, formatos, responsabilidades, evidências, profundidade ou critérios de aceitação.

Uma especificação robusta deve tratar pelo menos de:

Essa lógica é coerente com a série ABNT NBR ISO 19650, que estrutura requisitos de informação, responsabilidades, produção, revisão, aceitação e transição entre fase de entrega e fase operacional quando BIM e gestão da informação são utilizados.

Arquitetura do framework

O processo é dividido em doze etapas. Elas podem ser adaptadas ao porte do empreendimento, mas a redução de formalidade não deve eliminar a rastreabilidade necessária.

1. Definir requisitos de As-Built e critérios de aceite.
2. Estabelecer baseline e Lista Mestra de Documentos.
3. Definir responsabilidades, códigos, revisões e workflow.
4. Capturar mudanças durante a execução.
5. Levantar e verificar a condição executada quando necessário.
6. Consolidar documentos por disciplina e sistema.
7. Executar QA/QC e coordenação multidisciplinar.
8. Incorporar resultados e ajustes de comissionamento.
9. Fechar pendências que afetam a documentação.
10. Emitir, revisar e aprovar a condição As-Built.
11. Reconciliar MDR, Data Book e pacote de handover.
12. Transferir a informação para operação e gestão do ativo.

Etapa 1 — requisitos e critérios de aceite

A parte requerente deve estabelecer quais decisões futuras dependerão da informação. Um As-Built destinado apenas à regularização de uma pequena reforma pode exigir profundidade diferente de uma baseline para retrofit industrial, manutenção de Data Center ou gestão de ativos em infraestrutura crítica.

O nível de informação deve ser proporcional ao uso. Isso evita dois extremos: documentação insuficiente ou produção onerosa de atributos que nunca serão utilizados.

Os critérios de aceite precisam ser mensuráveis. Exemplos:

• todos os documentos previstos no MDR emitidos na revisão final definida;
• nenhum documento crítico com status pendente;
• plantas, diagramas e listas reconciliados;
• ativos identificados de forma consistente entre campo e documentação;
• mudanças aprovadas incorporadas;
• resultados de comissionamento refletidos nos parâmetros finais;
• arquivos nativos entregues quando exigidos;
• punch list documental encerrada ou formalmente aceita.

Etapa 2 — baseline e MDR

Antes de registrar mudança é necessário saber em relação a qual revisão a mudança ocorreu. A baseline é a referência controlada da qual o As-Built evoluirá.

A Lista Mestra de Documentos (MDR) consolida o universo esperado e acompanha responsável, revisão, status, datas e condição de entrega. No contexto do As-Built, ela deve identificar quais entregáveis requerem revisão final e quais documentos são apenas registros complementares.

Quando o MDR não existe, o encerramento passa a responder “quais arquivos recebemos?” em vez de “quais documentos deveriam existir?”. Essa diferença é decisiva para demonstrar completude.

Etapa 3 — Document Control e responsabilidades

O Document Control fornece as regras que preservam identidade e histórico. Código documental, revisão, status, finalidade de emissão, responsável e transmittal precisam ser controlados ao longo do empreendimento.

Uma matriz simplificada de responsabilidades pode conter:

Etapa 4 — captura contínua de mudanças

Redlines são registros intermediários. Precisam indicar documento-base, revisão, data, responsável, natureza da alteração e referência à decisão correspondente quando aplicável.

Uma prática deficiente é acumular desenhos impressos marcados sem controle durante meses e digitalizá-los ao final. Uma prática madura vincula cada alteração ao documento correto e mantém um registro de mudanças suficientemente atualizado para impedir perda de contexto.

O Engineering Change Management (ECM) é relevante quando a mudança modifica escopo, desempenho, custo, prazo, requisito ou interface. Nem toda atualização de campo representa uma mudança de engenharia, mas toda mudança aprovada que altera a condição final deve repercutir na documentação correspondente.

Etapa 5 — levantamento e verificação da condição executada

Nem toda informação pode ser obtida de documentos. Em brownfields, obras sem controle adequado de alterações ou ativos antigos, é necessário reconstruir parte da condição por meio de campo.

O Levantamento Cadastral pode combinar inspeções, medições, identificação de ativos, fotografias, rastreamentos e análise documental. Em geometrias complexas, Laser Scanning 3D e nuvem de pontos podem aumentar a densidade de captura.

Entretanto, nenhuma tecnologia de captura identifica automaticamente função, circuito, lógica, fabricante, parâmetro, revisão ou requisito contratual. Geometria capturada não substitui verificação de engenharia.

Em edificações, a família normativa brasileira relacionada à documentação cadastral e ao “como construído” deve ser considerada conforme o objeto. O conteúdo NBR 14645 e As-Built apresenta a relação com a evolução normativa do levantamento cadastral.

Etapa 6 — consolidação por disciplina e sistema

A atualização deve ocorrer como conjunto coordenado. Uma alteração em equipamento pode afetar layout, alimentação elétrica, lista de cargas, rede de dados, automação, identificação, infraestrutura, manutenção e modelo BIM.

Por isso, a unidade de controle não deve ser apenas “o desenho”. É necessário identificar os documentos correlatos de cada sistema.

Conteúdos disciplinares como As-Built Elétrico, As-Built Arquitetônico e As-Built Hidrossanitário detalham particularidades por disciplina.

Etapa 7 — QA/QC e coerência multidisciplinar

Uma revisão As-Built precisa verificar mais do que ortografia, layers e carimbos. O QA/QC deve buscar inconsistências entre fontes.

Uma matriz de coerência pode verificar:

• tag em planta × lista de equipamentos;
• circuito em unifilar × quadro × planta;
• rota em modelo × planta × levantamento;
• equipamento instalado × datasheet × manual;
• parâmetro de teste × configuração final;
• identificação de ativo × CMMS/EAM/AIM;
• revisão em arquivo nativo × PDF emitido;
• mudança aprovada × documentos afetados.

A falha típica é cada disciplina validar apenas seus próprios desenhos. Em interfaces, a coerência precisa ser examinada pelo sistema.

Gate 1 — baseline aprovada

Nenhum processo de As-Built deveria avançar sem saber quais documentos representam a referência inicial e quais entregáveis serão controlados.

Gate 2 — mudança registrada

Alterações relevantes devem possuir evidência suficiente antes da consolidação. Mudança sem origem identificável não deve ser incorporada automaticamente.

Gate 3 — condição verificada

A informação que depende de campo precisa ser verificada pelo método definido. Inferências devem ser explicitadas e não apresentadas como medição.

Gate 4 — pacote tecnicamente coerente

Antes da emissão final, documentos correlatos devem ser reconciliados e pendências documentais classificadas.

Gate 5 — entrega aceita e transferida

O pacote final precisa ser confrontado com MDR, Data Book e requisitos de handover antes de se tornar baseline operacional.

Etapa 8 — comissionamento como fonte de configuração final

Durante o Comissionamento, sistemas podem sofrer ajustes finais de setpoint, endereçamento, proteção, balanceamento, lógica e integração. A ABNT NBR IEC 62337:2020 determina, no contexto de seu escopo industrial, que alterações e modificações efetuadas durante o comissionamento sejam documentadas.

Assim, a revisão As-Built não deve ser congelada antes de os testes relevantes demonstrarem a configuração realmente entregue.

A cadeia recomendada é:

teste → ajuste aprovado → registro → reteste → atualização documental → revisão final.

Etapa 9 — punch list documental

Uma correção física pode reabrir documentação já preparada. A Punch List deve, portanto, indicar repercussões documentais.

Exemplos:

• equipamento substituído exige atualização de planta, lista, manual e ativo;
• mudança de rota exige planta, modelo e interferências;
• ajuste de proteção exige diagrama, estudo e registro de parametrização conforme escopo;
• mudança de endereço exige topologia, lista de pontos e backup;
• correção de identificação exige campo e documentação.

A pendência só deve ser considerada encerrada quando as evidências e documentos afetados estiverem coerentes.

Etapa 10 — emissão e status final

A organização deve definir claramente qual revisão/status representa a condição final. Termos como AFC, IFC, As-Built, Final, Record Drawing e Approved podem possuir significados diferentes entre empresas e contratos.

O importante é impedir ambiguidade: deve existir uma regra contratual de identificação da revisão final e do fluxo de aceite.

Antes da emissão, recomenda-se verificar:

• código e título;
• revisão e histórico;
• status/finalidade;
• assinaturas ou aprovações requeridas;
• coerência entre nativo e PDF;
• links e referências cruzadas;
• lista de documentos afetados;
• punch list documental;
• registro de transmittal.

Etapa 11 — Data Book e reconciliação final

O Data Book de Obra é mais amplo que o As-Built. Pode incluir relatórios, certificados, inspeções, FAT/SAT, manuais, garantias, comissionamento, treinamentos e demais evidências.

A reconciliação final deve comparar três universos:

1. o que o contrato e o MDR exigiam;
2. o que foi efetivamente produzido e aceito;
3. o que a operação precisa receber.

Qualquer diferença precisa estar formalmente tratada.

Etapa 12 — handover e ciclo de vida

O Handover Técnico transfere o ativo e a informação para a operação. Em ambientes BIM, a série ABNT NBR ISO 19650 estrutura a passagem de informação relevante do PIM para o AIM e sua continuidade durante a fase operacional.

O As-Built só produz valor ao longo do ciclo de vida se for recuperável, compreensível e mantido. Isso pode exigir integração com GED/EDMS, CDE, CMMS, EAM, sistemas de gestão de ativos ou outra estrutura corporativa.

A solução de Gestão de Documentos de Engenharia conecta codificação, revisões, status, listas mestras e rastreabilidade ao longo desse processo.

Framework de maturidade do As-Built

Indicadores para governança

Indicadores devem medir a qualidade do processo, não apenas quantidade de arquivos.

• % de documentos As-Built previstos emitidos — completude documental;
• % de redlines incorporados — fechamento das mudanças registradas;
• aging de comentários — tempo de resolução documental;
• documentos rejeitados por inconsistência — qualidade da primeira emissão;
• pendências com impacto documental — risco de baseline divergente;
• documentos reconciliados com testes — integração com comissionamento;
• entregáveis aceitos no primeiro ciclo — maturidade de QA/QC;
• diferença MDR × Data Book — lacunas de entrega.

As-Built em brownfield e retrofit

Em instalações existentes, o processo começa frequentemente sem baseline confiável. O conteúdo Projetos Brownfield mostra por que levantamento, interferências, operação ativa e documentação legada precisam ser tratados antes da intervenção.

Nesses casos, o framework deve separar três estados:

• condição existente antes da intervenção;
• modificações planejadas/executadas;
• condição final após testes e aceite.

Misturar os três estados é uma das principais causas de documentação final inconsistente.

As-Built Digital e BIM

O Modelo de As-Built Digital amplia o problema para geometria, propriedades, classificação, formatos e dados de ativos. Um modelo só deve ser chamado de As-Built quando os elementos que pretende representar tenham sido verificados segundo critérios estabelecidos.

LOD elevado não é sinônimo de informação confiável; digitalização não substitui governança.

Erros que o framework deve impedir

Checklist executivo de implantação

1. Definir finalidade e usuários do As-Built.
2. Formalizar escopo documental e disciplinas.
3. Estabelecer baseline.
4. Criar MDR e matriz de responsabilidades.
5. Definir processo de redline e mudança.
6. Planejar levantamento de campo.
7. Definir critérios de QA/QC.
8. Relacionar documentos por sistema.
9. Integrar registros de construção e fornecedores.
10. Integrar comissionamento e punch list.
11. Emitir revisão final controlada.
12. Reconciliar MDR e Data Book.
13. Executar recebimento técnico.
14. Transferir informação no handover.
15. Definir governança da informação durante a operação.

Conclusão

As-Built confiável é consequência de uma cadeia de engenharia bem governada. Quanto mais cedo o empreendimento define requisitos, baseline, responsabilidades e evidências, menor a necessidade de reconstrução documental no encerramento.

O framework apresentado transforma o As-Built de obrigação final em um processo contínuo:

requisito → baseline → execução → mudança → verificação → consolidação → QA/QC → comissionamento → punch list → revisão final → Data Book → aceite → handover → operação.

Essa sequência sustenta uma tese essencial para empreendimentos complexos: a instalação não está tecnicamente entregue enquanto a condição executada não estiver documentada, verificável e utilizável por quem assumirá o ativo.

Referências técnicas

• ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-1:2022. Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação — Parte 1: Conceitos e princípios. Catálogo ABNT.
• ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-2:2022. Gestão da informação — Parte 2: Fase de entrega de ativos. Catálogo ABNT.
• ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-3:2025. Gestão da informação — Parte 3: Fase operacional dos ativos. Catálogo ABNT.
• ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR IEC 62337:2020. Comissionamento de sistemas elétricos, de instrumentação e de controle de processos industriais — Fases e marcos específicos. Catálogo ABNT.

Materiais técnicos complementares

• Guia Completo de As-Built em Engenharia
• Projeto As-Built em Engenharia
• Data Book de Obra
• Handover Técnico em Engenharia
• Lista Mestra de Documentos (MDR)
• Serviço de As-Built de Engenharia