Projeto As-Built em Engenharia: como elaborar, documentos e critérios de aceite

Entenda como elaborar um Projeto As-Built, registrar alterações de campo, consolidar documentos, validar a condição executada e preparar a entrega para aceite, operação e manutenção.

Confira!

A documentação as-built é o conjunto de registros técnicos revisados para representar a condição efetivamente executada de uma instalação, sistema, edificação ou infraestrutura. Ela consolida alterações de campo, interfaces finais, identificações, características instaladas, configurações e evidências necessárias para que operação, manutenção, auditoria e futuros projetos trabalhem sobre uma base confiável.

O as-built não deve ser produzido apenas no encerramento, por meio de uma tentativa tardia de reconstruir o que aconteceu na obra. Sua qualidade depende da captura contínua das mudanças durante a execução, do controle das revisões, da participação das disciplinas envolvidas e da validação entre documentos, condições de campo, ensaios e configurações finais. Quando essa cadeia não existe, a entrega pode ter aparência de projeto concluído sem representar fielmente o ativo.

Este artigo trata especificamente de como estruturar e elaborar um Projeto As-Built sob a perspectiva da engenharia consultiva e da governança técnica. O foco está no método de produção, nos documentos e dados que compõem a entrega, na consolidação das alterações de campo, nos critérios de validação e na integração com o ciclo de vida do ativo. O objetivo é mostrar como transformar redlines, registros de execução, levantamentos e evidências dispersas em uma base documental verificável, útil e contratualmente defensável.

Projeto As-Built: diferenças para Projeto Executivo, redline e levantamento cadastral

As-built significa “como construído” ou “como executado”. É a documentação final revisada para corresponder à condição implantada, incluindo as modificações ocorridas entre o projeto aprovado e a execução. A ABNT NBR 5410, em seu item 6.1.8.2, estabelece para instalações elétricas de baixa tensão que a documentação do projeto deve ser revisada e atualizada após a conclusão para corresponder fielmente ao que foi executado.

O princípio ultrapassa a disciplina elétrica. Em qualquer sistema de engenharia, a documentação final precisa permitir identificar o que existe, onde está, como se conecta, quais características possui e em qual configuração foi entregue. A profundidade varia conforme o escopo, a criticidade, as exigências contratuais, as normas aplicáveis e as necessidades futuras de operação e manutenção. Para a visão ampla do conceito, requisitos, validação, Data Book, handover e ciclo de vida, o Guia Completo de As-Built em Engenharia funciona como hub desta trilha técnica.

Projeto Executivo e As-Built não são a mesma etapa

O Projeto Executivo de Engenharia define com detalhamento suficiente o que deve ser executado. O as-built registra o que foi efetivamente implantado. Em uma execução ideal, a condição final permanece próxima do projeto executivo; ainda assim, identificações, rotas, cotas, modelos, números de série, parâmetros, revisões de fabricante e ajustes de campo precisam ser consolidados.

O as-built não deve substituir a engenharia que faltou antes da obra. Quando soluções fundamentais são decididas apenas em campo, sem cálculo, compatibilização ou aprovação, a simples atualização do desenho não regulariza automaticamente a decisão. A documentação final registra a condição executada, mas não elimina a necessidade de verificar conformidade, desempenho, responsabilidade técnica e atendimento aos requisitos.

Redline é registro de alteração, não entrega final

Redline é a marcação de campo utilizada para indicar mudanças sobre desenhos ou documentos controlados. Pode registrar deslocamentos, exclusões, inclusões, alterações de rota, dimensões, equipamentos, conexões, identificações ou parâmetros. É uma entrada essencial para o processo, mas normalmente não constitui a documentação final.

Um redline precisa indicar documento de origem, revisão, data, responsável, descrição da alteração e referência à aprovação correspondente. Marcas sem identificação, fotografias soltas ou anotações em cópias não controladas tornam a consolidação posterior insegura. Depois de verificadas, as alterações devem ser incorporadas aos arquivos finais, submetidas à revisão técnica e emitidas na revisão definida para as-built.

Levantamento cadastral é uma forma de obtenção de dados

O levantamento cadastral identifica a condição existente por inspeção, medição, topografia, escaneamento, fotografia, teste, rastreamento de cabos, leitura de placas, exportação de configurações ou outras técnicas. Ele é indispensável quando os registros de execução são insuficientes ou quando a instalação já existe há anos sem documentação confiável.

