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

Sumário executivo

O As-Built em engenharia deve ser entendido como um processo de gestão da configuração e da informação executada, cujo produto final é uma baseline técnica verificável do ativo. Essa baseline precisa relacionar a condição física construída, as decisões que alteraram o projeto, os resultados de inspeções e testes, os registros de fornecedores, os dados de configuração e os documentos finais aceitos. O objetivo não é apenas produzir desenhos com carimbo “As-Built”, mas preservar uma representação suficientemente confiável para suportar operação, manutenção, auditoria, retrofit, expansão, investigação de falhas, regularização e novas fases de engenharia.

Em empreendimentos complexos, a maior parte dos erros de As-Built não nasce no CAD, no BIM ou na etapa final de documentação. Ela nasce antes: requisitos vagos, ausência de baseline documental, mudanças de campo sem rastreabilidade, redlines heterogêneos, levantamento sem critério de precisão, documentos de fornecedores não reconciliados, ajustes de comissionamento que não retornam à documentação e entregas que são conferidas por quantidade de arquivos, e não por coerência e utilidade.

Este whitepaper propõe um framework de referência para controlar esse processo ao longo do ciclo de entrega. A estrutura combina engenharia de requisitos, gestão documental, controle de configuração, levantamento e verificação de campo, QA/QC, gestão de mudanças, comissionamento, punch list, Data Book, handover e transição da informação para a operação. O framework não substitui requisitos contratuais nem normas aplicáveis a cada disciplina; ele organiza como esses requisitos devem ser convertidos em decisões, responsabilidades, evidências e gates de aceite.

A base normativa utilizada inclui a série ABNT NBR ISO 19650 para gestão da informação, a ABNT NBR 13133:2021 para levantamento topográfico, a ABNT NBR 17058:2022 para locação e controle dimensional de edificações, a ABNT NBR 17047:2022 para o contexto cadastral territorial de registro público, a ABNT NBR 16752:2020 para apresentação de desenhos técnicos, a ABNT NBR 14645-1:2001 como referência histórica e específica da família “como construído” para edificações e a ABNT NBR IEC 62337:2020 para a interface entre documentação, testes, completação e comissionamento em seu escopo industrial.

A tese central é: o As-Built confiável não é produzido no encerramento; ele é acumulado, verificado e reconciliado durante a execução. Quanto mais tarde a organização tenta reconstruir a condição executada, maior a dependência de memória, inferência e engenharia reversa. Quanto mais cedo requisitos, baselines e evidências são controlados, mais defensável se torna a informação final.

As-Built em uma página

Esse entendimento separa o As-Built de uma tarefa editorial. O desenho final é apenas uma das manifestações da configuração executada. Em sistemas elétricos, por exemplo, a condição final pode depender simultaneamente de unifilar, lista de cargas, ajustes de proteção, identificação de painéis, diagramas de comando e registros de testes. Em automação, parte relevante da configuração está em lógicas, parâmetros, backups e versões. Em BIM, a geometria é apenas uma fração do modelo de informação necessário.

O problema de engenharia que o As-Built resolve

Todo ativo físico passa por um processo de transformação entre intenção de projeto e condição instalada. Durante essa transformação surgem desvios aprovados, ajustes construtivos, compatibilizações, substituições de equipamentos, alterações de rota, respostas a RFIs, mudanças de fornecedor, correções de não conformidades e ajustes realizados durante testes. Se esses eventos não forem incorporados à informação final, a organização passa a operar um ativo cuja documentação descreve outra configuração.

A consequência não é apenas documental. Uma baseline incorreta pode induzir isolamento de circuito errado, especificação equivocada de peça, planejamento inadequado de intervenção, erro em estudo de ampliação, incompatibilidade em retrofit, perda de parâmetros após falha de equipamento ou repetição de levantamentos que já deveriam ter sido incorporados ao acervo.

O custo do As-Built deficiente aparece ao longo do ciclo de vida. A organização paga novamente para localizar ativos, confirmar rotas, reconstruir diagramas, identificar versões, refazer cadastros e validar o que poderia ter sido transferido de forma organizada. Por isso, o valor do processo não deve ser medido apenas pelo custo de atualização de desenhos, mas pelo risco e pelo retrabalho evitados nas decisões futuras.

Quatro classes de falha

As-Built não é sinônimo de redline, levantamento cadastral ou record drawing

A governança começa pela separação de conceitos. Um redline é registro intermediário de alteração sobre uma referência. Um levantamento cadastral é processo de captura da condição existente ou executada segundo finalidade e método definidos. Um record drawing pode ser um desenho de registro final, dependendo da terminologia contratual. O As-Built, no sentido adotado neste framework, é o conjunto final de informações que representa a configuração executada dentro do escopo definido e após o processo de verificação.

Também não se deve confundir As-Built com Data Book. O Data Book é um dossiê de evidências e documentos de entrega, podendo conter certificados, relatórios, testes, manuais e registros que não são As-Built. O As-Built é uma classe de informação sobre a condição executada que integra e utiliza parte dessas evidências.

Da mesma forma, um modelo BIM final não é automaticamente um “As-Built Digital”. O modelo só representa o executado naquilo que foi efetivamente verificado e conforme o nível de informação exigido. O artigo sobre Modelo de As-Built Digital aprofunda essa distinção entre geometria, dados e condição construída.

Arquitetura normativa: o que cada referência realmente cobre

Não existe uma única norma brasileira que, isoladamente, estabeleça todo o processo de As-Built para todas as disciplinas e todos os tipos de empreendimento. O método precisa ser construído a partir de referências complementares e, principalmente, de requisitos contratuais adequados ao objeto.

ABNT NBR 14645-1:2001

A ABNT NBR 14645-1 integra a série histórica “Elaboração do como construído (as built) para edificações”. Seu escopo está ligado ao levantamento planialtimétrico e cadastral de imóvel urbanizado para estudos, projetos e edificação. A própria norma define o levantamento de obras como atividade vinculada a um sistema tridimensional de referência e associada ao acompanhamento da obra até sua conclusão.

Essa referência é importante para compreender a origem normativa do termo no contexto topográfico, mas não deve ser extrapolada como se definisse todo o As-Built de sistemas elétricos, automação, telecomunicações ou documentação de ativos. Além disso, partes posteriores da série foram substituídas por normas mais recentes.

ABNT NBR 17047:2022

A ABNT NBR 17047 cancelou e substituiu a antiga NBR 14645-2. Seu escopo é específico: levantamento cadastral territorial para registro público em situações como usucapião, parcelamento, unificação e retificação de matrícula. Ela reforça princípios úteis — análise prévia de documentos, identificação de limites, precisão, controle de qualidade e peças técnicas —, mas não é uma norma geral de As-Built de engenharia.

ABNT NBR 17058:2022

A ABNT NBR 17058 cancelou e substituiu a antiga NBR 14645-3 e estabelece procedimentos para locação topográfica e controle dimensional de edificação. Para o framework de As-Built, são especialmente relevantes a análise prévia da documentação técnica, a confirmação da última revisão, a compatibilização entre sistema de referência de projeto e levantamento, a verificação de elementos notáveis e o registro formal de divergências e tolerâncias.

A norma evidencia uma lógica essencial: realidade de campo e projeto precisam ser comparados dentro de um sistema de referência e de tolerâncias previamente compreendido. Essa lógica é aplicável como princípio de verificação, embora o escopo normativo permaneça o de locação e controle dimensional de edificações.

ABNT NBR 13133:2021

A ABNT NBR 13133 estabelece procedimentos para levantamento topográfico, métodos, instrumentos, precisão, erros, planejamento, apoio, levantamento de detalhes, nivelamento, cálculos, ajustamento, desenho final, relatório, inspeção e aceitação. Para As-Built, ela fornece base para decidir como uma informação geométrica deve ser obtida e qual nível de controle é compatível com sua destinação.

O princípio técnico mais importante é que a precisão e o método precisam ser compatíveis com a finalidade do levantamento. Uma nuvem de pontos densa, por exemplo, não compensa ausência de referência, controle ou entendimento da acurácia necessária. O mesmo vale para medições manuais ou GNSS: a escolha do método depende do que será decidido com a informação.

ABNT NBR 16752:2020

A ABNT NBR 16752 trata da apresentação de desenhos técnicos: formatos, margens, disposição do espaço, legenda, informações complementares, lista de itens, tabela de revisão e escalas. Ela ajuda a estruturar a apresentação e o controle da emissão final, mas não demonstra por si só que um desenho representa a condição construída. Formato correto não substitui processo de verificação.

Série ABNT NBR ISO 19650

