{"id":72634,"date":"2026-08-28T09:50:12","date_gmt":"2026-08-28T12:50:12","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=72634"},"modified":"2026-08-28T09:50:12","modified_gmt":"2026-08-28T12:50:12","slug":"data-book-de-obra-ingenieria","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/es-es\/contenido\/articulos-tecnicos\/data-book-de-obra-ingenieria\/","title":{"rendered":"Data Book de Obra: qu\u00e9 es, estructura, documentos y criterios de aceptaci\u00f3n"},"content":{"rendered":"\n

El Data Book de obra<\/strong> es el expediente t\u00e9cnico estructurado que re\u00fane las evidencias necesarias para demostrar lo que fue dise\u00f1ado, 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\u00f3n controlada de documentos producidos durante el dise\u00f1o, los suministros, la fabricaci\u00f3n, la construcci\u00f3n, el montaje, el comisionamiento y el cierre.<\/p>\n\n\n\n

Su contenido var\u00eda seg\u00fan el contrato, la disciplina y la criticidad del activo. En una obra sencilla, puede incluir proyectos finales, documentaci\u00f3n As-Built, certificados, informes de inspecci\u00f3n, ensayos y manuales. En proyectos industriales, de energ\u00eda, infraestructura o sistemas cr\u00edticos, el Data Book puede incorporar tambi\u00e9n vendor data, hojas de datos, certificados de materiales, registros de fabricaci\u00f3n, inspecciones, pruebas FAT\/SAT, procedimientos, registros de no conformidad, calibraciones, listas de pendientes, evidencias de comisionamiento, garant\u00edas, listas de repuestos, par\u00e1metros finales y documentaci\u00f3n para operaci\u00f3n y mantenimiento.<\/p>\n\n\n\n

La caracter\u00edstica que diferencia un Data Book confiable de un simple archivo documental es la trazabilidad<\/strong>. Cada documento debe estar relacionado con el objeto, equipo, sistema, requisito o etapa que pretende evidenciar; tener identificaci\u00f3n y revisi\u00f3n controladas; contar con un estado conocido; y permitir que otro equipo comprenda la condici\u00f3n entregada sin depender de la memoria de quienes participaron en la obra.<\/p>\n\n\n\n

Por ello, Data Book y As-Built no son sin\u00f3nimos. El As-Built representa la configuraci\u00f3n efectivamente ejecutada de la obra, instalaci\u00f3n o sistema. El Data Book es m\u00e1s amplio: puede contener el propio As-Built, pero tambi\u00e9n todos los registros t\u00e9cnicos necesarios para demostrar conformidad, calidad, pruebas, origen de materiales, caracter\u00edsticas de los equipos, modificaciones, garant\u00edas y condiciones de operaci\u00f3n.<\/p>\n\n\n\n

Tampoco existe una \u00fanica norma universal que determine el contenido de cualquier Data Book. La estructura debe definirse por el contrato, las especificaciones t\u00e9cnicas, los requisitos del propietario, las normas aplicables a las disciplinas, los planes de inspecci\u00f3n y pruebas y el modelo de recepci\u00f3n del proyecto. El error m\u00e1s com\u00fan es exigir gen\u00e9ricamente la \u201centrega del Data Book\u201d sin definir \u00edndice, contenido, responsabilidades, formatos, revisiones y criterios de aceptaci\u00f3n.<\/p>\n\n\n\n

Un Data Book bien planificado comienza junto con la definici\u00f3n de los requisitos documentales. Durante la ejecuci\u00f3n, 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\u00f3n final deja de ser un archivo de la obra y pasa a ser una fuente de informaci\u00f3n para operaci\u00f3n, mantenimiento, auditor\u00eda, garant\u00eda, ampliaciones e intervenciones futuras.<\/p>\n\n\n\n

En s\u00edntesis, el Data Book es la memoria t\u00e9cnica verificable del proyecto entregado<\/strong>. Su funci\u00f3n no es solamente archivar documentos, sino demostrar que aquello que fue contratado puede identificarse, rastrearse, verificarse y utilizarse despu\u00e9s de la conclusi\u00f3n f\u00edsica de la obra.<\/p>\n\n\n\n\n

Qu\u00e9 es un Data Book de obra<\/h2>\n\n\n\n

El t\u00e9rmino Data Book<\/em> se utiliza en diferentes sectores de la ingenier\u00eda para designar el conjunto organizado de registros t\u00e9cnicos de un suministro, equipo, sistema, paquete o proyecto. El alcance cambia, pero existe un principio com\u00fan: consolidar informaci\u00f3n suficiente para demostrar la condici\u00f3n y la conformidad del objeto entregado.<\/p>\n\n\n\n

En una contrataci\u00f3n p\u00fablica de la Autoridad Portuaria de Santos<\/a>, por ejemplo, el Data Book fue establecido como documento necesario para respaldar la inspecci\u00f3n t\u00e9cnica de aceptaci\u00f3n de la obra. La documentaci\u00f3n prevista inclu\u00eda el historial de la obra, proyectos, informes de inspecci\u00f3n, As-Built, manual de operaci\u00f3n y mantenimiento y ensayos t\u00e9cnicos. Es un buen ejemplo del Data Book como instrumento de recepci\u00f3n<\/strong>, y no solamente como archivo administrativo.<\/p>\n\n\n\n

La aplicaci\u00f3n pr\u00e1ctica puede darse en tres escalas diferentes:<\/p>\n\n\n\n

Escala<\/td>Objeto t\u00edpico<\/td>Funci\u00f3n del Data Book<\/td><\/tr>
Equipo<\/td>panel, bomba, transformador, chiller, skid, UPS<\/td>reunir datos de fabricaci\u00f3n, materiales, inspecciones, pruebas, manuales y configuraci\u00f3n final<\/td><\/tr>
Sistema o paquete<\/td>el\u00e9ctrica, HVAC, automatizaci\u00f3n, telecomunicaciones, seguridad, proceso<\/td>consolidar documentos de varios equipos y demostrar integraci\u00f3n, pruebas y condici\u00f3n final<\/td><\/tr>
Proyecto<\/td>edificio, planta industrial, subestaci\u00f3n, data center, infraestructura<\/td>organizar la documentaci\u00f3n final multidisciplinaria para aceptaci\u00f3n, handover y operaci\u00f3n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Esto explica por qu\u00e9 la expresi\u00f3n Vendor Data Book<\/strong> tambi\u00e9n es com\u00fan. En este caso, el foco es el expediente t\u00e9cnico de un fabricante o proveedor. El Data Book de obra puede incorporar varios Vendor Data Books, a\u00f1adiendo documentaci\u00f3n de dise\u00f1o, construcci\u00f3n, integraci\u00f3n, pruebas de campo y recepci\u00f3n.<\/p>\n\n\n\n

La existencia de un anexo denominado \u201cDocumentaci\u00f3n Data-Book de la Obra\u201d en un proceso p\u00fablico de la Secretar\u00eda de Estado de Salud de Amazonas<\/a> tambi\u00e9n muestra que la expresi\u00f3n se utiliza formalmente en contrataciones de infraestructura. Lo importante es no concluir que existe un modelo \u00fanico: cada contratante debe especificar el contenido que realmente necesita.<\/p>\n\n\n\n\n

Data Book, As-Built, dossier de calidad y manual de operaci\u00f3n son documentos diferentes<\/h2>\n\n\n\n

Gran parte de los problemas de cierre nace de utilizar estos t\u00e9rminos como equivalentes. Est\u00e1n relacionados, pero cumplen funciones diferentes.<\/p>\n\n\n\n

Entregable<\/td>Pregunta principal<\/td>Contenido predominante<\/td>Relaci\u00f3n con el Data Book<\/td><\/tr>
As-Built<\/strong><\/td>\u00bfcu\u00e1l es la configuraci\u00f3n final ejecutada?<\/td>planos, diagramas, modelos, listas y datos actualizados<\/td>normalmente integra el Data Book<\/td><\/tr>
Dossier de calidad<\/strong><\/td>\u00bfqu\u00e9 controles demuestran la conformidad de fabricaci\u00f3n y ejecuci\u00f3n?<\/td>certificados, inspecciones, ensayos, ITP\/PIT, informes, NC y liberaciones<\/td>puede ser un volumen o secci\u00f3n del Data Book<\/td><\/tr>
Vendor Data Book<\/strong><\/td>\u00bfel equipo suministrado dispone de documentaci\u00f3n t\u00e9cnica y evidencias de fabricaci\u00f3n\/pruebas?<\/td>planos, data sheets, certificados, manuales, pruebas y registros del proveedor<\/td>puede incorporarse al Data Book del sistema\/obra<\/td><\/tr>
Manual de operaci\u00f3n y mantenimiento<\/strong><\/td>\u00bfc\u00f3mo operar y mantener el activo?<\/td>procedimientos, recomendaciones, rutinas, l\u00edmites, repuestos<\/td>integra o referencia el paquete final<\/td><\/tr>
Paquete de comisionamiento<\/strong><\/td>\u00bfel sistema fue verificado y probado conforme a los requisitos?<\/td>checklists, pruebas, resultados, excepciones y evidencias<\/td>integra el Data Book o el handover package<\/td><\/tr>
Data Book<\/strong><\/td>\u00bfexiste evidencia organizada de todo el objeto entregado?<\/td>conjunto consolidado de los registros t\u00e9cnicos pertinentes<\/td>es el dossier integrador<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

La diferencia m\u00e1s importante es de funci\u00f3n documental<\/strong>. El As-Built muestra la condici\u00f3n final. Un certificado de material demuestra una caracter\u00edstica del \u00edtem suministrado. Un informe de inspecci\u00f3n registra una verificaci\u00f3n. Una prueba funcional evidencia desempe\u00f1o. Un manual orienta la operaci\u00f3n. El Data Book crea la estructura que relaciona estas informaciones con el objeto entregado.<\/p>\n\n\n\n

Para profundizar espec\u00edficamente en la configuraci\u00f3n final ejecutada, el art\u00edculo sobre Proyecto As-Built en Ingenier\u00eda<\/a> aborda actualizaci\u00f3n, evidencias y criterios de aceptaci\u00f3n de lo \u201cconstruido\u201d.<\/p>\n\n\n\n

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\u00edcil, o un paquete demasiado reducido, compuesto solamente por PDFs finales sin documentaci\u00f3n suficiente para respaldar la aceptaci\u00f3n.<\/p>\n\n\n\n\n

El Data Book debe comenzar antes de que termine la obra<\/h2>\n\n\n\n

Montar todo el Data Book despu\u00e9s de la ejecuci\u00f3n es un proceso de reconstrucci\u00f3n. Los documentos pueden estar dispersos en correos electr\u00f3nicos, sistemas de proveedores, carpetas personales, plataformas de gesti\u00f3n, versiones preliminares o archivos sin aprobaci\u00f3n. Las evidencias de inspecci\u00f3n pueden no estar asociadas al \u00edtem correcto. Los certificados pueden haber sido entregados en formatos diferentes. Los equipos pueden haber sido sustituidos sin actualizar el registro.<\/p>\n\n\n\n

El proceso m\u00e1s robusto comienza en la contrataci\u00f3n, cuando se definen:<\/p>\n\n\n\n\n

  1. documentos exigidos por disciplina y por proveedor;<\/li>
  2. c\u00f3digos y reglas de identificaci\u00f3n;<\/li>
  3. formatos editables y formatos de registro;<\/li>
  4. flujos de emisi\u00f3n, revisi\u00f3n, aprobaci\u00f3n y devoluci\u00f3n;<\/li>
  5. responsabilidades por la producci\u00f3n y validaci\u00f3n;<\/li>
  6. documentos que deben capturarse antes de fases irreversibles;<\/li>
  7. requisitos de pruebas, inspecciones y comisionamiento;<\/li>
  8. estructura del \u00edndice final;<\/li>
  9. criterios de completitud y aceptaci\u00f3n.<\/li><\/ol>\n\n\n\n\n

    A partir de ah\u00ed, el Data Book se construye progresivamente. Esto reduce una falla recurrente: descubrir al cierre que determinado informe, certificado o prueba nunca fue producido.<\/p>\n\n\n\n

    Una forma eficiente de organizar este proceso es trabajar con un MDR \u2014 Master Document Register<\/strong> o una lista maestra equivalente. Cada documento esperado aparece antes de la entrega final, con responsable, plazo, revisi\u00f3n, estado y v\u00ednculo con el sistema o paquete. La Gesti\u00f3n de Documentos de Ingenier\u00eda<\/a> crea la infraestructura de revisi\u00f3n, 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.<\/p>\n\n\n\n

    \n

    El Data Book no debe montarse como una carpeta final de PDFs.<\/strong><\/p>\n\n\n\n

    \u00cdndice maestro, codificaci\u00f3n, revisiones, responsables y trazabilidad deben definirse desde el inicio para que la documentaci\u00f3n final sea controlable y auditable.<\/p>\n\n\n\n

    La Gesti\u00f3n de Documentos de Ingenier\u00eda<\/a> estructura MDR, revisiones, transmittals, estados y trazabilidad para que el Data Book se construya progresivamente durante el proyecto.<\/p>\n<\/div>\n\n\n\n\n

    Cu\u00e1l debe ser la estructura de un Data Book<\/h2>\n\n\n\n

    No existe un \u00edndice universal, pero una estructura consistente debe permitir que el usuario navegue desde el nivel m\u00e1s amplio hasta la evidencia espec\u00edfica. La organizaci\u00f3n debe reflejar la EDT, los sistemas, las disciplinas, los equipos o los paquetes de contrataci\u00f3n del proyecto.<\/p>\n\n\n\n

    Una arquitectura gen\u00e9rica puede contener:<\/p>\n\n\n\n

    Volumen\/secci\u00f3n<\/td>Contenido t\u00edpico<\/td><\/tr>
    00 \u2014 \u00cdndice y control<\/td>\u00edndice maestro, lista de vol\u00famenes, matriz de documentos, estado y revisiones<\/td><\/tr>
    01 \u2014 Requisitos y dise\u00f1o<\/td>especificaciones, memorias, planos aprobados, criterios de dise\u00f1o y revisiones aplicables<\/td><\/tr>
    02 \u2014 Suministros y vendor data<\/td>data sheets, planos del fabricante, listas, certificados, manuales y documentaci\u00f3n de equipos<\/td><\/tr>
    03 \u2014 Calidad y materiales<\/td>certificados de materiales, trazabilidad, procedimientos, inspecciones, END y registros de calidad<\/td><\/tr>
    04 \u2014 Construcci\u00f3n y montaje<\/td>registros de ejecuci\u00f3n, levantamientos, liberaciones, mediciones y evidencias de instalaci\u00f3n<\/td><\/tr>
    05 \u2014 Pruebas y comisionamiento<\/td>checklists, FAT, SAT, pruebas funcionales e integradas, calibraciones y resultados finales<\/td><\/tr>
    06 \u2014 Cambios y no conformidades<\/td>RFIs, field changes, NC, desv\u00edos, aprobaciones y registros de cambios<\/td><\/tr>
    07 \u2014 As-Built<\/td>planos, diagramas, listas, modelos y datos finales de la configuraci\u00f3n ejecutada<\/td><\/tr>
    08 \u2014 Operaci\u00f3n y mantenimiento<\/td>manuales, procedimientos, par\u00e1metros, repuestos, recomendaciones y capacitaci\u00f3n<\/td><\/tr>
    09 \u2014 Garant\u00edas y certificados finales<\/td>garant\u00edas, t\u00e9rminos, certificados regulatorios y documentaci\u00f3n de cierre<\/td><\/tr>
    10 \u2014 Recepci\u00f3n<\/td>Punch List final, t\u00e9rminos de aceptaci\u00f3n, pendientes remanentes y evidencias de cierre<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Esta estructura debe adaptarse. Una obra civil tiene registros diferentes de un sistema el\u00e9ctrico o de automatizaci\u00f3n. En un proyecto multidisciplinario, puede ser m\u00e1s eficiente crear vol\u00famenes por sistema y repetir internamente una misma l\u00f3gica documental.<\/p>\n\n\n\n

    La organizaci\u00f3n por sistema puede ser mejor que la organizaci\u00f3n por tipo de archivo<\/h3>\n\n\n\n

    Una carpeta \u00fanica de \u201ccertificados\u201d, otra de \u201cplanos\u201d y otra de \u201cpruebas\u201d puede funcionar en un proyecto peque\u00f1o, pero tiende a dificultar la operaci\u00f3n de un activo complejo. Para investigar un equipo espec\u00edfico, el usuario necesita navegar por varias estructuras desconectadas.<\/p>\n\n\n\n

    Una alternativa es organizar por sistema o tag:<\/p>\n\n\n\n

    Sistema \u2192 equipo\/activo \u2192 documentos de dise\u00f1o \u2192 fabricaci\u00f3n \u2192 instalaci\u00f3n \u2192 pruebas \u2192 As-Built \u2192 O&M \u2192 garant\u00eda.<\/strong><\/p>\n\n\n\n

    El criterio debe elegirse con base en el uso futuro. Si mantenimiento y operaci\u00f3n trabajan por sistema y activo, la estructura final debe facilitar esa misma l\u00f3gica.<\/p>\n\n\n\n\n

    Qu\u00e9 documentos pueden componer el Data Book<\/h2>\n\n\n\n

    La lista exacta debe provenir del contrato. Aun as\u00ed, existen familias documentales recurrentes que ayudan a estructurar los requisitos.<\/p>\n\n\n\n

    Documentos de ingenier\u00eda y dise\u00f1o<\/h3>\n\n\n\n

    Pueden incluir memorias, especificaciones, criterios de dise\u00f1o, planos generales, detalles, diagramas, listas, hojas de datos, c\u00e1lculos relevantes, documentos de interfaz y revisiones finales. En el cierre, solamente los documentos con el estado adecuado deben tratarse como referencia final.<\/p>\n\n\n\n

    Los proyectos preliminares, planos superados o archivos de trabajo pueden tener valor hist\u00f3rico, pero no deben competir visualmente con la documentaci\u00f3n aceptada. Si se conservan, deben estar claramente clasificados.<\/p>\n\n\n\n

    Documentaci\u00f3n de proveedores y equipos<\/h3>\n\n\n\n

    Para equipos y sistemas adquiridos, el Data Book puede reunir:<\/p>\n\n\n\n