Data Book de Obra: o que é, documentos, estrutura e aceite

Entenda o que é Data Book de obra, quais documentos deve conter, como estruturar vendor data, As-Built, testes e comissionamento e quais critérios aplicar no aceite.

Confira!

O Data Book de obra é o dossiê técnico estruturado que reúne as evidências necessárias para demonstrar o que foi projetado, fornecido, executado, inspecionado, testado, alterado e entregue em um empreendimento. Ele não deve ser entendido como uma pasta criada no encerramento da obra, mas como a consolidação controlada de documentos produzidos durante projeto, suprimentos, fabricação, construção, montagem, comissionamento e fechamento.

Seu conteúdo varia conforme o contrato, a disciplina e a criticidade do ativo. Em uma obra simples, pode incluir projetos finais, As-Built, certificados, relatórios de inspeção, ensaios e manuais. Em empreendimentos industriais, de energia, infraestrutura ou sistemas críticos, o Data Book pode incorporar também vendor data, folhas de dados, certificados de materiais, registros de fabricação, inspeções, testes FAT/SAT, procedimentos, registros de não conformidade, calibrações, listas de pendências, evidências de comissionamento, garantias, listas de sobressalentes, parâmetros finais e documentação para operação e manutenção.

A característica que diferencia um Data Book confiável de um simples arquivo documental é a rastreabilidade. Cada documento precisa estar relacionado ao objeto, equipamento, sistema, requisito ou etapa que pretende evidenciar; possuir identificação e revisão controladas; ter status conhecido; e permitir que outra equipe compreenda a condição entregue sem depender da memória de quem participou da obra.

Por isso, Data Book e As-Built não são sinônimos. O As-Built representa a configuração efetivamente executada da obra, instalação ou sistema. O Data Book é mais amplo: pode conter o próprio As-Built, mas também todos os registros técnicos necessários para comprovar conformidade, qualidade, testes, origem de materiais, características dos equipamentos, alterações, garantias e condições de operação.

Também não existe uma única norma universal que determine o conteúdo de qualquer Data Book. A estrutura precisa ser definida pelo contrato, pelas especificações técnicas, pelos requisitos do proprietário, pelas normas aplicáveis às disciplinas, pelos planos de inspeção e testes e pelo modelo de recebimento do empreendimento. O erro mais comum é exigir genericamente “entrega do Data Book” sem definir índice, conteúdo, responsabilidades, formatos, revisões e critérios de aceite.

Um Data Book bem planejado começa junto com a definição dos requisitos documentais. Durante a execução, documentos e evidências são classificados, revisados e vinculados aos respectivos sistemas. No comissionamento e no fechamento, o conjunto é verificado quanto à completude e coerência. No handover, a organização final deixa de ser um arquivo da obra e passa a ser uma fonte de informação para operação, manutenção, auditoria, garantia, expansão e futuras intervenções.

Em síntese, o Data Book é a memória técnica verificável do empreendimento entregue. Sua função não é apenas arquivar documentos, mas demonstrar que aquilo que foi contratado pode ser identificado, rastreado, verificado e utilizado depois da conclusão física da obra.

O que é um Data Book de obra

O termo Data Book é usado em diferentes segmentos da engenharia para designar o conjunto organizado de registros técnicos de um fornecimento, equipamento, sistema, pacote ou empreendimento. O nível de abrangência muda, mas existe um princípio comum: consolidar informação suficiente para provar a condição e a conformidade do objeto entregue.

Em uma contratação pública da Autoridade Portuária de Santos, por exemplo, o Data Book foi colocado como documento necessário para instruir a vistoria técnica de aceite da obra. A documentação prevista incluía histórico da obra, projetos, laudos de inspeção, As-Built, manual de operação e manutenção e ensaios técnicos. Esse é um bom exemplo de Data Book como instrumento de recebimento, e não apenas como arquivo administrativo.

A aplicação prática pode ocorrer em três escalas diferentes:

Escala	Objeto típico	Função do Data Book
Equipamento	painel, bomba, transformador, chiller, skid, UPS	reunir dados de fabricação, materiais, inspeções, testes, manuais e configuração final
Sistema ou pacote	elétrica, HVAC, automação, telecom, segurança, processo	consolidar documentos de vários equipamentos e demonstrar integração, testes e condição final
Empreendimento	edifício, planta industrial, subestação, data center, infraestrutura	organizar a documentação final multidisciplinar para aceite, handover e operação

Isso explica por que a expressão Vendor Data Book também é comum. Nesse caso, o foco é o dossiê técnico de um fabricante ou fornecedor. O Data Book de obra pode incorporar vários Vendor Data Books, adicionando a eles documentação de projeto, construção, integração, testes de campo e recebimento.