A série ABNT NBR ISO 19650 oferece uma arquitetura de gestão da informação aplicável ao ciclo de vida de ativos construídos. A Parte 1 estabelece conceitos e princípios; a Parte 2 organiza o processo de informação durante a fase de entrega; a Parte 3 aborda a fase operacional; e a Parte 4 detalha critérios para trocas de informação. Para As-Built, essa estrutura é decisiva porque transforma o problema de “entregar arquivos” em um processo de requisitos, produção, verificação, autorização, aceitação e continuidade.

ABNT NBR IEC 62337:2020

No escopo de sistemas elétricos, instrumentação e controle de processos industriais, a ABNT NBR IEC 62337 estrutura fases e marcos de completação e comissionamento, incluindo registros, documentação e tratamento de modificações. O valor para As-Built está na interface com a configuração final testada: alterações executadas durante comissionamento precisam retornar à documentação correspondente antes da baseline final.

Princípio 1 — As-Built é gestão de configuração

Uma configuração é um conjunto coerente de características físicas, funcionais e informacionais de um sistema em determinado estado. O As-Built funciona como uma baseline de configuração quando permite associar aquilo que está instalado às informações que o descrevem. Essa associação precisa sobreviver a mudanças, revisões, substituições, testes e transferência para operação.

A abordagem de configuração é superior à abordagem puramente documental porque obriga a perguntar: quais elementos formam o sistema? Quais documentos descrevem cada elemento? Quais atributos são críticos? Que mudança alterou a configuração? Qual evidência confirma o novo estado? Qual revisão passou a ser válida?

Estados de configuração

Princípio 2 — a fonte da verdade depende do tipo de informação

Não existe uma única fonte universal de verdade. A fonte mais confiável depende do atributo. Para posição geométrica, pode ser levantamento verificado. Para fabricante e modelo, a placa de identificação e a documentação de fornecimento podem prevalecer. Para parâmetro de proteção, a configuração validada em teste pode ser a referência. Para trajetória de uma tubulação embutida sem acesso, registros de execução podem ter mais valor do que inspeção tardia.

O framework precisa, portanto, definir uma hierarquia de evidências por classe de informação. Isso evita dois erros comuns: confiar automaticamente no documento mais recente e aceitar automaticamente a observação de campo sem compreender limitações, acessibilidade ou incerteza.

Matriz de fonte de verdade

Princípio 3 — requisitos precisam nascer na contratação

Um contrato que exige apenas “entregar As-Built ao final” transfere para o encerramento decisões que deveriam estar definidas antes da execução. O contratante precisa especificar quais informações são requeridas, para quais usos, em quais formatos, com qual profundidade, como serão verificadas, quem será responsável e o que caracteriza aceite.

A série ISO 19650 reforça que a informação deve ser orientada por requisitos. No contexto do As-Built, isso significa traduzir necessidades de operação, manutenção, legalização, auditoria e futuras intervenções em entregáveis verificáveis.

Requisitos mínimos a definir

• escopo de disciplinas, sistemas, áreas e ativos;
• documentos e modelos que precisam ser atualizados;
• nível de informação necessária para cada finalidade;
• formatos publicados, editáveis, nativos e abertos quando aplicáveis;
• convenções de identificação, metadados, revisão e status;
• regras de redline e registro de mudança;
• métodos de levantamento e tolerâncias quando a verificação de campo for necessária;
• critérios de QA/QC e amostragem;
• interface com testes e comissionamento;
• estrutura de submissão, comentários, rejeição e ressubmissão;
• estrutura de Data Book e handover;
• responsabilidades pela incorporação da informação aos sistemas operacionais.

Governança da informação: OIR, AIR, PIR e EIR

Quando a organização utiliza a lógica ISO 19650, os requisitos de informação podem ser estruturados desde os objetivos organizacionais até as trocas específicas. O OIR expressa necessidades de informação da organização; o AIR define informação necessária à gestão do ativo; o PIR relaciona informação às decisões do empreendimento; e o EIR estabelece o que deve ser trocado em um compromisso.

O As-Built não precisa reproduzir toda essa nomenclatura em qualquer projeto, mas precisa reproduzir a lógica: cada informação final deve existir porque responde a uma necessidade definida. A consequência prática é reduzir tanto a subentrega quanto o excesso de modelagem ou documentação sem uso.

O conteúdo Requisitos de Informação BIM: OIR, AIR, PIR e EIR detalha essa arquitetura.

Baseline documental e Lista Mestra de Documentos

Antes de registrar uma mudança é necessário saber qual documento e qual revisão constituem a referência. A baseline documental é o conjunto controlado de documentos que representa o estado autorizado em determinado marco. Sem baseline, um redline pode indicar uma alteração, mas não é possível afirmar com segurança em relação a qual versão ela foi feita.

A Lista Mestra de Documentos (MDR) deve funcionar como índice do universo de entregáveis, e não como simples lista de arquivos recebidos. Para cada documento relevante ao As-Built, convém controlar código, título, disciplina, responsável, revisão atual, status, finalidade, data planejada, data real, relação com sistema e condição final requerida.

Baseline em projetos multicontrato

Em empreendimentos com múltiplos projetistas, fornecedores e instaladores, o risco de baselines paralelas aumenta. Um fornecedor pode trabalhar sobre revisão diferente da contratada de montagem; a fiscalização pode possuir comentários ainda não incorporados; um submittal de fabricante pode alterar interfaces depois da emissão do projeto executivo.

Nesses casos, a governança precisa definir qual informação é autorizada para execução e qual evento altera essa autorização. A baseline final deve reconciliar as mudanças aprovadas em todos os contratos que afetam a mesma configuração.

Document Control como infraestrutura do As-Built

Document Control preserva identidade, histórico, estado e circulação dos contêineres de informação. Sem esse controle, uma revisão final pode até estar correta tecnicamente, mas não existe cadeia confiável para demonstrar como ela evoluiu.

Os principais controles são codificação documental, revisão, status/finalidade de emissão, transmittals, workflow de comentários, rastreamento de versões, registro de aprovação e arquivamento. Em ambientes digitais, a solução de Gestão de Documentos de Engenharia pode estruturar GED/EDMS, revisões e rastreabilidade para esse ciclo.

Estados de informação e risco de uso indevido

Um documento em trabalho, compartilhado para coordenação, publicado para determinada finalidade e aceito como baseline final não possui o mesmo significado. A governança deve impedir que um arquivo seja utilizado fora do estado para o qual foi liberado. A classificação de estados na ISO 19650 é particularmente útil para projetos BIM, mas a ideia se aplica a qualquer sistema documental: o usuário precisa saber para que aquela informação pode ser usada.

Captura de mudanças: redline como evidência intermediária

Redline deve registrar a mudança enquanto o contexto ainda existe. A marcação precisa estar vinculada à referência, possuir autoria, data, identificação da alteração e, quando necessário, referência ao RFI, NCR, field change, change request, vendor document ou decisão que a autorizou.

Acumular marcações informais em cópias impressas durante meses e digitalizá-las no final é um processo frágil. O risco aumenta quando diferentes equipes mantêm redlines paralelos sem reconciliação. O controle adequado é contínuo: a alteração nasce, é classificada, tem impacto avaliado, é aprovada quando aplicável e é incorporada ao conjunto de documentos afetados.

Redline não deve trabalhar sozinho

Uma mudança raramente afeta apenas o documento onde foi inicialmente marcada. A substituição de um equipamento pode exigir atualização de layout, lista de equipamentos, carga elétrica, alimentação, rede, automação, manutenção, sobressalentes, manual e dados do ativo. Por isso, cada mudança relevante deve gerar uma análise de impacto documental.

Matriz de impacto documental

Engineering Change Management e As-Built

Nem toda anotação de campo é uma mudança de engenharia, mas toda mudança aprovada que altera a configuração final precisa repercutir no As-Built. O processo de Engineering Change Management deve avaliar origem, necessidade, impacto, autoridade de aprovação, documentos afetados, implementação, verificação e fechamento.

A integração evita um erro recorrente: a mudança é aprovada comercialmente ou construtivamente, mas o pacote de documentação não é atualizado. Quando o projeto encerra, a equipe de As-Built encontra a alteração física sem contexto suficiente para reconstruir o raciocínio técnico.

Estratégia de levantamento: medir apenas o que precisa ser demonstrado

Levantamento de campo é uma das fontes do As-Built, não o processo inteiro. A estratégia deve começar pela pergunta: qual atributo precisa ser confirmado e qual decisão depende dele? A resposta define método, densidade de captura, precisão, acesso, amostragem e evidência.

O serviço de Levantamento Cadastral de Engenharia é particularmente relevante em brownfields, ativos sem documentação confiável ou escopos em que a configuração precisa ser reconstruída a partir do campo.

Inspeção visual e registro fotográfico

