Entienda qué es un Data Book de obra, qué documentos debe contener, cómo estructurar vendor data, documentación As-Built, pruebas y comisionamiento, y qué criterios aplicar para la aceptación.
¡Descúbrelo!
El Data Book de obra es el expediente técnico estructurado que reúne las evidencias necesarias para demostrar lo que fue diseñado, suministrado, ejecutado, inspeccionado, ensayado, modificado y entregado en un proyecto. No debe entenderse como una carpeta creada al cierre de la obra, sino como la consolidación controlada de documentos producidos durante el diseño, los suministros, la fabricación, la construcción, el montaje, el comisionamiento y el cierre.
Su contenido varía según el contrato, la disciplina y la criticidad del activo. En una obra sencilla, puede incluir proyectos finales, documentación As-Built, certificados, informes de inspección, ensayos y manuales. En proyectos industriales, de energía, infraestructura o sistemas críticos, el Data Book puede incorporar también vendor data, hojas de datos, certificados de materiales, registros de fabricación, inspecciones, pruebas FAT/SAT, procedimientos, registros de no conformidad, calibraciones, listas de pendientes, evidencias de comisionamiento, garantías, listas de repuestos, parámetros finales y documentación para operación y mantenimiento.
La característica que diferencia un Data Book confiable de un simple archivo documental es la trazabilidad. Cada documento debe estar relacionado con el objeto, equipo, sistema, requisito o etapa que pretende evidenciar; tener identificación y revisión controladas; contar con un estado conocido; y permitir que otro equipo comprenda la condición entregada sin depender de la memoria de quienes participaron en la obra.
Por ello, Data Book y As-Built no son sinónimos. El As-Built representa la configuración efectivamente ejecutada de la obra, instalación o sistema. El Data Book es más amplio: puede contener el propio As-Built, pero también todos los registros técnicos necesarios para demostrar conformidad, calidad, pruebas, origen de materiales, características de los equipos, modificaciones, garantías y condiciones de operación.
Tampoco existe una única norma universal que determine el contenido de cualquier Data Book. La estructura debe definirse por el contrato, las especificaciones técnicas, los requisitos del propietario, las normas aplicables a las disciplinas, los planes de inspección y pruebas y el modelo de recepción del proyecto. El error más común es exigir genéricamente la “entrega del Data Book” sin definir índice, contenido, responsabilidades, formatos, revisiones y criterios de aceptación.
Un Data Book bien planificado comienza junto con la definición de los requisitos documentales. Durante la ejecución, los documentos y las evidencias se clasifican, revisan y vinculan a los sistemas correspondientes. En el comisionamiento y el cierre, el conjunto se verifica en cuanto a completitud y coherencia. En el handover, la organización final deja de ser un archivo de la obra y pasa a ser una fuente de información para operación, mantenimiento, auditoría, garantía, ampliaciones e intervenciones futuras.
En síntesis, el Data Book es la memoria técnica verificable del proyecto entregado. Su función no es solamente archivar documentos, sino demostrar que aquello que fue contratado puede identificarse, rastrearse, verificarse y utilizarse después de la conclusión física de la obra.
Qué es un Data Book de obra
El término Data Book se utiliza en diferentes sectores de la ingeniería para designar el conjunto organizado de registros técnicos de un suministro, equipo, sistema, paquete o proyecto. El alcance cambia, pero existe un principio común: consolidar información suficiente para demostrar la condición y la conformidad del objeto entregado.
En una contratación pública de la Autoridad Portuaria de Santos, por ejemplo, el Data Book fue establecido como documento necesario para respaldar la inspección técnica de aceptación de la obra. La documentación prevista incluía el historial de la obra, proyectos, informes de inspección, As-Built, manual de operación y mantenimiento y ensayos técnicos. Es un buen ejemplo del Data Book como instrumento de recepción, y no solamente como archivo administrativo.
La aplicación práctica puede darse en tres escalas diferentes:
| Escala | Objeto típico | Función del Data Book |
| Equipo | panel, bomba, transformador, chiller, skid, UPS | reunir datos de fabricación, materiales, inspecciones, pruebas, manuales y configuración final |
| Sistema o paquete | eléctrica, HVAC, automatización, telecomunicaciones, seguridad, proceso | consolidar documentos de varios equipos y demostrar integración, pruebas y condición final |
| Proyecto | edificio, planta industrial, subestación, data center, infraestructura | organizar la documentación final multidisciplinaria para aceptación, handover y operación |
Esto explica por qué la expresión Vendor Data Book también es común. En este caso, el foco es el expediente técnico de un fabricante o proveedor. El Data Book de obra puede incorporar varios Vendor Data Books, añadiendo documentación de diseño, construcción, integración, pruebas de campo y recepción.
La existencia de un anexo denominado “Documentación Data-Book de la Obra” en un proceso público de la Secretaría de Estado de Salud de Amazonas también muestra que la expresión se utiliza formalmente en contrataciones de infraestructura. Lo importante es no concluir que existe un modelo único: cada contratante debe especificar el contenido que realmente necesita.
Data Book, As-Built, dossier de calidad y manual de operación son documentos diferentes
Gran parte de los problemas de cierre nace de utilizar estos términos como equivalentes. Están relacionados, pero cumplen funciones diferentes.
| Entregable | Pregunta principal | Contenido predominante | Relación con el Data Book |
| As-Built | ¿cuál es la configuración final ejecutada? | planos, diagramas, modelos, listas y datos actualizados | normalmente integra el Data Book |
| Dossier de calidad | ¿qué controles demuestran la conformidad de fabricación y ejecución? | certificados, inspecciones, ensayos, ITP/PIT, informes, NC y liberaciones | puede ser un volumen o sección del Data Book |
| Vendor Data Book | ¿el equipo suministrado dispone de documentación técnica y evidencias de fabricación/pruebas? | planos, data sheets, certificados, manuales, pruebas y registros del proveedor | puede incorporarse al Data Book del sistema/obra |
| Manual de operación y mantenimiento | ¿cómo operar y mantener el activo? | procedimientos, recomendaciones, rutinas, límites, repuestos | integra o referencia el paquete final |
| Paquete de comisionamiento | ¿el sistema fue verificado y probado conforme a los requisitos? | checklists, pruebas, resultados, excepciones y evidencias | integra el Data Book o el handover package |
| Data Book | ¿existe evidencia organizada de todo el objeto entregado? | conjunto consolidado de los registros técnicos pertinentes | es el dossier integrador |
La diferencia más importante es de función documental. El As-Built muestra la condición final. Un certificado de material demuestra una característica del ítem suministrado. Un informe de inspección registra una verificación. Una prueba funcional evidencia desempeño. Un manual orienta la operación. El Data Book crea la estructura que relaciona estas informaciones con el objeto entregado.
Para profundizar específicamente en la configuración final ejecutada, el artículo sobre Proyecto As-Built en Ingeniería aborda actualización, evidencias y criterios de aceptación de lo “construido”.
Cuando estos papeles no se diferencian, el cierre suele producir dos extremos: un paquete enorme y desorganizado, en el que encontrar una evidencia es difícil, o un paquete demasiado reducido, compuesto solamente por PDFs finales sin documentación suficiente para respaldar la aceptación.
El Data Book debe comenzar antes de que termine la obra
Montar todo el Data Book después de la ejecución es un proceso de reconstrucción. Los documentos pueden estar dispersos en correos electrónicos, sistemas de proveedores, carpetas personales, plataformas de gestión, versiones preliminares o archivos sin aprobación. Las evidencias de inspección pueden no estar asociadas al ítem correcto. Los certificados pueden haber sido entregados en formatos diferentes. Los equipos pueden haber sido sustituidos sin actualizar el registro.
El proceso más robusto comienza en la contratación, cuando se definen:
- documentos exigidos por disciplina y por proveedor;
- códigos y reglas de identificación;
- formatos editables y formatos de registro;
- flujos de emisión, revisión, aprobación y devolución;
- responsabilidades por la producción y validación;
- documentos que deben capturarse antes de fases irreversibles;
- requisitos de pruebas, inspecciones y comisionamiento;
- estructura del índice final;
- criterios de completitud y aceptación.
A partir de ahí, el Data Book se construye progresivamente. Esto reduce una falla recurrente: descubrir al cierre que determinado informe, certificado o prueba nunca fue producido.
Una forma eficiente de organizar este proceso es trabajar con un MDR — Master Document Register o una lista maestra equivalente. Cada documento esperado aparece antes de la entrega final, con responsable, plazo, revisión, estado y vínculo con el sistema o paquete. La Gestión de Documentos de Ingeniería crea la infraestructura de revisión, transmittal, estado y trazabilidad necesaria para que el Data Book deje de ser una sorpresa de cierre y pase a ser el resultado de un control continuo.
El Data Book no debe montarse como una carpeta final de PDFs.
Índice maestro, codificación, revisiones, responsables y trazabilidad deben definirse desde el inicio para que la documentación final sea controlable y auditable.
La Gestión de Documentos de Ingeniería estructura MDR, revisiones, transmittals, estados y trazabilidad para que el Data Book se construya progresivamente durante el proyecto.
Cuál debe ser la estructura de un Data Book
No existe un índice universal, pero una estructura consistente debe permitir que el usuario navegue desde el nivel más amplio hasta la evidencia específica. La organización debe reflejar la EDT, los sistemas, las disciplinas, los equipos o los paquetes de contratación del proyecto.
Una arquitectura genérica puede contener:
| Volumen/sección | Contenido típico |
| 00 — Índice y control | índice maestro, lista de volúmenes, matriz de documentos, estado y revisiones |
| 01 — Requisitos y diseño | especificaciones, memorias, planos aprobados, criterios de diseño y revisiones aplicables |
| 02 — Suministros y vendor data | data sheets, planos del fabricante, listas, certificados, manuales y documentación de equipos |
| 03 — Calidad y materiales | certificados de materiales, trazabilidad, procedimientos, inspecciones, END y registros de calidad |
| 04 — Construcción y montaje | registros de ejecución, levantamientos, liberaciones, mediciones y evidencias de instalación |
| 05 — Pruebas y comisionamiento | checklists, FAT, SAT, pruebas funcionales e integradas, calibraciones y resultados finales |
| 06 — Cambios y no conformidades | RFIs, field changes, NC, desvíos, aprobaciones y registros de cambios |
| 07 — As-Built | planos, diagramas, listas, modelos y datos finales de la configuración ejecutada |
| 08 — Operación y mantenimiento | manuales, procedimientos, parámetros, repuestos, recomendaciones y capacitación |
| 09 — Garantías y certificados finales | garantías, términos, certificados regulatorios y documentación de cierre |
| 10 — Recepción | Punch List final, términos de aceptación, pendientes remanentes y evidencias de cierre |
Esta estructura debe adaptarse. Una obra civil tiene registros diferentes de un sistema eléctrico o de automatización. En un proyecto multidisciplinario, puede ser más eficiente crear volúmenes por sistema y repetir internamente una misma lógica documental.
La organización por sistema puede ser mejor que la organización por tipo de archivo
Una carpeta única de “certificados”, otra de “planos” y otra de “pruebas” puede funcionar en un proyecto pequeño, pero tiende a dificultar la operación de un activo complejo. Para investigar un equipo específico, el usuario necesita navegar por varias estructuras desconectadas.
Una alternativa es organizar por sistema o tag:
Sistema → equipo/activo → documentos de diseño → fabricación → instalación → pruebas → As-Built → O&M → garantía.
El criterio debe elegirse con base en el uso futuro. Si mantenimiento y operación trabajan por sistema y activo, la estructura final debe facilitar esa misma lógica.
Qué documentos pueden componer el Data Book
La lista exacta debe provenir del contrato. Aun así, existen familias documentales recurrentes que ayudan a estructurar los requisitos.
Documentos de ingeniería y diseño
Pueden incluir memorias, especificaciones, criterios de diseño, planos generales, detalles, diagramas, listas, hojas de datos, cálculos relevantes, documentos de interfaz y revisiones finales. En el cierre, solamente los documentos con el estado adecuado deben tratarse como referencia final.
Los proyectos preliminares, planos superados o archivos de trabajo pueden tener valor histórico, pero no deben competir visualmente con la documentación aceptada. Si se conservan, deben estar claramente clasificados.
Documentación de proveedores y equipos
Para equipos y sistemas adquiridos, el Data Book puede reunir:
- hoja de datos final;
- plano dimensional y de disposición;
- diagramas eléctricos, neumáticos o de instrumentación;
- lista de componentes;
- certificados de materiales;
- certificados de calibración;
- curvas y datos de desempeño;
- informes de inspección;
- pruebas de fábrica;
- certificados de conformidad;
- manual de instalación;
- manual de operación y mantenimiento;
- lista de repuestos;
- garantías;
- backups, parámetros o archivos de configuración cuando corresponda.
El punto crítico es la correspondencia entre la documentación y el ítem suministrado. Un manual genérico de familia no necesariamente representa la configuración instalada. El Data Book debe identificar modelo, tag, serie, versión, firmware u otra característica necesaria para eliminar ambigüedades.
Registros de calidad e inspección
Dependiendo del alcance, pueden existir planes de inspección y pruebas, procedimientos, liberaciones, inspecciones de recepción, END, certificados de soldadores, certificados de materiales, registros de torque, pruebas de presión, inspecciones visuales, informes dimensionales y otros documentos.
Estos registros demuestran cómo se verificó la conformidad a lo largo de la fabricación y la ejecución. Su ausencia no puede compensarse simplemente con un plano As-Built correcto: plano y evidencia de calidad cumplen funciones diferentes.
Registros de construcción y montaje
Incluyen levantamientos de campo, registros de instalación, informes diarios cuando sean requeridos, mediciones, liberaciones de frentes, registros de elementos ocultos y demás documentos que ayuden a reconstruir la condición ejecutada.
Para redes enterradas, infraestructuras embebidas o componentes que quedarán inaccesibles, la evidencia debe producirse en el momento correcto. Fotografías sin ubicación, escala o identificación pueden ser insuficientes años después.
Pruebas, ensayos y comisionamiento
El Data Book debe preservar la evidencia de las pruebas que respaldan la aceptación. Esto puede incluir:
- inspecciones prefuncionales;
- pruebas de continuidad, aislamiento o resistencia;
- certificación de enlaces de telecomunicaciones;
- calibración de instrumentos;
- pruebas de estanqueidad y presión;
- balanceo y mediciones de HVAC;
- pruebas funcionales;
- FAT y SAT;
- pruebas integradas;
- resultados de desempeño;
- listas de excepciones;
- repetición de pruebas después de correcciones.
El resultado “aprobado” debe ser trazable al procedimiento, instrumento, equipo, fecha y responsable aplicables cuando ello sea requisito del sistema. El artículo sobre Comisionamiento en Ingeniería profundiza precisamente en la formación de estas evidencias a lo largo de la verificación y las pruebas.
Cambios, RFIs y no conformidades
Un Data Book que contiene solamente el estado final puede no explicar por qué una configuración difiere del diseño originalmente aprobado. Para ítems relevantes, la documentación final debe mantener trazabilidad con decisiones de campo, RFIs, registros de cambio, no conformidades y aprobaciones asociadas.
Esta relación no significa incluir toda la correspondencia administrativa dentro del Data Book. Significa preservar los registros que respaldan técnicamente la condición final. El proceso de Engineering Change Management (ECM) ayuda a diferenciar una modificación informal de un cambio técnicamente analizado, aprobado e incorporado a la baseline.
Documentación As-Built
El As-Built es una de las partes centrales del cierre. Planos, diagramas, modelos, listas de activos, identificación de circuitos, rutas, datos de configuración y demás información final deben corresponder a la instalación efectivamente entregada.
La trazabilidad debe conectar modificaciones, evidencias de campo y revisión final. Un plano simplemente renombrado como “As-Built” no demuestra que haya existido verificación. La Guía Completa de As-Built en Ingeniería organiza la visión general del proceso; para proyectos que exigen baselines, gates, QA/QC, matriz de evidencias y criterios formales de aceptación, el Framework de As-Built en Ingeniería profundiza en la gobernanza.
Operación, mantenimiento y garantías
El Data Book debe permitir transferir el activo a quienes lo operarán. Dependiendo del proyecto, esto incluye manuales, procedimientos, parámetros, rutinas de mantenimiento, consumibles, repuestos, certificados, garantías, contactos de fabricantes y limitaciones operativas.
Esta capa es especialmente relevante cuando el equipo de operación no participó en la construcción. La documentación debe ser suficiente para iniciar la operación y el mantenimiento sin depender del conocimiento informal del equipo de implantación.
Data Book por disciplina: el contenido cambia
Un error de contratación es exigir el mismo checklist documental para todas las disciplinas. La estructura general puede ser común, pero las evidencias deben reflejar el objeto.
| Disciplina | Ejemplos de documentos/evidencias |
| Civil/estructural | proyectos finales, control tecnológico, hormigonado, topografía, inspecciones, materiales, As-Built |
| Mecánica/proceso | data sheets, certificados, soldadura, END, pruebas hidrostáticas, alineación, flushing, manuales |
| Eléctrica | diagramas, listas de cables, paneles, protecciones, ensayos, ajustes, termografía cuando sea requerida, comisionamiento |
| Instrumentación | lista de instrumentos, calibraciones, loop checks, data sheets, range, setpoints, certificados |
| Automatización | arquitectura, I/O, backups, versiones de software, lógica, pantallas, parámetros, pruebas funcionales |
| Telecomunicaciones | diagramas, racks, fibras, enlaces, certificaciones, OTDR/OLTS cuando corresponda, inventario |
| Seguridad electrónica | planos, diagramas, inventario, configuraciones, direccionamiento, backups, pruebas, matrices funcionales |
| HVAC | equipos, curvas, TAB, controles, parámetros, pruebas, manuales y comisionamiento |
| Protección contra incendios | dispositivos, lazos, programación, cause & effect, ensayos, pruebas integradas y certificados aplicables |
Esto refuerza la necesidad de una Document Requirement List específica. La lista define qué debe entregar cada paquete e impide que el Data Book se convierta en un checklist genérico copiado de otro proyecto.
Vendor Data Book: cómo controlar la documentación de proveedores
Los equipos adquiridos normalmente llegan con documentación producida fuera del flujo principal del proyecto. Sin gobernanza, aparecen archivos con nomenclaturas propias, revisiones incompatibles, planos sin aprobación o manuales que no corresponden al ítem instalado.
El Vendor Data Book debe controlarse desde el procurement. Ya en la requisición o en la orden de compra, el contratante debería definir:
| Requisito | Ejemplo |
| Lista documental | plano GA, data sheet, manual, certificados, pruebas |
| Plazo | documentos para aprobación antes de la fabricación y documentos finales antes del embarque/aceptación |
| Revisión | codificación y estado esperados |
| Formato | PDF, DWG, XLSX, archivos nativos, backups |
| Idioma | requisito contractual |
| Identificación | tag, modelo, serie, pedido, fabricante |
| Aprobación | responsable técnico y flujo de comentarios |
| Final Data Book | índice y organización del paquete final |
Esto evita un problema frecuente: intentar exigir documentos importantes después de que el equipo ya haya sido fabricado, entregado o comisionado.
El Data Book tampoco debe confundirse con la aprobación de ingeniería. Recibir un documento no significa aprobarlo; aprobar un plano de proveedor no significa aceptar el equipo; aceptar el equipo no significa concluir el sistema. Los estados deben preservarse.
Data Book y comisionamiento deben estar integrados
El comisionamiento genera parte de las evidencias más importantes del cierre. Cada sistema debería contar con una relación clara entre requisitos, equipos, checklists, pruebas y resultados. Estas evidencias alimentan el Data Book y, en proyectos con una gobernanza documental más amplia, también el Quality Dossier del contrato o del proyecto.
Un proceso maduro puede utilizar una matriz como:
Requisito → sistema → tag/activo → procedimiento → prueba → resultado → pendiente → nueva prueba → documento final.
Esta estructura hace que el Data Book sea utilizable para auditoría y diagnóstico de problemas. Si un equipo presenta una avería futura, es posible recuperar qué prueba se ejecutó, qué parámetros estaban configurados y si existían excepciones en la aceptación.
El paquete de comisionamiento puede estar físicamente separado del Data Book, especialmente en proyectos grandes. Aun así, el índice final debe indicar dónde está almacenada cada evidencia y qué documento tiene estado de registro permanente.
FAT y SAT también deben tratarse correctamente. La prueba de fábrica demuestra un determinado desempeño o condición antes del envío; la prueba en campo demuestra las condiciones después de la instalación e integración. Una no sustituye automáticamente a la otra.
Data Book, Punch List y criterios de aceptación
La entrega del Data Book forma parte del cierre técnico, pero la recepción no debe ser automática. El contratante debe verificar si el paquete está completo, es coherente y está relacionado con la condición física aceptada.
Una estrategia de aceptación puede separar:
- completitud documental — todos los documentos previstos están presentes;
- corrección formal — codificación, revisión, títulos y estados son correctos;
- coherencia técnica — los documentos no se contradicen;
- correspondencia física — el As-Built y los registros representan lo ejecutado;
- trazabilidad — las modificaciones y evidencias tienen origen conocido;
- pruebas y comisionamiento — los resultados necesarios están completos y aprobados;
- pendientes — los ítems de Punch List están cerrados o formalmente clasificados;
- utilidad operativa — el paquete permite operar, mantener y localizar información del activo.
La Autoridad Portuaria de Santos ofrece un ejemplo claro de la conexión entre Data Book y aceptación: en el modelo contractual consultado, la entrega del Data Book es el gatillo para realizar la inspección técnica destinada a la aceptación de la obra.
La consecuencia es importante: la documentación no es una actividad administrativa posterior a la entrega; puede ser un requisito para caracterizar la propia entrega.
Cuando existan pendientes, la Punch List en Ingeniería debe tratar también ítems documentales, y no solamente correcciones físicas de campo.
Cómo montar una matriz de trazabilidad del Data Book
La lista de archivos, por sí sola, informa que algo fue recibido. Una matriz de trazabilidad muestra por qué existe ese documento y con qué se relaciona.
| Campo | Ejemplo de uso |
| ID del documento | código único |
| Título | descripción controlada |
| Disciplina/sistema | eléctrica, HVAC, automatización, etc. |
| Tag/activo | equipo o conjunto asociado |
| Requisito | especificación, contrato, norma o ITP que exige el registro |
| Proveedor/responsable | origen del documento |
| Revisión | revisión actual |
| Estado | para aprobación, aprobado, final, As-Built, etc. |
| Evidencia asociada | prueba, certificado, informe, cambio |
| Pendiente | ítem abierto que impide el cierre |
| Ubicación | volumen/carpeta/CDE |
| Aceptación | responsable y fecha |
Este modelo también reduce problemas con documentos duplicados. Un único registro maestro identifica cuál revisión es válida, mientras que las versiones antiguas pueden mantenerse en el historial sin aparecer como versiones competidoras en el paquete final.
El handover digital exige información utilizable, no solamente archivos almacenados.
El Data Book debe preservar la evidencia formal de la entrega y, cuando corresponda, conectar documentos, modelos, activos, metadatos y registros de operación en un entorno controlado.
Cuando la entrega necesita conectar documentos, modelos, activos y metadatos en un entorno controlado, la Gestión BIM e Información de Ingeniería estructura requisitos, estados de información, revisión, aceptación y continuidad para la fase operativa.
Data Book digital, CDE y gestión de la información
La digitalización del Data Book no debe limitarse a convertir papel en PDF. Un Data Book digital debe mejorar la búsqueda, la trazabilidad, el control de revisiones y la reutilización de la información.
En Brasil, la ABNT NBR ISO 19650-2:2022, en su Versión Corregida 2 de 2025, estructura la gestión de la información durante la fase de entrega de activos, incluyendo requisitos de información, CDE, producción colaborativa, revisión, aceptación del modelo de información y cierre del proyecto. La ABNT NBR ISO 19650-3:2025 extiende esta gobernanza a la fase operativa, abordando el mantenimiento del modelo de información del activo y la continuidad de las informaciones necesarias para la gestión del activo.
La ABNT NBR ISO 19650-4:2025 complementa esta lógica al detallar criterios para los intercambios de información, incluyendo conformidad, continuidad, consistencia y completitud. Ninguna de estas normas define un “Data Book” universal; su contribución es ofrecer una estructura de gobernanza para que la información entregada sea identificable, controlada, revisable y utilizable en la transición entre diseño, entrega y operación.
En entornos BIM, el handover puede conectar documentos con objetos, sistemas y activos. El PIM — Project Information Model — y el AIM — Asset Information Model ayudan a comprender esta transición. El Data Book tradicional y este flujo digital no son excluyentes: el primero puede funcionar como paquete formal de evidencias, mientras que el modelo de información permite el acceso y uso estructurado de estos datos durante la operación.
Un CDE — Common Data Environment — también reduce la necesidad de un “montaje artesanal” al cierre, porque las versiones, aprobaciones, transmittals y metadatos ya fueron gobernados durante el proyecto. El cierre pasa a ser un proceso de selección y validación del estado final, no de búsqueda de documentos perdidos.
Para datos estructurados de activos, COBie es otro ejemplo de cómo la información de equipos, espacios y mantenimiento puede organizarse para el handover sin sustituir los documentos formales del Data Book.
El PDF sigue siendo importante, pero también puede ser necesario el archivo nativo
El PDF tiene valor como registro estable, pero no sustituye todos los formatos editables. Dependiendo del uso futuro, el contrato puede exigir DWG, IFC, XLSX, archivos de configuración, backups de controladores, bases de datos, archivos de programación u otros formatos nativos.
La Autoridad Portuaria de Santos, en el ejemplo citado, exigió específicamente DWG y PDF. Este tipo de definición contractual elimina ambigüedades sobre el formato final.
La regla debe ser: formato de registro para preservar la evidencia + formato utilizable para operación, mantenimiento y futuras modificaciones, cuando sea necesario.
Quién es responsable del Data Book
El cierre documental es multidisciplinario y no debe concentrarse en una sola persona únicamente al final. Es útil separar responsabilidades.
| Rol | Responsabilidad típica |
| Contratante/propietario | definir requisitos, formatos y criterios de aceptación |
| Proyectista | emitir los documentos finales de ingeniería bajo su responsabilidad |
| Proveedor | producir vendor data y evidencias del suministro |
| Constructora/instaladora | mantener registros de ejecución y modificaciones de campo |
| Calidad | controlar inspecciones, ensayos, certificados y no conformidades |
| Comisionamiento | consolidar checklists, pruebas, excepciones y nuevas pruebas |
| Document Control | gobernar codificación, revisiones, transmittals, estados y estructura documental |
| Owner’s Engineering/fiscalización | verificar completitud, coherencia y correspondencia con los criterios de aceptación |
| Operación/mantenimiento | validar si la información recibida es utilizable en la fase operativa |
La matriz real depende del contrato. El punto crítico es evitar que la responsabilidad quede implícita. Si nadie es responsable de integrar documentos de proveedores, As-Built y pruebas, el resultado final será fragmentado aunque cada participante haya cumplido su parte de forma aislada.
Cómo especificar un Data Book en contrato o Términos de Referencia
La frase “la contratista deberá entregar el Data Book al final” es insuficiente. Una especificación técnicamente útil debe indicar el contenido y el mecanismo de control.
Como referencia externa de aplicación contractual, la Autoridad Portuaria de Santos vinculó expresamente la entrega del Data Book con la inspección técnica de aceptación, exigiendo historial de la obra, proyectos, informes de inspección, As-Built, manual de operación y mantenimiento y ensayos técnicos.
| Requisito contractual | Qué definir |
| Alcance | qué sistemas, áreas, paquetes y equipos se incluyen |
| Índice mínimo | estructura de volúmenes/secciones |
| Document Requirement List | qué documentos entrega cada disciplina/proveedor |
| Codificación | estándar para documentos y revisiones |
| Estado | aprobación, final, As-Built, registro, etc. |
| Formatos | PDF, DWG, IFC, hojas de cálculo, archivos nativos, backups |
| Metadatos | tag, disciplina, sistema, proveedor, revisión |
| Entregas parciales | cuándo debe entregarse cada paquete |
| Revisión y comentarios | flujo de análisis y plazo de corrección |
| Evidencias | qué certificados, inspecciones y pruebas son obligatorios |
| As-Built | criterios de actualización y validación |
| Comisionamiento | documentos permanentes del paquete de pruebas |
| Pendientes | regla para documentos vinculados a la Punch List |
| Organización | directorios, CDE, volúmenes, índice e hipervínculos |
| Aceptación | checklist, muestreo, criterios de rechazo y aprobación |
| Handover | forma de transferencia para operación y mantenimiento |
En contratos complejos, también es recomendable vincular el cierre documental a los hitos de medición. Si se alcanza el 100 % del pago antes de consolidar los documentos finales, el contratante pierde un mecanismo importante de incentivo para un cierre adecuado.
Del mismo modo, no es eficiente retener todo el control hasta el final. Aprobar parcialmente vendor data, registros de calidad y paquetes de sistema a lo largo de la ejecución reduce el volumen de correcciones tardías.
La recepción documental exige evidencia de completitud y correspondencia con la obra.
La auditoría debe verificar los documentos previstos, revisiones, firmas, pruebas, pendientes, As-Built y las condiciones necesarias para que operación reciba información confiable.
Cuando el cierre documental participa en la decisión de aceptación, la Recepción Técnica de Obras y Servicios de Ingeniería relaciona completitud, pendientes, evidencias y condiciones contractuales con la recomendación de recepción.
Cómo auditar un Data Book antes de la recepción
La auditoría puede dividirse en niveles.
Nivel 1 — Existencia
¿Se entregaron todos los ítems previstos en la Document Requirement List? ¿Existen lagunas, archivos dañados o referencias a documentos ausentes?
Nivel 2 — Control documental
¿Los códigos, revisiones, estados, fechas y títulos son coherentes? ¿El índice apunta a la revisión correcta? ¿Existen versiones competidoras presentadas como finales?
Nivel 3 — Contenido técnico
¿El documento corresponde al equipo, sistema o área correctos? ¿Los certificados y manuales representan el ítem realmente instalado? ¿Los resultados de las pruebas tienen identificación suficiente?
Nivel 4 — Correspondencia con campo
¿El As-Built y los registros críticos corresponden a la condición física? ¿Tags, rutas, equipos y configuraciones son coherentes con la instalación?
Nivel 5 — Trazabilidad
¿Las modificaciones relevantes tienen origen identificado? ¿Las no conformidades están cerradas? ¿Las nuevas pruebas confirman las correcciones? ¿Los documentos finales incorporan las decisiones tomadas?
Nivel 6 — Preparación operativa
¿El equipo de operación puede utilizar el Data Book? ¿Existe documentación suficiente para mantenimiento, diagnóstico de problemas, garantía, reposición y futuras modificaciones?
Esta última verificación es importante porque un paquete puede estar formalmente completo y aun así ser poco útil. El objetivo del handover no es solamente transferir archivos; es transferir información utilizable.
Errores comunes en la elaboración del Data Book
| Error | Consecuencia | Corrección |
| comenzar solamente al final | documentos perdidos y lagunas imposibles de recomponer | mantener MDR y entregas progresivas |
| no definir el índice en el contrato | cada proveedor entrega una estructura diferente | emitir template y Document Requirement List |
| aceptar cualquier revisión disponible | referencia final ambigua | controlar estado y revisión maestra |
| insertar documentos genéricos | el manual/certificado puede no representar lo instalado | vincular el documento con tag, modelo y serie |
| separar As-Built de las modificaciones | condición final sin historial técnico | mantener trazabilidad de las modificaciones relevantes |
| archivar pruebas sin identificación | el resultado no puede asociarse al sistema | registrar procedimiento, tag, fecha y responsable |
| duplicar archivos en varias carpetas | duda sobre cuál versión es válida | adoptar una única fuente de verdad y referencias controladas |
| entregar solamente PDF cuando se necesitan archivos nativos | la operación y las futuras modificaciones quedan limitadas | especificar formatos útiles desde la contratación |
| considerar la Punch List solamente física | los pendientes documentales permanecen abiertos | clasificar pendientes físicos, funcionales y documentales |
| confundir entrega con aceptación | el paquete puede estar incompleto o ser incorrecto | aplicar checklist y criterios formales de recepción |
Data Book como puente entre obra y operación
El mayor valor del Data Book aparece después de que el equipo de implantación deja el proyecto. Operación necesita localizar rápidamente documentación de equipos, confirmar parámetros, verificar garantías, comprender modificaciones, planificar mantenimiento y preparar futuras intervenciones.
Cuando el Data Book fue construido solamente para cumplir un ítem contractual, esta información tiende a permanecer aislada en carpetas. Cuando fue estructurado para el ciclo de vida del activo, puede alimentar GED/EDMS, CDE, CMMS, EAM, modelos BIM, registros patrimoniales y otras plataformas operativas.
La transición debe preservar la fuente de verdad. El documento final aprobado debe continuar siendo identificable aunque sea migrado a otro sistema. Los vínculos entre activo, documento, revisión, prueba y garantía no deberían perderse en el handover.
Este es también el punto en el que Data Book y gestión de activos se encuentran. El proyecto deja de tratarse como “obra” y pasa a tratarse como “activo en operación”. La documentación final es el puente entre estas dos condiciones. La Guía Completa de As-Built en Ingeniería amplía esta visión hacia documentación, validación, Data Book, handover y ciclo de vida.
El Data Book no cierra la ingeniería por sí solo
Incluso un Data Book completo no sustituye la verificación de la condición física. El cierre técnico depende de la convergencia entre ejecución, As-Built, pruebas, comisionamiento, corrección de pendientes, documentación y aceptación.
Un flujo consistente es:
requisitos documentales → diseño y procurement → fabricación → construcción/montaje → inspecciones → pruebas → cambios → As-Built → comisionamiento → Punch List → consolidación del Data Book → auditoría documental → recepción técnica → handover → operación.
Si la condición física todavía presenta pendientes impeditivos, el Data Book no hace que la obra esté lista. Si el sistema funciona pero la documentación está incompleta, la conclusión física tampoco representa un cierre técnico adecuado.
La lógica más robusta es considerar que la obra, el sistema y la información deben alcanzar juntos el estado de aceptación. Esto es lo que transforma el Data Book de un simple archivo de cierre en un instrumento de gobernanza técnica y continuidad del activo.
Referencias 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 del Data Book, documentación final, inspección y aceptación. 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. Referencias a As-Built y Data Book como documentación de ingeniería en un proyecto. Brasília: TCU, 2014.
Preguntas frecuentes
Es el expediente técnico estructurado que reúne documentos y evidencias de lo que fue diseñado, suministrado, ejecutado, inspeccionado, probado, modificado y entregado. Puede incluir proyectos, vendor data, certificados, inspecciones, pruebas, As-Built, manuales, garantías y registros de comisionamiento.
No. El As-Built representa la configuración final efectivamente ejecutada. El Data Book es más amplio y normalmente incorpora el As-Built junto con documentación de proveedores, calidad, inspecciones, pruebas, comisionamiento, manuales, garantías y demás registros requeridos.
No existe una única norma universal que defina el contenido de todo Data Book. El contenido debe establecerse mediante el contrato, las especificaciones, los requisitos del propietario, las normas de las disciplinas, los planes de inspección y pruebas y los criterios de recepción.
Desde la definición de los requisitos documentales y del procurement. La organización debe realizarse progresivamente durante diseño, fabricación, construcción, pruebas y comisionamiento, evitando intentar reconstruir todo el historial solamente al cierre.
Es el expediente técnico de un proveedor o equipo, que reúne documentos como data sheets, planos, certificados, inspecciones, pruebas, manuales, garantías y demás registros del suministro. Varios Vendor Data Books pueden integrar el Data Book general de la obra.
Depende del alcance. Entre los más comunes se encuentran proyectos finales, As-Built, memorias, hojas de datos, documentación de proveedores, certificados de materiales, inspecciones, ensayos, FAT/SAT, comisionamiento, registros de cambios, manuales, garantías, listas de repuestos y documentos de recepción.
Solamente si el contrato y el uso futuro lo permiten. El PDF es adecuado como registro estable, pero DWG, IFC, hojas de cálculo, backups, archivos de configuración y otros formatos nativos pueden ser necesarios para operación, mantenimiento y futuras modificaciones.
La verificación debe evaluar completitud, codificación, revisiones, coherencia técnica, correspondencia con campo, trazabilidad de cambios, pruebas, cierre de pendientes y utilidad de la información para operación y mantenimiento.
El comisionamiento genera evidencias de verificación y pruebas que normalmente integran o son referenciadas por el Data Book. Checklists, resultados, excepciones, nuevas pruebas, FAT/SAT y pruebas integradas ayudan a demostrar que la condición final fue verificada antes del handover.
El Data Book es uno de los principales instrumentos de transferencia de la información técnica desde la fase de implantación hacia la operación. En el handover, la documentación final debe dejar de ser solamente un archivo de la obra y convertirse en información utilizable para mantenimiento, garantía, auditoría y futuras intervenciones.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Requisitos, Evidencias y Criterios de Aceptación
- Gestión de Pendientes, RFIs y No Conformidades
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Gobernanza de Proyectos, Programas y Portafolios
Servicios relacionados
- Recepción Técnica de Obras y Servicios
- Comisionamiento de Equipos
- Apoyo Técnico a la Fiscalización
- Ingeniería del Propietario (Owner’s Engineering)
- Procurement Técnico
Contenidos principales sobre el tema
- Quality Dossier en Ingeniería
- Punch List en Ingeniería
- Criterios de Aceptación en Ingeniería
- FAT y SAT
- Informe de No Conformidad (RNC/NCR)
- Inspección de Fabricación y Vendor Inspection
- QA/QC en Obras de Ingeniería
