Entenda como estruturar um modelo de As-Built Digital com BIM, dados de ativos, formatos abertos, interoperabilidade, validação, PIM/AIM e critérios de entrega para operação.
Confira!
O modelo de As-Built Digital é a representação estruturada da condição efetivamente construída de um ativo, reunindo geometria, dados, documentos e relações necessárias para que a informação final possa ser verificada, entregue, reutilizada e mantida ao longo do ciclo de vida. Ele pode incluir um modelo BIM, mas não se limita ao arquivo tridimensional nem ao software em que esse arquivo foi produzido.
Na prática, o As-Built Digital precisa responder a duas perguntas diferentes: o que foi efetivamente construído e quais informações dessa condição precisam permanecer utilizáveis depois da entrega. A primeira exige reconciliação com campo, execução, alterações, ensaios e evidências; a segunda exige estrutura de dados, identificação, formatos, revisão, interoperabilidade, critérios de aceite e conexão com a operação.
Por isso, um arquivo RVT, IFC ou DWG denominado “As-Built” não é automaticamente um modelo de As-Built confiável. A confiabilidade depende da origem dos dados, do nível de verificação realizado, da coerência entre geometria e informação não gráfica e da capacidade de demonstrar que o conteúdo entregue corresponde à condição aceita do ativo.
Em ambientes BIM, o As-Built Digital passa a funcionar como ponte entre a fase de entrega e a fase operacional. A série ABNT NBR ISO 19650 trata modelos de informação como conjuntos de contêineres estruturados e não estruturados e estabelece processos para troca, aceitação e incorporação de informação ao Modelo de Informação do Ativo (AIM). Isso torna o As-Built parte de um processo de gestão da informação, e não apenas uma última revisão gráfica.
O que é um modelo de As-Built Digital
Um modelo de As-Built Digital é um conjunto controlado de informações que representa a configuração executada e aceita de uma edificação, instalação, infraestrutura ou sistema. Dependendo do empreendimento, pode reunir modelo BIM, desenhos, tabelas, banco de dados de ativos, listas de equipamentos, documentos técnicos, registros de comissionamento, fotografias, relatórios e outros contêineres relacionados à condição final.
O termo “digital” não deve ser usado apenas porque o documento está em PDF ou porque existe um arquivo CAD. O ganho real aparece quando a informação final possui estrutura suficiente para ser pesquisada, relacionada, validada, versionada, intercambiada e reutilizada em novos processos de engenharia ou operação.
Em um empreendimento simples, o As-Built Digital pode ser um conjunto coordenado de desenhos nativos, PDFs controlados, tabelas de ativos e registros técnicos. Em um empreendimento BIM, pode assumir a forma de um modelo federado com propriedades, classificações, identificadores e relações com documentos externos. Em ambos os casos, o critério principal é a adequação da informação ao uso pretendido.
As-Built Digital, As-Built tradicional, BIM e Digital Twin não são a mesma coisa
Os termos se aproximam, mas não são equivalentes.
| Conceito | Função principal | Característica dominante | Limitação típica |
| As-Built tradicional | registrar a condição executada | desenhos e documentação final | pode ter pouca estrutura de dados |
| As-Built Digital | registrar e estruturar a condição executada | arquivos digitais coordenados, dados e documentos | exige requisitos claros de informação |
| modelo BIM As-Built | representar a condição construída em ambiente BIM | geometria + informação estruturada | pode ser incompleto se modelado sem validação de campo |
| Scan to BIM | converter captura da realidade em modelo | reconstrução geométrica a partir de nuvem de pontos | não comprova sozinho função, especificação ou condição de ativos |
| AIM | suportar a fase operacional do ativo | modelo de informação relacionado à operação | depende de requisitos de informação do ativo |
| Digital Twin | representar e acompanhar dinamicamente um ativo | integração contínua entre informação digital e estado do ativo | exige integrações, sensores, processos e atualização além do As-Built |
Um As-Built Digital pode alimentar um AIM e pode ser uma das bases para um Digital Twin. Isso não significa que todo As-Built Digital seja um AIM completo ou um gêmeo digital.
Modelo de informação não significa apenas modelo 3D
A ABNT NBR ISO 19650-1 define modelo de informação como um conjunto de contêineres de informação estruturados e não estruturados. Essa distinção é fundamental para o As-Built Digital.
Geometria tridimensional é apenas uma parte do conjunto. Um equipamento pode estar corretamente posicionado no modelo e ainda faltar informação essencial sobre fabricante, modelo, capacidade, número de série, circuito associado, documentação de operação, manutenção, garantia, comissionamento ou identificação patrimonial.
Da mesma forma, um Data Book completo pode possuir excelente evidência documental e ainda não oferecer uma representação espacial adequada para futuras intervenções.
O objetivo deve ser construir uma arquitetura de informação coerente entre geometria, dados de ativos e documentos de suporte.
O que deve existir em um modelo de As-Built Digital
A composição varia conforme o ativo, mas pode ser organizada em cinco camadas.
Geometria da condição construída
A geometria deve representar os elementos necessários ao uso definido para o As-Built. Nem todo componente precisa ser modelado com o mesmo nível de granularidade.
Podem estar incluídos:
- arquitetura e espaços;
- estrutura;
- instalações elétricas;
- sistemas hidrossanitários;
- HVAC;
- incêndio;
- telecomunicações;
- segurança eletrônica;
- automação e instrumentação;
- utilidades industriais;
- equipamentos principais;
- infraestrutura enterrada ou externa;
- áreas técnicas e acessos de manutenção.
A decisão sobre o que modelar deve estar associada às decisões futuras que o proprietário precisa tomar.
Dados de ativos
Os elementos relevantes podem receber atributos como:
- código único do ativo;
- sistema e subsistema;
- fabricante;
- modelo;
- número de série;
- capacidade;
- especificação principal;
- localização;
- status operacional;
- data de instalação;
- referência de garantia;
- criticidade;
- documentação associada;
- identificadores utilizados em CMMS, ERP, BMS, SCADA ou outro sistema corporativo.
A lista deve ser definida a partir dos requisitos de informação, não a partir de todos os campos que o software permite preencher.
Relações e conectividade
Um As-Built Digital tecnicamente útil precisa representar, quando aplicável, relações que não são apenas geométricas.
Exemplos:
- quadro que alimenta determinado circuito;
- circuito que alimenta um equipamento;
- equipamento pertencente a determinado sistema;
- prumada que atende determinados pavimentos;
- sensor associado a um controlador;
- ativo relacionado a uma área ou espaço;
- documento associado a um equipamento;
- equipamento dependente de outro sistema para operação.
Essas relações permitem que o modelo deixe de ser apenas representação visual e passe a funcionar como estrutura de informação.
Documentos vinculados
O conjunto pode apontar para:
- datasheets;
- manuais de operação e manutenção;
- certificados;
- relatórios de ensaio;
- laudos;
- registros de comissionamento;
- fotografias;
- diagramas;
- memoriais;
- procedimentos;
- termos de aceite;
- garantias;
- documentação de fornecedores.
Não é obrigatório incorporar fisicamente todos os documentos dentro do modelo. Em muitos casos é preferível manter documentos em um ambiente documental controlado e vincular os respectivos identificadores.
Metadados de gestão da informação
Revisão, status, autoria, data, disciplina, classificação, adequação ao uso e histórico precisam permanecer controlados. Sem isso, o conjunto final pode perder rastreabilidade mesmo que o conteúdo técnico esteja correto.
A origem da informação precisa ser conhecida
Um dos maiores riscos do As-Built Digital é apresentar precisão visual maior do que a evidência disponível.
A geometria e os dados podem ter diferentes origens:
- modelo de projeto atualizado durante a execução;
- redlines;
- levantamento final;
- Laser Scanning;
- topografia;
- nuvem de pontos;
- inspeções de campo;
- registros fotográficos;
- documentação de fabricantes;
- testes e ensaios;
- comissionamento;
- cadastro de ativos;
- informações fornecidas pela operação;
- reconstrução por engenharia reversa.
Quando essas fontes são misturadas sem classificação, uma informação inferida pode parecer tão confiável quanto uma medição direta.
Classificação da confiabilidade da informação
Uma matriz simples pode ajudar a declarar como cada informação foi obtida.
| Classe | Origem típica | Tratamento recomendado |
| verificada em campo | medição, inspeção, scan ou ensaio atual | pode sustentar a representação dentro da precisão declarada |
| verificada por evidência de execução | redline controlado, registro fotográfico, relatório de inspeção | utilizar com rastreabilidade da evidência |
| documental confirmada | documentação de fabricante ou emissão aceita compatível com o ativo | manter vínculo com a fonte |
| documental não confirmada | projeto ou As-Built anterior não confrontado | declarar como informação a verificar quando crítica |
| inferida | reconstrução lógica ou geométrica | identificar explicitamente a inferência |
| desconhecida | informação não disponível | manter lacuna e definir tratamento |
A classificação não precisa necessariamente usar esses mesmos nomes. O importante é impedir que hipótese e fato sejam apresentados como equivalentes.
Um modelo digital só é confiável quando geometria, dados e documentos podem ser relacionados às evidências que sustentam a condição construída. A qualidade do As-Built depende tanto da representação final quanto da rastreabilidade de como cada informação foi confirmada.
Como elaborar o modelo de As-Built Digital
Uma sequência robusta pode ser estruturada da seguinte forma:
- Definir os objetivos de uso do As-Built após a entrega.
- Identificar sistemas, disciplinas e ativos incluídos.
- Definir requisitos de informação e responsabilidades.
- Estabelecer formatos, software, convenções e CDE.
- Definir nível de informação necessária por classe de elemento.
- Planejar como alterações de obra serão capturadas.
- Controlar redlines, revisões e decisões de engenharia.
- Definir estratégia de levantamento e validação de campo.
- Atualizar progressivamente modelos, desenhos e dados.
- Reconciliar projeto, execução, levantamento e evidências.
- Integrar dados de equipamentos e documentos associados.
- Verificar geometria, propriedades, classificações e relações.
- Realizar checagens de interoperabilidade e troca de informação.
- Resolver issues e inconsistências antes da emissão final.
- Submeter o conjunto para revisão e aceite.
- Publicar a versão aceita no ambiente documental acordado.
- Transferir a informação pertinente para o AIM e sistemas operacionais.
- Estabelecer processo para atualização futura após novas intervenções.
O ponto central é que o As-Built não deve nascer apenas no encerramento. A captura progressiva reduz a necessidade de reconstruir informações que deixaram de ser observáveis.
Scan to BIM e As-Built Digital têm funções diferentes
O processo de Scan to BIM transforma dados de captura da realidade em um modelo digital estruturado da condição existente. Isso pode ser uma etapa importante do As-Built Digital, especialmente em instalações existentes ou quando o modelo de projeto não foi mantido durante a obra.
Mas Scan to BIM não encerra o As-Built.
O scan comprova principalmente geometria visível. Ele não informa automaticamente função, lógica de controle, capacidade, identificação de circuitos, especificação interna de equipamento, relação documental ou estado operacional.
Por isso, um processo de As-Built Digital pode usar nuvem de pontos como uma das fontes e combinar essa evidência com documentos, inspeções, dados de ativos e registros de comissionamento.
A nuvem de pontos deve permanecer como evidência de referência
A nuvem de pontos em engenharia pode ser valiosa mesmo depois que o modelo BIM é produzido.
Ela preserva um registro denso da geometria observada em determinada data. Isso permite revisitar áreas que não foram inicialmente modeladas e verificar discrepâncias futuras.
Entretanto, o contrato precisa estabelecer se a nuvem de pontos faz parte do entregável definitivo, quais formatos serão fornecidos, qual sistema de coordenadas foi utilizado, qual precisão foi alcançada e como os arquivos serão preservados.
A captura 3D ganha valor quando responde a uma necessidade de engenharia definida. Precisão, cobertura, sistema de coordenadas e forma de entrega devem ser compatíveis com a validação geométrica que o As-Built precisa sustentar.
Quando a captura 3D melhora a confiabilidade geométrica do As-Built →
O nível de informação precisa ser definido pelo uso
Modelar tudo com máximo detalhe é caro, pesado e frequentemente inútil.
A ABNT NBR ISO 19650 trabalha com o conceito de nível de informação necessária: alcance e granularidade devem ser suficientes para atender ao objetivo, evitando informação excessiva.
Para um motor, por exemplo, pode ser relevante registrar posição, envelope, código, potência, tensão, fabricante, modelo e documentação associada. Modelar parafusos, ranhuras e componentes internos pode não gerar valor algum para operação.
Para uma tubulação enterrada, por outro lado, posição, cota, diâmetro, material e pontos de mudança de direção podem ser decisivos para futuras intervenções.
A granularidade deve ser distribuída de acordo com criticidade, uso e custo de manutenção da informação.
Geometria precisa e dado confiável são dimensões diferentes
Um modelo pode ter excelente aderência geométrica e dados ruins. Também pode ocorrer o inverso.
Por isso convém separar critérios de qualidade em dimensões distintas:
| Dimensão | Pergunta de verificação |
| posição | o elemento está no local correto? |
| geometria | forma e dimensões são adequadas ao uso? |
| identidade | o elemento possui identificação inequívoca? |
| propriedades | os atributos necessários estão preenchidos e corretos? |
| relação | conexões e pertencimento a sistemas estão representados? |
| documentação | documentos associados correspondem ao ativo correto? |
| revisão | a informação pertence à emissão aceita? |
| evidência | é possível rastrear como a informação foi confirmada? |
Isso evita reduzir o aceite à comparação visual entre modelo e point cloud.
As-Built Digital e PIM
Durante a fase de entrega, o Modelo de Informação do Projeto (PIM) reúne informação utilizada e produzida pelo empreendimento.
Um erro comum é assumir que o último PIM automaticamente se torna o modelo operacional. Antes da transição, o conjunto precisa ser reconciliado, revisado, aceito e filtrado conforme os requisitos da operação.
Elementos temporários, alternativas descartadas, objetos utilizados apenas para coordenação e informações internas de produção podem não ter utilidade no ambiente operacional.
O As-Built Digital funciona como uma das etapas de consolidação dessa condição final do empreendimento.
Do PIM ao AIM
A relação entre PIM e AIM é especialmente importante no encerramento.
A ABNT NBR ISO 19650-1 estabelece que PIM e AIM possuem funções distintas e que informação relevante é transferida entre eles no início e no fim de um empreendimento. A ABNT NBR ISO 19650-3 trata da fase operacional e prevê a aceitação de modelos de informação e sua agregação ao AIM.
Isso significa que o handover não deveria ser interpretado como simples cópia da pasta de projeto para a pasta de operação.
A informação precisa ser avaliada em relação ao que a operação realmente necessita.
O handover só cria valor operacional quando o conteúdo entregue foi selecionado e aceito conforme os requisitos do ativo. Transferir integralmente o último conjunto de projeto não substitui a estruturação da informação que será mantida na operação.
Como organizar a transição da informação de projeto para o modelo do ativo →
AIR: os requisitos operacionais deveriam influenciar o As-Built desde o início
Os Asset Information Requirements (AIR) expressam quais informações do ativo são necessárias para atender aos objetivos da organização na fase operacional.
Quando os AIR são definidos apenas no final, a equipe pode descobrir que dados necessários nunca foram coletados.
Exemplos de requisitos que podem afetar o As-Built:
- códigos patrimoniais;
- estrutura de localização;
- classes de ativos;
- atributos mínimos por tipo de equipamento;
- documentação de manutenção;
- dados de garantia;
- identificadores para integração com CMMS;
- parâmetros para BMS ou supervisão;
- informação necessária para inspeções regulamentares;
- relações entre equipamento e sistema;
- formatos e esquemas de troca.
A melhor estratégia é definir esses requisitos antes que a informação precise ser produzida.
COBie pode apoiar o handover, mas não substitui o modelo
COBie é uma abordagem estruturada para troca de dados de ativos no handover e pode ser útil quando prevista nos requisitos do empreendimento.
Ela não substitui automaticamente modelos geométricos, desenhos, documentos ou outras informações técnicas. Sua função depende dos sistemas que irão consumir os dados e da estratégia de gestão de ativos adotada.
O critério deve ser interoperabilidade e uso real, não a inclusão de um formato apenas porque ele está associado a BIM.
Formatos de entrega: nativo, aberto e de visualização
Um As-Built Digital robusto normalmente não deveria depender de um único formato.
Uma estratégia pode prever três camadas:
| Camada | Exemplos | Objetivo |
| arquivo nativo | RVT, DWG, arquivos de autoria equivalentes | permitir continuidade de edição quando contratualmente necessário |
| formato aberto | IFC, CSV, formatos de troca definidos | reduzir dependência de plataforma e facilitar interoperabilidade |
| formato de emissão | PDF, relatórios, documentos assinados | preservar representação controlada e evidência formal da entrega |
O conjunto exato precisa ser definido no Termo de Referência.
IFC no As-Built Digital
O IFC é um padrão aberto e internacional para compartilhamento de dados do ambiente construído e pode ser utilizado como uma das camadas de interoperabilidade do As-Built Digital.
Sua utilidade depende da versão, dos requisitos de troca, do escopo de informação e da capacidade dos softwares emissores e receptores.
Exportar um IFC sem verificar o resultado não é interoperabilidade. A troca precisa ser testada e revisada em relação aos dados que deveriam chegar ao destino.
Em alguns fluxos, determinados parâmetros podem ser corretamente preservados; em outros, propriedades, classificações, relações ou geometrias específicas podem exigir mapeamento adicional.
O CDE deve preservar estados, revisões e rastreabilidade
O Ambiente Comum de Dados (CDE) fornece o processo controlado para gestão dos contêineres de informação.
No As-Built Digital, isso ajuda a impedir que arquivos de trabalho sejam confundidos com documentos finais aceitos.
Estados como trabalho em andamento, compartilhado, publicado e arquivado cumprem funções diferentes. O proprietário precisa saber qual conjunto representa a emissão formal utilizada para decisão e qual conteúdo permanece apenas como histórico.
A entrega As-Built deve apontar inequivocamente para a revisão aceita.
Critérios de troca de informação segundo a ABNT NBR ISO 19650-4
A ABNT NBR ISO 19650-4 detalha o processo de troca e os critérios para apoiar a qualidade dos modelos de informação do projeto e do ativo.
Para o As-Built Digital, os grupos de critérios são particularmente úteis porque impedem que a validação seja reduzida a “o arquivo abriu”.
A revisão pode considerar:
- ambiente comum de dados;
- conformidade;
- continuidade;
- comunicação;
- consistência;
- completude;
- critérios específicos definidos pelo empreendimento.
Esses critérios precisam ser transformados em verificações objetivas no plano de entrega.
Matriz de validação do As-Built Digital
Uma matriz de aceite pode relacionar requisito, método e evidência.
| Critério | Exemplo de verificação | Evidência de aceite |
| completude | todos os sistemas e áreas contratados foram entregues | matriz de entregáveis encerrada |
| geometria | amostras críticas conferem com levantamento final | relatório de verificação |
| atributos | propriedades obrigatórias estão preenchidas | relatório automatizado ou checklist |
| identificação | códigos são únicos e coerentes com cadastro | exportação de ativos validada |
| interoperabilidade | arquivo aberto é importado sem perda crítica | relatório de teste de troca |
| coordenação | conflitos críticos foram resolvidos | registro de issues encerradas |
| revisão | arquivos pertencem à emissão final aceita | CDE e transmittal |
| documentos | vínculos apontam para documentos corretos | amostragem e validação documental |
| operação | dados necessários ao AIM foram aceitos | termo de handover ou aceite |
O critério deve ser definido antes da entrega, não inventado durante a conferência final.
Validação automática e validação técnica se complementam
Ferramentas podem verificar propriedades obrigatórias, classificação, formato, naming, duplicidade de identificadores e outros requisitos formalizáveis.
Mas uma regra automática não determina, sozinha, se a informação corresponde à realidade física.
A validação técnica pode exigir inspeção, medições, comparação com nuvem de pontos, evidência de execução, revisão por disciplina, comissionamento e conferência de documentos de fornecedor.
O melhor processo combina verificação automatizada de estrutura com verificação de engenharia sobre a condição construída.
As-Built Digital em projetos Brownfield
Em projetos Brownfield, o modelo digital pode ter dois momentos distintos.
Antes da intervenção, pode ser necessário reconstruir uma baseline da condição existente para permitir o desenvolvimento seguro do projeto. Depois da intervenção, a baseline precisa ser novamente atualizada para refletir a nova configuração.
Por isso, Brownfield evidencia a importância de manter a informação como sistema vivo de configuração, e não como arquivo produzido uma única vez.
As-Built Digital não é Digital Twin
A expressão Digital Twin costuma ser usada de forma excessivamente ampla.
Um As-Built Digital registra uma condição construída aceita em determinado momento. Um Digital Twin, em uma aplicação efetiva, normalmente pressupõe mecanismos para manter a representação digital relacionada ao estado atual do ativo, podendo incluir integrações com sistemas operacionais, sensores, histórico, simulações ou outros fluxos de atualização.
O As-Built pode ser uma baseline para esse processo, mas não deve ser vendido como gêmeo digital apenas por possuir geometria 3D e propriedades.
Como especificar o As-Built Digital em Termo de Referência
Um Termo de Referência deve transformar “entregar modelo As-Built” em requisitos verificáveis.
Convém definir:
- Finalidade da informação após a entrega.
- Sistemas, disciplinas e áreas incluídos.
- Requisitos de informação do proprietário.
- Ativos que precisam ser cadastrados.
- Atributos obrigatórios por classe de ativo.
- Convenção de identificação.
- Classificação e estrutura de informação.
- Requisitos geométricos por tipo de elemento.
- Sistema de coordenadas e referências espaciais.
- Tolerâncias e precisão quando aplicáveis.
- Tratamento de elementos ocultos.
- Fontes de evidência aceitas.
- Requisitos de Laser Scanning e nuvem de pontos.
- Critérios para informação inferida ou não verificada.
- Software de autoria quando necessário.
- Formatos nativos de entrega.
- Formatos abertos de troca.
- Versões de IFC ou outros esquemas exigidos.
- Requisitos de interoperabilidade.
- CDE, naming, status e revisões.
- Requisitos para vínculo com documentos.
- Integração com cadastro de ativos, CMMS, ERP, BMS ou sistemas aplicáveis.
- Procedimentos de checagem automatizada.
- Procedimentos de validação técnica em campo.
- Processo de tratamento de issues.
- Critérios de aprovação e aceite.
- Conteúdo a ser transferido ao AIM.
- Estrutura de Data Book e handover.
- Responsabilidades pela atualização durante a execução.
- Responsabilidade pela manutenção da informação depois do aceite.
Sem essas definições, duas propostas para “As-Built BIM” podem representar escopos totalmente diferentes.
O aceite de um As-Built Digital começa na contratação. Requisitos de informação, formatos, responsabilidades, métodos de verificação e critérios de aceite precisam estar definidos antes que a equipe produza os entregáveis finais.
Governança técnica para especificar, revisar e aceitar entregáveis digitais de engenharia →
Como medir o avanço de um escopo de As-Built Digital
A medição contratual pode ser baseada em entregáveis e marcos de maturidade, em vez de apenas porcentagem de modelagem.
Exemplos de marcos:
- Plano de execução e requisitos aprovados.
- Baseline e documentação de referência consolidadas.
- Modelos e dados preliminares por disciplina.
- Atualização pós-execução.
- Levantamento final concluído.
- Reconciliação com campo encerrada.
- Modelo federado e dados de ativos consolidados.
- Testes de interoperabilidade concluídos.
- Documentação e vínculos verificados.
- Emissão As-Built submetida.
- Pendências de revisão encerradas.
- Conjunto aceito e incorporado ao handover.
A estrutura permite relacionar pagamento a evidências objetivas de avanço.
Erros recorrentes
| Erro | Consequência |
| chamar o último modelo de projeto de As-Built | alterações de campo podem ficar ausentes |
| modelar apenas a geometria visível | informação funcional e documental fica incompleta |
| entregar somente arquivo nativo | cria dependência da plataforma de autoria |
| exportar IFC sem validar | perdas de informação podem passar despercebidas |
| exigir atributos sem definir uso | aumenta custo de produção e manutenção de dados inúteis |
| não classificar informação inferida | cria falsa precisão |
| deixar atualização para o final | informações de elementos ocultos são perdidas |
| confundir Scan to BIM com As-Built completo | modelo geométrico é tratado como registro técnico integral |
| não definir identificadores de ativos | integração com operação fica prejudicada |
| ignorar revisão e status | usuários podem operar com emissão incorreta |
| não testar arquivos no software receptor | incompatibilidades aparecem depois do handover |
| chamar As-Built de Digital Twin | cria expectativa de atualização dinâmica inexistente |
As-Built Digital da A3A Engenharia com ENGiOS
A A3A Engenharia estrutura o As-Built Digital como uma solução de engenharia apoiada por governança digital. A condição construída continua sendo estabelecida por levantamento, documentação de execução, inspeção, reconciliação e validação técnica; o ENGiOS entra como a camada que organiza o contexto, o ciclo documental, as revisões, as evidências e a rastreabilidade da informação produzida.
Essa distinção é importante. O ENGiOS não substitui ferramentas de autoria BIM, CAD, Laser Scanning ou processamento de nuvem de pontos. Modelos e registros podem ser produzidos em diferentes ambientes técnicos. A função da plataforma é permitir que esses entregáveis sejam tratados dentro de uma estrutura de projeto e governança, em vez de permanecerem como arquivos finais desconectados.
| Camada | Função no As-Built Digital | Resultado esperado |
|---|---|---|
| Engenharia A3A | levantamento, reconciliação, verificação e validação da condição construída | baseline técnico confiável |
| Autoria e captura digital | BIM, CAD, IFC, nuvem de pontos, documentos e bases de dados | representações e contêineres de informação |
| ENGiOS | projeto, fases, documentos, revisões, registros, evidências, pendências e histórico técnico | informação governada e rastreável |
| Handover e operação | entrega controlada, recuperação da informação e suporte a futuras intervenções | base técnica reutilizável ao longo do ciclo de vida |
Na prática, a solução permite relacionar o As-Built ao projeto que o originou, às fases e disciplinas envolvidas, aos documentos vigentes, aos ciclos de revisão, aos registros de campo e às evidências que sustentaram o aceite. RFIs, não conformidades, pendências e decisões técnicas também podem compor o histórico operacional quando fizerem parte do processo de engenharia.
O resultado pretendido não é simplesmente uma pasta digital mais organizada. É preservar a cadeia de proveniência da informação: qual documento está vigente, de onde veio determinado dado, qual revisão foi aceita, quais evidências sustentam a representação e em que contexto aquela informação deve ser utilizada.
Essa abordagem também evita confundir As-Built Digital com Digital Twin. O ENGiOS pode estruturar a governança da informação técnica e o histórico do ativo, mas a manutenção de uma representação continuamente sincronizada com a condição operacional depende de integrações, sensores, sistemas corporativos e processos de atualização definidos especificamente para esse objetivo.
Na solução de As-Built Digital da A3A Engenharia, o ENGiOS funciona como camada de governança da informação técnica. Modelos, documentos, revisões, evidências, pendências e histórico de decisão permanecem relacionados ao contexto de engenharia que sustenta a condição construída e o aceite.
Como o ENGiOS estrutura governança, documentos e rastreabilidade em operações de engenharia →
Do documento final à base operacional de informação
O maior valor do As-Built Digital aparece quando a entrega deixa de ser um arquivo de encerramento e passa a funcionar como uma base reutilizável para manutenção, reformas, retrofit, inspeções, gestão de ativos e novos projetos.
Essa utilidade depende de disciplina na origem: requisitos definidos antes da captura, atualização progressiva durante a execução, validação da condição construída, estrutura coerente de dados, formatos adequados, interoperabilidade testada e processo formal de aceite.
A cadeia pode ser sintetizada como:
requisitos de informação → projeto e PIM → execução e mudanças → evidências → levantamento final → reconciliação → modelo de As-Built Digital → validação → aceite → handover → AIM → operação e atualização futura.
Quando essa cadeia é preservada, o As-Built deixa de ser apenas registro retrospectivo e passa a reduzir incerteza nas próximas decisões de engenharia 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. Disponível em: ISO 19650-1.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-3:2020 — Information management using building information modelling — Part 3: Operational phase of the assets. Disponível em: ISO 19650-3.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-4:2022 — Information management using building information modelling — Part 4: Information exchange. Disponível em: ISO 19650-4.
[4] BUILDINGSMART INTERNATIONAL. Industry Foundation Classes (IFC). Disponível em: buildingSMART — IFC.
[5] 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 em: ABNT Catálogo.
Perguntas frequentes
É um conjunto estruturado de informações que representa a condição efetivamente construída e aceita de um ativo. Pode incluir modelo BIM, desenhos, dados de ativos, documentos, registros de comissionamento e outros contêineres necessários para entrega e operação.
Não necessariamente. Um modelo BIM pode ser uma parte central do As-Built Digital, mas o conjunto final pode incluir também documentos, tabelas, banco de dados de ativos, registros de ensaio, fotografias e outros arquivos.
Somente se tiver sido reconciliado e validado contra a condição executada e atender aos requisitos de informação e aceite. O fato de ser o último arquivo de autoria não comprova, por si só, que represente o que foi construído.
Não. Scan to BIM pode reconstruir a geometria observável, mas não determina automaticamente função, especificação, identificação, estado operacional, documentação ou relações entre ativos. Essas informações precisam ser obtidas e validadas por outras fontes.
O PIM está relacionado à fase de entrega do empreendimento; o AIM à fase operacional do ativo. No handover, informações relevantes e aceitas do empreendimento precisam ser transferidas e agregadas à base de informação utilizada pela operação.
Não existe uma regra universal. O IFC deve ser exigido quando fizer sentido para a estratégia de interoperabilidade e precisa ter versão, escopo e critérios de validação definidos. Outros formatos nativos e de emissão também podem fazer parte da entrega.
Não. O As-Built registra uma condição construída aceita. Um Digital Twin normalmente pressupõe mecanismos adicionais para manter a representação digital relacionada ao estado atual do ativo por meio de integrações e atualizações ao longo da operação.
O aceite deve verificar completude, fidelidade à condição construída, propriedades, identificação, relações, documentação, revisão, interoperabilidade e atendimento aos requisitos de informação. Testes automáticos devem ser combinados com validação técnica e evidências de campo.
Materiais técnicos complementares
As-Built e condição construída
- Guia Completo de As-Built em Engenharia
- Projeto As-Built em Engenharia
- As-Built Arquitetônico
- As-Built Elétrico
- As-Built Hidrossanitário
Levantamento e captura da realidade
- Levantamento Cadastral de Engenharia
- Laser Scanning 3D em Engenharia
- Nuvem de Pontos em Engenharia
- Scan to BIM
BIM e gestão da informação
- BIM na Engenharia: guia completo
- PIM e AIM no BIM
- Gestão da Informação em BIM
- Requisitos de Informação BIM: OIR, AIR, PIR e EIR
- CDE BIM
- COBie no BIM
- BIM 7D
Coordenação, entrega e operação
- Compatibilização de Projetos
- Data Book de Obra
- Comissionamento: guia completo
- Facility Management
- Engineering Change Management
Referenciais institucionais