É adequado para confirmar presença, identificação, condição aparente, arranjo e interfaces visíveis. Fotografia precisa ser vinculada a local, ativo ou sistema; uma biblioteca de imagens sem indexação possui valor limitado. Fotografias também não fornecem, por si só, precisão métrica adequada a todos os usos.

Medição direta

Trenas, paquímetros, níveis e instrumentos manuais podem ser suficientes para dimensões locais e elementos acessíveis, desde que a finalidade e a incerteza sejam compatíveis. O método simples é frequentemente mais eficiente que uma captura massiva quando o universo a confirmar é pequeno.

Estação total e apoio topográfico

Quando posição, alinhamento, cota e relação espacial precisam ser demonstrados de forma controlada, estação total e redes de apoio permitem maior rastreabilidade. A ABNT NBR 13133 fornece princípios para planejamento, instrumentação, precisão, apoio, cálculos e relatórios. A ABNT NBR 17058 reforça a necessidade de coerência entre sistemas de referência e documentos da obra.

GNSS

GNSS pode ser adequado a levantamentos externos, infraestrutura e pontos com condições de recepção compatíveis. O método, a referência geodésica e a precisão precisam ser definidos de acordo com o uso. Não é correto tratar coordenada obtida por qualquer receptor como equivalente a levantamento controlado.

Laser scanning e nuvem de pontos

Laser scanning é valioso para geometrias complexas, áreas extensas e captura densa. A nuvem de pontos pode apoiar modelagem, verificação de interferências e documentação dimensional. Porém, densidade não equivale a acurácia, e geometria não revela automaticamente função, material, circuito, lógica ou estado contratual.

Fotogrametria

Fotogrametria pode contribuir para registro geométrico em determinadas escalas e condições de acesso, desde que exista planejamento de captura, controle e validação compatíveis com a finalidade. Como nos demais métodos, o critério não é a tecnologia em si, mas a qualidade mensurável do produto em relação ao requisito.

Precisão, tolerância, acurácia e incerteza

Um dos erros mais graves em As-Built é declarar uma precisão que o processo não demonstrou. A precisão de representação gráfica, a resolução de captura e a acurácia do levantamento são conceitos distintos. Um modelo pode exibir milímetros e ainda ter sido produzido com dados cuja incerteza é muito maior.

A ABNT NBR 13133 relaciona método, instrumentos, erros e propagação de variâncias à destinação do levantamento. A ABNT NBR 17047 estabelece valores específicos de precisão e tolerância em seu escopo cadastral para registro público; esses valores não devem ser transportados automaticamente para outras aplicações. Em As-Built industrial ou predial, as tolerâncias precisam derivar do requisito técnico, do sistema e do uso futuro.

Classes de necessidade geométrica

Plano de verificação de campo

Antes de mobilizar equipe, recomenda-se preparar um plano que relacione sistemas, documentos, atributos a confirmar, método, amostragem, precisão requerida, acesso, segurança, responsáveis e formato de evidência. Isso transforma a visita de campo em atividade de engenharia orientada por requisitos.

Em áreas críticas, o plano também precisa considerar janelas operacionais, permissões de trabalho, bloqueio e etiquetagem, necessidade de acompanhamento da operação, restrições fotográficas, áreas classificadas e interfaces com sistemas energizados.

Registro da evidência

Cada evidência deve poder ser relacionada ao item verificado. Isso pode ser feito por tag, coordenada, localização, sistema, documento ou identificador de issue. O vínculo é mais importante do que a quantidade de registros. Um levantamento extenso sem estrutura de indexação cria um novo problema documental.

As-Built em engenharia civil e topografia

Na engenharia civil, parte importante da condição executada é espacial. Eixos, cotas, fundações, estruturas, limites, redes externas e elementos construídos podem depender de referência topográfica controlada. A NBR 17058 destaca a análise de documentação, a coerência do sistema de referência, o levantamento de elementos notáveis e o registro de divergências.

Para estruturas e elementos ocultos, o momento de verificação é crítico. Esperar o encerramento pode tornar a condição impossível de observar diretamente. Registros durante concretagem, inspeções, levantamentos antes de fechamento e documentação de execução podem ser necessários para preservar a informação.

As-Built arquitetônico

Arquitetura exige reconciliar ambientes, dimensões, vãos, acabamentos relevantes, acessos, circulações, fachadas, cortes, áreas técnicas e interfaces com instalações. A qualidade do As-Built não deve ser avaliada apenas pela semelhança visual da planta: alterações de compartimentação podem impactar segurança, uso, manutenção e sistemas complementares.

O conteúdo sobre As-Built Arquitetônico detalha esse recorte disciplinar.

As-Built estrutural

Estruturas demandam cuidado especial porque muitos elementos ficam ocultos e porque a condição final não pode ser inferida apenas por geometria aparente. Mudanças de seção, reforços, aberturas, inserts, chumbadores, bases e intervenções precisam ser sustentadas por documentação e evidências compatíveis.

Quando a informação de armadura ou elementos internos é necessária, o framework deve definir a fonte aceitável: projeto revisado, registros de execução, inspeções, ensaios específicos ou combinação de evidências. O As-Built não deve inventar informação que não foi observada ou registrada.

As-Built elétrico

Em instalações elétricas, a condição construída envolve topologia, capacidade, proteção, circuitos, cabos, quadros, identificação, aterramento, fontes, cargas, comandos e parâmetros. Um desenho de planta atualizado não é suficiente se unifilares, listas e ajustes permanecerem divergentes.

O método deve confrontar documentos de projeto, placas, identificação de campo, continuidade/rastreio quando necessário, resultados de testes, parametrização e alterações de comissionamento. O whitepaper específico Método de As-Built Elétrico aprofunda essa metodologia e será tratado como documento especializado complementar deste framework.

As-Built hidrossanitário e utilidades

Redes de água, esgoto, drenagem e utilidades apresentam o desafio de trechos embutidos ou enterrados. A oportunidade de captura durante a execução é decisiva. Fotografias vinculadas, medições antes de fechamento, testes, marcação de pontos e levantamentos de redes externas podem compor a evidência.

O conteúdo As-Built Hidrossanitário detalha prumadas, redes, equipamentos e documentação final.

As-Built mecânico e HVAC

Sistemas mecânicos e HVAC exigem conciliar equipamentos, capacidades, redes, dutos, tubulações, válvulas, dampers, identificação, pontos de medição, balanceamento e interfaces com automação. Alterações de campo frequentemente repercutem em operação e manutenção.

A configuração final deve refletir o que foi testado. Se o balanceamento ou start-up gerou ajustes em dampers, válvulas ou controles, esses ajustes podem precisar ser incorporados aos registros e documentos relevantes.

As-Built de instrumentação e automação

Em instrumentação e automação, parte substancial do ativo é lógica. Tags, I/O, ranges, endereços, setpoints, alarmes, causa e efeito, intertravamentos, lógica de controle, versões de software e backups precisam ser tratados como configuração.

A ABNT NBR IEC 62337:2020 fornece uma referência importante para a relação entre testes, registros e modificações durante comissionamento em seu escopo industrial. A baseline final precisa representar a configuração que efetivamente passou pelos testes aplicáveis.

As-Built de telecomunicações e segurança eletrônica

Telecomunicações, CFTV, controle de acesso e redes possuem componentes físicos e lógicos. Rotas, racks, fibras, portas, patching, VLANs, endereços, configurações, licenças e integrações podem fazer parte da condição entregue. A fronteira entre As-Built e documentação de configuração precisa ser explicitada no contrato.

Em sistemas cibernéticos ou sensíveis, credenciais e segredos não devem ser inseridos indiscriminadamente no acervo técnico geral. A governança deve separar documentação necessária à operação de informações sujeitas a controle de segurança.

Matriz de interfaces entre disciplinas

A principal fragilidade de um As-Built multidisciplinar costuma estar nas interfaces. Cada disciplina pode parecer correta isoladamente e ainda assim o sistema integrado permanecer incoerente.

As-Built Digital, BIM e modelo de informação

No ambiente BIM, o As-Built precisa ser tratado como modelo de informação, não apenas modelo geométrico. A ISO 19650-1 define PIM como modelo de informação relacionado à fase de entrega e AIM como modelo relacionado à fase operacional. O fim da entrega envolve selecionar e transferir informação relevante, não simplesmente arquivar o PIM inteiro.

O artigo sobre PIM e AIM aprofunda essa transição. Para o As-Built, o ponto central é que a geometria e os dados finais precisam corresponder ao nível de informação necessário e aos critérios de aceitação definidos.

Nível de informação necessária

Mais detalhe não significa melhor informação. A organização deve especificar o nível suficiente para a decisão ou processo que será suportado. Modelar componentes internos que nunca serão utilizados pode aumentar custo e complexidade sem aumentar valor; omitir tag, fabricante ou acesso de manutenção pode reduzir significativamente a utilidade operacional.