A existência de um anexo denominado “Documentação Data-Book da Obra” em processo público da Secretaria de Estado de Saúde do Amazonas também mostra que a expressão é utilizada formalmente em contratações de infraestrutura. O ponto importante é não concluir que existe um modelo único: cada contratante precisa especificar o conteúdo que efetivamente necessita.

Data Book, As-Built, dossiê de qualidade e manual de operação são documentos diferentes

Grande parte dos problemas de fechamento nasce da utilização desses termos como equivalentes. Eles se relacionam, mas têm funções diferentes.

Entregável	Pergunta principal	Conteúdo predominante	Relação com o Data Book
As-Built	qual é a configuração final executada?	desenhos, diagramas, modelos, listas e dados atualizados	normalmente integra o Data Book
Dossiê de qualidade	quais controles demonstram a conformidade de fabricação e execução?	certificados, inspeções, ensaios, ITP/PIT, relatórios, NCs e liberações	pode ser um volume ou seção do Data Book
Vendor Data Book	o equipamento fornecido possui documentação técnica e evidências de fabricação/teste?	desenhos, data sheets, certificados, manuais, testes e registros do fornecedor	pode ser incorporado ao Data Book do sistema/obra
Manual de operação e manutenção	como operar e manter o ativo?	procedimentos, recomendações, rotinas, limites, sobressalentes	integra ou referencia o pacote final
Pacote de comissionamento	o sistema foi verificado e testado conforme requisitos?	checklists, testes, resultados, exceções e evidências	integra o Data Book ou o handover package
Data Book	existe evidência organizada de todo o objeto entregue?	conjunto consolidado dos registros técnicos pertinentes	é o dossiê agregador

A diferença mais importante é de função documental. O As-Built mostra a condição final. Um certificado de material demonstra uma característica do item fornecido. Um relatório de inspeção registra uma verificação. Um teste funcional evidencia desempenho. Um manual orienta a operação. O Data Book cria a estrutura que relaciona essas informações ao objeto entregue.

Para aprofundar especificamente a configuração final executada, o artigo sobre Projeto As-Built em Engenharia trata de atualização, evidências e critérios de aceite do “como construído”.

Quando esses papéis não são diferenciados, o fechamento costuma produzir dois extremos: ou um pacote enorme e desorganizado, no qual encontrar uma evidência é difícil, ou um pacote muito reduzido, composto apenas por PDFs finais sem documentação suficiente para sustentar o aceite.

O Data Book deve começar antes da obra terminar

Montar todo o Data Book depois da execução é um processo de reconstrução. Documentos podem estar em e-mails, sistemas de fornecedores, pastas pessoais, plataformas de gestão, versões preliminares ou arquivos sem aprovação. Evidências de inspeções podem não estar associadas ao item correto. Certificados podem ter sido entregues em formatos diferentes. Equipamentos podem ter sido substituídos sem atualização do cadastro.

O processo mais robusto começa na contratação, quando são definidos:

1. documentos exigidos por disciplina e por fornecedor; 2. códigos e regras de identificação; 3. formatos editáveis e formatos de registro; 4. fluxos de emissão, revisão, aprovação e devolução; 5. responsabilidades pela produção e validação; 6. documentos que precisam ser capturados antes de fases irreversíveis; 7. requisitos de testes, inspeções e comissionamento; 8. estrutura do índice final; 9. critérios de completude e aceite.

A partir daí, o Data Book é construído progressivamente. Isso reduz uma falha recorrente: descobrir no encerramento que determinado relatório, certificado ou teste nunca foi produzido.

Uma forma eficiente de organizar esse processo é trabalhar com MDR — Master Document Register ou lista mestra equivalente. Cada documento esperado aparece antes da entrega final, com responsável, prazo, revisão, status e vínculo com sistema ou pacote. A Gestão de Documentos de Engenharia cria a infraestrutura de revisão, transmittal, status e rastreabilidade necessária para que o Data Book deixe de ser uma surpresa de fechamento e passe a ser o resultado de um controle contínuo.

Data Book não deve ser montado como uma pasta final de PDFs.

Índice mestre, codificação, revisões, responsáveis e rastreabilidade precisam ser definidos desde o início para que a documentação final seja controlável e auditável.

Conheça a solução de Gestão de Documentos de Engenharia

Qual deve ser a estrutura de um Data Book

Não existe um índice universal, mas uma estrutura consistente precisa permitir que o usuário navegue do nível mais amplo para a evidência específica. A organização deve refletir a EAP, sistemas, disciplinas, equipamentos ou pacotes de contratação do empreendimento.

Uma arquitetura genérica pode conter:

