Aprenda a estructurar documentación As-Built, capturar cambios de campo, coordinar redlines, validar entregables e integrar la información con la gestión de activos.
¡Descúbrelo!
La documentación As-Built es el conjunto de registros técnicos revisados para representar la condición efectivamente ejecutada de una instalación, sistema, edificio o infraestructura. Consolida cambios de campo, interfaces finales, identificaciones, características instaladas, configuraciones y evidencias necesarias para que operación, mantenimiento, auditoría y futuros proyectos trabajen sobre una base confiable.
El As-Built no debe producirse únicamente al cierre mediante un intento tardío de reconstruir lo ocurrido durante la obra. Su calidad depende de la captura continua de los cambios durante la ejecución, del control de revisiones, de la participación de las disciplinas involucradas y de la validación entre documentos, condiciones de campo, ensayos y configuraciones finales. Cuando esta cadena no existe, la entrega puede parecer un proyecto concluido sin representar fielmente el activo.
Este artículo trata específicamente de cómo estructurar y elaborar un paquete As-Built de ingeniería desde la perspectiva de la ingeniería consultiva y la gobernanza técnica. El foco está en el método de producción, los documentos y datos que componen la entrega, la consolidación de cambios de campo, los criterios de validación y la integración con el ciclo de vida del activo. El objetivo es mostrar cómo transformar redlines, registros de ejecución, levantamientos y evidencias dispersas en una base documental verificable, útil y contractualmente defendible.
Proyecto As-Built: diferencias frente al Proyecto Ejecutivo, redline y levantamiento de condición existente
As-Built significa “como construido” o “como ejecutado”. Es la documentación final revisada para corresponder a la condición implantada, incluyendo las modificaciones ocurridas entre el proyecto aprobado y la ejecución. La ABNT NBR 5410, en su apartado 6.1.8.2, establece para instalaciones eléctricas de baja tensión que la documentación del proyecto debe revisarse y actualizarse después de la conclusión para corresponder fielmente a lo ejecutado.
El principio va más allá de la disciplina eléctrica. En cualquier sistema de ingeniería, la documentación final debe permitir identificar qué existe, dónde está, cómo se conecta, qué características posee y en qué configuración fue entregado. La profundidad varía según alcance, criticidad, exigencias contractuales, normas aplicables y necesidades futuras de operación y mantenimiento. Para una visión amplia del concepto, requisitos, validación, Data Book, handover y ciclo de vida, la Guía Completa de As-Built en Ingeniería funciona como hub de esta línea técnica.
Proyecto Ejecutivo y As-Built no son la misma etapa
El Proyecto Ejecutivo de Ingeniería define con suficiente detalle lo que debe ejecutarse. El As-Built registra lo que efectivamente fue implantado. En una ejecución ideal, la condición final permanece próxima al proyecto ejecutivo; aun así, identificaciones, rutas, cotas, modelos, números de serie, parámetros, revisiones de fabricante y ajustes de campo deben consolidarse.
El As-Built no debe sustituir la ingeniería que faltó antes de la obra. Cuando decisiones fundamentales se toman únicamente en campo, sin cálculo, coordinación o aprobación, la simple actualización del plano no regulariza automáticamente la decisión. La documentación final registra la condición ejecutada, pero no elimina la necesidad de verificar conformidad, desempeño, responsabilidad técnica y cumplimiento de requisitos.
El redline es un registro de cambios, no la entrega final
El redline es la marca de campo utilizada para indicar cambios sobre planos o documentos controlados. Puede registrar desplazamientos, eliminaciones, inclusiones, cambios de ruta, dimensiones, equipos, conexiones, identificaciones o parámetros. Es una entrada esencial al proceso, pero normalmente no constituye la documentación final.
Un redline debe indicar documento de origen, revisión, fecha, responsable, descripción del cambio y referencia a la aprobación correspondiente. Marcas sin identificación, fotografías sueltas o anotaciones en copias no controladas hacen insegura la consolidación posterior. Después de verificarse, los cambios deben incorporarse a los archivos finales, someterse a revisión técnica y emitirse en la revisión definida para As-Built.
El levantamiento de condición existente es una forma de obtención de datos
El levantamiento de condición existente identifica la condición actual mediante inspección, medición, topografía, escaneo, fotografía, ensayo, rastreo de cables, lectura de placas, exportación de configuraciones u otras técnicas. Es indispensable cuando los registros de ejecución son insuficientes o cuando la instalación existe desde hace años sin documentación confiable.
Sin embargo, el levantamiento de condición existente y el As-Built no son sinónimos. El levantamiento produce datos sobre la condición observada. El As-Built transforma esos datos en documentación técnica coordinada, revisada, identificada y vinculada a sistemas, requisitos y activos. Según el caso, el levantamiento puede necesitar complementarse con ensayos, apertura de puntos, consulta a proveedores y validación por profesionales responsables.
As-Built, registro de activos y dossier de entrega
El As-Built representa planos, diagramas, memorias, listas y modelos actualizados. El registro de activos organiza equipos y componentes en una estructura orientada a la gestión, normalmente incluyendo ubicación, identificación, fabricante, modelo, número de serie, criticidad, garantía y plan de mantenimiento. El dossier de entrega reúne documentación más amplia, como certificados, ensayos, manuales, capacitaciones, actas, pendientes y garantías.
Estos elementos deben integrarse, pero no confundirse. Un conjunto de planos no sustituye el registro de activos; una planilla de equipos no sustituye diagramas ni relaciones espaciales; y un dossier voluminoso no garantiza que los documentos representen la condición instalada.
| Producto documental | Finalidad | Ejemplo de contenido |
| Proyecto Ejecutivo | orientar la ejecución | planos, cálculos, detalles, especificaciones y listas aprobadas |
| Redline | registrar cambios durante la ejecución | marcas controladas, referencias y aprobaciones |
| Levantamiento de condición existente | obtener datos de la condición existente | mediciones, inspecciones, fotos, nubes de puntos y rastreos |
| As-Built | representar técnicamente la condición final | planos, diagramas, memorias, listas y modelos actualizados |
| Registro de activos | incorporar elementos a la gestión operativa | tag, ubicación, fabricante, número de serie, garantía y mantenimiento |
| Dossier de entrega | sustentar la transferencia y aceptación | ensayos, certificados, manuales, capacitaciones y actas |
As-Built no es redibujar el proyecto después de la obra.
La documentación final debe distinguir proyecto, redline, levantamiento de condición existente, condición ejecutada y registro de activos.
Cómo elaborar un paquete As-Built durante la ejecución
La calidad de un paquete As-Built se define antes del cierre. El contrato y el plan de ejecución deben establecer documentos incluidos, formatos, responsabilidades, periodicidad de actualización, método de captura, flujo de aprobación y criterios de aceptación. Sin estas reglas, el trabajo tiende a aplazarse hasta el final, cuando los equipos ya se han desmovilizado y la información de campo se ha perdido.
En términos de proceso, la elaboración debe seguir una secuencia controlada: definir los requisitos y la matriz documental; capturar cambios y datos de campo; incorporar los cambios a los archivos de ingeniería; coordinar documentos y disciplinas; verificar la fidelidad mediante evidencias e inspecciones; y solo entonces emitir la revisión final para aceptación.
La Ejecución de Obras de Ingeniería debe tratar la documentación final como parte del avance, no como un pendiente administrativo posterior. Los paquetes ejecutables, inspecciones, mediciones y liberaciones deben generar evidencias que alimenten el As-Built por sistema, área, disciplina o contrato.
Definición de requisitos de información
El primer paso es establecer qué necesita recibir el propietario para operar, mantener, auditar, ampliar y contratar futuras intervenciones. La lista no debe copiarse de otro proyecto sin análisis. Un activo simple puede exigir planos, diagramas y manuales; una infraestructura crítica puede requerir bases de datos, parámetros, archivos nativos, modelos BIM, backups, inventarios, relaciones de interfaz e historiales de configuración.
Los requisitos deben especificar formatos editables y no editables, convenciones de nombre, codificación, unidades, sistemas de coordenadas, nivel de detalle, atributos obligatorios, estructura de carpetas, metadatos, firmas, responsabilidades y entorno de entrega. ISO 19650-4 organiza procesos y criterios de intercambio de información para asegurar la calidad de los modelos de información de proyecto y de activos en entornos BIM.
Matriz de documentos y responsabilidades
Una matriz As-Built relaciona cada documento con el sistema, disciplina, responsable de actualización, responsable de verificación, fuente de datos, formato e hito de entrega. Esta matriz evita brechas entre proyectista, ejecutora, supervisora, integrador, fabricante y propietario.
La responsabilidad debe ser compatible con el origen de la información. La ejecutora conoce los cambios de montaje; el proveedor posee los datos finales del equipo; el integrador controla configuraciones; el proyectista evalúa la coherencia técnica; la fiscalización o el Owner’s Engineering verifica la adherencia al contrato y a las evidencias. Concentrar toda la actualización en un equipo que no participó en las decisiones aumenta el riesgo de inferencias incorrectas.
| Elemento | Definición necesaria |
| Documento base | código, título, disciplina y revisión inicial |
| Fuente de actualización | redline, RFI, cambio aprobado, medición, inspección o dato de proveedor |
| Responsable de la información | parte que produce o confirma el dato de campo |
| Responsable de la incorporación | profesional que actualiza el archivo controlado |
| Verificación | responsable de verificar consistencia técnica y documental |
| Formato final | PDF, DWG, RVT, IFC, XLSX, base de datos, archivo de configuración u otro |
| Hito | emisión parcial, completación de sistema, aceptación o cierre |
| Evidencia | fotografía, informe, certificado, ensayo, levantamiento o registro de aprobación |
Captura continua de los cambios
La captura debe ocurrir en el momento del cambio o inmediatamente después de la ejecución. Diarios, inspecciones, aplicaciones de campo, modelos, informes fotográficos, RFI y registros de cambio pueden alimentar el proceso, siempre que utilicen identificación común y control de revisión.
Las fotografías necesitan contexto. Una imagen aislada rara vez demuestra ubicación, orientación, sistema y condición. El registro debe asociar fecha, área, activo, documento, descripción y responsable. En elementos embebidos o posteriormente inaccesibles, la documentación antes del cierre es especialmente importante.
La solución de Aplicaciones de Campo, Inspección y Recolección de Datos Técnicos permite estructurar esta captura, vinculando fotografías, observaciones y evidencias con los elementos técnicos que serán consolidados.
Control de cambios y trazabilidad
No toda diferencia entre proyecto y campo es un cambio aprobado. El proceso debe distinguir ajuste de representación, corrección de error documental, adecuación de montaje, sustitución equivalente, desviación, cambio de alcance y solución de ingeniería. Cada categoría puede exigir niveles distintos de análisis y aprobación.
La actualización del As-Built debe mantener el vínculo entre condición final e historial de decisiones. RFI, órdenes de cambio, aprobaciones de proveedores, no conformidades, informes de inspección y ensayos son fuentes que explican por qué cambió el documento. Esta trazabilidad es relevante para garantías, auditorías y futuras intervenciones.
Emisiones progresivas por sistema
Esperar la conclusión total del proyecto para iniciar la consolidación aumenta el riesgo. Los documentos pueden emitirse progresivamente cuando sistemas o áreas alcanzan suficiente madurez. Este enfoque permite verificar calidad, corregir estándares e incorporar los datos a la operación antes de la desmovilización de los equipos.
El cronograma debe reservar actividades y recursos para actualización, revisión y aceptación. Project Controls puede acompañar por separado el avance físico y documental. Una instalación concluida sin la documentación correspondiente no representa la entrega integral del paquete.
La calidad del As-Built se decide durante la ejecución.
Cambios, fotografías, aprobaciones y datos de campo deben capturarse mientras los equipos y las evidencias todavía están disponibles.
Qué documentos y datos deben componer la entrega As-Built
El contenido depende del tipo de proyecto, pero la entrega debe representar geometría, conexiones, características, identificación y configuración. Un error común es limitar el As-Built a los planos, ignorando diagramas, listas, memorias y datos digitales que determinan el funcionamiento real del sistema.
La ABNT NBR 5410 indica, para instalaciones eléctricas de baja tensión, planos, esquemas, detalles de montaje, memoria descriptiva, especificaciones de componentes y parámetros de proyecto como contenido mínimo de la documentación que debe actualizarse. En otras disciplinas, normas específicas, requisitos del propietario y contratos deben definir los elementos aplicables.
Planos, dibujos y modelos
Los planos deben mostrar ubicación, rutas, dimensiones, cotas, niveles, áreas, equipos, accesos, interferencias relevantes e identificaciones finales. Cortes, detalles y elevaciones deben actualizarse cuando sean necesarios para comprender montaje, operación o mantenimiento.
Los modelos BIM deben representar la condición acordada de entrega y poseer atributos compatibles con los requisitos de información. Un modelo visualmente detallado, pero sin codificación, clasificación, ubicación confiable o datos de activos, puede tener poco valor operativo. También es necesario aclarar qué fue verificado en campo y qué permanece como información de proyecto.
Diagramas y relaciones funcionales
Diagramas unifilares, funcionales, de bloques, topologías, arquitectura de red, causa y efecto, enclavamientos, flujos y esquemas de conexión representan relaciones que no aparecen adecuadamente en los planos. Deben reflejar equipos, puertos, circuitos, enlaces, direcciones, protecciones, interfaces y redundancias efectivamente implantadas.
En sistemas eléctricos deben consolidarse circuitos, cargas, protecciones, ajustes e identificaciones de tableros. En redes y telecomunicaciones, rutas, racks, fibras, puertos, enlaces, VLAN y topologías finales pueden ser esenciales. En automatización y seguridad electrónica, listas de puntos, lógicas, zonas, permisos e integraciones deben corresponder a la configuración entregada.
Memorias, especificaciones y listas
La memoria descriptiva final debe explicar la solución implantada, los límites del sistema, las interfaces y los principales cambios respecto del proyecto. No debe repetir genéricamente la especificación original cuando la ejecución adoptó equipos, métodos o condiciones diferentes.
Las listas de equipos, cables, circuitos, puntos, instrumentos, señales, materiales y documentos deben utilizar la misma codificación que los planos y el registro de activos. Las divergencias de tag, nomenclatura o ubicación entre archivos hacen insegura la consulta y dificultan la integración con mantenimiento.
Datos de equipos y configuraciones
La condición final incluye información que no aparece en los planos: fabricante, modelo, número de serie, firmware, licencia, dirección, parámetro, ajuste, versión de software, archivo de configuración y backup. La profundidad debe respetar seguridad de la información, responsabilidad y necesidad operativa.
Las credenciales no deben insertarse indiscriminadamente en documentos públicos o de amplia circulación. El propietario debe recibir accesos y claves mediante un proceso seguro, con control de custodia, autorización y recuperación. El As-Built debe indicar dónde se almacena la configuración controlada y qué versión corresponde a la aceptación.
Ensayos, certificados y evidencias
Los informes de ensayo, certificados de calibración, resultados de certificación, registros de inspección y documentos del Comisionamiento en Ingeniería no son planos As-Built, pero validan la condición representada e integran el dossier de entrega.
El vínculo entre documento y evidencia debe permitir identificar qué elementos fueron inspeccionados, probados y aceptados. En instalaciones ocultas, fotografías georreferenciadas, mediciones o registros antes del cierre pueden ser la única evidencia disponible de la ejecución.
Archivos nativos y formatos de entrega
El contrato debe definir si se entregarán archivos editables, PDF firmados, modelos abiertos, hojas de cálculo, bases de datos y archivos propietarios. Entregar solo PDF puede limitar futuras actualizaciones; entregar solo archivos nativos puede comprometer preservación, visualización y formalidad.
Una entrega robusta combina formato de registro y formato de uso. PDF preserva la emisión formal; DWG, RVT, IFC, XLSX o bases estructuradas permiten continuidad técnica; los formatos de configuración preservan parámetros operativos. La estructura debe acompañarse de índice maestro, lista de documentos y reglas de revisión.
La entrega debe combinar geometría, identificación, configuración y evidencias.
Los planos aislados no sustituyen diagramas, listas, datos de activos, archivos nativos ni parámetros finales controlados.
Cómo validar la calidad del As-Built antes de la aceptación
Recibir archivos no significa aceptar el As-Built. La validación debe verificar integridad, fidelidad, consistencia y usabilidad. El proceso puede combinar revisión documental, comparación con registros de ejecución, inspección de campo, muestreo de activos, ensayos y revisión por los equipos que utilizarán la información.
En obras viales federales de Brasil, instrucciones del DNIT tratan el paquete As-Built como parte de la recepción y atribuyen su aprobación a la fiscalización en contextos específicos. Este ejemplo demuestra la relevancia contractual de la validación, pero cada proyecto debe definir sus propias responsabilidades y criterios.
Integridad documental
La primera verificación compara la matriz de documentos con la entrega. Deben evaluarse códigos, revisiones, formatos, firmas, archivos nativos, metadatos y vínculos con sistemas. Los documentos cancelados, sustituidos o no aplicables deben tener su estado registrado para evitar dudas posteriores.
Integridad no significa volumen. Un dossier con miles de archivos puede seguir incompleto si faltan diagramas críticos, parámetros finales, listas coordinadas o documentación de interfaces. El índice maestro debe permitir localizar cada información e identificar su estado.
Fidelidad a la condición ejecutada
La fidelidad puede verificarse mediante muestreo basado en riesgo. Los elementos críticos, cambios relevantes, elementos ocultos, interfaces y áreas con historial de no conformidad requieren mayor profundidad. La inspección debe comparar ubicación, identificación, características y conexiones con la documentación presentada.
Cuando el muestreo revela divergencias sistemáticas, el problema no debe tratarse como un error aislado. Puede ser necesario ampliar la verificación, revisar el método de elaboración y reemitir conjuntos completos. Aceptar documentos basándose solo en una revisión visual del archivo transfiere riesgo al propietario.
Consistencia entre documentos
Plano, diagrama, lista, memoria, modelo y registro deben representar la misma configuración. Un equipo puede aparecer con tags diferentes, un circuito puede tener una descripción incompatible con el tablero o la topología puede no coincidir con la lista de puertos. Estas divergencias son comunes cuando disciplinas y proveedores actualizan archivos sin coordinación.
La Gestión Electrónica de Documentos Técnicos y Control de Revisiones ayuda a mantener versiones, aprobaciones y relaciones documentales. Sin embargo, la plataforma no sustituye la revisión de ingeniería; ofrece control para que la revisión sea trazable.
Calidad de datos y modelos
En bases estructuradas deben verificarse campos obligatorios, formatos, duplicidades, codificación, unidades, coordenadas, relaciones y valores inválidos. En modelos BIM, los criterios de intercambio de información pueden evaluar geometría, clasificación, atributos, federación, interferencias y capacidad para generar el modelo de información del activo.
Los datos deben ser utilizables en los sistemas del propietario. Una hoja de cálculo técnicamente correcta, pero incompatible con el registro de mantenimiento, puede exigir retrabajo. Los requisitos de importación e integración deben definirse antes de la entrega final.
Hito de decisión para la aceptación del As-Built
Antes de la aceptación, confirme que:
- La matriz de documentos está completa y con estado definido.
- Los cambios de campo tienen origen y aprobación trazables.
- Planos, diagramas, listas, memorias y modelos están coordinados.
- Los archivos formales y editables fueron entregados en los formatos contratados.
- Las identificaciones y datos de activos corresponden al campo.
- Las configuraciones, parámetros y backups tienen versión controlada.
- Los elementos críticos fueron verificados por inspección o evidencia equivalente.
- Los pendientes están clasificados, asignados y con plazo definido.
- Operación y mantenimiento pueden localizar y utilizar la información.
- Responsabilidades, garantías y futuras actualizaciones están formalizadas.
El resultado de la verificación debe registrarse en un dictamen técnico, informe o documento de aceptación. La solución de Gestión de Requisitos, Evidencias y Criterios de Aceptación permite relacionar requisitos, documentos, inspecciones, desviaciones y decisiones.
La aceptación exige verificación por muestreo y trazabilidad.
Recibir archivos no demuestra fidelidad al campo, consistencia entre documentos ni capacidad de uso por los equipos del propietario.
Cómo integrar el As-Built con operación, mantenimiento y gestión de activos
El valor del As-Built aparece después de la obra. Reduce tiempo de diagnóstico, orienta intervenciones, sustenta mantenimiento, facilita ampliaciones y preserva conocimiento. Para ello, la documentación no puede permanecer aislada en una carpeta de cierre; debe incorporarse a los procesos y sistemas utilizados por los equipos.
ISO 55001:2024 estructura requisitos para sistemas de gestión de activos orientados a la generación de valor. La documentación final contribuye a ese sistema al proporcionar información sobre configuración, ubicación, condición, responsabilidades y requisitos a lo largo del ciclo de vida.
Incorporación al registro de activos
La estructura de activos debe definirse antes de la entrega, con jerarquía, ubicaciones, tags, clases, criticidad y atributos. El As-Built alimenta esta base, pero los datos deben pasar por validación y normalización. Las importaciones automáticas sin control pueden crear duplicidades, tags incompatibles o relaciones incorrectas.
Los equipos relevantes deben vincularse a documentos, garantías, manuales, planes, repuestos e historiales. El registro no debe depender de rutas de archivo conocidas únicamente por el equipo del proyecto.
Mantenimiento y seguridad de las intervenciones
Los documentos confiables permiten localizar circuitos, aislamientos, válvulas, rutas, dispositivos, interfaces y puntos de acceso. La información incorrecta puede aumentar el tiempo de indisponibilidad y el riesgo de intervención. Por ello, mantenimiento debe participar en la validación de los documentos que utilizará.
El manual del sistema debe complementar el As-Built con modos de operación, límites, alarmas, enclavamientos, procedimientos y recomendaciones. La ABNT NBR 5410 también prevé manual del usuario en determinadas instalaciones sin equipo permanente cualificado, reforzando que la documentación debe adecuarse al perfil de quien la utilizará.
Gestión de configuración y futuras actualizaciones
El As-Built no debe tratarse como una fotografía inmutable. Después de la aceptación, cualquier cambio relevante debe generar una actualización controlada. La organización debe definir quién puede modificar documentos, qué eventos exigen revisión, cómo se aprueban las versiones y qué repositorio representa la condición vigente.
Los cambios en campo sin actualización crean una distancia creciente entre documento y activo. En sistemas digitales, el problema incluye firmware, software, reglas, direccionamiento e integraciones. La gestión de configuración debe abarcar archivos técnicos y condiciones operativas.
Integración con operación asistida
Durante la operación inicial pueden ocurrir ajustes de parámetros, sustitución de componentes, correcciones de identificación y actualización de procedimientos. La operación asistida debe registrar estos cambios e incorporarlos a la revisión final aplicable. Cerrar el proyecto con documentos anteriores a los ajustes posteriores al arranque reduce la confiabilidad de la entrega.
El Documento de Aceptación Técnica en Ingeniería puede indicar la revisión documental aceptada, los pendientes remanentes y la responsabilidad por actualizaciones posteriores.
Preservación, acceso y seguridad de la información
El repositorio debe garantizar disponibilidad, integridad, control de acceso, historial y recuperación. Los formatos propietarios exigen estrategia de preservación y licencias; los documentos sensibles necesitan permisos; los backups deben probarse.
La clasificación de la información debe considerar riesgos físicos y cibernéticos. Diagramas de seguridad, credenciales, configuraciones y rutas críticas no deben circular sin control. Al mismo tiempo, restricciones excesivas no pueden impedir que operación y mantenimiento accedan a lo necesario para trabajar con seguridad.
El documento final debe incorporarse al ciclo de vida del activo.
As-Built, registro de activos, mantenimiento, gestión de configuración y operación deben utilizar la misma base controlada de información.
Cómo contratar, medir y cerrar un alcance As-Built
El As-Built debe contratarse como un proceso técnico, no como una línea genérica de entrega. El alcance debe informar disciplinas, cantidad de documentos, condición de los archivos de origen, necesidad de levantamiento, formatos, grado de verificación, participación de especialistas, número de ubicaciones y criterios de aceptación.
Cuando el proyecto posee documentación organizada y redlines confiables, el esfuerzo es predominantemente de consolidación y revisión. Cuando la instalación está operando sin registros, el trabajo puede exigir diagnóstico, rastreo, ensayos, topografía, escaneo y reconstrucción documental. Las propuestas basadas solo en área física o número de planos pueden ocultar grandes diferencias de complejidad.
Modelos de contratación
La elaboración puede integrar el contrato de ejecución, supervisión, EPC, EPCM, gestión o Owner’s Engineering. También puede contratarse como servicio independiente para instalaciones existentes.
Cuando la ejecutora produce el As-Built, la supervisión o el equipo del propietario debe verificar la entrega. Cuando la documentación se reconstruye después de la obra, el alcance debe establecer limitaciones de acceso, premisas y nivel de certeza. No es técnicamente adecuado afirmar lo que no pudo verificarse.
Medición por entregables e hitos
La medición puede vincularse a la matriz de documentos y a los hitos de emisión. Los porcentajes pueden considerar levantamiento, redline consolidado, emisión para revisión, corrección, emisión final y aceptación. El pago total antes de la aprobación reduce la capacidad contractual de exigir correcciones.
La cantidad de archivos no debe ser el único indicador. Un documento extenso puede exigir más esfuerzo que decenas de listas simples. Criticidad, complejidad, interfaces, formato y calidad de los datos de origen deben considerarse.
Criterios comerciales para comparar propuestas
Las propuestas deben aclarar horas de campo, profesionales, disciplinas, recursos de levantamiento, software, desplazamientos, archivos nativos, cantidad de revisiones y responsabilidad por validación. También deben indicar exclusiones, como elementos ocultos inaccesibles, ensayos destructivos, cálculos de verificación o regularización de soluciones ejecutadas sin proyecto.
La nivelación técnica evita comparar una simple actualización gráfica con un proceso completo de levantamiento, coordinación y validación. El servicio de Proyecto Ejecutivo de Ingeniería puede abarcar la reconstrucción y consolidación documental cuando está asociado a levantamiento y verificación técnica; en proyectos complejos, Owner’s Engineering protege la decisión de aceptación.
Actuación de A3A Engenharia
La A3A Engenharia actúa en la estructuración, elaboración, coordinación y validación de documentación As-Built para instalaciones y sistemas multidisciplinarios. El trabajo puede incluir levantamiento de campo, revisión de documentos existentes, consolidación de redlines, actualización de planos y diagramas, registro de activos, organización de evidencias, control de revisiones y soporte a la aceptación.
La actuación puede integrarse con Proyecto Ejecutivo, Gestión de Proyectos, Comisionamiento, Operación Asistida u Owner’s Engineering. El objetivo es entregar una base técnica que represente el activo, preserve trazabilidad y pueda ser utilizada por la organización durante su operación.
Un As-Built confiable no es el plano final de la obra. Es la conexión entre ejecución, evidencia, aceptación y gestión del activo. Cuando se elabora como proceso continuo y se valida mediante criterios objetivos, reduce riesgos, retrabajo y dependencia del conocimiento informal.
¿Necesita elaborar, actualizar o validar documentación As-Built?
El alcance puede incluir levantamiento de campo, reconstrucción documental, consolidación de redlines, actualización de planos y diagramas, coordinación entre disciplinas, control de revisiones, evidencias y verificación para aceptación.
Cuando el alcance exige levantamiento de campo, reconstrucción documental, consolidación de redlines, actualización multidisciplinaria y verificación para aceptación, el servicio de As-Built de Ingeniería transforma estos requisitos en un paquete contratable de ingeniería con entregables y criterios de validación definidos.
Referencias técnicas
[1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. ABNT NBR 5410:2004 — Instalaciones eléctricas de baja tensión. Ítems 6.1.8.1 a 6.1.8.3. Río de Janeiro, 2004. Versión corregida, 2008.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 19650-4:2022 — Information management using building information modelling — Part 4: Information exchange. Ginebra, 2022.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 55001:2024 — Asset management — Asset management system — Requirements. Ginebra, 2024.
[4] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Ginebra, 2020.
[5] BRASIL. Departamento Nacional de Infraestructura de Transportes. Instrucción Normativa n.º 15/2021. Brasilia, 2021.
[6] BRASIL. Departamento Nacional de Infraestructura de Transportes. Instrucción Normativa n.º 2/2026. Brasilia, 2026.
Preguntas frecuentes
Es la documentación técnica revisada para representar fielmente la condición efectivamente ejecutada de una instalación, sistema, edificio o infraestructura.
El Proyecto Ejecutivo define lo que debe ejecutarse. El As-Built registra lo que efectivamente fue implantado, incluyendo cambios, identificaciones, características y configuraciones finales.
No necesariamente. El redline es el registro controlado de los cambios de campo. Esta información debe verificarse, incorporarse a los documentos finales y emitirse en la revisión definida para As-Built.
La responsabilidad depende del contrato y la disciplina. La actualización puede involucrar ejecutora, proyectista, supervisora, integrador, proveedor o equipo especializado, siempre con profesionales habilitados y responsabilidades claramente definidas.
Según el alcance, incluyen planos, diagramas, memorias, listas, modelos, datos de equipos, configuraciones, archivos nativos, registros y referencias a evidencias de inspección y ensayo.
La validación debe verificar integridad, fidelidad al campo, consistencia entre documentos, calidad de los datos, formatos contratados, trazabilidad de los cambios y capacidad de uso por operación y mantenimiento.
Materiales técnicos complementarios
Whitepapers
- Framework de As-Built en Ingeniería: planificación, gobernanza, validación y aceptación
- Método de As-Built Eléctrico: levantamiento, validación y aceptación
- Framework de Handover Técnico: de la completación a la operación
- Owner’s Engineering: framework ejecutivo para contratación, gobernanza y aceptación
- ENGiOS — Plataforma de Gestión Técnica para Empresas de Ingeniería
Artículos técnicos
- Proyecto Ejecutivo de Ingeniería
- Ejecución de Obras de Ingeniería
- Comisionamiento en Ingeniería
- Documento de Aceptación Técnica en Ingeniería
- Aceptación Técnica en Proyectos de Ingeniería
- Gestión Electrónica de Documentos: conceptos, riesgos y buenas prácticas
Servicios relacionados
- Proyecto Ejecutivo de Ingeniería
- Owner’s Engineering
- Gestión de Proyectos e Implantación
- Servicios Continuados de Ingeniería Consultiva
- Proyecto Eléctrico de Baja Tensión
- Proyecto de Telecomunicaciones