Entretanto, levantamento cadastral e as-built não são sinônimos. O levantamento produz dados sobre a condição observada. O as-built transforma esses dados em documentação técnica coordenada, revisada, identificada e vinculada aos sistemas, requisitos e ativos. Dependendo do caso, o levantamento pode precisar ser complementado por ensaios, abertura de pontos, consulta a fornecedores e validação com profissionais responsáveis.

As-built, cadastro de ativos e dossiê de entrega

O as-built representa desenhos, diagramas, memoriais, listas e modelos atualizados. O cadastro de ativos organiza equipamentos e componentes em uma estrutura destinada à gestão, normalmente incluindo localização, identificação, fabricante, modelo, série, criticidade, garantia e plano de manutenção. O dossiê de entrega reúne documentação mais ampla, como certificados, ensaios, manuais, treinamentos, termos, pendências e garantias.

Esses elementos devem ser integrados, mas não confundidos. Um conjunto de plantas não substitui o cadastro de ativos; uma planilha de equipamentos não substitui diagramas e relações espaciais; e um dossiê volumoso não assegura que os documentos representem a condição instalada.

Produto documental	Finalidade	Exemplo de conteúdo
Projeto Executivo	orientar a execução	desenhos, cálculos, detalhes, especificações e listas aprovadas
Redline	registrar alterações durante a execução	marcações controladas, referências e aprovações
Levantamento cadastral	obter dados da condição existente	medições, inspeções, fotos, nuvem de pontos e rastreamentos
As-built	representar tecnicamente a condição final	plantas, diagramas, memoriais, listas e modelos atualizados
Cadastro de ativos	incorporar itens à gestão operacional	tag, localização, fabricante, série, garantia e manutenção
Dossiê de entrega	sustentar transferência e aceite	testes, certificados, manuais, treinamentos e termos

Como elaborar um Projeto As-Built durante a execução

A qualidade de um Projeto As-Built é definida antes do encerramento. O contrato e o plano de execução devem estabelecer documentos abrangidos, formatos, responsabilidades, periodicidade de atualização, método de captura, fluxo de aprovação e critérios de aceite. Sem essas regras, o trabalho tende a ser adiado até o final, quando equipes já foram desmobilizadas e informações de campo se perderam.

Em termos de processo, a elaboração deve percorrer uma sequência controlada: definir os requisitos e a matriz documental; capturar alterações e dados de campo; incorporar as mudanças aos arquivos de engenharia; coordenar documentos e disciplinas; verificar a fidelidade por evidências e inspeções; e somente então emitir a revisão final para aceite.

A Execução de Obras de Engenharia deve tratar a documentação final como parte do avanço, e não como pendência administrativa posterior. Pacotes executáveis, inspeções, medições e liberações precisam gerar evidências que alimentem o as-built por sistema, área, disciplina ou contrato.

Definição dos requisitos de informação

O primeiro passo é estabelecer o que o proprietário precisa receber para operar, manter, auditar, ampliar e contratar intervenções futuras. A lista não deve ser copiada de outro empreendimento sem análise. Um ativo simples pode exigir plantas, diagramas e manuais; uma infraestrutura crítica pode demandar bases de dados, parâmetros, arquivos nativos, modelos BIM, backups, inventários, relações de interface e históricos de configuração.

Os requisitos devem especificar formatos editáveis e não editáveis, convenções de nome, codificação, unidades, sistemas de coordenadas, nível de detalhe, atributos obrigatórios, estrutura de pastas, metadados, assinaturas, responsabilidades e ambiente de entrega. A ISO 19650-4 organiza processos e critérios de troca de informações para assegurar a qualidade dos modelos de informação de projeto e de ativos em ambientes BIM.

Matriz de documentos e responsabilidades

Uma matriz de as-built relaciona cada documento ao sistema, disciplina, responsável pela atualização, responsável pela verificação, fonte dos dados, formato e marco de entrega. Essa matriz evita lacunas entre projetista, executora, supervisora, integrador, fabricante e proprietário.