Volume/seção	Conteúdo típico
00 — Índice e controle	índice mestre, lista de volumes, matriz de documentos, status e revisões
01 — Requisitos e projeto	especificações, memoriais, desenhos aprovados, critérios de projeto e revisões aplicáveis
02 — Suprimentos e vendor data	data sheets, desenhos de fabricante, listas, certificados, manuais e documentação de equipamentos
03 — Qualidade e materiais	certificados de materiais, rastreabilidade, procedimentos, inspeções, ENDs e registros de qualidade
04 — Construção e montagem	registros de execução, levantamentos, liberações, medições e evidências de instalação
05 — Testes e comissionamento	checklists, FAT, SAT, testes funcionais, integrados, calibrações e resultados finais
06 — Mudanças e não conformidades	RFIs, field changes, NCs, desvios, aprovações e registros de mudança
07 — As-Built	desenhos, diagramas, listas, modelos e dados finais da configuração executada
08 — Operação e manutenção	manuais, procedimentos, parâmetros, sobressalentes, recomendações e treinamento
09 — Garantias e certificados finais	garantias, termos, certificados regulatórios e documentação de fechamento
10 — Recebimento	Punch List final, termos de aceite, pendências remanescentes e evidências de encerramento

Essa estrutura deve ser adaptada. Uma obra civil possui registros diferentes de um sistema elétrico ou de automação. Em um empreendimento multidisciplinar, pode ser mais eficiente criar volumes por sistema e repetir internamente uma mesma lógica de documentação.

Organização por sistema pode ser melhor do que organização por tipo de arquivo

Uma pasta única de “certificados”, outra de “desenhos” e outra de “testes” pode funcionar em um projeto pequeno, mas tende a dificultar a operação de um ativo complexo. Para investigar um equipamento específico, o usuário precisa navegar por várias estruturas desconectadas.

Uma alternativa é organizar por sistema ou tag:

Sistema → equipamento/ativo → documentos de projeto → fabricação → instalação → testes → As-Built → O&M → garantia.

O critério deve ser escolhido com base no uso futuro. Se manutenção e operação trabalham por sistema e ativo, a estrutura final deve facilitar essa mesma lógica.

Quais documentos podem compor o Data Book

A lista exata deve vir do contrato. Ainda assim, existem famílias documentais recorrentes que ajudam a estruturar requisitos.

Documentos de engenharia e projeto

Podem incluir memoriais, especificações, critérios de projeto, desenhos gerais, detalhes, diagramas, listas, folhas de dados, cálculos relevantes, documentos de interface e revisões finais. No fechamento, apenas documentos com status adequado devem ser tratados como referência final.

Projetos preliminares, desenhos superados ou arquivos de trabalho podem ter valor histórico, mas não devem concorrer visualmente com a documentação aceita. Se forem preservados, precisam estar claramente classificados.

Documentação de fornecedores e equipamentos

Para equipamentos e sistemas adquiridos, o Data Book pode reunir:

folha de dados final;
desenho dimensional e de arranjo;
diagramas elétricos, pneumáticos ou de instrumentação;
lista de componentes;
certificados de materiais;
certificados de calibração;
curvas e dados de desempenho;
relatórios de inspeção;
testes de fábrica;
certificados de conformidade;
manual de instalação;
manual de operação e manutenção;
lista de sobressalentes;
garantias;
backups, parâmetros ou arquivos de configuração quando aplicável.

O ponto crítico é a correspondência entre documentação e item fornecido. Um manual genérico de família não necessariamente representa a configuração instalada. O Data Book precisa identificar modelo, tag, série, versão, firmware ou outra característica necessária para eliminar ambiguidade.

Registros de qualidade e inspeção

Dependendo do escopo, podem existir planos de inspeção e testes, procedimentos, liberações, inspeções de recebimento, ENDs, certificados de soldadores, certificados de materiais, registros de torque, testes de pressão, inspeções visuais, relatórios dimensionais e outros documentos.

Esses registros demonstram como a conformidade foi verificada ao longo da fabricação e execução. A ausência não pode ser compensada simplesmente por um desenho As-Built correto: desenho e evidência de qualidade cumprem funções diferentes.

Registros de construção e montagem

Incluem levantamentos de campo, registros de instalação, relatórios diários quando requeridos, medições, liberações de frentes, registros de elementos ocultos e demais documentos que ajudam a reconstruir a condição executada.

Para redes enterradas, infraestruturas embutidas ou componentes que ficarão inacessíveis, a evidência precisa ser produzida no momento correto. Fotografias sem localização, escala ou identificação podem ser insuficientes anos depois.

Testes, ensaios e comissionamento