Formatos nativos e abertos

A estratégia de entrega deve avaliar necessidade de arquivos nativos para continuidade de autoria e formatos abertos para interoperabilidade e preservação. A ISO 19650-4 enfatiza a importância de testar formatos e fluxos de troca e considerar riscos de degradação durante conversões.

QA/QC do As-Built segundo a lógica da ISO 19650-4

A ABNT NBR ISO 19650-4:2025 é particularmente útil para transformar a revisão de As-Built em um sistema estruturado. A norma detalha decisões e critérios de revisão para trocas de informação e pode ser adaptada como matriz de controle do pacote final. Os seis eixos centrais são CDE/metadados, conformidade, continuidade, comunicação, consistência e completude.

1. CDE e metadados

Verifica se identificação, nomenclatura, revisão, status e demais metadados necessários ao workflow foram aplicados corretamente. Para As-Built, isso impede que um arquivo tecnicamente correto entre no acervo com identidade ambígua ou estado inadequado.

2. Conformidade

Verifica aderência a esquemas e formatos acordados. O controle pode incluir templates, campos obrigatórios, estrutura de modelo, nomenclatura, unidades, classificação, codificação e regras do contrato.

3. Continuidade

Compara a informação com versões anteriores, outros contêineres, estados e fases. Esse critério é essencial ao As-Built porque ajuda a distinguir mudança real de perda acidental de informação durante atualização.

4. Comunicação

Verifica se a informação pode ser armazenada e transferida sem degradação. Conversões de formato, unidades, codificação e interoperabilidade precisam ser testadas quando relevantes. Em arquivos críticos, comparações de tamanho, relatórios ou checksums podem auxiliar o controle de integridade.

5. Consistência

Verifica conflitos, sobreposições, lacunas, contradições de propriedades, posicionamento e precisão adequada. Para As-Built multidisciplinar, essa é a base da reconciliação entre planta, lista, modelo, equipamento e banco de dados.

6. Completude

Verifica presença e adequação da informação em relação ao nível requerido. O pacote pode possuir todos os arquivos previstos nominalmente e ainda ser incompleto se propriedades, relações, documentos nativos ou evidências necessárias estiverem ausentes.

Automação de QA/QC e regras verificáveis

Parte dos controles pode ser automatizada quando os requisitos são estruturados. Nomenclatura, campos obrigatórios, formatos, propriedades, classificações, correspondência de identificadores e regras de modelo podem ser avaliados por rotinas de verificação. A automação aumenta repetibilidade, mas não substitui julgamento técnico onde a validade depende de contexto, condição física ou interpretação de engenharia.

Em BIM, recursos como IDS podem apoiar especificações e verificações de informação estruturada. O uso deve estar subordinado aos requisitos do projeto; a ferramenta não define por si só o que é necessário.

Auditoria cruzada entre documentos

O QA/QC mais valioso frequentemente é o que cruza fontes independentes. Uma única fonte pode estar internamente consistente e ainda estar errada. A auditoria deve buscar convergência entre documentos, campo, testes e dados.

Comissionamento como verificação da configuração final

Comissionamento não é apenas uma etapa posterior ao As-Built; ele é uma das principais fontes de evidência da configuração final. Durante testes podem ocorrer ajustes de setpoint, proteção, lógica, endereçamento, balanceamento e sequência operacional. Congelar a documentação antes desses ajustes cria uma baseline prematura.

A cadeia recomendada é teste → ajuste aprovado → registro → reteste → atualização documental → verificação final. O Guia Completo de Comissionamento aprofunda a estrutura dos testes e marcos.

Pré-comissionamento e Mechanical Completion

O Pré-Comissionamento e a Mechanical Completion produzem registros que ajudam a demonstrar condição física, testes preliminares e pendências por sistema. Esses registros devem ser considerados entradas para a consolidação final, e não ficar desconectados do As-Built.

Punch list e reabertura documental

Uma pendência física pode reabrir documentação já preparada. Se uma válvula é substituída, um circuito é reroteado ou um equipamento muda de posição para fechar um item de punch list, a baixa técnica só está completa quando a alteração repercute nos documentos afetados.

O processo deve vincular a Punch List ao impacto documental. Um item “fechado em campo” e “aberto na baseline” continua sendo um risco.

Emissão final: o que significa “As-Built” no carimbo

O contrato precisa definir qual revisão e qual status representam a condição final. Termos como As-Built, Final, Record, Approved, AFC e IFC possuem usos diferentes entre organizações. O carimbo deve ser consequência do processo de aprovação, não uma declaração autônoma.

A ABNT NBR 16752 fornece requisitos de apresentação, incluindo legenda e tabela de revisão. A governança do projeto deve complementar isso com codificação, finalidade, status, assinaturas, transmittal e controle do arquivo nativo.

Integridade entre arquivo nativo e arquivo publicado

Quando PDF e arquivo editável fazem parte da entrega, ambos precisam representar a mesma revisão. Alterações manuais em PDF sem atualização do nativo, ou exportações realizadas a partir de versões diferentes, criam bifurcação da baseline.

Em modelos e bancos de dados, o problema se amplia: um IFC pode não carregar integralmente propriedades do modelo nativo, um CSV pode perder relações e uma conversão de unidade pode alterar valores. Testes de exportação/importação e critérios de comunicação da ISO 19650-4 são relevantes para evitar degradação silenciosa.

Data Book: dossiê de evidência da entrega

O Data Book de Obra deve ser tratado como repositório estruturado de evidências da execução e do aceite. Ele pode conter documentos As-Built, certificados, inspeções, testes, relatórios, vendor data, manuais, garantias e registros de comissionamento.

O As-Built usa o Data Book como fonte e também integra o pacote de entrega, mas os dois não são equivalentes. A reconciliação final deve verificar se os documentos As-Built previstos no MDR estão presentes, na revisão correta e associados às evidências que sustentam sua condição.

Handover e transferência da baseline

O Handover Técnico é o processo que transfere ativo, informação, conhecimento e responsabilidade para a operação. Uma baseline As-Built tecnicamente correta perde valor se não for incorporada ao repositório, ao modelo de informação do ativo e aos sistemas utilizados pela equipe recebedora.

A ABNT NBR ISO 19650-3 reforça a continuidade da informação na fase operacional e a incorporação de modelos aceitos ao AIM. O framework de As-Built, portanto, só se encerra quando a informação possui destino e governança de manutenção.

Integração com CMMS, EAM e sistemas de ativos

Quando o projeto precisa alimentar CMMS/EAM, a estrutura de tags, ativos, localização, fabricante, modelo, serial, datas de garantia, planos de manutenção e documentos associados deve ser definida antes da entrega. A importação tardia de dados não estruturados aumenta retrabalho e risco de perda de vínculo.

O conteúdo sobre CMMS e integração com BIM e gestão de ativos detalha essa transição.

Brownfield: quando a baseline de partida é incerta

Em Projetos Brownfield, muitas vezes não existe documentação confiável da condição inicial. O As-Built da intervenção precisa separar claramente três estados: condição existente antes da obra, modificações executadas e condição final após testes.

Se esses estados forem misturados, a organização não consegue distinguir o que já existia do que foi alterado pelo contrato. O levantamento inicial funciona como baseline de partida e pode exigir Due Diligence documental, inspeção e captura de campo antes do projeto.

Convivência com operação

Brownfields também exigem controle de mudanças depois de liberações parciais. Um sistema já transferido pode ser afetado por obra remanescente. O processo precisa integrar gestão de mudança, permissões, redlines e atualização imediata da baseline operacional.

Projetos greenfield: oportunidade de produzir o As-Built progressivamente

Em greenfield, a organização possui a melhor oportunidade de evitar reconstrução. Requisitos podem ser inseridos nos contratos, redlines podem nascer junto com a execução, levantamentos podem ocorrer antes do fechamento de elementos e o Data Book pode ser consolidado progressivamente.

O erro típico é desperdiçar essa oportunidade e tratar o As-Built como entrega final administrativa. A eficiência maior ocorre quando cada pacote de trabalho encerra sua própria evidência e atualiza o conjunto de informação correspondente.

Framework executivo em 12 etapas

O processo pode ser organizado em doze etapas interdependentes. Elas não precisam ocorrer de forma estritamente sequencial; em grandes empreendimentos, diferentes sistemas podem estar em etapas distintas ao mesmo tempo.