A responsabilidade precisa ser compatível com a origem da informação. A executora conhece alterações de montagem; o fornecedor possui dados finais do equipamento; o integrador controla configurações; o projetista avalia coerência técnica; a fiscalização ou o Owner’s Engineering verifica aderência ao contrato e às evidências. Concentrar toda a atualização em uma equipe que não participou das decisões aumenta o risco de inferências incorretas.

Elemento	Definição necessária
Documento-base	código, título, disciplina e revisão inicial
Fonte de atualização	redline, RFI, mudança aprovada, medição, inspeção ou dado de fornecedor
Responsável pela informação	parte que produz ou confirma o dado de campo
Responsável pela incorporação	profissional que atualiza o arquivo controlado
Verificação	responsável por conferir consistência técnica e documental
Formato final	PDF, DWG, RVT, IFC, XLSX, banco de dados, arquivo de configuração ou outro
Marco	emissão parcial, completação de sistema, aceite ou encerramento
Evidência	fotografia, relatório, certificado, teste, levantamento ou registro de aprovação

Captura contínua das alterações

A captura deve ocorrer no momento da alteração ou logo após a execução. Diários, inspeções, aplicativos de campo, modelos, relatórios fotográficos, RFIs e registros de mudança podem alimentar o processo, desde que utilizem identificação comum e controle de revisão.

Fotografias precisam ter contexto. Uma imagem isolada raramente demonstra localização, orientação, sistema e condição. O registro deve associar data, área, ativo, documento, descrição e responsável. Em elementos embutidos ou posteriormente inacessíveis, a documentação antes do fechamento é especialmente importante.

A solução de Aplicações de Campo, Inspeção e Coleta de Dados Técnicos permite estruturar essa captura, vinculando fotografias, observações e evidências aos itens técnicos que serão consolidados.

Controle de mudanças e rastreabilidade

Nem toda diferença entre projeto e campo é uma alteração aprovada. O processo deve distinguir ajuste de representação, correção de erro documental, adequação de montagem, substituição equivalente, desvio, mudança de escopo e solução de engenharia. Cada categoria pode exigir níveis diferentes de análise e aprovação.

A atualização do as-built deve manter a ligação entre condição final e histórico decisório. RFIs, ordens de mudança, aprovações de fornecedor, não conformidades, relatórios de inspeção e testes são fontes que explicam por que o documento mudou. Essa rastreabilidade é relevante para garantias, auditorias e futuras intervenções.

Emissões progressivas por sistema

Esperar a conclusão total do empreendimento para iniciar a consolidação aumenta o risco. Documentos podem ser emitidos progressivamente quando sistemas ou áreas atingem maturidade suficiente. Essa abordagem permite verificar qualidade, corrigir padrões e incorporar os dados à operação antes da desmobilização das equipes.

O cronograma deve reservar atividades e recursos para atualização, revisão e aceite. O Project Controls pode acompanhar avanço físico e avanço documental separadamente. Uma instalação concluída sem documentação correspondente não representa entrega integral do pacote.

Quais documentos e dados devem compor a entrega As-Built

O conteúdo depende do tipo de empreendimento, mas a entrega precisa representar geometria, conexões, características, identificação e configuração. O erro comum é limitar o as-built às plantas, ignorando diagramas, listas, memoriais e dados digitais que determinam o funcionamento real do sistema.

A ABNT NBR 5410 indica, para instalações elétricas de baixa tensão, plantas, esquemas, detalhes de montagem, memorial descritivo, especificações dos componentes e parâmetros de projeto como conteúdo mínimo da documentação a ser atualizada. Em outras disciplinas, normas específicas, requisitos do proprietário e contratos devem definir os elementos aplicáveis.

Desenhos, plantas e modelos

Plantas devem mostrar localização, rotas, dimensões, cotas, níveis, áreas, equipamentos, acessos, interferências relevantes e identificações finais. Cortes, detalhes e elevações precisam ser atualizados quando necessários para compreender montagem, operação ou manutenção.

Modelos BIM devem representar a condição acordada de entrega e possuir atributos compatíveis com os requisitos de informação. Um modelo visualmente detalhado, mas sem codificação, classificação, localização confiável ou dados de ativo, pode ter baixo valor operacional. Também é necessário esclarecer o que foi verificado em campo e o que permanece como informação de projeto.

Diagramas e relações funcionais