O Data Book deve preservar a evidência dos testes que sustentam a aceitação. Isso pode incluir:

inspeções pré-funcionais;
testes de continuidade, isolação ou resistência;
certificação de enlaces de telecomunicações;
calibração de instrumentos;
testes de estanqueidade e pressão;
balanceamento e medições de HVAC;
testes funcionais;
FAT e SAT;
testes integrados;
resultados de desempenho;
listas de exceções;
retestes após correções.

O resultado “aprovado” precisa ser rastreável ao procedimento, instrumento, equipamento, data e responsável aplicáveis quando isso for requisito do sistema. O artigo sobre Comissionamento em Engenharia aprofunda justamente a formação dessas evidências ao longo da verificação e dos testes.

Mudanças, RFIs e não conformidades

Um Data Book que contém apenas o estado final pode não explicar por que uma configuração difere do projeto originalmente aprovado. Para itens relevantes, a documentação final deve manter rastreabilidade com decisões de campo, RFIs, registros de mudança, não conformidades e aprovações associadas.

Essa relação não significa colocar toda a correspondência administrativa dentro do Data Book. Significa preservar os registros que sustentam tecnicamente a condição final. O processo de Engineering Change Management (ECM) ajuda a separar alteração informal de mudança tecnicamente analisada, aprovada e incorporada à baseline.

Documentação As-Built

O As-Built é uma das partes centrais do fechamento. Desenhos, diagramas, modelos, listas de ativos, identificação de circuitos, rotas, dados de configuração e demais informações finais precisam corresponder à instalação efetivamente entregue.

A rastreabilidade deve conectar alterações, evidências de campo e revisão final. Um desenho simplesmente renomeado como “As-Built” não prova que houve verificação.

Operação, manutenção e garantias

O Data Book precisa permitir a transferência do ativo para quem irá operá-lo. Dependendo do empreendimento, isso inclui manuais, procedimentos, parâmetros, rotinas de manutenção, consumíveis, sobressalentes, certificados, garantias, contatos de fabricantes e limitações operacionais.

Essa camada é especialmente relevante quando a equipe de operação não participou da construção. A documentação deve ser suficiente para iniciar operação e manutenção sem depender de conhecimento informal da equipe de implantação.

Data Book por disciplina: o conteúdo muda

Um erro de contratação é exigir o mesmo checklist documental para todas as disciplinas. A estrutura macro pode ser comum, mas as evidências precisam refletir o objeto.

Disciplina	Exemplos de documentos/evidências
Civil/estrutural	projetos finais, controle tecnológico, concretagem, topografia, inspeções, materiais, As-Built
Mecânica/processo	data sheets, certificados, soldagem, END, testes hidrostáticos, alinhamento, flushing, manuais
Elétrica	diagramas, listas de cabos, painéis, proteções, ensaios, ajustes, termografia quando exigida, comissionamento
Instrumentação	lista de instrumentos, calibrações, loop checks, datasheets, range, setpoints, certificados
Automação	arquitetura, I/O, backups, versões de software, lógica, telas, parâmetros, testes funcionais
Telecom	diagramas, racks, fibras, enlaces, certificações, OTDR/OLTS quando aplicável, inventário
Segurança eletrônica	plantas, diagramas, inventário, configurações, endereçamento, backups, testes, matrizes funcionais
HVAC	equipamentos, curvas, TAB, controles, parâmetros, testes, manuais e comissionamento
Incêndio	dispositivos, laços, programação, cause & effect, ensaios, testes integrados e certificados aplicáveis

Isso reforça a necessidade de uma Document Requirement List específica. A lista define o que cada pacote precisa entregar e impede que o Data Book vire um checklist genérico copiado de outro empreendimento.

Vendor Data Book: como controlar documentação de fornecedores

Equipamentos comprados normalmente chegam com documentação produzida fora do fluxo principal do projeto. Sem governança, surgem arquivos com nomenclaturas próprias, revisões incompatíveis, desenhos sem aprovação ou manuais sem correspondência com o item instalado.

O Vendor Data Book precisa ser controlado desde o procurement. Ainda na requisição ou pedido de compra, o contratante deveria definir:

Requisito	Exemplo
Lista documental	desenho GA, data sheet, manual, certificados, testes
Prazo	documentos para aprovação antes da fabricação e documentos finais antes do embarque/aceite
Revisão	codificação e status esperados
Formato	PDF, DWG, XLSX, arquivos nativos, backups
Idioma	requisito contratual
Identificação	tag, modelo, série, pedido, fabricante
Aprovação	responsável técnico e fluxo de comentários
Final Data Book	índice e organização do pacote final