1. Definir propósito, usuários, requisitos e critérios de aceite.
2. Estabelecer baseline, MDR, codificação e estados de informação.
3. Definir papéis, responsabilidades, workflows e autoridade de aprovação.
4. Capturar redlines, RFIs, mudanças e evidências durante a execução.
5. Planejar e executar verificação/levantamento da condição física.
6. Consolidar documentos, modelos, listas e dados por sistema e disciplina.
7. Executar QA/QC e auditoria cruzada das informações.
8. Incorporar configuração final proveniente de testes e comissionamento.
9. Fechar punch list física e documental.
10. Emitir, revisar, rejeitar/corrigir e aceitar a revisão As-Built.
11. Reconciliar MDR, Data Book e handover package.
12. Transferir e incorporar a baseline ao ambiente operacional.

Gate 1 — baseline de referência controlada

Entrada: projeto e documentos disponíveis. Evidência: MDR, revisões autorizadas, registros de emissão e sistema de identificação. Critério de saída: cada entregável do escopo possui referência inequívoca a partir da qual mudanças serão controladas.

Sem esse gate, o processo de atualização fica exposto a redlines feitos sobre versões divergentes.

Gate 2 — mudanças e redlines reconciliados

Entrada: registros de execução, RFIs, mudanças, NCRs e vendor data. Evidência: change register, redlines identificados, matriz de documentos impactados. Critério de saída: alterações relevantes possuem origem, decisão e repercussões conhecidas.

Gate 3 — condição executada verificada

Entrada: documentos atualizados preliminares e plano de levantamento. Evidência: inspeções, medições, levantamentos, fotografias indexadas, registros de execução e relatórios. Critério de saída: atributos requeridos foram confirmados por método compatível e divergências foram registradas.

Gate 4 — pacote tecnicamente coerente

Entrada: conjunto consolidado por disciplina/sistema. Evidência: checklists QA/QC, auditoria cruzada, resolução de comentários, reconciliação de interfaces. Critério de saída: informação atende requisitos de conformidade, continuidade, consistência, comunicação e completude aplicáveis.

Gate 5 — baseline aceita e transferida

Entrada: revisão final, Data Book, MDR e handover package. Evidência: aceite, transmittal, registro de pendências residuais, incorporação ao repositório/AIM/sistemas operacionais. Critério de saída: a parte requerente consegue recuperar e utilizar a informação aceita para os fins definidos.

Modelo de papéis e responsabilidades

Assurance baseado em criticidade

Nem toda informação possui o mesmo impacto. O esforço de verificação deve ser proporcional à criticidade. Um erro em identificação de ambiente pode ter consequência limitada; um erro em intertravamento, proteção, rota de tubulação crítica ou localização de rede enterrada pode gerar risco relevante.

É recomendável classificar documentos, sistemas e atributos por criticidade e definir intensidade de revisão, amostragem e independência de verificação. Isso evita dois extremos: auditar tudo com o mesmo esforço ou aceitar por amostragem informação cujo erro é intolerável.

Exemplo de níveis de assurance

Essa classificação é uma construção de governança do projeto, não uma classificação normativa universal.

Critérios de rejeição do As-Built

O contrato deve permitir rejeição objetiva. Motivos típicos incluem documento fora da revisão requerida, ausência de arquivo nativo quando previsto, divergência com campo, mudança aprovada não incorporada, inconsistência entre documentos correlatos, modelo fora do esquema acordado, evidência insuficiente, documentação de fornecedor incompatível com equipamento instalado ou informação crítica de comissionamento não incorporada.

A rejeição precisa identificar requisito não atendido, localização do problema e evidência necessária para ressubmissão. Comentários vagos geram ciclos improdutivos e disputa sobre preferências.

Fluxo de revisão, autorização e aceite

1. responsável produz/atualiza a informação em ambiente controlado;
2. executa verificação interna e QA;
3. submete para coordenação/revisão técnica;
4. issues e comentários são registrados e atribuídos;
5. responsável corrige e ressubmete;
6. parte fornecedora líder ou coordenação autoriza, quando aplicável;
7. parte requerente revisa contra critérios de aceite;
8. aceita ou rejeita de forma registrada;
9. informação aceita recebe estado final e é incorporada ao acervo.

A lógica é coerente com o processo de troca de informação da ISO 19650-2/4, mas deve ser adaptada ao arranjo contratual real.

Como medir progresso sem criar falsa sensação de completude

Percentual de arquivos emitidos é um indicador insuficiente. O progresso do As-Built deve considerar pelo menos produção, verificação, aceitação e criticidade. Um projeto pode estar “95% entregue” por quantidade de documentos e ainda não possuir os 5% que controlam energização, segurança ou operação.

Indicadores recomendados

• % de entregáveis requeridos identificados no MDR;
• % de redlines reconciliados;
• % de mudanças aprovadas incorporadas;
• % de documentos submetidos / aceitos;
• taxa de rejeição na primeira submissão;
• aging de comentários;
• quantidade de pendências documentais críticas;
• % de documentos cruzados com evidência de campo/teste;
• % de ativos reconciliados entre campo, documento e banco de dados;
• diferença MDR × Data Book;
• % de sistemas com baseline final transferida à operação.

Estrutura de contratação do As-Built

O serviço pode ser contratado como obrigação da executora, escopo independente de engenharia, pacote de levantamento e atualização, ou componente de Owner’s Engineering. A melhor estrutura depende da qualidade da informação existente, do número de contratos, do risco de conflito de interesse e da necessidade de verificação independente.

Quando a própria executora produz o As-Built, o contrato deve prever critérios de verificação pelo proprietário. Quando a documentação de partida é deficiente, pode ser necessário contratar levantamento independente antes mesmo da execução.

Escopo contratual recomendado

• matriz de sistemas e documentos;
• responsabilidade por redline e atualização;
• requisitos de levantamento;
• critérios de precisão/tolerância;
• formatos e arquivos nativos;
• requisitos de BIM/dados quando aplicáveis;
• workflows e prazos de revisão;
• número de ciclos de correção previstos e regra para retrabalho por não conformidade;
• requisitos de Data Book e handover;
• marcos de medição e aceite.

Medição e pagamento por resultado

Medir As-Built apenas por horas ou volume de arquivos incentiva produção, não qualidade. Em contratos estruturados, marcos podem ser vinculados a resultados: baseline/MDR aprovados, levantamento concluído, pacote preliminar submetido, QA/QC aprovado, revisão final aceita e handover documental concluído.

O pagamento final deve evitar liberar parcela relevante antes da aceitação da baseline. Ao mesmo tempo, concentrar 100% no final transfere financiamento excessivo ao fornecedor. Um modelo equilibrado distribui remuneração por gates verificáveis.

Entregáveis técnicos de referência

Exemplo integrado — retrofit de uma instalação crítica

Considere a modernização de uma instalação existente envolvendo QGBT, UPS, automação, cabeamento e monitoramento. A documentação de partida possui unifilares antigos, plantas parcialmente atualizadas e ausência de arquivos de configuração de alguns dispositivos.

1. Baseline inicial

Antes do projeto, a equipe consolida MDR existente, identifica revisões, levanta painéis e equipamentos e registra divergências. O resultado não é chamado imediatamente de As-Built: é uma baseline “existing condition” com limitações explícitas.

2. Projeto e mudança

O projeto executivo utiliza essa baseline. Durante implantação, rotas e equipamentos sofrem ajustes. Cada mudança é registrada em redline e vinculada à decisão correspondente.

3. Verificação

Antes do fechamento de trechos, a equipe registra rotas e identifica cabos. Equipamentos são conferidos por tag e placa. Configurações são exportadas e associadas aos respectivos ativos.

4. Testes

Comissionamento altera alguns setpoints e lógica de transferência. As mudanças são registradas, retestadas e retornam aos diagramas, listas e backups.

5. Consolidação

QA/QC confronta unifilar, quadros, lista de cargas, topologia de comunicação, backups, plantas e resultados de teste. Issues são fechados antes da revisão final.

6. Handover

A revisão aceita é incorporada ao acervo; dados de ativos e garantias são transferidos ao CMMS; backups críticos recebem custódia definida. A operação assume uma baseline coerente com a configuração testada, e não apenas um conjunto de PDFs.

As-Built em empreendimentos com entrega progressiva

Grandes projetos raramente encerram todos os sistemas ao mesmo tempo. O As-Built pode ser organizado por systemization, permitindo que cada sistema forme sua própria baseline de entrega. Isso aproxima documentação, comissionamento e handover e reduz o volume acumulado no encerramento global.

O risco é alterar posteriormente um sistema já entregue por causa de interfaces com obra remanescente. Qualquer intervenção deve reabrir controle de mudança e atualizar a baseline correspondente.

Modelo de maturidade do As-Built

Diagnóstico de maturidade

Antes de implantar o framework, a organização deve responder: existe MDR confiável? os redlines são controlados? há regra para mudanças? documentos de fornecedores são reconciliados? levantamentos possuem método e precisão definidos? QA/QC cruza fontes? comissionamento atualiza configuração? existe critério de aceite? a operação participa dos requisitos? os dados migram para sistemas corporativos?