Diagramas unifilares, funcionais, de blocos, topologias, arquitetura de rede, causa e efeito, intertravamentos, fluxos e esquemas de conexão representam relações que não aparecem adequadamente em plantas. Eles precisam refletir equipamentos, portas, circuitos, enlaces, endereços, proteções, interfaces e redundâncias efetivamente implantadas.

Em sistemas elétricos, devem ser consolidados circuitos, cargas, proteções, ajustes e identificações dos quadros. Em redes e telecomunicações, rotas, racks, fibras, portas, enlaces, VLANs e topologias finais podem ser essenciais. Em automação e segurança eletrônica, listas de pontos, lógicas, zonas, permissões e integrações precisam corresponder à configuração entregue.

Memoriais, especificações e listas

O memorial descritivo final deve explicar a solução implantada, os limites do sistema, as interfaces e as principais alterações em relação ao projeto. Ele não deve repetir genericamente a especificação original quando a execução adotou equipamentos, métodos ou condições diferentes.

Listas de equipamentos, cabos, circuitos, pontos, instrumentos, sinais, materiais e documentos precisam utilizar a mesma codificação dos desenhos e do cadastro de ativos. Divergências de tag, nomenclatura ou localização entre arquivos tornam a consulta insegura e dificultam integração com manutenção.

Dados de equipamentos e configurações

A condição final inclui informações que não aparecem em desenhos: fabricante, modelo, número de série, firmware, licença, endereço, parâmetro, ajuste, versão de software, arquivo de configuração e backup. A profundidade deve respeitar segurança da informação, responsabilidade e necessidade operacional.

Credenciais não devem ser inseridas indiscriminadamente em documentos públicos ou de ampla circulação. O proprietário precisa receber acessos e chaves sob processo seguro, com controle de custódia, autorização e recuperação. O as-built deve indicar onde a configuração controlada está armazenada e qual versão corresponde ao aceite.

Ensaios, certificados e evidências

Relatórios de ensaio, certificados de calibração, resultados de certificação, registros de inspeção e documentos do Comissionamento em Engenharia não são desenhos as-built, mas validam a condição representada e integram o dossiê de entrega.

A ligação entre documento e evidência deve permitir responder quais itens foram inspecionados, testados e aceitos. Em instalações ocultas, fotografias georreferenciadas, medições ou registros antes do fechamento podem ser a única evidência disponível da execução.

Arquivos nativos e formatos de entrega

O contrato deve definir se serão entregues arquivos editáveis, PDFs assinados, modelos abertos, planilhas, bancos de dados e arquivos proprietários. Entregar apenas PDF pode limitar futuras atualizações; entregar apenas arquivos nativos pode comprometer preservação, visualização e formalidade.

Uma entrega robusta combina formato de registro e formato de uso. PDF preserva a emissão formal; DWG, RVT, IFC, XLSX ou bases estruturadas permitem continuidade técnica; formatos de configuração preservam parâmetros operacionais. A estrutura deve ser acompanhada por índice mestre, lista de documentos e regras de revisão.

Como validar a qualidade do As-Built antes do aceite

Receber arquivos não significa aceitar o as-built. A validação precisa verificar completude, fidelidade, consistência e usabilidade. O processo pode combinar análise documental, comparação com registros de execução, inspeção de campo, amostragem de ativos, testes e revisão pelas equipes que utilizarão a informação.

Em obras rodoviárias federais, instruções do DNIT tratam o projeto as-built como parte do recebimento e atribuem à fiscalização a aprovação em contextos específicos. Esse exemplo demonstra a relevância contratual da validação, mas cada empreendimento deve definir suas próprias responsabilidades e critérios.

Completude documental

A primeira verificação compara a matriz de documentos com a entrega. Devem ser avaliados códigos, revisões, formatos, assinaturas, arquivos nativos, metadados e vínculos com sistemas. Documentos cancelados, substituídos ou não aplicáveis precisam ter situação registrada para evitar dúvidas posteriores.

Completude não significa volume. Um dossiê com milhares de arquivos pode continuar incompleto se faltarem diagramas críticos, parâmetros finais, listas coordenadas ou documentação de interfaces. O índice mestre deve permitir localizar cada informação e identificar sua condição.

Fidelidade à condição executada

A fidelidade pode ser verificada por amostragem orientada por risco. Itens críticos, alterações relevantes, elementos ocultos, interfaces e áreas com histórico de não conformidade merecem maior profundidade. A inspeção deve comparar localização, identificação, característica e conexão com a documentação apresentada.