Isso evita um problema frequente: tentar exigir documentos importantes depois que o equipamento já foi fabricado, entregue ou comissionado.

O Data Book também não deve ser confundido com aprovação de engenharia. Receber um documento não significa aprová-lo; aprovar um desenho de fornecedor não significa aceitar o equipamento; aceitar o equipamento não significa concluir o sistema. Os status precisam ser preservados.

Data Book e comissionamento precisam conversar

O comissionamento produz parte das evidências mais importantes do fechamento. Cada sistema deveria possuir uma relação clara entre requisitos, equipamentos, checklists, testes e resultados.

Um processo maduro pode usar uma matriz como:

Requisito → sistema → tag/ativo → procedimento → teste → resultado → pendência → reteste → documento final.

Essa estrutura torna o Data Book utilizável para auditoria e troubleshooting. Se um equipamento apresentar falha futura, é possível recuperar qual teste foi executado, quais parâmetros estavam configurados e se existiam exceções no aceite.

O pacote de comissionamento pode ser fisicamente separado do Data Book, especialmente em empreendimentos grandes. Mesmo assim, o índice final precisa indicar onde cada evidência está armazenada e qual documento possui status de registro permanente.

FAT e SAT também precisam ser tratados corretamente. O teste de fábrica comprova determinado desempenho ou condição antes do envio; o teste em campo comprova condições após instalação e integração. Um não substitui automaticamente o outro.

Data Book, Punch List e critérios de aceite

A entrega do Data Book é parte do encerramento técnico, mas o recebimento não deve ser automático. O contratante precisa verificar se o pacote está completo, coerente e relacionado à condição física aceita.

Uma estratégia de aceite pode separar:

1. completude documental — todos os documentos previstos estão presentes; 2. correção formal — codificação, revisão, títulos e status estão corretos; 3. coerência técnica — documentos não se contradizem; 4. correspondência física — As-Built e registros representam o executado; 5. rastreabilidade — alterações e evidências possuem origem conhecida; 6. testes e comissionamento — resultados necessários estão completos e aprovados; 7. pendências — itens de Punch List estão encerrados ou formalmente classificados; 8. utilidade operacional — o pacote permite operar, manter e localizar informações do ativo.

A Autoridade Portuária de Santos fornece um exemplo claro da conexão entre Data Book e aceite: no modelo contratual consultado, a entrega do Data Book é o gatilho para a realização da vistoria técnica destinada ao aceite da obra.

A consequência é importante: documentação não é atividade administrativa posterior à entrega; pode ser requisito para caracterizar a própria entrega.

Quando houver pendências, a Punch List em Engenharia deve tratar também itens documentais, e não apenas correções físicas de campo.

Como montar uma matriz de rastreabilidade do Data Book

A lista de arquivos, sozinha, informa que algo foi recebido. Uma matriz de rastreabilidade mostra por que aquele documento existe e a que ele se relaciona.

Campo	Exemplo de uso
ID do documento	código único
Título	descrição controlada
Disciplina/sistema	elétrica, HVAC, automação etc.
Tag/ativo	equipamento ou conjunto associado
Requisito	especificação, contrato, norma ou ITP que exige o registro
Fornecedor/responsável	origem do documento
Revisão	revisão atual
Status	para aprovação, aprovado, final, As-Built etc.
Evidência associada	teste, certificado, relatório, mudança
Pendência	item aberto que impede fechamento
Localização	volume/pasta/CDE
Aceite	responsável e data

Esse modelo também reduz problemas com documentos duplicados. Um único registro mestre identifica qual revisão é válida, enquanto versões antigas podem ser mantidas em histórico sem aparecer como concorrentes no pacote final.

Handover digital exige informação utilizável, não apenas arquivos armazenados.

O Data Book deve preservar a evidência formal da entrega e, quando aplicável, conectar documentos, modelos, ativos, metadados e registros de operação em um ambiente controlado.

Conheça o serviço de Gestão BIM e Informação de Engenharia

Data Book digital, CDE e gestão da informação

A digitalização do Data Book não deve se limitar a converter papel em PDF. Um Data Book digital precisa melhorar busca, rastreabilidade, controle de revisão e reutilização da informação.

No Brasil, a ABNT NBR ISO 19650-2:2022, em sua Versão Corrigida 2 de 2025, estrutura a gestão da informação durante a fase de entrega de ativos, incluindo requisitos de informação, CDE, produção colaborativa, revisão, aceitação do modelo de informação e encerramento do empreendimento. A ABNT NBR ISO 19650-3:2025 estende essa governança à fase operacional, tratando da manutenção do modelo de informação do ativo e da continuidade das informações necessárias à gestão do ativo.