As respostas ajudam a priorizar controles. Uma organização não precisa implantar simultaneamente BIM, CDE avançado e automação de QA para melhorar o As-Built. O primeiro ganho vem da clareza de requisitos, responsabilidades e baselines.

Roadmap de implantação em 90 dias

Dias 0–30 — diagnosticar e estabilizar

• mapear contratos, sistemas e documentos;
• identificar baselines atuais e lacunas;
• definir owner do processo;
• estabelecer nomenclatura e MDR;
• congelar uso de versões não controladas;
• priorizar sistemas críticos.

Dias 31–60 — implantar fluxo e evidências

• padronizar redlines e change register;
• definir plano de levantamento;
• implantar checklists de QA/QC;
• estabelecer workflow de submissão/rejeição;
• integrar documentação de fornecedores e comissionamento;
• treinar equipes envolvidas.

Dias 61–90 — testar gates e preparar transferência

• aplicar gates em sistemas-piloto;
• medir taxa de rejeição e lacunas;
• reconciliar MDR e Data Book;
• ajustar critérios de aceite;
• definir destino da informação na operação;
• formalizar indicadores e rotina de governança.

Aplicação por cenário

Edificação nova

Priorizar captura progressiva, controle de mudanças e integração entre arquitetura, estrutura e instalações. O maior ganho é evitar perda de informação de elementos que serão ocultados.

Instalação industrial

Priorizar systemization, P&IDs, instrumentação, configuração, vendor data e integração com comissionamento. A baseline deve refletir o sistema efetivamente testado.

Data Center

Priorizar energia crítica, climatização, monitoramento, telecomunicações, lógica, parâmetros, capacidade e documentação de contingência. Mudanças de configuração podem ser tão relevantes quanto mudanças geométricas.

Infraestrutura linear

Priorizar referência espacial, redes enterradas, marcos, coordenadas, cruzamentos, profundidades e documentação de trechos. O plano de levantamento precisa ser ajustado ao método construtivo e ao acesso futuro.

Brownfield

Priorizar baseline inicial, segregação entre existente e novo, levantamento de interfaces e controle rigoroso das mudanças durante janelas de intervenção.

Erros que o framework deve impedir

Checklist técnico de auditoria

Requisitos

• finalidades e usuários definidos;
• escopo de sistemas/documentos definido;
• critérios de aceite mensuráveis;
• formatos e dados requeridos definidos.

Baseline e mudanças

• MDR atualizado;
• revisões de referência conhecidas;
• redlines vinculados às referências;
• mudanças aprovadas reconciliadas.

Campo

• plano de levantamento aprovado;
• método compatível com finalidade;
• referências e instrumentos controlados;
• limitações registradas.

QA/QC

• conformidade verificada;
• continuidade entre revisões verificada;
• consistência entre documentos verificada;
• completude confrontada com requisitos.

Testes e fechamento

• configuração testada incorporada;
• punch list documental fechada;
• Data Book reconciliado;
• revisão final aceita.

Handover

• destino operacional definido;
• arquivos nativos e publicados reconciliados;
• ativos/dados incorporados quando requerido;
• responsabilidade futura pela atualização definida.

Como a Engenharia do Proprietário pode governar o As-Built

Em empreendimentos multicontrato, o proprietário pode precisar de uma função independente para estruturar requisitos, integrar interfaces, verificar entregáveis e recomendar aceite. A Engenharia do Proprietário — Owner’s Engineering pode coordenar o framework sem substituir as responsabilidades das contratadas pela produção de suas informações.

O papel é especialmente relevante quando diferentes contratos possuem obrigações documentais distintas, quando o ativo permanecerá em operação durante a obra ou quando a aceitação precisa ser suportada por evidências independentes.

Recebimento Técnico e aceite do pacote final

O Recebimento Técnico deve confrontar a entrega com requisitos e evidências, evitando que a decisão se reduza a uma conferência formal de presença de arquivos. A análise pode produzir aceite, aceite com ressalvas conforme contrato ou rejeição fundamentada.

O aceite do As-Built não deve ser interpretado automaticamente como quitação de todas as obrigações do contrato, nem como garantia de inexistência de defeitos ocultos. Os efeitos jurídicos e comerciais do aceite precisam estar definidos no instrumento contratual.

Governança depois do As-Built

A baseline começa a envelhecer assim que novas mudanças são realizadas. Se a operação não possui processo de gestão de modificações e atualização documental, o esforço feito no encerramento perde valor progressivamente.

O nível mais alto de maturidade é manter a relação entre mudança física e atualização de informação durante todo o ciclo de vida. Isso exige owner do dado, workflows, revisões, controle de acesso e critérios para incorporar novas intervenções ao AIM ou repositório de ativos.

Arquitetura de dados do As-Built

Quando o As-Built deixa de ser um conjunto de desenhos e passa a sustentar gestão de ativos, a arquitetura de dados torna-se parte do escopo de engenharia. Cada objeto relevante precisa possuir identificador estável, contexto de localização, sistema ao qual pertence, atributos necessários, documentos associados e regra para atualização futura. Sem essa estrutura, a organização pode receber milhares de arquivos corretos isoladamente e ainda assim não conseguir navegar pela informação do ativo.

Uma arquitetura mínima deve relacionar ativo → sistema → localização → documento → evidência → revisão/status. Em empreendimentos digitais, essas relações podem ser implementadas no CDE, no modelo BIM, em bancos de ativos, CMMS/EAM ou por integrações entre sistemas. A tecnologia pode variar; a coerência dos identificadores não.

Identificação de ativos e tags

Tags precisam funcionar como chave de reconciliação entre campo e informação. Alterar a identificação de um equipamento sem atualizar listas, desenhos, CMMS, alarmes e documentação de manutenção cria duplicidade ou perda de vínculo. O processo de As-Built deve prever um registro mestre de tags e regras para criação, alteração, aposentadoria e substituição.

Localização física e localização funcional

Um ativo pode possuir localização física — sala, coordenada, elevação — e localização funcional — sistema, subsistema, linha, circuito ou processo. As duas dimensões são úteis e não devem ser confundidas. Para manutenção, saber “onde está” pode ser tão importante quanto saber “a que sistema pertence”.

Metadados como parte da qualidade documental

Metadados são essenciais para recuperação e uso controlado. Código, título, disciplina, revisão, status, autor, aprovador, sistema, área, data e classificação podem permitir que o acervo seja filtrado, auditado e integrado a workflows. A ISO 19650-4 inclui explicitamente CDE e metadados entre os critérios de revisão da troca de informação.

A qualidade do As-Built, portanto, deve considerar dois planos: qualidade do conteúdo e qualidade do contêiner. Um desenho pode estar correto, mas ser praticamente inutilizável se não possuir identidade, revisão e status confiáveis.

Vendor Data e documentação de fornecedores

Documentação de fornecedores é uma das fontes mais relevantes e mais frequentemente mal integrada ao As-Built. Datasheets, desenhos certificados, manuais, curvas, certificados, listas de peças, configurações, relatórios de FAT e recomendações de manutenção descrevem características que nem sempre aparecem no projeto multidisciplinar.

O problema surge quando a vendor data permanece em um repositório paralelo e não é reconciliada com o equipamento instalado. Uma documentação de fabricante genérica pode incluir várias versões do mesmo produto; um desenho aprovado durante procurement pode ter sido substituído; um FAT pode registrar configuração anterior à alteração feita no site.

Reconciliação por equipamento

Procurement e fabricação: As-Built começa antes da montagem

Decisões de procurement alteram a configuração antes que o equipamento chegue ao campo. Substituições aprovadas, vendor deviations, desenhos certificados e interfaces de fabricação podem modificar dimensões, cargas, pontos de conexão, requisitos de energia e automação.

Por isso, o processo de As-Built deve capturar mudanças desde a aprovação de fornecedor. Esperar a instalação para descobrir que o equipamento entregue difere do projeto-base força a equipe a reconstruir decisões que já estavam disponíveis durante procurement.

FAT como fonte de configuração

Em equipamentos complexos, o FAT pode produzir evidência de firmware, software, parâmetros, lógica e condição de fabricação. O registro precisa ser preservado e posteriormente reconciliado com SAT/comissionamento, porque a configuração de fábrica pode mudar depois da instalação.

Work Packages e produção progressiva do As-Built

Uma prática madura é associar o As-Built aos pacotes de trabalho. Cada construction work package ou installation work package pode possuir documentos de referência, inspeções, redlines, testes e evidências de fechamento. Ao concluir um pacote, a equipe entrega também o estado atualizado da informação correspondente.

Isso reduz o pico de trabalho no encerramento e melhora a qualidade porque a verificação ocorre enquanto pessoas, acesso e contexto ainda estão disponíveis. A lógica pode ser conectada à systemization para formar pacotes finais por sistema.