Quando a amostragem revela divergências sistemáticas, o problema não deve ser tratado como erro isolado. Pode ser necessário ampliar a verificação, revisar o método de elaboração e reemitir conjuntos inteiros. Aceitar documentos com base apenas em revisão visual do arquivo transfere risco ao proprietário.

Consistência entre documentos

Planta, diagrama, lista, memorial, modelo e cadastro precisam representar a mesma configuração. Um equipamento pode aparecer com tags diferentes, um circuito pode ter descrição incompatível com o quadro, ou a topologia pode não coincidir com a lista de portas. Essas divergências são comuns quando disciplinas e fornecedores atualizam arquivos sem coordenação.

A Gestão Eletrônica de Documentos Técnicos e Controle de Revisões ajuda a manter versões, aprovações e relações documentais. Entretanto, a plataforma não substitui a revisão de engenharia; ela oferece controle para que a revisão seja rastreável.

Qualidade dos dados e modelos

Em bases estruturadas, devem ser verificados campos obrigatórios, formatos, duplicidades, codificação, unidades, coordenadas, relações e valores inválidos. Em modelos BIM, critérios de troca de informação podem avaliar geometria, classificação, atributos, federação, interferências e capacidade de gerar o modelo de informação do ativo.

Dados precisam ser utilizáveis nos sistemas do proprietário. Uma planilha tecnicamente correta, mas incompatível com o cadastro de manutenção, pode exigir retrabalho. Os requisitos de importação e integração devem ser definidos antes da entrega final.

Marco de decisão para aceite do As-Built

Antes do aceite, confirme:

1. A matriz de documentos está completa e com situação definida.
2. As alterações de campo possuem origem e aprovação rastreáveis.
3. Desenhos, diagramas, listas, memoriais e modelos estão coordenados.
4. Arquivos formais e editáveis foram entregues nos formatos contratados.
5. Identificações e dados de ativos correspondem ao campo.
6. Configurações, parâmetros e backups possuem versão controlada.
7. Itens críticos foram verificados por inspeção ou evidência equivalente.
8. Pendências estão classificadas, atribuídas e com prazo definido.
9. Operação e manutenção conseguem localizar e utilizar a informação.
10. Responsabilidades, garantias e futuras atualizações estão formalizadas.

O resultado da verificação deve ser registrado em parecer, relatório ou termo de aceite. A solução de Gestão de Requisitos, Evidências e Critérios de Aceite permite relacionar exigências, documentos, inspeções, desvios e decisões.

Como integrar o As-Built à operação, manutenção e gestão de ativos

O valor do as-built aparece depois da obra. Ele reduz tempo de diagnóstico, orienta intervenções, sustenta manutenção, facilita expansões e preserva conhecimento. Para isso, a documentação não pode permanecer isolada em uma pasta de encerramento; precisa ser incorporada aos processos e sistemas utilizados pelas equipes.

A ISO 55001:2024 estrutura requisitos para sistemas de gestão de ativos orientados à geração de valor. A documentação final contribui para esse sistema ao fornecer informação sobre configuração, localização, condição, responsabilidades e requisitos ao longo do ciclo de vida.

Incorporação ao cadastro de ativos

A estrutura de ativos deve ser definida antes da entrega, com hierarquia, localizações, tags, classes, criticidade e atributos. O as-built alimenta essa base, mas os dados precisam passar por validação e normalização. Importações automáticas sem controle podem criar duplicidades, tags incompatíveis ou relações incorretas.

Equipamentos relevantes devem ser vinculados a documentos, garantias, manuais, planos, sobressalentes e históricos. O cadastro não deve depender de caminhos de arquivo conhecidos apenas pela equipe do projeto.

Manutenção e segurança das intervenções

Documentos confiáveis permitem localizar circuitos, isolamentos, válvulas, rotas, dispositivos, interfaces e pontos de acesso. Informação incorreta pode aumentar tempo de indisponibilidade e risco de intervenção. Por isso, a manutenção precisa participar da validação dos documentos que utilizará.

