Entenda o que é As-Built em engenharia, como ele se diferencia de projeto executivo e redline e como organizar requisitos, mudanças, validação, Data Book, handover e aceite.
Confira!
O As-Built em engenharia é o conjunto de informações que representa a condição efetivamente executada de uma obra, instalação, sistema ou ativo. A expressão significa “como construído”, mas o conceito técnico não se limita a redesenhar plantas no encerramento: o As-Built deve registrar de forma confiável o que foi instalado, alterado, configurado e entregue.
Seu objetivo é permitir que a condição final do ativo seja compreendida depois da obra por equipes que não acompanharam a execução. Isso pode envolver desenhos, diagramas, modelos, listas de equipamentos, identificação de circuitos e ativos, memoriais atualizados, documentos de fornecedores, parâmetros relevantes, registros de testes e outras informações necessárias para operação, manutenção, expansão, auditoria ou nova intervenção.
Um documento somente pode ser tratado como As-Built quando existe relação verificável entre a informação registrada e a condição executada. Uma planta atualizada a partir de anotações não validadas, um modelo BIM que permaneceu igual ao projeto ou um conjunto de PDFs reunidos ao final da obra podem fazer parte do processo, mas não constituem por si só uma base confiável de “como construído”.
Também é necessário distinguir As-Built de outros instrumentos. O Projeto Executivo estabelece a solução que deve ser implantada; o redline registra alterações observadas durante a execução; o levantamento cadastral documenta uma condição existente em determinado momento; e o As-Built consolida a configuração final entregue, incorporando alterações, verificações e informações necessárias ao uso futuro do ativo.
Por isso, a qualidade do As-Built depende menos do momento em que o desenho final é emitido e mais de como a informação foi controlada durante todo o empreendimento. Quando alterações são registradas somente depois da obra, rotas podem estar ocultas, equipamentos podem ter sido substituídos, parametrizações podem ter mudado e decisões de campo podem permanecer apenas em mensagens, atas ou memória das equipes.
O processo mais confiável começa antes da execução, com requisitos documentais, responsabilidades, baseline, regras de revisão, evidências exigidas e critérios de aceite definidos desde a contratação. Durante a obra, mudanças são registradas e controladas; no comissionamento e no fechamento, a configuração final é verificada; no handover, a informação passa a sustentar operação e manutenção.
Em síntese, As-Built é a transição da intenção de projeto para a informação confiável do ativo executado. A obra física pode estar concluída sem que o empreendimento esteja tecnicamente encerrado se a condição final ainda não estiver documentada, rastreável e utilizável.
As-Built, Projeto Executivo, redline e levantamento cadastral
Os quatro conceitos participam de momentos diferentes do ciclo de engenharia e não devem ser tratados como sinônimos.
| Instrumento | Pergunta principal | Origem da informação | Função |
| Projeto Executivo | O que deve ser construído? | engenharia de projeto, requisitos e critérios de dimensionamento | orientar implantação e detalhar a solução |
| Redline | O que mudou durante a execução? | marcações e registros produzidos em campo | capturar alterações antes da consolidação final |
| Levantamento Cadastral | O que existe no local no momento do levantamento? | medições, inspeções, documentos disponíveis e evidências de campo | estabelecer uma base técnica da condição existente |
| As-Built | O que foi efetivamente executado e entregue? | projeto, mudanças, campo, fornecedores, testes e validações | consolidar a configuração final do ativo |
O redline é, portanto, um registro intermediário. Ele pode indicar alteração de rota, equipamento, dimensão ou interface, mas ainda precisa ser conferido e incorporado aos documentos correlatos. A simples existência de um desenho marcado em vermelho não demonstra que a alteração foi tecnicamente aceita nem que todos os documentos afetados foram atualizados.
O levantamento cadastral tem outra função. Em ativos antigos ou brownfields, pode ser necessário reconstruir a condição existente antes de qualquer intervenção. Nesses casos, um Levantamento Cadastral de Engenharia cria a baseline sobre a qual o projeto e a futura atualização As-Built poderão trabalhar.
Já o artigo Projeto As-Built em Engenharia concentra a metodologia específica de elaboração e atualização dos documentos finais. Este guia mantém uma função diferente: explicar o As-Built no ciclo completo, incluindo contratação, mudanças, levantamento, validação, comissionamento, Data Book, handover e operação.
O As-Built começa nos requisitos de informação
O problema do As-Built raramente nasce no último mês da obra. Ele costuma começar quando o contrato não define com precisão qual informação deverá chegar ao final, quem deve produzi-la e como será aceita.
Uma cláusula genérica como “entregar As-Built ao término dos serviços” transfere para o encerramento decisões que deveriam estar tomadas desde o início: quais documentos serão atualizados, quais formatos serão exigidos, como as alterações serão registradas, quem verifica o conteúdo e quais evidências sustentam a aceitação.
Baseline documental e limites de escopo
Antes da execução, é necessário identificar a baseline: o conjunto de documentos aprovados que representa a solução autorizada para implantação. A partir dela, torna-se possível saber o que efetivamente mudou.
A baseline também evita um erro frequente: atualizar apenas os desenhos mais visíveis. Uma alteração de equipamento pode exigir revisão de layout, diagrama, lista de cargas, lista de materiais, memória técnica, cadastro de ativos e documento de interface. Se o escopo de As-Built não identifica essas relações, a entrega pode ficar internamente contraditória.
Uma matriz documental pode registrar, para cada documento, código, título, disciplina, revisão de referência, responsável pela atualização, formato de entrega, necessidade de verificação e status final esperado. Essa estrutura se aproxima dos princípios de Gestão de Documentos de Engenharia, nos quais documento vigente, revisão e finalidade de emissão precisam permanecer controlados.
Responsabilidades precisam ser explícitas
“As-Built é responsabilidade de todos” não é uma regra de governança. Em projetos com projetistas, executoras, fornecedores, fiscalização, comissionamento e múltiplos pacotes, cada ator produz partes diferentes da informação.
| Função | Responsabilidade típica no processo |
| Projetista | incorporar tecnicamente alterações aprovadas e manter coerência entre documentos |
| Executora | registrar mudanças de campo e fornecer evidências da condição implantada |
| Fornecedor | entregar documentação final do equipamento, interfaces e configurações aplicáveis |
| Fiscalização / Owner’s Engineering | verificar aderência aos requisitos, interfaces e evidências previstas |
| Comissionamento | confirmar a configuração efetivamente testada e registrar ajustes finais |
| Document Control | controlar códigos, revisões, status, transmittals e completude documental |
| Contratante | definir requisitos de informação e exercer as competências de aceite previstas no contrato |
A distribuição concreta dessas responsabilidades depende do modelo de contratação. EPC, EPCM, empreitada por pacotes e Owner’s Engineering podem atribuir deveres diferentes, mas a lógica é a mesma: cada informação precisa ter origem, responsável, revisão e condição de aceite identificáveis.
Requisitos devem ser proporcionais ao uso futuro
Não existe um nível universal de detalhe para As-Built. Um ativo destinado apenas a comprovação geométrica pode exigir um conjunto diferente daquele que será integrado a manutenção, gestão de ativos, operação crítica ou futuros projetos de expansão.
O requisito correto é aquele necessário para a finalidade prevista. Exigir informação sem uso aumenta custo e complexidade; deixar de exigir dados relevantes transfere custo e risco para a operação. Por isso, escopo, criticidade, ciclo de vida e necessidades do proprietário devem orientar o nível de informação.
Como a informação As-Built é construída durante a execução
O As-Built não deve depender de uma grande reconstrução documental no fim da obra. A condição final é formada progressivamente por decisões, desvios, substituições, interferências e ajustes que acontecem durante a implantação.
A melhor prática é manter a ligação entre evento de campo → decisão técnica → alteração executada → evidência → documentos afetados. Essa sequência permite reconstruir por que o documento final ficou diferente da baseline.
Captura de alterações em tempo próximo ao evento
Mudanças devem ser registradas enquanto ainda podem ser verificadas. Isso é especialmente relevante para infraestrutura que depois ficará ocultada, como tubulações, eletrodutos, dutos, redes enterradas, trajetos sobre forro, elementos embutidos e interfaces internas de equipamentos.
O registro pode assumir diferentes formas — redline controlado, RFI, registro de campo, solicitação de mudança, relatório de inspeção ou workflow digital — desde que preserve identificação, origem e vínculo com o documento afetado.
Quando a alteração modifica escopo, requisito, desempenho, capacidade, interface ou solução aprovada, ela deixa de ser apenas uma anotação de campo. Passa a exigir controle formal de mudança. O artigo sobre Engineering Change Management (ECM) aprofunda essa governança.
Redline não substitui análise de impacto
Uma mudança raramente afeta apenas o local em que foi anotada. A troca de uma bomba, por exemplo, pode refletir em alimentação elétrica, automação, lista de equipamentos, tubulação, base, setpoints e documentos de operação. Uma alteração em rack pode afetar cabeamento, alimentação, topologia, identificação e desenhos de infraestrutura.
Por isso, o fechamento de redlines exige análise das interfaces. O objetivo não é transcrever marcações para CAD, mas preservar consistência entre os documentos que descrevem o mesmo ativo.
RFI, não conformidade e mudança são registros diferentes
Uma RFI esclarece uma dúvida; uma não conformidade registra um desvio em relação a requisito; uma mudança modifica uma baseline aprovada. Esses eventos podem originar atualização As-Built, mas não devem ser confundidos.
A solução de Gestão de Pendências, RFIs e Não Conformidades mostra como esses objetos podem permanecer rastreáveis até a resolução. Para o As-Built, a informação importante é saber qual evento gerou uma alteração e quais documentos finais foram afetados.
Consolidação precisa ocorrer antes do encerramento
A consolidação periódica reduz o volume de incerteza acumulado. Em vez de deixar centenas de redlines para o fim, ciclos de revisão permitem resolver inconsistências enquanto as equipes de execução ainda estão mobilizadas e as evidências continuam acessíveis.
Esse processo também cria uma condição melhor para comissionamento, porque os testes podem ser executados sobre documentos mais próximos da configuração real.
Levantamento e verificação da condição executada
Mesmo quando as mudanças foram bem registradas, o As-Built precisa de verificação proporcional ao risco e à criticidade. A documentação final não deve se apoiar exclusivamente na afirmação de que “foi executado conforme o redline”.
Verificação pode incluir inspeção visual, medição, rastreamento de circuito ou rota, conferência de identificação, comparação com documentação de fabricante, consulta a registros de teste e análise de interfaces. O método depende da disciplina e do tipo de informação.
Informação medida, observada, documentada e inferida
Em instalações existentes, nem tudo pode ser verificado com a mesma certeza. Uma boa documentação distingue a natureza da evidência.
| Origem | Exemplo | Nível de confiança típico |
| Medida | dimensão, coordenada, comprimento ou posição levantada | elevado dentro da tolerância do método |
| Observada | identificação física, modelo de equipamento, rota visível | elevada quando o acesso permite inspeção adequada |
| Documentada | informação de manual, folha de dados ou desenho anterior | depende da confiabilidade e vigência da fonte |
| Testada | função, continuidade, desempenho, endereço ou integração confirmada por ensaio | elevada para o parâmetro efetivamente testado |
| Inferida | trecho oculto deduzido por continuidade ou documentação histórica | deve ser claramente declarado como inferência |
| Não verificada | informação sem acesso ou evidência suficiente | não deve ser representada como certeza |
Essa distinção evita falsa precisão. Um desenho visualmente detalhado não é necessariamente confiável quando parte da instalação permanece inacessível.
Brownfield e retrofit exigem reconstrução de baseline
Em brownfields, ampliações e retrofits, o ponto de partida pode ser um acervo com desenhos antigos, revisões conflitantes e intervenções que nunca foram documentadas. Nessa situação, o As-Built deixa de ser apenas um produto de encerramento e passa a exigir reconstrução da condição existente.
O processo pode combinar Site Survey, levantamento cadastral, inspeções específicas, análise documental e rastreamento de interfaces. Somente depois de estabelecer uma baseline suficientemente confiável é possível projetar a intervenção e controlar as novas mudanças.
Laser scanning e nuvem de pontos são meios de captura, não validação completa
Tecnologias de captura 3D podem aumentar produtividade e densidade geométrica, especialmente em áreas industriais, salas técnicas e ambientes complexos. Entretanto, uma nuvem de pontos registra geometria e aparência; ela não identifica automaticamente função, circuito, parâmetro, revisão, fabricante, lógica de controle ou requisito contratual.
Quando a captura é convertida em modelo, o Scan to BIM precisa definir tolerâncias, nível de informação e finalidade. O modelo resultante só pode ser tratado como As-Built quando a condição que pretende representar foi efetivamente verificada conforme os critérios do escopo.
O que deve constar na documentação As-Built
Não existe uma lista universal de entregáveis. O conteúdo depende do empreendimento, das disciplinas, da forma de contratação e do uso futuro da informação. Ainda assim, é possível organizar a documentação em camadas.
Representação física e funcional
A primeira camada descreve a configuração do ativo: localização, geometria, interligações, capacidades, circuitos, redes, identificação e interfaces. A forma de representação pode variar entre plantas, cortes, diagramas, modelos, esquemas, listas e cadastros.
| Disciplina ou sistema | Exemplos de informação relevante |
| Arquitetura e civil | dimensões executadas, acessos, aberturas, compartimentações, elementos relevantes e interfaces |
| Elétrica | quadros, alimentadores, circuitos, cargas, proteções, diagramas, rotas e identificações |
| Telecomunicações | racks, backbone, pontos, fibras, enlaces, topologia, infraestrutura e identificação |
| Segurança eletrônica | dispositivos, posições, controladoras, endereços, infraestrutura, integrações e parâmetros relevantes |
| Automação | controladores, redes, pontos, interfaces, lógicas, endereçamento e parâmetros controlados |
| HVAC | equipamentos, capacidades, dutos, tubulações, válvulas, instrumentos, controles e interfaces |
| Hidrossanitário | redes, prumadas, diâmetros, válvulas, equipamentos, reservatórios e pontos de inspeção |
| Incêndio | equipamentos, dispositivos, laços, zonas, redes, interfaces e identificações |
| Infraestrutura externa | redes enterradas, dutos, caixas, rotas, cotas, interferências e pontos de conexão |
A existência dessa tabela não significa que cada projeto precise entregar todos esses campos. A seleção deve ser contratual e tecnicamente justificada.
Informação de equipamentos e ativos
Para operação e manutenção, a posição geométrica costuma ser insuficiente. Pode ser necessário relacionar fabricante, modelo, número de série, tag, capacidade, documentação técnica, garantia, parâmetros e vínculo com sistema ou localização.
Essa camada torna o As-Built mais útil como base para gestão de ativos, mas também aumenta a responsabilidade sobre qualidade e atualização dos dados.
Documentos de fornecedores
Equipamentos e sistemas podem exigir datasheets finais, certificados, manuais, listas de peças, desenhos de fabricação, parâmetros, arquivos de configuração ou relatórios de ensaio. O documento de fornecedor precisa estar vinculado à configuração efetivamente fornecida, não apenas ao modelo genérico do produto.
Evidências de teste e configuração
Em sistemas elétricos, automação, telecomunicações, segurança eletrônica e outros sistemas ativos, a configuração final pode depender de testes e parametrizações. O As-Built deve refletir a condição que foi efetivamente colocada em serviço, especialmente quando o comissionamento resultou em ajustes.
Como validar um As-Built
Validação não é conferir se uma pasta contém arquivos. É avaliar se a documentação entregue pode ser aceita como representação suficientemente confiável da condição executada.
Cinco dimensões ajudam a estruturar essa avaliação.
| Dimensão | Pergunta de verificação |
| Completude | todos os documentos e campos exigidos estão presentes? |
| Fidelidade | a informação corresponde ao que foi efetivamente executado? |
| Consistência | desenhos, diagramas, listas, modelos e cadastros concordam entre si? |
| Rastreabilidade | é possível identificar revisão, origem, mudança e evidência relevante? |
| Usabilidade | a informação pode ser utilizada por operação, manutenção e futura engenharia? |
Essas dimensões podem ser convertidas em critérios objetivos de aceite por meio de uma Gestão de Requisitos, Evidências e Critérios de Aceite.
Verificação documental e verificação de campo têm papéis diferentes
A análise documental verifica código, revisão, status, completude, coerência e vínculos entre documentos. A verificação de campo avalia se aquilo que está representado corresponde à realidade observável ou testável.
Um processo pode usar amostragem em itens de menor criticidade e verificação integral em pontos críticos. A estratégia depende de risco, complexidade, histórico de mudanças e consequência de erro.
Evidência deve ser adequada ao tipo de informação
Fotografia pode comprovar posição ou identificação visível, mas não confirma necessariamente desempenho. Relatório de teste pode comprovar função, mas não localização. Nuvem de pontos comprova geometria, mas não parametrização. A evidência precisa responder à informação que se pretende validar.
Aceite com ressalvas exige pendências controladas
Documentos incompletos não devem desaparecer do processo porque a instalação entrou em operação. Quando uma entrega é aceita com ressalvas, o item precisa permanecer registrado com responsável, prazo, evidência exigida e condição de baixa.
A Punch List em Engenharia é uma das formas de controlar esses itens até o fechamento.
Comissionamento, As-Built, Data Book e handover
As-Built é uma parte do encerramento técnico, não um processo isolado. Sua configuração final precisa permanecer coerente com testes, pendências, documentos de fornecedores e o conjunto de informações que será transferido para operação.
Comissionamento confirma a configuração que será documentada
Durante o Comissionamento de Sistemas e Infraestruturas, podem ocorrer ajustes de setpoint, endereçamento, lógica, proteção, integração, balanceamento ou até alterações físicas. Quando modificam a configuração final, esses ajustes precisam retornar à documentação.
Isso evita um cenário comum: o sistema funciona corretamente depois do comissionamento, mas o desenho final ainda representa a configuração anterior aos testes.
Punch list fecha pendências, mas pode reabrir documentação
Uma correção física pode alterar mais de um documento. Por isso, a baixa de uma pendência deve considerar não apenas a correção em campo, mas também retestes e atualizações documentais necessárias.
A sequência de fechamento pode ser representada como:
execução → testes → pendência → correção → reteste/verificação → atualização documental → As-Built final → consolidação do dossiê → recebimento → aceite.
Data Book é mais amplo que As-Built
O Data Book é um dossiê de documentos e evidências da entrega. Dependendo do contrato, pode reunir desenhos As-Built, certificados, relatórios de ensaio, manuais, folhas de dados, documentos de fornecedores, registros de inspeção, comissionamento, garantias e demais documentos finais.
Portanto, um Data Book bem organizado não comprova automaticamente que o As-Built é fiel ao campo; e um conjunto de desenhos As-Built não substitui o Data Book quando o contrato exige um dossiê mais abrangente.
A governança de códigos, revisões, listas mestras e transmittals da Gestão de Documentos de Engenharia é o mecanismo que mantém essas entregas estruturadas.
Handover transfere informação utilizável para operação
Handover não é apenas entrega de arquivos. É a transferência controlada do ativo e das informações necessárias para operação, manutenção, gestão e futuras intervenções.
Nesse momento, a documentação precisa permitir identificar configuração, equipamentos, documentos vigentes, testes executados, garantias, pendências formalmente aceitas e dados que deverão ser incorporados a sistemas de manutenção ou gestão de ativos.
O Recebimento Técnico de Obras e Serviços de Engenharia considera essa prontidão documental em conjunto com execução, desempenho, testes e pendências.
As-Built Digital, BIM e gestão da informação
Digitalizar o As-Built não significa converter documentos em PDF nem armazená-los em nuvem. A maturidade digital depende de como a informação é estruturada, versionada, verificada, compartilhada, pesquisada e preservada ao longo do ciclo de vida.
A contribuição da série ISO 19650
A ISO 19650-1 estabelece conceitos e princípios para gestão da informação ao longo do ciclo de vida de ativos construídos, incluindo troca, registro, versionamento e organização. A ISO 19650-2 trata do processo de gestão da informação na fase de entrega dos ativos. No Brasil, a ABNT NBR ISO 19650-1:2022 adota esses princípios para o contexto nacional.
Essas referências são particularmente úteis quando o As-Built envolve BIM e ambientes estruturados de informação, mas não significam que todo As-Built precise ser BIM. O princípio transferível é outro: a informação final precisa ter requisitos, estado, revisão, responsabilidade, verificação e processo de entrega definidos.
O Guia Completo de BIM na Engenharia aprofunda a aplicação da gestão da informação e do ciclo de vida em ambientes BIM.
Modelo de projeto não vira As-Built automaticamente
Um modelo BIM elaborado para projeto representa a intenção aprovada. Para servir como condição executada, precisa incorporar mudanças e passar por critérios definidos de verificação. A conclusão física da obra não transforma automaticamente o modelo em As-Built.
Também não é adequado usar “LOD 500” como sinônimo universal de As-Built. O nível de informação necessário deve ser definido conforme finalidade. Geometria muito detalhada com informação funcional incompleta pode ser menos útil que um modelo mais simples, mas corretamente estruturado e confiável.
Informação do ativo deve continuar sendo governada depois da entrega
O As-Built é uma fotografia controlada da condição em determinado marco de entrega. Se o ativo for modificado durante a operação e a documentação não for atualizada, essa base perde confiabilidade.
Por isso, o valor do As-Built depende de continuidade: mudanças futuras precisam atualizar a informação de referência para que o ativo não retorne gradualmente a um estado documental desconhecido.
Como especificar As-Built em contratos de engenharia
A qualidade da documentação final é fortemente influenciada pelo contrato. Requisitos vagos produzem entregas difíceis de medir e aceitar.
Uma especificação tecnicamente robusta deve tratar pelo menos dos elementos abaixo.
| Elemento contratual | O que deve ser definido |
| Escopo documental | quais documentos, disciplinas, sistemas e áreas devem ser atualizados |
| Baseline | quais revisões representam a referência inicial |
| Registro de mudança | como redlines, RFIs e mudanças serão capturados e controlados |
| Formatos | arquivos nativos, formatos de leitura, modelos, bases e demais entregáveis |
| Codificação e revisão | padrão de identificação, revisão, status e finalidade de emissão |
| Documentos de fornecedores | conteúdo, formato, vínculo com equipamento e prazos |
| Verificação | método, amostragem, inspeções, tolerâncias e evidências necessárias |
| BIM | requisitos de informação, estrutura, classificação, precisão e usos previstos, quando aplicável |
| Data Book | estrutura do dossiê, índice, composição e formato de entrega |
| Critérios de aceite | completude, fidelidade, consistência, rastreabilidade e usabilidade |
| Responsabilidades | quem registra, consolida, verifica, aprova e aceita cada conjunto |
| Prazos | marcos intermediários e entrega final, evitando concentração no encerramento |
Entregáveis devem formar um conjunto coerente
Conforme o projeto, os entregáveis podem incluir desenhos, diagramas, modelos, listas de ativos, memoriais atualizados, documentos de fornecedores, relatórios de levantamento, registros de mudanças, evidências de teste, listas mestras e Data Book.
A qualidade não está na quantidade de arquivos, mas na coerência do conjunto. Um diagrama não deve contradizer a lista de ativos; um modelo não deve divergir das plantas; um cadastro não deve referenciar equipamento diferente daquele instalado.
Critérios de aceite precisam ser definidos antes da entrega
O momento de decidir o que significa “As-Built aceitável” não é a última reunião da obra. Critérios prévios permitem que projetistas, executoras e fornecedores saibam o padrão esperado e que a fiscalização consiga verificar a documentação com objetividade.
Quando o As-Built é parte de um escopo específico de engenharia, o serviço de As-Built de Engenharia reúne levantamento, consolidação, atualização, validação e documentação final dentro dessa finalidade comercial.
Erros que tornam o As-Built pouco confiável
Os problemas mais graves não são necessariamente erros gráficos. Eles aparecem quando o processo perde rastreabilidade entre projeto, execução, mudança e documentação final.
| Erro | Consequência |
| iniciar o As-Built somente depois da conclusão física | dependência de memória, perda de evidências e dificuldade de verificar elementos ocultos |
| transformar redlines diretamente em documento final | incorporação de anotações não validadas e inconsistências entre disciplinas |
| atualizar apenas plantas | diagramas, listas, memoriais e cadastros permanecem divergentes |
| utilizar documento mais recente sem controlar status | versão não aprovada pode ser tomada como vigente |
| representar inferência como informação medida | criação de falsa precisão |
| ignorar alterações realizadas durante comissionamento | documentação diverge da configuração efetivamente testada |
| fechar punch list sem revisar documentos afetados | pendência física encerra, mas a base técnica continua incorreta |
| aceitar Data Book como prova automática de fidelidade | dossiê pode estar completo e ainda conter documentos incompatíveis com o campo |
| usar modelo BIM de projeto como As-Built sem verificação | modelo digitaliza a intenção, não a condição final |
| entregar arquivos sem estrutura documental | operação recebe informação, mas não consegue identificar vigência e relações |
A correção desses problemas depende de processo, não de uma etapa adicional de desenho.
As-Built como base para operação e futuras intervenções
Depois do aceite, o valor do As-Built deixa de ser predominantemente contratual e passa a ser operacional. Manutenção, expansão, retrofit, investigação de falhas, gestão de ativos e novos projetos dependem da qualidade da informação herdada.
Quando a documentação é confiável, a próxima equipe consegue partir de uma baseline conhecida. Quando é deficiente, o proprietário precisa investir novamente em levantamento, inspeção, rastreamento e reconstrução de informações que deveriam ter sido preservadas no encerramento anterior.
Essa relação explica a posição do As-Built no ciclo de engenharia:
FEL → FEED → Projeto Básico → Projeto Executivo → contratação → execução → comissionamento → punch list → As-Built → Data Book → recebimento → aceite → operação.
Nas etapas iniciais são definidos requisitos e baseline. Durante a execução, mudanças são registradas. No comissionamento, confirma-se a configuração testada. No As-Built, consolida-se a condição final. No handover, a informação é transferida. Na operação, essa base precisa continuar sendo mantida diante de novas modificações.
O princípio que organiza todo o processo é simples: uma obra não termina tecnicamente apenas quando a instalação física termina; ela precisa terminar com a condição executada verificável, documentada, rastreável e utilizável no próximo estágio do ciclo de vida do ativo.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using building information modelling — Part 1: Concepts and principles. Geneva: ISO, 2018.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Information management using building information modelling — Part 2: Delivery phase of the assets. Geneva: ISO, 2018.
[3] PROJECT MANAGEMENT INSTITUTE. Construction Extension to the PMBOK Guide. Newtown Square: PMI, 2016.
Perguntas frequentes
As-Built é o conjunto de informações que representa a condição efetivamente executada de uma obra, instalação, sistema ou ativo, consolidando alterações, verificações e documentação necessária para entrega e uso futuro.
O Projeto Executivo define o que deve ser construído. O As-Built registra a condição que foi efetivamente executada e entregue, incorporando as alterações ocorridas durante a implantação.
Não. Redline é um registro intermediário das alterações de campo. O As-Built é a documentação final consolidada e verificada, que pode utilizar redlines como uma de suas fontes.
Os requisitos devem ser definidos antes da execução e a informação deve ser alimentada durante a obra. Deixar todo o processo para o encerramento aumenta o risco de perda de evidências e divergências.
Não. BIM pode ser utilizado quando previsto no escopo, mas o As-Built pode existir em diferentes formatos. Quando houver modelo BIM, ele precisa ser atualizado e verificado para representar a condição executada.
O levantamento cadastral documenta a condição existente em determinado momento. O As-Built consolida a condição final executada de um empreendimento ou intervenção e pode incorporar histórico de mudanças, revisões e evidências.
Não. O As-Built representa a condição executada. O Data Book é um dossiê mais amplo de documentos e evidências de entrega e pode incluir o As-Built entre seus componentes.
A validação deve considerar completude, fidelidade ao campo, consistência entre documentos, rastreabilidade e usabilidade, com evidências e profundidade de verificação proporcionais à criticidade.
Materiais técnicos complementares
Soluções relacionadas
- Gestão de Documentos de Engenharia
- Gestão de Requisitos, Evidências e Critérios de Aceite
- Gestão de Pendências, RFIs e Não Conformidades
Serviços de engenharia relacionados
- As-Built de Engenharia
- Levantamento Cadastral de Engenharia
- Site Survey
- Comissionamento de Sistemas e Infraestruturas
- Recebimento Técnico de Obras e Serviços de Engenharia
Conteúdos técnicos correlatos
- Projeto As-Built em Engenharia
- Punch List em Engenharia
- Comissionamento em Engenharia
- Engineering Change Management (ECM)
- Scan to BIM
Guias e referenciais