Obras ocultas e o momento correto da captura

O atributo mais caro de reconstruir é aquele que deixa de ser observável. Redes enterradas, tubulações embutidas, armaduras, inserts, caixas fechadas e rotas sobre forros podem exigir captura antes do fechamento. O plano de As-Built deve identificar antecipadamente esses pontos.

A responsabilidade de registrar a condição antes do fechamento precisa estar explícita. Se a equipe de As-Built é chamada somente depois, pode ser impossível confirmar a posição sem métodos invasivos ou inferência.

Hold point documental

Para itens críticos, pode ser estabelecido um hold point de documentação: o fechamento físico só ocorre após a evidência mínima ser coletada e vinculada ao registro correspondente. Essa prática deve ser definida no ITP/QCP do projeto quando aplicável; não é um requisito universal, mas um controle de governança particularmente eficaz para elementos ocultos.

Integração com ITP e Quality Control Plan

Planos de inspeção e testes já definem atividades, critérios, registros e pontos de intervenção de qualidade. O As-Built pode reutilizar essa infraestrutura para identificar quais resultados devem alimentar a baseline. O objetivo é evitar sistemas paralelos: um registro de inspeção aprovado não deveria precisar ser “redescoberto” pela equipe documental meses depois.

Uma matriz ITP × As-Built pode indicar para cada inspeção quais documentos, atributos ou modelos precisam ser atualizados em caso de desvio ou aprovação de alteração.

Não conformidade, desvio e mudança: efeitos diferentes sobre o As-Built

Uma não conformidade indica que o executado não atende a um requisito. O fechamento pode ocorrer por correção, aceitação de desvio conforme processo aplicável ou outra disposição formal. O As-Built precisa representar o estado final aceito — mas não pode apagar o histórico que explica por que a condição se tornou diferente do projeto original.

Uma mudança aprovada, por sua vez, altera deliberadamente a baseline. Um desvio de campo sem aprovação não deve ser simplesmente “desenhado como As-Built” para transformar fato consumado em condição aceita. Primeiro deve haver decisão técnica e contratual apropriada.

Matriz de disposição

Estratégia de amostragem

Verificar 100% de todos os atributos pode ser inviável. A amostragem deve ser definida com base em criticidade, repetitividade, histórico de qualidade, método construtivo e possibilidade de detecção posterior. Não existe um percentual universal adequado.

Itens críticos para segurança ou operação podem exigir verificação integral. Sistemas repetitivos e de menor impacto podem admitir amostragem, desde que critérios de expansão sejam definidos: se uma amostra falha, aumenta-se a cobertura até recuperar confiança.

Amostragem orientada por risco

O risco pode combinar probabilidade de erro, consequência e detectabilidade. Um atributo com baixa probabilidade, mas consequência catastrófica, pode justificar verificação intensa. Um atributo facilmente conferível na operação pode receber estratégia diferente.

Proveniência e cadeia de custódia da evidência

Para que uma evidência sustente o aceite, precisa ser possível compreender sua origem. Quem coletou? quando? com qual instrumento? sobre qual ativo? em qual condição? qual documento estava vigente? houve transformação do dado? A proveniência se torna especialmente importante em levantamentos digitais, fotografias, modelos e exportações.

Não é necessário transformar todo projeto em sistema forense, mas a evidência crítica deve ser suficientemente rastreável para que um revisor independente compreenda como a conclusão foi obtida.

Integridade digital e preservação de arquivos

Arquivos digitais podem sofrer corrupção, substituição silenciosa, perda de propriedades ou alteração sem histórico. Para entregáveis críticos, convém considerar mecanismos de controle como permissões, versionamento, logs, backups e verificações de integridade. Checksums podem ser úteis para demonstrar que um arquivo transferido é o mesmo arquivo aceito.

A necessidade desses controles deve ser proporcional ao risco e ao ambiente. O princípio é preservar a relação entre conteúdo aceito e objeto armazenado, especialmente quando o arquivo será reutilizado por longos períodos.

Segurança da informação no As-Built

Documentação As-Built pode conter informações sensíveis sobre infraestrutura crítica, rotas, sistemas de segurança, topologias de rede, acessos e configurações. A entrega indiscriminada de tudo a todos contraria boa governança. A classificação de acesso deve fazer parte do handover.

Credenciais, chaves privadas, senhas e segredos operacionais não devem ser tratados como conteúdo comum do Data Book. A organização precisa definir repositórios e canais apropriados, separando informação técnica necessária à manutenção de informação que exige custódia restrita.

Qualidade de dados de ativos

Quando o As-Built inclui dados estruturados, qualidade deixa de significar apenas “documento legível”. Os dados precisam ser completos, válidos, consistentes, únicos e vinculados ao ativo correto. Um campo preenchido com texto genérico apenas para superar validação formal não cria valor.

Dimensões de qualidade

Federação BIM e responsabilidade por modelos

Em projetos BIM, o modelo federado não elimina a responsabilidade dos modelos de autoria. O As-Built deve definir quais modelos são entregáveis controlados, quem os atualiza, como são federados e quais verificações são feitas antes da publicação.

Uma inconsistência pode surgir porque cada modelo está correto em sua disciplina, mas as coordenadas, níveis, classificações ou identificadores diferem entre eles. A ISO 19650-4 trata continuidade e consistência justamente como critérios de troca de informação.

Aceite de modelo As-Built BIM

O aceite de modelo não deve se limitar a abrir o arquivo sem erro. Os critérios podem incluir georreferenciamento/sistema de coordenadas, disciplina e federação, estrutura de contêineres, classificação, propriedades requeridas, ausência de elementos duplicados, nível de informação necessária, correspondência com documentos publicados e resultado de verificações geométricas.

Amostras de campo podem ser usadas para verificar a representação, mas o percentual e a tolerância precisam estar definidos no plano. A expressão “modelo conforme construído” deve possuir significado técnico mensurável.

Temporary Works, provisórios e elementos removidos

Durante a execução podem existir alimentações temporárias, suportes provisórios, desvios, by-passes, tapumes, redes temporárias e configurações transitórias. O As-Built final deve evitar incorporar elementos removidos como se fossem permanentes, mas os registros desses estados podem precisar ser preservados no histórico do projeto.

A distinção entre “existiu durante a obra” e “integra a configuração final” é importante para auditoria e investigação de eventos sem contaminar a baseline operacional.

Demolição, retirada e aposentadoria de ativos

As-Built também registra ausência. Em retrofit, não basta adicionar o novo: ativos removidos precisam ser retirados de plantas, listas, modelos e bancos de ativos, ou receber estado de aposentado conforme a governança. Manter componentes demolidos na documentação cria falsos ativos e pode gerar erros de manutenção.

Gestão de requisitos de informação do ativo

O AIR deve orientar quais dados precisam sobreviver à fase de entrega. Para alguns proprietários, serial e garantia são críticos; para outros, capacidade, criticidade, localização, materiais ou planos de manutenção são prioritários. Um framework corporativo pode padronizar o conjunto mínimo por classe de ativo.

A definição do AIR antes da contratação evita que fornecedores entreguem dados em formatos incompatíveis ou que a equipe de encerramento precise extrair manualmente informações de centenas de PDFs.

Handover progressivo e múltiplas baselines

Em projetos com entrega por sistemas, cada sistema pode atingir seu gate final em datas diferentes. A organização passa a manter simultaneamente sistemas em construção, sistemas em comissionamento e sistemas sob custódia operacional. O As-Built precisa acompanhar esses estados.

Uma matriz de custody/status pode indicar para cada sistema qual baseline está vigente e quem possui autoridade para modificá-lo. Alterações posteriores a um handover parcial devem seguir controle de mudança da operação, ainda que a obra global não esteja concluída.

Interface com Operação Assistida

Durante Operação Assistida podem surgir ajustes adicionais, especialmente em sistemas críticos. O contrato deve definir se e como esses ajustes reabrem o As-Built. A regra recomendada é simples: qualquer alteração aceita que mude a configuração operacional precisa retornar à baseline antes do encerramento definitivo do suporte.

Registro de riscos do As-Built

O processo deve possuir seu próprio registro de riscos informacionais. Exemplos incluem ausência de desenhos de partida, áreas inacessíveis, instrumentos indisponíveis, modelos sem coordenadas confiáveis, fornecedor que não entrega arquivos nativos, incompatibilidade de versões de software e prazo de campo insuficiente.

Cada risco deve ter responsável, resposta e impacto sobre a confiança da baseline. A transparência sobre limitações é superior à tentativa de esconder incertezas sob um carimbo final.

Exemplo de risk register

Acceptance Matrix