A ABNT NBR ISO 19650-4:2025 complementa essa lógica ao detalhar critérios para trocas de informação, incluindo conformidade, continuidade, consistência e completude. Nenhuma dessas normas define um “Data Book” universal; sua contribuição é oferecer uma estrutura de governança para que a informação entregue seja identificável, controlada, revisável e utilizável na transição entre projeto, entrega e operação.

Em ambientes BIM, o handover pode conectar documentos a objetos, sistemas e ativos. O PIM — Project Information Model — e o AIM — Asset Information Model ajudam a compreender essa transição. O Data Book tradicional e esse fluxo digital não são excludentes: o primeiro pode funcionar como pacote formal de evidências, enquanto o modelo de informação permite acesso e uso estruturado desses dados durante a operação.

Um CDE — Common Data Environment — também reduz a necessidade de “montagem artesanal” no encerramento, porque versões, aprovações, transmittals e metadados já foram governados durante o projeto. O fechamento passa a ser um processo de seleção e validação do estado final, não de busca por documentos perdidos.

Para dados estruturados de ativos, COBie é outro exemplo de como informações de equipamentos, espaços e manutenção podem ser organizadas para o handover sem substituir os documentos formais do Data Book.

PDF continua importante, mas arquivo nativo também pode ser necessário

O PDF possui valor como registro estável, porém não substitui todos os formatos editáveis. Dependendo do uso futuro, o contrato pode exigir DWG, IFC, XLSX, arquivos de configuração, backups de controladores, bases de dados, arquivos de programação ou outros formatos nativos.

A Autoridade Portuária de Santos, no exemplo citado, exigiu especificamente DWG e PDF. Esse tipo de definição contratual elimina ambiguidades sobre o formato final.

A regra deve ser: formato de registro para preservar evidência + formato utilizável para operação, manutenção e futuras alterações, quando necessário.

Quem é responsável pelo Data Book

O fechamento documental é multidisciplinar e não deve ficar concentrado em uma única pessoa apenas no final. É útil separar responsabilidades.

Papel	Responsabilidade típica
Contratante/proprietário	definir requisitos, formatos e critérios de aceite
Projetista	emitir documentos de engenharia finais sob sua responsabilidade
Fornecedor	produzir vendor data e evidências do fornecimento
Construtora/instaladora	manter registros de execução e alterações de campo
Qualidade	controlar inspeções, ensaios, certificados e não conformidades
Comissionamento	consolidar checklists, testes, exceções e retestes
Document Control	governar codificação, revisões, transmittals, status e estrutura documental
Owner’s Engineering/fiscalização	verificar completude, coerência e correspondência com critérios de aceite
Operação/manutenção	validar se a informação recebida é utilizável na fase operacional

A matriz real depende do contrato. O ponto crítico é evitar que a responsabilidade fique implícita. Se ninguém for responsável por integrar documentos de fornecedores, As-Built e testes, o resultado final será fragmentado mesmo que cada participante tenha cumprido sua parte isoladamente.

Como especificar Data Book em contrato ou Termo de Referência

A frase “a contratada deverá entregar Data Book ao final” é insuficiente. Uma especificação tecnicamente útil precisa indicar o conteúdo e o mecanismo de controle.

Como referência externa de aplicação contratual, a Autoridade Portuária de Santos vinculou expressamente a entrega do Data Book à vistoria técnica de aceite, exigindo histórico da obra, projetos, laudos de inspeção, As-Built, manual de operação e manutenção e ensaios técnicos.

Requisito contratual	O que definir
Escopo	quais sistemas, áreas, pacotes e equipamentos entram
Índice mínimo	estrutura de volumes/seções
Document Requirement List	quais documentos cada disciplina/fornecedor entrega
Codificação	padrão para documentos e revisões
Status	aprovação, final, As-Built, registro etc.
Formatos	PDF, DWG, IFC, planilhas, nativos, backups
Metadados	tag, disciplina, sistema, fornecedor, revisão
Submissões parciais	quando cada pacote deve ser entregue
Revisão e comentários	fluxo de análise e prazo de correção
Evidências	quais certificados, inspeções e testes são obrigatórios
As-Built	critérios de atualização e validação
Comissionamento	documentos permanentes do pacote de testes
Pendências	regra para documentos vinculados à Punch List
Organização	diretórios, CDE, volumes, índice e hiperlinks
Aceite	checklist, amostragem, critérios de rejeição e aprovação
Handover	forma de transferência para operação e manutenção

Em contratos complexos, também é recomendável atrelar o fechamento documental aos marcos de medição. Se 100% do pagamento for alcançado antes da consolidação dos documentos finais, o contratante perde um importante mecanismo de incentivo ao encerramento adequado.