O manual do sistema deve complementar o as-built com modos de operação, limites, alarmes, intertravamentos, procedimentos e recomendações. A ABNT NBR 5410 também prevê manual do usuário em determinadas instalações sem equipe permanente qualificada, reforçando que a documentação precisa ser adequada ao perfil de quem a utilizará.

Gestão de configuração e atualizações futuras

As-built não deve ser tratado como fotografia imutável. Após o aceite, qualquer alteração relevante precisa gerar atualização controlada. A organização deve definir quem pode modificar documentos, quais eventos exigem revisão, como versões são aprovadas e qual repositório representa a condição vigente.

Mudanças em campo sem atualização criam distância crescente entre documento e ativo. Em sistemas digitais, o problema inclui firmware, software, regras, endereçamento e integrações. A gestão de configuração precisa abranger arquivos técnicos e condições operacionais.

Integração com operação assistida

Durante a operação inicial, podem ocorrer ajustes de parâmetro, troca de componentes, correções de identificação e atualização de procedimentos. A operação assistida deve registrar essas mudanças e incorporá-las à revisão final aplicável. Encerrar o projeto com documentos anteriores aos ajustes pós-partida reduz a confiabilidade da entrega.

O Termo de Aceite Técnico em Engenharia pode indicar a revisão documental aceita, as pendências remanescentes e a responsabilidade pelas atualizações posteriores.

Preservação, acesso e segurança da informação

O repositório precisa garantir disponibilidade, integridade, controle de acesso, histórico e recuperação. Formatos proprietários exigem estratégia de preservação e licenças; documentos sensíveis precisam de permissões; backups devem ser testados.

A classificação da informação deve considerar riscos físicos e cibernéticos. Diagramas de segurança, credenciais, configurações e rotas críticas não devem circular sem controle. Ao mesmo tempo, restrições excessivas não podem impedir que operação e manutenção acessem o necessário para trabalhar com segurança.

Como contratar, medir e encerrar um escopo de As-Built

As-built precisa ser contratado como processo técnico, não como linha genérica de entrega. O escopo deve informar disciplinas, quantidade de documentos, condição dos arquivos de origem, necessidade de levantamento, formatos, grau de verificação, participação de especialistas, número de locais e critérios de aceite.

Quando o empreendimento possui documentação organizada e redlines confiáveis, o esforço é predominantemente de consolidação e revisão. Quando a instalação está em operação sem registros, o trabalho pode exigir diagnóstico, rastreamento, ensaios, topografia, escaneamento e reconstrução documental. Propostas baseadas apenas em área física ou número de desenhos podem ocultar grande diferença de complexidade.

Modelos de contratação

A elaboração pode integrar o contrato de execução, supervisão, EPC, EPCM, gerenciamento ou Owner’s Engineering. Também pode ser contratada como serviço independente para instalações existentes.

Quando a executora produz o as-built, a supervisão ou equipe do proprietário deve verificar a entrega. Quando a documentação é reconstruída após a obra, o escopo precisa estabelecer limitações de acesso, premissas e nível de certeza. Não é tecnicamente adequado afirmar o que não pôde ser verificado.

Medição por entregáveis e marcos

A medição pode ser vinculada à matriz de documentos e aos marcos de emissão. Percentuais podem considerar levantamento, redline consolidado, emissão para revisão, correção, emissão final e aceite. O pagamento integral antes da aprovação reduz a capacidade contratual de exigir correções.

A quantidade de arquivos não deve ser o único indicador. Um documento extenso pode demandar mais esforço do que dezenas de listas simples. Criticidade, complexidade, interfaces, formato e qualidade dos dados de origem precisam ser considerados.

Critérios comerciais para comparar propostas

Propostas devem esclarecer horas de campo, profissionais, disciplinas, recursos de levantamento, softwares, deslocamentos, arquivos nativos, quantidade de revisões e responsabilidade por validação. Também devem indicar exclusões, como elementos ocultos inacessíveis, ensaios destrutivos, cálculos de verificação ou regularização de soluções executadas sem projeto.

A equalização técnica evita comparar uma simples atualização gráfica com um processo completo de levantamento, coordenação e validação. O serviço de Projeto Executivo de Engenharia pode abranger a reconstrução e consolidação documental quando associado a levantamento e verificação técnica; em empreendimentos complexos, a Engenharia do Proprietário protege a decisão de aceite.

Atuação da A3A Engenharia