Para grandes empreendimentos, uma matriz de aceite permite transformar requisitos dispersos em critérios executáveis. Cada linha pode representar sistema, documento ou atributo e indicar responsável pela produção, evidência, verificador, condição de aceite e status.

Auditoria independente do As-Built

Em ativos críticos ou contratos de alto valor, uma auditoria independente pode avaliar a confiabilidade sem reproduzir todo o levantamento. A auditoria seleciona sistemas e atributos críticos, verifica rastreabilidade, confronta campo, revisa evidências e testa completude do pacote.

O resultado não deve ser apenas “aprovado/reprovado”, mas um parecer sobre nível de confiança, não conformidades, limitações e ações necessárias para aceite.

Plano de mobilização do As-Built

Antes de iniciar a execução, o projeto pode realizar uma mobilização específica do processo de informação: testar templates, nomenclatura, CDE, exportações, formulários de redline, aplicativos de campo, estrutura de fotos, workflows e responsabilidades. A ISO 19650-4 reforça o valor de testar os métodos e formatos antes das trocas reais.

Esse teste evita descobrir no encerramento que arquivos não são interoperáveis, que campos obrigatórios não foram coletados ou que o fluxo de aprovação não consegue produzir evidência de aceite.

Governança por fase do empreendimento

Planejamento e contratação

Definir requisitos, AIR/EIR quando aplicáveis, MDR inicial, formatos, papéis, metodologia de campo e critérios de aceite.

Projeto

Estabelecer baseline autorizada e identificar documentos que precisarão refletir a condição final.

Procurement

Capturar vendor data, desvios e interfaces que alteram o projeto.

Construção

Manter redlines, registros de execução, inspeções e evidências de elementos ocultos.

Comissionamento

Reconciliar configuração testada, mudanças, retestes e documentação.

Encerramento

Executar QA/QC, reconciliação, aceite e Data Book.

Operação

Incorporar a baseline, definir custódia e manter atualização após novas mudanças.

Self-assessment de prontidão do As-Built

A pontuação não constitui norma nem certificação; serve como ferramenta de diagnóstico interno. Organizações com resultado baixo devem priorizar fundamentos antes de investir em automação sofisticada.

Princípios para um padrão corporativo de As-Built

1. uma definição corporativa única de As-Built e seus estados;
2. uma taxonomia comum de documentos, sistemas e ativos;
3. requisitos mínimos escaláveis por criticidade;
4. templates de MDR, redline, change register e acceptance matrix;
5. métodos de verificação selecionados por finalidade;
6. QA/QC baseado em regras e risco;
7. integração obrigatória com comissionamento e handover;
8. destino operacional da informação definido;
9. processo contínuo de atualização após a entrega;
10. lições aprendidas incorporadas ao padrão.

Rotinas de governança recomendadas

Um framework de As-Built só se sustenta quando existe cadência de gestão. A organização precisa retirar o processo do modo “mutirão de encerramento” e transformá-lo em rotina de projeto. A frequência deve acompanhar o ritmo das mudanças e o porte do empreendimento.

Essas rotinas não são exigências normativas universais; são mecanismos de governança que reduzem o tempo entre ocorrência da mudança e atualização da informação.

Pacote mínimo de templates corporativos

Empresas que executam projetos recorrentes podem reduzir variabilidade mantendo templates corporativos adaptáveis ao contrato. Um conjunto mínimo pode incluir: Plano de As-Built; MDR; matriz sistema × documento; registro de baseline; formulário/redline digital; change register; matriz de impacto documental; plano de levantamento; formulário de evidência de campo; checklist QA/QC; acceptance matrix; registro de comentários; reconciliation report; handover register; e registro de lições aprendidas.

O template não deve engessar o processo. Seu papel é garantir que perguntas fundamentais sejam respondidas de forma consistente e que novos projetos não precisem reinventar controles básicos.

Glossário técnico do framework

• As-Built: informação final da condição executada dentro do escopo e dos critérios definidos.
• Baseline: estado de referência controlado usado para identificar e governar mudanças.
• Redline: registro intermediário de alteração em relação a uma referência.
• MDR: Lista Mestra de Documentos usada para controlar universo, revisão, status e entregas.
• CDE: ambiente comum de dados utilizado para coletar, gerenciar e disseminar contêineres de informação em processo controlado.
• PIM: modelo de informação associado à fase de entrega do empreendimento.
• AIM: modelo de informação associado à fase operacional do ativo.
• AIR: requisitos de informação do ativo, orientados às necessidades de gestão e operação.
• EIR: requisitos de troca de informação aplicáveis a compromissos e entregas específicas.
• QA/QC: garantia e controle da qualidade aplicados à produção e à revisão da informação.
• Systemization: decomposição do empreendimento em sistemas e subsistemas para gestão de completação, testes e entrega.
• Data Book: dossiê estruturado de documentos e evidências da execução e entrega.
• Handover: transferência estruturada de ativo, informação, conhecimento e responsabilidade para operação.

Critério final de sucesso do framework

O teste mais exigente para o As-Built não ocorre na data da entrega. O teste ocorre na próxima intervenção, quando uma equipe que não participou da obra precisa localizar um ativo, compreender sua configuração, planejar uma mudança e confiar na informação disponível. Se a equipe precisa reconstruir tudo em campo, a entrega documental foi formalmente concluída, mas o objetivo de ciclo de vida não foi alcançado.

Por isso, o sucesso deve ser medido pela capacidade de recuperar, interpretar, verificar e reutilizar a baseline com esforço proporcional ao ativo. Essa é a diferença entre arquivo histórico e infraestrutura de informação de engenharia.

Referências técnicas

1. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 13133:2021 — Execução de levantamento topográfico — Procedimento. Versão corrigida em 2025. Disponível no Catálogo ABNT.
2. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 14645-1:2001 — Elaboração do como construído (as built) para edificações — Parte 1. Disponível no Catálogo ABNT.
3. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 17047:2022 — Levantamento cadastral territorial para registro público — Procedimento. Disponível no Catálogo ABNT.
4. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 17058:2022 — Locação topográfica e controle dimensional de edificação — Procedimento. Disponível no Catálogo ABNT.
5. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 16752:2020 — Desenho técnico — Requisitos para apresentação em folhas de desenho. Disponível no Catálogo ABNT.
6. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-1:2018 — Information management using building information modelling — Part 1: Concepts and principles. Fonte oficial ISO.
7. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-2:2018 — Information management using building information modelling — Part 2: Delivery phase of the assets. Fonte oficial ISO.
8. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using building information modelling — Part 3: Operational phase of the assets. Fonte oficial ISO.
9. INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-4:2022 — Information management using building information modelling — Part 4: Information exchange. Fonte oficial ISO.
10. INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 62337:2012 — Commissioning of electrical, instrumentation and control systems in the process industry. Fonte oficial IEC.

Conclusão técnica

As-Built é uma disciplina de preservação da verdade técnica do ativo. Seu valor não está no carimbo, no número de folhas nem na quantidade de arquivos entregues, mas na capacidade de manter coerência entre condição física, configuração funcional, evidências, documentação e responsabilidade. Quando essas dimensões convergem, a organização possui uma baseline utilizável. Quando divergem, possui apenas documentação com aparência de encerramento.

O framework apresentado demonstra que a confiabilidade do As-Built depende de decisões tomadas muito antes da emissão final: definição de requisitos, estabelecimento de baselines, captura contínua de mudanças, escolha adequada de métodos de levantamento, controle de precisão, gestão documental, auditoria entre fontes e integração com testes. A etapa final é consequência dessa cadeia.

A série ABNT NBR ISO 19650 oferece uma arquitetura robusta para tratar a informação como um ativo controlado, especialmente ao separar produção, compartilhamento, autorização, aceitação e continuidade. A ABNT NBR 13133 e as normas topográficas complementares mostram que a condição de campo precisa ser obtida por métodos compatíveis com a finalidade e com controle de qualidade. A ABNT NBR IEC 62337 reforça, em seu domínio, que a configuração final só se torna defensável quando testes, modificações e documentação permanecem conectados.

Em termos de governança, o As-Built deve ser tratado como um sistema de configuração com cinco gates: baseline controlada → mudança reconciliada → condição verificada → pacote tecnicamente coerente → baseline aceita e transferida. Essa sequência reduz dependência de memória, evita o congelamento prematuro da informação e torna o aceite baseado em evidências.

O resultado de maturidade não é “ter um As-Built”. É possuir uma organização capaz de responder, anos depois da entrega, qual é a configuração do ativo, por que ela é assim, quais mudanças a produziram, quais evidências a confirmaram e qual informação deve ser usada para a próxima decisão de engenharia. Quando essa capacidade existe, o As-Built deixa de ser uma obrigação de encerramento e passa a funcionar como infraestrutura técnica para o ciclo de vida do ativo.