Da mesma forma, não é eficiente reter todo o controle para o final. Aprovar parcialmente vendor data, registros de qualidade e pacotes de sistema ao longo da execução reduz o volume de correções tardias.

Recebimento documental exige evidência de completude e correspondência com a obra.

A auditoria deve verificar documentos previstos, revisões, assinaturas, testes, pendências, As-Built e condições necessárias para que a operação receba informação confiável.

Conheça o serviço de Recebimento Técnico de Obras e Serviços de Engenharia

Como auditar um Data Book antes do recebimento

A auditoria pode ser dividida em níveis.

Nível 1 — Existência

Todos os itens previstos na Document Requirement List foram entregues? Existem lacunas, arquivos corrompidos ou referências para documentos ausentes?

Nível 2 — Controle documental

Os códigos, revisões, status, datas e títulos são coerentes? O índice aponta para a revisão correta? Existem versões concorrentes apresentadas como finais?

Nível 3 — Conteúdo técnico

O documento corresponde ao equipamento, sistema ou área correta? Certificados e manuais representam o item realmente instalado? Resultados de testes possuem identificação suficiente?

Nível 4 — Correspondência com campo

O As-Built e os registros críticos correspondem à condição física? Tags, rotas, equipamentos e configurações estão coerentes com a instalação?

Nível 5 — Rastreabilidade

As alterações relevantes possuem origem? Não conformidades estão encerradas? Retestes confirmam as correções? Os documentos finais incorporam as decisões tomadas?

Nível 6 — Prontidão operacional

A equipe de operação consegue usar o Data Book? Existe documentação suficiente para manutenção, troubleshooting, garantia, reposição e futuras modificações?

Essa última verificação é importante porque um pacote pode estar formalmente completo e ainda ser pouco útil. O objetivo do handover não é apenas transferir arquivos; é transferir informação utilizável.

Erros comuns na elaboração do Data Book

Erro	Consequência	Correção
começar somente no fim	documentos perdidos e lacunas impossíveis de recompor	manter MDR e submissões progressivas
não definir índice no contrato	cada fornecedor entrega estrutura diferente	emitir template e Document Requirement List
aceitar qualquer revisão disponível	referência final ambígua	controlar status e revisão mestre
inserir documentos genéricos	manual/certificado pode não representar o instalado	vincular documento a tag, modelo e série
separar As-Built das mudanças	condição final sem histórico técnico	manter rastreabilidade das alterações relevantes
arquivar testes sem identificação	resultado não pode ser associado ao sistema	registrar procedimento, tag, data e responsável
duplicar arquivos em várias pastas	dúvida sobre qual versão é válida	adotar fonte da verdade e referências controladas
entregar apenas PDF quando nativos são necessários	operação e futuras alterações ficam limitadas	especificar formatos úteis desde a contratação
considerar Punch List apenas física	pendências documentais ficam abertas	classificar pendências físicas, funcionais e documentais
confundir entrega com aceite	pacote pode estar incompleto ou incorreto	aplicar checklist e critérios formais de recebimento

Data Book como ponte entre obra e operação

O maior valor do Data Book aparece depois que a equipe de implantação deixa o empreendimento. A operação precisa localizar rapidamente documentação de equipamentos, confirmar parâmetros, verificar garantia, entender modificações, planejar manutenção e preparar futuras intervenções.

Quando o Data Book foi construído apenas para cumprir um item contratual, essa informação tende a permanecer isolada em pastas. Quando foi estruturado para o ciclo de vida do ativo, ele pode alimentar GED/EDMS, CDE, CMMS, EAM, modelos BIM, cadastro patrimonial e demais plataformas operacionais.

A transição deve preservar a fonte da verdade. O documento final aprovado precisa continuar identificável mesmo que seja migrado para outro sistema. Links entre ativo, documento, revisão, teste e garantia não deveriam se perder no handover.

Esse é também o ponto em que Data Book e gestão de ativos se encontram. O empreendimento deixa de ser tratado como “obra” e passa a ser tratado como “ativo em operação”. A documentação final é a ponte entre essas duas condições. O Guia Completo de As-Built em Engenharia amplia essa visão para documentação, validação, Data Book, handover e ciclo de vida.

Data Book não encerra a engenharia sozinho

Mesmo um Data Book completo não substitui a verificação da condição física. O fechamento técnico depende da convergência entre execução, As-Built, testes, comissionamento, correção de pendências, documentação e aceite.

Um fluxo consistente é:

requisitos documentais → projeto e procurement → fabricação → construção/montagem → inspeções → testes → mudanças → As-Built → comissionamento → Punch List → consolidação do Data Book → auditoria documental → recebimento técnico → handover → operação.