A A3A Engenharia atua na estruturação, elaboração, coordenação e validação de documentação as-built para instalações e sistemas multidisciplinares. O trabalho pode incluir levantamento de campo, revisão de documentos existentes, consolidação de redlines, atualização de plantas e diagramas, cadastro de ativos, organização de evidências, controle de revisões e suporte ao aceite.

A atuação pode ser integrada ao Projeto Executivo, ao Gerenciamento de Projetos, ao Comissionamento, à Operação Assistida ou ao Owner’s Engineering. O objetivo é entregar uma base técnica que represente o ativo, preserve rastreabilidade e possa ser utilizada pela organização ao longo de sua operação.

As-built confiável não é o desenho final da obra. É a conexão entre execução, evidência, aceite e gestão do ativo. Quando elaborado como processo contínuo e validado por critérios objetivos, ele reduz riscos, retrabalho e dependência de conhecimento informal.

Referências técnicas

[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 5410:2004 — Instalações elétricas de baixa tensão. Itens 6.1.8.1 a 6.1.8.3. Rio de Janeiro, 2004. Versão corrigida, 2008.

[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-4:2022 — Information management using building information modelling — Part 4: Information exchange. Geneva, 2022.

[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55001:2024 — Asset management — Asset management system — Requirements. Geneva, 2024.

[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva, 2020.

[5] BRASIL. Departamento Nacional de Infraestrutura de Transportes. Instrução Normativa nº 15/2021. Brasília, 2021.

[6] BRASIL. Departamento Nacional de Infraestrutura de Transportes. Instrução Normativa nº 2/2026. Brasília, 2026.

Perguntas frequentes

O que é as-built em engenharia?

É a documentação técnica revisada para representar fielmente a condição efetivamente executada de uma instalação, sistema, edificação ou infraestrutura.

Qual é a diferença entre Projeto Executivo e as-built?

O Projeto Executivo define o que deve ser executado. O as-built registra o que foi efetivamente implantado, incluindo alterações, identificações, características e configurações finais.

Redline já é considerado as-built?

Não necessariamente. Redline é o registro controlado das alterações de campo. Essas informações precisam ser verificadas, incorporadas aos documentos finais e emitidas na revisão definida para as-built.

Quem pode elaborar o as-built?

A responsabilidade depende do contrato e da disciplina. A atualização pode envolver executora, projetista, supervisora, integrador, fornecedor ou equipe especializada, sempre com profissionais habilitados e responsabilidades claramente definidas.

Quais documentos fazem parte do as-built?

Conforme o escopo, incluem plantas, diagramas, memoriais, listas, modelos, dados de equipamentos, configurações, arquivos nativos, cadastros e referências às evidências de inspeção e teste.

Como validar um as-built antes do aceite?

A validação deve verificar completude, fidelidade ao campo, consistência entre documentos, qualidade dos dados, formatos contratados, rastreabilidade das alterações e capacidade de uso por operação e manutenção.

Materiais técnicos complementares

Whitepapers

• Framework de As-Built em Engenharia: planejamento, governança, validação e aceite
• Método de As-Built Elétrico: levantamento, validação e aceite
• Framework de Handover Técnico: da completação à operação
• Owner’s Engineering: framework executivo para contratação, governança e aceite
• ENGiOS — Plataforma de Gestão Técnica para Empresas de Engenharia

Artigos técnicos

• Projeto Executivo de Engenharia
• Execução de Obras de Engenharia
• Comissionamento em Engenharia
• Termo de Aceite Técnico em Engenharia
• Aceite Técnico em Projetos de Engenharia
• Gestão Eletrônica de Documentos: conceitos, riscos e boas práticas

Serviços relacionados

• Projeto Executivo de Engenharia
• Owner’s Engineering — Engenharia do Proprietário
• Gerenciamento de Projetos e Implantação
• Serviços Continuados de Engenharia Consultiva
• Projeto Elétrico de Baixa Tensão
• Projeto de Telecomunicações

Soluções relacionadas

• Gestão Eletrônica de Documentos Técnicos e Controle de Revisões
• Aplicações de Campo, Inspeção e Coleta de Dados Técnicos
• Gestão de Requisitos, Evidências e Critérios de Aceite
• Gestão de Contratos, Escopo e Entregáveis
• Ambiente Comum de Dados e Gestão da Informação BIM