Se a condição física ainda possui pendências impeditivas, o Data Book não torna a obra pronta. Se o sistema funciona mas a documentação está incompleta, a conclusão física também não representa um encerramento técnico adequado.

A lógica mais robusta é considerar que obra, sistema e informação precisam chegar juntos ao estado de aceite. É isso que transforma o Data Book de simples arquivo de fechamento em instrumento de governança técnica e continuidade do ativo.

Referências técnicas

[1] AUTORIDADE PORTUÁRIA DE SANTOS. Consulta referente a edital de chamamento público para construção de berço público na região da Alamoa — cláusulas de entrega do Data Book, documentação final, vistoria e aceite. Governo Federal, Participa + Brasil, 2023.

[2] SECRETARIA DE ESTADO DE SAÚDE DO AMAZONAS. Chamamento Público nº 001/2024 — Anexo II: Documentação Data-Book da Obra. SES-AM, 2024.

[3] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-2:2022 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 2: Fase de entrega de ativos. Versão Corrigida 2: 2025.

[4] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-3:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 3: Fase operacional dos ativos.

[5] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR ISO 19650-4:2025 — Organização e digitização da informação sobre edifícios e obras de engenharia civil, incluindo BIM — Gestão da informação usando modelagem da informação da construção — Parte 4: Troca de informação.

[6] TRIBUNAL DE CONTAS DA UNIÃO. Acórdão 3112/2014 — Plenário. Referências a As-Built e Data Book como documentação de engenharia em empreendimento. Brasília: TCU, 2014.

Perguntas frequentes

O que é Data Book de obra?

É o dossiê técnico estruturado que reúne documentos e evidências do que foi projetado, fornecido, executado, inspecionado, testado, alterado e entregue. Pode incluir projetos, vendor data, certificados, inspeções, testes, As-Built, manuais, garantias e registros de comissionamento.

Data Book e As-Built são a mesma coisa?

Não. O As-Built representa a configuração final efetivamente executada. O Data Book é mais amplo e normalmente incorpora o As-Built juntamente com documentação de fornecedores, qualidade, inspeções, testes, comissionamento, manuais, garantias e demais registros requeridos.

Existe uma norma específica para Data Book de obra?

Não existe uma única norma universal que defina o conteúdo de todo Data Book. O conteúdo deve ser estabelecido pelo contrato, especificações, requisitos do proprietário, normas das disciplinas, planos de inspeção e testes e critérios de recebimento.

Quando o Data Book deve começar a ser montado?

Desde a definição dos requisitos documentais e do procurement. A organização deve ocorrer progressivamente durante projeto, fabricação, construção, testes e comissionamento, evitando tentar reconstruir todo o histórico somente no encerramento.

O que é Vendor Data Book?

É o dossiê técnico de um fornecedor ou equipamento, reunindo documentos como data sheets, desenhos, certificados, inspeções, testes, manuais, garantias e demais registros do fornecimento. Vários Vendor Data Books podem integrar o Data Book geral da obra.

Quais documentos devem constar em um Data Book?

Depende do escopo. Entre os mais comuns estão projetos finais, As-Built, memoriais, folhas de dados, documentação de fornecedores, certificados de materiais, inspeções, ensaios, FAT/SAT, comissionamento, registros de mudanças, manuais, garantias, listas de sobressalentes e documentos de recebimento.

Data Book pode ser entregue apenas em PDF?

Somente se o contrato e o uso futuro permitirem. O PDF é adequado como registro estável, mas DWG, IFC, planilhas, backups, arquivos de configuração e outros formatos nativos podem ser necessários para operação, manutenção e futuras alterações.

Como verificar um Data Book antes do aceite?

A verificação deve avaliar completude, codificação, revisões, coerência técnica, correspondência com o campo, rastreabilidade das mudanças, testes, encerramento de pendências e utilidade da informação para operação e manutenção.

Qual a relação entre Data Book e comissionamento?

O comissionamento gera evidências de verificação e testes que normalmente integram ou são referenciadas pelo Data Book. Checklists, resultados, exceções, retestes, FAT/SAT e testes integrados ajudam a demonstrar que a condição final foi verificada antes do handover.

Qual a relação entre Data Book e handover?

O Data Book é um dos principais instrumentos de transferência da informação técnica da fase de implantação para operação. No handover, a documentação final precisa deixar de ser apenas arquivo da obra e tornar-se informação utilizável para manutenção, garantia, auditoria e futuras intervenções.

Materiais técnicos complementares

Fechamento técnico e documentação final

Gestão da informação, BIM e handover

Soluções de governança e rastreabilidade

Serviços relacionados

Guias e whitepapers